Amazon ElastiCache
Amazon ElastiCache は、データをメモリ上に置いて高速に読み書きする「インメモリキャッシュ」を AWS が管理してくれるサービスです。SAA では「データベースの読み取り負荷を下げて応答を速くする」「セッション情報を複数のサーバーで共有する」といった要件で選びます。キャッシュ戦略（遅延読み込み・書き込みスルー・TTL）と、エンジン（Valkey / Redis OSS と Memcached）の違いが問われます。
ひとことで言うと: よく使うデータを、データベースの手前のメモリに置いておく「速い置き場所」です。
たとえるなら、倉庫（データベース）まで取りに行かなくて済むように、よく売れる商品をレジ横の棚（キャッシュ）に並べておくようなものです。棚の商品は倉庫の在庫と食い違うことがあるので、入れ替えのルールを決めておきます。
このページで押さえる論点
ElastiCache の基本
データベースはデータをディスク（SSD など）に保存するので、読み取りのたびにディスクへのアクセスや問い合わせの処理が発生します。ElastiCache はデータをメモリに置くので、ミリ秒未満（マイクロ秒単位）で応答できます。
ElastiCache は単独で使うというより、RDS や DynamoDB などの手前に置いて使うのが基本です。何度も読まれるデータや、計算に時間のかかる問い合わせ（複数テーブルの JOIN など）の結果をキャッシュに入れておくと、データベースへの問い合わせが減り、次の効果があります。
- 応答が速くなる（利用者の待ち時間が減る）
- データベースの読み取り負荷が下がる（インスタンスのサイズを上げたり、リードレプリカを増やしたりせずに済むことがある）
- 読み取りが急に増えても、データベースが処理しきれなくなるのを防げる
キャッシュに向くのは「よく読まれる」「取り出すのが遅い・高い」「多少古くても困らない（またはあまり変わらない）」データです。商品カタログ、ユーザーのプロフィール、ランキングなどが代表例です。
ElastiCache の作り方には、ノード（キャッシュ用のサーバー）の種類や台数を自分で決めるノードベースのクラスターと、容量の設計なしで使える ElastiCache Serverless があります。Serverless はアプリの負荷に合わせてメモリ・CPU・ネットワークを自動でスケールし、1 分未満で作成できます。
キャッシュ戦略
キャッシュを使うときは、「いつキャッシュにデータを入れるか」「古くなったデータをどう入れ替えるか」をアプリ側で決めます。これをキャッシュ戦略と呼びます。代表的なのは次の 3 つです。
| 戦略 | しくみ | 良い点 | 注意点 |
|---|---|---|---|
| 遅延読み込み（レイジーローディング） | まずキャッシュを見る。なければ（キャッシュミス）DB から読み、キャッシュに書き込んでから返す | 実際に読まれたデータだけがキャッシュに入る。キャッシュのノードが故障しても、遅くなるだけで動き続ける | ミスのたびに 3 回の往復（キャッシュ→DB→キャッシュ）で遅くなる。DB が更新されてもキャッシュは古いまま |
| 書き込みスルー | DB に書き込むたびに、キャッシュにも同じデータを書き込む | キャッシュのデータが常に新しい | 読まれないデータまでキャッシュに入り、メモリを無駄に使う。ノードの追加や故障のあと、データが入るまでは空のまま |
| TTL（有効期限）の追加 | キャッシュのデータに有効期限（秒）を付け、期限が切れたらキャッシュにないものとして扱う | 古いデータが残り続けるのを防ぎ、使われないデータも自然に消える | 期限内は古いデータが返ることがある |
実際には、遅延読み込みと書き込みスルーを組み合わせ、TTL も付けるのが推奨されています。試験では「データが古くなってもよいか」「キャッシュミスの遅さを許容できるか」で戦略を選びます。
遅延読み込みと TTL の動き
※簡略化しています: キャッシュを読み書きする処理はアプリのコードに書く（ElastiCache が自動で DB から読んでくれるわけではない）ことを、アプリからの矢印で表しています。応答時間の差や、TTL を 300 秒とした時間の経過は一瞬で描いています。書き込みスルーは表で説明しています。
エンジンの選び方: Valkey / Redis OSS と Memcached
ElastiCache では、キャッシュのソフトウェア（エンジン）を Valkey、Redis OSS、Memcached から選びます。Valkey と Redis OSS は、データ型・レプリケーション・フェイルオーバーなどの機能がほぼ共通で、ElastiCache のドキュメントでも同じ列で比べられています。試験で「Redis」と書かれていたら、Valkey / Redis OSS の列で考えます。
| 機能 | Valkey / Redis OSS | Memcached |
|---|---|---|
| レプリケーション（高可用性） | あり（リードレプリカ） | なし |
| 自動フェイルオーバー（マルチ AZ） | あり | なし |
| バックアップと復元 | あり | サーバーレスキャッシュのみ（ノードベースのクラスターはなし） |
| データ型 | 文字列に加え、リスト・ハッシュ・セット・ソート済みセット（順位付きの集合）など | 単純な文字列・オブジェクトのみ |
| Pub/Sub（メッセージの配信） | あり | なし |
| マルチスレッド | なし | あり（1 ノードで複数の CPU コアを使える） |
選び方の目安は次のとおりです。
- Valkey / Redis OSS: 高可用性（フェイルオーバー）、バックアップ、ランキング（ソート済みセット）、Pub/Sub など、キャッシュ以上の機能が必要なとき。試験ではこちらが正解になることが多いです。
- Memcached: 単純なキャッシュでよく、データが消えても DB から作り直せる。マルチスレッドで 1 ノードの性能を上げたい、ノードを足して横に広げたいとき。
ゲームのリーダーボード（スコアの順位表）は、スコアを入れるたびに自動で並べ替えるソート済みセットで作れるので、Valkey / Redis OSS の定番の使い道です。
高可用性とスケーリング
Valkey / Redis OSS のノードベースのクラスターでは、データをシャード（データを分けて持つ単位）に分けて保存します。1 つのシャードは、読み書きするプライマリノード 1 台と、読み取り専用のリードレプリカ最大 5 台でできています。
| 構成 | シャード数 | スケールの仕方 |
|---|---|---|
| クラスターモード無効 | 1 つだけ | ノードのサイズを上げる（垂直スケーリング）。読み取りはレプリカで分散 |
| クラスターモード有効 | 最大 500（ノード数も合計 500 まで） | シャードを増やしてデータと書き込みを分散（水平スケーリング） |
マルチ AZ の自動フェイルオーバーを有効にすると、プライマリノードが故障したときにリードレプリカが自動で昇格します。レプリカを別の AZ に置けば AZ 障害にも備えられます。ただしレプリケーションは非同期なので、まだレプリカにコピーされていない直前の書き込みは失われることがあります。
Memcached にはレプリケーションがありません。ノードが故障するとそのノードのデータは失われるので、データは DB から読み直します。
セッション情報の保存とステートレスなアプリ
セッション情報とは、ログイン状態やショッピングカートの中身のように、利用者ごとに一時的に覚えておくデータです。これを各 EC2 のメモリに持つと、次の問題が起きます。
- ロードバランサーが別の EC2 にリクエストを振り分けると、ログイン状態が失われる
- Auto Scaling で EC2 が終了すると、その EC2 のセッション情報も消える
スティッキーセッション（同じ利用者を同じ EC2 に送り続ける ELB の機能）でもしのげますが、負荷が偏り、EC2 の終了でセッションが消える問題は残ります。そこで、セッション情報を ElastiCache（または DynamoDB）に外出しして、どの EC2 からも同じデータを読めるようにします。EC2 がデータを持たない（ステートレスな）構成にすると、自由に台数を増減できます（ELB と Auto Scaling を参照）。
セキュリティ
- ElastiCache は VPC の中に作り、セキュリティグループでアプリのサーバーからの接続だけを許可します。
- 転送中の暗号化（TLS）と保管時の暗号化を有効にできます。Memcached は転送中の暗号化に対応しています（バージョン 1.6.12 以降）。
- Valkey / Redis OSS では、接続時にパスワード（AUTH トークン。転送中の暗号化が必要）や、ユーザーごとに操作を制限するロールベースのアクセス制御（RBAC。サーバーレスキャッシュでは必須）で認証できます。
キャッシュの選び方
AWS には「キャッシュ」の役割を持つサービスがいくつかあります。何をキャッシュしたいかで選びます。
| サービス | キャッシュするもの | 選ぶ場面 |
|---|---|---|
| Amazon ElastiCache | アプリが決めた任意のデータ（DB の問い合わせ結果・セッションなど） | RDS・Aurora の読み取り負荷を下げたい、セッションを共有したい、ランキングを作りたい |
| DynamoDB Accelerator（DAX） | DynamoDB の読み取り結果 | DynamoDB の読み取りをマイクロ秒にしたい。コードの変更を最小限にしたい（DynamoDB を参照） |
| Amazon CloudFront | 画像・動画・HTML などのコンテンツ | 世界中の利用者に近いエッジロケーションからコンテンツを配信したい |
| RDS のリードレプリカ | （キャッシュではなく DB のコピー） | SQL の読み取り全般を分散したい。アプリのキャッシュ処理を書きたくない（RDS と Aurora を参照） |
問題文のキーワード → 選ぶべき答え
| 問題文の言い回し | 答えと理由 |
|---|---|
| 「同じ問い合わせが繰り返され、RDS の読み取り負荷が高い」 | ElastiCache で問い合わせ結果をキャッシュ |
| 「ミリ秒未満の応答」「インメモリ」 | ElastiCache（DynamoDB の場合は DAX） |
| 「セッション情報を複数の EC2 で共有」「ステートレスにする」 | ElastiCache（または DynamoDB）にセッションを保存 |
| 「キャッシュのデータを常に最新にしたい」 | 書き込みスルー。DB への書き込みと同時にキャッシュも更新 |
| 「読まれたデータだけをキャッシュ」「キャッシュの容量を節約」 | 遅延読み込み |
| 「古いデータが残り続けないようにしたい」 | TTL を設定 |
| 「キャッシュの高可用性・自動フェイルオーバー」「バックアップ」 | Valkey / Redis OSS（マルチ AZ を有効化） |
| 「リアルタイムのランキング（リーダーボード）」 | Valkey / Redis OSS のソート済みセット |
| 「シンプルなキャッシュ」「マルチスレッド」「データは失われてもよい」 | Memcached |
| 「キャッシュの容量を設計・管理したくない」 | ElastiCache Serverless |
引っかけポイント
- 「ElastiCache を置けば、アプリを変えずに DB が速くなる」→ ✕。キャッシュを読み書きする処理はアプリのコードに書く。コード変更を最小限にしたい DynamoDB なら DAX、RDS ならリードレプリカも候補
- 「Memcached でマルチ AZ の自動フェイルオーバー」→ ✕。Memcached にはレプリケーションもフェイルオーバーもない。高可用性が必要なら Valkey / Redis OSS
- 「遅延読み込みならキャッシュのデータは常に最新」→ ✕。DB を更新してもキャッシュは古いまま。TTL や書き込みスルーで対策する
- 「書き込みスルーならキャッシュの容量を節約できる」→ ✕。読まれないデータまで書き込まれるので容量を多く使う
- 「画像や動画の配信を速くしたいので ElastiCache」→ ✕。静的コンテンツを利用者の近くから配信するのは CloudFront
- 「セッション情報は EC2 のローカルディスクに保存してスティッキーセッションで対応」→ △。動くが、EC2 の終了でセッションが消え、負荷も偏る。ElastiCache や DynamoDB への外出しが推奨
まとめ: SAA 試験で押さえるポイント
- ElastiCache はインメモリのキャッシュ。DB の手前に置いて読み取り負荷を下げ、応答を速くする
- 遅延読み込みは読まれたデータだけをキャッシュするが、ミス時に遅く、データが古くなりやすい
- 書き込みスルーはデータが常に新しいが、使われないデータでメモリを消費する。TTL を組み合わせて古いデータを消す
- 高可用性・バックアップ・ランキング・Pub/Sub が必要なら Valkey / Redis OSS、単純なキャッシュでマルチスレッドなら Memcached
- Valkey / Redis OSS は 1 シャードにリードレプリカ最大 5 台。マルチ AZ で自動フェイルオーバー。クラスターモード有効でシャードを増やして水平スケール
- セッション情報を ElastiCache（または DynamoDB）に外出しして、EC2 をステートレスにする
- DynamoDB 専用のキャッシュは DAX、コンテンツ配信のキャッシュは CloudFront
確認問題
参考リンク
AWS 公式ドキュメント（外部サイトが開きます）。