AWS SNSとSQSをメーリングリストとセンター問い合わせで例えてみる

AWSのSNSとSQSの仕組みについて学んでいて、
しっくり来る例えを思いついたので、少しまとめてみます。

SNSは「メーリングリスト」

まず仕組み自体を少しまとめます。
SNSはサーバを用意せずに「通知機能の仕組みづくり」を実現できるサービス。
メッセージを送るサービスとも言えます。

以下のようにしてPublisherからSubscriberにメッセージが送られます。

送信者側 Publisher

• Topicを作成する
• Topicに対してメッセージを送信する
• 複数の購読者(Subscriber)に対して、一括でメッセージが送信される(いわゆるfan out)

受信者側 Subscriber

• TopicのSubscriberに登録
  • 受信者自ら購読登録はしないが、プロトコルがメールの場合は認証が必要
    • Subscriberの登録はAWSコンソールやCLIにて行う

メーリングリストの仕組みと比べてみる

この仕組みは「メーリングリスト」に似ていると、言えるでしょう。
SNSと対照させながら、メール送信の流れを書きます。

• メーリングリストを受け取るメンバーを管理者が設定画面などで登録する。
  • SNSで言うと：Subscriberを登録する
• メッセージを作成し、メーリングリストのメールアドレスに送る
  • SNSで言うと：topicに対してメッセージを送る
• メーリングリストに登録されている宛先にメールが一括送信される
  • SNSで言うと：Subscriberに対してメッセージがfan outされる
• メッセージの送信者はメーリングリストに誰が登録されているかを気にしなくてよい。
  • SNSで言うと：メッセージ送信にあたり、 Subscriberに誰が、何が登録されているかを気にしなくてもよい。いわゆる「疎結合」の達成。

メーリングリストとの違い

SNSはSubscriberのプロトコルの種類が多いことが違いとして挙げられるでしょう。
メールやショートメッセージ(SMS)やプッシュ通知、HTTPリクエストなど。

SQSは「センター問い合わせ」

SQSはメッセージをキューとして保存し、取り出す仕組みを提供するサービス。
先述したSNSとメッセージングの観点では似たサービスですが、少し趣が異なります。

• プロデューサー(送信側)がSQSに対してメッセージを送る
• SQSがメッセージをキューとして蓄える
• コンシューマー(受信側)がSQSに対してメッセージがたまっていないかを確認し、メッセージがあれば受信する

送ったメッセージは即時では相手には届かず、
受け取り側が自ら取りに行くというという仕組みです。
(送信は完了しているけど、相手には届いていない。)
送った側としては受信側のことは気にせず、「さ、次の処理行こう！」ということができます。 これも「疎結合」

「センター問い合わせ」の仕組みと比べてみる

1990年代後半から2000年前半くらいまでのガラケーにあった、
「センター問い合わせ」に対して、少し近いところがあるためまとめます。
(SQSはサーバレス、センター問い合わせはがっつりサーバに関することですが。。

• 相手がメールを送る
  • SQSで言うと：プロデューサーがメッセージを送る
• メールが携帯電話のキャリアのメールサーバに保存される
  • SQSで言うと：メッセージがキューに入る
• 自分が携帯電話のキャリアのメールサーバに対して新着メールがあるかを問い合わせる(これがセンター問い合わせ)
  • SQSで言うと：コンシューマーがキューに対してメッセージの有無を確認。あれば取得。

SQSというよりは、「ポーリング」の仕組みの説明かもしれませんが、
受け取り側が自らサーバやキューに問い合わせるという行為は近しいものがあるかもしれません。

よく「メール来ているかな？」と少し期待しつつでセンター問い合わせを行ったのが懐かしい。

参考