Биллинг: практический уровень

Эта страница для команды, которой нужно не только понимать модель, но и управлять стоимостью в продакшене.

Что отслеживать в Usage

ONREZA Compute

• invocations, cpu_seconds, memory_gb_seconds, compute_seconds

Статические сайты и CDN

• static_egress_gb, static_storage_gb_month, static_image_transforms, static_origin_fetch_gb

Управляемый PostgreSQL

• compute_cu_seconds, storage_gb_month, transfer_gb, database_months, branch_months

KV-хранилище

• kv_storage_mb (показатель текущего объёма и лимита, не начисление)

Смотрите не только абсолютные значения, но и скорость роста по дням.

Что сильнее всего влияет на стоимость

ONREZA Compute

Драйвер	Что увеличивает расход	Что помогает
invocations	лишние фоновые вызовы, дубли запросов	кэш, дедупликация, rate limiting
cpu_seconds	тяжёлые вычисления на запрос	precompute, профилирование hot-path
memory_gb_seconds	большие объекты и долгие операции	уменьшение рабочей выборки, потоковая обработка
compute_seconds	долгие ответы, WebSocket-сессии, избыточное удержание экземпляров	idle-таймауты, авто-пауза, раннее завершение долгих соединений

KV-хранилище

Драйвер	Что увеличивает расход	Что помогает
kv_storage_mb	крупные значения, много ключей без TTL, churn ключей	TTL, cleanup, компактные payload/metadata

Статические сайты и CDN

Драйвер	Что увеличивает расход	Что помогает
static_egress_gb	большие файлы, высокий трафик	сжатие, CDN-кэш
static_storage_gb_month	крупные артефакты деплоя	очистка старых деплоев, оптимизация бандлов
static_image_transforms	много вариантов изображений	фиксированные breakpoints, pregeneration
static_origin_fetch_gb	частые cache miss	увеличение TTL, stale-while-revalidate

Управляемый PostgreSQL

Драйвер	Что увеличивает расход	Что помогает
compute_cu_seconds	долгие транзакции, большой CU size, постоянные соединения	connection pooling, auto-suspend, меньший CU
storage_gb_month	накопление данных, раздутый WAL, долго хранимые данные	VACUUM, партиционирование, архивирование, cleanup старых данных
transfer_gb	SELECT * без лимитов, тяжёлые JOIN	пагинация, проекция колонок, кэширование

Практический цикл контроля затрат

1. Зафиксируйте бюджет и лимиты на месяц.
2. Настройте предупреждения на 50%, 80% и 100% бюджета.
3. Ежедневно проверяйте тренды по ключевым метрикам каждого используемого слоя.
4. При всплеске определите, какой слой и какая метрика дала основной вклад.
5. Разберите по проектам, окружениям и релизам.
6. После оптимизаций сверяйте эффект на 7-дневном окне.

Как расследовать резкий рост счёта

1. Определите, какой слой показывает аномалию
2. Внутри слоя найдите метрику с наибольшим ростом
3. Сопоставьте с релизами, миграциями и маркетинговыми кампаниями
4. Проверьте burst-активность и повторные вызовы
5. Если рост необъясним, передайте период и разрезы в поддержку

Автоматическая защита от перерасхода

Платформа автоматически детектирует аномалии по каждому слою:

• Velocity spike — текущее значение метрики выросло более чем в 10 раз за последний час
• Jump anomaly — текущее значение метрики превышает 7-дневную медиану более чем в 5 раз

При срабатывании вы получаете уведомление с указанием конкретного слоя и метрики.

Hard Cap

Hard Cap ограничивает максимальные extra usage расходы за период.

• До порога сервис работает штатно
• На пороге срабатывает защитный режим (ограничения ресурсоёмких операций)
• После пересечения порога нужен следующий расчётный период или ручная корректировка

Осторожно

Hard Cap защищает бюджет, но может ограничить часть функциональности при пике нагрузки. Устанавливайте значение с запасом под плановые кампании и релизы.

См. также

• Слои и метрики
• Методика расчёта
• Лимиты и квоты
• Использование ресурсов