Instiq
第2章 · 回復性の高いアーキテクチャの設計·v2.1.0·更新 2026/6/14·読了目安 約9分

変更要約: in-scope サービス網羅: 自動スケーリング(EC2 Auto Scaling)・アプリ統合(MQ/Step Functions/AppSync/AppFlow)・移行/転送(Application Migration Service/DMS/DataSync/Transfer Family/Snow Family)・ハイブリッド接続(Direct Connect/Site-to-Site VPN/Client VPN/Transit Gateway/PrivateLink)を各節に追加

2.2疎結合とメッセージング

この節の要点

Amazon SQS(キュー)と Amazon SNS(パブリッシュ/サブスクライブ)を使ってコンポーネントを疎結合にし、スパイクの吸収やスケーラビリティを高める設計を理解します。

コンポーネントを直接つなぐと、片方の障害や過負荷が全体に波及します。SQSSNS疎結合 にすると、回復性とスケーラビリティが高まります。

2.2.1SQS と SNS

Amazon SQS(キュー:1対1・プル型・作業をバッファしスパイクを吸収)と、Amazon SNS(パブリッシュ/サブスクライブ:1対多・プッシュ型・多数の購読者へファンアウト)を対比した図。
SQS(キュー)と SNS(pub/sub)
  • Amazon SQSメッセージキュー。生産者と消費者を分離し、作業をバッファしてスパイクを吸収する(プル型・基本 1 対 1)。消費者は自分のペースで処理。
  • Amazon SNSパブリッシュ/サブスクライブ。1 つのメッセージを多数の購読者へファンアウトする(プッシュ型・1 対多)。
  • ファンアウト(SNS+SQS):1 つの SNS トピックを複数の SQS キューが購読し、通知を同時配信+各処理を独立にバッファ。
  • EventBridge:イベント駆動の連携(多様な AWS サービス/SaaS のイベントをルールでルーティング)。

コンポーネントを直接呼び合う(密結合)と、片方の障害や過負荷が連鎖し、スケールもしづらくなります。疎結合 は間にキューやトピックを挟み、各コンポーネントを独立させる設計です。SQS は「作業をためて順番に処理」=負荷の波を平準化し、消費者が落ちてもメッセージは残ります。SNS は「1 つの知らせを多数へ同時配信」=通知やイベントの一斉伝達向き。両者を組み合わせたファンアウト(SNS トピック→複数 SQS キュー)は SAA の頻出パターンです。判断軸は「ためて捌く=SQS/多数へ知らせる=SNS」。

観点Amazon SQSAmazon SNS
モデルキュー(1対1)pub/sub(1対多)
配信プル(消費者が取得)プッシュ(購読者へ送信)
主な用途作業のバッファ・平準化通知・ファンアウト

シナリオ:注文処理の疎結合。 受注ピークを吸収するため、注文を SQS キューに入れ、処理ワーカー(Auto Scaling)が自分のペースで消化。注文確定イベントは SNS トピックに発行し、「在庫」「請求」「通知メール」の各 SQS キューへファンアウトして並行処理。どこか1つが遅延・障害でも全体は止まりません。

注意

混同に注意:
SQS=キュー(プル・1対1・バッファ)/SNS=pub/sub(プッシュ・1対多・ファンアウト)
②疎結合は片方の障害の波及を防ぎ、独立スケールを可能にする。
③SQS はメッセージを保持するので消費者障害に強い。
④イベント駆動の汎用ルーティングは EventBridge

補足

Q. SQS と SNS はどちらを使う? ためて順番に処理=SQS、1つの知らせを多数へ=SNS。両立はファンアウト(SNS→複数 SQS)。Q. 疎結合の利点は? 障害の波及防止・独立スケール・スパイク吸収。Q. EventBridge と SNS の違いは? EventBridge は多様なソースのイベントをルールでルーティングするイベントバス、SNS は購読者へのファンアウト中心。

試験ポイント

「作業をバッファ/スパイク吸収=SQS(キュー・プル・1対1)」「1対多の通知/ファンアウト=SNS(pub/sub・プッシュ)」「SNS+SQS=ファンアウト」の使い分けは SAA で頻出です。疎結合はスケーラブルで回復性の高い設計の鍵。

2.2.2その他の主要 in-scope サービス(アプリケーション統合)

SQS/SNS/EventBridge に加え、疎結合とワークフローのためのサービスがあります。Amazon MQApache ActiveMQ/RabbitMQ 互換のマネージドメッセージブローカーで、JMS/AMQP など既存の標準プロトコルを使うアプリを移行したいときに選びます(新規でクラウドネイティブなら SQS/SNS が基本)。AWS Step Functions複数のサービス呼び出しを状態機械として順序・分岐・リトライ付きでオーケストレーションし、複数ステップの処理を確実につなぎたいときに選びます。AWS AppSyncマネージドな GraphQL APIで、複数データソースを 1 つの API に束ねたいときに。Amazon AppFlowSaaS(Salesforce 等)と AWS の間のノーコードなデータ連携で、定期的なデータ同期が要るときに選びます。

やりたいことサービス
標準プロトコルのメッセージブローカーAmazon MQ
複数ステップのワークフロー制御AWS Step Functions
マネージド GraphQL APIAWS AppSync
SaaS と AWS のノーコード連携Amazon AppFlow

2.2.3この節のまとめ

  • SQS(キュー・プル・バッファ)/SNS(pub/sub・プッシュ・ファンアウト) で疎結合
  • ファンアウト(SNS→複数 SQS)で同時配信+独立処理。疎結合はスケーラビリティと回復性を高める

進捗の記録にはログインが必要です。

理解度チェック

(軽い確認用)

Q1. 生産者と消費者を分離し、作業をバッファしてスパイクを吸収するのに適した AWS サービスはどれですか?

Q2. 1 つのメッセージを多数の購読者へ同時に配信(ファンアウト)するのに適したサービスはどれですか?

Q3. コンポーネントを疎結合にする主な利点はどれですか?

理解度を確認第2章「回復性の高いアーキテクチャの設計」の問題を解く