Amazon ElastiCacheとは ― キャッシュ戦略

同じデータを何度もデータベースから読むと、そのたびに時間と費用がかかります。よく読むデータをメモリに置いて返し、データベースへの問い合わせを減らすのが、Amazon ElastiCacheです。メモリ上のキャッシュをAWSが構築・管理するサービスです。アプリとデータベースの間に置いて使います。

データベースそのものは、RDSやDynamoDBなど別のサービスに置きます。ElastiCacheが保持するのは、そのデータのコピーです。機器の用意・監視・故障したノードの交換・ソフトウェアの更新は、AWSが行います。

アプリは、データが必要なときに、まずキーを指定してElastiCacheを読みます。値があれば、ElastiCacheがそのまま返します。この場合をキャッシュヒットと呼びます。

値が無いときや期限が切れているときは、キャッシュミスです。この場合は、アプリがデータベースに問い合わせ、受け取った結果をElastiCacheに書き込みます。次に同じキーを読むと、ヒットします。

AWSのユーザーガイドの説明では、データベースへの問い合わせはキャッシュからキーで値を探すより遅く、費用もかかります。ElastiCacheは、メモリに置いたキーと値の組を1ミリ秒未満で読めるように設計されています。複数の表を結合する重い問い合わせも、結果をキャッシュしておけば、実行は1回で済みます。

保存した結果を期限まで再利用する考え方は、DNSの記事やCDNの記事で説明したキャッシュと同じです。キャッシュに向くのは、何度も読まれ、あまり変わらないデータです。頻繁に変わるデータや、めったに読まれないデータは、キャッシュしても効果がありません。

ユーザーガイドは、キャッシュしたデータは古いものとして扱うよう勧めています。どこまで古い値を許容できるかは、データの用途で決まります。キャッシュにいつデータを保存するかの決め方が、次の2つの戦略です。

前の節の図の流れが、遅延読み込みです。必要になったデータだけを、読み出しでミスしたときにキャッシュに保存します。AWSの資料は、キャッシュアサイドとも呼ばれるこの方法を、最も広く使われるキャッシュの方法としています。

遅延読み込みでは、読まれたデータだけがキャッシュに保存されます。そのため、読まれないデータでメモリが埋まりません。ノードが故障して空のノードに交換されても、ミスが増えて遅くなるだけで、アプリは動き続けます。

欠点は2つあります。1つは、ミスのたびにキャッシュ・データベース・キャッシュと3回の往復が必要で、応答に時間がかかることです。もう1つは、データベースの値を書き換えても、キャッシュの値が古いまま残ることです。

書き込みスルーは、アプリがデータベースに書き込むたびに、キャッシュにも同じ値を書き込む方法です。キャッシュの値は書き込みのたびに更新されるので、古くなりません。その代わり、書き込みのたびに、データベースとキャッシュの2回の書き込みが必要です。

読まれないデータまでキャッシュに保存されるので、メモリが無駄になります。ユーザーガイドは、TTLを付けるとこの無駄を減らせるとしています。

故障したノードを交換したときや、ノードを追加したときは、新しいノードは空の状態から始まります。データベースに書き込まれるまで、そのデータは新しいノードにありません。ユーザーガイドは、遅延読み込みと組み合わせると、このデータの欠落を減らせるとしています。

TTLは、キーの期限が切れるまでの時間です。キャッシュに書き込むときに付けておくと、期限が切れたキーは無いものとして扱われます。アプリはデータベースから読み直し、キャッシュを更新します。

ユーザーガイドの例は、遅延読み込みと書き込みスルーのどちらにも、300秒のTTLを付けています。TTLを付けても、値が古くならないことまでは保証されません。それでも、古くなりすぎるのを防ぎ、読まれないデータがメモリを占有するのも減らせます。

期限はValkeyとRedis OSSでは秒かミリ秒で、Memcachedでは秒で指定します。DNSの応答のTTLと同じく、キャッシュを使ってよい期間を表します。IPヘッダのTTLは、ルータを1台通過するたびに1減る値で、別のものです。

次の図で戦略を選び、操作を1つずつ進めます。要求が届いた箱と矢印が強調され、アプリが受け取った値が最新か古いかが分かります。

遅延読み込みでは、5段目で古い1000円が返ります。両方＋TTLでは、期限が切れたあとの読み出しでデータベースに問い合わせ、最新の値を取得し直します。

ElastiCacheでは、キャッシュの内容を管理するソフトウェアを選びます。このソフトウェアをエンジンと呼びます。選べるのは、Valkey・Memcached・Redis OSSの3つです。どれも、キーと値の組をメモリに保存する仕組みです。

複製や多くのデータ型が必要ならValkeyかRedis OSS、単純さを優先するならMemcachedです。Memcachedはマルチスレッドで動き、コアの多い大きなノードを使えます。ノードを追加・削除して、台数を増減することもできます。

ValkeyとRedis OSSは、ほかのノードにデータを複製し、障害のときに自動で切り替えられます。ソート済みセットのような型を使うと、ゲームの順位表を作れます。ノードベースのValkeyの9.0以降では、データを複数のAZのログに残し、障害時にも失わない設定を選べます。

ElastiCacheの利用形態は2つあります。サーバーレスのキャッシュと、ノードベースのクラスタです。

サーバーレスは、名前を付けるだけで作れます。メモリや処理の使用量に応じて、AWSが自動で容量を増減します。データは3つのAZに保存され、可用性の保証は99.99%です。アクセス量を予測できない新しいアプリや、まず試したいときに向きます。

ノードベースは、ノードの種類と数、配置するAZを利用者が選びます。必要な容量を確保するのは、利用者の責任です。アクセス量をある程度予測でき、性能や費用を細かく管理したいときに向きます。

ElastiCacheの使いどころは、何度も読まれるデータをメモリから返し、データベースへの問い合わせを減らすことです。ログイン中の利用者の情報のように、短期間だけ保持すればよいデータの保存先にも使えます。セッションの情報とCookieの関係は、Cookieの記事で説明しています。

DynamoDBには、DAXという専用のキャッシュがあります。DAXはDynamoDBと同じAPIで使えます。DAXのクライアントが要求をDAXに送ります。キャッシュに無ければ、DAXがDynamoDBに要求を渡して、結果をキャッシュに入れます。ElastiCacheでは、キャッシュの読み書きとデータベースへの問い合わせの処理を、アプリに実装します。

CloudFrontもキャッシュを持ちますが、場所と内容が違います。CloudFrontは、利用者の近くのエッジロケーションで、HTTPの応答をキャッシュします。ElastiCacheは、アプリのそばで、データベースから読んだデータをキャッシュします。

2026年10月29日に料金ページで確認した、料金の決まり方は次のとおりです。料金体系には、オンデマンド・サーバーレス・Database Savings Plansがあります。金額は、リージョンやエンジンによって変わります。

• サーバーレス：保存したデータの量を1時間ごとの平均で数え、処理した要求の量をECPUという単位で数えます。読み書きするデータ1KBごとに、1ECPUを数えます。
• ノードベース：ノードを起動してから止めるまでの時間で数えます。1時間に満たない分も、1時間として数えます。
• リザーブドノード：ノードベースで、1年か3年の利用を約束して割引を受けます。サーバーレスでは使えません。

エンジンによっても料金は変わります。サーバーレスのValkeyは、ほかのエンジンより33%安い料金です。課金の最低データ量も、ほかのエンジンの1GBに対して100MBです。ノードベースでは、ValkeyはRedis OSSより20%安い料金です。

• AWS「What is Amazon ElastiCache?」と「Choosing between deployment options」
• AWS「Caching strategies for Memcached」（遅延読み込み・書き込みスルー・TTL）
• AWS「Caching Best Practices」（キャッシュアサイドの呼び名）
• AWS「Common ElastiCache Use Cases」（何をキャッシュするか）
• AWS「Comparing node-based Valkey, Memcached, and Redis OSS clusters」
• AWS「In-memory acceleration with DynamoDB Accelerator (DAX)」と「DAX: How it works」
• AWS「Amazon ElastiCache」（用途）
• AWS「Amazon ElastiCache pricing」（2026年10月29日に確認）