翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon SNS デッドレターキュー
デッドレターキューは、Amazon SNS サブスクリプションが受信者に正常に配信できないメッセージの送信先としての Amazon SQS キューです。クライアントエラーまたはサーバーエラーが原因で配信できないメッセージは、詳細な分析や再処理のためにデッドレターキューに保持されます。詳細については、「[サブスクリプションの Amazon SNS デッドレターキューを設定する](sns-configure-dead-letter-queue.md)」および「[Amazon SNS メッセージ配信の再試行](sns-message-delivery-retries.md)」を参照してください。
**注記**
Amazon SNS サブスクリプションと Amazon SQS キューは、同じ AWS アカウントとリージョンにある必要があります。
[FIFO トピック](sns-fifo-topics.md)では、Amazon SNS サブスクリプションのデッドレターキューとして Amazon SQS キューを使用できます。FIFO トピックサブスクリプションでは FIFO キューを使用します。標準トピックサブスクリプションでは標準キューを使用します。
暗号化された Amazon SQS キューをデッドレターキューとして使用するには、Amazon SNS サービスプリンシパルに AWS KMS API アクションへのアクセスを許可するキーポリシーを持つカスタム KMS を使用する必要があります。詳細については、このガイドの「[サーバー側の暗号化を使用した Amazon SNS データの保護](sns-server-side-encryption.md)」と、『*Amazon Simple Queue Service デベロッパーガイド*』の「[サーバー側の暗号化 (SSE) と AWS KMSを使用した Amazon SQS データの保護](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-server-side-encryption.html)」を参照してください。
## メッセージ配信が失敗する理由
一般に、Amazon SNS が*クライアント側*または*サーバー側のエラー*により、サブスクライブされたエンドポイントにアクセスできない場合、メッセージの配信は失敗します。Amazon SNS がクライアント側のエラーを受信した場合、または対応する再試行ポリシーで指定された再試行回数を超えるメッセージに対してサーバー側のエラーを受信し続ける場合、Amazon SNS はメッセージを廃棄します。ただし、デッドレターキューがサブスクリプションに添付されている場合を除きます。配信に失敗しても、サブスクリプションのステータスは変更されません。詳細については、「[Amazon SNS メッセージ配信の再試行](sns-message-delivery-retries.md)」を参照してください。
### クライアント側エラー
Amazon SNS に古いサブスクリプションのメタデータがあると、クライアント側のエラーが発生する可能性があります。これらのエラーは、通常、所有者がエンドポイント (Amazon SNS トピックにサブスクライブされている Lambda 関数など) を削除した場合や、サブスクライブしているエンドポイントに添付されているポリシーを、Amazon SNS がエンドポイントにメッセージを配信できないように所有者が変更した場合に発生します。Amazon SNS は、クライアント側のエラーの結果として失敗したメッセージ配信を再試行しません。
### サーバー側のエラー
サーバー側のエラーは、サブスクライブされたエンドポイントを担当するシステムが利用できなくなったり、Amazon SNS からの有効なリクエストを処理できないことを示す例外を返す場合に発生します。サーバー側のエラーが発生すると、Amazon SNS は一次バックオフ関数またはエクスポネンシャルバックオフ関数を使用して、失敗した配信を再試行します。Amazon SQS または によってバックアップされた AWS マネージドエンドポイントに起因するサーバー側のエラーの場合 AWS Lambda、Amazon SNS は 23 日間で最大 100,015 回配信を再試行します。
カスタマー管理のエンドポイント (HTTP、SMTP、SMS、モバイルプッシュなど) も、サーバー側のエラーを引き起こす可能性があります。Amazon SNS は、これらのタイプのエンドポイントへの配信も再試行します。HTTP エンドポイントはお客様定義の再試行ポリシーをサポートしますが、Amazon SNS は SMTP、SMS、およびモバイルプッシュエンドポイントに対して、内部配信再試行ポリシーを 6 時間にわたって 50 回に設定します。
## デッドレターキューのしくみ
メッセージの配信はサブスクリプションレベルで行われるため、デッドレターキューは (トピックではなく) Amazon SNS サブスクリプションに添付されます。これにより、各メッセージの元のターゲットエンドポイントをより簡単に識別できます。
Amazon SNS サブスクリプションに関連付けられたデッドレターキューは、通常の Amazon SQS キューです。メッセージの保持期間の詳細については、『*Amazon Simple Queue Service デベロッパーガイド*』の「[メッセージに関連するクォータ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-quotas.html#quotas-messages)」を参照してください。Amazon SQS `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)` API アクションを使用して、メッセージの保持期間を変更できます。アプリケーションの復元性を高めるために、デッドレターキューの最大保持期間を 14 日に設定することをお勧めします。
## メッセージがデッドレターキューに移動する仕組み
メッセージは、*再処理ポリシー*を使用してデッドレターキューに移動されます。再処理ポリシーは、デッドレターキューの ARN を参照する JSON オブジェクトです。`deadLetterTargetArn` 属性は ARN を指定します。ARN は、Amazon SNS サブスクリプションと同じ およびリージョンにある Amazon SQS Amazon SNS キューを指す必要があります。 AWS アカウント 詳細については、「[サブスクリプションの Amazon SNS デッドレターキューを設定する](sns-configure-dead-letter-queue.md)」を参照してください。
次の JSON オブジェクトは、SNS サブスクリプションに添付された再処理ポリシーのサンプルです。
```
{
"deadLetterTargetArn": "arn:aws:sqs:us-east-2:123456789012:MyDeadLetterQueue"
}
```
## メッセージをデッドレターキューから移動する方法
メッセージをデッドレターキューから移動するには、次の 2 つの方法があります。
+ **Amazon SQS コンシューマロジックの作成を避ける** - デッドレターキューをイベントソースとして Lambda 関数に設定して、デッドレターキューを吸い出します。
+ **Amazon SQS コンシューマーロジック**の書き込み – Amazon SQS API、 AWS SDK、または を使用して、デッドレターキュー内のメッセージをポーリング、処理、削除するためのカスタムコンシューマーロジックを AWS CLI 書き込みます。
## デッドレターキューのモニタリングとログ記録方法
Amazon CloudWatch メトリクスを使用して、Amazon SNS サブスクリプションに関連付けられたデッドレターキューをモニタリングできます。すべての Amazon SQS キューは 1 分間隔で CloudWatch メトリクスを送信します。詳細については、「*Amazon Simple Queue Service デベロッパーガイド*」の「[Amazon SQS で使用できる CloudWatch メトリクス](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)」を参照してください。デッドレターキューを持つすべての Amazon SNS サブスクリプションも、CloudWatch メトリクスを出力します。詳細については、「[CloudWatch を使用した Amazon SNS のモニタリング](sns-monitoring-using-cloudwatch.md)」を参照してください。
デッドレターキューのアクティビティを通知するには、CloudWatch メトリクスとアラームを使用できます。`NumberOfMessagesSent` メトリクスのアラームを設定するのは適切ではありません。このメトリクスは、処理の試行が失敗した場合に DLQ に送信されるメッセージをキャプチャしないためです。ここでは、`ApproximateNumberOfMessagesVisible` メトリクスを使用します。このメトリクスは、処理の失敗のために移動されたメッセージも含め、DLQ で現在利用可能なすべてのメッセージをキャプチャします。
**CloudWatch アラーム設定の例**
1. `ApproximateNumberOfMessagesVisible` メトリクスの [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)を作成します。
1. アラームしきい値を **1** (または期待と DLQ トラフィックに基づく別の適切な値) に設定します。
1. アラームが作動したときに通知される Amazon SNS **トピック**を指定します。この Amazon SNS トピックは、任意のエンドポイントタイプ (E メールアドレス、電話番号、モバイルポケットベルアプリなど) にアラーム通知を配信できます。
CloudWatch Logs を使用して、Amazon SNS 配信が失敗する原因となる例外や、デッドレターキューに送信されるメッセージを調査できます。Amazon SNS は、配信の成功と失敗の両方を CloudWatch に記録できます。詳細については、「[Amazon SNS モバイルアプリの属性](sns-msg-status.md)」を参照してください。