週8ElastiCache / SQS / SNS

2026-09-19（土）ElastiCache, SQS, SNS

この記事の目次
  1. このハンズオンで使うAWSサービスと役割
  2. 操作前に知っておくべき設定項目
  3. よくある詰まりポイント・注意点
  4. このハンズオンが対応する試験論点

1. 【このハンズオンで使うAWSサービスと役割】

サービス 役割
Amazon SQS (Simple Queue Service) ーー メッセージの一時保管庫（バッファ） [p.22, p.220] システムコンポーネント間を「非同期」かつ「疎結合」に接続するフルマネージドなメッセージキューイングサービスです [p.22, p.220]。
今回の実習では、送信されたメッセージ（データ）を一時的に内部に安全に保持し、処理待ちの列（キュー）を形成する役割を担います [p.220]。これにより、送信側と受信側の処理速度の差を吸収し、システムの過負荷によるデータ消失を防ぎます [p.220, p.221]。
Amazon SNS (Simple Notification Service) ーー メッセージの仲介配信人（パブリッシャー） [p.22, p.227] 「発行/購読（Pub/Sub）」型のフルマネージドメッセージ配信サービスです [p.22, p.227, p.228]。
実習では、SNSに「メッセージが発行された（パブリッシュ）」というイベントを検知し、それを購読（サブスクライブ）しているSQSキューに対して自動的にプッシュ送信（配信）する役割を果たします [p.22, p.228]。

2. 【操作前に知っておくべき設定項目】

Amazon SQS に関する設定項目

  • キュータイプ（Standard vs FIFO） [p.221]
    • Standard（標準キュー）: ほぼ無制限のスループットを提供しますが、配信順序はベストエフォート（入れ替わる可能性あり）で、メッセージが重複して届く（少なくとも1回の配信）可能性があります [p.221]。
    • FIFOキュー: 送信された順序を厳格に維持（先入先出）し、重複配信を完全に排除（正確に1回のみ処理）します [p.221]。
  • 可視性タイムアウト（Visibility Timeout） [p.222]
    • 1つのコンシューマー（受信アプリケーション）がメッセージを取り出した際、他のコンシューマーに一時的にそのメッセージを見えなくする保護期間（デフォルトは30秒）です [p.222]。この時間内に受信者が処理を完了してメッセージを明示的に削除しないと、メッセージは再び可視状態に戻り、別の受信者に二重処理されてしまいます [p.222]。
  • ポーリング待機時間（メッセージ受信待機時間） [p.221]
    • キューが空のときに、メッセージが到着するまで何秒間APIの接続を維持して待つかの設定です（0秒〜20秒） [p.221]。20秒を指定する設定を 「 ロングポーリング 」 と呼び、空振りのAPIコール数を激減させてコストを劇的に最適化できます [p.221]。

Amazon SNS に関する設定項目

  • トピックタイプ [p.228]
    • SQSと同様に、StandardとFIFOの2種類からトピックを定義します [p.228]。StandardトピックはStandardキューへ、FIFOトピックはFIFOキューへと、マッピング関係を一致させて連携します [p.221, p.228]。
  • サブスクリプションのプロトコルとエンドポイント [p.228]
    • トピックからどこにメッセージを届けるかを設定します [p.228]。今回は、プロトコルに「Amazon SQS」を選択し、エンドポイントに「作成したSQSキューのARN（Amazon Resource Name）」をマッピングします [p.228]。

3. 【よくある詰まりポイント・注意点】

  • ⚠️ 詰まりどころ①：SQS側の「アクセスポリシー」設定漏れによる疎通不能
    • SNSトピックを作成し、SQSをサブスクリプション（購読先）に登録しただけでは、SNSからのメッセージはSQSキューに届きません。
    • SQSキューが持つ「アクセスポリシー（IAMの親戚）」において、送信元となるSNSトピックのARNからの sqs:SendMessage アクションを明示的に「許可（Allow）」するよう書き換える必要があります。 このセキュリティ許可設定がないと、SNSはSQSへの書き込み権限エラー（Access Denied）となり、通知が完全に遮断されます。
  • ⚠️ 詰まりどころ②：可視性タイムアウト中のメッセージ重複受信 [p.222]
    • メッセージを受信した後、手動テスト等で内容を精査している時間が「可視性タイムアウト（初期値30秒）」を超えてしまうと、SQS側は「受信者が処理に失敗した」と見なして、メッセージを再表示します [p.222]。そのため、コンソール画面からメッセージを再ロードすると、同じメッセージが二重に表示され混乱を招くことがあります [p.222]。

4. 【このハンズオンが対応する試験論点】

  • 「Fan-out（ファンアウト）」による一対多の並列メッセージング [p.22, p.228]
    • SNSに1つのメッセージを送るだけで、裏側にぶら下がっている「複数の異なるSQSキュー（例：決済処理用キュー、在庫管理用キュー、分析ログ用キュー）」に対して一斉に自動複製してパケットを送り届けるアーキテクチャです [p.228]。
    • 試験では、「 1つのシステムイベントを契機に、互いに影響を及ぼしたくない複数の独立したバックエンドシステム群へ、安全に一斉同報通知を行いたい 」 という要件において、この「SNSトピック ＋ 複数SQS」を組み合わせたファンアウトパターンが最善のアーキテクチャ設計として頻繁に出題されます [p.228]。
  • 「疎結合（Decoupling）」による可用性と耐障害性の担保 [p.22, p.218, p.220]
    • システム同士が直接通信（密結合）している場合、一方のサーバーがダウンすると全体の通信が全滅します [p.22, p.220]。しかし、SQSのようなメッセージキューを間に挟む（疎結合にする）ことで、受信側のサーバー群が一時的に全ダウンしたとしても、データはSQS内に完全に保護（最大14日間保持）され続けます [p.220, p.222]。
    • サーバーが復旧した瞬間、キューに溜まっていたメッセージが何事もなかったかのように安全に再回収・順次処理（セルフヒーリング）されます [p.220, p.222]。この 「 耐障害性の向上と負荷スパイクのバッファリング 」 というクラウドならではの最強設計の利点を、本日のメッセージ送受信を通じて実体験してください [p.22, p.220]。

🧸 実習への前提知識はこれで完璧です！

「SNSからパブリッシュされたメッセージが、SQSキュー側でどのように滞留し、受信されるか」のメッセージライフサイクルをコンソール上で注意深く追いながら、有意義なハンズオン実習を進めてきてください。