「アプリが遅い、でもどの処理がボトルネックかわからない」——そんなときに役立つのがトレーシングです。マイクロサービスや複数システムの連携が当たり前になった現在、サービス境界を越えてリクエストの流れを追跡する「分散トレーシング」の重要性がますます高まっています。この記事では、その基本的な仕組みや活用場面をわかりやすく解説します。
目次
- トレーシングとは——リクエストの流れを可視化する
- 分散トレーシングとは何か
- 分散トレーシングの仕組み
- 分散トレーシングで取得できる情報
- 分散トレーシングの活用場面
- 分散トレーシングを始めるには
- Mackerelで始める分散トレーシング
トレーシングとは——リクエストの流れを可視化する
「アプリケーションのレスポンスが遅い」という報告を受けたとき、原因を特定するにはどうすればよいでしょうか。
ログを調べればエラーの発生はわかります。メトリックを見ればCPU使用率やメモリ消費量の異常に気づけます。しかし、1つのリクエストがアプリケーション内でどのような処理を経て、どこに時間がかかっているのかを把握するには、これらだけでは不十分な場面があります。
ここで役立つのがトレーシングです。トレーシングは、リクエストが処理される流れを記録し、可視化する手法です。たとえば、あるAPIリクエストがビジネスロジックの実行、データベースクエリ、外部APIの呼び出しといった処理を経ている場合、それぞれにどれだけ時間がかかったかを一目で確認できます。
これはマイクロサービスのような分散システムに限った話ではありません。モノリシックなアプリケーションでも、リクエスト内部の処理の内訳を可視化することでボトルネックの発見に役立ちます。
現在では、マイクロサービス化や複数システムの連携（決済・認証・外部APIなど）、クラウドネイティブ環境の普及により、1つのリクエストがサービスの境界を越えて流れる構成が増えています。こうした環境で、サービスをまたいだリクエストの流れを追跡する技術が分散トレーシングです。
分散トレーシングとは何か
オブザーバビリティにおけるトレースの位置づけ
分散トレーシングを理解するうえで、オブザーバビリティ（可観測性）という考え方に触れておきましょう。
オブザーバビリティとは、システムが出力するデータを通じてその内部状態を理解できる能力のことです。単に既知の異常を検知するだけでなく、「なぜこの問題が起きているのか」という未知の問いにも答えられることが重要とされています。
オブザーバビリティでは、メトリック・トレース・ログといった主要なシグナルを収集・活用してシステムの状態を把握します。それぞれのシグナルには異なる強みがあります。
- メトリック: システムの状態を数値で集計したデータです。エラー率やCPU使用率などを時系列で追跡でき、傾向の把握やアラートの設定に向いています。
- ログ: タイムスタンプ付きのイベント記録です。エラーメッセージや処理の詳細な経過を残せますが、単体では特定のリクエストとの紐づけが弱く、サービスをまたいだ分析には工夫が必要です。
- トレース: リクエストがシステム内をどのように流れたかの記録です。各処理の親子関係や所要時間がわかるため、ボトルネックや障害箇所の特定に力を発揮します。
メトリックで「何かがおかしい」と気づき、ログで個々のイベントを確認できても、「どのサービスのどの処理で時間がかかっているのか」を横断的に追うにはトレースが必要です。分散トレーシングは、このトレースをサービス境界を越えて実現する技術です。
分散トレーシングが解決する課題
分散トレーシングとは、1つのリクエストが複数のサービスやシステムをどのように流れたかを記録・可視化する手法です。
モノリシックなシステムでもリクエスト単位の調査にトレーシングは有効ですが、ログやプロファイラで補える場面もあります。しかし、サービスが分かれている環境では、こうした手段だけでは全体像をつかめません。本番環境でしか再現しない問題や、複数のサービスが絡む遅延の原因を調べるには、サービスをまたいだ視点が欠かせません。
分散トレーシングは、こうした課題に対して、リクエストの流れを1本の線としてつなげて見えるようにしてくれます。
分散トレーシングの仕組み
分散トレーシングを支える主要な概念を見ていきましょう。
トレースとスパン
トレースは、1つのリクエストの全体像を表すデータです。ユーザーのリクエストが発生してから処理が完了するまでの一連の流れを記録します。
トレースはスパンという単位で構成されます。スパンは個々の処理を表すもので、「APIリクエストの受信」「データベースへのクエリ」「外部APIの呼び出し」といった処理がそれぞれ1つのスパンになります。
各スパンには以下のような情報が含まれます。
- 処理の名前（例:
GET /api/users、SELECT Query） - 開始時刻と終了時刻
- ステータス（成功・エラー）
- 属性（HTTPメソッド、URL、ステータスコード、SQLクエリなど）
トレースID
トレース全体を一意に識別するIDです。1つのリクエストに関わるすべてのスパンに共通のトレースIDが付与されるため、異なるサービスで生成されたスパンであっても同じリクエストに属するものとして紐づけられます。
コンテキスト伝播
分散トレーシングの要となる仕組みがコンテキスト伝播（Context Propagation）です。
サービスAからサービスBにHTTPリクエストを送る際、親のトレースコンテキスト（トレースIDや親スパンの情報）をHTTPヘッダーに載せて伝えます。サービスBはそのヘッダーからコンテキストを引き継ぎ、自身の処理を表す新しいスパンを生成します。この仕組みにより、サービスの境界を越えてもリクエストの流れが途切れずに記録されます。
親子関係とツリー構造
スパン同士は親子関係を持ちます。たとえば、サービスAのスパンが親となり、その中で呼び出されるサービスBのスパンが子、さらにサービスBから呼び出されるデータベースクエリのスパンが孫、といった具合です。
この親子関係により、リクエストの流れがツリー構造として表現されます。ツリーを視覚化したタイムラインを見れば、どの処理が順番に実行され、どの処理が並列に動いているかも把握できます。こうした表示は一般にウォーターフォールビューと呼ばれます。
分散トレーシングで取得できる情報
分散トレーシングを導入すると、具体的にどのような情報が得られるのでしょうか。
- レイテンシーの内訳: リクエスト全体の処理時間だけでなく、各サービス・各処理にかかった時間の内訳がわかります。「全体で500msかかっているが、そのうち300msはデータベースクエリに費やされている」といった分析が可能です。
- エラーの発生箇所: どのサービスのどの処理でエラーが起きたかを特定できます。エラーが発生したスパンにはステータスや関連情報が記録されるため、影響範囲の把握もしやすくなります。
- サービス間の依存関係: リクエストがどのサービスを経由しているかが可視化されます。ドキュメントには書かれていない依存関係や、想定外の通信パターンが見つかることもあるでしょう。
- ボトルネックの特定: 特定の処理に時間がかかっていることが一目でわかります。外部APIの呼び出しが遅いのか、重いデータベースクエリが原因なのか、あるいはアプリケーションコード自体の処理に問題があるのか——こうした切り分けがスムーズになります。
分散トレーシングの活用場面
分散トレーシングは、さまざまな場面で活用できます。
- 障害調査: 本番環境で「レスポンスが遅い」「エラーが増えた」といった報告があったとき、トレースを追うことで原因箇所を素早く絞り込めます。問題のあるリクエストのトレースを見れば、どのサービスのどの処理で異常が起きているかがわかるため、調査の方向性を早い段階で定められます。
- パフォーマンス改善: 定常的にトレースデータを収集・分析することで、レイテンシーの傾向やボトルネックを継続的に把握できます。「このエンドポイントは平均レスポンスタイムが徐々に悪化している」といった変化に気づき、改善につなげられます。
- デプロイ後の影響確認: 新しいコードをリリースした後、レスポンスタイムの変化をデプロイ前後で比較できます。パフォーマンスリグレッションの早期発見に役立ちます。
- システム理解: 新しくチームに加わったメンバーにとって、サービス間の連携を視覚的に理解できることは大きな助けになります。コードやドキュメントを読むだけではつかみにくいリクエストの全体像を直感的に把握できます。
分散トレーシングを始めるには
分散トレーシングを導入するには、アプリケーションに計装を施してトレースデータを生成し、それを収集・可視化するバックエンドに送る必要があります。
トレースデータの収集にはさまざまな方法がありますが、近年はOpenTelemetryを使った計装が主流です。OpenTelemetryのゼロコード計装やライブラリ計装を使えば、少ないコード変更でトレースデータの収集を始められます。
収集したトレースデータを可視化・分析するには、APMなどのオブザーバビリティツールに送ります。
Mackerelで始める分散トレーシング
Mackerelは、OpenTelemetry形式のトレースに対応しており、分散トレーシングによるリクエストフローの可視化が可能です。トレースのウォーターフォールビューでボトルネックやエラー箇所を直感的に把握できるほか、トレースを集計したサマリーグラフでリクエスト数やレイテンシーの傾向を追ったり、サービスマップでサービス間の依存関係を確認したりできます。
また、Mackerelの既存のサーバー監視・メトリック監視と組み合わせることで、インフラからアプリケーションまで一貫した監視体制を構築できます。メトリックで異常を検知し、トレースで原因を深掘りする——こうした流れをひとつのツールで実現できるのがMackerelの強みです。
分散トレーシングを始めてみたい方は、以下のドキュメントもあわせてご覧ください。
Mackerelは無料トライアルでお試しいただけます。ぜひ分散トレーシングによるリクエストフローの可視化を体験してみてください。
＼Mackerelを無料で体験／
Mackerelは、サーバーやアプリケーションの状態を可視化し、システム全体の状況を把握できるサービスです。
トライアルでは、メトリックやアラート、ダッシュボードなどの機能を実際の画面で確認しながら、Mackerelによる監視や可視化を体験できます。
14日間無料で、全機能をご利用いただけます。
