Планування потужності і зростання навантаження

Коротке резюме

1. Прогноз попиту (базовий тренд + сезонність + івенти).

2. Модель навантаження (open-model для інтернету).

3. Запас міцності (headroom) і помилковий бюджет.

4. Масштабування (горизонт/вертикаль/авто) + обмежувачі (rate-limit/backpressure).

5. Фінанси: $/1000 RPS, $/мс p95, TCO за сценаріями.

Терміни та метрики

Throughput: RPS/QPS/CPS - фактична пропускна здатність.
Latency p95/p99: цільові SLO для призначених для користувача шляхів.
Saturation: завантаження CPU/пам'яті/IO/FD/з'єднань/черг.
Error rate: 5xx/timeout/429, помилковий бюджет за період.
Headroom: частка вільної потужності при піковому трафіку (рекомендується ≥ 30%).
Burst: короткостроковий сплеск (секунди/хвилини), Spike: різке зростання × N.

Базові моделі та формули

Little's Law (для систем з чергами)

L = λ W

L - середнє число запитів в системі, λ - середня інтенсивність входу (RPS), W - середній час в системі. Корисно для оцінки глибини черг.

Коефіцієнт завантаження (ρ)

ρ = λ / μ

μ - сервісна швидкість (RPS при 100% CPU). При ρ→1 латентність зростає нелінійно - тримайте робочу точку ρ ≤ 0. 6–0. 75.

Safety factor/запас

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Де Degradation_factor враховує відмову N, деградацію кешу, втрату одного РоР/регіону (наприклад, 1. 2).

Прогноз попиту

1. Історія: денні/тижневі профілі, сезонність, кореляція з подіями (матчі/стріми/виплати).
2. Івенти: сценарні коефіцієнти (звичайний день × 1, турнір × 2. 3, фінал × 3. 5).
3. Джерела флуктуацій: маркетингові кампанії, релізи, аномалії ботів.
4. Одиниці прогнозу: RPS за маршрутами (login, lobby, catalog, payments), CPS TLS, QPS DB, IOPS диска, egress Гбіт/с.
5. Довіра: зберігайте два сценарії - консервативний і агресивний.

Моделювання навантаження

Open-model (прихід Poisson-подібний): правдоподібно для публічних API/веба - використовуйте для sizing.
Closed-model (VU + think-time): підходить для внутрішніх послідовностей; комбінуйте.
Суміші маршрутів: вагові частки на ендпойнти; включайте не тільки «гарячі», але і «дорогі» (реєстрація, депозит).
Не забувати: ретраї, черги, ліміти партнерів (PSP, сторонні API).

Проектування запасу міцності

Headroom цільовий: ≥ 30% до піку (для інтернету); для платіжного ядра і критичних шляхів - 40-50%.
N+1 / N+2: витримуємо відмову 1-2 інстансів/зони без порушення SLO.
Multi-region: кожен регіон тягне ≥ 60% сумарного піку (щоб пережити втрату сусіда).
Degrade-режим: відключаємо другорядні функції, знижуємо payload, включаємо кеш/стаб-відповіді.

Sizing по шарах

Мережа/Edge

CPS/RPS на фронті, TLS-handshake p95, resumption≥70%, egress Гбіт/с.
Anycast/Geo-routing, ліміти CDN/WAF (заздалегідь узгодити).
Запас: лінк/аплінк ≥ пік × 1. 3, SYN backlog з запасом, UDP/443 для H3.

Балансувальники/Проксі

RPS на інстанс, open connections, черги, CPU/IRQ.
Keepalive і connection pooling - зменшують з'єднання до бекендів.
Запас: ρ ≤ 0. 7, limiter по CPS/RPS per route.

Додатки

Цільова продуктивність на ядро (RPS/core) в плато.
Пули (thread/DB/HTTP) - не впиратися в ліміти.
Запас: автоскейл до CPU 60-70% і latency-trigger (p95).

Кеші

Hit-ratio, обсяг hotset, eviction, репліка.
Запас: Пам'ять ≥ 1. 2 × hotset, мережевий headroom ≥ 30%.

Бази даних

QPS/TPM, p95 запитів, блокування, буферний кеш, WAL/replication lag.
IOPS і latency диска - ключ до p95.
Запас: робоча точка CPU 50-65%, лаг репліки <цільового; план шардування і read-replicas.

Диски/Сховища

IOPS (4k/64k), throughput, fsync cost.
Запас: IOPS ≥ пік × 1. 5, latency p95 в цільовому вікні; окремі пули під журнал/дані.

GPU/ML (якщо є онлайн-інференс)

Samples/s, latency, VRAM headroom, batching.
Запас: batch-параметри під «пилку» навантаження, warm-pool GPU.

Авто-масштабування

HPA/KEDA: метрики CPU + кастомні (p95 latency, RPS, черга).
Warm pools: перед-розігріті інстанси перед івентами.
Step-scaling: сходинки з cooldown, щоб не «пиляти».
Час реакції: цілимося в T_scale ≤ 1-2 хвилини для фронтового шару; для БД - заздалегідь.

Обмежувачі та backpressure

Rate-limit по IP/ASN/device/route; квоти для партнерів.
Черги з TTL, відмова «ввічливий» (429/через грей-вол) раніше, ніж таймаути.
Ідемпотентність: ключі для платежів; ретраї з budget + jitter.
Request collapsing/SWR: не будити origin під час сплеску.

Приклад швидкого розрахунку

Дано: прогноз піку 35k RPS по API, p95 ≤ 250 мс, середній service time 8 мс на інстанс при 60% CPU → μ≈125 RPS/core, 8 ядер на інстанс → ~ 1000 RPS/інстанс.
Крок 1 (без запасу): 35 інстансів.
Крок 2 (headroom 30%): 35 × 1. 3 = 46.
Крок 3 (відмова одного AZ, + 20%): 46 × 1. 2 ≈ 55.
Крок 4 (округлення + гарячий резерв 10%): 61 інстанс.
Перевірка: ρ ≈ 35k / (61k) ≈ 0. 57 - у зеленій зоні.

Фінансова модель (FinOps)

$/1000 RPS по шарах (edge, proxy, app, DB).
$/мс p95 (вартість зниження хвоста).
TCO сценаріїв: on-demand vs reserved vs spot (з ризиком переривань).
План потужностей: квартальні ліміти акаунтів/кластерів, квоти хмари, ліміти PSP/CDN.

Готовність до відмов і DR

Multi-AZ/region: кожне плече ≈ 60% навантаження.
Failover-план: withdraw Anycast, GSLB перемикання, TTL ≤ 60-120 с.
Критичні залежності: ліміти PSP/банків, вторинний провайдер.
Періодичні навчання: game day з вимкненням PoP/BG/кешу.

Спостережуваність і сигнали раннього насичення

Зростання p95/p99 і черг при стабільному вході.
Падіння hit-ratio кеша, зростання origin egress.
Збільшення retransmits/ECN CE, падіння resumption TLS.
Зростання 429/timeout і retry-rate.
Для БД - зростання конфліктів, checkpoint time, WAL fsync.

Операційні практики

Capacity review щомісяця: факт vs план.
Change windows під івенти: freeze ядра і ліміти.
Prewarm (CDN/DNS/TLS/пули) за 10-30 хв до піку.
Версіонування лімітів: фіксуйте конфіги rate-limit/пулів в Git.

Специфіка для iGaming/фінтех

Турніри/матчі: профілі spike + plateau, сірі маршрути для ботів, окремі ліміти реєстрації/депозитів.
Платежі/PSP: квоти по провайдеру/методу, fallback-маршрути, egress-IP пули, SLA Time-to-Wallet.
Контент-провайдери: розподіл по студіях, гарячі кеші, шард-пули.
Антифрод/AML: ліміт на правила/скоринг, деградація до light-правил при піку.

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

• Прогноз піків (база/сезон/івенти), два сценарії.
• SLO/помилковий бюджет і цільовий headroom ≥ 30%.
• Sizing по шарах (edge/proxy/app/cache/DB/IO/мережа).
• Обмежувачі: rate-limit, черги, idempotency, retry-budget.
• HPA/KEDA + warm pools; план розкрутки перед івентом.
• Multi-AZ/region, failover-плейбуки, TTL і GSLB.
• Квоти хмари/PSP/CDN узгоджені і задокументовані.
• Спостережуваність: дашборди capacity, ранні сигнали насичення.
• DR-навчання і регулярне capacity-review.

Типові помилки

План по середньому RPS без хвостів/сплесків.
ρ≈0. 9 «на папері» - латентність вибухає при найменшому шумі.
Ігнор лімітів зовнішніх сервісів (PSP/CDN/БД-кластера).
Немає degrade-режимів і backpressure - каскадні фейли.
Авто-масштаб без перед-розігріву - встигає «після» піку.
Єдиний headroom для всіх шарів - вузьке місце мігрує.

Міні-плейбуки

Перед піковою подією (T-30 хв)

1. Збільшити minReplicas/target HPA, включити warm pool.
2. Прогріти CDN/DNS/TLS/коннекти, прогріти кеші.
3. Підняти ліміти пулів і квоти PSP за домовленістю.
4. Увімкнути сірі маршрути/бот-фільтри, звузити важкі ендпойнти.

Часткова втрата регіону

1. GSLB → сусідній регіон, TTL 60-120 с.
2. Увімкнути режим degrade (кеш/спрощена видача).
3. Перерозподілити ліміти PSP/egress-IP.
4. Комунікація статусу, контроль р95/помилок.

Сплеск ретраїв

1. Знизити retry-budget, включити backoff + jitter.
2. Включити request-collapsing/SWR на GET.
3. Тимчасово посилити rate-limit для «галасливих» ASN.

Підсумок

Планування потужності - це прогноз попиту + інженерна модель + запас міцності + операційні важелі. Формалізуйте SLO і headroom, враховуйте зовнішні ліміти, автоматизуйте масштабування і деградації, міряйте «вартість мілісекунди» і проводьте регулярні capacity-review. Тоді зростання навантаження перетвориться не на ризик, а на керовану метрику бізнесу.