分散トレーシングは『どこで遅いか』の唯一の答え
マイクロサービス化が進むと、リクエストが複数サービスを経由してレイテンシが膨らみます。本記事では編集部の視点で、分散トレーシングを公開情報をもとに整理します。Observability 実践 もご参考に。
OpenTelemetry の基本
(1) 3つの柱：traces / metrics / logs。(2) SDK + Auto-instrumentation：手間を最小化。(3) Collector：データの集約と転送。(4) OTLP プロトコル：標準化された送信形式。(5) ベンダー非依存：Datadog / New Relic / Honeycomb / Tempo へ自在に。Datadog 活用ガイド も合わせて。
Span / Trace / Context の理解
(1) Trace：1リクエストの全工程。(2) Span：1つの操作(HTTP呼び出し/DBクエリ等)。(3) Parent-Child 関係：呼び出しツリーを形成。(4) W3C Trace Context：サービス間で ID を伝播。(5) Baggage：任意の属性をリクエスト間で運ぶ。
サンプリング戦略
(1) 全量採取はコスト爆発：1%〜10% が現実的(規模依存)。(2) Head-based：開始時にサンプリング判定。(3) Tail-based：完了後に判定(エラー/遅いものを優先保持)。(4) 確率サンプリング：固定比率。(5) ルールベース：エンドポイント/ユーザー単位で調整。
ボトルネック特定の手順
(1) 遅いトレースをフィルタ：p95/p99 ベース。(2) Span の hot path を見る：時間の長い span。(3) DB クエリ確認：N+1 や Lock 待ち。(4) 外部API待ち：タイムアウト/リトライ確認。(5) 修正→計測→比較：改善効果を数値化。
本番運用の注意
(1) 個人情報の混入禁止：span attribute に注意。(2) サンプル率の動的調整：流量に応じて。(3) Collector の冗長化：単一障害を避ける。(4) コスト監視：保存量・ベンダー課金。(5) SLI/SLO との連携：トレースから自動アラート。マイクロサービス設計 もご参考に。
失敗しがちなパターン
(1) Trace Context を伝播し忘れ：サービス間で trace が切れる。(2) 個人情報を span に保存：監査対象に。(3) サンプル率を高くしすぎる：ストレージ費用爆発。(4) 属性が多すぎ：1 trace 数MBで送信不能。(5) 導入したまま放置：レビュー文化が育たず形骸化。対策は、(1)Auto-instrumentation+確認、(2)属性除外ルール、(3)Tail-based + 確率併用、(4)属性数の上限、(5)障害対応で必ず参照、です。