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

1) Цілі та терміни

Балансування розподіляє трафік між екземплярами/зонами/регіонами для продуктивності і стійкості.
Failover - кероване перемикання при відмові.
RTO/RPO: цільовий час відновлення і допустима втрата даних.
SLO: цільовий рівень доступності/латентності; служить «воротами» для автоматичного фейловера і відкату.

2) Шари балансування

2. 1 L4 (TCP/UDP)

Плюси: продуктивність, простота, TLS passthrough. Мінуси: немає розуміння маршруту/куки.
Приклади: NLB/GLB, HAProxy/Envoy L4, IPVS.

2. 2 L7 (HTTP/gRPC)

Плюси: маршрутизація по шляху/хедерам, канарські ваги, sticky. Мінуси: дорожче по CPU/латентності.
Приклади: NGINX/HAProxy/Envoy/Cloud ALB/API Gateway.

2. 3 Глобальний рівень

DNS/GSLB: health-checks + гео/зважена відповідь.
Anycast/BGP: один IP по світу, найближча точка анонсу.
CDN/Edge: кеш/фейловер на периметрі.

3) Алгоритми розподілу

Round-robin/weighted - базові.
Least connections/latency - для «важких» запитів.
Consistent hashing - клейкість по ключу (user/tenant) без центрової сесії.
Hash-based locality - для кешів і stateful-сервісів.

4) Сесії і клейкість (sticky)

Cookie-sticky: L7 LB встановлює cookie для повернення до екземпляра.
Src-IP sticky: на L4, гірше при NAT/CGNAT.
Consistent hashing: краще для горизонтальних кешів/чатів.
Aim: по можливості робіть сервіс stateless, інакше - виносьте стан (сесії в Redis/DB), щоб спрощувати failover.

5) Надійність: health-checks і виведення з ротації

Active checks: HTTP 200/глибокі проби бізнес-шляху (наприклад, '/healthz/withdraw'з залежностями).
Passive (outlier detection): ежекція бекендів при 5хх/таймаутах.
Warm-up: плавне включення нових інстансів (slow-start).
Graceful drain: видалити з пулу → дочекатися завершення запитів.

NGINX (приклад):

nginx upstream api {
zone api 64k;
least_conn;
server app-1:8080 max_fails=2 fail_timeout=10s;
server app-2:8080 max_fails=2 fail_timeout=10s;
keepalive 512;
}
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;

Envoy outlier detection (фрагмент):

yaml outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

6) Управління збоями: timeout/retry/circuit-breaking

Timeouts: коротше, ніж таймаут клієнта; задавати per-route.
Retries: 1-2 з джитером та ідемпотентністю; заборона ретраїв на POST без ключів ідемпотентності.
Circuit breaker: обмеження одночасних запитів/помилок; «напіввідкрите» відновлення.
Budgets: ліміти ретраїв/злиття бурстів, щоб не влаштувати self-DDOS.

7) Kubernetes-патерни

ClusterIP/NodePort/LoadBalancer/Ingress - базові примітиви.
Readiness/Liveness: трафік тільки на готові поди.
PodDisruptionBudget: недопустити одночасне падіння N реплік.
HPA/VPA: масштабування по CPU/RED метрикам, зв'язка з LB.
ServiceTopology/Topology Aware Hints: локальність по зоні.
Service type=LoadBalancer (zonal): мінімум - по 2 репліки в кожній AZ.

Приклад readiness для критичного маршруту:

yaml readinessProbe:
httpGet: { path: /healthz/dependencies, port: 8080 }
periodSeconds: 5 failureThreshold: 2

8) Крос-зонний і крос-регіональний трафік

Multi-AZ (всередині регіону): розподіляйте рівномірно (zonal LB), зберігання - синхронні репліки.

Multi-region:

Active-Active: обидва регіони обслуговують трафік; складніше - потрібна реплікація даних, узгодженість і маршрутизація з географії.
Active-Passive: основний регіон обслуговує, резерв - «гарячий/теплий/холодний». Простіше, швидше перемикання, але вище RPO.

GSLB стратегії:

Geo-DNS (найближчий регіон).
Weighted DNS (канарки/перерозподіл).
Latency-based (RTT-вимірювання).
Failover = за сигналами здоров'я/доступності (probes з декількох vantage-точок).

9) Дані та failover

Кеш/стейт: по можливості - регіонально локальний; для Active-Active - CRDT/консистентні хеші.

БД:

Синхронна реплікація = низький RPO, вище латентність.
Асинхронна = нижче латентність, але RPO> 0.
Черги: дзеркалювання/мультикластерні топіки; дедуплікація подій.
Проектуйте ідемпотентність операцій і replay-механіку.

10) Периметр: DNS/Anycast/BGP/CDN

DNS: короткий TTL (30-60s) + health-checks поза вашою мережею.
Anycast: кілька РОР'ів з одним IP - найближчий приймає трафік, фейловер на рівні маршрутизації.
CDN/Edge: кеш і «шлюз» для захисту, статика/медіа обслуговуються при падінні origin; origin-shield + пер-POP health.

11) Зразки конфігурацій

HAProxy L7:

haproxy defaults timeout connect 2s timeout client 15s timeout server 15s retries 2 option redispatch

backend api balance leastconn option httpchk GET /healthz/dependencies http-check expect status 200 server app1 app-1:8080 check inter 5s fall 2 rise 2 slowstart 3000 server app2 app-2:8080 check inter 5s fall 2 rise 2 slowstart 3000

NGINX sticky по cookie:

nginx upstream api {
hash $cookie_session_id consistent;
server app-1:8080;
server app-2:8080;
}

Envoy retry/timeout (route):

yaml route:
timeout: 2s retry_policy:
retry_on: 5xx,connect-failure,reset num_retries: 1 per_try_timeout: 500ms

12) Автоматичний failover: сигнали та гейти

Тех-SLI: 5xx-rate, p95/p99, saturation, хендшейки TLS, TCP resets.
Бізнес-SLI: успіх депозитів/виплат, немає платіжних помилок у PSP.
Гейти: при перевищенні порогів - відключити зону/інстанс, підняти ваги стабільного пулу, перемкнути GSLB.
Runbook: покрокова інструкція перемикання і повернення (rollback).

13) Тести та інспекції (chaos & game-days)

Chaos-тести: відключення AZ/регіонів, деградації БД/кешів, симуляція packet-loss.
Game-day: тренувальний фейловер за участю on-call команд.
Діагностика: трасування від периметра до бекендів, зіставлення реліз-анотацій і метрик.

14) Безпека та комплаєнс

mTLS між LB↔servisy, WAF/Rate limits на периметрі.
Зони відмови/сегментації: ізоляція blast-radius.
Політики: заборона поодиноких точок відмови (SPOF), вимоги по «мінімум N реплік/AZ».

15) Анти-патерни

Один LB/одна зона для всього прод-трафіку (SPOF).
Відсутність глибокої перевірки «/healthz »(зелене - але БД/черга недоступні).
Ретрай без ідемпотентності → дубль операцій/платежів.
Sticky per IP при масовому NAT → дисбаланс.
DNS-фейловер з високими TTL (годинник до перемикання).
Немає graceful drain при деплое - обрив запитів.

16) Чек-лист впровадження (0-45 днів)

0-10 днів

Рознести інстанси по ≥2 AZ; включити readiness/liveness, health-checks.
Налаштувати L7-timeouts/retries (1 спроба), outlier detection.
Включити graceful drain і slow-start.

11-25 днів

Ввести GSLB (geo/weighted) або Anycast для периметра.
Канарські ваги/політики маршрутів; sticky через cookie/consistent hash.
SLO-гейти для авто-фейловера (p95/5xx + бізнес-SLI).

26-45 днів

Регіональний DR: Active-Active або Active-Passive з тестом перекладу.
Chaos-дні з відключенням AZ/регіонів, звіти RTO/RPO.
Автоматизовані runbook'і (скрипти pause/shift/rollback).

17) Метрики зрілості

Покриття Multi-AZ ≥ 99% критичних шляхів.
DNS/GSLB/Anycast впроваджені для публічних ендпоінтів.
MTTR при падінні однієї AZ <5 хвилин (p95).
RPO для критичних даних ≤ цільового (наприклад, ≤ 30 секунд).
Щоквартальні game-days і успішний плановий фейловер.

18) Висновок

Надійне балансування і failover - це листкова архітектура: локальні L7-політики (timeouts/retries/CB, health-checks), правильна клейкість і хешування, крос-зонна стійкість, а на периметрі - GSLB/DNS/Anycast. Додайте SLO-гейти, ідемпотентність, graceful drain і регулярні chaos-тести - і будь-яка втрата вузла, зони або навіть регіону стане керованою подією з передбачуваним RTO/RPO.

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