Планирование мощности и рост нагрузки

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

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, деградацию кэша, потерю одного PoP/регионa (например, 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. Коммуникация статуса, контроль p95/ошибок.

Всплеск ретраев

1. Снизить retry-budget, включить backoff+jitter.
2. Включить request-collapsing/SWR на GET.
3. Временно ужесточить rate-limit для «шумных» ASN.

Итог

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