SQS
https://gyazo.com/2416340e7eb2f242709a11d4ea25fc4a
ほぼ無制限のスケーラビリティを備えたフルマネージドな分散キュー
Q. ケースバイケースだと思うのですが、どのパターンがベストなのかを判断するポイントというのは、コストとかになるのでしょうか。(LambdaとLambdaをつなげるときに、SQSを使うべきか、StepFunctionsを使うべきか、EventBridgeRuleを使うべきか、など)
A. コストも検討要素のひとつではありますが、アーキテクチャの選択においては要件（この場合特に非機能要件）と制約を満たしていることがポイントとなります。例えば、Lambda関数からLambda関数を呼び出す構成で呼び出されたLambda関数でエラーが発生した場合にデータが失われては困る場合に、間にSQSを間に入れることで可用性の向上を図るなどが考えられます。
hiroki.iconSQSを使う判断ポイントはデータが失われては困る→永続化が必要かどうかだなぁ
https://youtu.be/avfc0gQ7X0A
コンポーネント間の連携検討ポイント
SQSでは非同期、Pull、P2Pのタイプ
#キュー
デッドレターキュー
キューのコンシューマがメッセージの処理に失敗した場合に、そのメッセージを保持するためのキュー
正常に処理することができないメッセージの送信先としてデッドレターキューが使われる
デバッグとか原因調査とかに使う
hiroki.icon処理ありきでSNSのデッドレターキューは到達するかしないかなので、そこが違うポイント
SNS→SQSの連携においてのデッドレターキュー
SNSのサブスクライバーにSQSを指定している時に、処理の失敗を検知するならSQSのデッドレターキュー
SNSとSQSとの連携に懸念がある場合はSNSのデッドレターキュー
hiroki.iconSNSとSQS間の連携が失敗するケースはそうそうないよね
ユースケース
バッファリング
https://gyazo.com/c5a1931729496bc6393c56b994823923
SQSとEC2とAutoScaling(SQSキューの深さに応じて)でスケーラブルなコンピューティング環境にできる
ワークキュー
https://gyazo.com/0ca90503a7058261041b618b68a8594c
リクエストのオフロード
https://gyazo.com/15acd5fd5aacda66ebd039f38d69ec38
ターゲットのファンアウト
https://gyazo.com/e8ead3a5838253a65cf723817e1a1a92
Kinesisとの使い分け
https://gyazo.com/7aa0dcecf0b923643f3547561916ff33