[AWS] SNS自分用まとめ

SNSとは

• メッセージやトピックの設定、操作、および送信ができる
• 「publish - subscribe（pub - sub）」は定期的なポーリングを行う必要のない「push」通知メカニズムを使って「fan out（一括送信）」できる
• HTTP/SやEメールなどの複数プロトコルに対応

publish - subscribe（pub - sub）

• publisher : 発行者
• subscriber : 購読者

publisher                   →  subscriber
           →   -----------
               |  topic  |  →  subscriber
               -----------
           →   topic owner
publisher                   →  subscriber

代表的機能

Mobile PUSH（プッシュ通知）

• モバイルアプリが起動していなくても通知
• モバイルユーザは通知を受け取るかどうか選択可能
• 通知をきっかけにアプリを起動してもらう

pub-sub

• 分散アプリケーションの結合用とに用いることも可能

Topic Owner（所有者）

• Topicを作成し管理する
• TopicはPublisherがメッセージを送信しSubscriberが通知を受信するための通信チャンネルとして機能します

Subscriber（購読者）

• Subscriberは購読したいTopicを選択し購読を開始します
• 購読するTopicごとにFilterPolicyを設定できPublisherから配信されるメッセージをフィルターすることができる

Publisher（発行者

• Publisherは発行したいTopicへメッセージを送信します
• PublisherはSubscriberの購読プロトコルごとにメッセージをカスタマイズして発行できる
  • HTTP/S
  • Email
  • Amazon Labmda
  • etc...
• PublisherとしてAWS Step FunctionsやAmazon CloudWatchなどのAWSサービスを選択可能

配信プロトコル/トランスポート

• HTTP/S
• Email
• Email-JSON
• Amazon SQS
• AWS Lambda
• Platform application endpoint
• SMS

Topicのアクセスコントロール

• AccessPolicyを通じてアクセス制御可能
• デフォルトはTopic Ownerのみアクセス可能

フィルター

Publish時のMessageAttribute

• メッセージに属性を付加することができる
  • メッセージ属性（Message Attribute）
• メッセージ属性を使用してメッセージのフィルタリングが可能になる

SubscriberによるFilterPolicy

• SubscriberがFilterPolicyを設定すると購読中Topicに送られてくるメッセージをフィルタして部分的に受信することが可能

      Message:A Message:B Message:C
                   ⇣
Publisher  ----> Topic ----> FilterPolicy  ----> Subscriber

FilterPolicyの設定

• PublisherはMessageAttributeを設定して送信
• FilterPolicyにマッチしたメッセージをSubscriberが受信
• WhiteList, BlackListどちらでもOK

配信方法

raw message

• SQS, HTTP/Sへの配信時にraw形式つまりPublishされたとおりのmessageが配信されるようにオプトインすることができる

購読プロトコルごとに合わせた発行

• Publisherは購読プロトコルごとにメッセージをカスタマイズして発行できる
  • デフォルトはプロトコルによらず同一メッセージ

{
  "lambda": "lambdaです",
  "sqs": "sqsです",
  "https": "httpsです",
  "email": "emailです",
  ...
}
                                      --> Lambda
                                      --> SQS
Publisher --> Topic --> FilterPolicy   
                                      --> HTTPS
                                      --> Email

リトライ

リトライポリシー

• SNSでは受信したメッセージは即時配信される
• 最初の試行で失敗した場合は次の４段階でリトライを行う
  1. 遅延なしのリトライ
  2. 最小遅延間隔でのリトライ
  3. バックオフモデル（線形または指数的）を使用したリトライ
  4. 最大遅延間隔でのリトライ
• リトライポリシーはエンドポイントによって異なる
• 発行メッセージの信頼性を高めたい場合は（他のトランスポート経由の通知に加えて）SQSにも配信されるようにする

プロトコル	1)即時	2)最小遅延	3)バックオフ	4)最大遅延	最大リトライ
Amazon SQS	10回	20秒間隔で100,000回の再試行	-	-	23日あまりで合計100,000回
Amazon Lambda	-	1秒間隔で2回	1秒から20分まで指数的に10回	20分間隔で38回	13時間あまりで合計50回
Email	1回	10秒おいて1回	10秒から5分まで線形的に10回	5分間隔で90回	7時間あまりで合計102回
HTTP/S	-	-	20秒から60秒まで線形的に3回	-	60秒あまりで合計3回

• HTTP/Sはリトライポリシーをublisherが指定した値で上書きが可能

プライベートな発行

Amazon VPCからプライベートに発行する

• VPC EndpointからSNSへPublishしてSubscribeする
  • すべてAWSCloud内に閉じる

アプリケーション統合

• CloudWatch
• AWS Step Fucntions
• S3
• SQS
• Amazon Lambda

モバイルプッシュ（プッシュ通知）

• Amazon SNS
• Amazon Pinpoint

SQSとPinpointの違い

サービス	特徴
SQS	デバイストークンを運用者が管理できる。特定期間での破棄が義務付けられているときに運用者側で破棄できる。SMSによる通知は単方向通知のみ（購読停止のみ逆方向通知）
Pinpoint	今後は基本的にPinpointを使用してプッシュ通知を実現する。デバイストークンの管理をサービス側で行う。分析ダッシュボードがついてくる。セグメントプッシュでは配信基盤が不要。SMSの双方向通知が可能