Что произойдет, если тяжёлые запросы будут прилетать на один хост, а лёгкие на другой

Влияние неравномерного распределения нагрузки на инфраструктуру

Когда тяжёлые запросы (например, сложные вычисления, обработка больших данных, длительные транзакции) концентрируются на одном хосте, а лёгкие запросы (быстрые чтения, простые API-вызовы) — на другом, возникает ряд серьёзных проблем для системы.

Проблемы на хосте с тяжёлыми запросами

1. Ресурсное истощение:
   • CPU будет постоянно на высоких значениях, возможны тепловые троттлинги.
   • Память может заполняться, вызывая свопинг или OOM (Out Of Memory) убийство процессов.
   • Дисковые операции могут стать медленными из-за высокой нагрузки на I/O.

# Пример мониторинга загрузки CPU (top покажет высокие значения)
top -bn1 | grep "Cpu(s)"
# Output может быть: Cpu(s): 95.3%us,  4.7%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si

1. Увеличение latency и timeoutы:

   • Запросы начинают обрабатываться медленно, что приводит к превышению таймаутов.
   • Возможна каскадная деградация, если этот хост критичен для других сервисов.

2. Риск полного отказа:

   • Хост может стать недоступным из-за перегрузки, вызывая partial outage.

Проблемы на хосте с лёгкими запросами

1. Неэффективное использование ресурсов:
   • Сервер работает с низкой нагрузкой, но оплачивается полностью.
   • Это прямо нарушает принципы экономической эффективности в облачных инфраструктурах.

# Пример: средняя загрузка хоста может быть низкой
import random
# Симулируем нагрузку лёгких запросов
request_load = [random.uniform(0.1, 0.3) for _ in range(100)]  # 10-30% утилизации
average_load = sum(request_load) / len(request_load)
print(f"Average load: {average_load:.2f}%")  # Может быть ~20%

1. Психологический эффект "ложной стабильности":
   • Мониторинг может показывать "зелёный" статус по этому хосту, маскируя проблему системы в целом.

Системные проблемы

1. Нарушение баланса:
   • Балансировщик нагрузки (например, nginx, HAProxy) может быть не настроен правильно или использует неадекватный алгоритм (round-robin вместо weighted или least-conn).

# Пример конфигурации nginx с round-robin (проблемный при неравномерных запросах)
upstream backend {
    server backend1.example.com;  # Хост с тяжёлыми запросами
    server backend2.example.com;  # Хост с лёгкими запросами
    # Оба получают равное количество запросов независимо от их сложности
}

1. Сложность масштабирования:
   • Автоскейлинг может неправильно оценивать нагрузку: один хост перегружен, но общая метрика кластера низкая, поэтому новые инстансы не добавляются.

Стратегии решения

1. Улучшение балансировки

• Использовать алгоритмы least connections или weighted load balancing.
• Ввести медленные старты (slow start) для восстановленных хостов.

# Пример: HAProxy с leastconn алгоритмом
backend app_servers
    balance leastconn
    server srv1 192.168.1.1:80 check weight 3
    server srv2 192.168.1.2:80 check weight 1  # Меньший вес, если хост менее мощный

2. Введение очередей и буферизации

• Использовать message queues (RabbitMQ, Kafka) для распределения задач.
• Применять паттерн "тяжёлые задачи в очередь".

# Пример: отправка тяжёлой задачи в очередь Celery
from celery import Celery
app = Celery('tasks', broker='pyamqp://guest@localhost//')
@app.task
def heavy_computation(data):
    # Длительная обработка
    return result
# Лёгкие запросы обрабатываются напрямую

3. Мониторинг и автоскейлинг на основе метрик хостов

• Мониторить не только общие метрики, но и per-instance metrics.
• Использовать пороговые значения для каждого хоста в правилах автоскейлинга.

# Пример правила автоскейлинга Kubernetes HPA с per-instance метриками
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  metrics:
  - type: Pods
    pods:
      metric:
        name: cpu_usage_per_pod
      target:
        type: AverageValue
        averageValue: "70"  # 70% загрузки на каждом Pod, не в среднем на кластере

4. Применение шаблонов распределения

• Sharding данных, чтобы тяжёлые запросы распределялись по разным узлам.
• Использовать read/write splitting для разделения типов операций.

Заключение

Неравномерное распределение запросов — классическая проблема архитектуры распределённых систем. Она требует комплексного решения: от корректной конфигурации балансировщиков и внедрения очередей до совершенствования метрик мониторинга и автоскейлинга. Игнорирование такой ситуации приводит к деградации SLA, финансовым потерям и риску полного отказа сервиса.