AWS SNSとSQSのファンアウト構成についてメモ

はじめに

AWS SNSとSQSのファンアウト構成についてメモ

参考

Amazon SNS(Simple Notification Service)とは

Amazon SNSは、Amazon Web Servicesのフルマネージドな通知サービスです。SNSを使用すると、アプリケーションやユーザーにスケーラブルなプッシュ通知、SMS、Lambda関数、HTTPSエンドポイント、SQSキューなど、さまざまなエンドポイントのSNSトピックにサブスクライブ(メッセージ送信)できます。

主な特徴と機能

• トピックとパブリッシュとサブスクライズ:

  • トピック
    • 利用者はトピックを作成し、そのトピックにメッセージを発行できます。
  • パブリッシュ
    • APIなどから特定のトピックにメッセージを発行すること。
    • このメッセージは、そのトピックにサブスクライブしている全てのエンドポイントやサービスに配信されます
  • サブスクライブ(定期購読)とは
    • トピックが受信するメッセージを受信したいリソースを登録して、リソースがメッセージを受信すること
    • メッセージを購読するリソース
    • Eメール、SMS、Lambda関数、HTTPSエンドポイント、SQSキューなど、さまざまなエンドポイントとしてSNSトピックにサブスクライブできます。

• ファンアウトとは

  • 一つのメッセージを複数のサブスクライバーやエンドポイント（SQSキュー、Lambda関数、Eメール、SMSなど）に同時に配信する能力。
  • 通常はSQSがサブスクライブして利用する構成が一般的？ SNS -> SQS -> リソース

流れ

• トピックの作成

  • まず、特定のイベントやサブジェクトに関連するメッセージの集合に対応するトピックをSNSで作成します。

• サブスクリプション

  • 次に、そのトピックにメッセージを受け取りたいエンドポイント（例: Email, SMS, AWS Lambda, SQSなど）をサブスクライブします。サブスクリプションを作成する際には、通知を受け取る方法やエンドポイントの詳細を指定します。

• メッセージの発行

  • APIなどからトピックにメッセージが発行されると、そのメッセージはサブスクライブされているすべてのエンドポイントに配信されます。
  • 例えば、あるトピックにEメールとLambda関数をサブスクライブしている場合、そのトピックにメッセージが発行されると、指定されたEメールアドレスにEメールが送信され、同時にLambda関数も実行されます

AWS SQS(Amazon Simple Queue Service)とは

SQSはAmazon Web Services（AWS）の提供する完全にマネージドなメッセージキューイングサービスです。アプリケーション間でメッセージを送受信する際のスケーラビリティ、信頼性、簡単な統合を提供します。

送信サービス -> SQS -> 受信サービス
あるサービスからからメッセージを受け付け、SQSをポーリングしている受信サービスがメッセージを受け取り、特定の処理を実行する
(後述するSNSとSQSの連携例がわかりやすいかもしれない)

特徴

• スケーラビリティ

  • SQSは、トラフィックの増減に関わらず、無限にスケーリングすることができます。

• 信頼性

  • メッセージは複数のサーバーに冗長に保存されるため、メッセージの喪失を防ぐことができます。

• デリバリー保証

  • SQSは、メッセージが少なくとも一度は処理されることを保証します。

• デッドレターキュー

  • 繰り返し処理に失敗するメッセージを特定のキューに移動させることができます。

• 動的な可視性タイムアウト

  • メッセージの再処理を制御することができます。

• スケーリングとスループット

  • SQSは高いスループットを持ち、大量のメッセージを効率的に処理する能力があります。これにより、突発的なトラフィックの増加や大量のメッセージが突如発生した場合でも、メッセージは確実にキューに保存され、順次処理されます。

SNSでSQSを使うメリット

• SNSとSQSを組み合わせることで、SQSの特徴を享受でき、SQSを利用してファンアウト構造をよりシンプルに、よりスケーラブルに実現できる。
• SNSの特定の特定をSQSがサブスクライブすること
• SNSだけでもできるけで、SQLを使うことでより信頼性、冗長性が向上するということ

SQSを用いたファンアウト構成

コンシューマは、通常、キューを定期的にポーリングして新しいメッセージが来ていないかを確認します。メッセージが存在する場合、コンシューマはそのメッセージを取得して処理を行い、処理が完了したらそのメッセージをキューから削除します。

SQSを用いたファンアウトシナリオ例

オンラインストアでの商品の購入

消費者購入 - > API実行 -> SNSトピックにパブリッシュ -> 複数のSQSがサブスクライブ　-> 複数のコンシューマが受信して特定処理を実施
(メッセージ: 「商品が購入された」というイベントを示すメッセージがSNSによって発行)

• 複数のコンシューマ:
  • 在庫管理システム: 購入された商品の在庫を減少させる。
  • 会計システム: 購入情報に基づいて請求処理を行う。
  • 通知システム: 購入者に購入完了のメール通知を送る。
  • 統計・分析システム: 購入データを集計し、分析やレポートを作成する。

上記のシナリオで、SNSを使って「商品が購入された」という一つのメッセージを発行(SNSトピックにパブリッシュ)すると、それぞれのSQSキューにそのメッセージが配信されます。
各SQSキューに関連付けられたコンシューマ（在庫管理、会計、通知、統計・分析）は、そのメッセージを受け取って独自の処理を行います。

このように、一つのイベント（メッセージ）が発生した際に、それに関連する複数のタスクを並列に、かつ効率的に処理することが可能になります。SNSとSQSを組み合わせることで、このようなファンアウト構造をシンプルに、スケーラブル(SQSのメリットの享受)に実現できるのです。