Tech Learning Daily

メトリクスは「遅くなった」は分かっても「誰が遅いか」は分からない

メトリクスとは、一定期間の測定値をカウンタ・ゲージ・ヒストグラムなどの数値として集計したデータのことだ。リクエスト数・エラー率・レイテンシの分布といった値を数秒〜数十秒おきに記録し、時系列として保存する。この集計というステップこそが要点で、個々のリクエストが「誰の何のリクエストだったか」という情報はここで捨てられる。捨てるからこそ、1 秒間に数万リクエストをさばくサービスでも保存コストを抑えたまま常時収集し続けられる。

ここで「ラベルを足せば個々のリクエストまで追えるのでは」と思うかもしれない。しかしラベルの値の組み合わせは、それぞれ独立した新しい時系列として保存される。この組み合わせの種類数をカーディナリティと呼ぶ。エンドポイントやステータスコードのように取りうる値が少ないラベルなら問題にならないが、ユーザー ID やリクエスト ID のように値が事実上無限に増え続けるラベルを付けると、時系列の数がリクエストの数だけ増殖してしまう。Prometheus の公式ドキュメントは、値の種類が絞られていないラベル（ユーザー ID やメールアドレスなど）をラベルに使わないよう明記しており、カーディナリティを低く保つことをメトリクス設計の基本としている。つまりメトリクスは「個々のリクエストを追えないように」設計上わざと粗くされている道具なのだ。

ログは詳細を持つが、サービスをまたぐと点でしかない

ログとは、ある時点で起きた出来事をテキストとして記録したものだ。エラーメッセージ、スタックトレース、リクエストのパラメータなど、メトリクスが捨てた文脈をそのまま保持できる。OpenTelemetry のドキュメントも、本番環境ではフィールドが決まった構造化ログを推奨している。スキーマが安定していれば機械的にパース・相関・大量分析ができるからだ。

問題は、1 つのリクエストが複数のサービスをまたぐ構成では、各サービスが自分の都合でログを吐いているだけだという点にある。API サーバーのログと、その先の認可サービスのログと、さらに先の DB プロキシのログは、それぞれ別のファイルや別のログ基盤に独立して記録される。タイムスタンプが近いというだけでは、それらが本当に同じ 1 件のリクエストに属するログなのか確証が持てない。同時刻に他のユーザーのリクエストも大量に処理されているからだ。

トレースは trace-id で「1 リクエストの旅」をつなぎ合わせる

トレースとは、1 つのリクエストがシステム内を移動する経路を、スパン（処理の最小単位。開始・終了時刻と、どの処理から呼ばれたかという親子関係を持つ）の集まりとして記録したものだ。OpenTelemetry のドキュメントは、同じトレースに属する全スパンが共通の trace-id を持ち、親スパンの ID を通じて呼び出し階層を表現すると定義している。

この trace-id をサービス間で受け渡す標準形式が W3C の Trace Context 仕様が定める traceparent ヘッダーだ。

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

ハイフン区切りで「バージョン」「trace-id（トレース全体で不変）」「親スパンの ID」「サンプリング等のフラグ」の 4 つを持つ、ただのテキストの HTTP ヘッダーである。仕様上、このヘッダーを受け取ったサービスは次の呼び出し先にも転送する義務があり、転送のたびに自分のスパン ID に更新してよいが、trace-id だけは書き換えずに引き継ぐ。特別なプロトコルではなく、curl でも手で付け外しできる普通のヘッダーだという点が重要だ。

┌──────┐   ┌──────┐   ┌──────┐
│ API  │──▶│ Auth │──▶│  DB  │
└──────┘   └──────┘   └──────┘
 span A      span B      span C
 └──── trace-id は全区間で共通 ────┘

三者を結びつけるのは、ログに埋め込まれた trace-id

実際の障害調査は、3 つを順番に乗り換えていく形で進む。まずメトリクスのアラートで「p99 レイテンシが閾値を超えた」という異常の発生と大まかな範囲（どのエンドポイントか）を知る。次に、その時間帯・そのエンドポイントに絞ってログを検索し、遅いリクエストや失敗したリクエストの詳細を探す。ここでログの各行に trace-id が埋め込まれていれば、その 1 行から「このリクエストのトレースを開く」という操作ができ、そこで初めて API・認可・DB のどのスパンが時間を食っていたのかが、スパンの親子関係と所要時間の内訳として見える。

つまり trace-id は、メトリクスが持たない個々のリクエストの識別子を、ログとトレースの双方に共通の鍵として持たせる仕組みだ。ログに trace-id を出力するようアプリケーションを計装しておかない限り、アラートで気づいた異常と、その原因となった具体的なリクエストの経路とは、決してつながらない。