アプリケーション統合とコンポーネントの疎結合化
SQS、SNS、EventBridge、Step Functions、API Gateway: 疎結合にして負荷に耐え、障害に耐え、個別にスケールさせます。
- 分野弾力性のあるアーキテクチャ
- 分野高性能なアーキテクチャ
- 図 13
- 出題パターン 10
- サービス 11
5 分で押さえる要点
- 疎結合 (decoupling) = 2 つのコンポーネントの間にキューやイベントバスを置き、一方が遅くなったり壊れたりしても他方を巻き込まないようにすることです。問題文に「負荷の急増」「リクエストを失ってはならない」「処理側が遅い」とあれば、多くの場合間に SQS が必要です。
- SQS はプル型のキューです。consumer が自分でメッセージを取りに行き、各メッセージは 1 つの consumer だけが処理して削除します。ブロードキャストではありません。1 つのメッセージを複数の宛先に届けたいなら SNS fan-out か EventBridge を使います。
- SQS Standard: スループットはほぼ無制限、少なくとも 1 回の配信、順序は保証されません。FIFO: message group ごとに順序どおり、重複なし (5 分間の dedup)。Standard の consumer は、メッセージが 2 回届く可能性があるため冪等である必要があります。
- Visibility timeout: 処理中のメッセージは非表示になります (デフォルト 30 秒、最大 12 時間)。処理が終わったら DeleteMessage が必要で、しないとメッセージが再表示されます。処理が visibility timeout より長い → メッセージが重複処理されます。timeout を延ばすか ChangeMessageVisibility を呼び出します。
- Dead-letter queue (DLQ): maxReceiveCount 回を超えて受信してもまだ失敗するメッセージを DLQ に移し、別途調査します。壊れたメッセージ (poison message) が永遠に再処理されるのを防ぎます。redrive で DLQ から元のキューへメッセージを戻せます。
- Long polling (WaitTimeSeconds 最大 20 秒) は空の受信回数を減らし、コストを下げます。「キューが空のことが多いときに API コール数 / SQS のコストを減らす」と問われたら、long polling を有効にします。
- SNS はプッシュ型の pub/sub です。topic に publish された 1 つのメッセージがすべての subscriber (SQS、Lambda、HTTP、メール、SMS…) に送られます。SNS + 複数の SQS = fan-out: 各システムが専用のキューを持ち、独立して処理し、consumer が一時的に停止してもメッセージを失いません。
- EventBridge: 内容でフィルタするルールを持つイベントバスで、AWS サービス、SaaS アプリケーション、自社アプリからイベントを受け取ります。AWS リソースの状態変化 (EC2 の停止、GuardDuty の検出など) に反応する、または SaaS からイベントを受け取るなら、SNS ではなく EventBridge です。
- Step Functions は retry、catch、待機、並列実行を伴う複数ステップを調整します。Standard は最大 1 年実行、正確に 1 回。Express は最大 5 分で、大量処理向けです。複数ステップのプロセスで、今どのステップにいるかを把握し、ステップごとにエラー処理したいなら、Lambda から Lambda を呼ぶのではなく Step Functions です。
- API Gateway: Lambda やバックエンドの前に置く HTTP/REST/WebSocket の入口で、throttling、キャッシュ (REST)、認証、usage plan を備えます。デフォルトはアカウントごと・リージョンごとに 10,000 リクエスト/秒。integration timeout はデフォルトで最大 29 秒です。
- Amazon MQ はマネージドの ActiveMQ / RabbitMQ で、標準プロトコル (JMS、AMQP、MQTT、STOMP、OpenWire) を話します。標準の message broker を使っているアプリをコードを変えずに AWS へ移すなら Amazon MQ。AWS 上で新規に構築するなら SQS / SNS です。
- Kinesis Data Streams: shard ごとに順序付けられたデータストリームで、保持期間内なら複数の consumer が再読み込みできます。複数のアプリが同じストリームを読む、再読み込みや順序どおりのリアルタイム処理が必要なら Kinesis。1 つの処理で各メッセージを 1 つの consumer が扱うなら SQS です。
- SQS メッセージは最大 1 MiB。それより大きければペイロードを S3 に置き、参照を送ります (extended client library)。古い問題では 256 KB と書かれていますが、現在の SQS の上限は 1 MiB です。
構成図
SQS による疎結合: キューが負荷の急増を吸収
ステップ
- Web は注文を SQS に書き込み、処理を待たずにすぐ顧客へ応答します。
- Worker はメッセージをプルして処理し、結果を書き込んでからキューからメッセージを削除します。
- 滞留メッセージ数が増えると、アラームが scaling policy を起動して worker を追加し、少なければ減らします。
SQS メッセージのライフサイクル: visibility timeout と dead-letter queue
SNS から複数の SQS queue への fan-out
ステップ
- 注文サービスが SNS topic に 1 回だけ publish します。
- SNS はメッセージのコピーを各 queue にプッシュします。メール用 queue は filter policy に一致するメッセージだけを受け取ります。
- 各システムは独立して処理します。システムが一時停止しても、メッセージはそのシステムの queue に残ります。
EventBridge: AWS、SaaS、アプリからのイベントを target へ
ステップ
- AWS サービス、SaaS パートナー、自社アプリがイベントを bus に送ります。
- ルールが EC2 stopped イベントに一致し、Lambda と SNS に送ります。
- ルールが order.created に一致し、Step Functions のワークフローを開始します。
- Archive はイベントを保持し、再処理が必要なときに replay できます。
Step Functions による注文プロセスの調整
ステップ
- API Gateway がワークフローを開始します。各ステップは順に実行され、一時的なエラーは Retry します。
- 決済が完了したら承認依頼を送り、task token を受け取るまで (数日かかることもある) 待機してから結果を書き込みます。
- 決済が完全に失敗した場合: Catch が取り消しステップに移します。
Lambda の前の API Gateway: 顧客ごとの throttling と SQS によるバッファ
ステップ
- 各顧客の API key を専用の usage plan (rate、burst、quota) に紐付けます。超過すると 429 が返ります。
- 注文の読み取り: Lambda が同期処理します (integration timeout はデフォルトで最大 29 秒)。
- 大量のイベント書き込み: API Gateway が SQS に直接送り、worker が後で処理します。
SQS FIFO: message group ごとに順序を保ち、group 間は並列
ステップ
- Producer は MessageGroupId (口座番号) と deduplication ID を付けて送信します。5 分以内の重複メッセージは破棄されます。
- 各 group はメッセージを順に 1 件ずつ配信し、2 つの group は 2 つの consumer で並列に実行されます。
Kinesis Data Streams: 複数の consumer が同じストリームを読む
ステップ
- 同じ partition key のレコードは同じ shard に入り、shard 内で順序が保たれます。
- 3 つのアプリがストリーム全体を読み、それぞれ独自の読み取り位置を保持します。Firehose は S3 に書き込みます。
Amazon MQ: JMS アプリをコード変更なしで AWS へ移行
ステップ
- アプリは EC2 に移行し、引き続き JMS / OpenWire で broker と通信します。
- 2 つの AZ の active/standby が共有ストレージを使います。active が故障すると standby が引き継ぎます。
SQS の short polling と long polling
Step Functions: ステップごとに state の種類を選ぶ
ステップ
- バッチ内の各注文を処理: 分岐なし、異なる分岐の並列実行もなし。
- 各注文に同じステップを繰り返す: Map。
- 各反復の中で在庫を引き当てる Lambda を呼ぶ: Task。
AppSync: 1 つの GraphQL エンドポイントで複数のデータソースを集約
ステップ
- アプリは Cognito にログインし、token を付けて query を送ります。AppSync が token を検証します。
- 1 つの query で、resolver を通じて複数のソースからデータを集約できます。
- Mutation がデータを変更すると、subscribe 中のクライアントは WebSocket ですぐに更新を受け取ります。
統合サービスの選び方
ステップ
- 新しい注文を在庫、請求、メールに届ける: SNS fan-out (通常は各宛先に SQS を 1 つずつ組み合わせる)。
- ある層が別の処理層に仕事を渡し、負荷の急増をバッファする必要がある: SQS。
比較表
SQS、SNS、EventBridge、Kinesis Data Streams
| SQS | SNS | EventBridge | Kinesis Data Streams | |
|---|---|---|---|---|
| モデル | キュー、consumer がプル | Pub/sub、subscriber へプッシュ | イベントバス、内容でフィルタするルール | shard を持つストリーム、consumer は位置で読む |
| 1 メッセージの届け先 | 1 つの consumer | すべての subscriber | 一致したルールのすべての target | すべての consumer (各自で読む) |
| メッセージの保持 | デフォルト 4 日、最大 14 日 | 保持しない (即時配信、retry あり) | 保持しない。replay 用の archive あり | ストリームの保持期間による |
| 順序 | FIFO: message group 内 | FIFO topic: message group 内 | 保証なし | 各 shard 内 |
| 適した用途 | 負荷のバッファリング、worker の疎結合化 | Fan-out、通知 | AWS / SaaS イベントへの反応、ルーティング | ログ、クリックストリーム、IoT、リアルタイム分析 |
SQS Standard と FIFO
| Standard | FIFO | |
|---|---|---|
| 順序 | ベストエフォート、保証なし | 各 message group 内で順序どおり |
| 配信 | 少なくとも 1 回 (重複の可能性あり) | 正確に 1 回 (5 分間の dedup) |
| スループット | ほぼ無制限 | API ごとに 300 TPS (バッチ 10 件で 3,000 メッセージ/秒)。high throughput mode ではずっと高い |
| キュー名 | 任意 | .fifo で終わる必要あり |
| 使う場面 | 大半のワークロードのデフォルト | 銀行取引、注文、順序が必要なコマンド |
Step Functions Standard と Express
| Standard | Express | |
|---|---|---|
| 最大実行時間 | 1 年 | 5 分 |
| セマンティクス | 正確に 1 回 | Async: 少なくとも 1 回、Sync: 最大 1 回 |
| 課金 | state transition の数 | 実行回数、実行時間、メモリ |
| 適した用途 | 長いプロセス、人による承認、決済 | IoT、ストリーム処理、大量処理のバックエンド |
Amazon MQ と SQS / SNS
| Amazon MQ | SQS / SNS | |
|---|---|---|
| プロトコル | JMS、AMQP、MQTT、STOMP、OpenWire | AWS API (HTTPS) |
| 運用 | インスタンス上で動く broker (サイズを選択)、Multi-AZ active/standby | サーバーレス、自動スケール |
| 使う場面 | ActiveMQ / RabbitMQ を使うアプリをコード変更なしで移行 | AWS 上の新規アプリケーション |
よく出る出題パターン
1Web アプリが注文を受け付けます。セール時は注文数が 20 倍になり、処理層が追いつかず注文を取りこぼします。注文を失わず、コストも妥当にする必要があります。
答えを見る
正解: Web と処理層の間に SQS を置き、Auto Scaling group 内の worker を滞留メッセージ数 (ApproximateNumberOfMessagesVisible / インスタンスあたりのメッセージ数) に応じてスケールさせる
キューが急増を吸収し、worker が順次処理するため、注文を失いません。
不正解: 処理層の EC2 のサイズを大きくする
平常時にコストがかかり、それでも上限があります。Web と処理が密結合している問題も解決しません。
不正解: Web と処理層の間に SNS topic を置く
SNS はメッセージを保持しません。consumer が過負荷でもメッセージは即時に配信されなければなりません。
2形式不正のメッセージが consumer をクラッシュさせ、メッセージがキューに戻って何百回も再処理されます。
答えを見る
正解: maxReceiveCount (例: 5) を指定して dead-letter queue を設定する
5 回受信しても削除できなければ、メッセージは DLQ に移って調査でき、他のメッセージをブロックしません。
不正解: visibility timeout を短くする
メッセージが早く戻るだけで、永遠に失敗し続けます。
3consumer は 1 メッセージあたり約 2 分かかります。多くのメッセージが 2 回処理されています。
答えを見る
正解: visibility timeout を処理時間より長くする (または処理中に ChangeMessageVisibility を呼び出す)
visibility timeout はデフォルト 30 秒で、処理が終わる前にメッセージが他の consumer に再表示されます。
不正解: FIFO queue に切り替える
FIFO は送信側の重複を防ぐ (dedup) もので、処理が visibility timeout を超えたときのメッセージ再表示は防げません。
4新しい注文があると、3 つのシステム (在庫、請求、メール) がそれぞれ受け取って独立に処理する必要があります。どのシステムが一時停止してもメッセージを失ってはなりません。
答えを見る
正解: SNS topic から 3 つの SQS queue へ fan-out し、各システムは自分の queue を読む
各 queue はメッセージを最大 14 日保持します。filter policy で各 queue が必要な種類のメッセージだけ受け取るようにできます。
不正解: 3 システムが共通で読む 1 つの SQS queue
各メッセージは 1 つの consumer にしか届かず、3 システムでメッセージを分け合うことになります。
不正解: SNS から 3 システムへ直接 HTTP 送信
システムが長く停止すると retry が尽き、メッセージを失います。
5アカウント内の EC2 instance が stopped 状態になるたびに Lambda を実行する必要があります。
答えを見る
正解: "EC2 Instance State-change Notification" イベントの state = stopped に一致する EventBridge ルールを作り、target を Lambda にする
AWS サービスは自動で default event bus にイベントを送り、ルールが内容でフィルタします。
不正解: 毎分 DescribeInstances を呼び出す Lambda
ポーリングはコストがかかり、遅いです。
不正解: CloudTrail から直接 Lambda に送る
CloudTrail は API ログを記録するもので、イベントルーティングの仕組みではありません。
6注文処理プロセスは在庫確認、決済、配送から成り、数日かかる承認待ちのステップがあります。各ステップの失敗時は retry または取り消しが必要です。
答えを見る
正解: Step Functions Standard (Retry、Catch、承認ステップには .waitForTaskToken コールバック)
最大 1 年実行、正確に 1 回で、実行履歴で各ステップを確認できます。
不正解: 1 つの Lambda が他の Lambda を順に呼び出す
Lambda は最大 15 分で数日は待てず、retry / 取り消しを自作するのは非常に複雑です。
不正解: Step Functions Express
最大 5 分です。
7口座ごとの株式取引は順序どおり、重複なしで処理する必要があります。異なる口座は並列に処理します。
答えを見る
正解: SQS FIFO、MessageGroupId = 口座番号
順序は各 group 内で保たれ、異なる group は並列に処理されます。
不正解: SQS Standard
順序が保証されず、重複配信の可能性があります。
不正解: 全メッセージに共通の MessageGroupId を 1 つ使う FIFO queue
順序は正しいものの逐次処理しかできず、並列性が失われます。
8企業がオンプレミスの ActiveMQ で JMS を使う Java アプリを AWS に移行し、コード変更を最小にしたいと考えています。
答えを見る
正解: Amazon MQ for ActiveMQ
マネージドの broker で JMS / OpenWire プロトコルをそのまま使えます。HA には Multi-AZ の active/standby を有効にします。
不正解: メッセージング部分を SQS で書き直す
コード変更と API の変更が必要です。
9クリックストリームデータを 3 つのアプリ (リアルタイム指標の計算、S3 への保存、不正検知) が同時に読み、エラー時には再読み込みできる必要があります。
答えを見る
正解: 複数の consumer (Lambda、Firehose → S3、独自アプリ) を持つ Kinesis Data Streams
データは保持期間のあいだストリームに残り、各 consumer は独自の位置で読みます。
不正解: SQS Standard
各メッセージは 1 つの consumer だけが受け取り、削除すると消えるため再読み込みできません。
10API Gateway + Lambda の公開 API で、1 つの顧客が大量に呼び出して他の顧客に影響を与えています。
答えを見る
正解: 顧客ごとに個別の throttling と quota を持つ usage plan + API key (REST API)
API の入口で顧客ごとに制限し、超過した顧客には 429 が返ります。
不正解: Lambda の reserved concurrency を増やす
悪い顧客がさらに多く使えるようになるだけです。
早見表
コンポーネント同士をどうつなぐか?
| やりたいこと | 使うもの |
|---|---|
| 2 つの層の間で負荷の急増をバッファし、各ジョブを 1 つの worker が処理 | SQS Standard + メッセージ数に応じた Auto Scaling · 図を見る |
| 順序どおり、重複なしで処理 | SQS FIFO (MessageGroupId) · 図を見る |
| 失敗メッセージが永遠に繰り返される | Dead-letter queue + maxReceiveCount · 図を見る |
| 1 つのメッセージを複数システムへ、システムの一時停止時も失わない | SNS fan-out → 複数の SQS · 図を見る |
| AWS サービスや SaaS のイベントに反応、内容でフィルタ | EventBridge (rule + target) · 図を見る |
| スケジュール実行 (cron) | EventBridge Scheduler |
| 複数ステップのプロセス、retry、承認待ち | Step Functions Standard · 図を見る |
| 大量処理、1 回の実行が短い (5 分未満) | Step Functions Express |
| Lambda / バックエンドの HTTP 入口、顧客ごとの throttling | API Gateway (usage plan) · 図を見る |
| 複数の consumer が同じストリームを読む、再読み込み可能 | Kinesis Data Streams · 図を見る |
| JMS / AMQP / MQTT を使っているアプリ | Amazon MQ · 図を見る |
| GraphQL、モバイルアプリ向けのリアルタイムデータ同期 | AWS AppSync · 図を見る |
落とし穴
- 同じメッセージを受け取る必要がある複数システムに 1 つの SQS queue を使う: SQS はメッセージを分配し、ブロードキャストしません。
- 処理が visibility timeout より長く、メッセージが 2 回処理される。
- 処理後にメッセージの削除を忘れる: メッセージがキューに戻ります。
- dead-letter queue を設定していないため、失敗メッセージが無限に繰り返される。
- 順序が不要で非常に大きなスループットが必要なワークロードに FIFO を選ぶ。
- すべての FIFO メッセージに 1 つの MessageGroupId を使い、なぜ並列で動かないのかと首をかしげる。
- 負荷のバッファリングや consumer 停止時にメッセージを失わないことが求められているのに SNS (メッセージを保持しない) を使う。
- EventBridge ルールではなく CloudTrail やポーリングで「イベントを捕捉」しようとする。
- 長いプロセスに Step Functions ではなく Lambda から Lambda を連鎖的に呼ぶ。
- 5 分を超えて動くプロセスに Step Functions Express を選ぶ。
- コード変更を最小にと求められているのに JMS アプリを SQS に書き直す (正解は Amazon MQ)。
- SQS メッセージの上限を 256 KB と覚えている: 現在は 1 MiB です。
このモジュールのサービス
変わりやすい数値 (AWS ドキュメントで確認済み)
- SQS: メッセージは最大 1 MiB。保持期間はデフォルト 4 日 (1 分〜14 日)。visibility timeout はデフォルト 30 秒、最大 12 時間。delay は最大 15 分。 2026-10-16 確認 ↗
- SQS FIFO: API ごとに 300 トランザクション/秒 (バッチ 10 件で 3,000 メッセージ/秒)。long polling は最大 20 秒。in-flight メッセージは最大 120,000 件。 2026-10-16 確認 ↗
- SNS: topic はデフォルトで 256 KiB までのメッセージを受け付け、1 MiB まで設定可能 (subscriber が SQS、Lambda、Firehose の場合のみ)。 2026-10-16 確認 ↗
- Step Functions: Standard は最大 1 年、正確に 1 回、state transition 数で課金。Express は最大 5 分、実行回数・実行時間・メモリで課金。 2026-10-16 確認 ↗
- EventBridge (classic): ルールあたり最大 5 target。 2026-10-16 確認 ↗
- API Gateway: デフォルトでアカウントごと・リージョンごとに 10,000 リクエスト/秒 (burst 5,000)。 2026-10-16 確認 ↗
- API Gateway REST: integration timeout は 50 ms〜29 秒で、Regional / private API では引き上げ可能。ペイロードは最大 10 MB。 2026-10-16 確認 ↗
- Lambda + SQS: Lambda はメッセージをバッチでプルし、少なくとも 1 回処理します。partial batch response を使い、成功済みメッセージの再処理を避けます。 2026-10-16 確認 ↗
- SQS: short polling は一部のサーバーだけに問い合わせ、空でも即座に返します。long polling (WaitTimeSeconds > 0) はすべてのサーバーに問い合わせ、最大 20 秒待機します。 2026-10-19 確認 ↗
- Step Functions には Task と 7 つの flow state (Choice、Parallel、Map、Pass、Wait、Succeed、Fail) があります。 2026-10-19 確認 ↗
- AppSync: サーバーレスの WebSocket による GraphQL subscription。認証は API key、IAM、Cognito、OpenID Connect または Lambda。 2026-10-19 確認 ↗