元記事
2025/11/05に公開された下記の記事のとおり、Amazon Q DeveloperからSynthetics Canaryのエラーを解析できるようになりました。
Amazon Q Developerとは
AWS が提供する生成AIベースの開発者向けアシスタント です。 AWSマネジメントコンソール・IDE・CLI などで利用でき、開発者の作業を自動化・支援してくれます。
本記事ではAWSマネジメントコンソール上でのトラブル調査にフォーカスして記載します。 マネジメントコンソール上でのAmazon Q Developerの活用例については下記の記事が参考になります。
Synthetics Canaryとは
アプリや API が正常に動いているかを自動で監視するためのロボットテスターです。 AWSが提供するシンセティック（Synthetic）モニタリング機能で、 指定した間隔でロボットがアプリにアクセスし、実際に操作して動作を確認します。
システムの外側からユーザーと同じように動作確認をする監視方法で、いわゆる外形監視の機能となります。 Webサイトの場合は、定期的にページにアクセスし正常に表示されるかチェックしたり、 APIの場合は、実際にAPIを呼び出してみて動作を確認します。
検証用アプリケーションの構成
検証にあたり、AWS SAMを用いて下記の構成のHTTP APIを作成しました。
下記の3つのLambdaを作成します。
クライアント（curlコマンド）からのリクエストを受け取って、SQSにメッセージを格納するAPI （sam-test-stack-Enqueue）
SQLからメッセージを取り出してDynamoDBに格納するLambda （sam-test-stack-Worker）
クライアントからのリクエストにより、DynamoDBをスキャンして返却するAPI （sam-test-stack-Query）
上記3つのLambdaを作成し、1と3についてはAPI Gatewayの背後に配置してAPIとして公開します。
各LambdaはADOT（AWS Distro for OpenTelemetry）を有効にし、OTel（OpenTelemetry）の情報をApplication Signalsに連携します。
検証用アプリケーションを作成した後、実際にAPIを叩いてOTelの情報を出力すると Application Signalsのトレースマップ画面に下記のように表示されます。
青枠が1.のsam-test-stack-Enqueue、黄枠が2.のsam-test-stack-Worker、赤枠が3.のsam-test-stack-Queryを表しています。
Synthetics Canaryの設定
ここから外形監視の設定を加えていきます。 Synthetics Canaryの画面で[Canaryを作成]ボタンをクリックします。
[Canaryを作成]画面では、[設計図]欄で[ハートビートのモニタリング]を選択し、エンドポイントのURLとして、上記1.のsam-test-stack-EnqueueのURLを指定します。 今回はAPIの画面がないことから、スクリーンショットは取得しない設定としています。
スクリプトエディタはChromeを選択しています。
スケジュールは5分間隔で実行するようにしています。
アクティブトレースは有効にしています。
同様の手順でsam-test-stack-Queryに対する外形監視も追加します。 設定が完了し、正常にAPIを監視できるようになりました。
擬似障害の発生
下記コマンドを実行して、sam-test-stack-Enqueueの同時実行数を0にします。
aws lambda put-function-concurrency --function-name sam-test-stack-Enqueue --reserved-concurrent-executions 0
これにより、該当のAPIが実行できずエラーになります。 15分ほど待ってSynthetics Canaryの画面を確認すると、下記のとおり外形監視が失敗になりました。
詳細画面でも下図のように失敗していることが確認できます。
Amazon Q Developerによる原因調査
上記詳細画面でAmazon Q Developerを開き、プロンプトを入力します。
途中省略しますが下図のとおり、エラー箇所を特定してくれます。
続けてAPI Gatewayのログを確認するようにプロンプトを投入します。
下図のとおり、Lambda側のエラーであるとの回答が得られました。
Lambda関数のエラーを調査するようにプロンプトを投入します。
根本原因がLambdaのスロットリングであると特定されました。
まとめ
本記事では検証用のアプリとSynthetics Canaryをセットアップしていますが、 実際の運用環境でSynthetics Canaryが既に設定されているのであれば、 特に何も変更することなくAmazon Q Developerを利用してSynthetics Canaryのエラーを起点として根本原因を調査することができます。 Amazon Q Developerの活用により、障害発生時の対応がより迅速にできるようになると見込まれます。
なお、Amazon Q Developerが各種ログを解析する際、AWSマネジメントコンソールにログインしているユーザの権限を利用します。 現在の権限設定によってはIAMユーザやIAMロールの設定変更が必要となります。
