SNS+SQSによるファンアウトシナリオの実現によるメリットについてのお話

1. Amazon SNS+SQSによる
Fanoutシナリオの話
株式会社エクストーン 豊田陽一

2. 今日のお話
❏ Amazon SQS・SNSについて
❏ 「ファンアウト」シナリオ
❏ 応用例

3. Amazon SQS
シンプルなメッセージキュー
→ メッセージをキューに入れる・読む・削除する
● 利用例
○ 非同期処理のタスクキュー
○ 定時バッチ処理の未処理分作業リスト
○ etc.

4. Amazon SNS
プッシュ通知サービス
→ 様々なサービスにプッシュ形式で通知を送信
○ Android
○ iOS
○ その他多くのOSへの通知
○ Amazon SQS

5. Amazon SNS
Topic
Subscription
メッセージを受信する通信チャネル。通知を行いたいイベントが発生した場合、
Topicに対してメッセージを送信する。
Topicのメッセージ送信先。Topicに登録することで、Topicにメッセージを送信し
た際にSubscriberに送信される。SubscriberにはiOSやAndroid等のPush通知
先やメールアドレス、Amazon SQSキューなどがある。

6. 「ファンアウト」シナリオ
一つの入力に対し、複数の出力が接続される
→ Fan(扇状の)-Out(出力)
入力: Amazon SNS
出力: 複数のAmazon SQSキュー (もしくは他の通知)

7. 「ファンアウト」シナリオ
ゴール
● イベントをトリガーにする複数の処理の分離
● 処理の追加時にイベント発火側の修正が不要にする
● 処理を行う側の修正も不要にする
● イベントの履歴を残す

8. 応用例
ECサイトで商品の注文を受ける処理
● 商品の注文完了
→ ユーザーに確認メール送信
→ ユーザーの注文履歴更新
→ 倉庫システムに商品の発送依頼
→ 決済システムにクレジットカードの支払情報送信

9. 応用例
ECサイトで商品の注文を受ける処理
● 注文完了時にメッセージを送るSNS Topicを作成
→ 以下のSQSキューをSubscriberとして登録
■ 確認メール送信用のキュー
■ 注文履歴更新用のキュー
■ 倉庫システム通信用のキュー
■ 決済システム通信用のキュー
→ 上記の処理を行うジョブワーカーをそれぞれ実装

10. 得られるメリット
● メール送信等の処理が失敗しても、他の処理に影響しない
● 処理が失敗した場合、リトライ処理が容易に実装可能
○ SQSのキューのメッセージを削除しなければいい
● 依存関係を変更したい場合の改修が容易
○ 例: 決済処理が完了してから発送処理したい！
■ 注文完了TopicのSubscriberからSQS発送キューを削除する
■ 決済完了Topicを新しく作り、そのSubscriberにSQS発送キューを追
加
■ 決済処理を行うWorkerが正常完了時にSNS Topicに通知を送る

11. 考えられるデメリット
● SNSの料金が追加でかかる
○ システム全体の割合から言えば微々たるもの
● SNSのメッセージ通信処理時間が多少長い
○ 送信時に25ms～50msくらい
■ あくまでSQSに直接メッセージ送る処理時間と比較して
■ 単純にSQSを利用したジョブキューをSNSに置き換えようとしている場
合は少しだけ注意

12. 終わりに
SNS+SQSでイベント通知と処理を分離
● 並列処理が楽！
● エラー処理・リトライ処理も楽！
● 改修も楽！