分散トレースの概要

アプリケーション ロードバランサの分散トレースを使用すると、クライアントからロードバランサを介してバックエンド サービスに送信されるリクエストをエンドツーエンドで可視化できます。

Cloud Load Balancing は Cloud Trace と統合され、ロードバランサが処理するリクエストのトレーススパンを生成します。ロードバランサはアプリケーション トラフィックのエントリ ポイントであるため、ロードバランサでトレース コンテキストを開始して伝播することで、リクエストパス全体で診断の可視性を確保できます。これらのトレースを使用すると、レイテンシのボトルネックの特定、障害が発生しているホップの分離、多層アーキテクチャ全体のエラーのトラブルシューティングを行うことができます。

ロードバランサは、オープン標準（W3C トレース コンテキストと OpenTelemetry）に準拠したトレースを生成します。OpenTelemetry で計測されたバックエンド サービスは、ロードバランサが開始したトレースを続行できます。

主なメリット

Cloud Trace を使用した分散トレースには、次の利点があります。

  • エンドツーエンドのリクエストの可視性: 外部アプリケーション ロードバランサと内部アプリケーション ロードバランサ、およびトラフィックをルーティングするバックエンド サービス全体でリクエストのパスをトレースします。
  • エッジ オブザーバビリティ: ロードバランサがバックエンドを選択する前に、転送ルールでトレーススパンをキャプチャします。これにより、バックエンドの計測では検出できないエッジエラーとレイテンシを確認できます。
  • 分離されたテレメトリー構成: ロードバランサのルーティング構成を変更せずに、スタンドアロンの TelemetryPolicy リソースでトレース設定を定義します。
  • クロス テレメトリーの相関関係: トレーススパンを Cloud Load Balancing リクエストログと Cloud Monitoring 指標に関連付けて、レイテンシやエラーの発生元を特定します。

サポートされているロードバランサ

次の表に、分散トレースをサポートするロードバランサと、各ロードバランサがサポートするサンプリング モードを示します。

ロードバランサ ロード バランシング スキーム 確率的サンプリング 親ベースのサンプリング
グローバル外部アプリケーション ロードバランサ EXTERNAL_MANAGED
リージョン外部アプリケーション ロードバランサ EXTERNAL_MANAGED
リージョン内部アプリケーション ロードバランサ INTERNAL_MANAGED
クロスリージョン内部アプリケーション ロードバランサ INTERNAL_MANAGED

従来のアプリケーション ロードバランサは、分散トレースをサポートしていません。

分散トレースの仕組み

分散トレースを構成するには、Network Services API で TelemetryPolicy リソースを作成します。テレメトリー ポリシーでは、次の項目を指定します。

  • ターゲット: トレースするロードバランサの転送ルール。
  • トレース構成: ロードバランサがトレースするリクエストを決定するサンプリング設定。

テレメトリー ポリシーの対象となる転送ルールにリクエストが到着すると、ロードバランサはリクエストをサンプリングするかどうかを決定します。リクエストがサンプリングされると、ロードバランサはトレーススパンを生成し、スパンを Cloud Trace に送信して、W3C traceparent リクエスト ヘッダーでトレース コンテキストをバックエンドに伝播します。

転送ルールのアタッチメント

テレメトリー ポリシーは、ロードバランサのフロントエンドを表すロードバランサの転送ルールをターゲットにします。転送ルールにトレースをアタッチすると、ロードバランサは、ロードバランサがバックエンドを選択する前に失敗したリクエストを含む、仮想 IP アドレス（VIP）とポートに入るすべてのトラフィックをトレースできます。

テレメトリー ポリシーには次の特性があります。

  • 独立したライフサイクル: テレメトリー ポリシーは、バックエンド サービス、URL マップ、ターゲット プロキシとは別です。ロードバランサによるトラフィックのルーティング方法を変更することなく、テレメトリー ポリシーを作成、変更、削除できます。
  • フロントエンド間で再利用可能: 1 つのテレメトリー ポリシーで複数の転送ルールをターゲットにできるため、複数のロードバランサ フロントエンドに一貫したトレース設定を適用できます。
  • ロケーション スコープ: global ロケーションにテレメトリー ポリシーを作成して、グローバル外部アプリケーション ロードバランサやクロスリージョン内部アプリケーション ロードバランサで使用されるグローバル転送ルールをターゲットにします。リージョンにテレメトリー ポリシーを作成して、そのリージョンのリージョン転送ルール（リージョン外部アプリケーション ロードバランサやリージョン内部アプリケーション ロードバランサで使用されるルールなど）をターゲットにします。

サンプリング モード

分散トレースは、次のサンプリング モードをサポートしています。各ロードバランサでサポートされているサンプリング モードの詳細については、このドキュメントのサポートされているロードバランサをご覧ください。

  • 確率的サンプリング: ロードバランサは、samplingRate フィールドで設定した一定の割合のリクエストをサンプリングします。たとえば、値を 0.01 にすると、リクエストの 1% がサンプリングされます。確率的サンプリングは、サポートされているすべてのロードバランサでサポートされています。

  • 親ベースのサンプリング: ロードバランサは、アップストリーム クライアントまたはサービスからの受信 traceparent ヘッダーのサンプリング決定を優先します。親ベースのサンプリングは parentBasedSampling フィールドで構成します。親ベースのサンプリングは、内部アプリケーション ロードバランサでのみサポートされます。

    親ベースのサンプリングを有効にすると、ロードバランサはリクエストを次のように処理します。

    • 受信 traceparent ヘッダーにサンプリング フラグが設定されている場合、ロードバランサは parentBasedSampling.samplingRate フィールドで指定されたレートでリクエストをサンプリングします。たとえば、このフィールドを 1.0 に設定すると、アップストリーム サービスがすでにサンプリングしたすべてのリクエストがトレースされます。
    • 受信 traceparent ヘッダーにサンプリング フラグが設定されていない場合、ロードバランサはリクエストをサンプリングしません。この動作は、アップストリームの決定を尊重し、OpenTelemetry 仕様に準拠しています。これにより、切断されたトレースが Cloud Trace に表示されなくなります。
    • リクエストに traceparent ヘッダーが含まれていない場合、ロードバランサはベースライン samplingRate を適用します。

トレース コンテキスト ヘッダーの処理

ロードバランサは、W3C traceparent ヘッダーを次のように処理します。

  • トレースが有効になっていないか、リクエストがサンプリングされていない: ロードバランサは、受信した traceparent ヘッダーを変更せずにバックエンドに転送します。
  • リクエストがサンプリングされ、traceparent ヘッダーが含まれていない: ロードバランサは新しいトレース ID とスパン ID を生成し、トレースフラグを 03（ランダムおよびサンプリング）に設定します。
  • リクエストがサンプリングされ、traceparent ヘッダーが含まれている: ロードバランサは、受信トレース ID とランダムフラグを保持し、新しいスパン ID を生成して、サンプリングされたフラグを設定します。

W3C トレース コンテキスト プロパゲータで OpenTelemetry SDK を使用するバックエンド サービスは、traceparent ヘッダーを自動的に読み取り、トレースを続行します。詳細については、トレース コンテキストをご覧ください。

一般的なユースケース

このセクションでは、分散トレースの一般的なシナリオについて説明します。

ストアフロント エッジをモニタリングする

e コマースのストアフロントは、グローバル外部アプリケーション ロードバランサを使用して顧客トラフィックを受信します。エッジのレイテンシと、404 レスポンスや TLS 障害などのエラーをモニタリングするには、確率サンプリングを使用したテレメトリー ポリシーをストアフロントの転送ルールに接続します。0.01（1%）などの低いサンプリング レートを使用すると、トラフィックのピーク イベント中に Cloud Trace の取り込み費用を予測できます。

チェックアウト サービス全体でトレースの継続性を維持する

購入手続きリクエストは、ストアフロントから内部アプリケーション ロードバランサを介して、内部のカート、在庫、決済サービスに送信されます。ストアフロントでサンプリングされたチェックアウト リクエストがすべての内部ホップでトレースされるようにするには、内部ロードバランサで親ベースのサンプリングを有効にし、parentBasedSampling.samplingRate を 1.0 に設定します。アップストリームのサンプリング決定を伴わないルーチンの内部トラフィックは、ベースライン samplingRate でサンプリングされます。

レイテンシのボトルネックを特定する

チェックアウトのレイテンシが増加するか、5xx エラーが急増すると、Cloud Trace のロードバランサ スパンをロードバランサのリクエストログとレイテンシ指標と比較します。この比較により、問題がロードバランサのエッジ、内部ロードバランサのホップ、バックエンド サービスのいずれで発生しているかを判断できます。

料金

ロードバランサは、トレーススパンの生成に対して課金しません。ただし、トレーススパンの取り込みについては、Cloud Trace の料金が適用されます。

トラフィックの多い本番環境ワークロードの取り込み費用を管理するには、samplingRate を 0.01（1%）または 0.001（0.1%）にすることをおすすめします。

制限事項

プレビュー期間中、アプリケーション ロードバランサの分散トレースには次の制限があります。

  • 親ベースのサンプリングは、外部アプリケーション ロードバランサではサポートされていません。
  • カスタム スパン属性はサポートされていません。
  • Google Kubernetes Engine Gateway API または Terraform を使用して分散トレースを構成することはできません。
  • 1 つのテレメトリー ポリシーで最大 50 個のリソースをターゲットにできます。

Agent Gateway の分散トレース

Agent Gateway を使用して AI エージェントのトラフィックを管理している場合は、Agent Gateway を介してトラフィックをモニタリングするで、エージェント トラフィックのモニタリングに関する情報をご覧ください。

次のステップ