Операції та Управління → Масштабування операційної інфраструктури

Масштабування операційної інфраструктури

1) Навіщо і що вважати «масштабуванням»

Масштабування - це системна здатність платформи збільшувати пропускну здатність (RPS/TPS, коннекти, IOPS, throughput) і обсяг даних без втрати SLO і з контрольованою собівартістю. Для iGaming/фінтеху це безпосередньо про гроші: конверсія депозитів/ставок, live-ігри та розрахунки.

• Тримати SLO при X-кратному зростанні навантаження і сезонних піках.
• Забезпечити передбачуваний час масштабування (minutes, not hours).
• Зберегти економіку: cost/RPS, cost/транзакцію, cost/1k подій.

2) Принципи масштабованої платформи

1. Горизонталь-спочатку: поділ на дрібні, статeless-сервіси; стан - у кластерах даних.
2. Back-pressure і черги: згладжування сплесків, захист від «штормів».
3. Кешування на всіх шарах: client/edge/сервіс/БД.
4. Ідемпотентність і повторюваність: безпечні ретраї, outbox, дедуп.
5. Залежності з обмеженнями: таймаути, брейкери, bulkhead-ізоляція, rate-limits.
6. Спостережуваність за сигналами ємності: headroom, p95/p99, lag, коннекти, квоти.
7. Авто-масштабування з гард-рейлами: HPA/VPA/Cluster Autoscaler + стоп-умови.
8. Multi-region by design: незалежні blast-зони, локальні дані, стійкі фейловери.

3) Capacity planning: як «порахувати, скільки потрібно»

Входи моделі: цільові пікові TPS, профіль трафіку (погодинної), «критичні шляхи», коефіцієнти кеш-хітів, середні payload'и, SLO і ліміти провайдерів.

• RPS → CPU/поди: 'поди = RPS p99_time/ефективне _ CPU _ в _ поді'( з запасом 30-50%).
• Черги: 'мінімальна _ швидкість _ консумерів ≥ пікова _ швидкість _ продюсерів 1. 2`.
• DB-коннекти: 'max _ conns = активні _ пули _ сервісів середній _ pool _ size 1. 3`.
• Кеш: розмір = «гарячий working-set за N хвилин» + 20-30% запас.
• Egress/CDN: пік egress = пік запитів середній розмір відповіді (врахувати компресію).

Headroom: мета 20-40% на піку (по шарах). Нижче 15% → тригер «capacity uplift».

4) Шари і патерни масштабування

4. 1 Edge / CDN / WAF

Кешування на краю (TTL + SWR), гео-баланс, стиснення, HTTP/2/3.
Rate-limits на периметрі по IP/JWT/ключу, захист від сплесків.
Фан-аут подій (джекпоти, live-оповіщення) через брокери/канали pub/sub.

4. 2 API-шлюз/Backend-for-Frontend

Горизонтальне масштабування за статлес-подами, dedicated пули на даунстріми.
HPA по бізнес-метрикам: RPS, p99, черга у ворк-пулі - а не тільки CPU.

4. 3 Асинхронні черги/стрімінг (Kafka/Rabbit/Pulsar)

Масштаб по партіях і консюмерах; уникати skew (ключі і розподіл).
Lag-алерти + авто-масштабування консюмерів; DLQ і retry-топіки.
Retention під SLA реконсиляції і реплея.

4. 4 Кеші (Redis/Memcached)

Кластерні режими, репліки, eviction-політики (LFU), multiget, pipeline.
Розділення hot-key'ев і фонових завдань, ліміти клієнтів і max-memory policy.

4. 5 Бази даних

Read-репліки та роутинг читань, connection pooling.
Шардування по регіону/тенанту/діапазону ключів.
CQRS: записи - на майстер/лідер, читання - в репліки.
Індексування та бетч-друкарські воркфлоу (outbox → stream → sink).
Архівація та гаряче/холодні дані (tiering).

4. 6 Файлові/об'єктні сховища

Багатопоточність, multipart-завантаження, CDN-front, асинхронні трансформації.
Квоти провайдера, чистка «хвостів» і бюджет egress.

4. 7 Провайдери (PSP/KYC/студії)

Мульти-вендор і маршрутизація за квотами/SLO/вартості.
Circuit breaker + rate-limit на кожного провайдера, черга ретраїв, «grace-режими».

5) Авто-масштабування та гард-рейли

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• VPA: рекомендації щодо ресурсів; оновлювати поза піком.
• Cluster Autoscaler: профілі нод-груп (spot + on-demand) з пріоритетами.
• PodDisruptionBudget / TopologySpreadConstraints: рівномірність по зонах.
• LimitRange/ResourceQuota: захист від «п'яних» деплоїв.

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• «Pause & Rollback», якщо при канарці p99> 1. 3 × baseline 10 хвилин.
• «Freeze scale-down» в прайм-тайм, тільки scale-up.
• «Stop retries» при'open _ circuit = 1'до вузьких місць.

6) Multi-region: актив/актив та актив/пасив

Blast-ізольовані регіони: незалежні кластери, локальні секрети/квоти.
Глобальний роутинг: latency-/geo-based, health-probes, ручной override.

• Гарячі - локально + eventual реплікація (стріми).
• Критичні транзакції - узгоджені по домену (ledger/баланси).
• Failover-плейбуки: покрокова зміна джерела, TTL, прогрів кешів.
• Регламент вправ (DR): квартальні тренування з цілями RTO/RPO.

7) Мережеві та сервісні патерни

Service Mesh: mTLS, retry/breaker, outlier detection, пер-даунстрім ліміти.
eBPF/Observability на L4/L7, ліміти на з'єднання, захист від head-of-line.
Внутрішні API-шлюзи для S2S, загальний rate-limit і аудит.
VPC/підмережі по blast-зонах, контроль NAT/Egress, peering з вендорами.

8) Продуктивність: тести та докази

Load & stress в профіль прайм-тайму + worst-case.
Soak (тривалі) - витоки пам'яті/дескрипторів, зростання latency.
Chaos/game-days: падіння брокера/провайдера/зони, «повільний провайдер».
Перф-регресії в CI: набір еталонних сценаріїв і автоматичних гейтів.

9) Дані та сховища: стратегії зростання

Вертикальний ріст до «стелі» → горизонталь/шардинг.
Читання → репліки/кеш; записи → батчі/асинхрон/журнал.
Міграції схем: expand → migrate → contract, без глобальних блокувань.
Архівація: холодні партії в дешеве сховище + on-demand ре-гідрація.
Пошук: окремі індекси (OpenSearch/Solr) з пайплайном інкрементальних оновлень.

10) Управління провайдерами та квотами

Карта квот (TPS, вікна, вартість); альберти'usage _ ratio> 0. 9`.
Роутинг за вартістю/якістю (smart routing).
Угоди OLA ↔ SLO і процес підвищення квот.
Пул альтернатив і «гаряче» перемикання.

11) Спостережуваність і сигнали масштабування

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Бізнес-метрики: success rate/конверсія депозиту, час запуску гри.
• Вартість: cost/RPS, cost/1k calls.

• Capacity Overview (headroom, топ-ризики, burn-rate SLO).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, коннекти, hit/evictions).
• Providers & Quotas (TPS, timeouts, вартість, перемикання).
• Change Safety (до/після релізу, канарка, автогейти).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps: масштабуватися вигідно

Коефіцієнти ефективності: cost/RPS, cost/депозит, cost/1k подій.
Right-sizing: VPA/рекомендації, звіти по «over-provisioned».
Spot/Preemptible для не-критичного; Reserved/Committed для базового навантаження.
Egress-бюджет і кешування, CDN/edge-офлоад.
Збір та архівація логів за рівнем цінності (hot vs cold).
Квоти попереджень (soft-cap) і авто-тікети на розширення.

13) Процеси і люди

Change Management: канарки, фічефлаги, зупинки при регресіях.
Інцидент-готовність: runbook'і «де додати ємність», «як перемкнути регіон».
Планування піків: календар матчів/турнірів/кампаній і вікна провайдерів.
Регулярні game-days і DR-навчання.
Матриця володіння: хто може «жати кнопку» на фейловер/збільшення квот.

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

• Карта критичних шляхів і лімітів (по шарах), мета headroom ≥ 30%.
• HPA по бізнес-метрикам + Cluster Autoscaler; PDB/SpreadConstraints.
• Черги на гарячих шляхах, idempotency-keys, outbox.
• Кеші: hit-цілі ≥ 90%, політика evictions, ключові індекси.
• DB: read-репліки, пул конектів, план шардингу.
• Провайдери: мульти-вендор, квоти, брейкери/ретраї.
• Дашборди «Capacity/Stream/DB/Providers», алерти з § 11.
• Канарка і автогейти «до/після релізу».
• DR-плейбук і один частковий фейловер-тренінг.

• Прогрів кешів, перед-скейл HPA/ASG, warm-standby реплік.
• Підвищення квот провайдерів, включення smart-routing.
• Включення night-mode пригнічень для некритичних алертів.
• Фічефлаг «safe mode» готовий до миттєвого включення.

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

Вертикальний апгрейд «до упору» замість горизонталі.
Загальний пул потоків/з'єднань на всіх даунстрімів (head-of-line).
Ретраї на таймаутах вузьких місць, відсутність джиттера → шторм.
Немає гістерезису в алертах і scale-політиках → «пиляння».
Єдина глобальна БД без шардингу і локалізації даних.
Сліпа віра в SDK вендора без контролю таймаутів/ретраїв/спостережуваності.
Відсутність DR-навчань: фейловер «тільки на папері».

16) KPI масштабованості

SLO-дотримання на піку (p95/p99, success rate).
Headroom по шарах в прайм-тайм.
MTTS (Mean Time To Scale) - до появи додаткових ресурсів.
Backlog/Lag Resolution Time - час схлопування черг після піку.
Change Failure Rate на період активного зростання.
Cost/RPS і економія від кеш/CDN/edge-офлоада.
DR Readiness: RTO/RPO у вправах.

17) Приклади «швидких» шаблонів

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

guardrails:
- metric: api_p99_ms, threshold: 1. 3 baseline_1d, window: 10m, action: pause_and_rollback
- metric: error_rate, threshold: 2 baseline_1d, window: 5m, action: pause max_step: 10%
step_interval: 15m

18) FAQ

Q: Що масштабувати першим?
A: Вузькі місця за даними дашбордів: черги/кеші/читання БД. Гарячі шляхи (депозит/ставка/запуск гри) - в пріоритеті.

Q: Як зрозуміти, що авто-масштабування «робить гірше»?
A: Дивіться кореляцію: scale- up↑, а р99/помилки не поліпшуються - можливо, ви «масштабуєте проблему» (вузький даунстрім/квота). Увімкніть брейкери/деградацію.

Q: Чи потрібен другий провайдер завжди?
A: Для критичних шляхів - так. Інакше хоча б «safe mode» зі спрощеним сценарієм і кешем.

Q: Active-active или active-passive?
A: Якщо вимоги по RTO низькі і багато регіональних гравців - active-active. Інакше почніть з active-passive з відпрацьованим фейловером.