CloudWatch Application Signals + X-Ray APM ハンズオン

ECS Fargate に ADOT サイドカーを設置してメトリクス・トレース・SLO を一元管理する

CloudWatch Application Signals AWS X-Ray ADOT ECS Fargate マネコン操作 中級 所要時間 90〜120 分 v1.0

📋 概要

CloudWatch Application Signals は、アプリケーションのパフォーマンスを SLO(Service Level Objectives)で管理できる APM(Application Performance Monitoring)機能です。AWS Distro for OpenTelemetry(ADOT)サイドカーを ECS Fargate タスクに追加することで、コードを変更せずにメトリクス・ログ・トレースの「オブザーバビリティ三本柱」を実現できます。

このハンズオンでは、既存の ECS Fargate サービスに ADOT コレクターサイドカーを設置し、Application Signals でサービスマップと SLO を確認し、X-Ray でリクエストトレースを可視化します。

項目内容
対象サービスCloudWatch Application Signals、AWS X-Ray、AWS Distro for OpenTelemetry、ECS Fargate
主な学習内容ADOT サイドカー設定・Application Signals 有効化・SLO 作成・X-Ray トレース分析・アラーム設定
所要時間90〜120 分(待機時間含む)
難易度★★★☆☆(中級者向け)
前提知識ECS Fargate の基本操作、コンテナの概念
費用目安約 1〜3 USD(ECS Fargate 実行時間・X-Ray トレース)
ℹ️ オブザーバビリティ三本柱
  • メトリクス — CPU・レイテンシ・エラー率などの数値指標(CloudWatch Metrics)
  • ログ — リクエスト・エラーの詳細テキスト(CloudWatch Logs)
  • トレース — 1 リクエストが経由したサービス間の呼び出し経路(X-Ray)
ℹ️ Application Signals と X-Ray の関係

Application Signals は X-Ray トレースデータをベースに、サービスごとの可用性・レイテンシの SLI(Service Level Indicators)を自動計算します。X-Ray でミクロな障害を、Application Signals でマクロな SLO 遵守状況をそれぞれ確認できます。

🏗️ アーキテクチャ

🌐 クライアント / ブラウザ
HTTP リクエスト
⚖️ Application Load Balancer
パブリックサブネット
📦 ECS Fargate タスク(プライベートサブネット)
[アプリコンテナ] + [ADOT サイドカー]
アプリ → OpenTelemetry SDK → ADOT コレクター(ポート 4317/4318)
↓ テレメトリデータ(gRPC / HTTP)
📡 ADOT コレクター(サイドカー)
CloudWatch EMF エクスポーター / X-Ray エクスポーター
↓ メトリクス
📊 CloudWatch Application Signals
サービスマップ・SLO・ダッシュボード
↓ トレース
🔭 AWS X-Ray
トレースマップ・セグメント詳細・アノテーション

使用リソース一覧

リソース詳細備考
ECS クラスター既存クラスター(Fargate)前提として作成済み
ECS タスク定義アプリ + ADOT サイドカーこのハンズオンで更新
ADOT コレクターpublic.ecr.aws/aws-observability/aws-otel-collector:latestサイドカーとして追加
CloudWatch ロググループ/ecs/otel-collectorADOT のログ出力先
SSM パラメーターストア/otel/configADOT 設定ファイル
IAM ロール(タスク実行)既存ロールに権限追加X-Ray / CloudWatch 権限

✅ 前提条件

⚠️ リージョン確認

作業リージョンを固定してください。このハンズオンでは ap-northeast-1(東京) を使用します。コンソール右上でリージョンを確認してください。

ℹ️ ECS 環境がない場合

ECS ハンズオン(ECS Fargate + RDS ハンズオン)または ECS CloudFormation キット(CloudFormation 環境構築キット)を先に完了させてください。このハンズオンでは既存の ECS サービスに対して ADOT サイドカーを追加します。

IAM 権限の確認

操作ユーザーに以下の IAM ポリシーが付与されていることを確認します。

📡 ステップ 1 ― Application Signals の有効化と IAM 権限設定

まず CloudWatch Application Signals を有効化し、ADOT サイドカーが必要とする IAM 権限を ECS ロールに追加します。

1-1. CloudWatch コンソールを開く

AWS マネジメントコンソールで 「CloudWatch」 を検索して開きます。左メニューを下にスクロールし、「Application Signals」 セクションを展開して 「サービス」 をクリックします。

1-2. Application Signals を開始する

初めて開く場合は「Application Signals を開始する」ボタンが表示されます。「Application Signals を開始する」 をクリックします。

ℹ️ 有効化について

Application Signals の有効化はリージョン単位で行われます。X-Ray トレースや CloudWatch Metrics の使用量に対して課金されます(Application Signals 自体への追加料金はありません)。

1-3. IAM コンソールを開く

AWS マネジメントコンソールで 「IAM」 を検索して開きます。左メニューから 「ロール」 をクリックします。

1-4. タスク実行ロールにポリシーをアタッチ

ECS タスク実行ロール(例: ecsTaskExecutionRole)を検索して選択します。「許可を追加」→「ポリシーをアタッチ」 をクリックし、以下のポリシーを追加します。

ポリシー名用途
CloudWatchAgentServerPolicyCloudWatch メトリクス送信
AWSXRayDaemonWriteAccessX-Ray トレース送信
AmazonSSMReadOnlyAccessSSM パラメーターストアから設定読み取り

「許可を追加」 をクリックして保存します。

1-5. タスクロールにも権限を追加

ECS タスクロール(例: ecsTaskRole)も同様に選択し、以下のポリシーをアタッチします。

ポリシー名用途
AWSXRayDaemonWriteAccessX-Ray セグメント送信
CloudWatchAgentServerPolicyApplication Signals メトリクス送信
✅ 確認ポイント

両方の IAM ロールの「許可」タブに上記のポリシーが表示されていれば準備完了です。

⚙️ ステップ 2 ― ADOT 設定ファイルの準備(SSM パラメーターストア)

ADOT コレクターは YAML 形式の設定ファイルを参照して動作します。SSM パラメーターストアに設定を保存し、ECS タスク定義から参照します。

2-1. Systems Manager コンソールを開く

AWS マネジメントコンソールで 「Systems Manager」 を検索して開きます。左メニューから 「パラメータストア」 をクリックします。

2-2. パラメーターの作成

「パラメータを作成」 をクリックし、以下の設定を入力します。

名前/otel/config
タイプString
データ型text
2-3. 設定内容を入力

「値」欄に以下の YAML を貼り付けます。

extensions:
  health_check:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch/traces:
    timeout: 1s
    send_batch_size: 50
  batch/metrics:
    timeout: 60s

exporters:
  awsxray:
    region: ap-northeast-1
  awsemf:
    region: ap-northeast-1
    namespace: ApplicationSignals
    log_group_name: /aws/application-signals/data
    dimension_rollup_option: NoDimensionRollup

service:
  extensions: [health_check]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch/traces]
      exporters: [awsxray]
    metrics:
      receivers: [otlp]
      processors: [batch/metrics]
      exporters: [awsemf]

「パラメータを作成」 をクリックします。

ℹ️ 設定の説明
  • receivers/otlp — アプリから OpenTelemetry プロトコルでテレメトリを受信(gRPC:4317、HTTP:4318)
  • exporters/awsxray — トレースを X-Ray に送信
  • exporters/awsemf — メトリクスを CloudWatch EMF 形式で送信(Application Signals が解釈)
  • processors/batch — データをまとめて送信してコストを削減
✅ 確認ポイント

パラメーターストアに /otel/config が作成されていれば次のステップに進めます。ARN をメモしておいてください(次のステップで使用します)。

📝 ステップ 3 ― タスク定義の更新(ADOT サイドカー追加)

既存の ECS タスク定義に ADOT コレクターコンテナをサイドカーとして追加します。

3-1. ECS コンソールを開く

AWS マネジメントコンソールで 「Elastic Container Service」 を検索して開きます。左メニューから 「タスク定義」 をクリックします。

3-2. 既存タスク定義を選択

アプリケーションのタスク定義を選択し、最新のリビジョンをクリックします。「新しいリビジョンを作成」→「新しいリビジョンを作成」 をクリックします。

3-3. ADOT コンテナを追加

画面を下にスクロールして 「コンテナを追加」 をクリックし、ADOT コレクターコンテナを設定します。

コンテナ名aws-otel-collector
イメージ URIpublic.ecr.aws/aws-observability/aws-otel-collector:latest
必須コンテナいいえ
CPU ユニット256
メモリ制限 (MiB)512
3-4. ポートマッピングを設定

コンテナ設定の 「ポートマッピング」 で以下を追加します。

コンテナポートプロトコル用途
4317tcpOpenTelemetry gRPC レシーバー
4318tcpOpenTelemetry HTTP レシーバー
13133tcpHealth Check エンドポイント
3-5. 環境変数を設定

「環境変数」 セクションで以下を追加します。

キー値の種類
AOT_CONFIG_CONTENTValueFromarn:aws:ssm:ap-northeast-1:<アカウントID>:parameter/otel/config
⚠️ ARN の確認

<アカウントID> は実際の AWS アカウント ID(12 桁)に置き換えてください。アカウント ID はコンソール右上のユーザー名をクリックすると確認できます。または SSM パラメーターストアでパラメーター名をクリックして ARN をコピーしてください。

3-6. ログ設定を追加

「ログ設定」 セクションで以下を設定します。

awslogs-group/ecs/otel-collector
awslogs-regionap-northeast-1
awslogs-stream-prefixecs

「コンテナを追加」 をクリックしてサイドカーを保存します。

3-7. アプリコンテナに環境変数を追加

既存のアプリコンテナを選択して編集します。OpenTelemetry SDK にエンドポイントを教えるための環境変数を追加します。

キー
OTEL_EXPORTER_OTLP_ENDPOINThttp://localhost:4317
OTEL_RESOURCE_ATTRIBUTESservice.name=myapp,service.namespace=production
OTEL_METRICS_EXPORTERotlp
OTEL_TRACES_EXPORTERotlp
OTEL_PROPAGATORSxray,tracecontext,baggage,b3
ℹ️ service.name について

service.name は Application Signals のサービスマップ上でサービスを識別する名前になります。アプリケーションを表す分かりやすい名前を付けてください(例: myappapi-server)。

3-8. 新しいリビジョンを作成

画面一番下の 「作成」 をクリックして新しいタスク定義リビジョンを保存します。

✅ 確認ポイント

タスク定義の最新リビジョンに aws-otel-collector コンテナが追加されていれば成功です。

🚀 ステップ 4 ― ECS サービスの更新・デプロイ

新しいタスク定義リビジョンを使用するよう ECS サービスを更新します。

4-1. ECS クラスターを開く

ECS コンソール左メニューから 「クラスター」 をクリックし、使用しているクラスターを選択します。

4-2. サービスを更新

「サービス」 タブでアプリケーションのサービスを選択し、「更新」 をクリックします。

タスク定義ファミリー(現在のファミリー名)
リビジョンLATEST(最新を選択)
サービスの強制新規デプロイ✓ チェックを入れる
4-3. デプロイを実行

「更新」 をクリックします。デプロイが開始され、ADOT サイドカーを含む新しいタスクが起動します。

4-4. デプロイの完了を待機

サービスの 「デプロイ」 タブでステータスを確認します。「PRIMARY」 ステータスのデプロイが完了するまで待ちます(通常 3〜5 分)。

ℹ️ タスクが起動しない場合
  • タスクの「ステータス」→「停止理由」を確認してください
  • CloudWatch Logs の /ecs/otel-collector ロググループでエラーを確認してください
  • SSM パラメーターの ARN が正しいか確認してください
  • IAM ロールへの権限追加が正しく行われているか再確認してください
4-5. ALB でアクセスして動作確認

デプロイ完了後、ALB の DNS 名にブラウザでアクセスし、アプリケーションが正常に動作することを確認します。数回アクセスしてトレースデータを生成します。

✅ 確認ポイント

ECS サービスのタスクが「RUNNING」状態になり、ALB 経由でアプリにアクセスできれば次のステップに進めます。

🗺️ ステップ 5 ― Application Signals でサービスマップを確認

ADOT がデータを収集し始めると、CloudWatch Application Signals にサービスが表示されます。

5-1. Application Signals を開く

CloudWatch コンソール左メニューの 「Application Signals」→「サービス」 をクリックします。デプロイから 5〜10 分後に myapp(設定した service.name)が表示されます。

ℹ️ 表示されない場合

ALB 経由でアプリに数回アクセスした後、1〜2 分待ってからページをリロードしてください。アプリに OpenTelemetry SDK が組み込まれていない場合、ADOT はテレメトリを受信できないためサービスが表示されません。SDK のインストール手順は AWS OTEL ドキュメント を参照してください。

5-2. サービスの詳細を確認

サービス名をクリックして詳細画面を開きます。以下の指標を確認します。

指標説明
可用性成功リクエスト率(エラー率の逆数)
レイテンシ (p99)リクエストの 99% が完了する時間
レイテンシ (p50)中央値レイテンシ
リクエスト数1 分あたりのリクエスト数
エラー率5xx エラーの割合
5-3. サービスマップを表示

左メニューから 「Application Signals」→「サービスマップ」 をクリックします。アプリケーションが呼び出すサービス(RDS、S3 など)がグラフで表示されます。各ノードをクリックするとレイテンシやエラー率の詳細が確認できます。

✅ 確認ポイント

Application Signals にサービスが表示され、可用性・レイテンシのグラフが確認できれば次のステップに進めます。

🎯 ステップ 6 ― SLO(サービスレベル目標)の設定

Application Signals の SLO 機能で、サービスの目標値を設定します。SLO を設定することで、エラーバジェットの消費状況をリアルタイムで監視できます。

6-1. SLO 画面を開く

CloudWatch コンソール左メニューの 「Application Signals」→「SLO」 をクリックします。「SLO を作成」 をクリックします。

6-2. 可用性 SLO を作成

最初に可用性(Availability)の SLO を作成します。

SLI の種類可用性
サービスmyapp(ステップ 5 で確認したサービス)
オペレーションすべて(または特定のエンドポイント)
SLO 名myapp-availability-slo
目標(%)99.9
評価期間ローリング 30 日

「SLO を作成」 をクリックします。

6-3. レイテンシ SLO を作成

再度 「SLO を作成」 をクリックして、レイテンシの SLO を作成します。

SLI の種類レイテンシ
サービスmyapp
SLO 名myapp-latency-slo
しきい値(ms 以下で応答する割合)500 ms
目標(%)99
評価期間ローリング 30 日

「SLO を作成」 をクリックします。

6-4. SLO の状態を確認

SLO 一覧に戻り、作成した 2 つの SLO のステータスを確認します。

表示項目説明
ステータス(OK / BREACHING)現在 SLO を遵守しているか
エラーバジェット残余30 日間の許容違反時間のうち残量
コンプライアンス率実績値(99.9% 等)
ℹ️ エラーバジェットとは

SLO 99.9% の場合、30 日間で許容されるダウンタイムは約 43 分です。これが「エラーバジェット」です。バジェットが残っている間は機能リリースを行い、枯渇したら信頼性改善にリソースを集中させる、という運用指針として活用できます。

✅ 確認ポイント

SLO 一覧に可用性・レイテンシ SLO が表示されていれば次のステップに進めます。

🔭 ステップ 7 ― X-Ray トレースの確認

X-Ray コンソールで個別リクエストのトレースデータを確認します。

7-1. X-Ray コンソールを開く

AWS マネジメントコンソールで 「X-Ray」 を検索して開きます。または CloudWatch コンソール左メニューの 「X-Ray トレース」→「トレース」 からも開けます。

7-2. 時間範囲を設定してトレースを検索

右上の時間範囲ピッカーで 「直近 30 分」 を選択します。ALB 経由でアプリにアクセスしたリクエストのトレース一覧が表示されます。

ℹ️ トレースが表示されない場合

ALB 経由でアプリにいくつかリクエストを送信してから再度確認してください。アプリに OpenTelemetry SDK が組み込まれていない場合は X-Ray へのトレース送信が行われません。/ecs/otel-collector のログでエラーがないか確認してください。

7-3. トレース詳細を確認

トレース ID をクリックしてトレース詳細を開きます。

表示項目説明
タイムライン各セグメントの開始時刻と所要時間
セグメントサービス内の処理単位(HTTP ハンドラー、DB クエリ等)
サブセグメント外部 API 呼び出し・SQL クエリの詳細
アノテーションカスタム属性(ユーザー ID、オーダー ID 等)
メタデータ詳細なコンテキスト情報
7-4. エラートレースをフィルタリング

フィルター式フィールドに以下を入力してエラーのあるトレースだけを抽出します。

fault OR error

エラーがある場合はトレース詳細でどのセグメントで失敗したかを確認できます。

✅ 確認ポイント

X-Ray にトレースが表示され、タイムラインでリクエストの処理時間を確認できれば次のステップに進めます。

🗺️ ステップ 8 ― X-Ray トレースマップの分析

サービスマップでサービス間の依存関係とパフォーマンスを視覚的に把握します。

8-1. サービスマップを開く

X-Ray コンソール左メニューの 「サービスマップ」 をクリックします。アプリケーション・データベース・外部 API などがノードとして表示され、矢印で依存関係が示されます。

8-2. ノードのステータスを読み取る

各ノードには以下の情報が色分けで表示されます。

表示意味
緑のリング正常なリクエスト(2xx)の割合
黄のリングクライアントエラー(4xx)の割合
赤のリングサーバーエラー(5xx / fault)の割合
リクエスト数 / 秒スループット
レイテンシ平均応答時間
8-3. ノードをクリックしてドリルダウン

ノードをクリックすると右側のパネルにトレース一覧が表示されます。「トレースを表示」 をクリックすることでそのサービスを経由したトレースに絞り込めます。ボトルネックや高レイテンシの原因を特定するのに活用します。

8-4. 応答時間の分布を確認

X-Ray コンソール左メニューの 「分析」→「応答時間の分布」 でレイテンシのヒストグラムを確認します。外れ値(p99 の遅いリクエスト)のトレースを特定できます。

✅ 確認ポイント

X-Ray サービスマップでアプリとバックエンドサービスの依存関係が可視化されていれば次のステップに進めます。

📊 ステップ 9 ― CloudWatch メトリクス・ダッシュボードの作成

ADOT が送信した Application Signals メトリクスを CloudWatch ダッシュボードで可視化します。

9-1. メトリクスを確認する

CloudWatch コンソール左メニューの 「メトリクス」→「すべてのメトリクス」 をクリックします。名前空間一覧に ApplicationSignals が表示されていることを確認します。

9-2. Application Signals 名前空間を確認

ApplicationSignals 名前空間をクリックして、利用可能なメトリクスを確認します。

メトリクス名説明
Latencyリクエストレイテンシ(p50、p99 等で統計を切り替え可能)
Availability可用性(成功リクエスト率)
Errorクライアントエラー(4xx)リクエスト数
Faultサーバーエラー(5xx)リクエスト数
9-3. カスタムダッシュボードを作成

CloudWatch コンソール左メニューの 「ダッシュボード」→「ダッシュボードの作成」 をクリックします。

ダッシュボード名APM-Overview

「ダッシュボードの作成」 をクリックします。

9-4. ウィジェットを追加

「ウィジェットの追加」 をクリックして以下のウィジェットを追加します。

  • 折れ線グラフApplicationSignals / Latency(p50、p99 の 2 系列)
  • 折れ線グラフApplicationSignals / Availability
  • 数値ApplicationSignals / Fault(合計)
  • 折れ線グラフ — ECS の CPUUtilizationMemoryUtilization

各ウィジェットを追加したら 「ダッシュボードを保存」 をクリックします。

ℹ️ ダッシュボードの共有

ダッシュボード右上の「共有」ボタンから、URL リンクとして共有したり、Slack や PagerDuty と連携するウィジェット画像を取得することができます。

✅ 確認ポイント

ダッシュボードにメトリクスグラフが表示されれば次のステップに進めます。

🔔 ステップ 10 ― CloudWatch アラームの設定

エラー率と高レイテンシを検知するアラームを設定し、SLO 違反を早期に検知できるようにします。

10-1. アラームの作成画面を開く

CloudWatch コンソール左メニューの 「アラーム」→「すべてのアラーム」→「アラームの作成」 をクリックします。

10-2. エラー率アラームのメトリクスを選択

「メトリクスの選択」 をクリックし、ApplicationSignalsFault メトリクスを選択して 「メトリクスと条件の指定」 をクリックします。

設定項目
統計合計 (Sum)
期間5 分
アラーム条件以上 (≥)
しきい値5

「次へ」 をクリックします。

10-3. SNS 通知を設定

「ALARM 状態のアクション」で 「通知の追加」 をクリックします。

SNS トピック新しいトピックの作成
トピック名apm-alert-topic
通知先メールアドレス(自分のメールアドレス)

「トピックの作成」 をクリックします。確認メールが届くので 「Confirm subscription」 リンクをクリックして購読を確認します。

10-4. アラーム名を設定して作成
アラーム名myapp-high-fault-rate
説明5 分間のサーバーエラーが 5 件以上

「アラームの作成」 をクリックします。

10-5. レイテンシアラームも作成(オプション)

同様の手順で ApplicationSignals / Latency メトリクスを使用したアラームを作成します。

統計p99
期間5 分
しきい値(ms)1000 以上
SNS トピックapm-alert-topic(既存)
アラーム名myapp-high-latency-p99
✅ 確認ポイント

アラーム一覧に myapp-high-fault-rate「データ不十分」 または 「OK」 状態で表示されていれば成功です。

ℹ️ SLO アラームとの連携

Application Signals の SLO 画面からも直接アラームを作成できます。SLO → 対象 SLO を選択 → 「アラームを作成」ボタンから設定すると、エラーバジェット消費率に基づいたアラームが自動生成されます。

🧹 クリーンアップ

ハンズオン完了後は以下の順序でリソースを削除してください。削除し忘れると継続的に費用が発生します。

⚠️ 削除順序に注意

ECS サービスを元に戻す(ADOT サイドカーなしのタスク定義に更新する)か、サービス・クラスターごと削除してください。ECS を引き続き使用する場合は元のタスク定義リビジョンにロールバックします。

1. CloudWatch アラームの削除

CloudWatch コンソール → 「アラーム」→「すべてのアラーム」 で作成したアラームを選択して 「アクション」→「削除」 をクリックします。

  • myapp-high-fault-rate
  • myapp-high-latency-p99(作成した場合)
2. SLO の削除

CloudWatch コンソール → 「Application Signals」→「SLO」 で作成した SLO を選択して削除します。

  • myapp-availability-slo
  • myapp-latency-slo
3. CloudWatch ダッシュボードの削除

CloudWatch コンソール → 「ダッシュボード」APM-Overview を選択して削除します。

4. SNS トピックの削除

SNS コンソール → 「トピック」apm-alert-topic を選択して削除します。

5. ECS タスク定義をロールバック(または ECS サービスを削除)

ECS コンソール → クラスター → サービスを選択して「更新」し、ADOT サイドカー追加前のリビジョンを指定して更新します。または ECS サービス・クラスターを削除します。

6. SSM パラメーターの削除

Systems Manager コンソール → 「パラメータストア」/otel/config を選択して削除します。

7. CloudWatch ロググループの削除

CloudWatch コンソール → 「ロググループ」 で以下を選択して削除します。

  • /ecs/otel-collector
  • /aws/application-signals/data
8. IAM ロールからポリシーをデタッチ(オプション)

このハンズオンで追加したポリシー(CloudWatchAgentServerPolicyAWSXRayDaemonWriteAccessAmazonSSMReadOnlyAccess)を ECS タスク実行ロール・タスクロールからデタッチします。

✅ 削除完了チェックリスト
  • ☐ CloudWatch アラームが削除された
  • ☐ Application Signals SLO が削除された
  • ☐ CloudWatch ダッシュボードが削除された
  • ☐ SNS トピックが削除された
  • ☐ ECS サービス / タスク定義が元に戻された(または削除)
  • ☐ SSM パラメーター /otel/config が削除された
  • ☐ CloudWatch ロググループが削除された
  • ☐ IAM ロールのポリシーをデタッチした(オプション)