SNSとSQSでpub-subな仕組みを構築するための検討

SNSトピックに {"command":"mail.send", param:{"name":"moge"}} みたいなのを投げるとjob queueが動くみたいなのを作りたかったので検討。

SNS -> SQS -> Lambda みたいな構成。

SNSの上限

https://docs.aws.amazon.com/ja_jp/general/latest/gr/sns.html

• メッセージを送信するAPIはpublish
  • 標準topic 東京リージョンは秒間1500call、バージニアは秒間30000call
  • FIFO topicは秒間300callかメッセージのデータ総量が秒間10MBのどちらか

SQSの上限

https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html

• メッセージをqueueするAPIはSendMessage
  • 標準 queueはほぼ無制限。かっこいい
  • FIFO queueは秒間300call。
    • SendMessageで送った場合は秒間300メッセージ
    • SendMessageBatchで10個まとめて送れば秒間3000メッセージ
  • 高スループットはFIFO queueの10倍の性能が出る
    • SendMessageで送った場合は秒間3000メッセージ
    • SendMessageBatchで10個まとめて送れば秒間30000メッセージ
    • 価格表では高スループットで別途価格が増えるとは書いてないので、単純に処理が増えた分のapi call分だけ料金がかかるという感じっぽい？

システム要件との比較

今のシステムは秒で300リクエストを飛ぶことはないので、FIFOのtopic、queueで問題なさそう。

FIFOから標準queueとか、us-east-1に移行とかすればスループットを稼げるが、秒間300callを超えるような規模感になっている時点で現在のインフラが耐えられないので変えないとダメだと思う。よってその時になってから考えればいいし、その時はkinesisとか使えばいいかなという感じ。

まとめ

いける