DatabricksにおけるAIを活用した数千のデータベースのデバッグ方法

Databricksでは、手動のデータベース運用をAIに置き換え、デバッグに費やす時間を最大90%削減しました。

当社のAIエージェントは、主要な指標とログを取得し、信号を自動的に相関させることで、解釈、実行、デバッグを行います。これは、あらゆる主要クラウドおよびほぼすべてのクラウドリージョンに展開されたデータベースのフリート全体で動作します。

この新しいエージェント機能により、エンジニアは、ストレージチームのオンコールエンジニアに連絡することなく、サービスの状態とパフォーマンスに関する質問に自然言語で日常的に回答できるようになりました。

調査ワークフローを簡素化するための小さなハッカソンプロジェクトとして始まったものは、その後、会社全体で採用されたインテリジェントプラットフォームへと進化しました。これが私たちの旅です。

AI以前：すべては機能していたが、何も連携していなかった

典型的なMySQLのインシデント調査中、エンジニアはしばしば次のようなことを行っていました。

• Grafanaでメトリクスを確認する
• クライアントワークロードを理解するためにDatabricksダッシュボードに切り替える
• InnoDBステータス（トランザクション履歴、I/O操作、デッドロックの詳細などを含む内部MySQL状態のスナップショット）を調べるためにCLIコマンドを実行する
• スロークエリログをダウンロードするためにクラウドコンソールにログインする

各ツールは単独ではうまく機能しましたが、連携すると、まとまりのあるワークフローを形成したり、エンドツーエンドの洞察を提供したりできませんでした。経験豊富なMySQLエンジニアは、タブやコマンドを適切な順序で切り替えるだけで仮説を組み立てることができましたが、その過程で貴重なSLO予算と時間を消費していました。一方、経験の浅いエンジニアは、どこから手をつければよいかわからないことがよくありました。

皮肉なことに、この内部ツールの断片化は、Databricksが顧客の克服を支援するまさにその課題を反映していました。

Databricks Data Intelligence Platformは、データ、ガバナンス、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 を使用します。

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

専門知識と運用コンテキストの両方がその推論にコード化されているため、エージェントは意味のある洞察を抽出し、エンジニアを調査に積極的にガイドできます。数分以内に、エンジニアがおそらく調査を検討しなかったであろう関連ログとメトリクスを提示します。レイヤー間で症状を接続し、予期しない負荷を発生させているワークスペースを特定したり、IOPS の急増と最近のスキーマ移行を相関させたりします。根本原因と結果を説明し、軽減のための次のステップを推奨することさえします。

これらの要素を組み合わせることで、可視性からインテリジェンスへの移行を示します。ツールの可視性やメトリクスを超えて、システムを理解し、専門知識を適用し、エンジニアを安全で効果的な軽減策に導く推論レイヤーに進みました。これは、データベースだけでなく、インフラストラクチャ全体を運用する方法にも構築し続けることができる基盤です。

影響: スケールでの構築と運用の再定義

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

新しいエンジニアのインフラストラクチャに関する学習曲線も急激に低下しました。コンテキストがゼロの新規採用者でも、5 分以内にデータベース調査を開始できるようになりました。これは以前はほぼ不可能でした。このプラットフォームの立ち上げ以来、素晴らしいフィードバックを得ています。

データベースアシスタントは本当に多くの時間を節約してくれるので、クエリダッシュボードがどこにあるかをすべて覚える必要がありません。どのワークスペースが負荷を生成しているかを尋ねるだけで済みます。最高のツールです！— Yuchen Huo, Staff Engineer

私はヘビーユーザーであり、これなしで生活していたとは信じられません。洗練度と有用性のレベルは非常に印象的です。チームの皆さん、開発者エクスペリエンスの大きな進歩です。— Dmitriy Kunitskiy, Staff Engineer

特に、AI を活用した洞察をインフラストラクチャの問題のデバッグにもたらす方法を気に入っています。このコンソールを最初からそのように設計したチームの先見の明に感謝しています。— Ankit Mathur, Senior Staff Engineer

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

しかし、最も意味のある影響は、単なる作業の削減やオンボーディングの迅速化ではありませんでした。それは考え方のシフトでした。私たちの焦点は、技術アーキテクチャから、エンジニアがシステムを体験する方法を定義する重要なユーザー ジャーニー (CUJ) へと移行しました。このユーザー中心のアプローチにより、インフラストラクチャ チームは、エンジニアがカテゴリをリードする製品を構築できるプラットフォームを作成できます。

まとめ

最終的に、私たちの旅は 3 つの教訓に集約されました。

• 迅速なイテレーションはエージェント開発に不可欠です: エージェントは、迅速な実験、検証、および改良によって改善されます。DsPy に着想を得たフレームワークにより、プロンプトとツールを迅速に進化させることができました。
• イテレーションの速度は、基盤となる基盤によって制限されます: 統合されたデータ、一貫した抽象化、およびきめ細かなアクセス制御により、最大のボトルネックが解消され、プラットフォームは信頼性が高く、スケーラブルで、AI に対応できるようになりました。
• 速度は、正しい方向を持っている場合にのみ重要です: 私たちはエージェント プラットフォームを構築することから始めませんでした。各イテレーションは、単にユーザー フィードバックに従い、エンジニアが必要とするソリューションに私たちを引き寄せました。

内部プラットフォームの構築は、見かけによらず困難です。同じ会社内であっても、製品チームとプラットフォーム チームは非常に異なる制約の下で運営されています。Databricks では、顧客への執着を持って構築し、抽象化によって簡素化し、インテリジェンスによって強化することで、外部顧客と同じ注意と厳密さをもって内部顧客を扱っています。

参加しませんか

今後、AI が本番システムをどのように形成し、複雑なインフラストラクチャを楽に感じさせることができるかの境界を押し広げ続けることに興奮しています。次世代の AI パワード内部プラットフォームの構築に情熱を注いでいるなら、ぜひご参加ください!

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事