2026-09-23（水）ElastiCache, SQS, SNS

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

本範囲は、アプリケーションの密結合を解消し、可用性とスケーラビリティを最大化するための「結合緩和（デカップリング）技術」と「高速インメモリキャッシュ」を学ぶエリアです [p.220]。

突発的なアクセス急増（スパイク）から後段のデータベースやワーカーを保護する Amazon SQS [p.220]、複数の異なる処理へ一斉にメッセージを同報プッシュ通知する Amazon SNS [p.227]、そしてデータベースの読み込み負荷を劇的に下げミリ秒未満の応答性を実現する Amazon ElastiCache [p.149] の機能境界を正確に理解する必要があります。

試験では、システムの耐障害性（セルフヒーリング）と処理順序、およびコスト要件から、最も適切なアーキテクチャの組み合わせを選択する設計能力が問われます [p.221]。

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

キーワード	説明
Amazon SQS (Simple Queue Service) [p.220]	システムコンポーネント間を疎結合化（デカップリング）し、非同期メッセージングを提供するフルマネージドメッセージキューサービス [p.220]。
標準キュー (Standard Queue) [p.221]	ほぼ無制限のスループットを誇る標準キュー [p.221]。「最低1回（At-Least-Once）の配信」を保証するが、まれにメッセージの重複や順序逆転が発生する可能性がある [p.221]。
FIFOキュー (FIFO Queue) [p.221]	送信された順序を厳密に維持（First-In-First-Out）し、データの「重複を完全に排除（Exactly-Once配信）」するキュー [p.221]。標準スループットには秒間300件（バッチで3,000件）の上限がある [p.221]。
可視性タイムアウト (Visibility Timeout) [p.222]	あるワーカーが処理中のメッセージを、他の並列ワーカーから一時的に見えなくする（非可視化）設定時間。デフォルト30秒（最大12時間） [p.222]。
ロングポーリング (Long Polling) [p.221]	キューが空の際に、メッセージが到着するまで接続を最大20秒間維持する受信方式。無駄な空リクエストAPI呼び出し（ReceiveMessage）を激減させ、コストを抑制する [p.221]。
遅延キュー (Delay Queue) [p.222]	メッセージがキューに送信されてから、最初の消費者が読み取れるようになるまでの遅延（ディレイ）時間（最大15分） [p.222]。
デッドレターキュー (Dead Letter Queue: DLQ) [p.223]	処理エラーが規定回数（最大受信数）に達しても正常処理できなかった「壊れたメッセージ」を、調査用に隔離・退避させるための専用キュー [p.223]。
Amazon SNS (Simple Notification Service) [p.227]	パブリッシュ/サブスクライブ（1対多）モデルに基づき、登録された複数のサブスクライバー（SQSキュー、Lambda、Eメール等）へ同時に一斉メッセージプッシュ配信（Fan-out）するフルマネージドサービス [p.227, p.228]。
Amazon ElastiCache [p.149]	データベースへの問い合わせ結果などの頻出データをメモリ上に保持し、読み取り応答（レイテンシー）をミリ秒未満へと劇的に高速化させる、フルマネージドなインメモリキャッシュサービス（MemcachedとRedisをサポート） [p.149]。

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

① Amazon SQS の仕様境界：標準キュー vs FIFOキュー [p.221]

メッセージの処理において、「スループット」と「順序・重複排除」のどちらを最優先するかを仕分ける境界です [p.221]。

比較項目	標準キュー [p.221]	FIFOキュー [p.221]
スループット	ほぼ無制限 [p.221]。	制限あり（標準で秒間300件、バッチ処理で最大3,000件） [p.221]。
配信順序	ベストエフォート（順序保証なし） [p.221]。	完全に送信順を維持（First-In-First-Out） [p.221]。
重複配信の排除	重複発生の可能性あり（最低1回は配信） [p.221]。	重複なし（Exactly-Once：1回のみ確実に配信） [p.221]。
決定的な選定シグナル	「順序や重複排除よりも、大量のログデータ処理などの圧倒的なスループット・パフォーマンスを優先させたい」 [p.221]。	「決済トランザクション、座席予約、銀行口座の残高移動など、順序逆転や二重処理が絶対に許されないクリティカルな要件」 [p.221]。

② 結合緩和サービス：Amazon SQS vs Amazon SNS [p.220, p.227]

非同期でデータを他コンポーネントへ引き渡す際、「1対1（引き抜き）」か「1対多（同報）」かによって切り分けます [p.220, p.227]。

比較項目	Amazon SQS [p.220, p.221]	Amazon SNS [p.227, p.228]
通信モデル	1対1（プル型 / Pull）。ワーカーが自主的にメッセージを引き抜く [p.220]。	1対多（プッシュ型 / Push / Fan-out）。登録宛先へ即時に送信 [p.227]。
メッセージの保持仕様	ワーカーに処理され明示的に削除されるまでキュー内に残留（最長14日） [p.221]。	送信完了した瞬間にSNSからは即時消失（メッセージ保持期間なし） [p.227]。
負荷平滑化（バッファ）	非常に優れる（急激なスパイク時にキューが全て受け止め、後段を過負荷から保護） [p.220]。	不適合（即時にプッシュ配信するため、後段の処理サーバーを保護する効果はない） [p.227]。
決定的な選定シグナル	「急激な書き込みトランザクション集中を受け止め、データベースの前段で負荷を平滑化させたい（疎結合）」 [p.220]。	「 1つの取引完了イベントを契機に、メール送信、決済、配送バッチなどの異なる複数の処理を同時に起動させたい」 [p.227, p.228]。

③ Amazon ElastiCache の選定境界：Memcached vs Redis [p.149, p.150, p.151]

求める「データの複雑さ」と「高可用・障害耐性」に応じてキャッシュエンジンを選択します [p.149]。

比較項目	ElastiCache for Memcached [p.150]	ElastiCache for Redis [p.151]
データ構造	シンプルな Key-Value のみ（フラットな文字列やオブジェクト） [p.149, p.150]。	リスト、セット、ハッシュ、ソート済みセットなどの複雑なデータ型 [p.149, p.151]。
可用性・永続化	永続化機能なし（再起動やノード障害で消失）。レプリケーション非対応 [p.149, p.150]。	永続化あり（スナップショット保持）。マルチAZ（自動フェイルオーバー）対応 [p.149, p.151]。
スレッドモデル	マルチスレッド（CPUコア数を十分に活用して高速動作） [p.149, p.150]。	シングルスレッド（複雑な処理がアトミックに実行される） [p.152, p.153]。
決定的な選定シグナル	「データ喪失がシステムに何の影響も及ぼさない、非常にシンプルかつ軽量なWeb静的アセット等のキャッシュ」 [p.149, p.150]。	「ユーザーのログインセッション情報の管理や、障害時もデータロストを防止してサービスを継続させたい高可用な要件」 [p.149, p.151]。

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

ひっかけ①：バグがあるメッセージがキューに残り続け、無限ループでワーカーが過負荷に陥る罠 [p.222, p.223]
- 罠: 処理に失敗したメッセージが、可視性タイムアウト時間が過ぎると自動的にキューの先頭に「未処理状態」として復活するため、ワーカーが同じバグ入りメッセージを永遠に引き抜いてクラッシュし続ける。
- 対策: 受信回数の上限（MaxReceiveCount）を設定した デッドレターキュー（DLQ） を構成し、指定回数失敗した不良メッセージを自動的に隔離退避させて、後から手動でデバッグ調査できるように構成します [p.223]。
ひっかけ②：キューが空のときの無駄な受信API連打による「呼び出しコスト」の増大を放置する罠 [p.221]
- 罠: メッセージが滅多に届かないキューに対し、デフォルトの「ショートポーリング」で定常的にリクエスト（ReceiveMessage）を繰り返すと、空応答に対しても膨大なリクエストAPI課金が発生する。
- 対策: 待機時間（WaitTimeSeconds）を最大20秒に設定する ロングポーリング を有効化し、メッセージが届くまでSQS側で接続を一時待機させることで、不必要な空リクエスト呼び出しを排除してコストを最適化します [p.221]。
ひっかけ③：セッションレプリケーションや永続化が必要な設計に、安易に「Memcached」を選定する罠 [p.149, p.150, p.151]
- 罠: モバイルアプリケーションのログイン情報を保持するセッションキャッシュとして、スレッド性能の高さだけで「Memcached」を選んでしまい、ノード障害やスケール時にデータが全消失して全ユーザーが強制ログアウトされる。
- 対策: 可用性、バックアップ、マルチAZによる自動フェイルオーバー、およびデータの永続化を標準サポートしている ElastiCache for Redis を確実に適合させてください [p.149, p.151]。