【AWS】「SNS」について

SNSとは？

「Simple Notification Service」の略です。

SNSが必要になる背景

よくある企業システムでは複数の処理が複雑に連携し合っている密結合な状態になっています。その中で疎結合にするため色々なアーキテクチャがあります。

独立分散型 + ポーリング

各処理を疎結合にして各処理が新しい処理依頼を受けたかどうか絶えずポーリングするような設計があります。中央の保留場所はそれらの確認に対して適切に回答する必要があります。

ポーリングの問題点

いつ新しい処理がクライアントからくるかがわからないため各処理からの確認行為による中央の保留場所の負荷が高まる点

独立分散型 + ファンアウト（一括送信）

ポーリングには問題があるので一括送信型というPUSH型のアーキテクチャが考えられます。中央の保留場所から各エンドポイントに対してファンアウトを行います。SNSでは基本的にこうしたPUSH型のアーキテクチャを採用しています。

メリット

中央の保留場所で処理が行われるのは処理を受け付けた場合のみでよくなるので中央の負荷が下がる。

SNSのイメージ

push通知メカニズムを使っているのでファンアウト（一括送信）

定期的なポーリングが必要ない。

複数のプロトコルに対応(HTTPS、eメール)している。

代表的な機能

機能としては二つあります。

• Mobile Push
• pub-sub

Mobile Push(プッシュ通知）

• モバイルアプリが起動してくれていないても通知できる。
• モバイルユーザーが通知を受け取るか否か選択できる。
• 通知をきっかけにアプリを起動してもらう。（顧客エンゲージメントの観点でも活用できる。）

publish-subscribe(pub-sub)

通知もできるが、分散アプリケーションの統合用途に使われます。SNSと言えばこちらの用途で使うことが多いです。PublisherがSUBSCRIBERに依存しない非同期のメッセージングモデルになっている。

Publisher

• SUBSCRIBERのことを全く知らない。
• 情報を発信することを使命と心得ており決まった形式でメッセージをTOPICに送信する。
• Subscriberの購読プロトコルごとにmessageをカスタマイズして発行できます。
• PublisherとしてAWS Step FunctionsやCloudWatch EventsなどのAWSサービスを指定できます。

TOPIC

Publisherとsubscriberが共に知っている存在で通信チャンネルとして機能します。これがあることによってPublisherとSubscriberを疎結合にすることが可能です。

TOPIC OWNER

TOPICの管理を行っている人、TOPICを作成したユーザーがTOPICオーナーとなります。

SUBSCRIBER

購読したいTOPICを選び購読を開始します。

Filter Policy

SubscriberがPublisherから配信されるメッセージをフィルタすることが可能です。

Pub/Subがサポートしている配信プロトコル

プロトコル	説明
HTTP/HTTPS	購読登録時にURLを指定する。POSTを通じてURLが届けられる。
email	eメールとしてテキストが送られる。
email-json	通知がJSONオブジェクトとして送信される。
SQS	指定されたキューにmessageを投入する。(FIFOキューは対象外)
Lambda	Lambda関数にmessageを配信する。
Platform application endpoint	サポートされているプラットフォームにpush通知する。
SMS	SMSテキストメッセージとして登録された電話番号に送信する。