2026-09-25（金）ElastiCache, SQS, SNS

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

本範囲は、クラウドアーキテクチャの2大原則である「高パフォーマンス（インメモリキャッシュによるデータベース負荷軽減）」と「弾力性（メッセージングサービスを用いたシステムの疎結合化）」を習得する、試験で最も配点の高い最重要セクションです [p.6, p.291, p.295]。

データベース層を高速化する Amazon ElastiCache [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 vs Redis [p.149]	ElastiCacheがサポートする2大エンジン [p.149]。Memcachedはマルチスレッド対応のシンプルな一時キャッシュ [p.149, p.153]、Redisはデータの永続化やマルチAZ自動フェイルオーバー（レプリケーション）を標準サポートする高性能データストアです [p.149, p.151, p.152]。
Amazon SQS (Simple Queue Service) [p.220]	システムコンポーネント間を非同期（プル型）に中継するフルマネージドなメッセージキューイングサービス [p.220]。突発的な大量リクエストを安全にバッファリングし、後段のシステムを過負荷から確実に保護します [p.220, p.291]。
可視性タイムアウト (Visibility Timeout) [p.222]	SQSからメッセージが1つのワーカーに取得された後、そのメッセージが他のワーカーに重複して処理されないように非表示（ロック）にする期間 [p.222]。
Amazon SNS (Simple Notification Service) [p.227]	Pub/Sub（パブリッシュ/サブスクライブ）型のプッシュ通知サービス [p.227]。送信された1つのイベントメッセージを、SQSやLambda、メールなど複数の異なる登録先へ同時に一斉同報配信します [p.227, p.228]。
ファンアウト（Fan-out）構成 [p.228]	SNSトピックの後段に、複数の独立したSQSキューをサブスクライバーとしてアタッチする構成 [p.228]。1つのイベントを契機に、異なる後段処理（決済、在庫管理、発送など）を並列かつ等速で安全に非同期実行させる王道の連携テンプレートです [p.220, p.228, p.291]。

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

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

比較項目	Memcached [p.149, p.153]	Redis [p.149, p.151, p.152]	決定的な選定シグナル（試験上のキーワード） [p.149]
データ構造	シンプルなKey-Value（文字列のみ） [p.149]。	リスト、セット、ソートセット、ハッシュ等多様 [p.149]。	🎯 「ソートされたランキング情報や複雑なデータ型をインメモリで扱いたい」 ➔ Redis [p.149]。
スレッドモデル	マルチスレッド対応 [p.153]。マルチコアを有効利用可能 [p.153]。	原則シングルスレッド動作（1コア制限） [p.152, p.153]。	🎯 「 CPUパワーを有効利用して、とにかくシンプルかつ超スループットな一時キャッシュが欲しい」 ➔ Memcached [p.149, p.153]。
高可用性・永続性	なし（再起動で全消失。データ同期も非対応） [p.149]。	あり（データの永続化、同期複製、自動フェイルオーバー対応） [p.149, p.151]。	🎯 「ノード被災時にもデータ消失を防ぎ、自動フェイルオーバーでサービスを継続させたい」 ➔ Redis [p.149]。

② SQSキュータイプの比較：標準キュー vs FIFOキュー [p.221]

比較項目	標準（Standard）キュー [p.221]	FIFOキュー [p.221]	決定的な選定シグナル（試験上のキーワード） [p.221]
メッセージ順序	ベストエフォート（順序が前後する可能性あり） [p.221]。	厳密な先入先出（First-In, First-Out） [p.221]。	🎯 「金融の取引履歴や、処理の順序が1ミリも前後しては困るワークフローを制御したい」 ➔ FIFO [p.221]。
重複配信の制御	少なくとも1回配信（極めて稀に重複する可能性あり） [p.221]。	1回限りの正確な配信（Exactly-Once） [p.221]。	🎯 「二重処理・二重決済をインフラの機能で完全に防止したい」 ➔ FIFO [p.221]。
スループット制限	ほぼ無制限 [p.221]。	1秒間あたり最大300トランザクション（バッチで最大3000） [p.221]。	🎯 「スループットを最優先し、並列ワーカーが超高速で処理を行いたい（順序は問わない）」 ➔ 標準 [p.221]。

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

ひっかけ①：Redisのコマンド処理高負荷に対し、インスタンスを無計画にスケールアップ（垂直拡張）する罠 [p.152, p.153]
- 罠パターン: 「Redis版ElastiCacheのCPU使用率が100%近くに達したため、マルチコアCPUが搭載された上位の超ハイエンドインスタンスタイプへ垂直拡張して高スループット化を図った。」
- なぜ間違いか（CPUの動作特性）: Redisは仕様上、メインのコマンド処理プロセスを「 シングルスレッド 」で実行するアーキテクチャです [p.152, p.153]。そのため、どれほど多くのマルチコアCPUを搭載したサーバーにスケールアップしても、Redisは1コアしか消費できず、パフォーマンスは1ミリも改善しません [p.152]。
- 正しい解決策: Redisクラスターモードを有効化（Cluster Mode Enabled）し、データを複数の「シャード」に分割して、複数のノードで並列処理（水平拡張・スケールアウト）させる設計を選択します [p.151, p.152]。
ひっかけ②：SQSのメッセージ二重処理（重複処理）問題に対し、「ロングポーリングの有効化」で解決しようとする罠 [p.221, p.222]
- 罠パターン: 「標準キューを使用中、特定のワーカー（EC2）がメッセージ処理を完了させる前に、同じメッセージが別のワーカーに引き抜かれて二重処理されてしまった。この問題を防止するため、SQSの受信オプションをロングポーリング（接続待機20秒）に変更した。」
- なぜ間違いか（機能の誤解）: ロングポーリングは、キューが空のときにメッセージが届くまで最大20秒間接続を維持することで「空の応答を減らして無駄なAPI問い合わせ料金を抑える」ためのコスト最適化技術です [p.221, p.222]。一度引き抜かれたメッセージが処理中に他のワーカーから見えなくなるロック制御とは無関係です。
- 正しい解決策: ワーカーの実際の処理時間に合わせて「 可視性タイムアウト（Visibility Timeout） 」を十分に長く設定（またはAPI呼び出しで一時的に延長）します [p.222]。可視性タイムアウトが処理時間より短すぎると、最初のワーカーの処理が終わる前にロックが解除され、別のワーカーへ再配信（重複処理）されてしまいます [p.222]。
ひっかけ③：非同期なファンアウト設計に対し、SQSの直後に直接「Amazon SNS」を配備する逆配置の罠 [p.220, p.228]
- 罠パターン: 「ユーザーのお問い合わせを契機に、1. 受付自動返信メールの送信、2. 社内Slackへの通知、の2つの異なる処理を並列に非同期処理させたい。このため、フロントからまずAmazon SQSキューにリクエストを投入し、そのSQSキューの後段にAmazon SNSトピックをアタッチして各サブスクライバーへプッシュ送信した。」
- なぜ間違いか（プル・プッシュの不整合）: SQSはプル型サービスであり、メッセージを受信者が引き抜くまでキューに留めます [p.220]。SQS自ら後段のSNSへメッセージをダイレクトに一斉プッシュ転送する機能は仕様上存在しません。
- 正しい解決策: 配置の順序を完全に逆にします。フロントエンドからは 「Amazon SNSトピック」へメッセージを直接プッシュ送信（パブリッシュ） させ、そのSNSトピックのサブスクライバーとして 複数の「Amazon SQSキュー」 をぶら下げるのが、正しいファンアウト構成です [p.228]。各ワーカーは自分専用のSQSキューから自律的にメッセージをプルして安全に並列等速処理を行います [p.220, p.228, p.291]。