翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
イベントの再試行ポリシーとデッドレターキューの使用
ルールで指定されたターゲットにイベントが正常に配信されないことがあります。これは、例えば、ターゲットリソースが使用できない場合、 がターゲットリソースに対するアクセス許可を EventBridge 持っていない場合、またはネットワーク状態が原因で発生する可能性があります。再試行可能なエラーが原因でイベントがターゲットに正常に配信されない場合、 はイベントの送信を EventBridge 再試行します。ターゲットの再試行ポリシー設定で、再試行する時間の長さと再試行回数を設定します。デフォルトでは、 はエクスポネンシャルバックオフとジッター またはランダム化された遅延を使用して
EventBridge DLQsは、 EventBridge がターゲットに正常に配信できなかったイベントを保存するために使用する標準 Amazon SQS キューです。DLQ を使用するかどうかは、ルールを作成してターゲットを追加するときに選択できます。DLQ を設定すると、正常に配信されなかったイベントを保持できます。そのため、失敗したイベント配信の原因となった問題を解決し、後でイベントを処理できるようになります。
イベントエラーには、さまざまな処理方法があります。一部のイベントは、再試行せずに削除されるか、DLQ に送信されます。例えば、ターゲットへのアクセス許可がない、またはターゲットリソースが存在しなくなったためにエラーが発生する場合、根本的な問題を解決するアクションが実行されるまで、再試行はすべて失敗します。再試行するのではなく、 はこれらのイベントを DLQ がある場合は DLQ に直接 EventBridge 送信します。
イベント配信が失敗すると、 はターゲットがinvocation
失敗したことを示すイベントを Amazon CloudWatch メトリクスに EventBridge 発行します。DLQ を使用する場合、 InvocationsSentToDLQ
と を含む に追加 CloudWatchのメトリクスが送信されますInvocationsFailedToBeSentToDLQ
。
DLQ の各メッセージには、次のカスタム属性が含まれます。
RULE_ARN
TARGET_ARN
ERROR_CODE
以下は、DLQ が返す可能性のあるエラーコードのサンプルです。
-
CONNECTION_FAILURE
-
CROSS_ACCOUNT_INGESTION_FAILED
-
CROSS_REGION_INGESTION_FAILED
-
ERROR_FROM_TARGET
-
EVENTS_IN_BATCH_REQUEST_REJECTED
-
EVENTS_IN_BATCH_REQUEST_REJECTED
-
FAILED_TO_ASSUME_ROLE
-
INTERNAL_ERROR
-
INVALID_JSON
-
INVALID_PARAMETER
-
NO_PERMISSIONS
-
NO_RESOURCE
-
RESOURCE_ALREADY_EXISTS
-
RESOURCE_LIMIT_EXCEEDED
-
RESOURCE_MODIFICATION_COLLISION
-
SDK_CLIENT_ERROR
-
THIRD_ACCOUNT_HOP_DETECTED
-
THIRD_REGION_HOP_DETECTED
-
THROTTLING
-
TIMEOUT
-
TRANSIENT_ASSUME_ROLE
-
UNKNOWN
-
ERROR_MESSAGE
EXHAUSTED_RETRY_CONDITION
次の条件が返されることがあります。
-
MaximumRetryAttempts
-
MaximumEventAgeInSeconds
-
RETRY_ATTEMPTS
次のビデオでは、DLQ の設定について説明します。
デッドレターキューを使用する際の考慮事項
の DLQ を設定するときは、次の点を考慮してください EventBridge。
-
サポートされるのは標準キューのみです。の DLQ に FIFO キューを使用することはできません EventBridge。
-
EventBridge には、エラーコード、エラーメッセージ、再試行条件の超過、ルール ARN、再試行、ターゲット ARN など、イベントメタデータとメッセージ属性がメッセージに含まれます。これらの値を使用して、イベントと障害の原因を特定します。
-
同じアカウントの DLQ に対するアクセス許可。
-
コンソールを使用してルールにターゲットを追加し、同じアカウントで Amazon SQS キューを選択すると、キュー EventBridge へのアクセスを許可するリソースベースのポリシーがキューにアタッチされます。
-
EventBridge API の
PutTargets
オペレーションを使用してルールのターゲットを追加または更新し、同じアカウントで Amazon SQS キューを選択する場合は、選択したキューに手動でアクセス許可を付与する必要があります。詳細については、「デッドレターキューへのアクセス許可の付与」を参照してください。
-
-
別の AWS アカウントから Amazon SQS キューを使用するためのアクセス許可。
-
コンソールからルールを作成する場合、他のアカウントのキューは表示されないため選択できません。他のアカウントのキューへのアクセス許可を付与するには、そのキューの ARN を指定し、リソースベースのポリシーを手動でアタッチする必要があります。詳細については、「デッドレターキューへのアクセス許可の付与」を参照してください。
-
API を使用してルールを作成する場合、デッドレターキューとして使用される別のアカウントの SQS キューに、リソースベースのポリシーを手動でアタッチする必要があります。詳細については、「デッドレターキューへのアクセス許可の付与」を参照してください。
-
-
使用する Amazon SQS キューは、ルールを作成するリージョンと同じリージョンに存在する必要があります。
デッドレターキューへのアクセス許可の付与
ルールのターゲットに DLQ を設定すると、 は呼び出しに失敗したイベントを選択した Amazon SQS キュー EventBridge に送信します。イベントをキューに正常に配信するには、そのアクセス許可 EventBridge が必要です。ルールのターゲットを設定し、 EventBridge コンソールを使用して DLQ を選択すると、アクセス許可が自動的に追加されます。API を使用してルールを作成する場合、または別の AWS アカウントにあるキューを使用する場合は、必要なアクセス許可を付与するリソースベースのポリシーを手動で作成し、キューにアタッチする必要があります。
次のリソースベースのポリシーは、 が Amazon SQS キュー EventBridge にイベントメッセージを送信するために必要なアクセス許可を付与する方法を示しています。このポリシー例では、 SendMessage
オペレーションを使用してMyEvent「DLQ」という名前のキューにメッセージを送信するアクセス許可を EventBridge サービスに付与します。キューは、 AWS アカウント 123456789012 の us-west-2 リージョンにある必要があります。Condition
ステートメントでは、 AWS アカウント 123456789012 の us-west-2 リージョンで作成されたMyTestRule「」という名前のルールからのリクエストのみが許可されます。
{ "Sid": "Dead-letter queue permissions", "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "sqs:SendMessage", "Resource": "arn:aws:sqs:us-west-2:123456789012:MyEventDLQ", "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:events:us-west-2:123456789012:rule/MyTestRule" } } }
ポリシーをキューにアタッチするには、Amazon SQS コンソールを使用してキューを開き、[Access policy] (アクセスポリシー) を選択してポリシーを編集します。を使用することもできます。詳細については AWS CLI、「」を参照してくださいAmazon SQS のアクセス許可。
デッドレターキューからイベントを再送信する方法
メッセージを DLQ から移動するには、次の 2 つの方法があります。
-
Amazon SQS コンシューマーロジックの作成を避ける - DLQ をイベントソースとして Lambda 関数に設定し、DLQ を吸い出します。
-
Amazon SQS コンシューマーロジックの書き込み – Amazon SQS API、 AWS SDK、または AWS CLI を使用して、DLQ 内のメッセージをポーリング、処理、削除するためのカスタムコンシューマーロジックを記述します。