🐷

SQS, SNS, EventBridgeについてまとめてみた

2023/01/21に公開

AWS

Lambda

Serverless

tech

SQSについて

SQSを使って疎結合設計を考えてみる

メッセージ(処理)を投げるプロデューサーから、メッセージを処理するコンシューマーの間にSQSを返すことにより、コンシューマーの処理が忙しく処理できない場合でもキューとしてSQSに処理をためておき、コンシューマーが処理に余裕がある際にポーリンングすることでプロデューサーはコンシューマーを気にせずリクエストを投げることができる。これで疎結合を実現できる。アプリケーション開発における依存関係逆転の法則のようなものですね！

処理をためておくキューですが実は２種類あります！

標準キュー
FIFOキュー

標準キューとはベストエフォートでメッセージが１回以上送られる可能性があり、送信順序も変わってくる

FIFOキューとは送信回数は必ず１回で順番を保証する、ただしこちらは秒間300の制限がある。ただし秒間3000の高スループットモードもある

SQSでエラーになった場合

標準キューやFIFOキューで失敗した場合DLQにメッセージが保存されます。
またDLQにメッセージが入ったタイミングでcloud watchにアラームを発行することも可能であり、失敗した場合迅速に気づけるような設計もすることができます。

遅延キューとメッセージタイマー

プロデューサーからメッセージを受け取り、一定期間後に処理をしたいものがある場合に使用できる。

遅延キューはキュー全体に一定期間後にコンシューマーからポーリングできるようにするもので、メッセージタイマーはメッセージごとに遅延時間を指定することができる。設定できる遅延時間は0~15分でセットできる。

ショートポーリングとロングポーリング

-　ショートポーリング
コンシューマーが要求した際にキューがなかった場合,キューなしですぐに応答を返す方法

ロングポーリング
コンシューマーが要求した際にキューがなかった場合,一定期間待ち、それでもキューが来なかった場合はキューなしで返す方式

一般的にはapiレスポンスを減らすことができるので、ロングポーリングの方が良いと言われている

SNS

特徴

SQS同様疎結合設計に有用である。SQSと違う点はプル型, プッシュ型かの違いになります。
どちらが良いとも言えませんが、使い分けると良い。

上記のような構成でSNSは使用可能, パブリッシャーからSNSへmessageを通知し、
SNSはプッシュ型なので、SQSやLambdaなどに処理を送信する。
補足:
SNSの送信先がLambdaなどのアプリケーションの場合A2Aといい
送信先がクライアントの場合はA2Cといます！

SNSはいくかのトピックを作成することができます。
トピックにより、処理の送信先を分けることも可能です。
下記の画像の例だとgreenトピックとblueトピックがあり、パブリッシャーからグリーンに処理が送信されれば、
SQSに処理を送信し、Blueに処理が送信された場合はlamdbaやhttpエンドポイントに処理が送信されることになる

またトピックに複数のサブスクライバーを登録することで並列に処理をすることが可能

SNSをまとめると以下のような特徴がある

プッシュベースで配信
トピックを利用した多対多のメッセージング方式に向いている(pub/sub方式)
サブスクライバーに登録できるものとしては以下があります。
- SQS
- Lambda
- HTTPエンドポイント
- Kinesis Data Firehose
- SMS
- Eメール
- モバイルプッシュ通知