Чому capacity planning ламається на реальному навантаженні
Запас ємності рідко витрачається рівномірно. У кластері частина вузлів тримає високу частку запитів за процесором і пам'яттю, а частина простоює через жорсткі правила розміщення й антиафінність: заявки резервуються під сервіс цілком, хоча фактичне споживання в рази нижче.
Тому capacity planning за середніми цифрами показує «половина вільна», а перевантаження кластера настає на конкретній групі вузлів.
Додайте сюди затримку горизонтального масштабування — від моменту зростання метрики до готовності нової репліки минають хвилини, і весь цей час пікове навантаження обробляється тим самим складом.
Пік майже ніколи не зростає рівномірно за всіма метриками. Першою впирається одна ланка: пул з'єднань до бази, ліміт одночасних запитів на боці зовнішнього сервісу, запис на диск або черга обробки.
Далі вмикається каскад — повтори запитів, збільшені таймаути, заповнені буфери, — і відмова через нестачу ємності виглядає як відмова всього контуру, хоча вичерпано рівно один ресурс.
Знайти його заздалегідь можна лише за профілем споживання кожного сервісу окремо, а не за зведеним графіком. У Kubernetes такі речі видно через ліміти й заявки за об'єктами, але інтерпретувати їх потрібно разом із реальним трафіком.
Ручні прикидки відстають із двох причин. Вони спираються на усереднені значення за минулий період і не помічають зміну профілю: новий клієнтський сценарій, пакетне вивантаження, сезонний сплеск.
І друге — ємність розширюють уже після деградації, в авральному режимі, без запасу на наступний пік.
Тому розбір починаємо з вимірювань: збираємо профіль за сервісами, знаходимо вузьке місце інфраструктури й рахуємо, який резерв потрібен на пікових сценаріях. Далі — як це закривається.
Що дає capacity planning на основі метрик навантаження
Capacity planning без метрик — це ставка на пік: запас за потужністю беруть «на око», і в одному з двох сценаріїв він або простоює, або закінчується в найнезручніший момент.
Небезпечне не зростання навантаження як таке, а відмова класу «не вистачило ресурсу»: черга переповнюється, час відповіді зростає ступенем, і споживачі отримують помилки замість передбачуваного уповільнення.
Основа — регулярне знімання навантаження: запити за секунду за типами операцій, глибина черг, насичення процесорів і диска, утилізація з'єднань до баз, час відповіді на 95-му й 99-му перцентилях, приріст сховища.
Ряди складаємо в Prometheus із тривалим терміном зберігання — так видно тижні й сезони, а не останню годину. З історії виводяться два числа, яких зазвичай бракує: точка насичення за кожною метрикою і швидкість наближення до неї.
Запас за потужністю рахуємо від точки насичення, а не від середнього споживання: наприклад, третина до порога, за яким час відповіді зростає нелінійно, і горизонт прогнозу на два-три місяці вперед.
Модель зростання будується на історичних вікнах з урахуванням добової та тижневої сезонності — прогноз зростання навантаження дає конкретну дату виходу на поріг замість абстрактного «скоро стане тісно». Розширення плануємо заздалегідь, із часом на закупівлю й перевірку на тестовому контурі.
Другий ефект — передбачувана деградація. Коли ліміти й квоти виставлені за виміряними порогами, перевантаження виглядає як зростання затримок у неприоритетних операцій, а не як відмова всього сервісу: критичні запити проходять, фонові звіти й перерахунки пригальмовуються першими.
Зниження простою й планування ресурсів ідуть не від того, що навантаження перестало зростати, а від того, що точка відмови відома заздалегідь.
Підходи до планування ємності: порівняння режимів
Вибір режиму планування ємності (capacity planning) — це компроміс між точністю прогнозу й вартістю помилки.
Ручний розрахунок спирається на пікові значення минулих періодів і закладений запас, прогноз за метриками — на динаміку навантаження за кілька тижнів, автоматичне масштабування реагує на поточний стан без участі людини. Нижче — де кожен режим працює передбачувано, а де починає заважати.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручний розрахунок ємності | Стабільний профіль навантаження, рідкісні релізи, зрозумілий сезонний пік | Реагує на зростання із затримкою; запас закладається приблизно — або простоює, або не вистачає при стрибку |
| Прогноз за історичними метриками | Накопичено ряди за кількістю запитів, часом відповіді та утилізацією ресурсів | Точність падає на нових сценаріях і аномаліях; модель потрібно регулярно переперевіряти |
| Автоматичне масштабування | Різкі, але однотипні за формою піки; сервіси без стану | Є затримка реакції на сплеск; при грубих порогах іде в гойдалки та зайві перемикання |
| Гібридна схема | Базовий рівень тримають статично, верхню межу закриває автоматика | Складніше налаштовувати й супроводжувати; потрібні спостережуваність і обґрунтовані пороги |
Чисті режими на практиці майже не трапляються: базу фіксують за історичними метриками, а верхню межу віддають автоматиці під прогноз навантаження.
Що підійде в конкретному випадку, залежить від профілю трафіку та допустимого часу деградації — тому порівняння починаємо із замірів і розбору інцидентів, а не з вибору інструмента.
Як ми впроваджуємо планування ємності: етапи робіт
Планування ємності починається не із закупівлі заліза, а з інвентаризації того, що система вже розповідає про себе. При формально налаштованому зборі метрик прогноз спирається на шум: середні приховують деградацію, а фонові завдання маскуються під піки. Тому починаємо з достовірності даних і лише потім переходимо до розрахунків.
- Аудит метрик. Звіряємо, які лічильники збираються, з якою частотою й глибиною зберігання, де розриви між сервісами. Мітки з неконтрольованою кардинальністю в розрахунок не беремо.
- Профіль навантаження. Розкладаємо трафік на добові й тижневі цикли, відокремлюємо користувацькі піки від фонових завдань — переіндексації, резервного копіювання, важких звітів. Інакше запас рахують під навантаження, що не стосується піку.
- Перевірка гіпотез. Зіставляємо піки з історією деградацій і залишаємо метрики, які справді передбачають проблему. Непідтверджені гіпотези з моделі прибираємо.
- Порогові значення. Рахуємо за перцентилями, а не за середніми, окремо для читання й запису, із запасом на втрату вузла або зони. Кожен поріг прив'язаний до дії: розширити, обмежити, вимкнути другорядне.
- Прогін на живому профілі. Звіряємо прогноз із фактом на історичному відрізку, потім повторюємо піковий сценарій на стенді. Розходження вище допуску відправляє модель на перерахунок.
- Вбудовування й передача. Пороги перетворюємо на оповіщення та правила автомасштабування, фіксуємо власника метрики й тригери перегляду. Віддаємо регламент — команда веде планування сама.
Що передаємо на руки: артефакти й робочі регламенти
Проєкт закінчується не звітом, а станом, у якому ваша команда змінює ємність без нас. Тому в передачу входить не лише конфігурація, а й правила, за якими вона живе: що робити при зростанні навантаження, хто переглядає пороги, куди дивитися в першу хвилину збою. Нижче — комплект, який залишається в замовника.
- Модель ємності — профілі навантаження за сервісами, виявлені вузькі місця, запас за кожним ресурсом і точка, після якої масштабування обов'язкове.
- Схеми інфраструктури — топологія сервісів, потоки трафіку, межі відмовостійкості та місця розділення зон.
- Налаштування оповіщень — правила з порогами за затримкою, насиченням і часткою помилок, із розділенням на «підняти чергового вночі» і «розібрати вранці».
- Регламент перегляду ємності — періодичність, власник цифр, метрики, які запускають перегляд, і форма фіксації рішення.
- Документація з інфраструктури — опис сервісів, параметрів конфігурації та типових операцій, достатній, щоб новий інженер розібрався без переказів.
- Інструкції для чергової зміни — сценарії на типові відмови: що перевірити, що перезапустити, коли ескалувати.
- Передача знань команді — спільні розбори, записи зустрічей, видані доступи й перевірка на реальних завданнях, а не на словах.
Через два-три тижні після передачі проводимо контрольний розбір: які оповіщення спрацювали вхолосту, які пороги виявилися низькими, що в інструкціях не збіглося з реальністю — і правимо це разом із вашими інженерами.
Кейс: прибрали перевантаження кластера й простій сервісів
До: деградація в години пік
Сервіс жив у Kubernetes-кластері, а ліміти й число реплік виставляли на око при першому запуску. У вечірні години пік і під час розсилок утилізація вузлів сягала 95%, черга запитів зростала швидше, ніж спрацьовувало автомасштабування, і шлюз починав віддавати помилки. За квартал — чотири інциденти по 40–90 хвилин і один позаплановий простій на кілька годин.
Після: метрики й керований запас
Зібрали історію метрик за кілька місяців: запити за секунду, час відповіді за перцентилями, утилізація процесорів і пам'яті, глибина черг.
За нею побудували прогноз з урахуванням добового профілю й сезонних сплесків, а від прогнозу — пороги розширення та правила випереджального додавання реплік.
Запас зробили керованим: під прогнозний пік резервується фіксована частка ємності, сезонне розширення запускається планово, до приходу навантаження, а навантажувальні прогони перевіряють, що нову стелю витримано.
Простою через ємність не було жодного разу, інциденти в години пік припинилися, завантаження вузлів у пік тримається нижче порога деградації. Розширення перестало бути аварійною роботою — це планова процедура з відомим строком.
Чим планування за метриками відрізняється від розрахунку за піками?
Розрахунок за піковим навантаженням виходить з однієї точки: беруть максимальний зафіксований сплеск, множать на коефіцієнт запасу й отримують конфігурацію на весь період. Логіка працює, поки пік залишається репрезентативним.
На практиці це часто аномалія — разова розсилка, шторм повторів, сканування — і вона заморожує ресурси, які решту часу простоюють.
Планування за метриками (capacity planning) починається з розподілу запитів: як навантаження змінюється за годинами, днями тижня й сезоном, де середня, де перцентилі, наскільки довгі та часті сплески.
Модель відповідає не на питання «що якщо станеться найгірше», а на питання «яку частку часу ми тримаємо цільовий час відгуку за такого профілю». Середнє навантаження задає базовий розмір, розкид — величину запасу, частота піків — потрібну швидкість реакції.
Далі розподіл рахують за компонентами. Вузьке місце зазвичай одне — база, черга, зовнішній сервіс — і воно впирається в межу раніше за інших.
Тому коефіцієнт запасу задають окремо для кожного елемента, з його розкиду й часу виходу на потужність: при автоматичному масштабуванні за хвилини запас потрібен невеликий, при ручному додаванні за години — помітно вищий.
Звідси різні рішення. Піковий розрахунок відповідає «чи витримаємо найгірший день» і майже завжди дає надлишкову конфігурацію, яку потім ніхто не переглядає.
Планування за метриками відповідає, скільки ресурсів потрібно під очікуваний профіль і в який момент пора масштабуватися, — тому надлишку менше, а рішення спирається на дані.
Технічні сумніви щодо планування ємності
Планування ємності спирається на виміряні дані, а не на здогадки: прогноз будується за історичними рядами навантаження із запасом на сезонність і піки. Звідси й основні сумніви — наскільки прогнозу можна вірити і де взяти метрики, якщо їх поки мало.
Наскільки точним виходить прогноз?
Рахуємо інтервальну оцінку, а не одне число: базою йде 95-й перцентиль, тому рідкісні піки не усереднюються й не губляться.
Перші тижні модель калібрується за фактом, далі розходження за піковим навантаженням тримається в межах 10–15%, а прогноз на квартал вперед перераховується за ковзним вікном.
У нас майже немає метрик — з чого почати?
Вистачає базового набору: завантаження обчислювальних ресурсів, споживання пам'яті, час відповіді, глибина черги запитів, число одночасних з'єднань. Цього достатньо, щоб побачити вузьке місце й оцінити запас. Якщо телеметрії немає зовсім, робота починається зі збору — модель на порожніх даних безглузда.
Чи сумісно це з нашим моніторингом?
Наявну систему збору не замінюємо, а підключаємося до неї як споживач метрик у стандартних форматах. Дашборди й правила оповіщення залишаються у звичному контурі, доступи видаються за поточною рольовою моделлю — дублювати агенти не потрібно.
Скільки займає впровадження?
Перший прогноз за ключовими сервісами — через два-три тижні після доступу до метрик. Повний контур з автоматичним перерахунком і порогом оповіщення про наближення до межі — зазвичай півтора-два місяці. Поріг спрацьовує раніше за деградацію, тому запас на перевантаження залишається.
Обговоримо вашу задачу й повернемося з оцінкою та планом
Щоб розбір ішов за фактами, а не за здогадками, надішліть вихідні дані щодо навантаження. Достатньо вивантаження метрик за кілька тижнів, схеми сервісів і опису пікових вікон — цього вистачає, щоб побачити, де запас вичерпано і який вузол упреться в стелю першим.
- метрики навантаження в динаміці: запити за секунду, перцентилі затримок, споживання процесора й пам'яті за кожним сервісом;
- опис пікових вікон — акції, релізи, сезонні сплески — з датами й тривалістю;
- схему сервісів і залежностей: черги, зовнішні виклики, спільні бази й кеші;
- цільові показники: який відгук вважаєте нормальним і яку частку відмов допускаєте на піку;
- історію інцидентів: що падало, з якої причини, скільки зайняло відновлення;
- плани зростання: очікуваний приріст трафіку й строки, до яких потрібно бути готовими;
- доступи лише на читання до метрик і конфігурацій, якщо готові дати їх на етапі розбору.
Далі ми збираємо модель навантаження, знаходимо вузькі місця й рахуємо запас до межі.
До плану робіт входять точки відмови, цільові значення за кожним сервісом, черговість змін і перевірка на контрольованому піку в робочому контурі — так capacity planning підтверджується вимірюваннями до реального напливу.
Опишіть задачу — повернемося з оцінкою та планом, назвемо склад робіт і порядок запуску проєкту.
