Databricksはどうやって数千のデータベースをAIでデバッグしているのか

Databricks では、手作業中心だったデータベースの運用を AI に置き換え、デバッグにかかる時間を最大 90% 削減しました。

我々の AI エージェントは、主要なメトリクスとログを取得し、それらのシグナルを自動的に関連付けることで、状態を解釈し、処理を実行し、デバッグを行います。これは、主要なクラウドとほぼすべてのクラウド リージョンにデプロイされた多数のデータベース群にわたって動作します。

この新しいエージェント機能により、エンジニアは、インフラチームの障害対応の担当エンジニアに連絡を取らなくても、サービスの健全性やパフォーマンスに関する質問に自然言語で日常的に答えることができるようになりました。

これは、調査ワークフローを簡素化するための小さなハッカソンプロジェクトとして始まった取り組みです。その後、全社で利用されるインテリジェントなプラットフォームへと進化しました。その道のりを紹介します。

AI導入前：個別のツールは機能していたが、連携してはいなかった

一般的な MySQL のインシデント調査中、エンジニアは以下のようなことをやっています

• Grafanaでメトリクスを確認
• Databricks のダッシュボードに切り替えて、クライアントのワークロードを把握
• CLIコマンドを実行してInnoDBステータス(トランザクション履歴、I/O操作、デッドロックの詳細などの情報を含むMySQL内部状態のスナップショット)を検査
• クラウドコンソールにログインし、遅いクエリーログをダウンロード

各ツールは単独では問題なく機能しましたが、組み合わせると一貫性のあるワークフローを形成できず、エンドツーエンドの知見を提供することもできませんでした。熟練した MySQL エンジニアなら、適切な順序で タブやコマンドを切り替えながら仮説を組み立てることができましたが、その過程で貴重な SLO（サービスレベル目標）バジェットと時間が消費されてしまいます。新米のエンジニアは、どこからスタートすればよいかわからないことがよくありました。

皮肉なことに、こうした社内ツールの分断こそが、Databricksがお客様とともに解決しようとしている課題そのものでもありました。

Databricks データ インテリジェンス プラットフォームは、データ、データガバナンス、AI を統合し、権限のあるユーザーがデータを理解して活用できるようにします。社内でも、エンジニアが必要としているのは同様で、インフラを支えるデータとワークフローを統合する単一のプラットフォームです。その基盤さえ整えば、AI を用いてデータを解釈し、エンジニアに次に取るべき適切なステップを導くことで、インテリジェンスを活用できます。

私たちの歩み：ハッカソンからインテリジェント・エージェントへの進化

私たちは、最初から何四半期もかかるような大掛かりなプロジェクトを立ち上げたわけではありません。全社ハッカソンで、このアイデアを小さく試してみるところから始めました。2日間で、いくつかの主要なデータベースメトリクスとダッシュボードを単一ビューに統合した簡易プロトタイプを構築しました。完成度は高くなかったものの、基本的なインシデント調査ワークフローの改善効果は即座に表れました。この結果を踏まえ、「迅速に実行し、常に顧客志向であり続けること」を開発の基本方針としました。

顧客志向によるプラットフォーム構築

さらにコードを書く前に、私たちはサービスチームへのインタビューを行い、デバッグにおけるペインポイントを洗い出しました。 浮かび上がってきたテーマはどのチームでも共通していて、ジュニアエンジニアは何から手を付ければよいか分からず、シニアエンジニアはツール群が分断されていて扱いづらいと感じていました。

実施の課題を直接見るために、私たちはオンコール・セッションに同席し、エンジニアがリアルタイムで問題をデバッグするのを観察しました。そこで特に目立ったのは、次の3つのパターンです：

• 断片化されたツール
  エンジニアは、ダッシュボード、CLI、そして調査や再起動やリストアのような操作のための手動ステップをやりくりしていました。それぞれのツールは単独で機能しますが、統合されていないため、ワークフローは遅く、ミスが起こりやすい状況でした。
• コンテキストの収集に時間を浪費
  作業時間の大半は、何が変わったのか、どの状態が"正常"なのか、誰が適切なコンテキストを持っているのかを把握することであり、肝心のインシデントの緩和そのものにはなかなか手が回っていませんでした。
• 安全な対応策が分かりにくいガイダンス
  インシデントの発生時、エンジニアはどの対応が安全で効果的か、確信が持てないことがよくありました。明確なランブックや自動化された手順がない場合、長時間の調査を行ったり、有識者を待ったりすることがデフォルトの対応になっていました。

振り返ってみると、ポストモーテム（振り返り）でこのギャップが明らかになることはめったにありませんでした。チームにデータやツールが不足していたわけではなく、溢れかえるシグナルを解釈し、安全で効果的なアクションへと導くためのインテリジェントなデバッグが欠けていたのです。

インテリジェンスに向けたイテレーション

最初のステップは、データベース調査をユースケースとして小さく始めました。初期バージョン（v1）では、デバッグ用のSOP（標準作業手順書）に沿って進める静的なエージェント型ワークフローを用意しましたが、これは効果的とは言えませんでした。エンジニアが本当に求めていたのは、手動のチェックリストではなく、その場でインサイトを得られる診断レポートでした。

私たちは、「正しいデータを集め、その上にインテリジェンスを重ねる」ことにフォーカスを切り替えました。そこから異常検知の仕組みを導入し、重要な異常は拾えるようになりましたが、それでも「次に何をすべきか」は明確には示せていませんでした。

真のブレークスルーは、デバッグの知識を体系化し、追加の質問に答え、調査そのものをインタラクティブなプロセスに変えてくれるチャットアシスタントによってもたらされました。この仕組みによって、エンジニアがインシデントをエンド・ツー・エンドでデバッグする方法は大きく変わりました。

基盤アーキテクチャ：抽象化と一元化

一歩下がって考えてみると、既存フレームワークはワークフローとデータを単一のインターフェース上に統合することは可能である一方で、AIが運用環境全体に対して推論を行うことを前提とした設計にはなっていないことに気づきました。どのエージェントも、リージョンやクラウドに固有のロジックを処理する必要がありました。また、一元化されたアクセス制御がなければ、制限が厳しすぎて役に立たないか、権限が緩すぎて安全でなくなるかのどちらかになってしまいます。

Databricksでは、数百のリージョン、8つの規制ドメイン、3つのクラウドにまたがる数千のデータベース・インスタンスを運用しているため、これらの課題はいっそう解決が難しくなります。クラウドと規制ごとの違いをうまく抽象化する堅牢な基盤がなければ、AIを統合しようとしても、以下のような避けられない障害にすぐにぶつかってしまいます：

• コンテキストの断片化：デバッグ・データがさまざまな場所に分散しているため、エージェントが一貫した全体像を組み立てるのが難しい。
• 不明確なガバナンスの境界: 一元化された認可とポリシー適用がなければ、エージェント（およびエンジニア）が適切な権限範囲内に収まっていることを保証するのが難しい。
• 低速なイテレーションループ：抽象化に一貫性がないため、AIの動作をテストして進化させることが難しく、時間の経過とともにイテレーションの速度が大きく低下してしまう。

AI開発を安全かつスケーラブルなものにするため、3つの原則を中心にプラットフォームの基盤強化に重点を置きました。

• セントラルファーストのシャーディングアーキテクチャ：グローバルな Storex インスタンスがリージョンごとのシャードをコーディネートし、機密データは各リージョンに保持してコンプライアンスを満たしつつ、単一のインターフェースを提供する。
• きめ細かなアクセス制御：チーム、リソース、RPCといった各レベルで制御をかけることで、エンジニアとエージェントが常に適切な権限の範囲内で安全に動作できるようにする。
• 統合されたオーケストレーション：既存のインフラサービス群をプラットフォーム側で統合し、クラウドやリージョンをまたいでも一貫した抽象化を提供できるようにする。

データとコンテキストを一元化できたことで、次にやるべきことは明確になりました。どうすれば、このプラットフォームを「単なる統合基盤」ではなく「インテリジェントな基盤」にできるのか、という問いです

「可視化」から「インテリジェンス」へ

統合された基盤が整備されたことで、データベース スキーマ、メトリクス、低速クエリーログの取得などの機能をAIエージェントに実装して公開することが簡単になりました。数週間以内に、私たちは基本的なデータベース情報を集約し、それについて推論し、ユーザーに提示できるエージェントを構築しました。

ここで難しかったのは、エージェントの信頼性を確保することでした。LLM は非決定論的であるため、アクセスできるツール、データ、プロンプトにどのように応答するかがわからなかったのです。これを正しく行うには、どのツールが効果的で、プロンプトにどのような文脈を含めるべきか（あるいは省くべきか）を理解するために、多くの実験が必要でした。

この迅速な反復を可能にするために、我々はMLflowのプロンプト最適化技術にヒントを得て、プロンプトをツールの実装から切り離すDsPyを活用した軽量フレームワークを構築しました。エンジニアはツールを通常のScalaクラスや関数シグネチャとして定義でき、ツールを説明する短いdocstringを追加するだけで済みます。そこから、LLMはツールの入力フォーマット、出力構造、結果の解釈方法を推測することができます。こうしてプロンプトと基盤を分離することによって、プロンプトの改善やエージェントに紐づくツールの差し替えを、構文解析やLLM接続、会話状態の管理といった下回りのインフラを頻繁に触ることなく素早く回せるようになりました。

エージェントを反復的に改善していく中で、リグレッションを招くことなく本当に性能が向上していることをどうすれば証明できるでしょうか？
この課題に対処するために、私たちは本番環境の状態をスナップショットとして取得し、そのトレースをエージェントに再生し直す検証フレームワークを構築しました。あわせて、プロンプトやツールを変更した際の応答について、精度と有用性の観点からスコアリングを行う専用の “judge” LLMを用いて評価しています。

このフレームワークによって迅速なイテレーションが可能になるため、システムやデータベースの問題に焦点を当てたエージェント、クライアント側のトラフィック パターンに焦点を当てたエージェントなど、さまざまなドメインに特化したエージェントを簡単に立ち上げることができます。この分解により、各エージェントはそれぞれの分野で深い専門知識を構築し、他のエージェントと協力しながら、より完全な根本原因分析を提供できるようになります。これはまた、データベースの枠を超え、AI エージェントをインフラストラクチャの他の部分に統合するための道を開きます。

専門知識と運用コンテキストの両方が推論に体系化されているため、当社のエージェントは有意義な知見を抽出し、調査を通じてエンジニアを積極的にガイドすることができます。数分以内に、エンジニアが調査を検討しなかったかもしれない関連ログやメトリクスを提示します。予期せぬ負荷を発生させているワークスペースの特定や、IOPS の急増と最近のスキーマ移行との関連付けなど、レイヤーを越えて症状を結びつけます。根本的な原因と結果を説明し、緩和策の次のステップを推奨します。

これらを合わせると、私たちは「可視化」から「インテリジェンス」へとシフトしたことになります。ツールやメトリクスによる可視化だけでなく、システムを理解し、専門家の知識を適用し、エンジニアを安全で効果的な緩和策へと導く「推論レイヤー」を手にしたと言えます。この基盤はデータベースだけでなく、インフラ全体の運用の在り方を変えていく土台として、今後も継続的に拡張していくことができます。

インパクト：大規模なシステムの構築と運用の在り方を再定義する

このプラットフォームは、Databricksのエンジニアのインフラとの関わり方を変えました。かつてはダッシュボード、CLI、SOPを切り替える必要があった個々のステップも、今ではチャットアシスタントが簡単に答えられるようになり、最大90% まで時間を短縮できるようになりました。

また、新人エンジニアにとっての当社インフラストラクチャの学習曲線も大幅に緩やかになりました。まったくコンテキストのない新入社員でも、今では5分以内にデータベースの調査を開始できるようになりました。これは以前はほぼ不可能だったことです。そして、このプラットフォームのリリース以来、素晴らしいフィードバックをいただいています。

データベース・アシスタントは本当に時間を節約してくれるので、クエリー・ダッシュボードがどこにあるか全部覚えておく必要がない。どのワークスペースに負荷がかかっているのかを聞けばいいだけだ。史上最高のツールです！- ユチェン・フオ、スタッフ・エンジニア

私はヘビーユーザーであり、以前はそれがない中で生活していたことが信じられない。その洗練度とユーティリティは非常に印象的だ。開発者体験における大きな飛躍をもたらしました。開発チームの取り組みに感謝します。- ドミトリー・クニツキー、スタッフ・エンジニア

インフラストラクチャの問題のデバッグに AI を活用した知見をもたらしている点が特に素晴らしいです。このコンソールをゼロから設計するにあたり、チームがその点を念頭に置いていかに先進的であったかに感謝します。— Ankit Mathur、シニア スタッフ エンジニア

アーキテクチャの観点から見ると、このプラットフォームはAI支援による本番運用という、次の進化への基盤を築くものです。データ、コンテキスト、ガードレールが統合されたことで、AI 支援による運用ワークフローに向けた次のステップとして、エージェントが復元、本番運用クエリー、構成の更新をどのように支援できるかを検討できるようになりました。

しかし、最も本質的なインパクトは、単なる作業負荷の削減やオンボーディング時間の短縮ではなく、マインドセットの転換でした。我々のフォーカスは、技術アーキテクチャから、エンジニアによるシステム体験を定義するクリティカル・ユーザー・ジャーニー（CUJ）へと移行しています。このユーザーファーストなアプローチにより、インフラストラクチャチームは、エンジニアがカテゴリをリードするプロダクトを構築可能なプラットフォームを提供できるようになります。

まとめ

最終的に、私たちの歩みは 3 つの要点に集約されました。

• エージェントの開発には、迅速なイテレーションが不可欠である：エージェントは、迅速な実験、検証、改良を通じて向上します。私たちのDsPyに着想を得たフレームワークは、プロンプトやツールを素早く進化させることで、これを可能にしました。
• イテレーションの速さはその下の基盤によって決まる: 統一されたデータ、一貫性のある抽象化、きめ細かなアクセス制御が最大のボトルネックを取り除き、プラットフォームを信頼性が高く、スケーラブルで、AI に対応したものにしました。
• スピードは、それ自体よりも「正しい方向性」があってこそ意味がある: 私たちは最初からエージェント プラットフォームの構築を目指していたわけではありません。各イテレーションでユーザーからのフィードバックにシンプルに従うことで、エンジニアが必要としていたソリューションへ自然に近づいていきました。

社内プラットフォームの構築は、一見した印象に反して難易度の高い取り組みです。同じ企業内であっても、製品チームとプラットフォームチームはまったく異なる制約のもとで活動しています。Databricks では、顧客志向を軸にした開発、抽象化による簡素化、インテリジェンスによる高度化を通じてこのギャップを橋渡しし、社外顧客と同等の配慮と厳密さをもって社内顧客を扱うことを重視しています。

採用情報を見る

今後も、AI が本番運用を形成し、複雑なインフラを簡単に感じさせる可能性を押し広げ続けることを楽しみにしています。次世代の AI を活用した社内プラットフォームの構築に情熱をお持ちでしたら、ぜひ私たちと一緒に働きましょう！