Amazon SNS+SQSによるFanoutシナリオの話

株式会社エクストーン 豊田陽一

今日のお話

❏ Amazon SQS・SNSについて❏ 「ファンアウト」シナリオ❏ 応用例

Amazon SQSシンプルなメッセージキュー

→ メッセージをキューに入れる・読む・削除する

● 利用例○ 非同期処理のタスクキュー○ 定時バッチ処理の未処理分作業リスト○ etc.

Amazon SNSプッシュ通知サービス

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

Amazon SNSTopic

Subscription

メッセージを受信する通信チャネル。通知を行いたいイベントが発生した場合、Topicに対してメッセージを送信する。

Topicのメッセージ送信先。Topicに登録することで、Topicにメッセージを送信した際にSubscriberに送信される。SubscriberにはiOSやAndroid等のPush通知先やメールアドレス、Amazon SQSキューなどがある。

「ファンアウト」シナリオ

一つの入力に対し、複数の出力が接続される→ Fan(扇状の)-Out(出力)

入力: Amazon SNS出力: 複数のAmazon SQSキュー (もしくは他の通知)

「ファンアウト」シナリオ

ゴール● イベントをトリガーにする複数の処理の分離● 処理の追加時にイベント発火側の修正が不要にする● 処理を行う側の修正も不要にする● イベントの履歴を残す

応用例

ECサイトで商品の注文を受ける処理

● 商品の注文完了→ ユーザーに確認メール送信→ ユーザーの注文履歴更新→ 倉庫システムに商品の発送依頼→ 決済システムにクレジットカードの支払情報送信

応用例

ECサイトで商品の注文を受ける処理● 注文完了時にメッセージを送るSNS Topicを作成

→ 以下のSQSキューをSubscriberとして登録■ 確認メール送信用のキュー■ 注文履歴更新用のキュー■ 倉庫システム通信用のキュー■ 決済システム通信用のキュー

→ 上記の処理を行うジョブワーカーをそれぞれ実装

得られるメリット

● メール送信等の処理が失敗しても、他の処理に影響しない● 処理が失敗した場合、リトライ処理が容易に実装可能

○ SQSのキューのメッセージを削除しなければいい

● 依存関係を変更したい場合の改修が容易○ 例: 決済処理が完了してから発送処理したい！

■ 注文完了TopicのSubscriberからSQS発送キューを削除する■ 決済完了Topicを新しく作り、そのSubscriberにSQS発送キューを追

加■ 決済処理を行うWorkerが正常完了時にSNS Topicに通知を送る

考えられるデメリット

● SNSの料金が追加でかかる○ システム全体の割合から言えば微々たるもの

● SNSのメッセージ通信処理時間が多少長い○ 送信時に25ms～50msくらい

■ あくまでSQSに直接メッセージ送る処理時間と比較して■ 単純にSQSを利用したジョブキューをSNSに置き換えようとしている場

合は少しだけ注意

終わりに

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