CLF / ドメイン3 クラウドテクノロジーとサービス

重要な内容

Amazon SQS (Simple Queue Service)

は、アプリケーションのコンポーネント間でメッセージ（データ）をやり取りするための、フルマネージドのメッセージキューサービスです。 送信側はキューにメッセージを入れ、受信側は自分のペースでキューからメッセージを取り出して処理します。

CLF では、SQS がコンポーネント間をにする目的で使われること、スタンダードキューと キューの違い、 や との使い分けを判断できることが重要です。

Point
  • SQS = Simple Queue Service の略です。
  • Queue（キュー） は「待ち行列」という意味です。レジの行列のように、メッセージが処理を待つ場所をイメージします。
  • SQS は「メッセージをいったん預かる待ち行列サービス」と覚えます。
  • 和訳

概要

は、サーバーの準備や管理をせずに利用できるメッセージキューです。 メッセージを送る側を「プロデューサー」、受け取って処理する側を「コンシューマー」と呼び、キューが両者の間に入ってメッセージを一時的に保管します。

概要の図 プロデューサーメッセージ送信側 SQS キューメッセージを保管 コンシューマーメッセージ処理側

代表的な使い道は、注文処理やバッチ処理などの非同期処理、アクセス急増時の処理待ちのバッファ、間のデータ連携です。 受信側が一時的に停止したり処理が追いつかなくなったりしても、メッセージはキューに残るため失われにくくなります。

試験では、「コンポーネントをにしたい」「処理の負荷を平準化したい」という要件で SQS を選べるか、そして や とどう使い分けるかを判断します。

主要技術

①キューとメッセージの基本

では、まずキューを作成し、そこにメッセージを送信します。 メッセージは複数のサーバーに冗長に保存され、コンシューマーが処理して削除するまで、設定した保持期間の間キューに残ります。

SQS はフルのため、利用者はキューを動かすサーバーの管理や容量の見積もりをする必要がありません。 負荷の増減に合わせて自動的にスケールし、料金はリクエスト数などに応じたです。

Point
  • プロデューサー（Producer） は「生産者」、つまりメッセージを作って送る側です。
  • コンシューマー（Consumer） は「消費者」、つまりメッセージを受け取って処理する側です。
  • 和訳

②コンポーネントの疎結合（デカップリング） ⚠️ 頻出

の最大の目的は、コンポーネント間の（デカップリング）です。 コンポーネント同士が直接やり取りする密結合の構成では、受信側が停止すると送信側も影響を受け、処理やデータが失われるおそれがあります。 間に SQS を挟むと、送信側はキューに入れるだけで次の作業へ進め、受信側は自分の処理能力に合わせてメッセージを取り出せます。

②コンポーネントの疎結合（デカップリング） ⚠️ 頻出の図 密結合の構成 SQS による疎結合の構成 直接呼び出し 停止すると全体が影響を受ける Web サーバー 処理サーバー Web サーバー SQS キュー 処理サーバー

疎結合にすると、次のような利点があります。

  • 受信側が一時的に停止しても、メッセージはキューに残り、復旧後に処理を再開できます。
  • 送信側と受信側を別々にスケールでき、片方の変更がもう片方へ影響しにくくなります。
  • アクセスの急増時も、キューがバッファとなって受信側の処理を平準化できます。
Point
  • デカップリング（Decoupling） は「切り離すこと」、疎結合（Loose Coupling） は「ゆるいつながり」という意味です。
  • Couple（結合する） に、否定の De- が付いた形です。
  • 試験では「decouple」「疎結合」「コンポーネントを分離」というキーワードが出たら SQS を第一候補にします。
  • 和訳

⚠️ 頻出: 「アプリケーションのコンポーネントを疎結合（デカップリング）したい」という要件は、SQS が代表的な答えです。

③スタンダードキューとFIFOキュー ⚠️ 頻出

には 2 種類のキュータイプがあります。 順序や重複の扱いが異なるため、要件に合わせて選びます。

項目スタンダードキューキュー
配信順序ベストエフォート（順序が入れ替わる可能性あり）送信した順序を保証
配信回数少なくとも1回（同じメッセージが重複して届く可能性あり）重複なく1回だけ処理
ほぼ無制限で非常に高いスタンダードより制限あり
判断ポイント順序や重複を気にせず、大量のメッセージを高速に処理したい場合に選びます。銀行取引や在庫更新のように、順序の保証と重複の排除が必要な場合に選びます。
Point
  • FIFO = First-In, First-Out（先入れ先出し） の略です。先に入れたメッセージが先に出てきます。
  • スタンダードキューは「at-least-once（少なくとも1回）」配信のため、まれに同じメッセージが2回届くことがあります。
  • FIFOキューは「exactly-once（正確に1回）」の処理をサポートします。
  • 「順序」「重複させない」というキーワードが出たら FIFO、と覚えます。
  • 和訳

⚠️ 頻出: 「メッセージの順序保証が必要」「重複処理を避けたい」は FIFO キュー、「とにかく高いスループットが必要で順序は問わない」はスタンダードキューです。

④可視性タイムアウトとデッドレターキュー

CLF では、次の 2 つの仕組みを概念レベルで押さえます。

機能目的判断ポイント
あるコンシューマーが処理中のメッセージを、一定時間ほかのコンシューマーから見えなくします。同じメッセージを複数のコンシューマーが同時に処理するのを防ぎます。
（DLQ）何度受信しても処理に失敗するメッセージを、別のキューへ隔離します。失敗メッセージを分離して、原因調査やデバッグに使います。

可視性タイムアウトの間に処理と削除が完了しないと、メッセージは再びキューに現れ、別のコンシューマーが受信できるようになります。 これにより、処理の途中でコンシューマーが停止してもメッセージは失われません。

Point
  • 可視性タイムアウト = Visibility Timeout です。Visibility は「見えること、可視性」という意味です。
  • DLQ = Dead-Letter Queue（デッドレターキュー） の略です。配達できなかった「死んだ手紙（dead letter）」の保管場所のイメージで覚えます。
  • 和訳

⑤ポーリング（プル型）の仕組み

はプル型のサービスです。 キューがコンシューマーへメッセージを送り付けるのではなく、コンシューマー側からキューへ「メッセージはありますか」と問い合わせ（）て取り出します。

ポーリング方式動作判断ポイント
ショートポーリング問い合わせに対して、メッセージがなくてもすぐに応答を返します。既定の動作です。空の応答が増えやすくなります。
メッセージが届くまで一定時間待ってから応答します。空の応答が減るため、リクエスト数を抑えてコスト削減につながります。
Point
  • プル（Pull）型は受信側が「取りに行く」方式、プッシュ（Push）型は送信側が「送り付ける」方式です。
  • SQS はプル型、SNS はプッシュ型です。この対比は試験で狙われます。
  • 和訳

⑥SNS・EventBridgeとの使い分け ⚠️ 頻出

とよく比較されるメッセージング系サービスに、 と があります。 配信モデルの違いで使い分けます。

サービス配信モデル主な用途判断ポイント
Amazon SQSキュー（プル型）非同期処理、負荷のバッファリング、メッセージを溜めて、コンシューマーが自分のペースで1件ずつ処理したい場合に選びます。
Amazon SNSPub/Sub（プッシュ型）複数の宛先への同時通知（）、メール・SMS・モバイルプッシュ通知1つのメッセージを多数のサブスクライバーへ即時に配信したい場合に選びます。
Amazon EventBridgeイベントバスAWS サービスや のイベントをルールで振り分けるアーキテクチャイベントの内容に応じて、条件（ルール）で複数のターゲットへルーティングしたい場合に選びます。

SNS と SQS は組み合わせて使うこともできます。 SNS トピックに複数の SQS キューをサブスクライブさせると、1つのメッセージを複数のキューへ同時に配信できます（ファンアウトパターン）。

⑥SNS・EventBridgeとの使い分け ⚠️ 頻出の図 パブリッシャー SNS トピック SQS キュー A注文処理 SQS キュー B分析処理 Eメール通知
Point
  • Pub/Sub = Publish/Subscribe（出版/購読） モデルの略です。発行者（Publisher）がトピックへ発信し、購読者（Subscriber）が受け取ります。
  • ファンアウト（Fan-out） は、扇（fan）が開くように1つのメッセージを複数の宛先へ広げる配信パターンです。
  • 和訳

⚠️ 頻出: 「1対1でメッセージを溜めて処理」は SQS、「1対多へ即時にプッシュ通知」は SNS、「イベントをルールで振り分け・SaaS 連携」は EventBridge です。

試験対策

CLF の問題では、まず「メッセージを誰が、どのように受け取るか」を確認します。 受信側が取りに行って1件ずつ処理するなら 、多数の宛先へ同時に押し届けるなら 、イベントの内容で振り分けるなら と整理します。

問題文のキーワード優先して考える機能・サービス理由
コンポーネントを（デカップリング）にするAmazon SQSキューを挟むことでコンポーネント同士を分離できます。
処理の急増をバッファリング・平準化Amazon SQSメッセージをキューに溜め、受信側のペースで処理できます。
メッセージの順序保証・重複の排除SQS キュー先入れ先出しと重複のない処理をサポートします。
高で順序は問わないSQS スタンダードキューほぼ無制限のスループットを持つ既定のタイプです。
複数のサブスクライバーへ同時に通知Amazon SNSPub/Sub 型で配信ができます。
メール・SMS・モバイルへのプッシュ通知Amazon SNS多様なへのプッシュ配信に対応します。
AWS サービスのイベントをルールで振り分けAmazon EventBridgeイベントバスとルールでターゲットへルーティングします。
処理に失敗したメッセージを隔離して調査（DLQ）失敗メッセージを別キューに分離できます。
同じメッセージの同時処理を防ぐ処理中のメッセージを他のコンシューマーから隠します。
既存のメッセージブローカー（ActiveMQ / RabbitMQ）からの移行標準プロトコル互換のマネージドブローカーです。

よくある誤答パターンは次のとおりです。

  • SQS と SNS の取り違えです。SQS はプル型のキュー、SNS はプッシュ型の通知です。「通知を送る」なら SNS、「処理を溜めて順に片付ける」なら SQS を選びます。
  • 「順序」という言葉がないのに FIFO キューを選ぶパターンです。順序保証や重複排除の要件がなければ、スループットの高いスタンダードキューが基本です。
  • メッセージキューの問題で Amazon MQ を選ぶパターンです。Amazon MQ は既存のメッセージブローカーからの移行向けで、新規のクラウドネイティブなアプリケーションには SQS や SNS が推奨されます。
  • SQS がメッセージをコンシューマーへ自動的にプッシュすると考えるパターンです。SQS はコンシューマーがで取りに行くプル型です。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください