Committed Use Discounts у GCP: чому знижка не застосовується
Рівномірне цілодобове навантаження, зобов'язання оформлені, а в деталізації рахунку немає рядка зі знижкою за довгострокове зобов'язання.
Committed Use Discounts у GCP не розподіляються по інфраструктурі автоматично: знижка прив'язана до проєкту, регіону, сімейства машин і типу ресурсу окремо. Збігаються всі параметри з фактичним споживанням — знижка застосовується, розійшовся хоч один — вона не знаходить об'єкт.
Розбіжність зазвичай виглядає нешкідливо. Зобов'язання оформили на один проєкт, а робочі навантаження живуть у двох-трьох — після розділення інфраструктури частина переїхала в окремий проєкт. Або регіон у зобов'язанні один, а інстанси роз'їхалися по зонах і сусідньому регіону. Або сімейство машин змінили під час оновлення, а зобов'язання залишилося на попередній ряд.
Тому перше, що ми робимо, — знімаємо профіль споживання за 30–60 днів у розрізі проєктів, регіонів і рядів машин. Він показує, де навантаження справді рівномірне і скільки його тримається вночі та у вихідні.
Резервування ресурсів за піковими значеннями — друга часта помилка: оплачена ємність простоює половину часу, і вигода нівелюється.
Окремо перевіряємо, чи не перекривають зобов'язання одне одного і чи не конфліктують вони з автоматичним масштабуванням: те, що піднімається за розкладом, у довгострокове зобов'язання брати невигідно.
Далі розбираємо, як це закривається: як зіставити зобов'язання з реальним споживанням, який профіль споживання вважати рівномірним і що варто тримати на вимогу, а не в зобов'язанні.
Що дає керована модель резервування ресурсів
Зобов'язання з резервування — не знижка, а фіксація базової частини навантаження на довгий строк: ви заздалегідь оголошуєте, скільки ресурсів тримаєте постійно, і платите за них за зниженим тарифом. Усе, що вище бази — піки, експерименти, сезонні сплески — залишається на вимогу.
Такий контур налаштовується в Google Cloud і перетворює хмарний рахунок з лотереї на керований показник.
Далі — чек-ліст, за яким ми перевіряємо, що модель справді працює, а не просто увімкнена:
- Частка покриття зобов'язаннями вирівнюється. Тримаємо 60–75% стабільної бази під зобов'язанням, решту — на вимогу: при перекосі понад 85% будь-який спад навантаження перетворюється на переплату.
- Витрати на інфраструктуру перестають зростати. Рахунок стає функцією від кількості сервісів, а не від випадкових піків — відхилення місяць до місяця тримається в одиницях відсотків.
- Передбачуване навантаження відокремлене від пікового. Бази, кеш, черги та фонові завдання переходять під зобов'язання, разові прогони залишаються гнучкими.
- Зникає клас відмов через нестачу квот у пік. Резерв прив'язаний до сімейства машин і регіону, і нова машина в момент зростання піднімається без очікування виділення ресурсів.
- Вартість володіння рахується на горизонті. Ефект резервування видно не в першому рахунку, а на кварталі: порівнюємо «зобов'язання плюс на вимогу» проти чистого споживання.
Кожен пункт звіряємо з реальним профілем навантаження за кілька місяців — інакше зобов'язання або недовантажене, або заважає зростати.
Режими резервування: порівняння варіантів і обмежень
Режим резервування визначає не лише розмір знижки, а й ціну помилки при зміні конфігурації.
У Google Cloud знижки за зобов'язання (committed use discounts) бувають ресурсними — фіксується обсяг ядер і пам'яті в конкретному сімействі машин і регіоні — і грошовими, коли закріплюється рівень споживання за сервісами. Перші дають максимальну знижку, але жорсткіше прив'язані до типу ресурсу.
Зобов'язання не покривають надбавки за образи, ліцензії та мережевий трафік — вони тарифікуються як звичайно. Нижче чотири реальні альтернативи: коли кожна доречна і чим обмежує.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Зобов'язання на обчислювальні ресурси | Рівномірний профіль навантаження: веб-шар, воркери, потокова обробка | Строк від року, прив'язка до регіону та сімейства машин, простій оплачується |
| Зобов'язання на пам'ять і сховище | Бази даних, кеші, аналітика, де вузьке місце — пам'ять | Знижка нижча, вужчий список сервісів, що покриваються, немає перенесення між регіонами |
| Зобов'язання на базу та автоматичне масштабування | Піки непередбачувані: сезонність, запуски кампаній | Знижка лише на зарезервований мінімум, піки йдуть за звичайним тарифом |
| Без резервування | Нові сервіси, короткі проєкти, перевірка гіпотез | Найвища ціна та відсутність гарантії наявності ресурсів |
Робоча схема — зобов'язання на передбачувану базу плюс автоматичне масштабування на піках: знижка працює там, де споживання стабільне, гнучкість зберігається на решті.
Обмеження, про яке дізнаються пізно: зобов'язання не переноситься між проєктами та сімействами машин, тому склад ресурсів фіксують за фактом споживання, а не за прогнозом.
Порядок впровадження: від інвентаризації до передачі регламентів
Впровадження зобов'язань у GCP — це не купівля знижки, а проєктування схеми покриття на реальних даних. Якщо пропустити інвентаризацію, зобов'язання зафіксує неправильний профіль навантаження: зобов'язання куплено, а частина резерву не вибирається. Тому йдемо суворою інженерною послідовністю.
- Інвентаризація споживання — вивантажуємо історію за кілька періодів і розбираємо її за проєктами, регіонами та сімействами машин, розділяючи стійку базу й пікове навантаження.
- Розбір аномалій — знаходимо разові прогони, тимчасові стенди, забуті ресурси та все, що спотворює профіль; позначаємо й виключаємо з розрахунку, інакше база завищується.
- Проєктування схеми покриття — визначаємо, яку частку бази закривати зобов'язаннями, а що залишити під гнучкі тарифи, щоб зберегти маневр при зміні архітектури.
- Налаштування зобов'язань — вибираємо тип, строк і прив'язку, фіксуємо конфігурацію в коді інфраструктури, а не руками в консолі, щоб схему можна було відтворити й відкотити.
- Перевірка гіпотез на даних — звіряємо розрахунок із фактичним споживанням і завантаженням за перший період: де зобов'язання недобирає або перекриває зайве, коригуємо до того, як спрацює поріг незворотності.
- Передача регламентів — віддаємо правила перегляду покриття, пороги оповіщень на недобір і порядок дій при зміні профілю навантаження.
На виході в команди не разове налаштування, а керований процес: при зміні навантаження схема перераховується за регламентом, а не перезбирається з нуля.
Комплект налаштувань, схем і регламентів за підсумками робіт
Після здачі робіт у вас залишається не презентація, а робочий контур у репозиторії та вікі: за ним новий інженер розбереться із зобов'язаннями за один вечір, а не за тиждень розпитувань.
Документи лежать поруч із конфігураціями інфраструктури й оновлюються в тому ж порядку рев'ю, що й код.
- Карта проєктів — таблиця «проєкт / власник / профіль навантаження / застосовний тип зобов'язань (регіональні під обчислювальні ресурси, гнучкі під загальні витрати) / дата закінчення / відповідальний за продовження».
- Схема розподілу зобов'язань — яка частка базового навантаження закрита зобов'язаннями, яка залишається на вимогу, де зосереджений ризик недобору при падінні споживання.
- Політики доступу — ролі та підтвердження: хто має право оформлювати, продовжувати й скасовувати зобов'язання, хто погоджує зміну обсягу, що фіксується в журналі.
- Регламент перегляду — чек-ліст із періодичністю: звірка фактичного споживання з планом, перевірка дрейфу профілю навантаження, вхід у вікно продовження заздалегідь, щоб не втратити знижку.
- Інструкції для чергової зміни — що дивитися у звітах щодо витрат, які відхилення вважати сигналом, кому ескалювати й у який строк.
- Звіт про покриття — частка навантаження під зобов'язаннями, строки експірації за кожним блоком і список відмов, які знято: відсутність штрафів за недобір і втрати знижки при простої.
Усе це передається з обходом по репозиторію та розбором на вашій стороні — щоб регламент перегляду працював без нас.
Кейс: стабілізували профіль споживання та прибрали стрибки навантаження
Клієнт — продуктовий відділ із постійним парком віртуальних машин під сервіси та епізодичними важкими завданнями в Google Cloud.
Зобов'язання щодо споживання (Committed Use Discounts) були оформлені під пікові тижні, а не під фактичний профіль: частина ресурсів простоювала, частина йшла за цінами без знижки. Частку покриття ніхто не рахував — рішення ухвалювалися за відчуттями від рахунку.
Що показали заміри
За перший місяць замірів: зобов'язаннями закрито 43% споживання, добове споживання коливалося майже вчетверо — від нічного мінімуму до денного піку. Упор у квоти за квартал дав 6 інцидентів, три розбирали вручну. Причина одна: план потужностей жив окремо від того, як навантаження поводиться протягом доби.
Розклали історію споживання на базову та змінну частини: базу зафіксували зобов'язаннями, піки віддали автоматичному масштабуванню, для передбачуваних годин додали розклад. Оповіщення про наближення до квот налаштували за трендом, а не за фактом відмови.
Що стало
Через квартал частка покриття — 88%: знижка працює на постійній частині, а не на випадковому зрізі. Розкид добового споживання стиснувся з чотирьох разів до півтора, інцидентів через упор у квоти — нуль. Наступний перегляд зобов'язань іде вже від даних, а не від пікового тижня.
Зобов'язання щодо ресурсів чи автоматичне масштабування?
Зобов'язання й автомасштабування вирішують різні завдання — їх протиставляють лише у звітах. Зобов'язання фіксує ставку за ресурс на тривалий строк: у Google Cloud це committed use discounts зі знижкою до 55% від погодинної вартості.
Автомасштабування керує кількістю працюючих екземплярів під поточне навантаження. Конфлікт тут економічний: знижка рахується від фактичного споживання, і при плаваючому навантаженні покриття перетворюється на переплату.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Зобов'язання | Рівномірне базове навантаження: системні сервіси, бази, черги | Не зменшити всередині строку; при падінні споживання частина оплачується марно |
| Автомасштабування | Сплески, сезонність, пакетні завдання, середовища розробки | Ставка без знижки, рахунок зростає пропорційно навантаженню |
| Гібрид | Є стійке базове навантаження та змінна частина | Потрібен моніторинг споживання й регулярний перегляд покриття |
Зобов'язання беруть під базове навантаження — системні сервіси, бази, мінімум пулу, який тримається цілодобово. Автомасштабування залишають хвильовому навантаженню: пакетним завданням, сезонним сплескам, середовищам розробки.
Гібридна схема рахується від перцентилів, а не від середнього: покриття беруть за нижнім перцентилем споживання за вікно спостереження — зазвичай 60–70% медіани, тоді піки залишаються на автомасштабуванні.
Перегляд покриття — найризикованіший момент: зобов'язання не можна зменшити всередині строку. Спочатку вводять нові зобов'язання під змінений профіль, дочікуються їх обліку й лише потім відмовляються від старих. Сервіси не перезапускаються — змінюється тарифікація, простою немає.
Технічні сумніви: що уточнюють перед стартом робіт
Перед стартом сумніви в інженерів майже завжди одні й ті самі: що буде при падінні споживання, чи можна змінювати склад ресурсів, як ділити зобов'язання між командами. Нижче — відповіді по суті.
Що буде, якщо споживання просяде?
Зобов'язання фіксує мінімальний обсяг споживання на строк і автоматично не перераховується — недобір закривається за тарифом зобов'язання. Тому ми рахуємо базову лінію за історичними метриками за довгий період і беремо зобов'язання лише на стійку частину навантаження.
Чи можна змінювати склад ресурсів усередині зобов'язання?
Тип зобов'язання прив'язаний до сімейства машин і регіону, гнучкі варіанти допускають заміну в межах групи. Ми вибираємо тип із максимальною свободою заміни й оформлюємо різні групи ресурсів окремими зобов'язаннями — тоді зміна конфігурації не обнуляє покриття.
Як ділити зобов'язання між командами?
У Google Cloud зобов'язання прив'язані до спільного акаунта, а не до окремої команди, тому частку кожної рахують за мітками на ресурсах. Ми налаштовуємо розмітку так, щоб команда бачила своє споживання й покриття, а продовження вирішувалося за цифрами.
Коли переглядають умови?
Чим довший строк, тим вища знижка й тим менше свободи — це головний ризик зобов'язань. Тому в план закладаємо точку перегляду й заздалегідь фіксуємо метрики-приводи змінювати схему: просідання базової лінії, переїзд частини навантаження, зміну платформи.
Обговоримо задачу та повернемося з оцінкою й планом
Щоб повернутися не із загальними міркуваннями, а зі схемою покриття та конкретними строками, нам потрібен зріз вашого фактичного споживання й обмежень.
Зберіть те, що вже є в білінгу та облікових системах — спеціально готувати нічого не доведеться, достатньо передати дані в будь-якому зручному вигляді: вивантаження, доступ на читання або таблиця.
- Помісячну розбивку споживання за 6–12 місяців за сервісами, регіонами та проєктами — за нею видно базовий рівень, який можна закривати зобов'язаннями, і разові піки, які закривати не можна.
- Розбивку за сімействами ресурсів: обчислювальні ядра, пам'ять, прискорювачі, сховище, мережевий трафік — знижка за зобов'язаннями за кожним напрямом рахується окремо.
- Поточні зобов'язання: що вже оформлено, на який строк, у якому регіоні, скільки залишилося і яка частка споживання ними реально покривається.
- Профіль навантаження: добові та тижневі коливання, мінімальний рівень споживання, плани щодо зростання та сезонні сплески.
- Карту середовищ і вимоги до відмовостійкості: які сервіси переживуть переведення на інший клас ресурсів, а які жорстко прив'язані до конфігурації.
- Організаційні обмеження: квоти, погодження, строки планування бюджету й те, хто ухвалює рішення щодо зобов'язань.
Опишіть задачу та передайте ці дані — наступний крок за нами. Повернемося з оцінкою, схемою покриття за сімействами ресурсів, розрахунком частки закритого споживання та планом робіт з етапами, щоб рішення можна було ухвалювати за цифрами, а не за відчуттями.
