Навантажувальне тестування: де інфраструктура ламається першою
Навантажувальне тестування інфраструктури відповідає не на питання «скільки запитів за секунду витримує сервіс», а на питання, що саме відмовляє першим.
Пул з’єднань до бази вичерпується раніше, ніж закінчується процесорний час: застосунок починає чекати на вільний слот, час відповіді зростає нелінійно, а зовні це виглядає як «сервіс працює, але повільно».
Точки відмови під навантаженням майже ніколи не збігаються з тим, що показує моніторинг у спокійному режимі.
Другий типовий шар — дискові операції та черги. Запис журналу, синхронне скидання на диск, накопичення завдань у черзі фонових обробників: поки запас великий, усе виглядає рівно, але при наближенні до межі пропускної здатності черга зростає швидше, ніж її встигають розбирати.
Деградація під піковим навантаженням іде каскадом — повільний диск гальмує обробник, обробник займає з’єднання, з’єднання вичерпує пул.
Третій шар — ліміти зовнішніх сервісів: квоти на виклики, обмеження на кількість одночасних запитів, таймаути на боці партнера.
Вузьке місце в контурі часто перебуває саме там, за межею нашої зони контролю, і без заміру його не видно: сервіс відповідає швидко, поки ліміт не вибрано, а після — частина запитів отримує відмову.
Тому замір будується як пошук межі пропускної здатності з поступовим зростанням навантаження, а не як один прогін на максимумі. Розбираємо, як вибудувати такий замір і що він показує про запас вашої інфраструктури.
Вимірюваний ефект: частка відмов, запас ємності, час відновлення
Ефект від навантажувального тестування фіксуємо не за середнім завантаженням процесора, а за поведінкою контуру на межі.
Профіль навантаження піднімаємо сходинками з постійною частотою запитів: рівний потік на wrk2 показує, де починає зростати час відповіді, а не лише де закінчується пропускна здатність.
Кожну позицію знімаємо до та після змін на одному й тому самому профілі — інакше порівняння нічого не доводить.
- Частка відмов під навантаженням — помилки через перевищення часу очікування, відмови залежностей і відповіді з ознакою перевантаження рахуємо окремо. Клас «сервіс ліг повністю під піком» після налаштування обмежувачів і черг більше не відтворюється.
- Запас ємності контуру — відомо, на якій кратності до робочого трафіку починається зростання часу відповіді й де проходить аварійний поріг.
- Час відновлення сервісу — прогін на відмову: скільки займає повернення трафіку, які кроки робить чергова зміна і що перевіряє після.
- Передбачуване масштабування — точка додавання екземплярів прив’язана до конкретної метрики, а не до інтуїції чергового.
- Усунений клас відмов — фіксуємо, який саме збійний сценарій закрито і які перевірки не дадуть йому повернутися.
За кожним пунктом у звіті залишаються графіки до та після, пороги й умови прогону. На них чергова зміна спирається при наступному зростанні трафіку, а не на здогади.
Формати навантажувального тестування: режими, стенди, обмеження
Профіль навантаження задає не лише сценарій — частку читань і записів, тривалість піку, поведінку при відмовах, — а й те, де прогін узагалі допустимо запускати.
Формат вибирають за трьома осями: ізоляція від продуктивного контуру, достовірність замірів і ціна помилки, якщо тест зачепить живих користувачів. Нижче — варіанти, між якими реально вибирають, та обмеження кожного.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ізольований стенд | Перевірка гіпотез і регрес після змін у коді або конфігурації | Не відтворює мережеві затримки, поведінку балансувальника та профіль сусідніх сервісів |
| Репліка продуктивного контуру | Потрібні реалістичні заміри перед викаткою на бойовий | Розходиться з бойовим за обсягом даних і характером трафіку, потребує постійної підтримки |
| Прогін на продуктивному контурі | Разово, у вікно низького навантаження, для валідації ємності | Ризик для користувачів, немає повторюваності, замір змішується з реальним трафіком |
| Безперервний контроль навантаження | Фонові прогони малої інтенсивності, канареечні заміри після релізу | Слабкий сигнал на граничних режимах, потрібні еталонні значення й автоматичне порівняння |
У методу заміру є власні обмеження, про які варто пам’ятати під час читання звіту. Генератор навантаження сам споживає ресурси й на високих профілях стає вузьким місцем раніше, ніж досліджуваний сервіс: цифри падають, хоча система ще тримає.
Перші секунди прогону викривлені прогрівом кешів і пулів з’єднань, тому ділянку розгону в розрахунок не беруть, а середній час відповіді приховує хвіст розподілу — дивляться перцентилі.
Вибраний формат фіксуємо в регламенті: профіль, тривалість, прогрів, критерій придатності та стенд. Тоді результати порівнювані між прогонами й релізами, а зростання затримок видно до того, як його помітять користувачі.
Етапи робіт: від аудиту контуру до передавання регламентів
Навантажувальне тестування починається не із запуску генератора, а з інвентаризації контуру: де стоять балансувальники, які ліміти пулів з’єднань і таймаутів задано, як поводяться зовнішні залежності.
Без цієї карти прогін вимірює межу самого генератора або одного випадково вгаданого параметра, а не системи.
Далі робота йде етапами — кожен закриває окрему гіпотезу й залишає артефакт, який можна переперевірити.
- Аудит контуру. Знімаємо схему зв’язків, ліміти з’єднань, місця зберігання стану; відокремлюємо вузли для ізольованих замірів від тих, що перевіряються лише спільно.
- Сценарії навантаження. Узгоджуємо профілі: рівне навантаження, ступінчасте зростання до відмови, короткі піки. Фіксуємо цільову інтенсивність і допустиму затримку на p95 та p99.
- Підготовка тестових даних. Наповнюємо стенд зіставним обсягом записів і розподілом ключів — інакше кеш та індекси поводяться інакше, ніж на реальних даних.
- Складання стенда й калібрування генератора. Перевіряємо, що інструмент навантаження не впирається у власні ресурси, і додаємо прогрів перед замірами.
- Прогони й спостереження. Знімаємо метрики застосунку та хостів одночасно й міняємо по одній змінній — так вузьке місце визначається однозначно.
- Перевірка результату. Повторюємо профіль і звіряємо розкид між прогонами: відтворюваність важливіша за одиничне гарне значення.
- Передавання регламенту. Віддаємо сценарії, конфігурації, дашборди й порядок повторних перевірок після змін у контурі.
На виході в команди замовника залишається процедура, а не разовий звіт: перед кожною зміною контуру прогін повторюється за тими самими сценаріями, і регрес видно до виходу в робочий режим.
Що залишається у вас: конфігурації, схеми, політики, звіти
Після здавання проєкту контур залишається у вашому репозиторії та вашій інфраструктурі — ми не тримаємо його «в себе» й не прив’язуємо до своїх серверів.
Нижче те, чим розробники й чергова зміна користуються без нашої участі: від готових профілів навантаження до порогів, за якими прогін вважається проваленим.
- Набір конфігурацій навантаження — параметризовані сценарії під різний профіль трафіку: короткі сплески, довга полиця, ступінчасте зростання. Запуск однією командою, без ручного редагування скриптів під кожен прогін.
- Схема контуру й точок заміру — що і де вимірюється: генератори, балансувальник, застосунок, база, кеш. Відразу видно, на якій ланці втрачається час, а не лише підсумкове «стало повільніше».
- Порогові значення навантаження — інтенсивність, частка помилок і затримка на 95-му та 99-му процентилі, за яких прогін вважається проваленим, і за якими налаштовується автоматична зупинка.
- Політики доступу до тестових даних — обезличена копія бази, правила її оновлення й жорстка заборона на запис у продуктивний контур під час прогону.
- Інструкція для чергової зміни — порядок запуску, дозволені вікна, що дивитися при деградації, як перервати прогін і відкотити внесені зміни.
- Шаблон звіту за прогоном — графіки затримок, розподіл помилок, вузька ланка, порівняння з попередньою збіркою в однакових умовах.
- Регламент регресії — які сценарії обов’язкові перед викаткою і за якого результату реліз блокується автоматично.
Усе це описано так, щоб новий інженер у команді відтворив прогін за документацією, не ставлячи нам питань.
Кейс: як зняли деградацію під піковим навантаженням
Сервіс із добовою нерівномірністю трафіку: під вечірнім піком частка помилок сягала 6–7%, а час відповіді зростав у рази від робочого рівня.
Збої були непостійними — контур тримався на кеші та запасі за потужностями, тому чергова зміна дізнавалася про деградацію зі звернень до підтримки, а не з алертів.
Зібрали відтворюваний профіль навантаження на wrk2 — з постійною інтенсивністю замість «залпів», щоб повторні прогони були зіставні між собою.
Вузьке місце виявилося не в застосунку: під піком вибирався пул з’єднань до бази, а агресивні повтори запитів добивали її й перетворювали локальну затримку на каскадну відмову. Збільшили пул, обмежили повтори із затримкою, важкі фонові завдання винесли за межі пікового вікна.
| Метрика під піком | До робіт | Після |
|---|---|---|
| Частка помилок | 6–7% | до 0,2% |
| Час відповіді | зростання в 5–8 разів | у межах 1,5× від норми |
| Виявлення деградації | звернення до підтримки | алерт за затримкою й насиченням пулу |
| Повторюваність прогонів | розкид до 40% | у межах 10% |
Після усунення деградації прогнали навантаження ще тричі з кроком за інтенсивністю — картина відтворювалася, каскаду не виникало.
Пороги алертів прив’язали до затримки й заповнення пулу, тому черговий бачить проблему раніше за клієнтів, а сам профіль навантаження залишився в регресійному контурі й запускається перед великими викатками.
Що робити, якщо контур працює і його не можна валити
На живому контурі навантажувальний прогін не відрізняється від звичайного трафіку — питання лише в тому, хто першим помітить, що система на межі.
Тому перевірку будують навколо бюджету, вище якого деградація стає необоротною: зростають черги, час відповіді виходить за поріг, а зупинка займає хвилини замість секунд.
Ощадний режим прогону задається трьома обмежувачами: швидкість запитів, кількість одночасних з’єднань і загальна тривалість. Інтенсивність тримаємо постійною, без ступінчастого розгону — так видно, де саме починається деградація, а не де вона вже сталася.
Обов’язковий автоматичний стоп: щойно 95-й або 99-й процентиль часу відповіді перевищує поріг, навантаження знімається саме, до того як це помітять користувачі.
Частину прогонів доречніше проводити у вікно обслуговування — там знімається питання впливу на людей, можна підняти інтенсивність і перевірити поведінку при відмові вузлів.
На живому трафіку залишається мала частка: один вузол із групи, тимчасово виведений з балансування, або невелика частка запитів через окремий маршрут.
Перед цим контур проганяють на копії з тим самим профілем даних і тими самими лімітами, що в робочому середовищі. Генератор на кшталт wrk2 тримає рівний потік запитів і коректно міряє затримки під навантаженням — середні значення тут марні, важливий хвіст розподілу.
Межу системи знімають не одним великим прогоном, а серією коротких, із заздалегідь відомою точкою зупинки. Так перевірка залишається безпечним експериментом, а не інцидентом.
Технічні сумніви: ізоляція, дані, достовірність замірів
Перед стартом навантажувального тестування в команди замовника виникають одні й ті самі питання: де ганяти навантаження, звідки брати дані й чи можна вірити цифрам. Розбираємо їх заздалегідь — на старті це дешевше, ніж у звіті.
Як прогін ізолюється від продуктивного контуру?
Під тест розгортаємо окремий стенд — копію продуктивної топології з власною базою, кешем і чергами.
Генератор навантаження живе у своїй підмережі з квотами на ресурси, тому не забирає потужність у робочих сервісів, а трафік не йде через зовнішні балансувальники: користувачі не отримують ні зайвих з’єднань, ні відмов.
Звідки беруться тестові дані та персональні відомості?
Беремо обезличену вибірку: імена, адреси й контакти замінюємо синтетикою, але зберігаємо структуру та пропорції — обсяг таблиць, частку активних профілів, співвідношення читання й запису. Якщо вивантаження неможливе, генеруємо набір за узгодженим профілем. Персональні відомості не залишають контур замовника й не потрапляють у звіти.
Наскільки достовірні заміри й чи відтворюється результат?
До замірів прогріваємо систему й знімаємо фонові метрики, щоб відокремити навантаження від власної активності сервісів. У звіт потрапляє режим прогону: кількість з’єднань, профіль запитів, тривалість, склад стенда.
Повторний прогін у тих самих умовах дає розходження в межах кількох відсотків, інакше шукаємо причину, а не усереднюємо.
Що потрібно від вас для старту і як ми повернемося з оцінкою
Щоб план робіт був реалістичним, а не «середнім по галузі», потрібен мінімум вхідних даних. Збираємо їх на першій розмові — зазвичай 40–60 хвилин із вашим інженером або власником сервісу, після чого фіксуємо домовленості письмово й повертаємося з оцінкою та планом.
- Сценарій, критичний для бізнесу: які маршрути запитів і в якій пропорції дають реальний трафік, що вважаємо успішною відповіддю.
- Профіль навантаження: пікова й середня інтенсивність, кількість одночасних клієнтів, тривалість прогону та швидкість наростання.
- Цільові показники: допустимий час відповіді на високих перцентилях, частка помилок, за якої прогін вважається проваленим, поріг деградації для зупинки.
- Тестовий контур, зіставний із робочим: адреси, облікові дані, обмеження на зовнішні сервіси та способи їх підміни.
- Обмеження й вікна: коли навантаження можна подавати, з ким узгоджуємо, хто з боку експлуатації може натиснути «стоп».
- Точка контакту: відповідальний з вашого боку й канал, де оперативно вирішуємо питання під час прогонів.
Далі порядок такий: розбираємо дані, повертаємося з планом робіт — сценарії, вибір генератора навантаження (для рівної інтенсивності й точних перцентилів беремо wrk2, для коротких сплесків — wrk), метрики, ролі та вікна прогонів. План узгоджуємо з вашими інженерами й лише після цього починаємо.
