SQSとSNSの違いを理解しよう

[トランスクリプション]

イントロダクション

SQSとSNSはAWSのサービスで、名前はとても似ていますが、それぞれの使用例が少し違います。今日のビデオでは、その違いと、それぞれを使うタイミングを見ていきましょう。

それでは、長引くことなく、SQSが何かをさっそく見てみましょう。

SQS（Simple Queue Service）

ちょっと右にずらして、SQSはその頭文字から分かる通り、Simple Queue Service、すなわち「単純なキューサービス」です。AWSのキューサービスで、その名の通り、キューのような振る舞いをします。

SQSはキューサービスであるため、メッセージのプロデューサーとコンシューマーがいます。プロデューサーはメッセージをキューに公開し、そのキュー内にメッセージを一時的に保管し、後で他のアプリケーションが処理できるようにします。

たとえば、ここにAというメッセージをキューに入れたプロデューサーがいるとします。それをSQSのキュー内で待つ2つのコンシューマーが興味を示しています。そして、これらのコンシューマーはプル型の動作をします。例えば5秒ごとにSQSのエンドポイントを呼び出して、新しいメッセージがないかを確認します。

プロデューサーがAメッセージを公開したとすると、その操作を行ったコンシューマーはメッセージを受け取り、それがコンシューマー1に直接渡されます。時間が経ち、プロデューサー2がBメッセージを公開したとすると、コンシューマー1と2はSQSを通してプル操作を続け、もしキューに新しいメッセージがあれば消費し、そのメッセージはコンシューマー2にも渡り得ます。

SQSの興味深いポイントは、そのメッセージは少なくとも一度はコンシューマーによって消費されることです。大多数の場合、例えばCメッセージがキューにある場合、それはこのコンシューマーによっても、あるいはこのコンシューマーによっても消費されるべきではありません。そのメッセージは通常、たったひとつのコンシューマーによってのみ消費されます。ですから、SQSの特徴を考えると、基本的にそれはキューシステムです。つまり、メッセージはキューに残るまま消費されるまで待機します。

ここで面白い点は、メッセージは少なくとも一度は消費される、ということです。SQSはまさに一度だけ消費されることを保証するものではありませんが、少なくとも一回は保証されます。ですので、滅多にありませんが、メッセージが2回消費されることはありうるシナリオですが、起こりにくいものです。

使用例

SQSの使用例としては、特にマイクロサービス間での分離を行うためによく使われます。たとえば、このプロデューサー1とコンシューマー1が、別々のJavaアプリケーションだとしましょう。このキューが両サービス間の連携を分離するためのものだとします。

たとえば、プロデューサー1がユーザー作成を行いたいとします。実際にそれを行うのはコンシューマー1です。ですから、直接コンシューマー1を呼び出す代わりに、プロデューサー1はキューにコマンドを送ります。ユーザーを作成せよ、JSONやペイロードを含めて。それをコンシューマー1が受け取り、消費し、そして実際にそのユーザーの永続化を行います。

このようにして、私たちはサービス間の分離を持っていると言えます。なぜなら、コンシューマー1のサービスが例えばオフラインだった場合に、プロデューサーがそのユーザーの作成を行いたいとしても、メッセージは最長14日間キューに残り続け、その間にコンシューマーが立ち直り、健全な状態でまた消費してユーザー作成を行う時間が与えられるからです。

SQSはマイクロサービスのコンテキストでこのように利用されます。なぜなら、私たちが言うには2つのアプリケーション間での分離を持つからです。良し、SQSはこれで十分ですね。次はSNSについて理解しましょう。

SNS（Simple Notification Service）

SNSはSQSと名前では異なります。SQSはSimple Queue Service、つまり単純なキューサービスを意味します。一方、SNSはSimple Notification Service、すなわち単純な通知サービスです。なので、キューシステムと通知システムのちょっとした違いがあります。

しかし、この通知システムとは実際には何でしょう？

通知システムとは、たとえば私たちのプロデューサーがいて、システム内で何かが起こり、それを様々な異なるチャンネルの消費者たち、たくさんの人に伝えたいとします。

そうやってプロデューサーがSNSにその通知を送ると、SNSはその通知を様々な通信手段にルーティングする知識を持っています。ですから、SNSは例えばAイベントをSQSキューへ送り、それをここに送ります。また別のSQSキューも通じてAイベントを指定することができます。

さらに、通知が来たらすぐにEメールシステムも繋がっていれば、そのイベントAのメールも送ることができます。さらに、SQSをトリガーする以外にも、例えばユーザーの携帯へのプッシュ通知など、他にも様々なオプションがあります。

ですから、SNSはシステム内で何かが起き、そのイベントが多くの人々に通知される必要がある場合に便利です。このコミュニケーションの流れは1対多、いわゆるブロードキャストやパブサブと呼ばれるものです。つまり、プロデューサーはイベントを1度だけ送りますが、SNSはその通知を他のすべての消費者に届ける責任があります。

SNSのポイントは、我々はSQS（先ほど見たように）をSNSと組み合わせることができるということです。ですから、例えば、私たちが放出したBイベントはSQS1に送られますし、このBイベントもSQS2に送られるでしょう。そうすることで、これらのコンシューマーは別々にメッセージを消費します。なぜなら、彼らは異なるキューにいるからです。

たとえば、このBイベントはコンシューマー1によって消費され、例えば10時に起動して処理する場合があります。一方、コンシューマー2は4時にしかそのメッセージを処理しないとしましょう。その場合、Bメッセージはコンシューマー2が起動して消費するまで待たされます。そして、それが起こったら、そのメッセージはキューから取り出され、きちんと処理されます。

SNSの特徴は、基本的に通知システムであるということです。それはパブサブ、ブロードキャストのような形です。つまり、私たちは一度だけ話し、それをみんなに伝えます。目的地はSQS、Eメール、プッシュ通知など、AWSがSNSとの統合を提供している他の多くのオプションがあります。

また、一つのメッセージが多くの消費者に送られるという点も非常に興味深い特徴です。つまり、SQSとは異なり、メッセージが一度だけ消費されるのではなく、SNSではメッセージを送り、それが多くの人々に消費されます。

使用例

たとえば、SNSの一般的な使用例として、イベント主導のシステムが挙げられます。我々がAPI、マイクロサービスのユーザー管理サービスだとこちらのプロデューサーだとします。

特定のユーザーが登録されたら、そのユーザーが作成されたことを示すイベントを放出します。そのイベントが放出されると、そのイベントは例えば2つのキューに向けてリダイレクトされます。それは会社のマーケティング部門のアプリケーション向けのキューかもしれません。または、ここの別の消費者は会社の商品部門かもしれません。

そんなわけで、ユーザーが作成されると、マーケティング部門や商品部門は既に通知を受けていて、たとえばメールを送ったり、特定の割引を提供したり、メールマーケティングを行ったりします。

そのため、私たちはアーキテクチャをイベント主導型にしておくことができます。ですので、システム内でそのイベントが重要な場合、SNSはそれを必要とする全員に送る手助けをします。

結論

それでは、これで終わりです。今日の動画のスタイルが気に入ってもらえたら嬉しいです。内容はSQSとSNSの違いどういったものか理解するための、とても速い概要を説明する動画でした。

何か疑問があったり、提案がある場合は、下のコメントに書いてください。

それでは、去る前にチャンネル登録をして、ソーシャルメディアでのフォローもよろしくお願いします。それでは、また次回！

こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/buildrun/entenda-as-diferencas-entre-o-sqs-e-o-sns-1nfh