Опыт Datadog: безопасная миграция хранилища Stream Router с FoundationDB на PostgreSQL и DuckDB при поддержке Claude и Cursor
Инженерная команда компании Datadog поделилась практическим опытом масштабного рефакторинга слоя хранения управляющего сервиса Stream Router. Нагруженная система, обрабатывающая решения о маршрутизации потоков метрик в платформе с объемом свыше 100 триллионов событий в сутки, столкнулась с жесткими лимитами производительности своей исторической базы данных FoundationDB.
Решение задачи потребовало полной смены модели данных — перехода от нереляционного хранилища пар «ключ-значение» (Key-Value) к полноценным реляционным СУБД PostgreSQL и DuckDB. При этом миграция проводилась под живым продакшен-трафиком без остановки обслуживания пользователей. Решающую роль в ускорении переписывания кода сыграли инструменты искусственного интеллекта (Claude 3.5 Sonnet и Cursor), использованные в строго управляемом тестовом цикле.
Назначение Stream Router и кризис масштабирования Key-Value модели
Сервис Stream Router представляет собой внутренний control plane платформы Datadog. Он не передает сами метрики напрямую, но отвечает на критический вопрос для каждого входящего точечного измерения: в какой кластер Apache Kafka, топик и партицию данные должны быть записаны продюсерами и откуда их должны вычитывать консьюмеры.
Первоначальная архитектура системы, заложенная в 2016 году, использовала распределенную базу данных FoundationDB на пути записи (write path). Данные о маршрутизации экспортировались в виде снэпшотов в объектное хранилище и загружались в оперативную память дистрибьюторов чтения с использованием встраиваемой БД RocksDB.
По мере роста платформы Key-Value модель начала сбоить:
- Отсутствие реляционных связей: маршрут (Route) ссылается на стратегию шардирования и стрим, а правила (Rules) ссылаются на маршруты. В KV-модели приложению приходилось вычитывать десятки тысяч записей в память пода и вручную воссоздавать реляционный граф, выполняя работу СУБД.
- Превышение размера транзакций: крупные административные операции объединения правил стали выходить за пределы жесткого 10-мегабайтного лимита транзакций FoundationDB.
- Проблема паттерна доступа: попытка прямым ходом заменить FoundationDB на PostgreSQL с сохранением старого KV-кода показала, что вызовы выполняют тысячи последовательных сетевых RTT, а одна операция занимает до 45 минут.
Архитектурный переход: PostgreSQL для транзакций и DuckDB для памяти
Инженеры Datadog спроектировали новую реляционную схему данных, где сущности (Streams, Sharding Strategies, Routes, Rules) связаны явными внешними ключами (Foreign Keys), а ограничения целостности соблюдаются на уровне СУБД.
Для слоя записи выбор пал на управляемую платформу PostgreSQL. Для слоя чтения требовалась встраиваемая в процесс СУБД с быстрым стартом из снимков памяти. Рассматривался вариант SQLite, но от него отказались из-за отсутствия нативной поддержки массивов (Array Columns).
В результате в качестве движка чтения выбрана DuckDB. Эта СУБД имеет развитую поддержку типов массивов и SQL-диалект, практически совпадающий с PostgreSQL. Это позволило команде использовать единый слой формирования SQL-запросов для обеих СУБД, избежав дублирования бизнес-логики.
Фундамент безопасности: модульность, тесты и Blue/Green валидаторы
Применение ИИ-агентов для генерации кода критической системы стало возможным только благодаря наличию трех архитектурных гарантий:
- Модульная изоляция (Controller Interface): весь код работы с хранилищем был спрятан за единым абстрактным интерфейсом Controller. Создание нового хранилища сводилось к написанию второй реализации интерфейса без изменения остальной системы.
- Сплошное тестовое покрытие: каждый метод интерфейса именовал четкие инварианты и проверялся интеграционными тестами. Падающий тест служил бинарным критерием правильности сгенерированного ИИ кода.
- Параллельная валидация (Blue/Green Infrastructure): в продакшене были подняты две параллельные цепочки сервиса (старая на FoundationDB и новая на PostgreSQL/DuckDB). Специальный сервис-валидатор непрерывно сравнивал ответы маршрутизации между двумя контурами на реальном трафике.
Картографирование кода и метод-за-методом рефакторинг с ИИ
Процесс рефакторинга был разделен на два этапа:
На первом этапе модель Claude применили для построения структурной карты старого кода. Модели передавался монструозный метод старого KV-контроллера и давалось задание составить Markdown-документ с описанием бизнес-цели и охраняемых инвариантов, а не построчного кода.
На втором этапе инженеры запускали цикл разработки для каждого метода. В контекст ИИ-редактора Cursor (Claude 3.5 Sonnet) подавались:
- Составленный на этапе 1 документ бизнес-цели метода;
- Новая реляционная схема PostgreSQL/DuckDB;
- Падающий интеграционный тест.
Модель генерировала первую реализацию метода, а интеграционные тесты мгновенно показывали ошибки в пограничных случаях. В среднем для каждого метода требовалось 2–3 итерации уточнения контекста.
Пошаговый чек-лист инженерной миграции критического хранилища
Для проведения безопасной миграции СУБД без простоя рекомендуется следующий пошаговый порядок действий:
- Выделение слоя данных: зафиксируйте интерфейс доступа к хранилищу (Storage Boundary) и изолируйте вызовы баз данных от бизнес-логики приложения.
- Проектирование схемы: нормализуйте схему данных с явными внешними ключами (FK) и индексами в соответствии с реальными связями сущностей.
- Создание эталонного тестового пакета: напишите интеграционные тесты для каждого метода интерфейса хранилища, проверяющие состояние базы после операции.
- Настройка Blue/Green инфраструктуры: разверните параллельный контур новой СУБД и подсоедините автоматически сравнивающий ответы валидатор.
- Итеративный рефакторинг методов: переписывайте методы по одному, подгружая в ИИ-контекст описание бизнес-цели, схему и падающий тест.
- Постепенный перевод трафика: включайте чтение и запись в новую СУБД через канареечные флаги (Feature Flags) при нулевом расхождении в ответах валидатора.
Уроки Datadog: граница между возможностями LLM и человеческим контролем
Опыт Datadog показывает, что ИИ-инструменты крайне эффективны в выполнении рутинных механических задач: написании шаблонов SQL-адаптеров, трансформировании типов данных и ускорении отладки.
Однако стратегические решения — проектирование реляционной схемы, выбор подходящих СУБД (PostgreSQL и DuckDB), построение валидационной инфраструктуры и определение границ ответственности транзакций — остаются в зоне глубокой компетенции инженеров. Доверив ИИ генерацию кода под защитой тестов, команда выполнила сложнейшую миграцию в сжатые сроки без единого сбоя в продакшене.