疎結合な非同期処理
キュー/通知/イベントで送信側と処理側を切り離し、スパイク吸収・リトライ・スケールを実現する定番パターン。
中級信頼性パフォーマンス効率コスト最適化
このパターンは？
重い処理や急増するリクエストを、直接同期呼び出しせずにいったん「間に箱を挟んで」捌く構成。SAA最頻出の「疎結合」設計です。
- スパイクをバッファして取りこぼさない
- 失敗をリトライ／DLQで安全に退避
- 送信側と処理側を独立にスケール
構成
[フロント/Producer]
│ イベント発生
▼
SNS (同報) ──► 複数の SQS ──► ワーカー(Lambda / ECS) ──► DynamoDB / S3
│
└─ 失敗 ─► DLQ(退避)
別解: EventBridge (内容ベースのルーティング) ──► 各ターゲット
コンポーネントの役割と使い分け
- SQS: バッファ。ワーカーがポーリングし、可視性タイムアウト＋DLQで確実に処理
- SNS: 1イベントを複数へ同報（ファンアウト）。
SNS → 複数SQSが鉄板 - EventBridge: イベントの内容でルーティング、SaaS連携やcronも
- ワーカー: Lambda（短時間）/ ECS（長時間・常駐）
SNS + SQS ファンアウト
「複数システムに同報」かつ「各処理を確実に」なら SNS→複数SQS。SNSで配り、各SQSがバッファ＆リトライ＆DLQを担います。
設計の勘所
- 処理は冪等に（標準SQS/SNSは最低1回配信＝重複し得る）
- 厳密な順序が要るならFIFO
- ワーカーはキューの深さでAuto Scaling
- 大きいペイロードは S3 に置き、メッセージには参照を入れる
Well-Architected の観点
- 信頼性: バッファ・リトライ・DLQで取りこぼさない
- パフォーマンス効率: 送信/処理を独立スケール
- コスト最適化: 必要な時だけ処理、スパイクに過剰投資しない
よくある落とし穴
アンチパターン
- 同期呼び出しのまま重い処理を実行し、フロントがタイムアウト
- 冪等性を考えず、重複メッセージで二重課金/二重登録
- DLQ未設定で、失敗メッセージが無限リトライ or 消失
選び方の早見表
| やりたいこと | 選ぶもの |
|---|---|
| バッファして1対1で処理 | SQS |
| 1イベントを複数へ同報 | SNS(＋複数SQS) |
| 内容で振り分け/SaaS連携/定期実行 | EventBridge |
| 順序付き・再読み込み・ストリーム分析 | Kinesis |
AWS Pattern
疎結合な非同期処理を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
reliability
比較で見る軸
クラウド: AWS / 難易度: intermediate / 関連サービス: 7件
導入後に効く点
キュー/通知/イベントで送信側と処理側を切り離し、スパイク吸収・リトライ・スケールを実現する定番パターン。
先に潰すリスク
パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。
数字・仕様の読み方
- クラウド
- AWS
- 難易度
- intermediate
- 関連サービス
- 7件
- 設計柱
- reliability / performance / cost
判断チェックリスト
- 自社の用途が「reliability / performance」に近いか確認する。
- 強みである「キュー/通知/イベントで送信側と処理側を切り離し、スパイク吸収・リトライ・スケールを実現する定番パターン。」が本当に評価軸になるか確認する。
- 注意点の「パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
reliabilityperformancecostAmazon SQSAmazon SNSAmazon EventBridgeAWS LambdaAmazon ECS / Fargate