Committed Use Discounts GCP: экономия до 55% при правильной настройке

Committed Use Discounts в GCP: почему скидка не применяется

Ровная круглосуточная нагрузка, обязательства оформлены, а в детализации счёта нет строки со скидкой за долгосрочное обязательство. Committed Use Discounts в GCP не размазываются по инфраструктуре автоматически: скидка привязана к проекту, региону, семейству машин и типу ресурса по отдельности. Совпадают все параметры с фактическим потреблением — скидка применяется, разошёлся хотя бы один — она не находит объект.

Расхождение обычно выглядит безобидно. Обязательство оформили на один проект, а рабочие нагрузки живут в двух-трёх — после разделения инфраструктуры часть переехала в отдельный проект. Или регион в обязательстве один, а инстансы разъехались по зонам и соседнему региону. Или семейство машин сменили при обновлении, а обязательство осталось на прежний ряд.

Поэтому первое, что мы делаем, — снимаем профиль потребления за 30–60 дней в разрезе проектов, регионов и рядов машин. Он показывает, где нагрузка действительно ровная и сколько её держится ночью и в выходные. Резервирование ресурсов по пиковым значениям — вторая частая ошибка: оплаченная ёмкость простаивает половину времени, и выгода съедается.

Отдельно проверяем, не перекрывают ли обязательства друг друга и не конфликтуют ли они с автоматическим масштабированием: то, что поднимается по расписанию, в долгосрочное обязательство брать невыгодно.

Дальше разбираем, как это закрывается: как сопоставить обязательства с реальным потреблением, какой профиль потребления считать ровным и что стоит держать по требованию, а не в обязательстве.

Что даёт управляемая модель резервирования ресурсов

Обязательство по резервированию — не скидка, а фиксация базовой части нагрузки на длинный срок: вы заранее объявляете, сколько ресурсов держите постоянно, и платите за них по пониженному тарифу. Всё, что выше базы — пики, эксперименты, сезонные всплески — остаётся по требованию. Такой контур настраивается в Google Cloud и превращает облачный счёт из лотереи в управляемый показатель.

Дальше — чек-лист, по которому мы проверяем, что модель действительно работает, а не просто включена:

• Доля покрытия обязательствами выравнивается. Держим 60–75% стабильной базы под обязательством, остальное — по требованию: при перекосе выше 85% любой спад нагрузки превращается в переплату.
• Расходы на инфраструктуру перестают расти. Счёт становится функцией от числа сервисов, а не от случайных пиков — отклонение месяц к месяцу держится в единицах процентов.
• Предсказуемая нагрузка отделена от пиковой. Базы, кэш, очереди и фоновые задачи уходят под обязательство, разовые прогоны остаются гибкими.
• Уходит класс отказов из-за нехватки квот в пик. Резерв привязан к семейству машин и региону, и новая машина в момент роста поднимается без ожидания выделения ресурсов.
• Стоимость владения считается на горизонте. Эффект резервирования виден не в первом счёте, а на квартале: сравниваем «обязательство плюс по требованию» против чистого потребления.

Каждый пункт сверяем с реальным профилем нагрузки за несколько месяцев — иначе обязательство либо недогружено, либо мешает расти.

Режимы резервирования: сравнение вариантов и ограничений

Режим резервирования определяет не только размер скидки, но и цену ошибки при смене конфигурации. В Google Cloud скидки за обязательства (committed use discounts) бывают ресурсными — фиксируется объём ядер и памяти в конкретном семействе машин и регионе — и денежными, когда закрепляется уровень потребления по сервисам. Первые дают максимальную скидку, но жёстче привязаны к типу ресурса.

Обязательства не покрывают надбавки за образы, лицензии и сетевой трафик — они тарифицируются как обычно. Ниже четыре реальные альтернативы: когда каждая уместна и чем ограничивает.

Рабочая схема — обязательство на предсказуемую базу плюс автоматическое масштабирование на пиках: скидка работает там, где потребление стабильно, гибкость сохраняется на остальном. Ограничение, о котором узнают поздно: обязательство не переносится между проектами и семействами машин, поэтому состав ресурсов фиксируют по факту потребления, а не по прогнозу.

Порядок внедрения: от инвентаризации до передачи регламентов

Внедрение обязательств в GCP — это не покупка скидки, а проектирование схемы покрытия на реальных данных. Если пропустить инвентаризацию, обязательство зафиксирует неверный профиль нагрузки: обязательство куплено, а часть резерва не выбирается. Поэтому идём строгой инженерной последовательностью.

1. Инвентаризация потребления — выгружаем историю за несколько периодов и разбираем её по проектам, регионам и семействам машин, разделяя устойчивую базу и пиковую нагрузку.
2. Разбор аномалий — находим разовые прогоны, временные стенды, забытые ресурсы и всё, что искажает профиль; помечаем и исключаем из расчёта, иначе база завышается.
3. Проектирование схемы покрытия — определяем, какую долю базы закрывать обязательствами, а что оставить под гибкие тарифы, чтобы сохранить манёвр при смене архитектуры.
4. Настройка обязательств — выбираем тип, срок и привязку, фиксируем конфигурацию в коде инфраструктуры, а не руками в консоли, чтобы схему можно было воспроизвести и откатить.
5. Проверка гипотез на данных — сверяем расчёт с фактическим потреблением и загрузкой за первый период: где обязательство недобирается или перекрывает лишнее, корректируем до того, как сработает порог необратимости.
6. Передача регламентов — отдаём правила пересмотра покрытия, пороги оповещений на недобор и порядок действий при смене профиля нагрузки.

На выходе у команды не разовая настройка, а управляемый процесс: при изменении нагрузки схема пересчитывается по регламенту, а не пересобирается с нуля.

Комплект настроек, схем и регламентов по итогам работ

После сдачи работ у вас остаётся не презентация, а рабочий контур в репозитории и вики: по нему новый инженер разберётся с обязательствами за один вечер, а не за неделю расспросов. Документы лежат рядом с конфигурациями инфраструктуры и обновляются в том же порядке ревью, что и код.

• Карта проектов — таблица «проект / владелец / профиль нагрузки / применимый тип обязательств (региональные под вычислительные ресурсы, гибкие под общий расход) / дата окончания / ответственный за продление».
• Схема распределения обязательств — какая доля базовой нагрузки закрыта обязательствами, какая остаётся по требованию, где сосредоточен риск недобора при падении потребления.
• Политики доступа — роли и подтверждения: кто вправе оформлять, продлевать и отменять обязательства, кто согласует изменение объёма, что фиксируется в журнале.
• Регламент пересмотра — чек-лист с периодичностью: сверка фактического потребления с планом, проверка дрейфа профиля нагрузки, вход в окно продления заранее, чтобы не потерять скидку.
• Инструкции для дежурной смены — что смотреть в отчётах по расходу, какие отклонения считать сигналом, кому эскалировать и в какой срок.
• Отчёт о покрытии — доля нагрузки под обязательствами, сроки экспирации по каждому блоку и список отказов, которые сняты: отсутствие штрафов за недобор и потери скидки при простое.

Всё это передаётся с обходом по репозиторию и разбором на вашей стороне — чтобы регламент пересмотра работал без нас.

Кейс: стабилизировали профиль потребления и убрали скачки нагрузки

Клиент — продуктовый отдел с постоянным парком виртуальных машин под сервисы и эпизодическими тяжёлыми задачами в Google Cloud. Обязательства по потреблению (Committed Use Discounts) были оформлены под пиковые недели, а не под фактический профиль: часть ресурсов простаивала, часть уходила по ценам без скидки. Долю покрытия никто не считал — решения принимались по ощущениям от счёта.

Что показали замеры

За первый месяц замеров: обязательствами закрыто 43% потребления, суточное потребление гуляло почти вчетверо — от ночного минимума до дневного пика. Упор в квоты за квартал дал 6 инцидентов, три разбирали вручную. Причина одна: план мощностей жил отдельно от того, как нагрузка ведёт себя в течение суток.

Разложили историю потребления на базовую и переменную части: базу зафиксировали обязательствами, пики отдали автоматическому масштабированию, для предсказуемых часов добавили расписание. Оповещения о приближении к квотам настроили по тренду, а не по факту отказа.

Что стало

Через квартал доля покрытия — 88%: скидка работает на постоянной части, а не на случайном срезе. Разброс суточного потребления сжался с четырёх раз до полутора, инцидентов из-за упора в квоты — ноль. Следующий пересмотр обязательств идёт уже от данных, а не от пиковой недели.

Обязательства по ресурсам или автоматическое масштабирование?

Обязательство и автомасштабирование решают разные задачи — их противопоставляют только в отчётах. Обязательство фиксирует ставку за ресурс на длительный срок: в Google Cloud это committed use discounts со скидкой до 55% от почасовой стоимости. Автомасштабирование управляет числом работающих экземпляров под текущую нагрузку. Конфликт здесь экономический: скидка считается от фактического потребления, и при плавающей нагрузке покрытие уходит в переплату.

Обязательство берут под базовую нагрузку — системные сервисы, базы, минимум пула, который держится круглосуточно. Автомасштабирование оставляют волновой нагрузке: пакетным задачам, сезонным всплескам, окружениям разработки.

Гибридная схема считается от перцентилей, а не от среднего: покрытие берут по нижнему перцентилю потребления за окно наблюдения — обычно 60–70% медианы, тогда пики остаются на автомасштабировании.

Пересмотр покрытия — самый рискованный момент: обязательство нельзя уменьшить внутри срока. Сначала вводят новые обязательства под изменившийся профиль, дожидаются их учёта и только затем отказываются от старых. Сервисы не перезапускаются — меняется тарификация, простоя нет.

Технические сомнения: что уточняют перед стартом работ

Перед стартом сомнения у инженеров почти всегда одни и те же: что будет при падении потребления, можно ли менять состав ресурсов, как делить обязательства между командами. Ниже — ответы по существу.

Можно ли менять состав ресурсов внутри обязательства?

Тип обязательства привязан к семейству машин и региону, гибкие варианты допускают замену в пределах группы. Мы выбираем тип с максимальной свободой замены и оформляем разные группы ресурсов отдельными обязательствами — тогда смена конфигурации не обнуляет покрытие.

Как делить обязательства между командами?

В Google Cloud обязательства привязаны к общему аккаунту, а не к отдельной команде, поэтому долю каждой считают по меткам на ресурсах. Мы настраиваем разметку так, чтобы команда видела своё потребление и покрытие, а продление решалось по цифрам.

Когда пересматривают условия?

Чем длиннее срок, тем выше скидка и тем меньше свободы — это главный риск обязательств. Поэтому в план закладываем точку пересмотра и заранее фиксируем метрики-поводы менять схему: просадку базовой линии, переезд части нагрузки, смену платформы.

Обсудим задачу и вернёмся с оценкой и планом

Чтобы вернуться не с общими соображениями, а со схемой покрытия и конкретными сроками, нам нужен срез вашего фактического потребления и ограничений. Соберите то, что уже есть в биллинге и учётных системах — специально готовить ничего не придётся, достаточно передать данные в любом удобном виде: выгрузка, доступ на чтение или таблица.

• Помесячную разбивку потребления за 6–12 месяцев по сервисам, регионам и проектам — по ней видно базовый уровень, который можно закрывать обязательствами, и разовые пики, которые закрывать нельзя.
• Разбивку по семействам ресурсов: вычислительные ядра, память, ускорители, хранилище, сетевой трафик — скидка за обязательства по каждому направлению считается отдельно.
• Текущие обязательства: что уже оформлено, на какой срок, в каком регионе, сколько осталось и какая доля потребления ими реально покрывается.
• Профиль нагрузки: суточные и недельные колебания, минимальный уровень потребления, планы по росту и сезонные всплески.
• Карту окружений и требования к отказоустойчивости: какие сервисы переживут перевод на другой класс ресурсов, а какие жёстко привязаны к конфигурации.
• Организационные ограничения: квоты, согласования, сроки планирования бюджета и то, кто принимает решение по обязательствам.

Опишите задачу и передайте эти данные — следующий шаг за нами. Вернёмся с оценкой, схемой покрытия по семействам ресурсов, расчётом доли закрытого потребления и планом работ с этапами, чтобы решение можно было принимать по цифрам, а не по ощущениям.