Облако удобно тем, что ресурсы включаются по клику. Этим же оно и коварно: незаметно накапливается счёт за то, что работает вхолостую или взято с запасом «на всякий случай». Хорошая новость — большинство переплат лечится несколькими понятными приёмами. Многое опирается на то, где вы запускаете сервис и как храните данные.

Модели оплаты и скидки

Базовая модель — оплата по мере использования (pay-as-you-go): платите за то, что работает, по факту. У GCP есть несколько способов заплатить меньше:

  • Скидки за длительное использование (sustained use discounts) — начисляются автоматически, если машина работает большую часть месяца. Отличительная черта GCP: ничего резервировать не нужно, скидка приходит сама.
  • Скидки за обязательство (committed use discounts, CUDs) — за то, что вы заранее бронируете объём ресурсов на 1–3 года. Разумно для стабильной постоянной нагрузки.
  • Spot-машины (preemptible) — сильно дешевле обычных, но GCP может их в любой момент забрать. Идеальны для нагрузок, которые не жалко прервать: пакетная обработка, тесты, фоновые расчёты. Для боевого сервиса, который должен быть доступен всегда, — нет.

Правило: spot — под то, что не жалко потерять; обязательства — под стабильную базу; sustained use применяется само; pay-as-you-go — под эксперименты.

Right-sizing: не брать с запасом

Самая частая переплата новичка — взять машину «помощнее, чтобы наверняка», и оставить её загруженной на 5%. Right-sizing — подгонка размера под реальное потребление: посмотреть в Cloud Monitoring, сколько процессора и памяти действительно используется, и уменьшить машину. Инструмент рекомендаций (Recommender) подсказывает такие возможности автоматически.

Сюда же — гасить то, что не работает: тестовые и dev-окружения ночью и в выходные никому не нужны, их останавливают по расписанию. А serverless Cloud Run масштабируется до нуля сам, поэтому под нерегулярную нагрузку он дешевле постоянно включённой машины.

Классы хранения и трафик

Два коварных места в счёте связаны с данными.

Классы хранения. В Cloud Storage холодные данные (старые логи, бэкапы, архивы) не должны лежать в дорогом классе Standard. Lifecycle-правила сами переносят их в Nearline, Coldline и Archive — это копейки за хранение вместо полной цены.

Исходящий трафик. За данные, уходящие из облака наружу, берут плату. На раздаче популярной статики это растёт незаметно. Помогает Cloud CDN перед хранилищем и внимание к архитектуре, которая гоняет данные между зонами и регионами без нужды.

Контроль расходов

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

Где это применяется

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

Типичные ошибки новичков:

  • берут машины с запасом и оставляют их почти пустыми;
  • держат dev-окружения включёнными круглосуточно;
  • не настраивают классы хранения — платят за Standard даже за архив;
  • не разносят затраты по проектам и не ставят бюджеты — счёт становится сюрпризом;
  • ставят spot-машины под боевой сервис — и он падает, когда их забирают.

Что учить дальше: где смотреть потребление — в наблюдаемости; дешёвые классы хранения — в Cloud Storage; serverless под нерегулярную нагрузку — в serverless. Тот же набор приёмов в AWS — оптимизация затрат в AWS.