Балансування навантаження

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 перевірки.
• Коди помилок нормалізовані; ЕТА/причини на клієнт.

Для БД/кешів

• 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.