AWS SNSのSubscriberはどう使い分けるべきでしょうか？

Question

AWS SNSのSubscriberにはhttpやSQSを指定することが出来ますが、これらにはどういったメリット/デメリットがあり、どう使い分けるべきなのでしょうか。
一見すると、SQSを使用した場合はclientがポーリングする手間がある為、httpのエンドポイントを叩く方がシンプルで実装が楽なようにも感じます。

Answer 1

SNS の配送が失敗した場合、SNS は時間を開けて 最大 3回まで再試行します。
再試行がすべて失敗した場合はSNSは配送を諦めてしまうので、通知は取りこぼされます。

http の場合は、サーバーがダウンしたとき、応答がなくタイムアウト(15秒)したとき、HTTP 500応答が有ったとき、などに失敗します。SQSの場合は、アプリケーションの処理が成功するまでキューに残ってますので、取りこぼしが起きにくいのがメリットです。

使い分けとしては、通知の取りこぼしを許容できる場合かつ、上記で書いたような失敗するケースは気にしなくていいなら httpで問題ないと思います。取りこぼしが許容できない場合、または、通知が失敗する可能性が高い場合は、SQSを考えたいところです。また、サーバーのスペック、台数などを試算して、費用が安い方を選ぶという考え方もあると思います。

ただ、SQSは 順序が保証されない、重複することがあるといった、クセがあるので、SQSの特徴をよく理解してから採用しないと、困ったことになる場合がありますので、ドキュメントなどを読んで 理解した上で使ってください。

Answer 2

ユースケース次第です。

SNSでメッセージ発行した直後になにかさせたいならhttp/sエンドポイントで十分かと思います。

SQSを使うメリットは実行タイミングをコントロールできることで、これをすることで処理を切り離すことが出来ます。
なので、逐次実行すると時間がかかるから別の時間帯や別サーバにやらせたい処理なんかはキューを使うこと実行環境や時間をコントロールできます。
メッセージは先に発行しつつ、処理は後でやりたい、みたいな用途があればそのときに使えます。
メッセージを発行する側としては、メッセージを発行する処理までになるので。
別サーバにやらせる処理なんかはまあどちらでもできないことはないでしょうけど。

SNS+SQSの組み合わせは、ドキュメントにも載っている「ファンアウト」がよくあるパターンだと思います
一般的な Amazon SNS シナリオ

Answer 3

SNSとSQSには一長一短があります。

SNSでは、メッセージをサブスクライバーにプッシュ配信します。SQSのようにポーリングを待つ必要が無く、メッセージを即時配信できます。ただし、サブスクライバーが常時メッセージを受け取れるようにする必要があります。

一方のSQSは、受信クライアントが自身の都合に合わせて、ポーリングによってメッセージを受け取ります。キューにメッセージが届いたとき、受信クライアントが使用可能である必要はありません。

SNSとSQSを組み合わせると、特定のクライアント（サブスクライバー）にはメッセージを即時配信し、他のクライアントはポーリングでメッセージを受け取る、というアーキテクチャーを作れます。その場合、SNSトピックに特定のクライアントとSQSキューをサブスクライバーとして登録しておきます。さらに、他のクライアントはSQSキューをポーリングするようにします。

これが答えかも。
https://xtech.nikkei.com/atcl/learning/lecture/19/00047/062700001/?P=8