Балансировка нагрузки

1) Зачем и где она в архитектуре

• доступность (без единой точки отказа), латентность (p95 вниз), масштаб (горизонталь), безопасность (TLS/WAF), управляемость релизов (canary/blue-green).

• Edge/Global: Anycast, GSLB/GeoDNS, CDN/Edge-LB, DDoS.
• L4 (TCP/UDP): NLB, маглев, прокси без терминации.
• L7 (HTTP/2, gRPC, WebSocket, QUIC): маршрутизация по пути/заголовкам/клеймам, кеш/сжатие/ретраи.
• Data-tier: DB-прокси (PgBouncer/ProxySQL), Redis Cluster/Consistent Hash, Kafka partitioning.

2) Модели и алгоритмы балансировки

Round-Robin (RR): простой равномерный.
Least Connections (LC): хорошо для долгих коннектов (WS, gRPC).
Least Request / Power-of-Two (P2C): сравнение двух случайных — хороший баланс скорость/качество.
Weighted RR/LC: веса для canary/«горячих» нод.
Consistent Hashing (CH): сессионная липкость без таблицы (cart, Redis).
Maglev / Flow-hash: быстрая L3/L4-дистрибуция с устойчивостью к флаппингу.
Latency-aware: выбор по скользящей p50/p95.
EWMA: учитывает историю задержек.

Рекомендация: по умолчанию P2C (least-request) на L7; для stateful/кэшей — consistent hash; для WS/gRPC — least-connections.

3) Здоровье апстримов: проверки и «выселение»

Health-checks: TCP, HTTP 200/匹配 тела, gRPC status; интервалы/таймауты/порог ошибок.
Outlier Ejection: автоисключение «шумных» инстансов (consecutive-5xx, success-rate-ejection).
Slow-start & warmup: мягкий ввод новых инстансов (постепенный рост веса).
Connection draining: при выкл/деплое — «доливка» активных коннектов без обрыва.

4) Сессии и липкость (stickiness)

Cookie-stickiness (L7): `Set-Cookie: lb=<id>; SameSite; Secure`.
CH по ключу: `hash(userId|sessionId|cartId)`.
IP-hash — только в закрытых сетях (NAT ломает).
TTL липкости + fallback при эвикции ноды.
Важно: минимизируйте необходимость липкости → храните состояние вне инстанса (Redis/DB/JWT).

5) Глобальная балансировка (GTM/GSLB)

Anycast + health-probe: один IP, трафик в ближайший PoP; автоматический фейловер.
GeoDNS/Latency-DNS: ответ по гео/задержке.
Региональные кластеры: «данные резидентов» остаются в регионе (GDPR); межрегиональный failover с репликацией.
Политики: гео-блоки, «стикерегион» по аккаунту/токену.

6) Протоколы и особенности

HTTP/2: мультиплекс, приоритеты; нужен грамотный connection-pool на апстрим.
gRPC: долгоживущие стримы → least-connections, агрессивные health-checks.
WebSocket/SSE: липкость по коннекту, большие idle-таймауты, TCP keep-alive.
QUIC/HTTP/3: быстрый старт, устойчивость к потере; следите за MTU/патх-MTU.
TLS-termination/mTLS: терминировать на edge/L7-LB; внутрь — mTLS/identity (SPIFFE).

7) Защита от перегрузки (overload control)

Rate-limit: per-IP, per-key, per-route; burst+sustain.
Adaptive Concurrency (Envoy): динамический предел одновременных запросов.
Queue/Surge-buffer: ограниченный размер очереди с честным отказом 503.
Hedging / Parallel racing: дублирование медленных запросов (только идемпотентные).
Timeout budget: раздельные connect/read/write.
Backpressure: `503 + Retry-After`, клиентские экспоненциальные ретраи с джиттером.
Slow-loris защита: таймауты чтения/записи, минимальная скорость.

8) Релизы и трафик-менеджмент

Canary (weighted): 1–5–10–25–50–100% с guardrails (p95, 5xx, timeouts).
Blue-Green: мгновенный свитч, откат — DNS/LB.
Shadow/Mirror: копия запросов без влияния на ответ; маскирование PII.
Header/Claim-routing: `X-Canary: 1` или `JWT.claims.region/role`.

9) Автоскейлинг и дренаж

HPA/ASG по CPU+RPS+p95+queue-depth.
PreStop hook: дождаться завершения коннектов.
Warm pool/instance reuse: сокращение холодных стартов.
Capacity planning: целевые `utilization 60–70%` при p95 в норме.

10) Наблюдаемость и SLO

Метрики LB: RPS, p50/p95/p99, 4xx/5xx, open-connections, queue-len, ejections, retries, hit-ratio кеша.
Трейсинг: `traceparent/x-request-id` сквозь LB → сервисы → БД.
Логи: структурные, маски PII/PAN, кореляция с апстримом.
SLO по маршруту: например, `latency p95 ≤ 300 ms`, `availability ≥ 99.9%`, `5xx ≤ 0.5%`.
Алерты: по отклонениям (burn-rate SLO, всплеск ejection, рост 5xx/timeout).

11) Балансировка данных и кэшей

• Read/Write split (ProxySQL/pgpool) + read-replicas; sticky-txn.
• Failover: синхронная реплика для RPO=0 (дороже).

• Redis Cluster + hash-slot; для сессий — CH; таймауты/Retryable errors.

• Баланс через partitioning и consumer-groups; не путать с HTTP-LB.
• Object Storage (S3/MinIO): multi-region failover через GSLB/replication.

12) K8s и облачные LB

Service (ClusterIP/NodePort/LoadBalancer) — базовая L4.
Ingress / Gateway API — L7-маршрутизация, канареечные веса, TLS.
AWS: NLB (L4, высокая пропускная), ALB (L7, WAF, sticky, header-routing).
GCP: Global LB (L7/HTTP(S) с Anycast), TCP/UDP proxy LB.
Azure: Front Door (global), Application Gateway (L7), Load Balancer (L4).

13) Примеры конфигураций

13.1 NGINX (L7, least_conn, sticky, canary)

nginx upstream api_pool {
least_conn;
server api-1:8080 max_fails=3 fail_timeout=10s;
server api-2:8080 max_fails=3 fail_timeout=10s;
sticky cookie lb_id expires=30m path=/ secure httponly;
}

map $http_x_canary $dst {
default api_pool;
1    canary_pool;
}

upstream canary_pool {
least_conn;
server api-canary:8080 weight=1;
}

server {
listen 443 ssl http2;
location /api/ {
proxy_read_timeout 5s;
proxy_connect_timeout 1s;
proxy_set_header X-Request-Id $request_id;
proxy_pass http://$dst;
}
}

13.2 HAProxy (P2C, health, slowstart, stick-table)

haproxy backend api balance leastconn option httpchk GET /health default-server inter 3s fall 3 rise 2 slowstart 10s server s1 10. 0. 0. 11:8080 check server s2 10. 0. 0. 12:8080 check stick-table type ip size 100k expire 30m http-request track-sc0 src rate limit per IP http-request deny deny_status 429 if { sc_http_req_rate(0) gt 50 }

13.3 Envoy (P2C, outlier, retries, adaptive concurrency)

yaml load_assignment: {... }
lb_policy: LEAST_REQUEST least_request_lb_config: { choice_count: 2 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s typed_extension_protocol_options:
envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency:
gradient_controller_config:
sample_aggregate_percentile: PERCENTILE_50 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 1s

13.4 Kubernetes (Gateway API, weighted canary)

yaml apiVersion: gateway. networking. k8s. io/v1 kind: HTTPRoute spec:
rules:
- matches: [{ path: { type: PathPrefix, value: /api }}]
backendRefs:
- name: api-v1 weight: 90 port: 8080
- name: api-v2-canary weight: 10 port: 8080

14) Чек-листы

Перед релизом LB/маршрута

• Алгоритм выбран (P2C/LC/CH) под тип трафика.
• Health-checks и пороги ejection настроены.
• Slow-start, warmup, connection-drain включены.
• TLS/mTLS, HSTS, безопасные шифры; HTTP/2/3 при необходимости.
• Sticky/CH только если требуется; TTL и fallback.
• Rate-limit/burst, timeouts, retry-budget, adaptive concurrency.
• Логи/трейсы: `trace-id` прокидывается; маскирование PII.
• SLO/алерты по p95/5xx/элекциям/queue-len.
• Канареечные веса + план отката; shadow при больших изменениях.

Для платежных/комплаенс-маршрутов

• Идемпотентность POST (Idempotency-Key).
• Failover между PSP; same-method проверки.
• Коды ошибок нормализованы; ETA/причины на клиент.

Для БД/кэшей

• RW-split/реплики; таймауты, сетевые retry-ы.
• CH/slot-hash для Redis; защита от «горячих ключей».
• Мониторинг задержек и replication-lag.

15) Метрики качества (минимум)

Latency p50/p95/p99 по маршрутам/методам.
Error rate 4xx/5xx, timeout/overflow.
Open/active connections, queue depth, retry count.
Outlier ejections и причины.
Sticky hit-ratio / cache hit-ratio.
GSLB: региональное распределение, фейловеры, доступность PoP.

16) Анти-паттерны

Один монолитный LB без резервирования.
Sticky-сессии «на все», вместо выноса состояния.
Глобальные бесконечные очереди (скрывают проблему, растят p99).
Ретраи без джиттера/бюджета — «шторм» запросов.
Доверие `X-Forwarded-For` без списка доверенных прокси.
Отсутствие drain при деплоях → обрывы WS/gRPC.
Неучет long-lived коннектов при автоскейле.

17) iGaming-специфика

Пики и турниры: micro-cache на справочниках/листингах (1–5 с), авто-скейл по очереди.
Лайв-игры/стримы: LC для долгих коннектов, приоритет ближайших PoP.
Платежи: маршрутизация по гео/валюте/сумме/провайдеру; строгие таймауты и идемпотентность.
Ответственная игра и комплаенс: приоритет пропускать запросы лимитов/блокировок даже при деградации (fail-open/close по политике).

18) Процесс внедрения (4 спринта)

1. Карта трафика: протоколы, нагрузки p95/p99, критичные маршруты.
2. Конфигурация LB: алгоритмы, health/outlier, TLS, лимиты/таймауты, observability.
3. GSLB/Edge: Anycast/GeoDNS, PoP-хелсчеки, региональные политики данных.
4. Релиз-стратегия: canary/shadow, SLO-алерты, автоскейл + drain, пост-инцидентный разбор.

Итоговая шпаргалка

Выбирайте алгоритм под тип трафика (P2C/LC/CH) и длительность коннекта.
Держите апстримы «здоровыми»: health-checks + outlier + slow-start + drain.
Управляйте пиковой нагрузкой: rate-limit, adaptive concurrency, очереди с отказом.
Используйте GSLB/Anycast для глобальной доступности и комплаенса по регионам.
Наблюдаемость и SLO — обязательны; релизы — через canary/shadow с планом отката.
Где возможно — убирайте сессионность из инстансов и липкость из LB.