// シス担のミカタ
監視・オブザーバビリティ

分散トレーシング ぶんさんとれーしんぐ

分散トレーシングJaegerZipkinマイクロサービススパントレースID
分散トレーシングについて教えて

簡単に言うとこんな感じ！

マイクロサービスで「注文処理が遅い！」と言われたとき、どのサービスが原因か追いかけるのが分散トレーシングだよ。リクエストが複数サービスをまたいで処理される旅路を、一本の「トレース」として可視化できるんだ。

分散トレーシングとは

分散トレーシング（Distributed Tracing）とは、マイクロサービスやサーバーレスなど複数のサービスにまたがるリクエストの処理過程を追跡し、全体の流れと各処理のレイテンシを可視化する技術です。オブザーバビリティ（可観測性）の3本柱（メトリクス・ログ・トレース）の「トレース」に相当します。

モノリシックなアプリケーションであれば、スタックトレースを見ればボトルネックを特定できました。しかし、マイクロサービスでは1つのユーザーリクエストが「フロントエンド → API Gateway → 注文サービス → 在庫サービス → 決済サービス → 通知サービス」と複数サービスを通過するため、どこで遅延が発生しているかが見えにくくなります。

分散トレーシングでは、リクエスト発生時にトレースID（Trace ID）を発行し、各サービスへのリクエストヘッダーに伝播させます。各サービスは自分の処理をスパン（Span）として記録し、全スパンを集めることでガントチャート状のトレースとして可視化できます。

主要概念

用語説明
トレース（Trace）1つのリクエストの全処理を表す一連のスパンの集合
スパン（Span）単一サービス内の処理単位。開始時刻・終了時刻・タグを持つ
トレースIDトレース全体を一意に識別するID。全スパンで共有
スパンID個々のスパンを識別するID
親スパン / 子スパンサービス間呼び出しを親子関係で表現
コンテキスト伝播トレースIDをHTTPヘッダー等でサービス間に引き渡す仕組み

代表的なトレースコンテキストヘッダー

  • traceparent（W3C Trace Context標準）
  • X-B3-TraceId（Zipkin/B3形式）
  • X-Amzn-Trace-Id（AWS X-Ray形式）

歴史と背景

  • 2010年：Googleが内部論文「Dapper」を発表。分散トレーシングの概念を体系化
  • 2012年：TwitterがZipkinをOSSとして公開
  • 2016年：JaegerがUber社により開発・公開。CNCFに寄贈
  • 2016年：OpenTracing（CNCF）が分散トレーシングのAPIを標準化
  • 2018年：OpenCensus（Google発）が計装ライブラリを提供
  • 2019年：OpenTracingとOpenCensusが統合されOpenTelemetryとして一本化

分散トレースの可視化イメージ

分散トレース（ガントチャート） サービス 0ms 100ms 200ms 300ms API Gateway 290ms（ルートスパン） 注文サービス 200ms 在庫サービス 80ms 決済サービス 110ms ← ボトルネック！ 通知サービス 50ms

主要ツール比較

ツール開発元特徴
JaegerUber→CNCFOSSで機能豊富、Kubernetes環境に最適
ZipkinTwitter→OSSシンプルで導入しやすい老舗ツール
AWS X-RayAmazonAWS環境との統合が容易
Datadog APMDatadog商用。メトリクス・ログとの統合が強力
TempoGrafana LabsGrafanaと連携しコスト効率が良い

関連する規格・RFC

規格内容
W3C Trace Context（REC）traceparent / tracestate ヘッダーの標準仕様
B3 PropagationZipkinが提唱したトレースコンテキスト伝播形式

関連用語