LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

分散トレーシングとは——1つのリクエストが複数サービスをまたぐ時代の課題

分散トレーシング（distributed tracing）とは、1つのリクエストがマイクロサービス等の複数プロセス・複数サービスを経由する経路を追跡し、どこで時間がかかり、どこで失敗したかを可視化する手法を指します。OpenTelemetryの公式ドキュメントでは、トレースは「リクエストがアプリケーション内を通る経路」を表すものと定義されており、モノリシックなシステムから複雑なマイクロサービス環境まで、リクエストの全体像を把握するために不可欠だとされています^*1。

マイクロサービス構成では、1つのAPIリクエストが認証・在庫・決済など複数のサービスを順に経由することが珍しくありません。各サービスが個別にログを出力するだけでは、あるリクエストがどのサービスで遅延したのか、どのサービスで例外が発生したのかを追うのに時間がかかります。サービスごとのログを1件ずつ照合する作業は、サービス数が増えるほど負担が大きくなります。

分散トレーシングは、リクエスト単位で発行した識別子を全サービスに伝播させ、各サービスの処理区間（スパン）を1つのトレースとして束ねることでこの課題に対応します。可観測性の3本柱（メトリクス・ログ・トレース）のうち、サービス間の因果関係と処理時間の内訳を扱うのがトレースの役割です。

トレースとスパン——OpenTelemetryが定義する基本単位

OpenTelemetryは分散トレーシングを含む可観測性データの計装・収集・エクスポートについて、ベンダーに依存しない仕様とツール群を提供するプロジェクトです。その中核となる概念が「トレース」と「スパン」の2つです。

トレースは前述の通り、リクエストがアプリケーション内を通る経路全体を表します^*1。これに対しスパンは、トレースを構成する個々の作業単位・操作を表す基本要素です。OpenTelemetryの定義では、各スパンには名前・親スパンID・開始時刻と終了時刻・スパンコンテキスト・属性・イベント・リンク・ステータスといった情報が含まれます^*1。

複数のスパンが同一のトレースID（trace_id）を共有することで、階層的な親子関係を持つ1つのトレースとして組み立てられます^*1。例えば、APIゲートウェイのスパンを親として、その配下に認証サービス・在庫サービスそれぞれのスパンが子として連なる、という構造です。この親子関係を可視化することで、リクエスト全体のどの区間に処理時間が集中しているかを特定できます。

コンテキスト伝播とW3C Trace Context——サービスをまたいでIDをつなぐ仕組み

分散トレーシングとは、複数のプロセス・サービスにまたがるスパンを相互に相関させ、1つのトレースとして組み立てる技術です。この相関付けを可能にする基本概念が「コンテキスト伝播」です^*1。コンテキスト伝播とは、あるサービスが発行したトレースIDやスパンIDを、次に呼び出すサービスへリクエストヘッダー等を介して受け渡す仕組みを指します。

コンテキスト伝播の形式を標準化した仕様がW3C（World Wide Web Consortium、Webの技術標準を策定する国際的な標準化団体）のTrace Contextです。W3C勧告として2021年11月23日に発行されたこの仕様は「分散トレーシングのシナリオを実現するための標準HTTPヘッダーと値形式を定義する」ものであり、策定にはMicrosoft・Google・Dynatraceの担当者が編集者として関わっています^*2。

Trace Contextの中核をなすtraceparentヘッダーは、トレースグラフにおける受信リクエストの位置を、ポータブルかつ固定長の形式で表現します^*2。異なるベンダーの計装ライブラリやAPMツールを組み合わせても、このヘッダー形式に準拠していればトレースIDを一貫して伝播できる点が、標準化の意義です。OpenTelemetryも、このW3C Trace Contextをサービス間伝播のデフォルト形式として採用しています。

自動計装と手動計装——OpenTelemetryのAPI・SDK・Collectorの役割分担

分散トレーシングを導入するには、アプリケーションにスパンを生成させる「計装（instrumentation）」の作業が必要です。OpenTelemetryは計装方法を自動計装（Zero-code Solutions）と手動計装（Code-based Solutions）の2種類に整理しています^*3。

自動計装は、アプリケーションのコードを変更せずに、利用中のライブラリや実行環境からテレメトリを取得する方式です^*3。導入初期やアプリケーションコードを変更できない場面に向いています。手動計装は、OpenTelemetry APIを用いてアプリケーション自身にテレメトリ生成のコードを書き込む方式で、アプリケーション内部からより詳細で豊富なデータを取得できます^*3。OpenTelemetryは両者を排他的なものではなく同時に利用できる補完関係として位置づけています^*3。

この計装を支えるのがOpenTelemetryの3つの構成要素です。APIはテレメトリデータを生成・相関させるためのデータ型と操作を定義する言語非依存の仕様、SDKはそのAPIの言語別実装で設定・データ処理・エクスポートの機能を持つもの、Collectorは複数形式のテレメトリを受信し処理した上で1つ以上のバックエンドへ送信する、ベンダーに依存しないプロキシです^*4。実務では、アプリケーションにSDKを組み込んでスパンを生成し、Collectorを経由してバックエンドへエクスポートする構成が一般的です。

サンプリング設計——ヘッドサンプリングとテールサンプリングの選択

トラフィック量が多いサービスでは、全リクエストのトレースを収集・保存するとデータ量とコストが増大します。そのため実際の導入では、どのトレースを記録するかを決める「サンプリング」の設計が論点になります。OpenTelemetryはサンプリング方式を主にヘッドサンプリングとテールサンプリングの2種類に整理しています^*5。

ヘッドサンプリングは、できるだけ早い段階でサンプリング可否を決める手法です^*5。トレースIDと目標サンプリング率に基づいて判定するため設定が容易で計算負荷も低く、収集パイプラインの任意の地点で実装できます^*5。一方でトレース全体を検査する前に決定してしまうため、エラーを含むトレースだけを狙って残すといった選別はできません^*5。

テールサンプリングは、トレースを構成するスパンの全体または大部分を確認したうえでサンプリング可否を判定する手法です^*5。エラーを含むトレース、処理時間が長いトレース、特定の属性を持つトレースを優先的に残す、といった柔軟な判定が可能です^*5。ただし実装・運用の複雑さが増し、状態を保持する仕組み（ステートフルな処理）が必要になり、特定ベンダーの機能に依存しやすくなる傾向がある点が課題です^*5。どちらを選ぶかは、保存コストの許容範囲と「エラー時のトレースを取りこぼしなく残したいか」という要件のバランスで判断することになります。

メトリクス・ログとの相関付けとバックエンド連携

分散トレーシングは単体でも有用ですが、可観測性の3本柱であるメトリクス・ログと組み合わせることで価値が増します。トレースIDをログの共通フィールドに含めておけば、あるトレースで異常が見つかった際に、対応する詳細ログへ直接たどり着けます。メトリクスで異常な傾向を検知し、該当時間帯のトレースで原因区間を特定する、という組み合わせ方も一般的です。

収集したスパンは、OpenTelemetry Collectorを経由して分析用のバックエンドへエクスポートします。エクスポート先には複数の選択肢があり、それぞれ機能・料金体系・運用方式が異なります。自社の既存監視基盤やAPM（Application Performance Monitoring）契約の有無に応じて、エクスポート先を選定する必要があります。特定製品の優劣を一律に論じることは難しく、既存システムとの親和性・保存期間・費用条件を踏まえて個別に比較検討することが前提になります。

分散トレーシング基盤を内製構築する難易度

分散トレーシングを内製で構築する場合、必要になる知識は1つの技術領域にとどまりません。OpenTelemetryのAPI・SDKの実装知識、対象言語・フレームワークごとの計装ライブラリの選定、W3C Trace Contextに準拠したコンテキスト伝播の実装、サンプリング方式の設計、Collectorの構成管理、エクスポート先バックエンドの選定と運用まで、一連の知識が必要です。

計装の範囲を誤ると、サービス間でコンテキストが途切れ、トレースが分断されたまま可視化されないという事態が起こり得ます。特に、非同期処理やメッセージキューを介した通信は、HTTPリクエストと異なりコンテキストの伝播経路を個別に実装する必要があるため、計装の抜け漏れが発生しやすい領域です。トレースが分断された状態で運用を続けると、障害発生時にサービスをまたいだ原因特定ができず、結局は従来通り各サービスのログを個別に照合する作業に戻ってしまい、分散トレーシングを導入した目的が果たせません。

内製でこれらを実装するには、バックエンド・フロントエンド双方の実装知識に加え、OpenTelemetryの仕様理解と運用設計の知識を持つ人員を確保する必要があります。既存の開発チームがアプリケーション機能の開発と並行してこれを担う場合、計装の設計・レビューに割く工数の確保が課題になりやすいところです。

外注の委託範囲と発注準備で整理すべきこと

分散トレーシング導入を外注する場合、委託範囲を事前に整理しておくことで、認識齟齬による手戻りを避けられます。整理すべき主な論点は次の通りです。

• 対象サービス・言語・フレームワークの一覧と、自動計装で対応可能な範囲・手動計装が必要な範囲の切り分け
• HTTP通信以外（メッセージキュー・バッチ処理等）のコンテキスト伝播をどこまで実装するか
• サンプリング方式（ヘッド／テール）の選定と、保存コストの許容範囲
• Collectorの構成・運用（自社ホスト型かマネージドサービスか）とエクスポート先バックエンドの選定
• 導入後の計装追加・保守を委託先が継続対応するか、内製チームへ引き継ぐか

これらを発注前にRFP（提案依頼書）へ落とし込んでおくと、複数の委託先候補から提案を受ける際に比較がしやすくなります。特に、内製へ引き継ぐ前提であれば、委託先に計装コードのドキュメント化や運用手順書の作成まで含めて依頼するかどうかを、契約時に明記しておくことが望ましいです。

まとめ：分散トレーシング導入の3つの判断軸

本稿では、OpenTelemetryによる分散トレーシング導入の基本概念と外注時の論点を整理しました。要点を3つに集約すると次の通りです。第一に、トレース・スパン・コンテキスト伝播というOpenTelemetryの基本概念とW3C Trace Contextの標準を理解することが土台になります。第二に、自動計装と手動計装の使い分け、ヘッドサンプリングとテールサンプリングの選択は、システム構成とコスト要件に応じて個別に判断する必要があります。第三に、内製で担う場合はコンテキスト伝播の抜け漏れが課題になりやすく、外注する場合は委託範囲と導入後の保守体制を発注前に明確にしておくことが手戻りを防ぎます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OpenTelemetry「Traces」（OpenTelemetry公式ドキュメント、https://opentelemetry.io/docs/concepts/signals/traces/）
2. *2　出典：W3C「Trace Context」（W3C Recommendation、2021年11月23日、https://www.w3.org/TR/trace-context/）
3. *3　出典：OpenTelemetry「Instrumentation」（OpenTelemetry公式ドキュメント、https://opentelemetry.io/docs/concepts/instrumentation/）
4. *4　出典：OpenTelemetry「Components」（OpenTelemetry公式ドキュメント、https://opentelemetry.io/docs/concepts/components/）
5. *5　出典：OpenTelemetry「Sampling」（OpenTelemetry公式ドキュメント、https://opentelemetry.io/docs/concepts/sampling/）

Tweet