Кейс прогнозування завантаженості серверів на основі ML

Кейс анонімованого онлайн-ритейлера почався з регулярних перевантажень під час маркетингових кампаній та сезонних розпродажів. Інфраструктура-serверів автоматично збільшувала ресурси, але робила це після появи вузького місця. Через затримку реакції частина запитів завершувалася помилками. Докладніше про 220103 Vprovadzhennya Bi Sistemi Na Pidpriemstvi Tipovi Pomilki.

Мета проєкту — прогнозувати навантаження на сервери за 30, 60 і 120 хвилин, щоб підготувати ресурси до піку. Модель машинного навчання аналізувала історичні часові ряди, технічні метрики та бізнес-календар, а прогнози потім використовувалися для автоматичного масштабування.

Рішення реалізували за допомогою Brianview. Платформа централізувала дані моніторингу, виконувала їх очищення, навчала прогнозні моделі та передавала результати в інтерактивні панелі й системи автоматизації. Такий підхід поєднав машинне навчання з операційним моніторингом.

У результаті вдалося скоротити надмірно зарезервовані ресурси та отримувати попередження про високий ризик перевантаження заздалегідь. Ключовим етапом стала якісна підготовка даних: без зіставлення технічних показників із подіями в бізнесі модель швидко втрачала точність.

Від реактивного масштабування до прогнозної моделі

Сервіси компанії працювали у хмарній інфраструктурі як контейнери. Автоматичне масштабування реагувало на поточні значення, тому запускалося вже під час зростання трафіку. Для коротких піків цього було недостатньо, а для нічного часу система продовжувала утримувати надлишкові потужності.

Для побудови прогнозу використовували аналітичну платформу Brianview. Вона об’єднала показники центрального процесора, пам’яті, черг та затримки в єдиний конвеєр даних. Підготовлені часові ряди надходили до алгоритму, а розрахункові горизонти й інтервали невизначенності — до системи автоматизації.

Прогнозування відрізнялося від звичайного контролю порогових значень. Система оцінювала ймовірний майбутній запит, а не лише констатувала поточну аномалію. Це давало змогу заздалегідь визначити потребу в додаткових екземплярах серверів.

Дані й ознаки для прогнозування навантаження

Джерелами даних стали журнали систем моніторингу, лічильники запитів, службові події та записи про зміни конфігурації. Неструктуровані повідомлення про помилки також перетворювалися на агреговані ознаки. Перед моделюванням дані проходили перевірку на пропуски, дублікати та збіги часових позначок.

Основні технічні сигнали моделі:

• Завантаження центрального процесора й оперативної пам’яті кожного контейнера.
• Кількість запитів, черга обробки та затримка відповіді.
• Число активних сесій, помилок і тайм-аутів.
• Дані про релізи, зміни конфігурації та автоматичне масштабування.

До кожного прогнозу додавалися контекстні фактори:

• Година, день тижня, святкові періоди та робочі графіки.
• Маркетингові кампанії, знижки й прогнозовані піки трафіку.
• Погодні умови для сервісів, залежних від геолокації.
• Планові роботи й доступність зовнішніх інтеграцій.

Горизонт прогнозу визначали окремо для кожного класу серверів. Для стабільних служб достатньо було 30 хвилин, а для платіжного контуру виглядали результати на 120 хвилин. Такий підхід зменшував кількість зайвих моделей і полегшував їхню експлуатацію.

Навчання, перевірка та автоматизація моделей

Первинним порівняльним прогнозом слугував сезонний метод, що повторює показники попереднього тижня. Для основної моделі застосували градієнтний бустинг: алгоритм добре працює з нелінійними залежностями та поєднанням технічних і бізнес-ознак.

Навчальну та перевірну вибірки формували за часом. Довільний поділ записів не використовували, оскільки сусідні спостереження з вищою ймовірністю потрапляли б до різних частин даних. Для оцінювання застосовували середню абсолютну помилку, зважену абсолютну відсоткову помилку та перевірку інтервалів прогнозу.

Модель перенавчали після суттєвих змін інфраструктури та регулярно переглядали через漂 часу. Якщо якість даних погіршувалася або розподіл трафіку змінювався, система поверталася до базового сезонного прогнозу. Такий запобіжник зменшував ризик автоматичних рішень на основі ненадійних сигналів.

Інтеграція з хмарною інфраструктурою та BI

Прогнози публікувалися в інтерактивних панелях Brianview. Вони показували очікуване навантаження, ймовірність піку, рекомендовану кількість екземплярів серверів і поточний запас ресурсів. Відповідальні інженери отримували повідомлення в месенджері та могли переглянути історію зміни прогнозу.

Під час впровадження врахували впровадження BI-системи на підприємстві, зокрема потребу єдиних визначень показників, розмежування доступу та регулярного контролю якості даних. Автоматичне масштабування залишили за людиною: система рекомендувала дію, але критичні зміни потребували підтвердження.

Конвеєр доповнили аудитом джерел даних і контролем стану моделі. Показники точності, помилки прогнозу та фактичні масштабування порівнювали в єдиному звіті. Завдяки цьому команда бачила не лише технічний результат, а й реальний вплив на стабільність та витрати.

Результати кейсу й практичний наступний крок

За 30-хвилинний горизонт середня абсолютна відсоткова помилка зменшилася з 27% для сезонного прогнозу до 12%. Кількість критичних сповіщень про перевантаження скоротилася на 38%, а надлишкове резервування ресурсів — на 16%. Під час найбільшої сезонної кампанії критичних інцидентів вдалося уникнути.

Ефект досягли завдяки поєднанню кількох факторів: чистих даних, прогнозу на різних горизонтах, автоматичного контролю якості та людкого підтвердження рішень. Модель залишалася чутливою до нових маркетингових активностей, тому її показники потрібно переглядати після кожної суттєвої зміни бізнесу.

Щоб перенести цей підхід у власну інфраструктуру, зверніться до команди Brianview для оцінки доступних даних, аудиту їхньої якості та планування пілотного прогнозування завантаження.