SAA ElastiCache キャッシュ設計パターン5選｜Cache-Aside・Write-Through・セッション管理・Redis vs Memcached 選択基準
AWS SAA-C03 で頻出の ElastiCache 設計を完全整理。Cache-Aside（Lazy Loading）・Write-Through・Write-Around の3キャッシュ戦略、セッションストアパターン、Redis vs Memcached の選択判断軸を、試験頻出シナリオと要件キーワードから即答できる粒度で解説。クラスターモード有効／無効の使い分けと DAX との違いも網羅。
「ElastiCache の問題は、まずエンジンを選び、次にキャッシュ戦略を選べ」 — SAA-C03 で ElastiCache が絡む問題の正解は、ほぼ「Redis か Memcached か」と「どのキャッシュ戦略を使うか」で決まる。本記事では、要件キーワードからパターンへの逆引きができる粒度で、試験頻出の5つの設計パターンを整理する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
1. 結論：ElastiCache 設計パターン5選
SAA-C03 で問われる ElastiCache の設計パターンは大きく5つに集約される。
| パターン | エンジン | 主なユースケース |
|---|---|---|
| Cache-Aside（Lazy Loading） | Redis / Memcached | RDS・DynamoDB のクエリ結果キャッシュ |
| Write-Through | Redis / Memcached | 書き込み頻度が高いデータの常時同期 |
| Write-Around | Redis / Memcached | 読み取り頻度が低いデータの書き込み回避 |
| セッションストア | Redis（推奨） | EC2・ECS のステートレス化・セッション共有 |
| クラスターモード設計 | Redis のみ | 大規模シャーディング・高可用性 |
2. Redis vs Memcached 選択の判断軸
ElastiCache を選ぶ問題の最初のステップは Redis か Memcached か の選択だ。
2軸の判断フロー
要件を確認
├─ 永続化が必要 → Redis
├─ マルチ AZ が必要 → Redis
├─ レプリケーションが必要 → Redis
├─ Sorted Set / PubSub / Geo → Redis
├─ AUTH / TLS が必要 → Redis
├─ マルチスレッド性能重視 → Memcached
└─ シンプル KV キャッシュのみ → どちらでも可（Memcached が低コスト）| 評価項目 | Redis（Valkey） 推奨 | Memcached |
|---|---|---|
| データ永続化 | ◎ RDB / AOF | × なし |
| マルチ AZ / フェイルオーバー | ◎ 自動 | × なし |
| レプリケーション | ◎ 最大5リードレプリカ | × なし |
| クラスターモード（シャーディング） | ◎ 最大500ノード | ○ 最大20ノード |
| マルチスレッド | △ 基本シングルスレッド | ◎ ネイティブ対応 |
| Sorted Set / PubSub | ◎ 対応 | × 非対応 |
| AUTH / TLS 暗号化 | ◎ 対応 | △ TLS のみ |
| セッションストア | ◎ 最適 | ○ 可能 |
| コスト | やや高 | 低 |
3. パターン1：Cache-Aside（Lazy Loading）
概要
最も頻出のキャッシュパターン。キャッシュミス時のみ DB から取得してキャッシュに書く 遅延ロード方式。
実装フロー
1. アプリ → ElastiCache に GET
2a. キャッシュヒット → 即レスポンス（DB アクセスなし）
2b. キャッシュミス → RDS / DynamoDB から取得
3. 取得結果を ElastiCache に SET（TTL 付き）
4. アプリへレスポンス試験での要件キーワード
- 「データベースの読み取り負荷を軽減したい」
- 「同じクエリが繰り返し実行される」
- 「読み取りが書き込みより多い（Read-Heavy）」
4. パターン2：Write-Through
概要
DB への書き込みと同時にキャッシュも更新する パターン。常に最新データがキャッシュに存在する。
実装フロー
1. アプリ → DB（RDS 等）に WRITE
2. DB 書き込み成功 → ElastiCache にも同時に SET
3. 次回の読み取り → キャッシュヒット（常に最新）試験での要件キーワード
- 「キャッシュとデータベースの整合性を常に保ちたい」
- 「古いデータ（Stale Data）の読み取りを避けたい」
- 「書き込み頻度が高くてもリアルタイムに最新データを返したい」
5. パターン3：Write-Around
概要
書き込みはキャッシュをバイパスして直接 DB へ書く パターン。読み取り時のみキャッシュを参照する（Cache-Aside と組み合わせることが多い）。
試験での要件キーワード
- 「書いたデータが頻繁に読み返されるわけではない」
- 「ログやイベントデータを DB に書き込むが、キャッシュを汚したくない」
6. パターン4：セッションストア（Session Store）
概要
EC2 や ECS コンテナのセッションデータを ElastiCache に保存してステートレス化する パターン。Auto Scaling・スケールイン時もセッションが失われない。
ユーザー → ALB → EC2インスタンス（ステートレス）
↕ セッション読み書き
ElastiCache Redis（セッションDB）試験での要件キーワード
- 「スケーラブル / ステートレスなアーキテクチャにしたい」
- 「ユーザーセッションが Auto Scaling のスケールインで消えてしまう」
- 「マルチ AZ 構成でセッションを共有したい」
- 「ALB スティッキーセッションを廃止したい」
7. パターン5：クラスターモード設計
クラスターモード無効 vs 有効
ElastiCache Redis では クラスターモード（シャーディング） の有無でアーキテクチャが大きく変わる。
| 評価項目 | クラスターモード無効 | クラスターモード有効 推奨 |
|---|---|---|
| シャード数 | 1 シャード固定 | 最大 500 シャード |
| リードレプリカ | 最大 5 台 | 各シャードに最大 5 台 |
| データ分散 | × なし（全データが1シャード） | ◎ キーでハッシュ分散 |
| フェイルオーバー | ◎ プライマリ→リードレプリカ | ◎ 各シャード独立 |
| 書き込みスケール | × 垂直スケールのみ | ◎ 水平スケール可能 |
| Multi-AZ | ◎ 対応 | ◎ 対応 |
| ユースケース | 中規模・シンプル構成 | 大規模・高スループット |
8. キャッシュ戦略 詳細比較
| 評価項目 | Cache-Aside | Write-Through | Write-Around |
|---|---|---|---|
| キャッシュタイミング | 読み取り時（ミス時のみ） | 書き込み時（常に） | 読み取り時（ミス時のみ） |
| 整合性 | △ TTL 依存 | ◎ 常に最新 | △ TTL 依存 |
| 読み取り速度（初回） | △ ミス時に遅い | ◎ 常にキャッシュヒット | △ ミス時に遅い |
| 書き込み速度 | ◎ DB のみ | △ DB + キャッシュの2回 | ◎ DB のみ |
| メモリ効率 | ◎ 使われたデータのみ | △ 全書き込みデータが蓄積 | ◎ 読まれたデータのみ |
| DB 障害耐性 | ◎ キャッシュで継続可 | ◎ 同上 | ◎ 同上 |
| 向いているワークロード | Read-Heavy | 整合性重視 | Write-Heavy（読み戻し少） |
9. 要件キーワード早見表
| 要件キーワード | 正解パターン |
|---|---|
| 「RDS の読み取り負荷を軽減」 | Cache-Aside（ElastiCache Redis/Memcached） |
| 「データベースのクエリ結果をキャッシュ」 | Cache-Aside |
| 「常に最新データをキャッシュしたい」 | Write-Through |
| 「整合性が重要でステイルデータ不可」 | Write-Through |
| 「ユーザーセッションの共有・ステートレス化」 | セッションストア（Redis 推奨） |
| 「Auto Scaling でセッションが消える問題」 | セッションストア（Redis） |
| 「ALB スティッキーセッションを廃止」 | セッションストア（Redis） |
| 「大量データのシャーディング」 | Redis クラスターモード有効 |
| 「フェイルオーバー・マルチ AZ が必要」 | Redis（Memcached は不可） |
| 「永続化が必要（障害後もデータを保持）」 | Redis（RDB/AOF） |
| 「マルチスレッドで高スループット KV キャッシュ」 | Memcached |
| 「DynamoDB を高速化したい」 | DAX（ElastiCache ではない） |
| 「PubSub / ランキング（Sorted Set）」 | Redis |
| 「AUTH / TLS 暗号化」 | Redis（Memcached はTLS のみ） |
10. 頻出ひっかけパターンと正しい打ち手
ひっかけ1：「Memcached でマルチ AZ フェイルオーバー」
- ❌ 誤：ElastiCache Memcached はマルチ AZ フェイルオーバーをサポートする
- ✅ 正：Memcached は マルチ AZ フェイルオーバーなし。フェイルオーバーが必要なら Redis を選ぶ
ひっかけ2：「DAX で RDS をキャッシュ」
- ❌ 誤：DAX を使って RDS の読み取りを高速化する
- ✅ 正：DAX は DynamoDB 専用。RDS のキャッシュには ElastiCache を使う
ひっかけ3：「クラスターモード有効でのトランザクション」
- ❌ 誤：クラスターモード有効の Redis でも任意のキーをトランザクション操作できる
- ✅ 正：クラスターモード有効では、トランザクションのキーは 同一ハッシュスロット に存在しなければならない
ひっかけ4：「Cache-Aside でのデータ整合性」
- ❌ 誤：Cache-Aside はキャッシュと DB が常に一致している
- ✅ 正：Cache-Aside は TTL 期限内にキャッシュが古くなる（Stale Data）可能性がある。常時一致が必要なら Write-Through を選ぶ
ひっかけ5：「スティッキーセッションとセッションストアの等価視」
- ❌ 誤：ALB スティッキーセッションを使えば ElastiCache セッションストアと同等の可用性が得られる
- ✅ 正：スティッキーセッションはインスタンス固定なので、そのインスタンスが落ちるとセッションが消える。ElastiCache セッションストアは完全分離で可用性が高い
11. 次のアクション チェックリスト
12. 関連記事
- ElastiCache for Redis 完全ガイド
- ElastiCache Memcached — シンプル KV キャッシュの使いどころ
- DAX — DynamoDB インメモリキャッシュ
- RDS 完全ガイド
- SAA データベース選択ガイド（RDS/Aurora/DynamoDB/ElastiCache/Redshift）
- SAA 高可用性設計パターン