はじめに
AWS のアーキテクチャを設計する際に、処理に失敗することを考慮して、デッドレターキュー（DLQ）を採用されたご経験はございますでしょうか？
デッドレターキュー（DLQ）にキューが積まれる条件を正しく理解していないと要件にあった設計が困難になります。
この記事では、デッドレターキュー（DLQ）の使用例をもとに注意ポイントをご紹介させていただきます。
デッドレターキュー（DLQ）とは
デッドレターキュー（DLQ）は、AWSのメッセージングサービスにおいて、処理に失敗したメッセージを保存するための特別なキューです。
これにより、失敗したメッセージを後で確認し、問題を特定して対処することができます。
また、システムの信頼性とメンテナンス性が向上します。
デッドレターキュー（DLQ）の設定例
こちらのシステム構成図は特定の通知をEメールへ送信と、AWS Lambdaの関数を呼び出すものとなります。
下記システム構成図のように、 Amazon SNS と AWS Lambda にデッドレターキュー（DLQ）を設定することができます。
デッドレターキュー（DLQ）に積まれる条件について
上記の Amazon SNS と AWS Lambda に設定されているデッドレターキュー（DLQ）について、どのタイミングでキューが送信されるかの理解が必要です。
Amazon SNS に設定されているデッドレターキュー（DLQ）
Amazon SNS に設定されているデッドレターキュー（DLQ）は、SNS がサブスクライバー（今回の例では AWS Lambda）へメッセージを配信できなかった場合に、メッセージが送信されます。
ここで注意すべき点は、 Amazon SNS と AWS Lambda の連携は 非同期呼び出し であるという点です。
Amazon SNS は AWS Lambda 関数そのものの処理結果（成功・失敗）までは判定しておらず、「AWS Lambda サービスへの起動リクエストが正常に受け付けられたか」のみをもって配信成功と判断します。
そのため、以下のようなケースでは Amazon SNS 側の デッドレターキュー（DLQ） にはメッセージは送信されません。
- AWS Lambda 関数が正常に起動したが、処理途中でエラーが発生した
- AWS Lambda 関数内のロジックエラーや外部サービス連携失敗により処理が失敗した
一方で、以下のように SNS が配信自体に失敗した場合 には、SNS に設定された デッドレターキュー（DLQ） にメッセージが送信されます。
- AWS Lambda のエンドポイントが存在しない
- 権限不足などにより AWS Lambda を起動できない
- 一定回数のリトライ後も配信に失敗した
AWS Lambda に設定されているデッドレターキュー（DLQ）
AWS Lambda に設定されているデッドレターキュー（DLQ）は、AWS Lambda 関数の実行が失敗した場合 に、イベントデータが送信されます。
特に Amazon SNS からの呼び出しは非同期実行となるため、AWS Lambda 側では以下のような条件で失敗と判定され、デッドレターキュー（DLQ） へ送信されます。
- 関数の実行中に例外が発生した
- タイムアウトが発生した
- 非同期実行における再試行（最大回数）後も処理が成功しなかった
このように、「AWS Lambda の処理結果に起因する失敗」を検知してメッセージを保持したい場合は、AWS Lambda 側に デッドレターキュー（DLQ） を設定する必要があります。
SNS 側の デッドレターキュー（DLQ） と AWS Lambda 側の デッドレターキュー（DLQ） は役割が異なるため、「どのレイヤーでの失敗を検知・再処理したいのか」を明確にした上で、適切なサービスにデッドレterキュー（DLQ）を設定することが重要です。
おわりに
紹介させていただいたリソース以外にも Amazon SQS や Amazon EventBridge にも デッドレターキュー（DLQ）を設定することが可能です。
また、 AWS Lambda に関しては、デッドレターキュー（DLQ）の送信先を Amazon SNS にすることが可能です。
デッドレターキュー（DLQ）に送信される条件について、正しく理解してシステム構成を検討しましょう。
では、よりよい AWS ライフを
