SNS のデッドレターキューと SQS のデッドレターキューについて解説します😎

こんにちは！

SNS へトピックを作成し、SQS でサブスクライブするアーキテクチャーはよくあるベストプラクティスです。

わたしたちは外部 API ( 決済 API へのリクエスト、SNS の API 投稿 ) への通信などを行う際に、このアーキテクチャーを採用することが多いですね。

本記事では、SNS のサブスクライバーに SQS を指定している場合のデッドレターキューの扱いについて解説したいと思います。

想定する読者

• AWS サーバーレスで開発をしているヒト
• SNS のサブスクライバーに SQS を指定しているヒト

はじめに

SNSとSQSの違い

SNS はトピックを作成しサブスクライバーへメッセージを通知する送信者で、SQS は受信者です。

つまり、そもそも送信者である SNS と受信者である SQS はユースケースが異なります。( それぞれ非同期で処理してくれる点は変わらない )

下記にそれぞれのユースケースを記載します。

SNSのユースケース（並列非同期処理）

• 注文情報を処理しつつデータウェアハウスの SQS を発火
• AWS サービスのシステムアラート
• システムの利用ユーザーへのプッシュ通知
• ユーザー個人への E メール送信または SMS 送信

SQSのユースケース（非同期処理）

• データウェアハウスへの格納処理
• AWSサービスのシステムアラート送信先のカスタム
• 注文情報の処理
• 決済 API との連携処理

デッドレターキューの扱い

SNSのデッドレターキューの定義

SNSトピックからサブスクリプション ( お客様の場合ですとSQSキュー ) に到達不能になった場合に、そのメッセージを保持するためのキュー。

SQSのデッドレターキューの定義

キューのコンシューマが指定された回数だけキュー内のメッセージの処理に失敗した場合に、そのメッセージを保持するためのキュー。

SNS→SQSの間で問題が発生しそうな場合はSNSデッドレターキューを検討

SNS のサブスクライバーに SQS を指定している時、メッセージの処理自体の失敗を検知するなら SQS のキュートなり、SNS と SQS の連携部分に懸念がある場合は SNS のデッドレターキューを使用します。

SNS と SQS 間の連携が失敗するケースは、実際そうそうありません。( AWS の障害などを想定すれば可能性は広がりますが… )

わたしたちは、例え可能性が低くても SNS → SQS のサブスクリプションが失敗した場合のエラー通知を設置しておきます。( 例えばSlack通知、Email通知など ) こうした細かいところの設定を拘るのが、最終的な品質かなと考えています。

まとめ

AWS サーバーレスを扱うなら、SNS と SQS 連携はぜひ抑えておくといいでしょう。非同期で処理をしたいときに非常にシンプルに実装することが可能ですし、サーバーレスの性質上、使用しなければ料金がかからないのでスタートアップや新規事業に優しいです。

SNS、SQSの実装、サーバーレスの開発はお気軽にお問い合わせください。