Нагрузочное тестирование: профили игроков и пики трафика

1) Зачем моделировать профили, а не «среднюю температуру»

У iGaming-нагрузки высокая взрывчатость: промо/турниры/стримы дают кратные всплески RPS, а распределение действий неравномерно (логин→депозит→ставки/вывод). Тест должен отражать поведение сегментов (новички, VIP, «бонус-хантеры», мобильные), иначе вы получите «зелёные графики» и красные инциденты.

Ключевые SLO (пример на 30 дней):

Логин: успешность ≥ 99.9%, p95 ≤ 250 мс
Депозит: успешность ≥ 99.85%, p95 ≤ 400 мс
Ставка (WS): p95 message RTT ≤ 120 мс, disconnect rate ≤ 0.5%
Запуск игры: успешность ≥ 99.8%, p95 ≤ 800 мс

2) Профили игроков (поведенческие сценарии)

A. Newbie (новый игрок) — 25–40% пикового трафика

Путь: регистрация → логин → просмотр промо → депозит (малые суммы) → запуск 1–2 слотов

Особенности: высокая доля ошибок UX, ретраи платежей, скачки между страницами

B. Regular (возвратный) — 40–50%

Путь: логин → быстрый депозит/без депозита → 3–5 игр → редкий вывод

Особенности: стабильные сессии, чувствителен к p95>200 мс на WS

C. Bonus-hunter (промо) — 10–20% при акциях

Путь: регистрация → активация бонуса → минимальные ставки → попытка быстрого вывода

Особенности: всплески к `/promo/claim`, злоупотребление ретраями, частые 429 без правильных лимитов

D. High-roller / VIP — ≤ 1%, но высокий чек

Путь: логин → крупный депозит → лайв-игры/высокие ставки → вывод

Особенности: чувствителен к любой задержке/фейлам провайдера игр, критичен SLA платёжек

E. Bettor (спорт/лайв)

Путь: логин → подписка на котировки → частые ставки в «узких окнах» (до 10–30 с)
Особенности: пульсирующая нагрузка на WS/кэш коэффициентов, всплески при голах/VAR

3) Модели трафика и тайминг

Open vs Closed model

Open (Poisson, arrivals/sec) — подходит для публичных промо и стримов (пользователи «приходят сами»).

Closed (фикс. число виртуальных пользователей с think-time) — для стабильных сессий (VIP, лайв-игры).

Трафик-паттерны:

Ramp: линейный разгон x1 → x5 за 10–20 мин
Burst: «взрыв» x3–x10 на 30–120 с (анонс бонуса/джекпота/гол)
Wave: гребни каждые 5–10 мин (стрим/турнирные раунды)
Soak: 2–12 ч стабильной нагрузки (утечки, GC, дескрипторы, деградации)

4) Критичные флоу и метрики

Аутентификация и профиль

RPS на `/login`, `/2fa/verify`, p95/p99, error-rate, lock/ratelimit-сработки

Платежи

`/payments/deposit	withdraw` по провайдерам: success-ratio, p95/p99, колбэки, идемпотентность
Ограничения PSP (per-merchant RPS/транзакции в минуту), очередь ретраев

Игровые гейты

Запуск слота/лайв-стола: success-ratio, time-to-first-spin, отказ провайдера

WebSocket: соединений в пике, сообщения/сек, RTT, rate-limit/429, reconnects/min

Промо/бонусы

`/promo/claim`, `/freespin/activate`: 200/4xx/5xx, доля 409/конкурентные апдейты, каскады на кошелёк

Хранилища и очереди

Saturation: CPU, DB-connections, pool-timeouts, queue lag, GC pauses

5) Гео и реальность сети

Геораспределение по рынкам (EU/LatAm/MEA/APAC) и ASN-микс (мобильные сети, хостинги).

Латентность edge→origin (Anycast/CDN), mobile RTT, пакетные потери.

A/B: с CDN и в обход (origin) — для оценки «чистого» бэкенда.

6) Дизайн тестовых данных

Псевдонимизированные аккаунты, BIN-карты по регионам, валюты, KYC-состояния.

Реалистичные поведенческие тайминги: think-time 1–7 с для casual, 0.3–1.2 с для live-ставок.

Контроль неидемпотентных операций (вывод/депозит): сухой режим для PSP sandbox, заглушки кошелька.

Анти-фрод/бот-фильтры: whitelist тестовых ASN/IP/девайсов, иначе WAF/anti-bot «задушит» стенд.

7) План тестов (шаблон на релиз/промо)

1. Smoke-нагрузка: 10–20% от пика, 30 мин

2. Capacity ramp: x1 → target → x1.5 от целевого пика, по 10–15 мин на ступень

3. Burst-серии: 3–5 волн по 60–120 с на x3–x5 от текущего уровня

4. Soak: 4–8 ч на 60–80% пика (утечки, деградации)

5. Failover/Chaos: отключение одного PSP/PoP, деградация провайдера игр, падение одного shard БД

6. WS-шторм: массовые reconnect + 5–10× сообщений в течение 2–3 мин

7. Promo-шторм: /promo/claim + регистрация + депозит в 60-сек «окне»

Критерии выхода: все SLO в зелёной зоне; headroom ≥ 30% по CPU/коннектам; PSP-квоты не превышены; нет роста очередей и p99 после теста.

8) Инфраструктурные паттерны для выдерживания пиков

Warm-pool/provisioned concurrency (функции/контейнеры), pre-scale перед промо.

Connection pooling и лимиты на upstream (DB/PSP) + очереди запросов.

Idempotency keys на депозиты/вебхуки.

Backpressure: 429/503 с `Retry-After`, деградация «тяжёлых» рутов (репорты/поиск).

Кэш/edge-кэш коэффициентов и статик-метаданных игр.

9) Анти-регресс: что «ломается» в первую очередь

Переполненные DB-пулы → рост p99 и тайм-ауты

Wallet-locking при массовых апдейтах баланса

PSP-rate limits → лавина ретраев и дублей
WS-broadcast на тысячи подписок без батчинга
Слишком агрессивные WAF-правила → FPR на логине/депозите

10) Наблюдаемость во время теста

Дашборды RED/USE + бизнес-воронки (логин→депозит→ставка→вывод).

Трейсы end-to-end для «медленных»/ошибочных запросов (100% sample ошибок).

Маркеры этапов теста (ramp/burst) в метриках/логах.

Отдельные панели PSP/провайдеров игр, очередь ретраев, idempotency-хиты.

11) Команда и процесс

War-room: перфоманс-инженер, бэкенд, SRE, риск/платежи, WAF/безопасность, продукт.

Runbook: что делаем при p99>целевого, как понижаем нагрузку, кого звать у провайдера.

Отчёт: SLO, пропускная способность, узкие места, стоимость, рекомендации по коду/архитектуре/квотам.

12) Капасити-план: от числа игроков к RPS

Оценка (пример):

Одновременные игроки в пике: 50k
Средняя частота действий: 0.25–0.5 req/s на игрока (мобильный ниже, live выше)
Оценочный API RPS: 12.5k–25k + сервисные запросы (кошелёк, провайдеры, кэш)
WS: 30–60k активных коннектов, 3–8 msg/s на стол/тему
Добавьте 30–50% headroom на burst и ретраи

13) Чек-лист подготовки стенда

Данные: аккаунты/кошельки/карты/валюты/страны/игры, псевдонимизированные
Изоляция платёжек: sandbox + заглушки вебхуков, запрет «живых» списаний
Edge/CDN/WAF как в проде; антибот в «мягком» режиме для тестовых ASN
Наблюдаемость: дашборды, алерты, трассировка включены
Автоскейл и warm-pool настроены; лимиты пулов/коннектов задокументированы
Канареечный флаг для «тяжёлых» фич (репорты, массовые экспорты)

14) Инструменты (ориентиры)

Генераторы: k6, Gatling, Locust (HTTP/WS), JMeter (в т.ч. WebSocket плагин)

Фид-эмуляторы: кастомные скрипты котировок/провайдеров игр

Трафик-реплей: tcpreplay/ingress-зеркалирование с анонимизацией и нормализацией

15) Пример профиля «Промо-турнир, 60 секунд до старта» (кейс)

Волна −5 мин → 0:

Open arrivals: 400 → 2 500 req/s (логин/refresh)
`/promo/claim`: bursts по 1 000 rps 3× по 20 с
WS: +15k connect, +5 msg/s на тему «leaderboard»

Готовность:

Предпрогрев кэша и warm-pool
Rate-limit `/promo/claim`: 10/min IP, 2/min аккаунт, 30-сек кэш отрицательных ответов
Идемпотентность и очередь бонусных начислений (batch 50–100/такт)
«Мягкий» 429 с `Retry-After` + UI-прогресс

Критерии успеха: нет деградации SLO логина/депозита, p95 WS < 150 мс, <0.5% ошибок claim, отсутствие раздувания очередей.

Резюме

Нагрузочное тестирование iGaming — это поведенческое моделирование, а не «стрельба по эндпойнту». Сначала определите SLO и профили игроков, затем выбирайте модель трафика (open/closed), строите реальные сценарии логина/депозита/ставок/промо с гео и лимитами PSP, тестируйте bursts и soak, включайте наблюдаемость и готовьте автоскейл. Закрепляйте результат капасити-планом и runbook’ами — так вы встретите пики трафика без сюрпризов и потерь конверсии.