Миграция Datadog с помощью ИИ: затраты на БД упали на 90%

Почему Stream Router перерос свое хранилище ключ-значение

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

Все началось с исправления старой проблемы. В 2016 году маршрутизацию вели через файл конфигурации из трех строк, который вырос до тысяч строк, правимых вручную. Stream Router заменил его сервисом gRPC, чей путь записи работал на FoundationDB с моделью ключ-значение.

По мере роста таблицы маршрутов критические операции упирались в ограничения FoundationDB на размер транзакции. Самые требовательные шли до 45 минут из-за тысяч последовательных обращений туда и обратно. Маршруты, потоки, стратегии шардирования и правила по природе реляционные, поэтому код вытягивал десятки тысяч записей в процессы подов и вел себя как реляционная база данных внутри процесса.

Что Datadog изменил в модели данных

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

Переход сделала возможным высокая модульность: новый Stream Router реализовал тот же API на PostgreSQL вместо FoundationDB, и в остальных местах ничего менять не пришлось. Оставалось отрефакторить всю кодовую базу со старой модели на новую, и тут команда подключила Claude и Cursor.

Как Claude и Cursor работали метод за методом

Модели работали в жестком цикле, а не сами по себе. Инженер Арнольд Уоким описал это так.

«Они не генерировали код автономно: для каждого метода мы давали старую реализацию, новую схему и падающий тест». Арнольд Уоким, инженер Datadog

Модели делали первый вариант, а тесты решали, верен ли он. Работа шла в три этапа: сначала Claude описывал замысел каждой ключевой функции; затем инженеры писали точечные запросы для исправления падающих тестов, указывая ожидаемое поведение и контекст с первого шага; наконец, новый сервис вышел в продакшен по схеме blue/green.

Как команда защитила живой трафик

Безопасность в продакшене обеспечил одновременный запуск обеих систем. Два независимых экземпляра Stream Router, один на PostgreSQL и один на FoundationDB, обрабатывали одни и те же запросы, а флаги функций переключали клиентов между ними. Сервис-валидатор в каждом кластере сравнивал ответы маршрутизации и сразу оповещал команду, если они расходились.

Где модели не справились

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

Что дала миграция

Измеренные результаты принадлежат самой компании. Операции, которые занимали 45 минут, сократились до секунды, а задержки упали от сотен миллисекунд до нескольких. Хранилище данных стало меньше в 40 раз, снизилась нагрузка на процессор и память, затраты на базу упали на 90%. Datadog говорит, что без ИИ-инструментов не закончила бы реализацию за отведенное время.

Что это говорит командам, которые планируют рефакторинг с ИИ

Для инженерной организации задача здесь большой повторяющийся рефакторинг боевого кода с дедлайном. Миграция Datadog с помощью ИИ подсказывает, где сидит ценность: модели ускорили набор кода, а набор тестов, модульная архитектура и валидатор, работающий рядом, сделали скорость безопасной. Уоким делает вывод, что сила набора тестов определила, насколько команда могла доверять коду от ИИ. Команда без такого набора получила бы тот же код быстрее и без способа узнать, верен ли он.

Вопросы и ответы

Как Datadog использовал Claude и Cursor при миграции?

Для каждого метода инженеры давали моделям старую реализацию, новую схему и падающий тест. Модели писали первый вариант, а тесты показывали, верен ли он.

Какие результаты дала миграция на PostgreSQL?

Datadog говорит, что операции сократились с 45 минут до секунды, задержки упали от сотен миллисекунд до нескольких, хранилище уменьшилось до 40 раз, а затраты на базу упали на 90%.

Чего не смогли ИИ-модели?

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