SQS と SNS

このページで押さえる論点

• 疎結合とキューイング・メッセージングの考え方
• SQS の基本動作（ポーリング、可視性タイムアウト、ロングポーリング、デッドレターキュー）
• SQS の設定値（保持期間・最大メッセージサイズ・遅延キュー）と暗号化
• 標準キューと FIFO キュー（スループット、メッセージグループ ID、重複排除）
• キューの滞留に合わせたコンシューマーのスケーリング
• SNS のパブリッシュ／サブスクライブ、ファンアウト、フィルターポリシー
• EventBridge・Kinesis Data Streams・Amazon MQ・Step Functions との使い分け

疎結合とキューイング・メッセージングの考え方

2 つのシステムが直接呼び出し合う形を密結合と呼びます。相手が止まっていたり処理が追いつかなかったりすると、呼び出した側まで失敗します。間に SQS を挟むと、送信側はメッセージをキューに置くだけで済み、受信側は自分のペースで取り出して処理できます。これが疎結合です。

SAA の試験ガイドでは「疎結合を実現するために必要な AWS のサービスを決定する」「コンポーネントを個別にスケールできるようにワークロードを疎結合にする」ことが求められます。キューを挟むと、送信側（プロデューサー）と受信側（コンシューマー）の台数を別々に増減できます。メッセージングには大きく 2 つの型があります。

• キュー（SQS）: 1 件のメッセージは、取り出した 1 つのコンシューマーが処理して削除します。仕事を複数の作業者で分け合うイメージです。
• パブリッシュ／サブスクライブ（SNS）: 1 件のメッセージを、購読している全員に配ります。同じ知らせを全員に回すイメージです。

SQS の基本動作

SQS はコンシューマーがキューに「メッセージはありますか」と問い合わせて取り出すプル型（ポーリング）のサービスです。送られたメッセージは、SQS が複数のアベイラビリティーゾーン（AZ）に冗長に保存します。

可視性タイムアウト

コンシューマーがメッセージを受信しても、メッセージはすぐには消えません。キューに残ったまま、一定時間だけほかのコンシューマーから見えなくなります。この時間が可視性タイムアウトです（既定 30 秒、最大 12 時間）。処理が終わったらコンシューマーがメッセージを削除します。削除しないままタイムアウトを過ぎると、メッセージは再び見えるようになり、別のコンシューマーが同じメッセージを処理してしまいます。そのため、可視性タイムアウトは処理にかかる最大時間に合わせて設定します。処理が長引く場合は ChangeMessageVisibility で途中から延長できます。

ショートポーリングとロングポーリング

既定のショートポーリングは、メッセージが見つからなくてもすぐに空の応答を返します。ロングポーリングは、メッセージが届くまで最大 20 秒待ってから応答します。空の応答が減るので、問い合わせ回数に応じてかかる SQS のコストを下げられます。

デッドレターキュー（DLQ）

何度処理しても失敗するメッセージ（形式が壊れているなど）がキューに残り続けると、ほかのメッセージの処理を邪魔します。そこで、受信回数の上限（maxReceiveCount）を超えたメッセージを別のキュー（デッドレターキュー）へ移し、あとで原因を調べます。原因を直したら、DLQ から元のキューへ戻して再処理（リドライブ）できます。

• 標準キューでは、DLQ に移ってもメッセージの有効期限は元のキューに入った時刻から数えます。DLQ の保持期間は元のキューより長く設定するのが推奨です。
• メッセージの順序を厳密に守る必要がある処理では、FIFO キューに DLQ を使わないよう AWS は案内しています。

SQS の設定値と暗号化

遅延キューは、キューに入れたメッセージを一定時間（最大 15 分）見えなくする設定です。可視性タイムアウトと似ていますが、見えなくなるタイミングが違います。遅延キューは「キューに入った直後」、可視性タイムアウトは「受信された後」に見えなくなります。キュー全体ではなくメッセージごとに遅延させたいときはメッセージタイマーを使います。

暗号化: 保管中のメッセージは、サーバー側暗号化（SSE）で暗号化できます。鍵の管理方法は、SQS が管理する鍵を使う SSE-SQS と、AWS KMS の鍵を使う SSE-KMS の 2 種類です。暗号化されるのはメッセージ本文で、キュー名やメッセージ ID などのメタデータは暗号化されません。また、暗号化を有効にする前からキューにあったメッセージは暗号化されません。SSE を有効にしたキューへのリクエストは HTTPS（転送中の暗号化）を使う必要があります。

標準キューと FIFO キュー

標準キューは重複や順序の入れ替わりが起こりうるので、受信側で「同じメッセージを 2 回処理しても結果が変わらない」作りにしておく必要があります。FIFO キューでは次の 2 つが試験で問われます。

• メッセージグループ ID: FIFO キューへの送信では必須です。同じグループのメッセージは 1 件ずつ厳密な順序で処理され、同時に 2 件処理されることはありません。順序が必要なのは「同じ顧客の注文どうし」のような範囲だけ、という場合は顧客ごとに別のグループ ID を付けます。グループ同士は並行して処理できるので、全体の処理量が上がります。
• 重複排除: 同じメッセージ重複排除 ID を持つメッセージが 5 分以内に再送されると、重複として扱われ 1 件だけ配信されます。ID を付ける代わりにコンテンツベースの重複排除を有効にすると、SQS がメッセージ本文のハッシュ値を ID として使います。

キューの滞留に合わせたスケーリング

キューに入るメッセージが、受信側の処理能力より多ければ滞留は増え、少なければ減ります。受信側（コンシューマー）の台数を増やすと処理能力が上がります。

コンシューマーを EC2 の Auto Scaling グループで動かす場合、キューのメッセージ数をそのまま指標にすると、台数と比例しないので適切に増減できないことがあります。AWS はインスタンスあたりのバックログ（キューのメッセージ数 ÷ 稼働中のインスタンス数）を指標にしたターゲット追跡スケーリングを案内しています。目標値は「許容できる最大の待ち時間 ÷ 1 件あたりの平均処理時間」で決めます。たとえば許容 10 秒・1 件 0.1 秒なら目標は 1 台あたり 100 件です。10 台で 1,500 件溜まっていれば 1 台あたり 150 件なので、5 台増やして 15 台にします。

図では省略している可視性タイムアウト・再試行・デッドレターキューは「SQS の基本動作」、処理量の上限は「標準キューと FIFO キュー」で説明しています。

SNS のパブリッシュ／サブスクライブとファンアウト

SNS では、送り手がトピック（話題ごとの配信窓口）にメッセージを発行（パブリッシュ）し、トピックをサブスクライブ（購読登録）している宛先すべてに届けます。SQS と違い、SNS から宛先へ押し出すプッシュ型です。宛先には次のものを指定できます。

• アプリケーション向け（A2A）: Amazon SQS、AWS Lambda、HTTP/HTTPS エンドポイント、Amazon Data Firehose
• 人向け（A2P）: E メール、SMS、モバイルプッシュ通知

SQS キューを宛先にすると、各システムが自分のペースで確実に処理できます。これが SNS + SQS のファンアウトです。

フィルターポリシー

既定では、トピックの全購読者がすべてのメッセージを受け取ります。サブスクリプションにフィルターポリシー（JSON で書く受信条件）を設定すると、条件に合うメッセージだけを受け取れます。条件はメッセージ属性か、JSON 形式のメッセージ本文に対して書けます。たとえば「注文種別が返品のメッセージだけを返品処理用キューに届ける」ことが、送信側を変えずに実現できます。

配信の失敗と FIFO トピック

• 再試行しても宛先に配信できなかったメッセージは、既定では破棄されます。サブスクリプションにデッドレターキュー（SQS キュー。サブスクリプションと同じアカウント・同じリージョン）を設定すると、残して後から分析や再処理ができます。
• SNS FIFO トピックを SQS FIFO キューと組み合わせると、順序と重複排除を保ったままファンアウトできます。

EventBridge・Kinesis Data Streams・Amazon MQ・Step Functions との使い分け

見分け方の目安: 「後で確実に処理したい」なら SQS、「複数に同時に配りたい」なら SNS、「イベントの中身で行き先を変えたい」なら EventBridge、「大量のデータを流し続け、複数のアプリで読む・読み直す」なら Kinesis Data Streams です。SQS では受信側が削除したメッセージは読み直せませんが、Kinesis Data Streams では保持期間内なら何度でも読めます。

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「1 つの SQS キューを複数のシステムで読めば、全システムに同じメッセージが届く」→ ✕。1 件は取り出した 1 つのコンシューマーが処理して削除します。全員に届けるなら SNS のファンアウトです。
• 「標準キューでも重複なく 1 回だけ届く」→ ✕。標準キューは「少なくとも 1 回」で、まれに重複します。重複を許さないなら FIFO キューか、受信側で重複しても問題ない作りにします。
• 「FIFO キューは標準キューと同じく処理量はほぼ無制限」→ ✕。高スループットモードでない場合、API アクションごとに毎秒 300 件（バッチで毎秒 3,000 メッセージ）が上限です。
• 「遅延キューと可視性タイムアウトは同じもの」→ ✕。遅延キューはキューに入った直後から、可視性タイムアウトは受信された後から見えなくします。
• 「保持期間を延ばせば SQS に何か月も残せる」→ ✕。最大 14 日です。長期間の保持や読み直しが必要なら Kinesis Data Streams（最大 365 日）や S3 を検討します。
• 「順序が大事な FIFO キューにも DLQ を付けておけば安心」→ 要注意。メッセージや操作の厳密な順序を守る必要がある処理では、FIFO キューに DLQ を使わないよう AWS は案内しています。

まとめ: SAA 試験で押さえるポイント

• 「急なアクセス増で後段の処理が追いつかない」「後段が止まっても注文を失いたくない」→ 間に SQS を挟んで疎結合にする
• SQS の標準キューは「少なくとも 1 回」配信で順序は保証されない。順序どおり・重複なしが必要 → FIFO キュー（メッセージグループ ID ごとに順序を保証、重複排除は 5 分間）
• 受信側の EC2 は、インスタンスあたりのバックログを指標にしたターゲット追跡で Auto Scaling させる
• 何度処理しても失敗するメッセージはデッドレターキュー（DLQ）へ移して、あとで調べる
• 可視性タイムアウト（既定 30 秒、最大 12 時間）: 取り出されたメッセージは一定時間ほかの受信側から見えなくなる。処理時間より短いと二重処理の原因になる
• メッセージ保持期間は既定 4 日・最大 14 日、最大メッセージサイズは 1 MiB、遅延は最大 15 分
• 1 つのイベントを複数のシステムに届けて、それぞれ独立に処理させる → SNS + SQS のファンアウト。宛先ごとに絞るならフィルターポリシー
• 空のキューへの問い合わせを減らしてコストを下げる → ロングポーリング（メッセージが来るまで最大 20 秒待つ）
• イベントの内容で振り分け → EventBridge、ストリーミングと読み直し → Kinesis Data Streams、既存ブローカーの移行 → Amazon MQ