SQSとSNS

このレッスンを終えると、Amazon Simple Queue Service (SQS) と Amazon Simple Notification Service (SNS) の違いを疎結合という観点から説明でき、要件の文からどちらかを選べるようになります。

自分でサーバーを建てたときは何をしていたか

1 台のサーバーの中に、画像をアップロードする処理とサムネイルを作る処理を両方書いたとします。この作りだと次の問題が起きます。

• サムネイル生成が重いと、アップロードの応答まで遅くなる
• サムネイル生成が失敗すると、アップロード自体が失敗したように見える
• 処理を分けたくても、片方を直すともう片方が動かなくなる

そこで、間に「やることリスト」を置く方法を考えます。アップロード側はリストに 1 行書くだけで返し、サムネイル側は空いたときにリストから 1 件取り出して処理する。この「間に置くやることリスト」がキューであり、AWS のマネージドなキューが SQS です。送る側と受ける側が直接つながらなくなることを 疎結合 (loose coupling) と呼びます。

もう一つ、複数の相手に同じお知らせを一斉に配りたい場面もあります。注文が確定したら、在庫システムにも、経理システムにも、担当者のメールにも同時に伝えたい。この一斉配信を引き受けるのが SNS です。

SQS と SNS の対比

SQS はメッセージを一定期間保持するので、受け手が落ちていても仕事が消えません。受け手が復旧してから取りに行けば処理できます。この「あとで処理できる」性質が、突発的な負荷を吸収する緩衝材になります。

SNS の送り先はメールや SMS、HTTP エンドポイント、AWS Lambda、そして SQS キューなどです。SNS のトピックに複数の SQS キューを購読させて、1 件の出来事を複数の処理系にそれぞれのキュー経由で届ける組み合わせもよく使われます。これはファンアウトと呼ばれます。

試験ではこう出る

CLF では設定方法ではなく、役割の選び分けが問われます。次の言い換えを覚えておきます。

• 「コンポーネント間を疎結合にしたい」「処理の滞留を吸収したい」「順番に非同期で処理したい」から SQS
• 「複数の受信者に同時に通知したい」「メールや SMS でアラートを送りたい」から SNS
• 「CloudWatch アラームの通知先」も SNS。アラーム自体は CloudWatch、通知の配信は SNS という役割分担です
• 「イベントに応じて処理をつなぎ合わせたい」「複数ステップのワークフローを可視化したい」なら AWS Step Functions

引っ掛けの中心は、通知という言葉です。受け手が 1 つで、順番に確実に処理させたいなら SQS、受け手が複数で、同時に知らせたいなら SNS と押さえます。「メッセージを失わずに処理したい」は SQS、「担当者に知らせたい」は SNS です。

まとめ

• SQS はキュー。送信側と受信側を切り離し、受け手が自分のペースで取り出す
• SNS はトピックへの発行と購読。1 件の出来事を複数の購読者へ同時に配る
• どちらも疎結合を実現するが、1 対 1 の処理が SQS、1 対多の通知が SNS
• CloudWatch アラームの通知先として SNS を使う組み合わせは頻出