ElastiCache（RedisとMemcached）試験で効く比較
RedisとMemcachedの機能差、レプリケーションとクラスター、永続化、Pub/Sub、TLS、淘汰ポリシー、DynamoDB／DAXとの距離を表とシナリオで厚く整理します。
学習順Step 51 / 77サービスDB試験ドメインパフォーマンス
このページの狙い
ElastiCache は 読み取り負荷の吸収と ミリ秒未満の応答で頻出です。試験では Redis と Memcached の機能差、DynamoDB／DAX との役割の取り違え、セキュリティがセットで問われます。ここでは 表に加え、典型シナリオと 誤答パターンを厚くします。
公式ドキュメント（入口）
- ElastiCache ドキュメント
- Redis と Memcached の比較（AWS）
- Redis の暗号化
- Memcached のセキュリティ機能
- Redis の高可用性（レプリケーショングループ）
Redis と Memcached（本質の対比）
| 観点 | Redis | Memcached |
|---|---|---|
| データ構造 | 文字列に限らず、リスト・セット・ハッシュ・ソート済み集合など | シンプルなキーバリュー |
| スレッドモデル | 単スレッド実行が中心（ノードを水平に足す発想） | マルチスレッドで単一大容量ノードに強い |
| 永続化 | RDB/AOF 等 | 基本的に揮発キャッシュ想定 |
| 高可用 | レプリケーショングループ、マルチ AZ、自動フェイルオーバーが論点 | シンプル用途の記述が多い |
| Pub/Sub | あり（チャット、通知） | なし |
| ソート・ランキング | ソート済み集合などで実装しやすい | 素のキーバリューで工夫が必要 |
| トランザクション風 | MULTI/EXEC など（試験では入口レベル） | 期待しない |
Memcached が残る場面（試験文脈）
- 極めて単純なオブジェクトキャッシュで、マルチスレッドのスループットが支配的。
- 永続化やフェイルオーバー不要で割り切れる。
- ノードの増減でスケールアウト／インが主戦術。
一方で 複雑なデータ構造・レプリケーション・自動復旧・Pub/Sub が要件に入ると Redis 優位になりやすいです。
Redis の運用パターン（試験で効く）
| パターン | 説明 | 注意 |
|---|---|---|
| レプリケーショングループ | プライマリ＋レプリカで読み取り分散と DR | 読み取り遅延（レプリケーションラグ） |
| クラスターモード | シャーディングで水平拡張 | キー設計とクライアントライブラリの対応 |
| セッションストア | スティッキセッションや JWT ブラックリスト | TTL と無効化 |
| ランキング | ソート済み集合 | メモリ使用量 |
キャッシュ戦略（実務と試験の交点）
| 戦略 | 挙動 | 向くケース |
|---|---|---|
| Lazy loading | ミス時に DB から読んでキャッシュ | 初回遅延とスタンペード対策が必要 |
| Write-through | 書き込み時にキャッシュも更新 | 読み取り一貫性を取りやすいが書き込みコスト増 |
| TTL | 時間で失効 | 多少の遅延を許容するデータ |
誤答の型: 「キャッシュに書いたからディスク側の正も必ず同期済み」→ 設計次第。キャッシュは 揮発し、失敗時に 再計算／再取得できるかが前提です。
淘汰（Eviction）とメモリ圧力
maxmemory-policy に相当する話として、LRU 系などが試験に出ることがあります。ホットキーが淘汰されると DB に thundering herd が起きる、というストーリーで DAX／事前ウォーム／ジッター が対比されます。
DynamoDB・DAX との距離（誤答しやすい）
| 要件 | 寄り先 |
|---|---|
| セッションやホットキーの一時退避 | ElastiCache |
| 永続の主記録 | DynamoDB または RDB |
| DynamoDB の読み取りを互換 API で極限まで速く | DAX（ElastiCache, DAX） |
誤答の型
- 「DynamoDB が遅いから ElastiCache に主データを全部移す」→ 耐久性とクエリモデルが崩れやすい。
- 「DAX と Redis はどちらも同じだからどちらでもよい」→ DAX は DynamoDB 専用。
セキュリティ（転送・保管・認証）
Redis では 転送中 TLS、保管時 KMS、Redis AUTH などがセットで問われます。Memcached も TLS のサポートが進展しているため、採用時点のエンジンバージョンで公式を確認してください。
アーキテクチャ定石（チェックリスト）
- RDS／DynamoDB を正とし、読み取りのホットスポットだけを ElastiCache に逃がす。
- キャッシュ無効化（TTL、バージョン付きキー、更新時の削除）を設計に含める。
- 障害時にキャッシュが空でも成立するか（graceful degradation）。
- セキュリティグループでクライアントを限定し、暗号化を有効化する。
関連トピック
重要ポイント
- ▸Redisは豊富なデータ構造とレプリケーション・自動フェイルオーバー・スナップショット等。MemcachedはマルチスレッドのシンプルKVに強い
- ▸Pub/Sub、ソート済み集合、ジオ、LuaはRedis寄り。Memcachedはスループット至上の単純キャッシュに寄せる
- ▸キャッシュは揮発前提。正のデータはRDSやDynamoDBに置き、無効化戦略を設計に含める
- ▸DynamoDBは主記録、DAXはDynamoDB読み取り特化。用途が似ても層が異なる
- ▸TLS・保管時暗号化・AUTHの可否はエンジンとバージョンで変わるため公式の暗号化ガイドで確認
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
RDS / Aurora / ElastiCache に関連するトピックを続けて確認できます。