RDS や DynamoDB を触ったあと、「読み取りが増えて DB が重い」「セッションを複数台で共有したい」と言われて ElastiCache の名前を聞く場面があります。DB と何が違うのか、どこに置くのか、何が壊れうるのかを説明できないと、「速いデータベース」として正のデータを置く事故につながります。この記事では、DB の前に置く読み取りの近道という位置づけから、載せ方と古さの扱いまでを順に整理します。DB 側の基本は RDS とは に譲ります。
この記事の結論
- ElastiCache はマネージドのインメモリ・データストア（キャッシュ）で、アプリと DB の間に置いて読み取りの負荷とレイテンシを下げます。
- 使い方は2つあります。容量を AWS が見るサーバーレスと、ノードの種類・数・配置を自分で決めるノード型です。
- エンジンは Valkey・Redis OSS・Memcached の3つです。高度な機能が要るなら Valkey / Redis OSS 系、単純な水平スケールのキャッシュなら Memcached が候補になります。
- 載せ方の基本は遅延読み込み（キャッシュアサイド）です。古さは TTL で許容範囲を決め、ライトスルーを組み合わせることもあります。
- キャッシュが空になっても動く設計にします。正のデータは DB に残し、ElastiCache を正の保存先にしません。
ElastiCache とは何か｜DB の前に置くインメモリのキャッシュ
Amazon ElastiCache は、データをメモリの上に置いて読み書きを速くする、マネージドのインメモリ・データストアです。ディスクを経由する DB より読み取りが速く、よく読まれるデータを手前に置いておく用途に向いています。ノードの導入やパッチ適用といった土台の面倒を AWS が見る点は、RDS と同じ考え方です。
ここで押さえたいのは役割です。ElastiCache は DB の代わりではなく、DB の前に置く近道です。アプリはまずキャッシュを見て、あればそこから返します。無ければ DB から読み、次のためにキャッシュへ入れます。
CACHE-ASIDE読み取りの流れ
まずキャッシュを見て、無いときだけ DB から読んで載せる
-
キャッシュを見る
アプリが最初に問い合わせる
-
あれば返す
ヒット。DB には行かない
-
無ければ DB を読む
ミスのときだけ
-
キャッシュに書く
TTL を付けて返す
たとえるなら、窓口の手元に貼った「よく聞かれる質問の答え」のメモです。奥の書庫（DB）まで毎回取りに行かずに済みますが、正本は書庫にあります。メモは古くなったら書き直します。用語に戻すと、メモがキャッシュ、書庫が DB、書き直しの期限が TTL です。
なぜ DB の前に置くのか｜読み取りが多いデータと、毎回同じ答えを返す問い合わせ
DB が重くなる典型は、同じ内容を何度も読み出している状態です。商品の詳細や設定値のように、更新は少なく、読み取りが多いデータがその例です。毎回 DB に問い合わせると、DB の CPU とコネクションを同じ答えのために使い続けることになります。
そこで、読み取りの多いデータをメモリに置き、DB へ行く問い合わせを減らします。効果は2つです。
- DB の負荷が下がる。読み取りを手前で受け止めるので、DB は書き込みや本当に必要な問い合わせに集中できます。
- 応答が速くなる。メモリから返すので、DB まで往復するより待ち時間が短くなります。
一方で、向かないデータもあります。毎回違う答えを返す問い合わせや、常に最新でなければならない値は、載せても当たりません。何を載せるかは「読む回数が多く、少し古くてもよいか」で決めます。
CHECK 1ここまでの確認
読み取りが増えて DB が重いとき、DB の前に置いて負荷を逃がす部品はどれ?
答えと解説
答え: 2. ElastiCache のようなインメモリのキャッシュ
ElastiCache は DB の代わりではなく、DB の前に置く読み取りの近道です。正のデータは DB に残ります。最初の2つの章を読み直してください。
サーバーレスとノード型の違い｜容量を任せるか、ノードを自分で決めるか
ElastiCache には、サーバーレスとノード型の2つの使い方があります。違いは、容量とノードを誰が見るかです。
SERVERLESS VS NODES容量を見るのは誰か
サーバーレスは容量を任せ、ノード型は自分で決める
サーバーレス
決めることを減らす
- 容量は AWS が見る
- ノードの種類・数は選ばない
- 負荷が読みにくくても始めやすい
ノード型
構成を自分で握る
- 容量を見積もって決める
- ノードの種類・数・配置を選ぶ
- 構成を細かく決めたいときに向く
| 観点 | サーバーレス | ノード型 |
|---|---|---|
| 容量を見る人 | AWS が見る | 自分で見積もって決める |
| ノードの選択 | 利用者は選ばない | 種類・数・配置を自分で決める |
| 向く場面 | 負荷が読みにくい、まず始めたい | 構成を細かく決めたい、前提が固まっている |
どちらが優れているというより、「決めることを AWS に任せるか、自分で握るか」の選択です。RDS で「自分で持つものを減らすほど運用が楽になる」と整理したのと同じ軸です。対応する機能や条件、料金は更新されるので、選ぶ前に公式ドキュメントで確認してください。
Valkey・Redis OSS・Memcached はどう選ぶか｜機能の多さか、単純さか
ElastiCache が使えるエンジンは、Valkey・Redis OSS・Memcached です。大きく分けると、機能の多い Valkey / Redis OSS 系と、単純な Memcached の2系統になります。
| 観点 | Valkey / Redis OSS 系 | Memcached |
|---|---|---|
| 性格 | 機能が多い | シンプル |
| 永続化・レプリカ | 使える | 想定しない |
| Pub/Sub など | 使える | 使えない |
| 向く用途 | キャッシュ以外の用途も含めて使う | 単純なキャッシュを水平に増やす |
永続化・レプリカ・Pub/Sub といった機能が要るなら Valkey / Redis OSS 系を選びます。値を置いて読むだけの単純なキャッシュを、台数を増やして支えたいなら Memcached が候補になります。
エンジンごとの機能の対応や、新しい版の扱いは更新が速い領域です。選ぶ前に、公式ドキュメントのエンジンの比較で最新の状況を確かめてください。ここでは、機能の多さで選ぶか単純さで選ぶかという判断軸だけを持ち帰れば十分です。
キャッシュにデータを載せる方法｜遅延読み込み・ライトスルー・TTL
キャッシュに何をいつ載せるかには、代表的な方式があります。
遅延読み込み（キャッシュアサイド）
必要になったときに載せる方式です。アプリはキャッシュを見て、無ければ（ミス）DB から読み、その結果をキャッシュに入れて返します。あれば（ヒット）DB には行きません。
- 長所: 実際に読まれたデータだけが載る。キャッシュが落ちても DB から読めるので動き続ける。
- 短所: ミスの1回目は遅い。DB が更新されても、キャッシュの値は古いまま残りうる。
ライトスルー
書き込みのたびに、DB とキャッシュの両方を更新する方式です。
- 長所: キャッシュが常に新しい。
- 短所: 書き込みが遅くなる。一度も読まれないデータまで載るので、載せすぎになりやすい。
TTL で古さの許容範囲を決める
TTL（有効期限）は、キャッシュの値を古いまま使ってよい長さです。期限が切れた値は捨てられ、次の読み取りで DB から読み直されます。
FRESHNESS VS LOADTTL でつり合わせる
載せ方は古さと書き込みの重さを TTL でつり合わせる
遅延読み込み
- 古くなりうる
- 最初のミスは遅い
ライトスルー
- 常に新しい
- 書き込みが遅い
- 載せすぎになりやすい
古さの許容範囲
TTL を短くすれば新しさは保てますが、ミスが増えて DB へ戻る問い合わせが増えます。長くすれば DB の負荷は下がりますが、古い値を見せる時間が延びます。つまり TTL は、新しさと DB の負荷の釣り合いを決めるつまみです。値は、データが何分古くても業務上困らないかから決めます。
実務では、遅延読み込みを基本にして TTL を付け、更新が頻繁で古さが許されないデータだけライトスルーを足す、という組み合わせがよく取られます。
CHECK 2ここまでの確認
キャッシュに無かったときだけ DB から読み、その結果をキャッシュに入れる載せ方を何と呼ぶ?
答えと解説
答え: 2. 遅延読み込み（キャッシュアサイド）
遅延読み込みは「ミスのときだけ DB を読む」方式です。ヒットすれば DB には行きません。ライトスルーは書き込みのたびに更新する方式です。
CHECK 3ここまでの確認
TTL で決めているものはどれ?
答えと解説
答え: 1. キャッシュの値を古いまま使ってよい長さ
TTL は古さの許容範囲です。期限が切れた値は捨てられ、次の読み取りで DB から読み直します。載せ方の章を読み直してください。
セッションの置き場にもなる｜アプリをステートレスにする
ElastiCache の用途は、DB の手前のキャッシュだけではありません。セッション情報の置き場としても使われます。
Web アプリを複数台に増やすと、ログイン状態をサーバー自身のメモリに持っている場合、リクエストが別のサーバーに振り分けられた途端にログインが切れます。スケールインで台数が減るときも、消えるサーバーの分の利用者が切れます。
そこで、セッションを各サーバーの外にある共有ストアに出します。ElastiCache や DynamoDB が置き場の候補になります。どのインスタンスからも同じセッションを読めるので、アプリはステートレスになり、台数を自由に増減できます。
注意点は、セッションを置いた ElastiCache が止まると全員のログインに影響しうることです。置き場を単一のノードにせず、レプリカや配置で可用性を考える必要があります。構成の詳細は運用の層の話なので、ここでは「外に出す」という考え方までを押さえてください。
CHECK 4ここまでの確認
アプリを複数台に増やしても利用者のログイン状態が切れないようにする設計は?
答えと解説
答え: 2. セッションを ElastiCache のような共有ストアに出す
どのインスタンスからも読める場所にセッションを置くと、アプリ側はステートレスになります。セッションの章を読み直してください。
DB の代わりにしてはいけない理由｜正のデータはどこか
最後に、よくある誤解を整理します。ElastiCache はメモリ上で動くので速いですが、だからといって正のデータの保存先にはできません。
ElastiCache でやってはいけないこと
- 失ってはいけないデータを、DB に無いままキャッシュにだけ置く
- キャッシュが常に温まっている前提で、空になった瞬間の DB の負荷を見積もらない
- 古くなってはいけない値に、長い TTL を付けたまま載せる
理由は3つあります。
- キャッシュはいつ空になってもよい前提で設計するものです。ノードの入れ替えや障害で中身が消えることがあります。
- 空になった直後は、全部がミスになって DB に問い合わせが集中します。DB がその負荷を受けられるかを事前に考えます。
- 遅延読み込みでは、DB が更新されてもキャッシュが古いまま残ります。古さを許容できない値は載せないか、TTL を短くします。
まとめると、正のデータは DB に残し、ElastiCache は「消えても作り直せる写し」を置く場所として使います。その前提なら、キャッシュが落ちても DB から読んで動き続けられます。
Cloudory 執筆者（AWS 認定 全冠）
「速くしたい」と聞いたときは、先に「何が何度も読まれているか」と「何分古くてよいか」の2つを聞きます。この2つが決まれば、載せるか、どう載せるか、TTL をどうするかはほぼ決まります。
参照ソース
- What is Amazon ElastiCache?（Amazon ElastiCache ユーザーガイド） — ElastiCache の定義、サーバーレスとノード型、対応エンジンの根拠（2026-11 時点）
- Caching strategies（Amazon ElastiCache ユーザーガイド） — 遅延読み込み・ライトスルー・TTL とそれぞれの長所短所の根拠（2026-11 時点）
