Устойчивая архитектура LB: anycast, zone-aware маршрутизация и observability

Ваш балансировщик здоров. Потом — нет. Все клиентские соединения обрываются одновременно, потому что единственная машина LB упала. Ваш балансировщик нагрузки — компонент, призванный сделать backend устойчивым — является единственной точкой отказа.

Единственная точка отказа LB

Если балансировщик — это одна машина, её отказ выводит из строя весь трафик. Даже с горячим резервом (active-passive failover) переключение занимает 10–30 секунд — достаточно для замечания пользователями.

Решение: anycast + BGP ECMP

Несколько машин LB все анонсируют один anycast VIP (virtual IP) через BGP. Equal-Cost Multipath (ECMP) маршрутизация сети распределяет клиентский трафик по всем LB:

• Клиент подключается к IP 203.0.113.10 (VIP).
• BGP видит несколько маршрутов равной стоимости к 203.0.113.10 — один через LB_A, один через LB_B, один через LB_C.
• ECMP хеширует 5-tuple (IP источника, порт источника, IP назначения, порт назначения, протокол) для выбора пути.
• Если LB_A падает, BGP отзывает его маршрут. ECMP пересчитывает хеш на LB_B или LB_C. Конвергенция: <1 секунды.

Требование stateless LB. Когда ECMP перенаправляет поток на другой LB, у этого LB нет памяти о предыдущем состоянии. Если LB хранил состояние соединения (TLS-сессия, состояние HTTP/2 потока) локально, клиент должен переподключиться. Stateless LB не хранят состояние на поток — каждое соединение самодостаточно. Именно поэтому Maglev (LB Google) использует consistent hashing 5-tuple для всегда отображения одного потока на один и тот же LB, даже при изменении набора машин.

Zone-aware маршрутизация

Проблема: Клиент в зоне A (us-east-1a), маршрутизирующий на backend в зоне B (us-east-1b), несёт:

• Стоимость межзонального исходящего трафика: $0,01–0,02/ГБ в большинстве облаков.
• Дополнительную задержку: 1–5 мс внутрирегиональный RTT.

Zone-aware маршрутизация: Предпочитать backends в той же зоне, что и LB. Переходить в другие зоны только когда все backends в той же зоне нездоровы или достигнуты пределы circuit breaker.

Zone-affinity AWS ALB: Включена по умолчанию в новых регионах AWS. Envoy: locality_weighted_lb_config с предпочтением локальной зоны. GCP: использует zone-affinity режим по умолчанию когда backends охватывают зоны.

Изоляция зонального отказа. При частичном отказе зоны A zone-aware маршрутизация предотвращает каскадирование: трафик остаётся в зоне A (или перемещается в зону B/C только для трафика зоны A), поэтому зоны B/C внезапно не поглощают 3-кратную нормальную нагрузку.

Завершение TLS на LB

LB завершает TLS: расшифровывает TLS-сессию клиента, видит открытый текст и (опционально) повторно шифрует соединение к backend или отправляет открытый текст по внутренней сети.

Преимущества:

• Backends не нужно управлять сертификатами — один сертификат на edge LB.
• Стоимость TLS-рукопожатия (~20–50 мс на новое соединение) несётся один раз на LB, а не каждым backend.
• LB может завершать TLS 1.2 от старых клиентов и обновляться до TLS 1.3 на соединении к backend.

TLS 1.3 0-RTT возобновление на LB. Если у клиента есть pre-shared key (PSK) от предыдущей сессии, первый запрос может быть отправлен в том же flight, что и ClientHello — нулевые дополнительные round trip. LB должен маршрутизировать запрос возобновления на тот же LB-экземпляр, который хранит session ticket, или PSK должен храниться в распределённом кэше сессий, общем для всех LB.

Стоимость: ~20–50 мс на новое соединение, 50–2 000 мс при пиках нагрузки. Повторное использование TLS-сессии амортизирует это по множеству запросов.

DNS балансировка нагрузки vs LB-маршрутизация

DNS round-robin: Возвращать несколько A-записей для одного hostname. Клиенты выбирают одну. Просто, но:

• TTL DNS 60–300 секунд — изменения backend не отражаются до 5 минут.
• Клиенты кешируют DNS-результаты и нарушают балансировку.
• Нет осведомлённости о здоровье — DNS возвращает мёртвые backends до истечения TTL.

Правильный паттерн: DNS указывает на один anycast VIP (один на регион). Кластер LB за VIP обрабатывает балансировку на запрос. DNS обеспечивает географическую маршрутизацию (возвращает ближайший региональный VIP); LB обеспечивает балансировку на запрос внутри региона.

Observability: минимально необходимые метрики

Метрики, требующие алертинга для кластера балансировщиков:

1. Частота запросов на backend (метод RED: Rate, Errors, Duration).
2. p50/p95/p99 задержка на backend — p99 показывает tail latency, затрагивающую 1% пользователей.
3. Частота ошибок на backend — алерт при > 0,01%.
4. Количество активных соединений на backend.
5. Частота успеха/отказа health check — алерт при флаппинге.
6. Открытия/закрытия circuit breaker — одно в неделю нормально; 10 в час сигнализирует о проблеме.
7. Частота retry — алерт при > 0,1% от частоты запросов (ранний признак бури).
8. Дисбаланс нагрузки — стандартное отклонение количества запросов по backends; высокий дисбаланс сигнализирует о проблемах алгоритма или affinity.
9. Время drain при отключениях — длинное время drain (приближающееся к таймауту) сигнализирует о долго выполняющихся запросах.

SLO:

• p99 задержка < 100 мс для API endpoint.
• Частота ошибок < 0,01%.
• Время открытого circuit breaker < 1 минуты/неделя.