変更要約: in-scopeサービス網羅(軸B): s2(EventBridge)にKinesis Data Streamsのストリーミング定義・役割・SQS/SNS/Firehoseとの選択基準を追記。
2.1SQS と SNS による疎結合
メッセージキューの SQS（1対1・プル）とパブ/サブの SNS（1対多・プッシュ）の違い、可視性タイムアウト、デッドレターキュー、ファンアウトといった疎結合設計の基礎を理解します。
コンポーネントを直接つながず、間にメッセージを挟むと片方の障害が波及しにくくなります。AWS では SQS（キュー）と SNS（パブ/サブ）が代表的です。
2.1.1SQS と SNS
- SQS：キュー。コンシューマーがプルして1メッセージを1度処理する。ピーク吸収や非同期処理に。
- SNS：パブ/サブ。トピックへ発行すると複数の購読先へプッシュ配信（ファンアウト）。
- 可視性タイムアウト：処理中のメッセージを他のコンシューマーから一時的に隠す時間。短すぎると二重処理、長すぎると再処理が遅れる。
- デッドレターキュー（DLQ）：規定回数失敗したメッセージを退避し、原因調査・再処理する。
- 標準キュー／FIFO キュー：標準＝高スループット・順不同・少なくとも1回。FIFO＝厳密な順序・重複排除（1回限り）。
コンポーネントを直接呼び合うと、片方の障害や過負荷が波及します。間にメッセージングを挟む疎結合が、回復性とスケールの鍵です。SQS（キュー）は「ためて1回ずつ確実に処理」——コンシューマーがプルし、処理が終わるまで可視性タイムアウトで他から隠し、失敗が続けばDLQへ退避します。SNS（パブ/サブ）は「1つの発行を多数へプッシュ」。両者を組み合わせたファンアウト（SNS トピック→複数 SQS キュー）は、同じ通知を複数の処理系へ配り、各々が独立にバッファ・再試行できる定番パターンです。順序や重複排除が要るなら FIFO キューを選びます。
| 観点 | SQS | SNS |
|---|---|---|
| モデル | キュー（1対1） | パブ/サブ（1対多） |
| 配信 | プル | プッシュ |
| 主な用途 | バッファ・非同期処理 | 通知・ファンアウト |
| 特徴機能 | 可視性TO・DLQ・FIFO | トピック・サブスクリプション |
シナリオ：注文の非同期処理。 受注ピークを吸収するため注文を SQS に入れ、ワーカー（Lambda/Auto Scaling）が自分のペースで処理。処理失敗が続くメッセージは DLQ に退避して調査。注文確定の通知は SNS トピックへ発行し、「在庫」「請求」「メール」の各 SQS キューへファンアウトして並行処理。順序が重要な決済は FIFO キューを使用。
混同に注意：
①SQS＝プル・1対1／SNS＝プッシュ・1対多。
②可視性タイムアウトは「短すぎ＝二重処理／長すぎ＝再処理遅延」——処理時間に合わせる。
③DLQ は失敗メッセージの退避（消すのではない）。
④標準（順不同・少なくとも1回）と FIFO（厳密順序・重複排除）を取り違えない。
Q. SQS と SNS はどちらを使う？ ためて1回ずつ処理＝SQS、1つの発行を多数へ＝SNS。両立はファンアウト（SNS→複数 SQS）。Q. 可視性タイムアウトとは？ 処理中メッセージを一時的に隠す時間。処理時間より長めに設定。Q. 標準と FIFO の違いは？ 標準は高スループットだが順不同・少なくとも1回、FIFO は厳密な順序と重複排除（1回限り処理）。
「1度だけ処理・プル＝SQS」「1対多にプッシュ＝SNS」「複数先へ同時配信＝SNS ファンアウト（SNS→複数 SQS）」「失敗メッセージの退避＝DLQ」「順序/重複排除＝FIFO キュー」「処理中に隠す＝可視性タイムアウト」 は DVA で頻出です。
2.1.2この節のまとめ
- SQS＝キュー（プル・1対1・バッファ）／SNS＝パブサブ（プッシュ・1対多・ファンアウト）
- 可視性タイムアウト・DLQ・標準/FIFO（順序・重複排除）を押さえる
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 1つのメッセージを1つのコンシューマーが取り出して処理する、プル型のキューはどれですか？
Q2. 1つのメッセージを複数の購読先へ同時にプッシュ配信したい。何を使いますか？
Q3. SQS で処理に繰り返し失敗するメッセージを退避し、後で調査できるようにする仕組みはどれですか？