BMW перевела контроль облачных расходов на ежедневный поиск аномалий по 14 000 аккаунтов

Что именно прогнозирует CLEA

Основа — биллинговые данные AWS Cost and Usage Reports (AWS CUR), главный источник, к которому добавлены аналогичные выгрузки остальных провайдеров облачного парка BMW Group. AWS CUR, по описанию AWS, содержит наиболее полный набор данных о затратах и использовании и доставляет отчёты в бакет Amazon S3, а каждый отчёт состоит из строк по уникальной комбинации продуктов, типов использования и операций. Сырые данные BMW Group — это порядка 3 млрд строк и 500 колонок в месяц. CLEA приводит их к одному зерну: суточная стоимость на аккаунт и на сервис, с задержкой в один день, поэтому вчерашние траты анализируются и по ним же рассылаются оповещения сегодня.

Один аккаунт с Amazon EC2, Amazon S3, AWS Lambda и Amazon RDS даёт четыре суточных временных ряда — по одному на сервис. Аккаунт с пятнадцатью сервисами даёт пятнадцать рядов, а на 14 000 аккаунтов с их собственными наборами активных сервисов набираются сотни тысяч пар «аккаунт — сервис», и каждой нужен свой прогноз и своя оценка аномалии. В терминах статьи «ожидаемые расходы» — это предсказание для пары «аккаунт — сервис» на конкретный день по истории в 365 дней, «фактические расходы» — записанная в биллинге стоимость за тот же день, а «эффект» — разница между ними, так что положительный эффект означает перерасход относительно прогноза.

Prophet и конвейер прогноза

Базу стоимости CLEA строит на Prophet — открытой библиотеке прогнозирования от Meta, выбранной за простоту и ровную работу на временных рядах расходов. Prophet, как описывает его собственная документация, — процедура прогнозирования временных рядов на аддитивной модели, где нелинейные тренды сочетаются с годовой, недельной и суточной сезонностью и эффектами праздников, и лучше всего она работает на рядах с выраженной сезонностью и несколькими сезонами истории. Модель в CLEA обучается на 365 днях суточной истории каждой пары «аккаунт — сервис» с аддитивной сезонностью.

Ежедневный прогон оркестрирует AWS Step Functions: подготовительная функция AWS Lambda находит активные аккаунты и записывает список в Amazon S3 как JSON, после чего Distributed Map разносит работу на столько параллельных функций Lambda, сколько нужно, — до 500 одновременно. Механика соответствует документации: в распределённом режиме каждая итерация состояния Map исполняется как дочерний workflow-запуск, что и даёт высокую параллельность. Полный прогон по 14 000 аккаунтов завершается примерно за 20 минут, а результат используется двояко — как скользящий прогноз на 12 месяцев и как посуточные предсказанные значения, становящиеся базой ожидаемой стоимости для поиска аномалий.

Прогнозирование в CLEA — сменный модуль: интерфейсами служат формат входа (суточная стоимость на пару «аккаунт — сервис») и формат выхода (посуточные предсказания с доверительными интервалами), поэтому движок прогноза можно заменить, не трогая слои обнаружения и оповещения, на которые владельцы аккаунтов опираются ежедневно.

Почему фиксированный порог не работает

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

Часть сервисов в модель не попадает вовсе: до запуска обнаружения исключаются сервисы с низкими тратами (в среднем ниже $0,10 за последние 3 дня), сервисы с историей меньше 10 дней и отдельные строки и типы начислений, не относящиеся к прогнозу. Дальше работает порог отклонения: помеченный день должен отклониться от ожидаемых расходов минимум на 40 процентов, чтобы остаться в рассмотрении, а оставшиеся срабатывания проходят через две группы фильтров — общие пороги и пороги под конкретные случаи.

Общие пороги устроены по кластерам аккаунтов, разбитым по средней трате за последние три месяца: до $100 тыс. — минимальный эффект для оповещения более $300, от $100 тыс. до $250 тыс. — более $500, от $250 тыс. до $500 тыс. — более $750, свыше $500 тыс. — более $1 000. Смысл в абсолютных величинах: скачок на 900 процентов по сервису, где аккаунт тратил $0,10 и стал тратить $1,00, формально всплеск, но перерасход пренебрежимо мал. Поверх этого действуют пороги по сервисам: у AWS Glue, Amazon Athena и Amazon EC2 суточные траты законно колеблются сильнее, и под стандартные 40 процентов они давали непропорционально много ложных срабатываний, поэтому для них порог отклонения поднят до 60 процентов. Отдельный список аккаунтов пониженной чувствительности требует превысить стандартные пороги втрое, прежде чем уйдёт оповещение, — это команды с заведомо волатильными нагрузками, попросившие меньше уведомлений.

Что автоматика решить не может

CLEA видит операции, типы использования и итоговые стоимости, но не видит намерения: планировался ли рост расходов — например, развёртывание новой нагрузки или миграция — знает только владелец аккаунта. Эта граница между обнаружением и суждением постоянна, поэтому пороги настраивают по обратной связи пользователей, а не пытаются устранить её инженерией; обратная связь собирается кнопкой в приложении и призывом к действию в каждом письме с оповещением. У модели есть и структурное ограничение: адаптирующийся к тренду прогноз со временем этот тренд впитывает — устойчивый ступенчатый рост расходов отмечается первые несколько дней, а затем оседает как новый ожидаемый уровень по мере обновления обучающего окна, поэтому такой поиск аномалий сильнее всего именно на всплесках.

Отдельная бухгалтерия нужна на таком масштабе и для группировки: CLEA склеивает соседние помеченные дни в диапазоны, и логика группировки читает все исторические снимки модели, а не только последний прогон, — иначе диапазоны дробились бы каждый раз, когда Prophet переклассифицирует отдельный день между запусками.

Письмо владельцу и разбор без участия платформенной команды

Оповещения идут отдельным процессом после обнаружения: движок выбирает активные за день аномалии и дедуплицирует их, сопоставляя обнаруженную дату с текущей, так что на аномалию приходится одно оповещение; аномалии, начавшиеся в последние четыре дня, порождают письмо, более старые — только если продолжаются. В письме владелец получает идентификатор и имя аккаунта, владельцев и иерархию подразделений из метаданных BMW Group, затронутый сервис, диапазон дат и длительность аномалии, ожидаемые и фактические расходы, абсолютный эффект и процент отклонения, накопленный эффект по всем одновременным аномалиям аккаунта, а полная таблица приложена файлом Excel.

Пример, приведённый авторами, показывает уровень детализации: письмо сообщает о превышении ожидаемых расходов на $1 775,13 и отдельно оговаривает, что аномалии определяются по всплескам трат и могут содержать ложные срабатывания; в таблице — Amazon EC2, аномалия длиной в один день, ожидаемые расходы $809,30 против фактических $2 584,43, эффект $1 775,13, или 219,34 процента. Разбираться владелец может сам: в дашборде аномалий Amazon Quick Sight он видит обнаруженные аномалии своего аккаунта с теми же полями, может расширить фильтр и на те, что не попали в оповещения, а по выбранной аномалии открывается детализация — две столбчатые диаграммы разбивают фактические суточные траты по операции и по типу использования, и таблица перечисляет типы использования, формирующие стоимость, вплоть до значений вида `EUC1-InstanceUsage:db.r6g.large`. На разобранном примере в левой диаграмме доминирует `RunInstances`, а один день доходит примерно до $2 600 при базовой линии около $900, и правая диаграмма относит почти весь этот день к `EUC1-BoxUsage:g6.48xlarge`, то есть называет тип инстанса за всплеском.

Архитектура и цена

Производственный контур целиком серверный: `dbt` переразбивает данные о стоимости в Parquet-файлы уровня аккаунта — по одному на аккаунт, агрегированные по сервису и дню; запуск workflow инициируется ежедневным событием по времени; подготовительная Lambda записывает список аккаунтов в Amazon S3; каждый обработчик Distributed Map читает данные своего аккаунта по ключу; результаты аномалий пишутся в сырой слой Amazon S3 как один JSON на аккаунт; задание AWS Glue сводит их в единый суточный Parquet исходного слоя; представления Amazon Athena открывают результаты, а модели `dbt` применяют логику порогов, группировку диапазонов и разметку оповещений, после чего движок оповещений читает размеченный выход и отправляет уведомления.

Ограничения по надёжности тоже названы явно: в Distributed Map задана максимальная параллельность 500, а допуск на сбои — пять аккаунтов из примерно 14 000, что требует 99,96 процента успешных обработок за прогон. Полный цикл укладывается примерно в 20 минут, а вся конструкция обходится около $50 в месяц на вычисления — меньше половины цента на аккаунт в месяц, и, поскольку все компоненты серверные, простаивающей инфраструктуры между запусками не оплачивается. Дополнительный контекст по источнику данных: AWS CUR агрегируется по часу, дню или месяцу — по выбору заказчика.

Что дальше и что статья не доказывает

В планах — интеграция оповещений с существующей ITSM-системой, чтобы владельцы аккаунтов получали инциденты в привычных рабочих процессах, а не только письмом; передача владельцам прямого управления чувствительностью оповещений в портале рекомендаций CLEA; интеграция с AWS CloudTrail, которая показывает, какой пользователь или роль настроили сервис за подорожанием. Кроме того, команда строит агентный эндпоинт, который должен давать автоматические объяснения первопричины: что скорее всего вызвало рост расходов и что делать, чтобы остановить аномалию или не допустить её повторения.

Границы доказанного стоит держать в уме: статья описывает развёртывание внутри одной компании, все цифры — объёмы данных, пороги в долларах, стоимость контура и сроки прогона — относятся именно к окружению BMW Group и не являются независимым отраслевым бенчмарком. Приведённые эффекты, включая $1 775,13 и 219,34 процента, — иллюстрация работы оповещения на одном аккаунте, а не измеренная экономия программы.