AWS Certified Developer - Associate (DVA-C02) #5 Domain 1-4 AWS サービスでの開発 — メッセージングとイベント
#4 DynamoDB までデータを整理したので、次はコンポーネントを 疎に結ぶ非同期メッセージング です。サーバーレスアーキテクチャは同期呼び出しだけではスケールに限界があります。試験は「SQS・SNS・EventBridge・Step Functions のどれを選ぶべきか」をシナリオで繰り返し問います。4 つのサービスの役割を一文でまず整理します。
| サービス | 一行定義 |
|---|---|
| SQS | 作業を キューに溜めて 1 つの消費者が引いて処理 (point-to-point) |
| SNS | メッセージを 複数の購読者に同時発行 (pub/sub、プッシュ) |
| EventBridge | イベントを ルールでルーティング するイベントバス (SaaS・スケジュール統合) |
| Step Functions | 複数のステップを ステートマシンでオーケストレーション |
SQS — キュー #
SQS は生産者がメッセージをキューに入れ、消費者がポーリングして取り出す フルマネージドキュー です。コンポーネントを分離 (decouple) し、処理量を平準化 (バッファリング) します。
標準キュー vs FIFO キュー #
| 区分 | 標準 (Standard) | FIFO |
|---|---|---|
| 順序 | 保証されない (best-effort) | 厳格な順序 |
| 配信 | at-least-once (重複あり) | 正確に 1 回 (重複排除) |
| 処理量 | 事実上無制限 | 制限あり (バッチで向上) |
「順序が重要 / 重複を防ぐ必要がある」なら FIFO、処理量が最優先なら標準です。標準キューは重複がありうるので、消費者は 冪等 でなければなりません。
可視性タイムアウト (Visibility Timeout) #
消費者がメッセージを取り出すと、そのメッセージは 可視性タイムアウト の間、他の消費者には見えません。この時間内に処理して削除すれば終わりで、削除できなければメッセージが再びキューに現れて再処理されます。
試験の落とし穴: 処理に時間がかかるのに可視性タイムアウトが短いと、まだ処理中のメッセージが再び見えて 重複処理 されます。答えは可視性タイムアウトを延ばすか、
ChangeMessageVisibilityで延長することです。
ロングポーリングと DLQ #
- ロングポーリング (Long Polling) — 空の応答を減らすためにメッセージが来るまで (最大 20 秒) 待ちます。空の受信コストを減らす推奨設定です。
- DLQ —
maxReceiveCountの回数だけ処理に失敗したメッセージを別のキューに送って隔離します。毒メッセージ (poison pill) がキューを塞ぐのを防ぎます。
SNS — 発行/購読 #
SNS は 1 つのメッセージを 複数の購読者に同時にプッシュ します。購読者は Lambda、SQS、HTTP/S、メール、SMS などです。SQS が「1 つの消費者が引いていく (pull)」なら、SNS は「すべての購読者に押し出す (push)」です。
ファンアウトパターン (SNS + SQS) #
試験の常連パターンです。SNS トピックに複数の SQS キューを購読 させると、一度発行したメッセージが複数のキューに同時に入り、各キューの消費者が独立して処理します。
- 各消費者が自分のペースで処理 (バッファリング)。
- 1 つの消費者の障害が他の消費者に影響しない。
- 後から新しい購読者 (キュー) を追加しやすい。
「1 つのイベントを複数のシステムがそれぞれ処理する必要があり、各処理の耐久性とリトライが必要だ」の答えが SNS + SQS ファンアウト です。SNS だけだと、購読者が失敗したときにメッセージをバッファリング・再処理するのが難しいです。
EventBridge — イベントバス #
EventBridge はイベントを ルール (rule) でフィルタリングしてターゲット (target) にルーティング するイベントバスです。SNS に似て見えますが質感が異なります。
| 視点 | SNS | EventBridge |
|---|---|---|
| モデル | トピック購読、シンプル・高処理量 | イベントパターンマッチング、豊富なルーティング |
| フィルタリング | メッセージ属性フィルター | イベント内容ベースのパターンマッチング |
| ソース | 直接発行 | AWS サービスイベント・SaaS パートナー・カスタム |
| スケジュール | なし | cron/rate スケジュール 内蔵 |
| スキーマ | なし | スキーマレジストリ |
核心となる区別: シンプルで高速なファンアウトは SNS、多様なソースのイベントを内容ベースでルーティングしたい場合やスケジュールが必要なら EventBridge です。「毎日決まった時刻に Lambda を実行」の答えは EventBridge のスケジュールルールです (旧 CloudWatch Events)。
Step Functions — オーケストレーション #
複数のステップを持つワークフローを ステートマシン で調整します。分岐・並列・リトライ・待機・エラー処理をコードではなく定義 (ASL, Amazon States Language) で表現します。
| タイプ | 適した場合 |
|---|---|
| Standard | 長く (最大 1 年) 実行、正確に 1 回、監査履歴が必要 |
| Express | 短く (最大 5 分) 大量・高頻度のイベント処理 |
「複数の Lambda を順番に・条件付きで呼び出し、失敗時にリトライ/補償処理」が必要なら、Lambda の中で直接呼び出すのではなく Step Functions でオーケストレーションするのが正解です。状態遷移が一目で見え、各ステップのリトライ・エラー処理を宣言的に扱えます。
サービス選択クイック表 #
| 要件のキーワード | 正解 |
|---|---|
| 作業の分離・バッファリング、1 つの消費者 | SQS |
| 順序・重複排除 | SQS FIFO |
| 1 つを複数の購読者にプッシュ | SNS |
| 1 つのイベント → 複数のシステムがそれぞれ耐久処理 | SNS + SQS ファンアウト |
| 内容ベースのルーティング・SaaS イベント | EventBridge |
| 決まった時刻/周期で実行 | EventBridge スケジュール |
| 多段ワークフローの調整・リトライ・分岐 | Step Functions |
試験の出題パターン #
- 「処理量が急増するときにバックエンドを保護しつつ作業を平準化。」 → SQS (バッファ)。
- 「注文は受けた順に、重複なく処理。」 → SQS FIFO。
- 「1 つのイベントを決済・通知・分析システムがそれぞれ処理。」 → SNS + SQS ファンアウト。
- 「GitHub/Datadog のような SaaS イベントに反応。」 → EventBridge。
- 「毎日深夜に整理作業を実行。」 → EventBridge スケジュールルール。
- 「5 段階の承認ワークフローをリトライ・分岐とともに。」 → Step Functions。
- 「メッセージが処理中なのにまた消費された。」 → 可視性タイムアウトの延長。
まとめ #
この記事の要点:
- SQS キュー (分離・バッファ)、標準 (at-least-once) vs FIFO (順序・重複排除)
- 可視性タイムアウト・ロングポーリング・DLQ は SQS 運用の核心
- SNS 発行/購読、SNS + SQS ファンアウト で耐久性のある複数消費
- EventBridge — 内容ベースのルーティング・SaaS・スケジュール
- Step Functions — 多段ワークフローのオーケストレーション (Standard vs Express)
次へ — Domain 1-5 SDK 開発パターン #
サービスをコードで呼び出すとき、繰り返される共通パターンがあります。#6 SDK 開発パターン では、ページネーション、スロットリング対応のための指数バックオフとジッター、冪等性の実装、S3 マルチパートアップロードと presigned URL、そして SDK の認証情報供給チェーンまで見ていきます。