1. はじめに

AWSの構築や運用を担当していると、AWSリソースの設定を行ったにもかかわらず、期待した処理が実行されないことがあります。

例えば、S3イベントを起点として、EventBridge、SQS、Lambdaと処理が連携する以下のような構成があるとします。

S3 イベント
 ↓
Amazon EventBridge
 ↓
Amazon SQS
 ↓
Amazon Lambda

S3でイベントが発生していないのか、EventBridgeでイベントを検知できていないのか、SQSへメッセージが送信されていないのかなど、処理のどの段階で問題が発生しているのかを切り分ける必要があります。

今回は、AWS CloudTrailやその他ダッシュボードを利用して、AWSリソースが期待どおりに動作しない場合に、どのように原因を調査していくのかを整理します。

2. AWS CloudTrailを障害調査に利用する

CloudTrailでは、AWSユーザーやIAMロール、AWSサービスによって実行されたAPI操作をイベントとして確認できます。

3. 障害調査の流れ

ここでは、以下の構成でSQSにメッセージが送信されないケースを例に調査方法を確認します。

S3 イベント
    ↓
Amazon EventBridge
    ↓
Amazon SQS
    ↓
AWS Lambda

この構成では、S3にオブジェクトが配置された際に発生するイベントをAmazon EventBridgeが検知し、イベントをAmazon SQSへ送信します。

その後、SQSに送信されたメッセージをLambdaが取得して処理します。

しかし、何らかの原因によってSQSにメッセージが送信されない場合、S3、EventBridge、SQSのどこに問題があるのかを切り分ける必要があります。

そこで、CloudTrailに記録されたイベントを確認し、AWSサービス間でどのようなAPI操作が行われたのかを追跡していきます。

4. 調査

ここでは、S3にファイルを配置したにもかかわらず、Lambdaが処理を実行していないケースを考えます。

今回の構成では、S3へのファイル配置を起点に処理が順番に行います。

S3
 ↓
EventBridge
 ↓
SQS
 ↓
Lambda

Lambdaが実行されていない場合、はじめにLambdaを確認するのではなく、処理がどこまで進んでいるのか、どこで止まっているのかを確認していく必要があります。

4.1 S3へのファイル配置を確認する

所定のバケットにファイルが配置されていることを確認します。

配置されている。

4.2 EventBridgeを確認する

次に、S3へのファイル配置をきっかけとして、EventBridgeがイベントを検知できているかを確認します。

EventBridge のダッシュボードの「MatchedEvents」にイベントが 1 件カウントされている。

ただし、「Invocations」が 1件カウントされているが、「FailedInvocations」でも 1件カウントされており、処理が失敗していそうだとわかる。

4.3 CloudTrailでAPI操作を確認する

ここでCloudTrailを確認します。

CloudTrailのイベント履歴から、EventBridgeから対象のSQS に対してSendMessage が実行されていることを確認します。

CloudTrailの証跡に保存されているか確認する。SendMessage はCloudTrailのデータイベントでCloudTrailのマネジメントコンソールには表示されないので、CloudWatch LogsやCloudTrailのログ保管先であるS3のログを確認し出力されていないことを確認しました。

4.4 SQSを確認する

念のために、SQSのダッシュボードを確認します。

「空の受信数」のみカウントされており、受信済みのメッセージは増えていません。

このように調査対象を切り分けることで、問題となっている箇所を限定していくことができます。

※ CloudTrailは、単独ですべての原因を特定するためのものではありません。しかし、AWSサービス間でどのようなAPI操作が行われたのかを確認することで、「どこまで処理が進んでいるのか」を切り分けるための手がかりとして利用できます。

※ CloudTrail で SQSの証跡を取得するには、SQSのデータイベントの設定を有効にする必要があります。これがなければ、CloudTrailの履歴に保管されません。

※ ダッシュボードへのメトリクスの反映は、数分程度のラグがあります。

4.5. EventBridge のイベントバスのログを確認する

イベントバスのログを確認すると以下のようなエラーが出力されていました。

"error_message": "The queue should either have ContentBasedDeduplication enabled or MessageDeduplicationId provided explicitly (Service: AmazonSQS; Status Code: 400; Error Code:

FIFOを利用する場合は、コンテンツに基づく重複排除を有効にする必要があるようです。

この設定を有効にすることで、EventBeidgeからSQSへメッセージが送信されるようになりました。

AWSのSQS(FIFO)でContentBasedDeduplicationで怒られたときの解決方法

5. おわりに

今回は、S3へのファイル配置を起点として、EventBridge、SQS、Lambdaへ処理を連携する構成を例に、障害調査の流れを確認しました。

S3
 ↓
ファイル配置を確認
 ↓
EventBridge
 ↓
イベント検知・ターゲット呼び出しを確認
 ↓
CloudTrail
 ↓
API操作を確認
 ↓
SQS
 ↓
キューの状態を確認
 ↓
権限設定を確認

という順番で調査を進めました。

このように、AWSのイベント連携で問題が発生した場合は、最初からLambdaのログだけを確認するのではなく、処理の流れに沿って各サービスを確認することが重要です。

また、CloudTrailは障害の原因を単独ですべて特定するためのサービスではありません。

CloudWatchのメトリクスや各AWSサービスの設定、ログなどと組み合わせることで、**「どこまで処理が進んでいるのか」「次にどこを調査すべきなのか」**を判断するための手がかりとして活用できます。

複数のAWSサービスを組み合わせたシステムでは、個々のサービスだけを見るのではなく、サービス間の処理の流れを追いながら切り分けることが、障害調査の重要なポイントになります。