Навантажувальне тестування та стрес-профілі
Коротке резюме
Навантажувальне тестування - це системна перевірка продуктивності та стійкості під реалістичними та екстремальними сценаріями. Основа успіху: коректна модель трафіку (open vs closed), зафіксовані SLO, чиста метрика (latency/throughput/помилки/насичення), репрезентативні дані, автоматизація і повторюваність. Результат - не «цифра RPS», а рішення: де вузькі місця, скільки коштує продуктивність, де поріг відмови і як його зрушити.
SLO/SLI та цільові метрики
SLO (приклад): p95 API ≤ 250 мс, p99 ≤ 600 мс; помилка ≤ 0. 3 %/30 днів.
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
Буджети помилок і Saturation-тригери (наприклад, CPU> 75% або queue depth> X → деградація).
Види тестів
1. Baseline/Benchmark - одиночний сервіс/ендпойнт, «ідеальні» умови.
2. Load - реалістичний «робочий день» + ramp-up/ramp-down.
3. Stress - нарощуємо навантаження до деградації і фіксації breakpoint.
4. Spike - різкий стрибок (x2-x10 за секунди/хвилини).
5. Soak/Endurance - тривалий прогін (8-72 год): витоку пам'яті, дрейф латентності.
6. Capacity - ступінчасте навантаження для побудови кривої продуктивності і планування ємності.
7. Degradation/Chaos-mix - навантаження + часткові відмови (уповільнена БД, падіння кешу, «схлопнутий» аплінк).
Моделі трафіку: Open vs Closed
Open model (реалістичніше для інтернету): користувачі приходять з інтенсивністю λ (Poisson-подібний потік). Якщо система гальмує, запити накопичуються, а не «заморожуються».
Closed model: фіксоване число віртуальних користувачів (VU) з think-time. При зростанні затримки RPS штучно падає - обережно з висновками.
Рекомендація: для фронтових API використовуйте open model (k6'arrival-rate'), для внутрішніх синхронних сценаріїв - комбінуйте з closed.
Профілі навантаження (шаблони)
«Звичайний день»: базовий фон + денні коливання.
«Пік-івент»: 10-30 хв до старту (прогрів), різкий spike на старті, плато, хвіст.
«Турнір/стрім»: драбинка сходинок, повторні піки в інтервалах.
«Деградація інфраструктури»: половина кеша порожня, один регіон вимкнений, збільшення латентності PSP.
«Failover»: трафік перетікає на резерв за 1-5 хв; перевіряємо авто-скейл/HPA/Retry-шторми.
Дані та підготовка оточення
Тестові дані: реалістичний кардиналітет (провайдери, валюти, країни), «брудні» поля, розподілу запитів (Pareto/Zipf).
Секрети/PII: анонімізація; ключі/PSP - sandbox.
Оточення: виділений perf-стенд, ізоляція від інтеграцій (mock/стаби), фіксовані версії.
Спостережуваність: метрики (Prometheus), логи (Loki/ELK), траси (OTel). Фіксуйте build-id у відповідях.
Антишторму ретраїв та ідемпотентність
Ретраї тільки для ідемпотентних операцій; ставте retry-budget (наприклад, ≤ 10% від трафіку).
Exponential backoff + jitter; «collapsing» ідентичних GET.
Для платежів - ідемпотентні ключі і явні статуси.
Захист від thundering herd: кеш-локи, SWR, локальні семафори.
Інструменти та патерни
k6 (скриптовий, open-model, хороші звітності), Locust (Python-сценарії), Gatling (Scala), JMeter (широкий спектр протоколів).
Протоколи: HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; не тестуйте «як GET».
Генерація трафіку: горизонтальне масштабування генераторів, контроль мережевого вузького місця.
Знімання профілів: pprof/async-profiler/ebpf під навантаженням, траси OTel.
javascript import http from 'k6/http';
import {check, sleep} from 'k6';
export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};
export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}Методика проведення
1. Гіпотеза → які вузькі місця ймовірні (CPU, БД, кеш, мережа, TLS, GC).
2. Профіль → сценарії/маршрути, частки трафіку, моделі (open/closed), дані.
3. Прогрів → кеш/коннекти/TLS/інтерпретатори.
4. Наростання → ступеня до цільової інтенсивності.
5. Плато → збір стабільних метрик і трас.
6. Стрес/спад → пошук точки зламу, спостереження за авто-скейлом.
7. Розбір → кореляція метрик, flamegraph, звіт і план змін.
8. Репруф → повтор через пайплайн CI (Regression Perf).
Аналіз результатів
Крива «навантаження → затримка/помилки»: шукаємо коліно (capacity).
Breakdown латентності: мережа (DNS/TLS/connect), проксі, додаток, БД, зовнішні виклики.
Сатурація: CPU> 75-85%, GC pause> p95, I/O-очікування, черга завдань.
Еластичність: час реакції автоскейла (HPA/KEDA), «холодний старт», прогрів кешу.
Вартість: $/1000 RPS при цільовому SLO, прогноз бюджету на пік.
Інженерні практики
Індикатори деградації: «хвости» p99, зростання черг, падіння hit-ratio, зростання спроб ретраїв.
Виключайте конфаундери: ліміти файлових дескрипторів, sysctl, conn-pool,'reuseport', TLS-ланцюжка, OCSP.
БД: індекси/плани/кеш запитів, пул з'єднань, батч-операції, backpressure на продьюсерів.
Кеші: розмір/eviction-політика, гарячі ключі, реплікації.
Мережа/edge: HTTP/2/3, resumption≥70%, Brotli, CDN-ключ кешу, tiered-cache.
Спостережуваність під навантаженням
Метрики: системні (CPU/mem/IO), runtime (GC/heap), мережеві (RTT/loss/ECN), L7 (p95/99, 5xx/429), черги, кластери БД/кеш.
Трейси: включити семплювання на «хвости» (tail-based), позначки build-id/канарки.
Логи: агрегація помилок з обмеженням обсягу (щоб не «заDOSабо» лог-пайплайн).
Експерименти: feature-flags і конфіги повинні фіксуватися в звіті.
Автоматизація та CI/CD
Perf-jobs в CI (smoke 3-5 хв, nightly 30-60 хв, weekly soak).
Межі допуску: латентність/помилки/ресурси → «ламаємо білд» при регресії.
Артефакти: графіки, flamegraphs, профілі, JSON-звіти (k6/jtl).
Версіонування даних і сценаріїв, PR-рев'ю перф-скриптів.
Специфіка для iGaming/фінтех
Турніри/матчі: spike + plateau; прогрів TLS/DNS/CDN, підвищені ліміти пулів, «сірі» маршрути для ботів.
Платежі/PSP: sandbox-ліміти, ідемпотентність, строгі таймаути; перевірка degrade-mode (кеш довідників, черги).
Джекпоти/івенти: атомарність і послідовність, відсутність дублів, навантаження на RNG/лідерборди.
Антифрод/AML: навантаження на правила/ML-скоринг, backpressure, дедуплікація подій.
Регуляторика: логування метрик і версій при піках, звіти для аудиту.
Чек-лист запуску
- Зафіксовані SLO/SLI і «червоні лінії» (помилка/латентність/сатурація).
- Сценарії та профілі навантаження затверджені (open/closed, spike/soak/stress).
- Дані реалістичні, PII замасковані, інтеграції - sandbox/mock.
- Спостережуваність готова: метрики/трейси/логи, теги релізу.
- Конфіги систем (ulimit/sysctl/pools) задокументовані.
- План авто-скейла/підігріву кешу і rollback-критерії.
Порогові алерти і план зв'язку команд (on-call).
- Звітний шаблон (графіки, висновки, дії) підготовлений.
Типові помилки
Тест closed-model видає «зелений» результат, а прод падає (не можна ігнорувати open-модель).
Нерепрезентативні дані (одна валюта/один провайдер) → помилкові висновки.
Нульова підготовка: холодні кеші/TLS/коннекти → завищена латентність на старті.
Ретраї без лімітів → шторм і каскадні падіння.
Однакові профілі для всіх сервісів → пропуск реальних «гарячих точок».
Відсутність soak-прогонів → витоку пам'яті і дрейф не видно.
Непрозорі результати: немає трас/флеймграфів → неможливо локалізувати вузьке місце.
Міні-плейбуки
Визначення граничної пропускної здатності (breakpoint)
1. Ступені по 10-20% навантаження кожні 5-10 хв. 2) Фіксуємо момент, де p95 різко зростає і помилки> SLO. 3) Знімаємо профілі CPU/БД/кешу. 4) План оптимізацій і повтор.
Приборкання штормів ретраїв
1. Обмежити retry-budget і включити backoff + jitter. 2) Ввести request-collapsing/SWR. 3) Дозволити «деград-режим» (обмежений функціонал). 4) Перевірити ідемпотентність.
Пік-івент (турнір) - перед-план
1. Прогріти CDN/DNS/TLS/пули. 2) Збільшити target HPA, заготовити резерв. 3) Окремі rate-ліміти для ботів. 4) Дашборди «пік-режиму», міст зв'язку on-call.
Soak-ніч
1. 8-12 годин стабільного навантаження. 2) Моніторимо heap/FD/conn/GC-pauses. 3) Звіряємо дельту p95 і hit-ratio. 4) Фіксуємо витоки і дрейф.
Підсумок
Навантажувальне тестування - це процес прийняття інженерних рішень, а не «гонка за RPS». Моделюйте реальні профілі (особливо open-модель), фіксуйте SLO, знімайте метрики і траси, шукайте коліно продуктивності і рахуйте вартість продуктивності. Автоматизуйте прогони, тримайте анти-шторму ретраїв і плануйте пікові події - так платформа буде передбачуваною і стійкою в найнапруженіші моменти.