SQS
暗号化
サーバー側の暗号化を設定することができる
デフォルトでは有効になっている
キーのタイプが選択することができる
SQS自体が作成、管理、使用する暗号化キーと
KMSと連携して暗号化を自分で管理することも可能
SQSアクセスポリシー
ベーシックタイプとアドバンストがある
ベーシックタイプはシンプルな設定です。
キュー所有者のみにアクセスを許可したり、
指定したAWSアカウントを設定するだけであれば、ベーシックを使います。
アドバンストについては、IAMポリシーのようにJSONオブジェクトを使用して、高度なアクセスポリシーを定義することが可能です。
アクセスポリシーを設定する際は、
キュー自体に送信できるユーザー
キューを受診できるユーザー
それぞれに定義します。
デットレターキューの設定
デットレターキューとは
デッドレターキュー（Dead Letter Queue, DLQ）とは、メッセージキューシステムにおいて、正常に処理できなかったメッセージを特別に保存しておくための専用キューのことです。メッセージが複数回リトライされても処理に失敗した場合や、一定の保持期間を超えた場合などに、そのメッセージは通常のキューからデッドレターキューに移動されます。これは、メッセージ処理の障害やエラーの分析、再処理のために使用されます。
各種設定
許可ポリシーの再実行では、この作成しているキューをデットレターキューとして使用できるソースキューを特定する画面です。
デットレターキューは、有効にした場合、処理に失敗したものを他のキューに送るための設定です。
基本的なユースケース
サービスの疎結合に役立つことが大きな役割です。
LambdaやEC2でアプリケーションを構築して、処理の前にSQSを挟むことで、アプリケーション側でエラーが発生してもSQSでメッセージを保持することができるので、処理内容の情報を失うことを防ぐことができます。
SNSを使って、SQSにメッセージを送ることができます。
１つのメッセージで複数のマイクロサービスが動く場合、サービスごとにSQSを構築して
１つのSNSでメッセージを同時に複数のSQSにパブリッシュすることで、同時にサービスがSQSからポーリングして処理をすることができます。
AWSの試験でも、lambdaと連携してマイクロサービスを構築することや
SNSとの連携もよく出るので、試験を受ける際も押さえておきましょう。
今度はlambdaを使って、疎結合の簡易的なアプリケーションでも作りたいなと思ってます。