Right-sizing віртуальних машин: де простоюють ресурси
Майже на будь-якій інфраструктурі, старшій за рік, видно ту саму картину: профілі ресурсів виставлялися «із запасом на зростання» і відтоді не переглядалися.
Пікові запити закривали додаванням ядер і пам'яті, а назад їх уже ніхто не знімав — так і з'являються простоюючі ресурси, зарезервовані під сценарій, який не настав.
Друга причина — перекіс профілю навантаження. Шаблон віртуальної машини один, а ролі за ним різні: сервіс, який тримає стан у пам'яті, і сервіс, який обчислює, отримують однаковий набір.
У підсумку одна машина вибирає виділену пам'ять і майже не торкається обчислень, сусідня впирається в стелю, а середня утилізація за обома вузлами виглядає цілком нормальною.
Ціна перекосу подвійна. Спершу ми платимо за зарезервований обсяг, а не за спожитий: у простоюючих машин утилізація тримається в районі кількох відсотків, і це не разова переплата, а постійна.
Потім приходить нестача ресурсів у піку — там, де профіль не збігається з реальним характером навантаження, машина деградує: зростають черги запитів і час відповіді, а на піковій хвилі з'являються відмови. Реакція на відмову зазвичай одна — додати ще, і перекіс закріплюється вже назавжди.
Right-sizing віртуальних машин починається не зі зменшення розмірів, а зі зняття фактичного профілю: як машина споживає пам'ять, обчислення й дискові операції протягом доби та тижня, де в неї піки, а де рівна полиця. Далі розбираємо, як це закривається без ризику для пікових сценаріїв.
Що дає вирівнювання профілю навантаження і ресурсів
Профіль навантаження знімаємо за вікно, яке захоплює і пік, і спад: утилізація пам'яті та процесора, глибина черг, кількість відмов через нестачу ресурсу.
Дивимося не середнє, а розподіл — за ним одразу видно, що машину підібрано під рідкісний сплеск, а основну частину часу вона простоює. Prometheus віддає ці ряди у придатному для розбору вигляді, тому right-sizing віртуальних машин тут будується на фактах, а не на відчуттях.
Після вирівнювання зникає цілий клас відмов: аварії через нестачу пам'яті в піку, деградація відгуку під навантаженням, падіння під час паралельної обробки черги. Пік більше не впирається в стелю виділеного ресурсу — стелю підібрано саме за ним, а не за даними минулого сезону.
Обсяг ресурсів, який тримали про запас, скорочується: частина машин зменшується, частина переїжджає на інший клас. Резерв при цьому не зникає — він переїжджає в правила автомасштабування, які додають потужність за пороговим значенням і знімають її, коли навантаження спадає.
Простій і час відновлення падають з двох причин: типові аварії через ресурси просто не настають, а якщо відмова все-таки сталася, черговий бачить зрозумілу картину — який параметр уперся в межу і що з ним робити. Відновлення з шаблону займає хвилини замість десятків хвилин ручної діагностики.
Варіанти приведення профілю віртуальних машин до норми
Звести профіль до фактичного навантаження можна різними способами, і вони не взаємозамінні: у кожного своя ціна помилки й горизонт реакції.
Спершу фіксуємо межі — зниження ресурсів обмежене піковими вікнами, запасом на сплески, накладними витратами гостьової системи та мінімальним профілем, який виробник прикладного ПЗ зазначає в документації.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручний перегляд профілю за метриками | Стабільне навантаження, парк до десятків машин, рідкісні зміни | Потрібен розбір історії за повний цикл; результат застаріває між ревізіями й залежить від того, хто дивиться |
| Автоматичні рекомендації за телеметрією | Великий різнорідний парк, немає ресурсів на постійний ручний аналіз | Радить, але не діє; якість залежить від глибини історії та наявності агента всередині гостьової системи |
| Гнучке масштабування за правилами | Змінне навантаження з передбачуваними добовими й тижневими піками | Не рятує від повільного зростання споживання пам'яті; вимагає коректного виведення вузла з обслуговування |
На практиці підходи комбінують: рекомендації дають кандидатів на зниження, ручна ревізія їх підтверджує, гнучке масштабування закриває піки.
Ключове правило — знижувати ступенями, не більше однієї градації за раз, з вікном спостереження не коротшим за повний бізнес-цикл і збереженою можливістю повернути попередній профіль.
Порядок робіт: від збору метрик до передачі регламенту
Порядок робіт будується так, щоб кожна зміна спиралася на виміряний профіль, а не на відчуття «цій машині явно забагато ресурсів». Етапи впровадження йдуть послідовно: спочатку дані, потім рішення, далі перевірка — і тільки після цього передача регламенту.
- Інвентаризація парку. Зводимо машини, їхнє призначення, власників і теги в один реєстр. Одразу позначаємо дублі та середовища, де навантаження фактично відсутнє.
- Зняття профілю навантаження. Накопичуємо метрики 2–4 тижні: медіана, пікові перцентилі, добові й місячні сплески, споживання пам'яті, дисковий обмін. Фіксуємо, що саме впирається в стелю.
- Схема цільових конфігурацій. Таблиця «поточна → цільова» із запасом під пік і обґрунтуванням за кожним класом. Узгоджуємо з власниками сервісів, а не змінюємо мовчки.
- Зміни. Ідемо групами: спочатку непродуктивні середовища, потім продуктивні — з вікном обслуговування, точкою відкату й критерієм зупинки.
- Перевірка під навантаженням. Синтетичний тест плюс спостереження за реальним трафіком після перемикання. Новий профіль порівнюємо зі знятим: якщо пік знову впирається в стелю, конфігурацію коригуємо.
- Передача регламенту. Віддаємо документ: як читати метрики, з якою періодичністю переглядати конфігурації, за якими правилами заводяться нові машини.
На виході залишається не разова кампанія з економії, а робоче правило: парк переглядається за метриками, тому конфігурації не «розпливаються» назад за кілька місяців.
Регламенти, схеми та політики: що передаємо команді
Інженерна робота закінчується не звітом, а комплектом, за яким команда далі діє самостійно. Нижче — що залишається у вас після перегляду профілів: від карти парку до порядку повернення, якщо новий розмір виявився тісним.
- Карта парку — за кожною машиною група, роль, поточний профіль, фактична утилізація за вікно спостереження та запас до стелі.
- Профілі ресурсів за групами — типові набори під веб-шар, черги повідомлень, бази та складальні вузли, з обґрунтуванням обраного запасу.
- Схеми оточень — що де розміщено, як середовища пов'язані між собою і де проходять межі відмовостійкості.
- Політики перегляду — з якою періодичністю і за якими тригерами профіль перевіряється: зростання навантаження, великий реліз, сезонний пік.
- Порядок повернення — як відкотити попередній розмір, що перевірити після і хто підтверджує рішення.
- Регламент змін — хто погоджує нове значення, як фіксується причина і де зберігається історія рішень.
- Документація чергування — паспорти машин, пороги оповіщень, короткі інструкції на випадок деградації.
Комплект передаємо у вашому форматі: у репозиторії, базі знань або внутрішньому порталі. Він оновлюється разом з інфраструктурою, тому новий інженер входить у контур за документом, а не за розповідями колег.
Кейс: перегляд профілів у кластері з піковим навантаженням
Кластер під високонавантаженим сервісом жив із профілями, підібраними на око: кожному сервісу видавали запас пам'яті та процесорів під найгірший сценарій.
За фактом утилізація трималася на 10–15%, а надлишкові резерви займали більше половини виділеного обсягу — при цьому в пікові години частина сервісів усе одно впиралася в ліміти й додавала затримку. Частка недоступності за квартал сягала 0,4%, і майже всі ці хвилини припадали на пік.
Що змінили і що отримали
Спочатку зняли профіль споживання за повний цикл — робочий тиждень і пікові дні, за медіаною та верхніми перцентилями процесорів, пам'яті й дискових операцій.
Потім розділили сервіси на три класи: рівна база, пікові з верхньою межею та вертикальним автомасштабуванням, і окремий пул під пакетні задачі, які прибрали із загального контуру в нічне вікно.
Запити й ліміти розвели, щоб планувальник Kubernetes розкладав поди за фактичною потребою, а не за максимальним апетитом. Зміни перевіряли навантажувальним прогоном за трафіком найважчого дня — до викочування в бій.
Після перегляду надлишкові резерви стиснулися з 60% до 15% від виділеного обсягу, середня утилізація зросла до 40–45%, а метрики піку не просіли. 95-й перцентиль часу відгуку в години максимуму навіть знизився: сервіси перестали конкурувати за пам'ять.
Частка недоступності наступного кварталу впала до 0,05%, інциденти з нестачею пам'яті припинилися. Відкат залишався дешевим: старі профілі зберегли як конфігурацію попереднього релізу, повернення займало хвилини.
Що робити, якщо застосунок уже розгорнуто під навантаження
Right-sizing на працюючій системі робиться частинами. Ми не чіпаємо весь контур одразу: вибираємо один компонент, переводимо його на новий профіль, кілька діб спостерігаємо і тільки потім беремося за наступний.
Тоді помилка в розрахунку коштує не простою, а одного перезавантаження екземпляра, виведеного з балансування.
Цільовий профіль рахуємо за метриками споживання за тривалий період, а не за разовим заміром. Враховуємо добові й тижневі піки та окремо — рідкісні сплески: закриття звітного періоду, нічні перерахунки, сезонні кампанії.
Профіль підбирається під пік із запасом, а не під середнє: саме середнє й обертається нестачею пам'яті в найнезручніший момент.
Головний ризик — не сам перегляд, а втрата запасу. Машина, у якої пам'яті було вдвічі більше за потрібне, не видає цього, поки не з'явиться новий потік даних. Вузьким місцем може стати й ввід-вивід: урізали процесор, а вперлися в дискові операції.
Тому перед кожною зміною фіксуємо контрольну точку: знімок диска, попередній профіль, набір метрик «до». Далі вікно спостереження — якщо відгук або довжина черги виходять за коридор, повертаємо попередній розмір. Відкат займає хвилини й не потребує перезбирання оточення.
Порядок обходу — від менш критичних сервісів до ядра. Починаємо з компонентів, у яких є дублювальний екземпляр, і тільки переконавшись у стійкості, чіпаємо те, що тримає основне навантаження.
Технічні заперечення: ризики зниження ресурсів та їхнє зняття
Заперечення на розборах зазвичай ті самі: зріжемо ресурси — продуктивне середовище впаде в пік.
Знімаються вони не обіцянками, а даними: розрахунок спирається на тривалі метрики споживання — завантаження процесора, пам'ять, дискові операції, мережу — з урахуванням добових і тижневих піків, а не на середні значення.
Другий контур безпеки — оборотність і межі. Зміна застосовується до однієї машини або невеликої групи, вікно спостереження фіксоване, відкат — повернення до попереднього профілю з шаблону, а не ручна правка на живій системі.
Як переконатися, що зниження ресурсів безпечне?
Дивимося верхні значення та тривалість утримання навантаження, а не середнє. Якщо споживання підскакує короткочасно, запас зберігаємо: знижуємо простоююче, а не те, що працює на межі.
Що буде, якщо навантаження зросте після зміни?
На групі залишаються правила автомасштабування та поріг, за якого додається ресурс. Перевищення порогу дає оповіщення черговому — зростання навантаження не залишається непоміченим.
Як часто переглядати конфігурації?
Планово — раз на квартал, плюс позапланово після великого релізу, зміни архітектури або помітного зсуву в профілі запитів. Розклад перегляду фіксуємо, щоб профілі не застарівали мовчки.
Де закінчується автоматизація?
Автоматично застосовуємо лише зміни, що пройшли перевірку за метриками і мають готовий відкат. Для критичних вузлів і баз даних рішення погоджуємо з власником сервісу — там ціна помилки вища за вигоду від зниження.
Обговоримо задачу: зберемо профіль і повернемося з планом
Щоб right-sizing не залишився разовим зрізом, стартуємо з інвентаризації.
Від вас потрібен мінімум: вивантаження споживання за кожною машиною за повний цикл навантаження, а не за спокійний тиждень; перелік сервісів із позначкою, що критично, а що терпить перезапуск; вікна, у які зміни допустимі; контакт інженера, який підтверджує правки за своєю групою машин.
Якщо доступ до системи моніторингу або гіпервізора є — вивантаження зберемо самі, готувати їх заздалегідь не потрібно.
Перший крок за нами: зіставляємо пікове та медіанне завантаження, відсікаємо разові сплески й залишаємо ті, що повторюються, позначаємо машини із запасом під сезонність і рахуємо цільовий розмір. Далі повертаємося з оцінкою та планом робіт:
- таблиця за кожною машиною: поточний розмір, фактичне споживання, цільовий розмір і чим він обґрунтований;
- список машин, які чіпати не варто, із зазначенням причини — там запас тримає стійкість продакшену;
- порядок змін групами, з вікнами й точками відкату на попередній розмір;
- прогноз ефекту: скільки ресурсів вивільняється і наскільки скорочується розкид завантаження між піком і простоєм;
- терміни перегляду парку — з якою періодичністю повертаємося до профілю і які події запускають позаплановий прохід: зростання навантаження, зміна релізу, сезонний пік;
- розподіл ролей: що підтверджує ваша сторона і де ми діємо самі.
Опишіть задачу у двох-трьох абзацах — за цими даними повернемося з оцінкою, планом робіт і порядком впровадження.
