DatadogのAI支援の移行、DBコストを90%削減

Stream Routerがキーバリューストアに収まらなくなった理由

Datadogの課題は、ボトルネックになったルーティングサービスでした。Stream Routerは社内のコントロールプレーンで、プロデューサーにはメトリクスデータの書き込み先を、クエリ側には読み取り先を伝えます。1日に100兆件を超えるイベントを処理するプラットフォームで、各データポイントのKafkaクラスター、トピック、パーティションを選びます。

始まりは、より古い問題への対処でした。2016年、ルーティングは3行の設定ファイルで管理されていましたが、それが手作業で編集される数千行にまで膨らみました。Stream RouterはそれをgRPCサービスに置き換え、書き込み経路はキーバリューモデルを使うFoundationDBで動いていました。

ルーティングテーブルが大きくなるにつれ、重要な処理がFoundationDBのトランザクションサイズの上限に達しました。最も負荷の高い処理は、数千回の逐次的な往復のために最大45分かかりました。ルート、ストリーム、シャーディング戦略、ルールは本質的にリレーショナルなので、コードは数万件のエントリをポッドのプロセスに読み込み、プロセス内でリレーショナルデータベースの役割を果たしていました。

Datadogがデータモデルで変えたこと

解決策はリレーショナルなスキーマでした。エンジニアはこれらのエンティティ間の関係を軸にデータモデルを設計し直し、アプリケーションのコードが手作業で再構築していたルールを、PostgreSQLの外部キーで強制できるようにしました。

強いモジュール性が切り替えを可能にしました。新しいStream Routerは、FoundationDBの代わりにPostgreSQLで同じAPIを実装し、他の場所に変更は不要でした。残った仕事は、コードベース全体を古いモデルから新しいモデルへリファクタリングすることで、そこでチームはClaudeとCursorを投入しました。

ClaudeとCursorがメソッドごとにどう働いたか

モデルは自律的にではなく、密なループの中で働きました。エンジニアのArnold Wakimはこう説明しています。

「モデルは自律的にコードを生成していたわけではありません。メソッドごとに、古い実装、新しいスキーマ、失敗するテストを渡しました。」 — Arnold Wakim、Datadogエンジニア

モデルが最初の案を出し、それが正しいかどうかはテストが決めました。作業は3つの段階で進みました。まずClaudeが各主要関数の意図を説明し、次にエンジニアが、失敗するテストを直すための的を絞ったプロンプトを、期待する動作と最初の段階の文脈を添えて書き、最後に新しいサービスをブルー/グリーン構成で本番に投入しました。

チームが稼働中のトラフィックを守った方法

本番の安全性は、両方のシステムを同時に動かすことで確保されました。PostgreSQLを裏に持つものとFoundationDBを裏に持つものの2つの独立したStream Routerのインスタンスが同じリクエストを処理し、フィーチャーフラグでクライアントを両者の間で移しました。各クラスターのバリデーターサービスがルーティングの応答を比較し、食い違うとチームにすぐ警告しました。

モデルが及ばなかった点

モデルには明確な限界があり、Wakimがそれを挙げています。より抽象的なプロンプトはうまく機能しませんでした。Claudeは正しい結果を返すものの、必要以上に多くの往復を発行するクエリを書き、バッチ処理、UNNEST、共通テーブル式といった最適化には人の手が必要でした。エンジニアが最適化したパターンを書くと、モデルはその後のメソッドでそれを繰り返しましたが、自分で見つけることはありませんでした。トークンの使用量も多くなりました。チームが、切り詰めた抜粋ではなくテスト出力の全文をループに渡したためです。

移行がもたらしたもの

測定された結果は同社自身のものです。45分かかっていた処理は約1秒に、レイテンシーは数百ミリ秒から数ミリ秒に下がりました。データの保存容量は最大40倍小さくなり、CPUとメモリの使用量は減り、データベースのコストは90%下がりました。Datadogは、AIツールがなければ、限られた時間内に実装を終えられなかっただろうとしています。

AI支援のリファクタリングを計画するチームに示すこと

エンジニアリング組織にとっての課題は、期限のある中で、本番コードの大規模で反復的なリファクタリングを行うことです。DatadogのAI支援の移行は、価値がどこにあるかを示しています。モデルは入力を速くし、その速さを安全にしたのはテストスイート、モジュール化された設計、並行して動かすバリデーターでした。Wakimは、テストスイートの強さが、AIが生成したコードをどこまで信頼できるかを決めたと結論づけています。そのスイートのないチームは、同じコードをより速く得られても、それが正しいかどうかを知る手段がありません。

よくある質問

Datadogはこの移行でClaudeとCursorをどう使いましたか?

メソッドごとに、エンジニアが古い実装、新しいスキーマ、失敗するテストをモデルに渡しました。モデルが最初の案を書き、テストがそれが正しいかを示しました。

PostgreSQLへの移行でどんな結果が出ましたか?

Datadogによると、処理は45分から約1秒に、レイテンシーは数百ミリ秒から数ミリ秒に下がり、保存容量は最大40倍小さくなり、データベースのコストは90%下がりました。

AIモデルにできなかったことは何ですか?

正しいが遅いクエリを書きました。バッチ処理、UNNEST、共通テーブル式には人間のエンジニアが必要で、モデルはそれらのパターンを見た後にだけ再利用しました。