あるIoTプラットフォームが、多数のデバイスからセンサーデータをSNSトピックで受信し、複数の下流サービスに配信している。下流サービスの1つ（アナリティクス用DynamoDB書き込み）が一時的に利用できない場合でもデータ損失なく再処理できるようにしたい。最小限の変更で実現する方法はどれか。
- A. SNSトピックからアナリティクス向けのSQSキューをサブスクライブし（SNS→SQS ファンアウト）、SQSでDLQとリトライポリシーを設定した上でLambdaがSQSからDynamoDBに書き込む
- B. DynamoDB書き込みLambdaをSNSから直接サブスクライブし、Lambdaのデスティネーション設定でオンフェイルアーをSQS DLQに向ける
- C. SNSのメッセージ配信再試行ポリシーを最大50回に増やし、バックオフを指数関数的に設定する
- D. SNSトピックのサブスクリプションフィルターポリシーを設定し、失敗時はメッセージを破棄する
解答と解説を見る
正解: A
SNS→SQSのファンアウトパターンは、SNSが各下流サービスの前段にSQSキューを置く設計で、キューがバッファとして機能するためDynamoDBが一時的に利用できなくてもメッセージはSQSに保持される。SQSのリトライポリシーとDLQでデータ損失なく再処理できる。これがイベント駆動アーキテクチャにおける標準的な信頼性パターンである。Dのサブスクリプションフィルターは配信条件を絞るものであり、失敗時のメッセージ保持機能はなく、破棄では要件を満たせない。CのSNS配信再試行ポリシーはHTTPSエンドポイント向けで、SQSやLambdaサブスクリプションには効果が限定的であり、50回のリトライはSNSのデフォルト設定を超えた複雑な構成になる。BのLambdaデスティネーション（オンフェイルアー）は非同期呼び出し専用の機能であり、SNSからの同期的呼び出しには適用できない。
📚 関連サービスの解説: Amazon SNS ・ Amazon SQS