CloudWatch Application Signalsにトレースを送信する構成パターン
この記事は「AWS×OpenTelemetryについて調査&検証してみた連載」の第2回目です。
- 第1回目：AWS Distro for OpenTelemetry（ADOT）とは何か？
- 第2回目：CloudWatch Application Signalsにトレースを送信する構成パターン（本記事）
- 第3回目：Apache / PHP-FPM構成のLaravelからCloudWatch Application Signalsにトレースを送信する方法
はじめに
前回は、「AWS Distro for OpenTelemetry（ADOT）とは何か？」という記事で、ADOTというサービスが何者なのかについて説明しました。今回は、アプリケーションからAWSのオブザービリティサービスであるCloudWatch Application Signalsにトレースを送信する方法をまとめます。
AWSでは、CloudWatch Application Signalsへトレースを送信する方法として、前回説明したADOTを利用する方法を含め、複数のパターンがあります。それらが少し分かりづらいと感じたため、3つの要素に分解して、利用可能な組合せを整理します。
AWSのオブザーバビリティサービス
X-RayとCloudWatch Application Signalsの関係
はじめに、AWSのオブザーバビリティサービスについて説明します。AWSでは、分散トレーシングに関連するオブザーバビリティサービスとして、「X-Ray」と「CloudWatch Application Signals」の2つが提供されています。
X-Rayは、分散トレーシングを可視化して、アプリケーションのパフォーマンスの問題を分析するサービスです。X-Rayは以前から提供されており、AWSで分散トレーシングを分析するならX-Rayと言える代表的な存在でした。
CloudWatch Application Signalsは、2023年のre:Inventで発表され、2024年にGAされた比較的新しいサービスです。X-Rayと同じく、トレースをもとにアプリケーションのパフォーマンスの問題を分析するためのサービスですが、名前の通りCloudWatchの一機能で、他のCloudWatchの機能との連携も容易です。また、OpenTelemetryに対応しているという特徴もあります。
X-Rayは独立したコンソールを持っていますが、現在は CloudWatchのコンソールからもアクセス可能で、徐々に統合が進められています。
また、CloudWatchのトランザクション検索を有効にすると、X-Rayに取り込んだトレースをCloudWatch Logsに自動連携して、CloudWatchの他の機能と連携して活用できます。CloudWatch Application Signalsも、X-RayからCloudWatch Logsに自動で連携されたトレースを参照して動作します。
そのため、X-RayとCloudWatch Application Signalsは独立したサービスではなく、CloudWatch Application Signalsは、X-Rayのトレースをデータソースとして活用し、より高度な可視化と分析を提供する上位レイヤーのサービスという関係にあります。
トレースの送信構成のパターン
アプリケーションで生成したトレースをCloudWatch Application Signalsに送信するまでには、3つの構成要素があります。
- トレースの生成方法（アプリケーションへの計装手法）
- トレースの処理方法（集約・加工・サンプリング・送信先の決定など）
- トレースの送信形式（トレースを送信する際のフォーマット）
それぞれに複数の選択肢があり、これらの組合せによって構成パターンが決まります。
以下の図は、トレースの生成から処理、送信に至るまでの全体像と、各ステップで選択可能な構成要素を示した概念図です。
①トレースの生成方法
まずは、トレースを生成する方法です。アプリケーションへの手動または自動の計装によって、トレースを記録するコードを埋め込みます。
このとき選べる代表的な方法は、以下の2つです。
X-Rayによる計装
X-Ray SDKを利用して、トレースを生成する方法です。
以前から提供されている方法です。
OpenTelemetryによる計装
OpenTelemetry SDKを利用して、トレースを生成する方法です。
前回紹介したADOT(AWS Distro for OpenTelemetry)だけでなく、他のディストリビューションのSDKも利用可能です。
②トレースの処理方法
生成されたトレースは、収集・加工・サンプリングなどの処理を経て、CloudWatch Application Signalsに送信されます。
この処理ステップには以下の手段があります。
X-Ray Daemon
X-Rayによる計装を行った場合に使われる伝統的な手法です。
アプリケーションからX-Ray Daemonにトレースを送信し、そこからX-Rayへ転送します。
OpenTelemetry Collector
OpenTelemetryによる計装を行った場合、OpenTelemetry Collectorを通じてトレースを処理・送信します。
サンプリング、Exporterの設定、送信先の設定など、柔軟な制御が可能です。
CloudWatch Agent
X-Rayによる計装とOpenTelemetryによる計装の両方の場合で、CloudWatch Agentを利用してトレースを処理・送信することも可能です。
これは2023年の以下のアップデートから利用可能になりました。
③トレースの送信形式
最後に、CloudWatch Application Signalsにトレースを送信する際のフォーマットです。
X-RayとOpenTelemetryではトレースのフォーマットが異なり、CloudWatch Application Signalsではどちらの形式も受け取れるようになっています（その際の経路は異なります）。
X-Ray形式
X-Ray Daemonを利用した場合は、X-Ray形式でトレースを送信します。また、OpenTelemetry Collector(ADOT)を利用した場合も、X-Ray Exporterを設定するとX-Ray形式でトレースを送信します。CloudWatch Agentを利用した場合も、デフォルトではX-Ray形式でトレースを送信します。
OTLP形式
OpenTelemetry Collectorを利用した場合は、OTLP(OpenTelemetry Protocol)というOpenTelemetryの仕様に準拠したフォーマットでトレースを送信することも可能です。
2024年の以下のアップデートにより、X-RayのOTLPエンドポイントがサポートされるようになったため、利用可能になりました。
また、CloudWatch Agentを利用した場合も、CloudWatch Agentの設定で、transit_spans_in_otlp_formatパラメータをtrueに設定すると、OTLP形式でトレースを送信することができます（デフォルトはfalse）。
CloudWatch Agentの設定詳細については以下のドキュメントを参照してください。
組合せ可能なパターン
それぞれの組合せ可能なパターンを整理すると、以下の表のようになります。
| No | 構成名 | トレースの生成方法 | トレースの処理方法 | トレースの送信形式 |
|---|---|---|---|---|
| 1 | X-Rayフル構成 | X-Rayによる計装 | X-Ray Daemon | X-Ray形式 |
| 2 | X-Ray + CWAgent構成（X-Ray形式） | X-Rayによる計装 | CloudWatch Agent | X-Ray形式 |
| 3 | X-Ray + CWAgent構成（OTLP形式） | X-Rayによる計装 | CloudWatch Agent | OTLP形式 |
| 4 | OTel + OTelCollector構成（X-Ray形式） | OpenTelemetryによる計装 | OpenTelemetry Collector | X-Ray形式 |
| 5 | OTel + OTelCollector構成（OTLP形式） | OpenTelemetryによる計装 | OpenTelemetry Collector | OTLP形式 |
| 6 | OTel + CWAgent構成（X-Ray形式） | OpenTelemetryによる計装 | CloudWatch Agent | X-Ray形式 |
| 7 | OTel + CWAgent構成（OTLP形式） | OpenTelemetryによる計装 | CloudWatch Agent | OTLP形式 |
AWS推奨の構成パターン
AWSのドキュメントでは、CloudWatch Application Signalsに対応した送信構成として以下の3パターンが説明されています（機械翻訳の内容は一部修正しています）。
- AWS Distro for OpenTelemetry(ADOT)をCloudWatch Agentと一緒に使用する
- OpenTelemetry SDKとOpenTelemetry Collectorを使用する
- AWS X-Ray SDKとX-Ray Daemonを使用する
これらは、本記事で紹介した構成パターンのうち、以下の番号に対応します。
| 構成 | パターンNo |
|---|---|
| AWS Distro for OpenTelemetry(ADOT)をCloudWatch Agentと一緒に使用する | 7 |
| OpenTelemetry SDKとOpenTelemetry Collectorを使用する | 5 |
| AWS X-Ray SDKとX-Ray Daemonを使用する | 1 |
AWSが明示的にサポート対象としているのはこれらの3パターンですが、実際には他の構成でもトレースを送信することが可能です。AWSとしての推奨パターンがこの3つなのだと解釈しています。
構成パターンごとのおすすめ利用シーン
最後に、構成パターンごとにおすすめの利用シーンを整理します。
| パターンNo | 構成 | おすすめ利用シーン |
|---|---|---|
| 1 | X-Rayフル構成 | 既にX-Rayで構築済みの場合 |
| 2 | X-Ray + CWAgent構成（X-Ray形式） | 非推奨 |
| 3 | X-Ray + CWAgent構成（OTLP形式） | X-Rayを利用しつつ、OTLP形式でトレースを送信したい場合 |
| 4 | OTel + OTelCollector構成（X-Ray形式） | 非推奨 |
| 5 | OTel + OTelCollector構成（OTLP形式） | 複数アプリのトレースを集中処理したい場合 柔軟なルーティングや加工が必要な場合 |
| 6 | OTel + CWAgent構成（X-Ray形式） | 非推奨 |
| 7 | OTel + CWAgent構成（OTLP形式） | 新しく分散トレーシングを始める場合 既にログやメトリクスでCloudWatch Agentを利用している場合 |
No.2、No.4、No.6を非推奨とした理由は、トレースの送信形式としてX-Ray形式とOTLP形式の両方が選べる場合、CloudWatch Application Signals との相性の面でOTLP形式の方が適していると考えられるためです。
X-Ray形式で送信した場合、CloudWatch Application Signalsの一覧画面では span名がリクエストパスの第一階層までしか表示されず、どのエンドポイントのトレースかが判別しにくくなります。
また同様の理由で、エンドポイントごとにSLO（Service Level Objective）を設定することができませんでした。
まとめ
本記事では、アプリケーションからCloudWatch Application Signalsにトレースを送信するための構成パターンについて、できるだけ網羅的に整理しました。CloudWatch Application Signalsを導入する際の構成の参考になれば幸いです。
次回は、PHPのサンプルアプリケーションから実際にCloudWatch Application Signalsにトレースを送信する流れについて説明します。
ご意見やご指摘などありましたら、ぜひコメントで教えてください！
Discussion