Amazon SNS と Amazon SQS (通知とバッファ)

概要

(Simple Notification Service) は、1つのメッセージを複数の購読者へ一斉に送る通知サービスです。 (Simple Queue Service) は、メッセージを一時的にためておき、受け手が自分のペースで取り出すキューです。データパイプラインでは、SNS で成功・失敗のアラートを送り、SQS で処理の負荷を平準化します。

主要技術

の、のルール ( ジョブの FAILED、の実行失敗など)、Step Functions の Catch からトピックへ送り、メール、、、などの購読者へ届けます。担当者への通知は SNS、と覚えます。購読ごとにポリシーを設定すると、メッセージの属性 (例: severity が critical) に一致したものだけをその購読者へ届けられます。

② SQS による負荷の平準化

取り込みが急増しても、メッセージをにためておけば、や処理側は追いつける速さで取り出せます。 (受信したメッセージを他の受け手から隠す時間) は、処理にかかる時間より長く設定します。順序と重複排除が必要ならキューを使います。FIFO キューの重複排除は5分の間隔の中で同じ重複排除 ID を除くもので、から FIFO キューへ配るには FIFO トピックが必要です (標準トピックは FIFO キューへ配信できません)。から SQS へ直接送り、Lambda のイベントソースマッピングの最大数で取り出す速さを抑えると、ピークの受信を失わずに下流のデータベースを守れます。

③ DLQ

何度処理しても失敗するメッセージは、最大受信数 (maxReceiveCount) を超えた時点でへ移し、原因を調べてから元のキューへ戻します。DLQ のメッセージ数にのを設定し、で知らせます。アラームには ApproximateNumberOfMessagesVisible を使います。NumberOfMessagesSent は、最大受信数を超えて自動で DLQ へ移ったメッセージを数えないため、DLQ の監視には向きません。

④ SNS → SQS のファンアウト

1つのトピックに複数のキューを購読させると、同じイベントを複数の処理 (たとえば集計用と用) へ独立して配れます。各キューが自分の速さで処理でき、片方の停止がもう片方に影響しません。

試験対策

① 選択基準

「失敗したら担当者にメールで知らせる」は、「急増する取り込みを処理側の速度に合わせる」は、「同じイベントを複数の処理へ独立に配る」は SNS → SQS のを選びます。

② 混同しやすい点

は通知の仕組みではなく、受け手が取り出しに来るまでメッセージを保持するキューです。逆には届けることが役割で、受け手が取り出しに来るまでためておく仕組みではありません。受け手が止まっている間のデータを守りたい場合は、SNS の後ろに SQS を置きます。