2026-09-21（月）ElastiCache, SQS, SNS

1. 【この範囲の全体像】

本範囲は、高可用で極めてレスポンスの速いシステム設計（キャッシュ戦略）と、システムの疎結合化（非同期連携）を実現する最重要アーキテクチャ設計エリアです [p.149, p.220, p.227]。

データベース層の前段で読み取りをミリ秒未満に高速化する Amazon ElastiCache の選定（Memcached vs Redis）[p.149]、一時的なリクエスト急増を安全にバッファリングする Amazon SQS [p.220]、そしてイベント発生を一斉同報配信する Amazon SNS [p.227] の機能境界を学びます。

試験では、これらを組み合わせて「過負荷に強く、かつ停止しない自律分散システム」を最適に設計する能力が厳格に問われます [p.220, p.228, p.291]。

2. 【重要キーワード・サービス一覧】

キーワード	説明
Amazon ElastiCache [p.149]	フルマネージドなインメモリ型キャッシュデータベースサービス [p.149]。頻繁に読み出されるデータやクエリ結果をメモリ上に一時保持することで、DBの読み取り圧力を劇的に引き下げ、応答時間をミリ秒未満へ高速化します [p.149]。
Memcached [p.149]	ElastiCacheで選択可能なエンジンの1つ。データ構造が極めてシンプル（Key-Valueのみ）で、マルチスレッド処理に対応する高スループットなキャッシュ [p.149, p.153]。データの永続化や自動フェイルオーバー機能はありません [p.149]。
Redis [p.149]	ElastiCacheでもう1つの選択肢。多様なデータ構造（リスト、セット、ソートセット、ハッシュ等）に対応 [p.149]。データの永続化（耐久性）、レプリケーション、自動フェイルオーバーを標準サポートする高性能インメモリDBです [p.149]。
Amazon SQS (Simple Queue Service) [p.220]	フルマネージドなメッセージキューイングサービス [p.220]。コンポーネント間を非同期（プル型）で中継し、突発的な大量アクセスを安全にバッファリングすることで、バックエンドを過負荷から守り疎結合化を実現します [p.220, p.291]。
Amazon SNS (Simple Notification Service) [p.227]	フルマネージドなPub/Sub（パブリッシュ/サブスクライブ）型のメッセージ通知サービス [p.227]。パブリッシャーが送信したイベント情報を、登録された複数のサブスクライバー（SQS、Lambda、HTTP、メール等）へ同時に一斉同報配信（プッシュ型）します [p.227, p.228]。

3. 【試験で問われる比較ポイント】

① インメモリキャッシュエンジンの選定：Memcached vs Redis [p.149, p.151, p.153]

「キャッシュするデータの特性」と「求める可用性」を基準に選択します [p.149]。

比較項目	Memcached [p.149, p.153]	Redis [p.149, p.152]
データ構造	シンプルなKey-Value（文字列のみ）[p.149]。	文字列、リスト、セット、ソートセット、ハッシュ等多様 [p.149]。
スレッドモデル	マルチスレッドに対応 [p.153]。マルチコアCPUのパワーを有効活用可能 [p.153]。	原則シングルスレッドで動作 [p.152, p.153]（1コアしか使用しない仕様）[p.152]。
データの永続性	なし（再起動やメンテナンス時にキャッシュは物理消去）[p.149]。	あり（スナップショットやデータ永続化で再起動後も復旧可能）[p.149]。
高可用性・レプリケーション	なし（データの分散のみ）[p.149]。	あり（プライマリからリードレプリカへの同期複製、自動フェイルオーバー）[p.149, p.151]。
決定的な選定シグナル	「とにかく安価でシンプル、万が一データが吹き飛んでもメインDBから即時再生成可能な一時キャッシュ」 [p.149]。	「キャッシュの停止や損失がシステム全体に致命的な影響を与えるため、自動フェイルオーバーや永続化が必須のシーン」 [p.149]。

② メッセージングの役割：Amazon SQS vs Amazon SNS [p.220, p.227]

通信モデルが「プル（受信者が引き抜く）」か「プッシュ（送信元が送りつける）」かでサービスの境界が決まります [p.220, p.227]。

比較項目	Amazon SQS [p.220, p.221]	Amazon SNS [p.227, p.228]
通信モデル	プル型（非同期）。消費者（ワーカー）が自らキューからメッセージを引き抜く [p.220]。	プッシュ型（即時）。メッセージ受信時に即座にサブスクライバーへ配信 [p.227, p.228]。
メッセージ保持（バッファ）	あり（標準で4日間、最大14日間キューに安全に滞留可能）[p.220]。	なし（即時送信。受信側がオフラインの場合はリトライポリシーに依存）。
配信モデル	1対1配信（キュー内の1メッセージは、通常1つのワーカーにのみ処理される）[p.220]。	1対多配信（送信されたメッセージは登録された全宛先へ同時に一斉配信）[p.227, p.228]。
決定的な選定シグナル	「バックエンドの処理速度に合わせてリクエストをバッファリングし、過負荷による接続クラッシュを防止したい（負荷平滑化）」 [p.220, p.291]。	「あるイベント（例: 商品購入）をトリガーとして、複数の異なる処理（決済、在庫確保、完了メール送信）を同時に並列実行させたい」 [p.228]。

4. 【ひっかけ注意ポイント】

ひっかけ①：高可用性が要求されるシステムに、安易に「Memcached」を選択する罠 [p.149]
- 罠パターン: 「モバイルゲームのアクセスセッション情報をElastiCacheに保持させたい。耐障害性を高めるため、アベイラビリティゾーン（AZ）全体が被災した際にも全自動でフェイルオーバーし、セッションデータが消失しない高可用なMemcached構成を設計した。」
- なぜ間違いか: Memcachedエンジンは、仕様としてレプリケーション、自動フェイルオーバー、データの永続化機能を備えていません [p.149]。物理ノードやAZ障害が発生した場合、ノード内のデータは例外なくすべて消滅（クリア）されます [p.149]。
- ベストプラクティス: 高可用性や障害からの自律復旧（自動フェイルオーバー）が必要なインメモリキャッシュ・データストア要件には、必ず ElastiCache for Redis を選択して適用します [p.149]。
ひっかけ②：Redisのコマンド実行負荷（CPU使用率）を下げるために、インスタンスサイズをスケールアップ（垂直拡張）する罠 [p.152, p.153]
- 罠パターン: 「Redis版ElastiCacheの負荷が高まったため、CPUコア数が非常に多い最新のハイエンドインスタンスタイプへとスケールアップした。これにより、Redisのコマンド処理が自動で複数コアに分散され処理能力が向上すると期待した。」
- なぜ間違いか: Redisは原則として「 シングルスレッド 」で処理を実行するアーキテクチャです [p.152, p.153]。いくらマルチコアの巨大なインスタンスへ垂直拡張しても、コマンド処理自体は1つのCPUコアしか有効活用できず、無駄なコストを払いスループットは改善しません [p.152]。
- ベストプラクティス: Redisの処理能力を高める場合は、クラスターモードを有効化（Cluster Mode Enabled）し、データを複数の「シャード（Shard）」に分割してスケールアウト（水平拡張） を行う設計を選択します [p.151, p.152]。
ひっかけ③：非同期な一斉同報通知（SNS）において、受信側のサーバー過負荷を考慮せずにプッシュ配信する罠 [p.220, p.228]
- 罠パターン: 「ユーザーの商品購入を契機に、決済用Lambdaと発送用EC2に対して、Amazon SNSを用いて同時プッシュ通知した。タイムセール時の高負荷スパイク発生時も、SNSのプッシュ転送機能だけで安全に負荷を処理できるとした。」
- なぜ間違いか: SNSはプッシュ型で即座にメッセージを送りつけるため、後段のEC2やシステムが処理限界に達すると、接続がパンクしてトランザクションがロスト（注文消失）する致命的な障害に繋がります [p.220]。
- ベストプラクティス: SQSとSNSを結合させた「 ファンアウト（Fan-out）パターン 」を設計します [p.228]。SNSトピックの後段にそれぞれ用途別の Amazon SQSキュー をサブスクライバーとしてアタッチし、EC2側は自身の処理限界を超えないペースでSQSからデータを「プル（引き抜き）」して安全に等速非同期処理させます [p.220, p.228, p.291]。