Amazon CloudWatch Application Signalsでアプリケーションを監視しよう

はじめに
CloudWatch Application Signalsとは何か
Application Signalsの利用料金
やってみた
おわりに

はじめに

はじめまして、クラウド事業推進部の奥山です。

最近のアプリケーションは構成が複雑化し、「どこで何が起きているのか」を把握しづらくなりました。AWS上のアプリも同様で、連携するサービスが多いほど処理の追跡は難しくなります。

従来のログ中心の調査だけでは、ログデータの量や調査にかかる手間が課題になりがちです。そこで注目されるのがAPM（アプリケーションパフォーマンスモニタリング）です。APMはアプリケーションのパフォーマンスを継続的に監視するための手法を指します。
AWS上のアプリケーションを監視するにあたり、サードパーティー製APMツールは有力ですが、コストやAWS外部のサービスを運用する負荷がネックになる場合もあります。

APM導入のハードルが高いと感じたことがある方にとって、有力な選択肢となるのがAmazon CloudWatch Application Signalsです。

CloudWatch Application Signalsとは何か

Amazon CloudWatch Application Signalsは、OpenTelemetry（OTel）ベースのAPM機能です。EC2／ECS／EKS／Lambdaに対応し、環境に応じた方法で計測を有効化できます。
対応言語は2026年3月現在、Java、.NET、PHP、Ruby、Python、Node.js、GoLangです。

Application Signalsの利用料金

CloudWatchの他サービスと同じく、初期費用や最低利用料金はかからず、使った分だけ支払う従量課金制です。

無料利用枠：100GBのデータ取り込み + 100万件のスパンインデックス化
アジアパシフィック(東京)の場合
- データ取り込み：USD 0.35 / GB（最初の10TBまで）
- インデックス化：USD 0.75 / 100万スパン

他リージョンおよび最新の情報はAmazon CloudWatch の料金をご参照ください。

やってみた

本記事では簡単なデモアプリケーションを利用してApplication Signalsの機能を確認します。

1. デモ用アプリケーションを作成する

デモ用にECS上で稼働するNode.js製のマイクロサービスアプリケーションをデモとして用意しました。

構成図

アプリケーションコンテナ群
- BFF：フロントエンドからのリクエストの入り口となります。後続の各バックエンドサービス（Catalog / Inventory / Reviews）に対して、API呼び出しを行います。エンドポイントは/api/product/:idです。
- Catalog / Inventory / Reviews：それぞれ商品情報・在庫情報・レビュー情報を管理し、BFFからのリクエストに応じてレスポンスを返すバックエンドサービスです。ReviewsのみDynamoDBにアクセスします。

2. Application Signalsを有効化する

これらのアプリケーションをApplication Signalsでモニタリングするため、AWS公式ドキュメントのサイドカー戦略を使用してデプロイする - Amazon CloudWatchにしたがって、Application Signals導入の設定をしていきます。

ECSの場合、有効化までの手順は下記の通りになります。

（初回のみ）CloudWatchの「サービス」ページから「サービスの検出を開始」を選択する。
ECSタスク用のIAMロールにIAMポリシーCloudWatchAgentServerPolicyをアタッチする。
ECSにCloudWatchエージェントを導入し、Application Signalsにデータを送信する設定を行う。
（CloudWatchエージェント設定ファイル・共有ボリューム・ecs-cwagent/initコンテナ・アプリケーションコンテナの環境変数の設定）

この構成によりアプリケーションコードを変更せずにテレメトリデータを収集できます。

3. アプリケーションを監視する

Application Signalsを有効化してから数分ほど待つと、サービスが自動検出され、CloudWatchの「サービス」ページに環境変数で設定した名前が表示されます。

CloudWatchの「サービス」ページに表示されるサービス一覧

サービス名を選択すると、自動的に収集されている障害・エラー・レイテンシーが一覧で表示されます。

BFFサービスの「概要」ページ

Application Signalsの機能のひとつは、SLOの設定・追跡です。
設定したSLOはダッシュボードで達成度やエラーバジェットなどの重要指標がグラフで表示され、状況を直感的に把握できます。さらに、SLOをベースにしたCloudWatchアラームを設定でき、Amazon SNSを使って通知することも可能です。

このサービスでSLOを設定してみましょう。
「サービス」ページの左上「Create SLO」からSLOの作成ページに移動できます。

「サービスレベル指標(SLI)を設定」画面

SLOでは次の項目を設定できます。

サービスレベル指標（SLI）：どの指標で信頼性を測るか
例）/api/product/:idに対するGETリクエストが5xxレスポンスを返さないこと。
達成度目標：SLIが期間またはリクエスト比でどの程度満たされているべきか。
例）過去28日間で99%以上が5xxを返さない。

CloudWatchのSLOについての詳細はAWS公式ドキュメントのサービスレベル目標 (SLO) - Amazon CloudWatchをご参照ください。

本デモでは、意図的に障害が発生するよう実装しているため、SLOを設定していくつかリクエストを送信してしばらく待ってから「サービス」ページを見ると、SLOのステータスが「異常」に変わります。

SLOの「Triage SLI Health」が「異常」になっているBFFサービスの「概要」ページ

「サービスオペレーション」タブを選択すると、オペレーション別にリクエストグラフを見ることができます。
「選択したオペレーション」のグラフの頂点を選択すると、右ペインに関連するトレース情報が表示されます。赤枠で囲ったトレースが、5xx障害が発生したリクエストのトレースです。

BFFサービスの「サービスオペレーション」ページ。右側に開いたペインに5xx障害が発生したリクエストのトレースが表示されている。

障害が発生したトレースを選択すると、「トレース」ページに遷移し、詳細な情報が表示されます。
Inventoryサービスで発生した障害が接続しているBFFサービスに影響していることが一目でわかります。

「トレース」ページで表示されるトレースの詳細

同ページの「セグメントのタイムライン」では、上図についてさらに詳細な情報を確認することができます。例外が発生した箇所については、「View exception」を選択することで詳細が表示されます。

「トレース」ページの「セグメントのタイムライン」

このトレース詳細画面で確認できるのは障害だけではありません。一見正常に見えるリクエストに存在する問題を視覚的に確認することができます。

下のトレースにあるDynamoDBへのアクセスは、赤枠で囲んだところで同じテーブルへのGetItemオペレーションが連続して発生しています。

「トレース」ページの「セグメントのタイムライン」

今回は数アクセスのみですが、実際の本番環境では同様のアクセスが1リクエスト内で何十回、場合によっては何百回と発生するケースもあります。これらはすぐにエラーとして表面化しませんが、気づくとレイテンシー増加やDynamoDBコストの増加につながるため、Application Signalsのようなトレースの可視化が大きな助けになります。