おはようございます、YASUです。
DVAの勉強を進めていて、一番「どれがどれだか分からなくなった」のが、SQS・SNS・EventBridgeの3つでした。どれも「サービス同士をつなぐ」という似た役割に見えて、模擬試験で何度か選択肢を取り違えてしまいました。今日は、自分が混乱したポイントと、どう整理して理解したかを書き残しておきます。
結論
3つの違いは「誰が、どのようにメッセージを受け取るか」で整理すると、一気に分かりやすくなりました。SQSは「受け手が自分で取りに来る(プル型の待ち行列)」、SNSは「届け先全員に一斉に配る(プッシュ型の一斉送信)」、EventBridgeは「ルールに従って、イベントの種類ごとに適切な宛先へ振り分ける(仕分け役)」でした。
最初に混乱した原因
3つとも、AWS公式の説明では「メッセージングサービス」「イベント連携」のようにひとくくりにされがちで、違いがぼんやりしたまま学習を進めていました。模擬試験で「ある処理を非同期で繋ぎたい」という問題が出た時、3つとも正解に見えてしまうのが、一番厄介なところでした。
SQS:受け手が自分のペースで取りに来る「待ち行列」
SQSは、送られたメッセージをキュー(待ち行列)に一時的に溜めておき、受け取る側が自分のタイミングで取りに行く仕組みです。レストランの注文票が厨房に並んで、料理人が手の空いたタイミングで1枚ずつ取っていく様子をイメージすると、しっくりきました。
- 受け手が不在でも、メッセージは最大14日間保持される
- 処理速度の違うサービス同士を繋ぐ時、速度差を吸収する「バッファ」になる
- 処理に失敗したメッセージは、デッドレターキュー(DLQ)という別のキューに退避できる
特に引っかかったのが「可視性タイムアウト」という概念でした。受け手がメッセージを受け取ると、そのメッセージは一定時間(デフォルト30秒)だけ、他の受け手から見えなくなります。これは「処理時間の上限」ではなく、「その間は自分が独占して処理しているから、他の人は触らないでね」という意味合いだと理解して、ようやく腑に落ちました。SQSとLambdaを組み合わせる場合、AWS公式は「可視性タイムアウトをLambda関数のタイムアウトの6倍以上に設定する」ことを推奨しているそうです。
SNS:全員に一斉に配る「放送」
SNSは、1つのメッセージを、登録している複数の宛先(サブスクライバー)へ一斉に届ける仕組みです。学校の校内放送のように、1回アナウンスすれば、聞きたい人全員に同時に届きます。
- プッシュ型:メッセージが発行された瞬間に、サブスクライバーへ配信される
- 1つのメッセージを、Lambda、SQS、メール、モバイル通知など、複数の宛先へ同時に送れる(ファンアウト)
- 受け手が不在の場合、SQSのように保持はされず、再試行のうえ破棄される(DLQを設定すれば退避は可能)
この「SNSは受け手が不在だと保持しない」という点が、SQSとの決定的な違いでした。SQSは「溜めておく」、SNSは「その場で配る」という性質の違いです。
EventBridge:イベントを仕分けて、適切な宛先に届ける「交通整理」
EventBridgeは、さまざまな場所から発生するイベントを、あらかじめ決めたルールに従って、適切な宛先へ振り分ける仕組みです。駅の改札で、行き先ごとに利用者を案内する駅員さんのようなイメージでした。
- イベントの内容に応じて、どのターゲット(Lambda、Step Functions、SQS、SNSなど)に送るかをルールで細かく制御できる
- AWSの各サービスだけでなく、サードパーティのSaaSとも連携できる
- SNSやSQSが直接はできない、サードパーティSaaSとの統合に強い
最終的にたどり着いた、3つの使い分け
SQS → 溜めておいて、受け手のペースで処理させたい(デカップリング・バッファリング)
SNS → 同じ内容を、複数の宛先に一斉に届けたい(ファンアウト通知)
EventBridge → イベントの種類ごとに、宛先と条件を分けたい(ルールベースの振り分け)これを、試験問題を読む時の判断軸にしました。「処理速度の違うサービスを繋ぎたい」ならSQS、「1つの通知を複数に配りたい」ならSNS、「イベントごとに宛先を変えたい、SaaSと連携したい」ならEventBridge、という具合です。
SNSとEventBridgeで迷った時
特に迷ったのが、SNSとEventBridgeの境目でした。調べて見つけたのが、「受け手が固定で、同じものをそのまま配るならSNS。イベントの種類が増え続け、宛先ごとに条件や整形が必要ならEventBridge」という整理です。単純な一斉送信に、EventBridgeのルール管理という手間を持ち込む必要はない、という考え方は、以前紹介したモジュール化や、Step Functionsの回での「用途に合った道具を選ぶ」という話とも共通していると感じました。
組み合わせて使うパターン
実際のアーキテクチャでは、これらは単独で使うだけでなく、組み合わせて使われることが多いようです。代表的なのが「SNS+SQSのファンアウト」で、SNSで1つのメッセージを複数のSQSキューへ配り、それぞれのキューで別々の処理を非同期に行う、というパターンです。SNSの「一斉に配る」性質と、SQSの「溜めておく」性質を組み合わせることで、受け手が不在でもメッセージを失わずに、複数の処理を並行して進められます。
まとめ
- SQSは受け手が取りに来る待ち行列、最大14日間メッセージを保持でき、速度差を吸収するバッファになる
- SNSは登録した宛先全員に一斉に配るプッシュ型で、受け手不在時は保持されない
- EventBridgeはルールに基づいてイベントを仕分けるサービスで、SaaS連携にも強い
- 可視性タイムアウトは「処理時間の上限」ではなく「独占時間」と理解すると腑に落ちる
- SNS+SQSのファンアウトのように、組み合わせて使うパターンも多い
3つとも似た役割に見えて、実は「誰が、どのように受け取るか」という軸で、きれいに分けて整理できました。この整理で、次の模擬試験ではどう変わるか楽しみです。それでは、また明日!
コメント