【ぶんさんとれーしんぐ】
分散トレーシング とは？
最終更新:
💡 マイクロサービスの「荷物追跡」
複数のサービスにまたがって処理される1つのリクエストの経路と所要時間を、共通のIDでつないで追跡・可視化する技術。マイクロサービスで遅い箇所やエラーの発生箇所を探すのに使う。
📌 このページのポイント
- 1つのリクエストが複数サービスを通過する経路と、各処理にかかった時間を可視化する
- トレースIDでリクエスト全体を、スパンIDで個々の処理単位（スパン）を識別し、親子関係でつなぐ
- サービス間ではtraceparentヘッダー（W3C Trace Context）などでIDを受け渡す
- OpenTelemetryは計装とデータ送信の共通の仕組みで、保存・表示はJaegerやZipkin、商用サービスなどのバックエンドが担う
ひよこ なぜ普通のログだけじゃダメなの？
ペンギン先生 ひよこ トレースIDとスパンIDの違いは？
ペンギン先生 トレースIDはリクエスト全体を表すID、スパンIDは各サービスの処理など1つの作業単位を表すIDだよ。スパンは「親スパン」のIDを持つから、1つのトレースの下にスパンがツリー状につながるんだ。時間軸に並べたウォーターフォール図で見ると、どのスパンに時間がかかっているかがわかりやすいね
ひよこ 次のサービスにはどうやってIDを渡すの？
ペンギン先生 HTTPならリクエストヘッダーに入れて渡すよ。標準はW3C Trace Contextのtraceparentヘッダーで、トレースIDと呼び出し元のスパンIDなどを載せるんだ。これを「コンテキスト伝搬」と呼んで、途中のサービスが受け渡しに対応していないと、トレースがそこで途切れてしまうよ
ひよこ OpenTelemetryって何？
ペンギン先生 ひよこ 導入のコツは？
もっと詳しく知りたい人へ
サンプリングするとエラーのトレースを見逃さない？
見逃すことがあるよ。リクエストの最初に記録するかを決める「ヘッドサンプリング」は簡単で軽い反面、あとでエラーになったトレースを必ず残せるとは限らない。トレースが終わってから判断する「テールサンプリング」なら「エラーを含むトレースは必ず残す」といった条件にできるけど、途中のデータを保持する分、実装と運用が難しくなるんだ。
まとめ：ざっくりこれだけ覚えればOK！
「分散トレーシング」って出てきたら「サービスをまたぐリクエストの経路と時間を、共通IDで追跡する技術」と思えればだいたいOK！
📖 おまけ：英語の意味
「Distributed Tracing」 ＝ 分散追跡
💬 Trace（追跡する）。宅配便の追跡番号のように、リクエストが「どこを通って、どこで時間がかかったか」がわかるよ