Как балансируется нагрузка между несколькими инстансами сервиса?

Балансировка нагрузки — это механизм распределения входящего трафика между несколькими экземплярами сервиса, чтобы система выдерживала больше запросов и продолжала работать при сбоях отдельных узлов.

Где может происходить балансировка

Балансировка может быть реализована на разных уровнях, и это влияет на возможности и стоимость решения.

1. DNS-уровень

Идея:

1. DNS возвращает разные IP для одного домена (например, round-robin).

2. Клиенты попадают на разные точки входа.

Ограничения:

1. DNS-кэширование у клиентов и провайдеров усложняет контроль.

2. Нельзя быстро «убрать» инстанс из выдачи без учета TTL.

Используется для грубой балансировки между регионами или точками присутствия.

2. L4 (Transport) балансировщик

Это балансировка на уровне TCP/UDP.

Что умеет:

1. Распределять соединения по бэкендам.

2. Работать очень быстро и с минимальными накладными расходами.

Чего не умеет (обычно):

1. Не «понимает» HTTP-уровень (URI, headers) как L7.

Примеры логики: распределение TCP-соединений на разные инстансы.

3. L7 (Application) балансировщик

Это балансировка на уровне HTTP/HTTPS (и выше).

Что умеет:

1. Маршрутизация по пути (/api, /static).

2. Маршрутизация по хосту (несколько доменов).

3. Терминация TLS (заканчивает HTTPS на балансировщике).

4. Повторные попытки (retries) при некоторых ошибках.

5. Более умные health checks.

Компромиссы:

1. Дороже по ресурсам.

2. Сложнее конфигурация.

Как балансировщик понимает, куда можно отправлять трафик

Чтобы не отправлять запросы на «мертвые» или перегруженные инстансы, применяются проверки здоровья.

Health check

Варианты:

1. TCP-check: порт открыт и соединение устанавливается.

2. HTTP-check: запрос к /health или /ready.

3. Глубокая проверка: сервис проверяет зависимости (БД, очередь, диск).

Практика:

1. Разделять liveness и readiness.

2. readiness должен отвечать «готов принимать трафик», а не просто «процесс жив».

Если инстанс не проходит check, балансировщик исключает его из пула.

Что происходит при поступлении запроса

На каждом запросе (или соединении) балансировщик обычно делает следующее:

1. Принимает входящее соединение/запрос.

2. Выбирает бэкенд по стратегии.

3. Проксирует запрос (L7) или перенаправляет соединение (L4).

4. Учитывает таймауты и ошибки.

5. При необходимости повторяет запрос на другой инстанс (не всегда безопасно).

Дополнительные важные детали

Session affinity (sticky sessions)

Иногда балансировщик «приклеивает» клиента к одному инстансу.

Зачем это нужно:

1. Если сессия хранится в памяти инстанса.

2. Если есть состояние, которое не вынесено во внешнее хранилище.

Как делается:

1. По cookie.

2. По IP.

Минусы:

1. Ухудшает равномерность распределения.

2. При падении инстанса часть клиентов теряет сессию.

Практический вывод: лучше выносить состояние в Redis/DB и избегать sticky, если возможно.

Таймауты и повторные попытки

Балансировщик обычно имеет:

1. connect timeout — время на установку соединения.

2. read timeout — ожидание ответа.

3. idle timeout — время простоя соединения.

Retries полезны, но опасны:

1. Если запрос не идемпотентный (например, создание заказа), повтор может привести к дублям.

2. Для идемпотентных запросов (GET) retry безопаснее.

Наблюдаемость

Балансировщик часто является ключевой точкой мониторинга:

1. Метрики: RPS, latency, error rate, распределение по бэкендам.

2. Логи: access logs, upstream errors.

3. Трейсинг: прокидывание trace-id.

Это помогает понять, кто «тормозит»: клиент, балансировщик, инстансы или зависимости.

Вывод

Нагрузка между несколькими инстансами балансируется через DNS и/или L4/L7 балансировщики, которые выбирают бэкенд по стратегии и исключают недоступные узлы через health checks. На практике качество балансировки сильно зависит от корректных readiness-проверок, таймаутов, политики retries и того, вынесено ли состояние из памяти инстансов.