Что такое load balancer

Load balancer (балансировщик нагрузки) — сетевой компонент, который распределяет входящий трафик между несколькими серверами или инстансами приложения. Его главная цель — обеспечить равномерную загрузку ресурсов, повысить отказоустойчивость и доступность сервиса, а также упростить масштабирование.

Какие задачи решает

• Распределение запросов между доступными бэкендами для равномерной загрузки.

• Повышение доступности: при падении одного узла трафик перенаправляется на здоровые.

• Масштабирование: добавление/удаление инстансов не требует перенастройки клиентов.

• SSL/TLS-терминация (offload): шифрование/расшифровка трафика на балансировщике, разгружая бэкенды.

• Контентная маршрутизация: маршрутизация по пути, хосту, заголовкам или параметрам (важно для микросервисов).

• Health checks: регулярная проверка состояния бэкендов.

• Connection draining/graceful shutdown: завершение текущих соединений при выводе инстанса из пула.

• Логирование и метрики для мониторинга и алертинга.

Уровни работы (Layer 4 vs Layer 7)

• L4 (транспортный уровень — TCP/UDP): маршрутизация по IP/портам, очень быстрая, не смотрит внутрь протокола. Подходит для TCP/UDP-приложений, игр, баз данных (в некоторых случаях).

• L7 (приложенческий уровень — HTTP/HTTPS): анализирует HTTP-запросы, может маршрутизировать по URL, host, заголовкам, cookies. Поддерживает SSL-терминацию, переписывание заголовков, rate-limiting и другие функции.

Алгоритмы распределения трафика

• Round-robin — циклическое распределение.

• Least connections — наказывает узлы с большим числом активных соединений.

• Weighted (взвешенный) — даёт более мощным узлам больше трафика.

• IP-hash / consistent-hash — клиент привязывается к конкретному бэкенду по IP/ключу (полезно для кэшей).

• Random + др. — простые стратегии для специфических случаев.

Сессии и состояние

• Sticky sessions (session affinity): связь клиента с конкретным бэкендом (cookie, source IP). Удобно, но ухудшает балансировку и масштабирование.

• Лучшая практика — делать приложения stateless и хранить состояние в распределённых хранилищах (Redis, DB), чтобы любой инстанс мог обслужить запрос.

Виды и размещение

• Внешний (Edge) LB — для интернет-трафика, обычно с функциями WAF, CDN-интеграции.

• Внутренний (internal) LB — внутри сети/VPC для сервис-ту-сервис коммуникаций.

• DNS-балансировка / GSLB — распределение на уровне DNS (geo-routing, anycast) для глобальной доступности.

• Аппаратные vs программные vs облачные managed сервисы.

Интеграция и эксплуатация

• Интеграция с автоскейлингом: автоматическое добавление/удаление бэкендов.

• Здоровье системы контролируется метриками: RPS, latency p50/p95/p99, error rate, active connections.

• Timeout-ы, keepalive и конфигурация health checks критичны — ошибки здесь приводят к перезапускам или преждевременному исключению узлов.

Распространённые проблемы и риски

• Один LB как SPOF — использование активного кластера/резервирования.

• Неправильные health checks — удаление рабочей ноды или наоборот невыявление падения.

• Sticky sessions мешают масштабированию и ведут к «горячим» узлам.

• SSL-терминация на LB требует корректного управления сертификатами и безопасных настроек.

• Неправильные timeout’ы и размер пулов соединений могут вызвать сбои при пиках.

Типичные реализации

Примеры технологий: программные прокси/балансировщики и сервисные проксies, которые предоставляют возможности L4/L7, health checks, SSL, rate-limiting и интеграцию с оркестраторами. Часто балансировщик ставят перед веб-кластерами, API-gateway и микросервисами (внутренними и внешними).

Заканчивая описание — load balancer является ключевым элементом распределённой архитектуры: он обеспечивает распределение нагрузки, отказоустойчивость, гибкое масштабирование и контроль трафика, но требует продуманной конфигурации health checks, стратегий сессий и мониторинга.