Application Real-Time Monitoring Service:トレースサンプリング設定のベストプラクティス

概要

デジタルトランスフォーメーションを進める企業が増えるにつれて、IT システムはますます分散アーキテクチャとマイクロサービスを採用するようになっています。さまざまなミドルウェアの導入により、すでに複雑なビジネスロジックはさらに複雑化し、呼び出しチェーンも深くなっています。分散トレーシングは、エンドツーエンドのリアルタイムな可観測性を提供するために登場し、分散システムにおける呼び出し関係の明確な可視化と正確な根本原因の特定を可能にします。

以下の可視化されたトレースは、Application Real-Time Monitoring Service (ARMS) のトレース分析によってレンダリングされたものです。完全なトレースは通常、1 つ以上のサービスを通過する単一のリクエストのパスを表します。このパスの各セグメントはスパンと呼ばれます。スパンは、RPC 呼び出し、ミドルウェアの呼び出し、あるいは for ループなどの作業単位を表します。

ARMS トレース分析ページでは、トレースがウォーターフォール図として表示され、各スパンの完全な呼び出し階層と処理時間が示されます。この例では、mall-gateway が合計処理時間 47 ms のリクエストを開始し、そのリクエストは mall-product-server、mall-redis-server、mall-mysql-server、mall-kafka-producer、mall-user-server などのサービスノードを順に通過します。各スパンには、そのコンポーネントタイプ (例：http、Redis、MySQL) と処理時間がアノテーションされています。スパンを選択すると、右側のパネルに追加の詳細が表示され、アプリケーション名、インターフェイス名、spanId、parentSpanId、および http.status_code、namespace、clusterName などの属性が含まれます。

ビジネス規模の拡大に伴い、トレースデータ量も増加します。次の計算を考えてみましょう：あるトレースエンドポイントが 4,000 QPS を処理し、各リクエストが約 30 のスパンを生成し、各スパンが約 500 バイトを消費する場合、1 日のデータ量は次のようになります：4,000 × 30 × 500 バイト × 24 時間 = 4.7 TiB。

100 のトレースエントリポイントで全量データ収集が必要な場合、1 日のデータ量は 400 TiB に達します。フルサンプリングは、インシデント発生時にトラブルシューティングのための完全なトレースを確保できる一方で、ネットワーク I/O、トレース処理、パフォーマンスのオーバーヘッド、データストレージから生じる多大なコストも発生させます。

一般的なサンプリングアプローチ

広範な実践から、リソース消費や利用シナリオの観点から評価しても、すべてのインストルメンテーションデータを収集する必要は多くの場合ないことが示されています。そのため、分散トレーシングシステムは、コストと価値のバランスを取るために、定義された戦略に基づいてデータを選択的にレポートする機能をサポートしています。サンプリングの決定が行われるタイミングに基づいて、典型的な 3 つの戦略があります：

• ヘッドベースサンプリング

  ヘッドベースサンプリングは、クライアント側でトレースをサンプリングするかどうかを決定します。継続性を維持するため、決定はトレースのエントリサービスで行われます。このメソッドは、各リクエストにほぼ均等なサンプリング確率を与えます。オーバーヘッドとコストを効果的に削減しますが、決定が早期に行われるため、エラーが発生しやすい、遅い、または異常なトレースを見逃す可能性があります。

• テールベースサンプリング

  テールベースサンプリングは、トレースが完了するまでサンプリングの決定を遅延させます。システムはトレースデータを一時的にキャッシュし、サーバー側のルールを評価した後にのみデータを保存または破棄します。このアプローチは、いつでも診断のために問題のあるトレースを正確にキャプチャできますが、より高いオーバーヘッドとコストが発生します。

• ユニタリーサンプリング

  ユニットサンプリングは非協調的です：各サービスが独立して自身のスパンをレポートするかどうかを決定します。その結果、レポートされるトレースは不完全になることがよくあります。

ARMS は、エラー/低速トレースの優先順位付け、インターフェイスレベルの制御、トラフィック適応型サンプリングなどの機能でヘッドベースサンプリングを強化しています。ARMS のトレースサンプリングルールに関する詳細については、「トレースサンプリングモードの選択 (プローブバージョン 3.2.8 以前)」をご参照ください。

ビジネスシナリオに基づくサンプリング戦略の最適化

各サンプリング戦略にはトレードオフがあります。実際には、単一の戦略で完璧なコスト効率を達成することは稀です。ビジネスシナリオ、可観測性のニーズ、コストの制約を評価して、最も適切なアプローチを設定してください。例えば、コアアプリケーションやクリティカルパスからはより多くのデータを収集し、特に異常なトレースのヒット率を最大化する一方で、バイパスサービスやエッジサービスについては収集を削減またはスキップします。重要イベント保護期間中 (例：大規模な販売促進やグレースケールリリース) は、安定性と緊急対応を優先し、一時的にフルサンプリングを有効化します。

以下のセクションでは、ARMS のサンプリングルール、コスト管理、およびトレース価値の最大化の観点から、一般的なシナリオに最適なサンプリング戦略を分析します：

• エントリアプリケーションレベルでサンプリングレートを調整して、全体のトレースデータ量を制御する

  ヘッドベースサンプリングでは、エントリアプリケーションがトレースをサンプリングするかどうかを決定します。ルートスパンがサンプリングされると、その決定はアプリケーションの境界を越えてすべてのダウンストリームサービスに伝播され、トレースの完全性が保証されます。明確な呼び出し階層を持つ特定のビジネスフローにおいて、エントリアプリケーションの QPS とサンプリングレートは、観測可能な総データ量を直接決定します。ARMS の最新の課金モデル (観測可能なデータ量に基づく) では、これはコストに直接影響します。

  図に示すように、アプリケーション A の完全なトレースパスは A → 1 → 3 → 4 で、アプリケーション B のパスは B → 2 → 4 です。この図は、Top N インターフェイスの固定確率サンプリング後のアプリケーションレベルでの呼び出し関係を抽象化したものです。実際のアプリケーション内のインターフェイスのトレースは異なる場合があります。

  ダウンストリームアプリケーション (1, 2, 3, 4) は、サンプリング決定のほとんどをアップストリームサービスから継承します。したがって、アプリケーション A と B のサンプリングレートを調整することで、総データインジェストを大幅に制御できます。トレースの価値の観点から見ると、ほとんどのトレースは反復的です。問題が稀なグリッチでない限り、異常な動作は通常、複数のトレースに現れ、固定の確率でキャプチャされます。特に高 QPS のエントリアプリケーションのサンプリングレートを下げると、診断価値の損失を最小限に抑えながら、大幅なコスト削減が実現します。例えば、サンプリングレートを 10% から 5% に下げるとコストは半減しますが、本番環境ではエラー、遅延、異常は稀であるため、トレースの価値は半分にはなりません。

  ARMS は、アプリケーションレベルでの固定確率サンプリングをサポートしています。ビジネスロジックに基づいて、ゲートウェイ、プロキシ、またはコアのアップストリームサービスなどのエントリアプリケーションのサンプリングレートを調整してください。

  ARMS コンソールで、対象アプリケーションの Application Configuration > カスタム設定 ページに移動し、[サンプリング設定] セクションで固定サンプリングレートを調整します。詳細については、「固定サンプリングレート」をご参照ください。

  デフォルトの [サンプリングレート (%)] は 10 です。この値を増やすと、追加のシステムリソースを消費します。特に必要がない限り、デフォルト値を維持してください。

  ARMS はグローバルなサンプリングレート調整もサポートしています。システムはプローブを介してルートスパンを識別し、ルートスパンの数に基づいてエントリアプリケーションを計算し、トレースデータ量でソートして、Top N エントリアプリケーションのサンプリングレートを迅速に調整できます。

• 重要なインターフェイスに高いサンプリングレートを設定して、コアビジネスロジックのデータをより多くキャプチャする

  監視対象のアプリケーションの中で、ビジネスの重要性に基づいてコアと非コアを区別します。単一のアプリケーション内でも、一部のインターフェイスは他よりも重要です。例えば、E コマースシステムでは、商品詳細やチェックアウトのフローは、ユーザープロファイルのクエリや編集よりも優先度が高いです。これらの重要なフローをサポートするバックエンドインターフェイスは、再現が困難な障害を即座に分析できるように、積極的に (100% であっても) サンプリングする必要があります。

  ARMS はインターフェイスレベルのサンプリングポリシーをサポートしています。固定パーセンテージまたは固定トラフィック量に基づいて、インターフェイスごとにカスタムサンプリング戦略を設定できます。

  ARMS コンソールで、対象アプリケーションの Application Configuration > カスタム設定 ページに移動し、[サンプリングレート設定] セクションでインターフェイスレベルのサンプリングポリシーを設定します。

  サンプリングフォームでは、デフォルトの [サンプリングレート (%)] は 10 です。この値を増やすと、追加のシステムリソースを消費します。特に必要がない限り、デフォルト値を維持してください。[フルサンプリングインターフェイス名] フィールドは、プローブバージョン 3.2.0 以降でのみサポートされます。また、[フルサンプリングインターフェイスプレフィックス] と [フルサンプリングインターフェイスサフィックス] も設定できます。

  逆に、非コアのアプリケーションやインターフェイスのサンプリングレートを下げて、トレースの価値とコスト効率のバランスを最大化します。

• 適応型サンプリングを使用して、高トラフィックと低トラフィックの両方のインターフェイスを確実にキャプチャする

  複雑なアプリケーションは多くのインターフェイスを公開することがよくあります。インターフェイスごとにカスタムサンプリングを手動で設定すると、運用保守のオーバーヘッドが大幅に増加します。また、トラフィックパターンもビジネスの変化に伴って変動します。スケジューリングエンドポイントのような一部の低トラフィックインターフェイスは非常に重要であり、ここでの障害は主要なワークフロー全体を中断させる可能性があります。固定のアプリケーションレベルサンプリングでは、これらのインターフェイスは高トラフィックのものに圧迫されてしまいます。インターフェイスごとのルールを設定するには、すべての低トラフィックインターフェイスを手動で特定する必要があり、運用コストが増加します。

  この負担を軽減するため、ARMS はアプリケーションレベルの適応型サンプリングを提供しています。固定レートサンプリングとは異なり、適応型サンプリングは複数のヒット戦略を使用してトレースをサンプリングするかどうかを動的に決定し、低いレートでのカバー率のギャップと高いレートでのコスト急増の問題を解決します。

  主要な適応型サンプリング戦略には、以下が含まれます：特定のインターフェイスのフルサンプリング、Top N インターフェイスサンプリング、および低トラフィックフォールバックサンプリング。

  • 特定の API のフルサンプリング：API 名、プレフィックス、またはサフィックスを指定して、100% のサンプリングが必要な API をマークできます。これらの API へのすべてのリクエストは、トレース全体の 100% サンプリングをトリガーします。収集されるデータ量が大幅に増加するため、これは最も重要な API または一時的なデバッグのためにのみ有効にしてください。

  • API の Top-N サンプリング：これは、変更された LFU (Least Frequently Used) アルゴリズムを使用して、特定の期間内に各 API の限られた数のリクエストをサンプリングします。これにより、データ収集が API トラフィックと線形に増加しないことが保証されます。

  • 低トラフィック API の最小サンプリング：これにより、特定の期間内に各 API に対して少なくとも 1 つのトレースがサンプリングされることが保証されます。これにより、トラフィックが少ない期間でも、すべてのビジネス API の貴重な特性情報が記録されることが保証されます。

  ARMS コンソールで、対象アプリケーションの Application Configuration > カスタム設定 ページに移動し、[サンプリング設定] セクションで適応型サンプリングを設定します。詳細については、「適応型サンプリング」をご参照ください。

  適応型サンプリングセクションでは、デフォルトの [Top N サンプリング数] は 5、デフォルトの [サンプリングレート (%)] は 10 です。どちらかの値を増やすと、追加のシステムリソースを消費します。特に必要がない限り、デフォルト値を維持してください。特定のインターフェイスで全量データ収集を行うために、[フルサンプリングインターフェイス名] を設定することもできます。

• 重要イベント保護期間中はフルサンプリングを有効にする

  運用保守チームは、大規模な販売促進や新バージョンのストレステストなど、重要イベント保護が必要なシナリオにしばしば直面します。これらの期間中、特定のタグ付けされたデータまたはすべてのアプリケーションに対して全量データ収集とストレージを有効にすることで、障害診断、監査、責任追跡を迅速化します。保護期間が終了したら、標準のサンプリング戦略に戻して、パフォーマンスのオーバーヘッドとコストを削減します。

  ARMS は、テンプレート化されたトレースサンプリング設定をサポートしており、異なるシナリオに応じて異なるテンプレートを切り替えることができます。詳細については、「他のアプリケーションへの設定のコピー」をご参照ください。

関連ドキュメント

トレース収集後、フィルターと集約ディメンションを自由に組み合わせて、保存されたフルトレースデータに対してリアルタイム分析を実行します。詳細については、「トレース分析」をご参照ください。