分散トレーシングは、セルフホスト型サービス間で1つのAIリクエストをどのように追跡するのか？

分散トレーシングは、サービス境界を越えて共有されたトレース識別子を1つのAIリクエストに持たせ、関係する各操作を因果関係のあるスパンとして記録します。

セルフホスト型AIのリクエストは、ユーザーに応答が表示されるまでに、リバースプロキシ、エージェントサービス、ベクトルストア、モデルランタイム、作業キュー、ストレージサービス、ツールエンドポイントを通過することがあります。これらのコンポーネントは異なるコンテナやマシン上で動作し、独立したログを書き込む場合があるため、タイムスタンプが近いというだけでは、どの処理が1つのリクエストに属するのかを証明できません。分散トレーシングを使えば、後から推測して再構成するのではなく、処理とともにリクエストの識別子を引き継げます。

トレースによって、エンドツーエンドの1つのリクエストに共有識別子を持たせる

トレースはリクエスト全体の経路を表し、各スパンは検索、再ランキング、モデル推論、ツール呼び出し、レスポンスのシリアライズなど、範囲を限定した操作を記録します。これらのスパンが1つのトレース識別子を持てば、バックエンドは、時間的に近いイベントが因果関係にあると仮定することなく、別々のサービスで行われた処理をまとめられます。

したがって有用な単位は、平坦なタイミング一覧ではなく、つながりを持つリクエストツリーです。1つのトレースIDがサービス境界をまたげば、多数のプロセスで実行された時間計測付きの操作を、ばらばらのログレコードではなく、1つのリクエストとして再構成できます。

ホームAIスタックでは、ルートスパンがユーザー向けAPIで始まり、検索、権限確認、モデル処理、ツールへ分岐することがあります。トレースを使えば、遅かった理由を調べる前に、どの操作がこのリクエストに属していたのかを確認できます。

すべてのサービス境界でコンテキストを注入・抽出する必要がある

トレースの継続性は、各呼び出し元が現在のコンテキストを送信キャリアに注入し、各受信側が独自のスパンを作成する前にそのコンテキストを抽出することで保たれます。プロキシ、クライアントライブラリ、サービスのいずれか1つが代わりに新しいトレースを開始すると、基盤となるリクエストが正常に完了していても、エンドツーエンドの経路は途切れます。

伝播の仕組みが運ぶのは、ユーザーの業務ペイロードではなく、識別子とサンプリング状態です。注入・抽出サイクルによって、異なるサービス間でも、プロセスやネットワークの境界を越える処理に同じリクエスト識別子を引き継げます。

これは、異なる技術が混在するセルフホスト型スタックで重要です。リバースプロキシ、Pythonエージェント、ベクトルデータベース、RustまたはGoで作られたツールサービスは、伝播形式が相互運用可能である限り、同じトレーシングライブラリを使う必要はありません。

したがって、伝播の欠落は、下流サービスが独立して実行された証拠ではなく、データ品質の問題です。途切れたトレースは、識別子が失われた境界で診断すべきです。

親子関係とスパンリンクによって、異なる因果関係の形を維持する

通常、直接的な同期処理は、ある操作が次の操作を開始して完了を待つため、親子関係のチェーンになります。一方、ファンアウトや非同期ワークフローでは、より複雑な関係になることがあります。トレースモデルには、すべての下流操作を人工的に1つのコールスタックへ押し込むことなく、因果関係を維持することが求められます。

サービス呼び出しが直接入れ子になっている場合は親子エッジが有効ですが、階層構造を持たない関係のスパンリンクを使えば、以前の処理によって起動されたものの、単一のアクティブな親の下にきれいに入れ子にならない処理もつなげられます。

ホームAIのリクエストでは、検索と権限確認を並列に開始し、その両方の完了を待ってからモデル生成に進むことがあります。トレースは、先に開始したスパンがもう一方を引き起こしたかのように示すのではなく、その並列構造を維持する必要があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

キュー内のメッセージとともにコンテキストを引き継いだ場合にのみ、リクエストの追跡を維持できる

非同期キューはプロセス内の直接的なコールスタックを分断しますが、トレースコンテキストをメタデータとしてメッセージに含めれば、キューに入れられた処理を元のリクエストに関連付けたままにできます。コンシューマーはそのコンテキストを使って、後から処理を開始した時点で次のスパンを作成するか、明示的なリンクを作成します。

これは、ホームサーバーがインタラクティブなリクエスト経路から意図的に切り離すOCR、埋め込み生成、カメラ分析、通知ジョブなどで重要になります。メッセージバスでの受け渡しでは、スレッドローカル状態や直接的なコールスタックが維持されなくても、明示的な伝播によってトレース識別子を保持できます。

ZimaSpaceのホームAIに分離された作業キューが必要な理由に関する説明では、非同期処理を運用上分離する理由を解説しています。分散トレーシングは、その分離された処理を、原因となったリクエストに結び付け続ける識別子を提供します。

この識別子がなければ、遅いバックグラウンド処理が無関係なジョブに見え、運用担当者はユーザーのリクエストが実際に継続していることを見落とす可能性があります。

再構成されたトレースによって、クリティカルパスと欠落箇所が明らかになる

スパンがトレーシングバックエンドに到着すると、識別子、タイムスタンプ、親子関係、ステータス、サービスメタデータを組み合わせて、エンドツーエンドのリクエストビューを構成できます。並列処理は重なって実行される可能性があるため、最も長いスパンが必ずしもユーザーに見える遅延の原因とは限りません。重要なのは、どの依存関係のチェーンが完了を左右しているかです。

コンテキスト伝播が欠落していると、トレースは分断されます。そのため、整ったウォーターフォール表示も、それを生成した計装が完全である範囲でしか信頼できません。

サンプリングにも別の限界があります。サンプリングされなかったリクエストは、後から完全なスパンの証拠を提供できません。また、一部しか計装されていないサービスは、その他の部分が有効なトレースであっても、見えない領域を残すことがあります。したがって分散トレーシングは因果関係の可視性を高めますが、記録されていない操作のテレメトリを新たに作り出すことはできません。

1つのユーザーリクエストを、すべてのサービスログを同じデータベースに集約したり、タイミングだけで因果関係を証明しようとしたりせず、実際のセルフホスト型経路に沿って追跡できるとき、この仕組みは成功しています。