はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した ElastiCache / DAX 関連の知識をまとめました。
「どのキャッシュサービスを選ぶか」は試験で頻出であり、Redis vs Memcached の違い、DAX との使い分け、地理空間データの扱いなど、判断ポイントが多いサービス群です。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
ElastiCache Redis vs Memcached
| Redis | Memcached | |
|---|---|---|
| 地理空間データ | ✅ | ❌ |
| データ構造 | 豊富（String, List, Set, Hash, Sorted Set, Geo 等） | String のみ |
| 永続化 | ✅ | ❌ |
| レプリケーション | ✅ | ❌ |
| Pub/Sub | ✅ | ❌ |
| マルチスレッド | ❌ | ✅ |
試験のポイントは明快です。「地理空間」が出たら Redis 一択。高度な機能が不要でシンプルなキャッシュだけなら Memcached です。
DAX（DynamoDB Accelerator）
- DynamoDB 専用キャッシュ
- DynamoDB API と完全互換 → コード変更最小
- ミリ秒 → マイクロ秒に高速化
キャッシュサービスの使い分け
| サービス | 用途 | 特徴 |
|---|---|---|
| DAX | DynamoDB 専用キャッシュ | API 互換、コード変更最小 |
| CloudFront | S3 等の静的/動的コンテンツ配信 | エッジキャッシュ |
| ElastiCache Redis | 汎用インメモリキャッシュ | セッション、リーダーボード、地理空間 |
| ElastiCache Memcached | シンプルなキャッシュ | 単純な Key-Value |
ElastiCache Redis のユースケース
適している用途:
- 読み取り負荷の高いアプリ（リーダーボード、SNS、Q&A）
- コンピュート集約型の結果キャッシュ（レコメンデーション等）
- セッションストア
- リアルタイム分析
- 地理空間データ（GEOADD, GEORADIUS, GEODIST）
適さない用途:
- 書き込み負荷の高いアプリ（キャッシュがすぐ古くなる）
ElastiCache の高可用性
- Multi-AZ + 自動フェイルオーバー
- Read Replica はスケーリング用（DR ではない）
- バックアップ（日次 / AOF）はデータ損失リスクあり
地理空間コマンド（Redis）
| コマンド | 用途 |
|---|---|
GEOADD |
緯度 / 経度を追加 |
GEORADIUS |
指定半径内のメンバーを検索 |
GEODIST |
2点間の距離を計算 |
試験で問われる設計パターン
キャッシュサービスの選択
DynamoDB キャッシュ → DAX、S3 静的コンテンツ → CloudFront
シナリオ: DynamoDB の読み取り性能を改善しつつ、S3 の静的コンテンツも高速に配信したいです。それぞれどのキャッシュサービスを使うべきでしょうか？
正解: DAX + CloudFront
- DAX = DynamoDB API 互換
- ElastiCache Redis は汎用キャッシュ
- ElastiCache Memcached は S3 キャッシュには不向き
Aurora 読み取り負荷（繰り返し同じクエリ）→ ElastiCache Redis
シナリオ: Aurora に対して同じクエリが繰り返し実行され、読み取り負荷が高くなっています。最もコスト効率の良い対策はどれでしょうか？
正解: ElastiCache for Redis
- 同じクエリの繰り返し → キャッシュが最適
- Read Replica を追加しても毎回 DB にクエリが飛ぶ
インメモリ + リアルタイムリーダーボード → ElastiCache Redis / DynamoDB + DAX
シナリオ: リアルタイムのリーダーボード機能にインメモリのデータストアが必要です。どのサービスが適切でしょうか？（2つ選択）
正解:
- ElastiCache for Redis
- DynamoDB + DAX
- 「インメモリ」→ ElastiCache Redis / DAX
- Aurora / Neptune はインメモリではない
- DynamoDB 単体はインメモリではない（DAX が必要）
地理空間データ系
RDB キャッシュ + 地理空間データ → ElastiCache for Redis
シナリオ: リレーショナル DB のキャッシュとして使いつつ、地理空間データ（位置情報の検索）も処理したいです。どのキャッシュサービスが適切でしょうか？
正解: ElastiCache for Redis
- 「地理空間」→ Redis 一択（Memcached は非対応）
- DAX は DynamoDB 専用
- Global Accelerator はネットワーク最適化
リアルタイム位置追跡 + 高頻度読み書き + 地理空間 → ElastiCache Redis
シナリオ: ライドシェアアプリで、ドライバーの GPS 座標を高頻度で更新・読み取りしています。「半径 X km 以内のドライバー」を検索する機能も必要です。どのサービスが最適でしょうか？
正解: ElastiCache for Redis + TTL ベースのキャッシュ戦略
- Redis の地理空間コマンド（GEOADD 等）で半径検索が1コマンドで可能
- RDS Read Replica は書き込み負荷を軽減しない
セッション管理系
分散インメモリセッション管理 → ElastiCache
シナリオ: 複数の EC2 インスタンスでセッション情報を共有したいです。サーバー障害時もセッションが失われないようにするにはどうすべきでしょうか？
正解: Amazon ElastiCache（Redis or Memcached）
- サーバー障害時もセッション維持
- ALB Sticky Sessions はサーバー障害時にセッション消失
- DynamoDB はディスクベース（インメモリではない）
高可用性系
ElastiCache Redis DR → Multi-AZ + 自動フェイルオーバー
シナリオ: ElastiCache Redis のデータ損失を最小限にしたいです。DR（災害復旧）策としてどの構成が最適でしょうか？
正解: Multi-AZ + 自動フェイルオーバー
- バックアップ（日次 / AOF）はデータ損失リスクがある
- Read Replica は読み取りスケーリング用（DR ではない）
ユースケース選択系
ElastiCache の適切なユースケース
シナリオ: ElastiCache が最も効果を発揮するユースケースを2つ選んでください。
正解:
- 読み取り負荷の高いワークロードのレイテンシー・スループット改善
- コンピュート集約型ワークロードのパフォーマンス改善
- 書き込み負荷が高いとキャッシュがすぐ古くなるため効果が薄い
- ETL は Glue / EMR、複雑な JOIN は RDS / Aurora の領域
おわりに
キャッシュサービスの選択は「DynamoDB → DAX」「地理空間 → Redis」「シンプルなキャッシュ → Memcached」「S3 配信 → CloudFront」という判断パターンで整理できます。特に「地理空間データが出たら Redis 一択」というルールは、試験で反射的に使えるようにしておきましょう。
間違いや補足があればぜひコメントで教えてください。