Биллинг: практический уровень
Эта страница для команды, которой нужно не только понимать модель, но и управлять стоимостью в продакшене.
Что отслеживать в Usage
Заголовок раздела «Что отслеживать в Usage»Compute
Заголовок раздела «Compute»invocations,cpu_seconds,memory_gb_seconds,residency_seconds- Если используете:
streaming_seconds,websocket_seconds
Isolate
Заголовок раздела «Isolate»invocations,cpu_seconds,memory_gb_seconds,subrequests
egress_gb,storage_gb_month,image_transforms,origin_fetch_gb
Managed PostgreSQL
Заголовок раздела «Managed PostgreSQL»cu_hours,storage_gb,data_transfer_gb,extra_databases,extra_branches
Смотрите не только абсолютные значения, но и скорость роста по дням.
Что сильнее всего влияет на стоимость
Заголовок раздела «Что сильнее всего влияет на стоимость»Compute
Заголовок раздела «Compute»| Драйвер | Что увеличивает расход | Что помогает |
|---|---|---|
invocations | лишние фоновые вызовы, дубли запросов | кэш, дедупликация, rate limiting |
cpu_seconds | тяжёлые вычисления на запрос | precompute, профилирование hot-path |
memory_gb_seconds | большие объекты и долгие операции | уменьшение рабочей выборки, потоковая обработка |
residency_seconds | избыточное удержание экземпляров | idle-таймауты, авто-пауза |
streaming_seconds | долгие стримы | сокращение сессий, раннее завершение |
Isolate
Заголовок раздела «Isolate»| Драйвер | Что увеличивает расход | Что помогает |
|---|---|---|
invocations | высокая частота edge-запросов | кэширование, ISR |
cpu_seconds | тяжёлая логика в isolate | вынос вычислений в Compute |
memory_gb_seconds | высокий configured memory limit | уменьшение лимита памяти в настройках |
subrequests | массовые KV/fetch операции | батчинг, кэширование ответов |
| Драйвер | Что увеличивает расход | Что помогает |
|---|---|---|
egress_gb | большие файлы, высокий трафик | сжатие, CDN-кэш |
storage_gb_month | крупные артефакты деплоя | очистка старых деплоев, оптимизация бандлов |
image_transforms | много вариантов изображений | фиксированные breakpoints, pregeneration |
origin_fetch_gb | частые cache miss | увеличение TTL, stale-while-revalidate |
Managed PostgreSQL
Заголовок раздела «Managed PostgreSQL»| Драйвер | Что увеличивает расход | Что помогает |
|---|---|---|
cu_hours | долгие транзакции, большой CU size, постоянные соединения | connection pooling, auto-suspend, меньший CU |
storage_gb | накопление данных, раздутый WAL | VACUUM, партиционирование, архивирование |
data_transfer_gb | SELECT * без лимитов, тяжёлые JOIN | пагинация, проекция колонок, кэширование |
Практический цикл контроля затрат
Заголовок раздела «Практический цикл контроля затрат»- Зафиксируйте бюджет и лимиты на месяц.
- Настройте предупреждения на 50%, 80% и 100% бюджета.
- Ежедневно проверяйте тренды по ключевым метрикам каждого используемого слоя.
- При всплеске определите, какой слой и какая метрика дала основной вклад.
- Разберите по проектам, окружениям и релизам.
- После оптимизаций сверяйте эффект на 7-дневном окне.
Как расследовать резкий рост счёта
Заголовок раздела «Как расследовать резкий рост счёта»- Определите, какой слой показывает аномалию
- Внутри слоя найдите метрику с наибольшим ростом
- Сопоставьте с релизами, миграциями и маркетинговыми кампаниями
- Проверьте burst-активность и повторные вызовы
- Если рост необъясним, передайте период и разрезы в поддержку
Guardrails — защита от перерасхода
Заголовок раздела «Guardrails — защита от перерасхода»Платформа автоматически детектирует аномалии по каждому слою:
- Velocity spike — текущее значение метрики выросло более чем в 10 раз за последний час
- Jump anomaly — текущее значение метрики превышает 7-дневную медиану более чем в 5 раз
При срабатывании вы получаете уведомление с указанием конкретного слоя и метрики.
Hard Cap
Заголовок раздела «Hard Cap»Hard Cap ограничивает максимальные overage-расходы за период.
- До порога сервис работает штатно
- На пороге срабатывает защитный режим (ограничения ресурсоёмких операций)
- После пересечения порога нужен следующий расчётный период или ручная корректировка