Представляем управление расходами: лимиты расходов и оповещения для Cloudflare
- Cloudflare запустила бета-версию управления расходами для клиентов PayGo; сейчас функция поддерживает Workers и Durable Objects.
- Пользователи задают лимиты и пороги оповещений; при достижении лимита продукт автоматически приостанавливается.
- В панели управления расходы видны с задержкой менее 10 минут; настраивать лимиты можно также через API и CLI.
Почему это важно: Лимиты помогают избежать неожиданных счетов из-за незапланированного использования.
Контроль расходов уже довольно давно входит в число самых востребованных функций среди разработчиков, создающих проекты на нашей платформе. Сейчас на Cloudflare работают более 10 миллионов разработчиков, поэтому эта возможность важна как никогда.
Уже некоторое время в платных тарифах доступны уведомления об использовании и предупреждения о бюджете, но они не решают проблему полностью: информировать — не то же самое, что контролировать.
Теперь можно устанавливать лимиты расходов и выбирать, приостанавливать ли работу Cloudflare при их достижении, чтобы избежать неожиданных счетов из-за незапланированного использования. Сегодня мы запускаем бета-версию функции «Управление расходами» для всех клиентов с оплатой по факту использования (PayGo), начиная с Workers и Durable Objects.
Используйте «Управление расходами» вместе с лимитами расходов AI Gateway, чтобы контролировать затраты на вычисления и вывод ИИ во всём приложении. В AI Gateway уже можно устанавливать бюджеты для отдельных пользователей и моделей в Workers AI и других ИИ-провайдерах, применяемые к запросам, направленным через ваш шлюз.
Как это работает
Начать пользоваться функцией «Управление расходами» можно через панель управления, интерфейс командной строки cf или REST API.
В панели управления перейдите в раздел «Управление» > «Аккаунт» > «Оплата» > «Лимиты расходов» и включите контроль для нужных продуктов.
Включив контроль для продукта, вы сможете задать лимит расходов, указать адрес электронной почты для уведомлений и установить один или несколько порогов оповещения.
Включение функции «Управление расходами» для Durable Objects
Если вы укажете адрес электронной почты для уведомлений, Cloudflare будет отправлять сообщения, когда рассчитанные расходы достигнут одного из пороговых значений или лимита. При достижении лимита активируется блокирующая политика, а продукт автоматически приостанавливается.
Уведомление по электронной почте о достижении лимита расходов
В панели управления можно почти в реальном времени (с задержкой менее 10 минут) посмотреть расходы по каждому поддерживаемому продукту за текущий платёжный цикл, а также управлять настройками и пороговыми значениями. На обзорной панели указано, для каких продуктов настроены пороговые значения и лимиты. В этом примере видно, что Workers сработали два предупреждения, прежде чем был достигнут жёсткий лимит.
Обзор продуктов, для которых используется функция «Управление расходами»
Обратите внимание: платёжный цикл начинается с момента оформления платной подписки, а не с момента развёртывания Worker или установки лимита расходов. Например, подписка, начавшаяся 10 октября, обычно действует с 10 октября по 10 ноября, а не в течение календарного месяца.
В панели управления также отображается журнал аудита: в нём можно посмотреть, кто и когда изменил лимит или когда он был достигнут.
Как и большинство сервисов Cloudflare, «Управление расходами» доступно и через API, поэтому его можно использовать программно. Документация опубликована в разделе документации для разработчиков. Вот пример использования API:
curl --fail-with-body --request POST \
"https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/billing/spend-policies" \
--header "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
--header "Content-Type: application/json" \
--data '{
"name": "Workers spending cap",
"product_id": "workers",
"enabled": true,
"threshold_cents": 10000,
"action": "usage_block",
"notification_email": "me@example.com"
}'И, конечно, можно воспользоваться cf — интерфейсом командной строки для всего API Cloudflare:
cf billing spend-policies list
cf billing spend-policies create
cf billing spend-policies get
cf billing spend-policies update
cf billing spend-policies delete
cf billing spend-policies audit list
cf billing spend-policies activity list
cf billing spend-policies create --body '{
"name": "Workers spending cap",
"product_id": "workers",
"enabled": true,
"threshold_cents": 10000,
"action": "usage_block",
"notification_email": "me@example.com"
}'После активации лимита новые вызовы этого продукта отклоняются. Обратите внимание: мы приостанавливаем только вызовы кода клиента, которые влекут за собой расходы. Например, в Workers приостанавливаются Cron Triggers и вызовы обработчиков очередей, но статические ресурсы продолжают обслуживаться.
Чтобы возобновить работу сервиса, можно:
- Увеличить лимит так, чтобы он превышал расходы, накопленные за текущий цикл.
- Отключить или удалить блокирующую политику.
- Дождаться следующего платёжного цикла — существующая блокировка истечёт.
Вот и всё. Уже сегодня можно начать пользоваться функцией «Управление расходами» для Workers и Durable Objects; вскоре к ним присоединятся и другие продукты.
Читайте дальше, чтобы узнать, как мы создали эту систему и что планируем делать дальше.
Как мы создали функцию «Управление расходами»
На первый взгляд всё кажется простым, но создать такую систему в масштабах Cloudflare было непросто. От вызова, поступившего из любой точки нашей распределённой сети, до решения о блокировке, которое нужно применить глобально, — разработка функции «Управление расходами» потребовала совместной работы нескольких команд, изменения кода существующих систем и создания новых систем с нуля.
Для начала взглянем на схему события, которое тарифицируется и учитывается при достижении лимита:
Жизненный цикл события, учитываемого при достижении лимита
А теперь разберёмся подробнее.
Сбор и агрегация данных как можно ближе к источнику
Каждый вызов формирует показатели использования: количество запросов, время работы процессора, длительность выполнения или операции с хранилищем — в зависимости от продукта. Но передавать и обрабатывать весь этот массив необработанных данных от источников до расчётного движка было бы неэффективно и не позволило бы масштабировать систему.
Поэтому мы собираем и агрегируем показатели как можно ближе к источнику с помощью двухэтапного конвейера учёта. Он объединяет события в сводные показатели использования, чтобы движок обрабатывал накопленные данные, а не каждое событие по отдельности.
Рассмотрим схему.
Как мы собираем, анализируем и агрегируем данные перед отправкой в расчётный движок
На первом этапе объём необработанных событий сокращается непосредственно в ходе их разбора: данные объединяются в минутные интервалы. Каждый анализатор учёта преобразует исходные события в показатели использования, а затем группирует совпадающие показатели, как правило, по минутным интервалам. При этом несколько записей могут относиться к одному аккаунту и одному временному интервалу.
На втором этапе отдельный сервис объединяет эти частичные агрегаты, полученные на первом этапе, по тем же правилам группировки, но обычно за интервалы продолжительностью пять минут. Перед последующей обработкой движком учёта использования объём данных дополнительно сокращается. Здесь же мы архивируем итоговые агрегаты — это даёт нам надёжный набор данных для последующей аналитики и сверки.
Преимущество такого двухэтапного конвейера в том, что объём исходных событий сокращается на раннем этапе. Поэтому последующие движки обрабатывают только агрегированные данные об использовании, необходимые для расчёта расходов и принятия мер. Именно это позволяет системе работать в масштабах Cloudflare.
Движок учёта использования: обработка с разделением по аккаунтам
Движок учёта использования преобразует агрегированные показатели в записи об использовании — стандартизированные записи с данными об аккаунте, временном интервале использования, метрике, количестве и соответствующих измерениях. Иными словами, он сопоставляет специфичные для каждого продукта счётчики с поддерживаемыми метриками использования.
Мы разделяем обработку по аккаунтам, чтобы данные об использовании и подписке каждого аккаунта обрабатывались в одном месте. Это позволяет отслеживать накопленный объём использования и применять включённые в план лимиты без координации между процессорами расчёта стоимости при каждом обновлении.
Обработка с разделением по аккаунтам в движке учёта использования
Как видно на схеме, разные разделы обрабатываются параллельно. Это позволяет распределять задачи между аккаунтами, сохраняя данные о стоимости для каждого аккаунта в одном месте. Обратите внимание: каждый раздел хранит как локальное состояние для быстрого доступа, так и долговечный журнал упреждающей записи (WAL) на диске. Это обеспечивает:
- Меньше координации между разделами: данные об использовании и подписке каждого аккаунта хранятся вместе.
- Согласованный расчёт стоимости: при обновлении данных об использовании учитываются одни и те же включённые лимиты и накопленные расходы.
- Параллельную обработку: расходы для разных разделов рассчитываются независимо.
- Восстановление после сбоев: долговечное состояние позволяет новым процессорам при необходимости восстановить данные и продолжить работу после отказа.
Затем метрики использования поступают в расчётный движок.
Расчётный движок
Расчётный движок — важнейший компонент функции «Управление расходами»: он переводит данные об использовании в денежное выражение и отвечает на вопрос: «Сколько потратил аккаунт с учётом использованных ресурсов, подписки и тарифов?»
Вот как он работает.
Общая схема работы расчётного движка — центрального компонента функции «Управление расходами»
По сути, расчётный движок объединяет три составляющие:
- Записи об использовании: такие показатели, как количество запросов и миллисекунды процессорного времени.
- Данные о подписке: платёжный период аккаунта и изменения тарифного плана.
- Правила расчёта стоимости: тарифы, включённые лимиты и правила округления при расчётах.
Данные об использовании и подписках поступают независимо
Обновления данных об использовании и подписках поступают независимыми потоками, поэтому нельзя рассчитывать, что они попадут в расчётный движок в правильном порядке. Кроме того, система должна уметь восстанавливаться после сбоев обработки данных и отсутствия информации о подписке, например из-за ошибки вебхука.
Если данные об использовании поступают раньше сведений о подписке, необходимых для расчёта стоимости, мы сохраняем их как ожидающие обработки и возвращаемся к ним, когда эти сведения становятся доступны. Это позволяет выдерживать временные задержки и не считать использование бесплатным только потому, что его стоимость ещё не рассчитана.
Отслеживание накопленных расходов
Наконец, мы рассчитываем и отслеживаем накопленные расходы. Расчётный движок использует каталог продуктов — базу данных, в которой определены метрики использования, в том числе включённые лимиты, тарифы и правила округления, —, а также сведения о подписке аккаунта. Миллион миллисекунд процессорного времени не обязательно означает дополнительную плату: сначала движок учитывает включённый в тариф лимит процессорного времени, а затем рассчитывает стоимость превышения. Стоимость рассчитывается на основе накопленного использования, а не путём округления и оплаты каждого запроса по отдельности.
После расчёта накопленных расходов выполняются два действия:
- Проверка политик: определяется, достигнут ли один или несколько порогов предупреждения или блокировки.
- Отчётность: мы показываем в панели управления оценочные расходы на использование через наши API и при необходимости отправляем предупреждения по электронной почте с помощью Email Service от Cloudflare.
Асинхронное применение лимитов
Расчётный движок не участвует в обработке запросов и не отклоняет их напрямую. Вместо этого сервис политик передаёт лимит в службу конфигурации среды выполнения и Quicksilver — нашу внутреннюю систему хранения «ключ — значение», созданную для быстрой глобальной репликации и доступа с низкой задержкой в масштабах всей планеты. Затем лимит асинхронно распространяется на все наши узлы.
Когда лимит поступает в Quicksilver, среда выполнения получает его при очередном периодическом обновлении и начинает отклонять вызовы или операции, на которые распространяется лимит.
Иными словами, для применения лимитов используется локальное состояние, поэтому запросам не приходится ждать ответа от расчётного движка. Используя существующую архитектуру ограничения аккаунтов в среде выполнения, мы не включаем расчёт стоимости в обработку запросов и при этом распространяем лимиты по всей глобальной сети.
Что дальше
Все клиенты с оплатой по факту использования уже могут начать пользоваться функцией «Управление расходами». Это важный этап нашей дорожной карты, но только начало. Расскажем о планах на ближайшие недели и месяцы.
Больше продуктов
Сейчас мы запускаем лимиты для Workers и Durable Objects, но в ближайшем будущем можно будет измерять использование и устанавливать лимиты для многих других продуктов и базовых компонентов Cloudflare. Мы создали систему так, чтобы подключать к ней новые продукты было просто и удобно, поэтому список будет расширяться.
Ещё ближе к реальному времени
Задержка менее 10 минут — отличный показатель для работы почти в реальном времени, но нас он не устраивает. Будучи инженерами, которые не привыкли сдаваться, мы уже нашли способы ещё больше сократить это время. Постепенно мы будем уменьшать промежуток между измерением и применением лимита — надеемся, до менее чем минуты.
Бюджеты для агентов и приложений
Сейчас мы измеряем расходы по продуктам и базовым компонентам, но для контроля затрат полезно учитывать и другие параметры. Например, разработчик может захотеть отслеживать расходы конкретного приложения — например, скрипта Worker, который использует другие компоненты, такие как R2 или Workers AI. Как рассчитать совокупные расходы всего приложения и приостановить его работу, не отключая базовые компоненты для всех приложений клиента?
Ещё один важный сценарий применения контроля расходов — ИИ-агенты. Мы все читали истории о том, как вышедшие из-под контроля агенты зацикливаются на рекурсивных рассуждениях без ограничений, пытаясь решить задачу методом перебора. В результате частые и дорогостоящие вызовы API могут обойтись в тысячи долларов, не говоря уже о перегрузке баз данных и других сервисов вплоть до отказа в обслуживании (DoS). AI Gateway уже позволяет задать агенту бюджет на ИИ-запросы, проходящие через него. Но задача может также потреблять вычислительные ресурсы, ресурсы баз данных и хранилищ. Мы хотим дать возможность устанавливать бюджеты на такое более широкое использование ресурсов в разных продуктах.
Вы сможете помечать вызовы ваших агентов, а наш конвейер будет передавать эти метаданные из среды выполнения в расчётный движок. Это позволит относить расходы на конкретное приложение или задачу агента и приостанавливать её работу в разных продуктах, не затрагивая другие приложения, не связанные с ней.
Начало работы
Этот запуск — первый шаг к тому, чтобы контроль расходов стал неотъемлемой частью разработки на Cloudflare наряду с развёртыванием кода и мониторингом приложений.
Подробнее читайте в документации для разработчиков по оплате. Начните пользоваться функцией «Управление расходами» и расскажите нам, что работает хорошо, чего не хватает и в каких случаях пригодились бы более гибкие бюджеты.
Присоединяйтесь к нам в Discord и соцсетях. Мы прислушиваемся к вашим отзывам!
