分散トレーシング｜クラウドインフラ

🎓 レベル：発展　|　重要度：B（推奨）

📎 前提：メトリクス・ログ・トレース（3本柱）　|　関連：Service・Ingress・監視とアラート設計

要点（BLUF）

マイクロサービスでは1リクエストが多数のサービスを横断する。分散トレーシングは、その**1リクエストの全経路を1本の線（トレース）**として可視化し、どこで遅延/失敗したかを特定する。
構成要素は トレース（1リクエスト全体） と スパン（各サービスでの処理区間）。スパンが親子で連なって木構造を作る。
鍵は 文脈伝播（context propagation）：サービス間呼び出しにトレースIDを引き継ぐことで、バラバラのログを1本に縫い合わせる。OpenTelemetry が標準。

概念 ── 1リクエストを1本の線に

モノリスなら処理は1プロセス内で完結し、ログを追えば分かります。しかしマイクロサービス（Service・Ingress）では、1つのリクエストが「フロント → 認証 → 注文 → 在庫 → 決済」と何台ものサービスを渡り歩く。どこか1つが遅いと全体が遅いが、メトリクス（メトリクス・ログ・トレース（3本柱））の平均値では犯人が分かりません。

分散トレーシングは、この旅路に共通のトレースIDを持たせ、各サービスでの滞在をスパンとして記録。後で1本のタイムラインに組み立てます。

flowchart TB
    t["トレース（trace_id=abc・リクエスト全体）"]
    t --> s1["スパン: フロント 5ms"]
    s1 --> s2["スパン: 認証 8ms"]
    s1 --> s3["スパン: 注文 120ms ← ここが遅い"]
    s3 --> s4["スパン: 在庫DB 110ms ← 真犯人"]

この図のように、各スパンの所要時間を見れば「注文サービスが遅く、その中でも在庫DBアクセスが支配的」と一目で分かります。

仕組み ── スパンと文脈伝播

**スパン（span）**は1つの作業単位の記録：開始/終了時刻、サービス名、操作名、親スパンID、タグ（HTTPステータス等）。スパンが親子関係で繋がり、トレースという木になります。

文脈伝播が肝。サービスAがサービスBを呼ぶとき、HTTPヘッダ等にトレースID・親スパンIDを載せて渡します（W3C Trace Context が標準）。Bはそれを引き継いで自分のスパンを子として記録。これで分散したスパンが同じトレースに集約されます。

flowchart LR
    a["サービスA（span1 を作成）"] -->|"ヘッダで trace_id と span1 を伝播"| b["サービスB（span1 を親に span2 を作成）"]
    b -->|"伝播"| c["サービスC（span3）"]
    a --> collector["コレクタが全スパンを収集・トレースに組立"]
    b --> collector
    c --> collector

実装は OpenTelemetry SDK で自動計装（フレームワークの呼び出しに自動でスパンを挿入）するのが現代的。収集先は Jaeger・Tempo・各種マネージド（要最新確認）。

トレースが見せるのは「どこで遅いか」。なぜ複数サービスで一貫性や順序が問題になるかという分散システムの理論（合意・因果順序）は分散システムへ。ここは運用での使い方に絞る。

なぜトレーシングが要るのか

平均では犯人が分からないから：メトリクスの平均レイテンシは「全体が少し遅い」としか言わない。トレースは特定リクエストの内訳を見せ、ボトルネックのサービス/クエリを名指しする。
サービス境界を越えるから：1サービスのログだけでは全体像が見えない。文脈伝播で横断的に縫い合わせて初めて全経路が見える。
アラートからの深掘り口になるから：症状ベースのアラート（監視とアラート設計）で「遅い」と気づいた後、トレースで「どこが遅いか」へ即座に降りられる。

⚠️ よくある誤解・落とし穴

「全リクエストをトレース」→ オーバーヘッドと保存費が膨大。サンプリング（一定割合 or 異常時のみ）で代表を取る。
「文脈伝播を一部サービスで落とす」→ そこでトレースが途切れ、経路が分断される。全サービスで一貫した計装が要る。
「トレースIDをログに入れない」→ トレースとログが繋がらない。ログにトレースIDを埋め、3信号を相関させる（メトリクス・ログ・トレース（3本柱））。
「独自フォーマットで計装」→ ベンダロックイン・相互運用不能。OpenTelemetry／W3C Trace Context 等の標準に従う。
「トレースを入れれば原因まで分かる」→ トレースは「どこ」を示すが「なぜ」はログ・コードで読む。3本柱の併用が前提。

対応ラボ

なし（発展トピック）。トレーシングは複数サービスと計装が前提のため参照に留める。土台のメトリクス収集はメトリクス・ログ・トレース（3本柱）のラボで体験できる（OTel Collector の追加は要最新確認）。