Балансування навантаження в операціях

1) Навіщо операційній команді управляти балансуванням

Балансування навантаження - це не тільки розподіл запитів. Це шар управління ризиками і продуктивністю: обмеження радіусу відмови, передбачувана латентність, економія на масштабуванні, ізоляція «галасливих сусідів», прямий вплив на виконання SLO і вартість інцидентів.

2) Шари балансування: від мережі до бізнес-операцій

L3/L4 (IP/порт): проста і швидка (DSR, ECMP, IPVS, LVS). Ідеальна для TCP/UDP-сервісів, брокерів, гейтів.
L7 (HTTP/gRPC/WebSocket): маршрутизація по шляху/заголовкам/метаданим; canary, A/B, гео- і клієнт-aware політика.
GSLB/GeoDNS/Anycast: глобальний розподіл по регіонах/РоР, облік затримки, близькості і здоров'я регіонів.
Внутрішньосервісне балансування: клієнти з service discovery (xDS, Consul, Eureka), клієнтські балансувальники (gRPC pick_first/round_robin), service mesh.

3) Алгоритми розподілу і коли їх застосовувати

Round-Robin (RR): простий базовий варіант при однорідних вузлах і коротких запитах.
Least Connections (LC): краще при різній тривалості запитів.
Least Request / Peak EWMA: адаптивно знижує латентність при «довгих» запитах і шумі.
Weighted RR/LC: враховує потужність вузлів або «cost guardrails».
Consistent Hashing (Rendezvous/Maglev): для sticky ключів (користувач, стіл/кімната, кошик), зменшує перемаршрутизацію при масштабуванні.
Power of Two Choices: гарне наближення LC при високому навантаженні з меншою телеметрією.
Hedged/Retry Budgeted Requests: паралельні наздоганяючі запити з бюджетом ретраїв для p99.

4) Сесії, стан і клейкість

Sticky-сесії (cookie/IP/ідентифікатор) - коли кеш населений локально або є stateful-контекст (наприклад, live-стіл в iGaming).
Мінуси: hotspot-ефект, складніше евакуювати вузли.
Рішення: короткі TTL клейкості, винесення стану в зовнішні сховища (Redis, session store), shared-nothing і event-sourcing де можливо.

5) Health-checks і захист від флапінгу

Контентні перевірки L7 (asssert по тілу/заголовку) замість «200-як-успіх».
Комбіновані проби: ТСР + НТТР + внутрішній '/ready'з різними таймаутами.
Дебаунс: n невдач → виняток; m успіхів → повернення в пул.
Outlier detection: автоматичне виключення вузлів з високою error-rate/латентністю (ejection).

6) Політики таймаутів, ретраїв і backpressure

Budget-орієнтовані ретраї: обмеження сумарного часу користувача (наприклад, 800 мс SLA → retriable 2 × по 200 мс + запас).
Circuit Breakers: обмеження одночасних запитів/підключень/к-во помилок.
Quotas/Rate Limits: дефолтні «пер-тенант/пер-IP/пер-ключ» ліміти біля самого краю.
Server-side queueing: короткі черги або відмова з явною деградацією, щоб не «розганяти» хвіст латентності.

7) Глобальне балансування та відмовостійкість

Geo-routing: по затримці (latency-based), по регіону клієнта, по здоров'ю.
Anycast + health-probes: миттєва конвергенція маршрутів при падінні PoP.
Failover-ієрархія: RoR→region→oblako; холодний/теплий/гарячий DR.
Traffic Partitioning: продуктові/юридичні ізоляції (країни, провайдери платежів, VIP-сегменти).

8) Балансування для потоків і реального часу

WebSocket/SSE/gRPC-stream: довготривалі з'єднання → стежте за підключеннями/вузол, перерозподілом при scale-out.
Sticky по користувачеві або по кімнаті/столу через консистентне хешування.
Drain/PreStop Hooks: коректно виселяти з'єднання при релізі і автоскейлі.

9) Безпека на периметрі

TLS-термінація, HSTS, ALPN; mTLS для east-west.
WAF/бот-менеджмент до балансувальника додатків.
DDoS-захист: rate-limits, challenge-/proof-of-work, upstream scrubbing.
Політики як код (OPA/Kyverno/Envoy RBAC).

10) Спостережуваність і SLO для балансування

SLI: успішні запити, помилка/сек, p50/p95/p99 латентність, saturations (CPU/conn/epoll).
Per-backend метрики: request rate, error rate, EWMA-latency → вхід в алгоритми.
Логи L7: кореллюйте з релізами (анотації), фіч-прапорами, канарками.
Алерти: по burn-rate бюджету помилок і по симптомах клієнта (зовнішня синтетика).

11) Автоскейлінг і cost-ефективність

HPA/VPA/KEDA: масштабування за RPS, чергами, призначеними для користувача метриками.
Weighted-routing за вартістю: дешевші регіони/хмари отримують більшу вагу при нормальному навантаженні.
Warm pools/підігрів: заздалегідь прогріті екземпляри, щоб не «ловити» холодний старт.

12) Управління змінами: canary, shadow, blue-green

Canary-маршрутизація: 1%→5%→25% з авто-стопом при деградації по SLO.
Shadow traffic: дублювання запитів у нову версію без відповіді клієнту (для валідації).
Blue-Green: миттєве перемикання VIP/таблиці маршрутизації; швидкий відкат.

13) Конфігурація та GitOps

Єдине джерело правди: маршрути, ваги, політики таймаутів і лімітів - в репозиторії.
Промоція конфігурації по середах (dev→stage→prod) тим же пайплайном.
Валідація та тести конфігурації: лінтери, dry-run, симуляція карт трафіку.

14) Приватні кейси (регульовані домени)

Платіжні/КУС-провайдери: паралельні канали, перемикання за якістю/часом відповіді; пер-провайдер SLO.
Мульти-юрисдикції: гео-маршрутизація, політика контенту/лімітів по країні.
VIP-сегменти: окремі ваги/канали, підвищені SLO, «ручки» деградації UX.

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

Один балансувальник як «єдина точка відмови».
Sticky по IP за NAT - «липкі» кластери і перекіс трафіку.
Універсальний RR при важких/довгих запитах - зростання хвостів p99.
Ретраї без бюджету і без ідемпотентності - шторм запитів.
Health-check тільки TCP - «зелений» при непрацюючому додатку.
«Вічні» клейкі сесії без TTL - неможливість евакуації вузлів.
Конфіги правляться вручну, без рев'ю і промоції - дрейф і інциденти.

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

• Вибрано рівень: L4/L7/GSLB, визначені цілі та зони відповідальності.
• Алгоритм розподілу відповідає профілю навантаження (EWMA/LC/Hash).
• Консистентне хешування там, де потрібен stateful-контекст.
• Комбіновані health-checks, outlier-ejection, дебаунс.
• Таймаути/ретраї/ліміти - як код, з бюджетами часу.
• Спостережуваність per-backend і клієнтська синтетика; burn-rate алерти.
• Canary/blue-green + shadow traffic; швидкий відкат.
• GitOps для конфігов; dry-run і тести маршрутів.
• План DR і ієрархія failover (RoR→region→oblako).
• Ізоляція VIP/юридичних когорт і провайдерів.

17) Приклад архітектурного потоку

1. GSLB (latency-based) направляє клієнта в найближчий здоровий регіон.
2. Edge/L7-балансувальник застосовує WAF, TLS, rate-limits, канарку 5%.
3. Service mesh розподіляє по подах з LC + EWMA, виключаючи outliers.
4. Для real-time столів - consistent hashing по'table _ id', sticky TTL 10 хв.
5. HPA масштабує фронтенди по RPS і чергах; warm pool → без холодного старту.
6. Спостережуваність: дашборд p50/p95/p99, error-rate, saturations, burn-rate.
7. При деградації: auto-eject вузлів, зменшення канарки, перемикання на запасний провайдер, відкат версії.

18) Підсумок

Балансування навантаження - це операційна дисципліна, що з'єднує мережу, додаток, дані і бізнес-SLO. Правильно підібраний рівень (L4/L7/GSLB), адекватні алгоритми, строгі health-checks, політики таймаутів і ретраїв, спостережуваність і GitOps-управління перетворюють балансування з «коробки з налаштуваннями» в механізм стійкої та економічної поставки сервісів.