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

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

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_в_поде` (c запасом 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↑, а p99/ошибки не улучшаются — возможно, вы «масштабируете проблему» (узкий даунстрим/квота). Включите брейкеры/деградацию.

Q: Нужен ли второй провайдер всегда?
A: Для критичных путей — да. Иначе хотя бы «safe mode» с упрощенным сценарием и кэшем.

Q: Active-active или active-passive?
A: Если требования по RTO низкие и много региональных игроков — active-active. Иначе начните с active-passive с отработанным фейловером.