Article by: Rohan Agarwal
デバッグは、すべての開発者にとって常に付きまとう課題であり、たとえAIがコードを書くようになったとしても、その負担が増す可能性さえあります。Sentry のようなツールは、長年にわたりエンジニアが問題を追跡し、デバッグを行う際に支援してきましたが、新たなAIツールを活用することで、こうしたプロセスをさらに迅速かつ容易にできる点が魅力です。
もちろん、Sentry から例外のスタックトレースをコピーして ChatGPT に貼り付けることも可能です。しかし、もし本当に賢いものが欲しいとしたら、どうでしょうか。AI が最善の仕事をするために、より多くのコンテキストを持ち、分散システムを深く理解し、本番環境でそれらをデバッグする能力を備えたものがあればどうでしょうか。
本記事では、私たちがどのようにして、トレーシングの力を活用して、Sentry の本番レベルの AI デバッグアシスタント「Seer」を構築したのかを説明します。
AI によるデバッグの欠点はどこにあるのか？
Seer とその Autofix 機能は、Sentry のIssues 詳細とコードベースとの緊密な統合を活用することで、問題の根本原因を突き止め、修正するための優れたツールとなっています。Autofix は開発者と協働しながら、問題の根本をより深く理解し、効果的な解決策を計画し、さらにはそれを修正するプルリクエストの下書きまで作成します。さらに、リグレッションを防ぐための単体テストも含まれます。これまでのところ、その裏側では主に Sentry のスタックトレースやパンくずリスト、そしてコードベース検索に依存して知見を得ていました。実際、Autofix はすでに数多くの開発者を助けており、さまざまなアプリケーションのバグを修正してきました。 Autofix 自身のバグさえもです。
しかし時には、Autofix が的を外してしまうこともありました。たとえば、フロントエンドから報告された「500 Internal Server Error」に対して Autofix を実行しても、バックエンドでの問題を特定することはできません。あるいは、2つのマイクロサービス間で認証の問題が発生した場合、Seer には実際に何が起きているのか把握できませんでした。さらに、複雑なアプリケーション全般においては、エラーの発生源となっているモジュールがどのように、なぜ利用されているのかについて、ほとんど理解できていませんでした。
ここで登場するのがトレースです。トレースを使うことで、Seer はマルチサービスシステム全体のフロー（フロントエンドとバックエンドといった複数階層を持つソリューションや、さまざまなマイクロサービスを利用するものを含む）、関連するエラー、エラー発生前後に実行された正確な処理（さらにプロファイリングを有効にすれば正確な関数呼び出しまで）を明確に把握できます。これにより Seer は、プロジェクトやリポジトリをまたいだ問題を非常に速く分析し、現実世界でエンジニアが直面する最も複雑な問題の一部を自律的にデバッグできるようになります。それに比べて、チャットボットにコピー＆ペーストするだけでは表面をなぞるに過ぎません。
トレースとは何か？どう活用できるのか？
すでに内容をご理解いただいている場合は、このセクションをスキップしていただいて構いません。そうでない場合は、ここで簡単にご説明します。
トレースとは、アプリケーションおよびその関連サービスを通じてリクエストがどのように流れるかを記録し、データの移動経路や潜在的な問題の発生箇所を可視化する仕組みです。トランザクションやリクエストに関与するイベントのシーケンスを追跡することで、分散システムにおけるパフォーマンスのボトルネック、エラー、依存関係などを特定するのに役立ちます。
トレース内の各ステップは「スパン」と呼ばれ、データベースクエリ、API呼び出し、関数の実行などの作業単位を表します。これらのスパンを組み合わせることで、初期リクエストから最終レスポンスまでの全トランザクションの経路を、包括的に視覚化することができます。トレースは複雑なマイクロサービスアーキテクチャのデバッグおよび最適化において、特に高い価値を発揮します。
Sentry を使えば、トレースを簡単に始められます。アプリに Sentry SDK を追加すると、多くの部分が自動的にインスツルメントされ、後からカスタムのスパンや属性を任意でインスツルメントすることもできます。たとえば Python では、SDK で標準的なトレーシング収集を有効にするために必要なのは、次のような作業だけです。
ステップ1：Seer に最初のプロンプトでシステム全体のコンテキストを与える
まず私たちの目標は、Seer にシステム全体の構造、サービス間の相互作用、Autofix によるデバッグを支援する関連問題についての洞察を与えることでした。幸いにも、これを実現するために必要なデータはすべて Sentry に揃っています。ただし、その量は膨大です。トレースには複数のサービスにまたがる数百、場合によっては数千ものスパンが含まれており、その多くは問題に直接関係していない可能性があります。こうしたトレースを大規模言語モデルに入力する際、混乱し無限の行き止まりに迷い込まないようにするにはどうすればよいのでしょうか。
幸いなことに、Sentry のトレースには「トランザクション」と呼ばれるサービス境界の概念があり、これによって絞り込みが可能になります。トランザクションには、ページ遷移、エンドポイント呼び出し、アプリケーション内のその他の大きな作業単位などが含まれます。これを使って、Seer のために凝縮されたシステム全体の概要（入れ子状かつ相互に接続されたトランザクションのツリー）を構築できました。また、そのトランザクション内で発生した関連エラーイベントも付け加えることができます。
このツリー型データ構造を構築した後、それを LLM に入力できるテキストとして整形できます。
すぐに Autofix は、自身がデバッグしている問題の周囲にあるコンテキストをより把握するようになり、より正確な根本原因を突き止め、より効果的な解決策を見つけられるようになりました。
ステップ2：必要に応じて Seer がさらに深掘りできるようにする
大まかな概要は良い出発点ですが、豊富で細かなデータをすべて捨ててしまうべきではありません。いつ役に立つかわからないのですから。問題解決の際にどの情報が必要かを判断するのに最も適しているのは AI です。そのため、私たちの解決策は、AI が必要に応じて自由に使えるツールを与えることでした。
最初に Seer に与えたツールは、関連するエラーを調べられるようにするものでした。高レベルのトレースツリーには、トレース内の他のエラーが名前と ID で記載されているため、Autofix はその ID を入力して、そのエラーのスタックトレースやその他のIssue データを確認できます。例えば、フロントエンドで InternalServerError が発生した場合、Seer はバックエンドで実際にどのようなエラーが起きたのか、それがどこで発生したのか、なぜ起きたのかを正確に確認できるようになりました。
同様に、Autofix にトレースツリーからトランザクション ID を入力させ、そのトランザクションに含まれるスパンを表示できるようにしました。システム内で何が起きたのかについて、より細かなデータが役立つ場合には、そのデータを利用できるようになっています。
最後に、CPU プロファイルを表示するためのツールを作成しました。任意のトランザクションには、その実行時に呼び出された関数とその実行時間を正確に記録したプロファイルが付随している可能性があります。これは Seer がバグを再現する上で極めて貴重な情報となり、さらにプロファイル ID を入力するためのツールを 1 つ追加するだけで実現できました。
ステップ3：これらの機能を日々のデバッグに活用する
これらの機能を Seer に組み込み、Sentry が提供するデータ一式を活用できるようにしたところで、次は開発者がそれを実際に使えるようにする段階になりました。そこで私たちは設定ペインを導入し、ユーザーが各 Sentry プロジェクトごとに Seer に利用可能とする関連リポジトリを選択できるようにしました。これにより、Autofix はリポジトリ全体を横断して検索できるようになります。そして一度アクセスが許可されれば、プロジェクトをまたいでトレースを活用することで、Autofix は特定の問題に対してどのリポジトリを分析すべきかを自動的に推定できるようになります。
このトレースに関連するコンテキストのすべてのおかげで、Autofix はサービスを横断する問題をデバッグできるようになり、さらには複数のリポジトリに同時にプルリクエストを作成することも可能になりました。
実際の例として、Sentry のバックエンドと Sentry の AI マイクロサービスである Seer の間で認証の問題が発生していました。これは長年続いていた問題でしたが、Autofix は私たち自身が苦労してきた根本原因を見つけ出し、それぞれのリポジトリに修正のためのプルリクエストを作成することに成功しました。過去には、同様の問題を手作業で解決するのに 2〜3 日かかっていました。
デバッグは難しくなくていい
Seer は、本来であれば簡易的で表面的な根本原因の特定やコード修正のためのツールにとどまっていたかもしれません。しかし、トレースが提供する深いコンテキストによって、私たちはそれを最も難しいバグでさえデバッグできる、強力で有能なアシスタントへと進化させました。複数の分散サービスを持つ複雑なアーキテクチャにおいても同様です。そして、スタックトレース、ブレッドクラム、HTTP リクエスト、プロファイルなど、Sentry の他のあらゆるコンテキストと緊密に統合することで、AI を用いた本番システムのデバッグがついに現実のものとなりました。
Autofix を是非試してみてください。
Original Page : Sentry’s AI debugger now references traces for troubleshooting distributed systems
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
