Представляем управление расходами: лимиты расходов и оповещения для Cloudflare

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

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

Теперь вы можете устанавливать пороги расходов и настраивать Cloudflare на приостановку активности при достижении этих лимитов, избегая таким образом неожиданных счетов за непредвиденное использование. Сегодня мы представляем функцию «Управление расходами» в режиме бета-тестирования для любых клиентов с оплатой по факту использования (PayGo), начиная с Workers и Durable Objects.

Используйте управление расходами вместе с лимитами расходов AI Gateway, чтобы управлять затратами на вычисления и инференс ИИ в вашем приложении. AI Gateway уже поддерживает бюджеты для каждого пользователя и каждой модели для Workers AI и других ИИ-провайдеров, применяемые к запросам, маршрутизируемым через ваш шлюз.

Как это работает

Вы можете начать использовать управление расходами через панель управления, cf CLI или REST API.

В dashboard перейдите в раздел «Управление аккаунтом» > «Биллинг» > «Лимиты расходов» и включите продукты, расходы на которые вы хотите контролировать.

Когда вы включаете элементы управления для продукта, вы можете задать лимит расходов, указать адрес электронной почты получателя для уведомлений и установить один или несколько порогов оповещения.

Если вы настроите адрес электронной почты получателя, Cloudflare будет отправлять уведомления, когда оцениваемые расходы достигнут одного из порогов или вашего лимита расходов. При достижении лимита применяется политика блокировки, и ваш продукт автоматически приостанавливается.

Если вы зайдете в dashboard, вы сможете в режиме, близком к реальному времени (менее 10 минут), просматривать расходы за текущий расчетный цикл по каждому поддерживаемому продукту, а также управлять своими настройками и пороговыми значениями. На панели обзора отображается информация о том, для каких продуктов настроены пороговые значения и лимиты. В этом примере вы можете видеть, что для Workers было отправлено два оповещения перед достижением жесткого лимита.

Обратите внимание, что расчетный цикл начинается с момента начала платной подписки, а не с момента развертывания Worker или создания ограничения расходов; подписка, начинающаяся 10 октября, обычно имеет цикл с 10 октября по 10 ноября, а не календарный месяц.

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

Как и большинство сервисов Cloudflare, функция управления расходами также представляет собой API, который вы можете использовать программно; документацию можно найти в нашей документации для разработчиков. Вот пример использования API:

И, конечно же, вы можете использовать cf — интерфейс командной строки для всего API Cloudflare:

Как только ограничение начинает действовать, новые вызовы этого продукта отклоняются. Обратите внимание, что мы приостанавливаем только вызовы пользовательского кода, которые влекут за собой расходы. Например, в Workers вызовы Cron Triggers и потребителей очередей приостанавливаются, но статические активы продолжают обслуживаться.

Чтобы возобновить обслуживание, вы можете:

• Увеличить лимит выше накопленных расходов текущего цикла.
• Отключить или удалить политику блокировки.
• Подождать до следующего расчетного цикла, когда истечет срок действия существующей блокировки.

Вот и всё. Вы можете начать использовать управление расходами для Workers и Durable Objects уже сегодня, а другие продукты появятся в ближайшее время.

Читайте далее, чтобы узнать, как мы создали эту систему и что будет дальше.

Как мы создали управление расходами

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

Давайте начнем с общего обзора платного события с ограничением:

А теперь давайте углубимся в детали.

Сбор и агрегирование данных вблизи источника

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

Поэтому мы собираем и агрегируем измерения как можно ближе к источнику, используя двухэтапный конвейер измерения, который объединяет события в агрегаты использования, так что движок видит накопленное использование, а не должен обрабатывать все события по одному.

Давайте посмотрим на диаграмму.

Первый этап сокращает объем сырых событий на этапе синтаксического анализа до одноминутных окон. Каждый парсер измерений преобразует сырые события в измерения использования, а затем объединяет совпадающие измерения в типичные одноминутные бакеты. Тем не менее, несколько записей могут описывать один и тот же аккаунт и временное окно.

На втором этапе отдельная служба объединяет эти частичные агрегаты первого этапа, используя те же правила группировки, но обычно для пятиминутных окон, и дополнительно сокращает объем перед дальнейшей обработкой движком использования (Usage Engine). Здесь мы также архивируем консолидированные агрегаты; это дает нам надежный набор данных для последующей аналитики и сверки.

Преимущество этого двухэтапного конвейера заключается в том, что он сокращает объем сырых событий на ранней стадии, поэтому последующие движки обрабатывают только то агрегированное использование, которое необходимо для расчета расходов и принятия мер. Именно это делает подход практичным в масштабах Cloudflare.

Движок использования (Usage Engine): обработка с разделением по аккаунтам

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

Мы разделяем обработку по аккаунтам, поэтому информация об использовании аккаунта и его подписке встречается в одном месте. Это позволяет нам поддерживать накопленное использование и применять включенные лимиты без необходимости координации между процессорами ценообразования при каждом обновлении.

Как видите, мы запускаем различные разделы параллельно, что позволяет нам распределять работу между аккаунтами, сохраняя при этом состояние ценообразования каждого аккаунта в едином месте. Также обратите внимание, что каждый раздел хранит как локальное состояние для быстрого доступа, так и надежный журнал упреждающей записи (WAL) на диске. Это дает нам следующие преимущества:

• Меньшая межразделочная координация: состояние использования и подписки каждого аккаунта остаются вместе.
• Согласованное ценообразование: обновления использования разделяют одинаковые лимиты и состояние накопленных расходов.
• Параллельная обработка: разные разделы независимо рассчитывают расходы.
• Возможность восстановления: надежное состояние позволяет запасным процессорам восстанавливаться и возобновлять работу после сбоев, если это необходимо.

И, наконец, метрики использования передаются в механизм тарификации (Rating Engine).

Механизм тарификации (Rating Engine)

Механизм тарификации является важнейшим блоком управления расходами; он превращает использование в денежную стоимость и способен ответить на вопрос: «Учитывая то, что потребил этот аккаунт, его подписку и цены, сколько он потратил на данный момент?»

Вот как это работает по существу.

По сути, механизм тарификации объединяет три вещи:

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

Данные об использовании и подписки представляют собой независимые потоки

Обновления об использовании и подписках поступают как независимые потоки, поэтому мы не можем предполагать, что они поступают в Rating Engine по порядку. Кроме того, мы должны иметь возможность восстанавливаться после сбоя обработки данных или отсутствия информации о подписке из-за, например, сбоя веб-хука.

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

Отслеживание накопленных расходов

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

После расчета накопленных расходов выполняются два шага:

• Оценка политик: определение того, были ли достигнуты один или несколько пороговых значений предупреждений или блокировок.
• Отчетность: мы показываем предполагаемые расходы на использование на панели управления через наши API и при необходимости рассылаем оповещения по электронной почте (через Cloudflare Email Service).

Асинхронное применение лимитов

Rating Engine не находится в пути запроса и не отклоняет запросы напрямую. Вместо этого служба политик отправляет лимит в нашу службу конфигурации среды выполнения и в Quicksilver — наше внутреннее хранилище типа «ключ-значение», разработанное для обеспечения быстрой глобальной репликации и доступа с низкими задержками в масштабах планеты. Это распространяет его на все наши узлы асинхронно.

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

Другими словами, принудительное применение использует локальное состояние, поэтому запросам никогда не приходится ждать Rating Engine. Повторно используя нашу существующую архитектуру ограничения учетных записей среды выполнения, мы исключаем расчет тарифов из пути запроса, распределяя лимиты по глобальной сети.

Что дальше

Любой клиент, использующий модель pay-as-you-go, может начать использовать Spend Management уже сегодня. Хотя это важный этап в нашей дорожной карте, это также только начало. Позвольте нам поделиться некоторыми планами на ближайшие недели и месяцы.

Больше продуктов

Мы начинаем с лимитов для Workers и Durable Objects, но в ближайшем будущем вы сможете измерять и ограничивать множество других продуктов и примитивов Cloudflare. Мы создали систему таким образом, чтобы нашим продуктам было легко и привычно подключаться к ней, так что ожидайте роста каталога.

Ближе к реальному времени

Хотя близкое к реальному времени значение менее чем за 10 минут является отличным ориентиром, мы не останавливаемся на достигнутом, и, будучи упрямыми инженерами, у нас есть весьма неплохие идеи о том, как еще больше сократить это время. Ожидайте, что со временем мы сократим разрыв между измерением и применением ограничений, надеемся, до одной минуты.

Бюджеты на основе агентов и приложений

Прямо сейчас мы измеряем расходы по продуктам и примитивам, но есть и другие полезные аспекты для изучения при контроле затрат. Например, разработчик может захотеть отслеживать затраты на конкретное приложение — такое как скрипт Worker, который использует другие примитивы, такие как R2 или Workers AI. Как мы можем измерить совокупную стоимость всего приложения и приостановить его работу, вместо того чтобы отключать базовые примитивы во всех приложениях клиента?

Еще один убедительный вариант использования средств контроля затрат — ИИ-агенты. Все мы читали страшные истории о вышедших из-под контроля агентах, попадающих в неограниченные циклы рекурсивных рассуждений для решения проблемы методом перебора и генерирующих тысячи долларов убытков из-за высокочастотных и дорогостоящих вызовов API, не говоря уже о создании проблем типа «отказ в обслуживании» (DoS) для баз данных и других служб. AI Gateway уже позволяет выделить агенту бюджет для запросов ИИ, направляемых через него. Задача также может потреблять ресурсы вычислений, баз данных и хранения. Мы хотим сделать возможным бюджетирование этого более широкого использования ресурсов для разных продуктов.

Вы сможете тегировать вызовы от ваших агентов, и наш конвейер будет переносить эти метаданные из среды выполнения в Rating Engine. Это позволит нам относить расходы на конкретный счет и приостанавливать работу приложения или задачи агента для разных продуктов, не прерывая работу других несвязанных приложений.

Начало работы

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

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

Присоединяйтесь к нам в Discord или в соцсетях. Мы ждем ваших отзывов!