BMW Group следит за расходами более чем 14 000 облачных аккаунтов через внутреннюю FinOps-платформу CLEA (Cloud Efficiency Analytics). Каждый день она строит прогноз трат для каждой пары «аккаунт - сервис» библиотекой Prophet, сравнивает прогноз с фактом из биллинга и отправляет письмо владельцу аккаунта, если расходы ушли от ожидаемой линии. Весь прогон выполняется на AWS Step Functions в режиме Distributed Map примерно за 20 минут, а вычислительная часть обходится около $50 в месяц.
Задача у системы практическая: заметить скачок затрат на следующий день после того, как он случился, и отправить уведомление конкретному человеку, который отвечает за аккаунт. Не в общий чат дежурной команды, не на дашборд, куда никто не заглянет, а в почту владельцу с контекстом аномалии.
Ниже разбор архитектуры: какие данные поступают на вход, как устроен параллелизм на 500 функций, почему выбран Prophet, как отсекаются ложные срабатывания и где у подхода слабые места.
Что такое CLEA и зачем BMW понадобилась автоматическая детекция аномалий
CLEA (Cloud Efficiency Analytics) - внутренняя FinOps-платформа BMW Group, которую компания построила на AWS совместно с Reply. Платформа охватывает более 14 000 облачных аккаунтов по всему парку BMW. Детали работы системы описали Philipp Karg из BMW Group и Christopher Masurek из Data Reply в техническом разборе AWS о детекции аномалий расходов.
От дашбордов Quick Sight к ежедневным алертам
CLEA начиналась как набор дашбордов в Amazon Quick Sight. Они давали сотрудникам видимость расходов: можно было открыть график и увидеть, сколько тратит аккаунт. Дашборд по своей природе пассивный инструмент. Он показывает данные только тому, кто в него заглянул, и молчит, если никто не смотрит.
Пока аккаунтов было немного, это работало. Владелец команды раз в неделю открывал отчёт и замечал странности. На масштабе 14 000 аккаунтов подход разваливается: никто не просматривает тысячи графиков вручную, а аномалия на одном аккаунте может незаметно расти неделями.
Автоматика сменила модель работы. Система каждый день сравнивает фактические расходы с прогнозом и сама пишет владельцу аккаунта, когда траты выходят за ожидаемые рамки. Человек получает уведомление с контекстом аномалии, а не приглашение сходить на дашборд.
Масштаб задачи: 14 000 аккаунтов и сотни тысяч временных рядов
Сырые биллинговые данные BMW - это порядка 3 млрд строк и 500 колонок в месяц. Этот объём нужно не просто хранить, а ежедневно превращать в прогнозы.
Логика разбиения простая. Один аккаунт с EC2, S3, Lambda и RDS даёт четыре дневных временных ряда, по одному на сервис. Аккаунт с 15 активными сервисами - 15 рядов. По 14 000 аккаунтов, у каждого свой набор сервисов, набираются сотни тысяч комбинаций «аккаунт - сервис». Каждая требует отдельного прогноза и отдельной проверки на аномалию.
Это ключевая сложность: задача не сводится к одной модели на весь счёт. Общий график затрат сгладил бы локальный скачок на одном сервисе в одном аккаунте, а именно такие скачки и представляют интерес.
Как устроен пайплайн: от AWS CUR до письма владельцу аккаунта
Ежедневный цикл состоит из сбора биллинга, агрегации, прогноза, сравнения и рассылки. Оркестратор всего процесса - AWS Step Functions.
Сбор и подготовка данных: CUR, агрегация и гранулярность
Основной источник данных - AWS Cost and Usage Reports (CUR). Дополнительно CLEA забирает эквивалентные биллинговые экспорты от других облачных провайдеров в парке BMW. Первичные данные приходят с задержкой в один день (T-1): вчерашние расходы анализируются сегодня.
Сырые выгрузки приводятся к единому виду - дневная стоимость на аккаунт на сервис. Одна гранулярность для всех источников упрощает прогнозирование: каждая модель работает с одинаковым форматом временного ряда.
Отдельная деталь надёжности: пайплайн запускается после подтверждения, что доставка CUR полностью завершена. Если стартовать раньше, в данные попадёт неполный день, и прогноз получит искажённую точку, которая может выглядеть как аномалия.
Оркестрация на Step Functions и Distributed Map
Схема ежедневного прогона:
- Подготовительная AWS Lambda-функция находит активные аккаунты и записывает их список в Amazon S3 в формате JSON.
- Step Functions запускает Distributed Map и разворачивает работу на до 500 одновременных Lambda-функций.
- Каждая функция берёт один аккаунт и строит прогнозы для всех его сервисов.
- Полный прогон по 14 000 аккаунтов завершается примерно за 20 минут.
Распараллеливание по аккаунтам выбрано удачно: аккаунты независимы друг от друга, между ними нет общих вычислений. Одна функция на аккаунт даёт естественную единицу работы, которую легко масштабировать и перезапускать при сбое отдельного шага.
Прогнозирование расходов с Prophet: как строятся ожидания и считается impact
Для каждой пары «аккаунт - сервис» CLEA обучает отдельную модель Prophet на 365 днях дневной истории с аддитивной сезонностью.
Почему Prophet, а не ARIMA или нейросети
Prophet - открытая библиотека прогнозирования от Meta. Выбор BMW объясняет простотой и стабильными результатами на временных рядах затрат.
Для сотен тысяч рядов простота превращается в конкретное преимущество: обучение предсказуемо по времени, модель устойчива к пропускам и выбросам, не требует тонкой ручной настройки под каждый сервис. Нейросетевые модели на таком количестве коротких рядов потребовали бы больше данных и вычислительных ресурсов на обучение, а ARIMA сложнее настраивать и поддерживать в автоматическом режиме.
У выбора есть и обратная сторона. Prophet строит аддитивную модель, где нелинейный тренд описывается кусочно-линейной функцией с точками изменения, к которой добавляются годовая, недельная и дневная сезонность и праздничные эффекты. Такой модели трудно даётся резкий разрыв в истории: на слишком коротком ряде, где невозможно отличить изгиб тренда от сдвига годовой волны, выжившие точки изменения могут оказаться далеко от реального разрыва. Документация и практические руководства по Prophet прямо не рекомендуют применять его на очень коротких рядах - ориентир в районе менее 50 точек данных. Для дневных рядов это означает, что на истории короче пары месяцев качество прогноза заметно падает.
Определение expected, actual и impact
Три величины, на которых держится вся логика алертов:
- Expected spend - предсказанная стоимость для одной пары «аккаунт - сервис» на один день, построенная на 365 днях истории.
- Actual spend - стоимость, записанная в биллинге за тот же аккаунт, сервис и день.
- Impact - фактические расходы минус ожидаемые. Положительный impact означает перерасход относительно прогноза.
Такая разбивка даёт понятную метрику для приоритизации. Отклонение на $200 в аккаунте с оборотом $50 000 и отклонение на $200 в аккаунте с оборотом $500 - события разного веса, и impact позволяет их различить ещё до отправки письма.
Как отсекаются ложные срабатывания: пороги, кластеризация и персональные настройки
Главный риск любой системы алертов - шум. Если письма приходят каждый день и в половине случаев ничего страшного не произошло, владельцы аккаунтов перестают их читать. BMW гасит шум несколькими фильтрами.
Базовый порог 40% и кластеризация по среднему расходу
Алерт отправляется, если фактические расходы отклоняются от прогноза минимум на 40%. Порог в процентах сам по себе не универсален: для крупного аккаунта отклонение в несколько процентов может означать десятки тысяч долларов, для мелкого те же 40% не заинтересуют никого.
Поэтому аккаунты сортируются в четыре кластера по среднему расходу за последние три месяца. У каждого кластера свой минимальный порог денежного влияния - от $300 до $1000. Это снижает шум: мелкие колебания на фоне крупного счёта не превращаются в письмо.
Повышенные пороги для Glue, Athena и EC2
Часть сервисов волатильна по своей природе. AWS Glue, Athena и EC2 работают с пакетной обработкой и on-demand вычислениями: один запуск большого ETL-задания или тяжёлого запроса даёт резкий скачок дневных затрат. Стандартный порог 40% для них слишком чувствителен и порождает ложные срабатывания.
Для этих сервисов порог повышен до 60%. Это пример настройки под характер потребления конкретной услуги вместо единого правила на всё.
Персональные настройки для волатильных команд
Отдельным командам повышенных порогов тоже мало: их рабочие нагрузки нестабильны, и даже адаптированные правила дают ложные алерты. Для команд с известными волатильными нагрузками предусмотрен статус пониженной чувствительности: его можно запросить, и тогда аномалия должна превысить трёхкратный стандартный порог, прежде чем сработает алерт.
Сколько это стоит и как быстро работает: 20 минут и $50 в месяц
Ежедневная обработка 14 000 аккаунтов занимает около 20 минут. Вычислительная часть пайплайна обходится примерно в $50 в месяц.
Почему serverless даёт такую низкую стоимость
Экономика складывается из модели оплаты. Lambda тарифицируется за время выполнения, Step Functions - за переходы состояния. Пайплайн работает раз в сутки, а внутри запуска нагрузка держится минуты, не часы. Постоянных серверов нет: между запусками не платит никто.
Distributed Map с 500 параллельными функциями сокращает общее время прогона, а значит уменьшает и оплачиваемые секунды вычислений. Если бы те же 14 000 аккаунтов обрабатывались последовательно, счёт вырос бы пропорционально времени, а не объёму работы.
В $50 входит только вычисление. Хранение 365 дней истории по сотням тысяч рядов, биллинговые выгрузки и сопутствующая инфраструктура считаются отдельно - точных цифр по этим статьям в разборе AWS не приводится.
Ограничения и подводные камни подхода
Минусы и компромиссы стоит держать в голове до того, как копировать схему:
- Задержка T-1. Аномалия становится видна на следующий день. Для медленно растущего перерасхода это нормально, для часового всплеска на дорогом сервисе - нет. Система не заменяет real-time контроль бюджета.
- Пропуски и неполные данные. Если CUR доставлен частично, прогноз получит искажённую точку. Запуск после подтверждения полноты выгрузки снижает риск, но не убирает его полностью.
- Холодный старт. При 500 параллельных Lambda часть вызовов уходит на инициализацию: при первом запросе, для которого создаётся новый рабочий процесс, AWS Lambda нужно найти свободные ресурсы и инициализировать функциональный модуль. Это добавляет задержку и влияет на оплачиваемое время, поскольку Lambda тарифицируется в том числе по GB-секундам длительности. На 20 минутах это незаметно, на меньших прогонах ощутимее.
- Чувствительность Prophet к разрывам в истории. Резкие изменения профиля нагрузки модель отрабатывает с задержкой, пока не накопит новую историю.
- Стоимость истории. 365 дней по сотням тысяч рядов - заметный объём хранения, который не входит в $50. Точная величина этих затрат в разборе не раскрывается.
Система дополняет ручной анализ, а не отменяет его. Автоматика отсеивает шум и подсвечивает подозрительное, решение о том, что делать с найденной аномалией, остаётся за владельцем аккаунта.
Как адаптировать подход под свой облачный парк: практические шаги
Схему можно перенести на меньший масштаб без переписывания под 14 000 аккаунтов.
- Инвентаризация. Соберите список аккаунтов и сервисов, которые в них реально работают. Без этого не построить гранулярность.
- Сбор биллинга. Настройте выгрузку AWS CUR или аналогичного экспорта от вашего провайдера. Копите историю сразу: Prophet для базовой сезонности нужен минимум год, для старта хватит меньшего, но точность будет ниже.
- Единая гранулярность. Агрегируйте данные к виду «дневная стоимость на аккаунт на сервис». Один формат для всех источников.
- Прогноз. Начните с Prophet: он быстро разворачивается и не требует подбора гиперпараметров под каждый ряд. Если ряды длинные и сложные, позже можно добавить альтернативные модели для сравнения.
- Пороги. Поставьте базовый порог отклонения и разведите аккаунты по группам среднего расхода. Для волатильных сервисов вроде ETL и вычислений поднимите порог отдельно.
- Оркестрация. Step Functions с Distributed Map даёт параллелизм по аккаунтам без управления серверами. 500 параллельных функций - ориентир для крупного парка, для небольшого хватит и нескольких десятков.
- Обратная связь. Заложите механизм, которым получатели алертов сообщают о ложных срабатываниях. Без него пороги быстро устареют.
Внедряйте постепенно: сначала несколько команд и один крупный сервис, затем расширение. Качество порогов важнее охвата - система, которая шумит, перестаёт работать через неделю.