Amazon ElastiCache のキャッシュ設計 - Valkey / Redis OSS / Memcached の選定とキャッシュ戦略

Valkey・Redis OSS・Memcached の選定基準を整理し、Lazy Loading・Write-Through のキャッシュ戦略と Serverless モードの活用法を紹介します。

Valkey・Redis OSS・Memcached の選定基準

ElastiCache は Valkey・Redis OSS・Memcached の 3 つのエンジンを提供し、マイクロ秒単位のレイテンシで毎秒数百万リクエストを処理します。Valkey は Redis のフォークとして誕生したオープンソースの互換エンジンで、ElastiCache の既定エンジンとして提供されています。Valkey と Redis OSS はシングルスレッドのイベントループモデルで動作し、文字列、ハッシュ、リスト、セット、Sorted Set、Streams、HyperLogLog など豊富なデータ構造を提供します。AOF (Append Only File) と RDB スナップショットによるデータ永続化、リードレプリカ、自動フェイルオーバー、Pub/Sub メッセージングをサポートし、キャッシュだけでなくセッションストア、リーダーボード、リアルタイムランキング、メッセージブローカーとしても活用できます。Memcached はマルチスレッドアーキテクチャでシンプルなキー・バリューキャッシュに特化し、ノード追加による水平スケーリングが容易です。データ永続化やレプリケーションが不要で、純粋にデータベースクエリの結果をキャッシュしたい場合に適しています。エンジン選定では、Valkey が Redis OSS と同じコマンドセットとクライアントライブラリを使いながら、ノードの時間単価・Serverless の ECPU 単価・Serverless の最小課金ストレージのいずれも Redis OSS より低く設定されている点が効きます。そのため新規構築は Valkey を出発点にし、Redis OSS は既存クラスタの延命や特定バージョンへの依存がある場合に、Memcached はレプリケーションも永続化も要らない単純なキャッシュ層に、という切り分けが実務的です。

表: 3 エンジンは「何を任せられるか」と価格水準が違う
観点Valkey (既定エンジン)Redis OSSMemcached
実行モデルシングルスレッドのイベントループシングルスレッドのイベントループマルチスレッド
データ構造文字列・ハッシュ・リスト・セット・Sorted Set・Streams・HyperLogLogValkey と同じ (Valkey が Redis OSS 互換)単純なキー・バリューのみ
永続化とレプリケーションAOF と RDB スナップショット、リードレプリカ、自動フェイルオーバーAOF と RDB スナップショット、リードレプリカ、自動フェイルオーバーいずれも持たない
スケールの仕方シャーディングとリードレプリカシャーディングとリードレプリカノード追加による水平スケーリングが容易
キャッシュ以外の使い道セッションストア、リーダーボード、リアルタイムランキング、Pub/Sub のメッセージブローカーセッションストア、リーダーボード、リアルタイムランキング、Pub/Sub のメッセージブローカー基本的にキャッシュ専用
Serverless 対応対応。最小課金ストレージは 1 キャッシュあたり 100 MB対応。最小課金ストレージは 1 キャッシュあたり 1 GB対応。最小課金ストレージは 1 キャッシュあたり 1 GB
コスト水準3 エンジンで最も安い (ノードの時間単価・ECPU 単価・Serverless ストレージ単価のすべて)Valkey より高いノードの時間単価は Redis OSS と同水準
向いている場面新規構築の既定。Redis OSS 互換のまま最も安く始められる既存の Redis OSS 資産をそのまま使い続けたい場合データベースのクエリ結果を純粋にキャッシュしたいだけの場合

キャッシュ戦略の設計

Lazy Loading (Cache-Aside) はキャッシュミス時にデータベースから取得してキャッシュに書き込む戦略です。キャッシュには実際にリクエストされたデータのみが格納されるため、メモリ効率が高い反面、初回アクセス時にキャッシュミスが発生します。Write-Through はデータベースへの書き込みと同時にキャッシュも更新する戦略です。キャッシュのデータが常に最新に保たれますが、書き込みのレイテンシが増加し、読まれないデータもキャッシュに格納されます。実践的には両者を組み合わせ、Write-Through で書き込み時にキャッシュを更新しつつ、TTL を設定して古いデータを自動的に失効させるアプローチが有効です。TTL の設定値はデータの鮮度要件に応じて決定し、リアルタイム性が求められるデータは短く (数秒から数分)、マスターデータは長く (数時間から数日) 設定します。キャッシュヒット率を CloudWatch メトリクスで継続的に監視し、TTL やノードサイズの適正化を定期的に見直すことが運用の鍵です。

表: Lazy Loading (Cache-Aside) と Write-Through の得手不得手
観点Lazy Loading (Cache-Aside)Write-Through
キャッシュを書くきっかけキャッシュミス。データベースから取得したついでに書き込むデータベースへの書き込み。同じタイミングでキャッシュも更新する
キャッシュに載るデータ実際にリクエストされたものだけ書き込まれたものすべて。読まれないデータも載る
メモリ効率高い低くなりやすい
データの鮮度キャッシュが古くなり得る常に最新に保たれる
弱点初回アクセスでキャッシュミスが起きる書き込みのレイテンシが増える
実践的な着地点両者を組み合わせ、Write-Through で書き込み時に更新しつつ TTL で古いデータを自動失効させる。TTL はリアルタイム性が要るデータは数秒〜数分、マスターデータは数時間〜数日

クラスタモードとシャーディング

Valkey または Redis OSS でクラスタモードを有効にすると、データを 16384 個のハッシュスロットに分散し、複数シャードで水平スケールできます。各シャードにプライマリと最大 5 つのリードレプリカを配置し、読み取り負荷を分散します。クラスタの既定上限はシャード数ではなくノード数で決まり、プライマリとレプリカの合計でクラスタあたり 90 ノードまでです (レプリカを置かない構成なら最大 90 シャード)。Valkey 7.2 以降 (Redis OSS は 5.0.6 以降) では上限緩和の申請でクラスタあたり最大 500 ノードまで拡張できます (公式ドキュメント記載値・2026 年 8 月時点)。クライアントはハッシュスロットのマッピングに従ってリクエストを正しいシャードに送信し、スロットが移動した場合は MOVED リダイレクトで自動接続します。ノードタイプの選択ではメモリ最適化の r 系インスタンス (cache.r7g 系) がキャッシュワークロードに適しており、データ量とスループット要件に応じてシャード数とレプリカ数を調整します。マルチ AZ 配置と自動フェイルオーバーを有効にすると、プライマリ障害時はレプリケーション遅延が最も小さいレプリカが自動昇格し、公式ドキュメントでは書き込みを再開できるまで通常は数秒とされています。ただしレプリケーションは非同期のため、昇格したレプリカがわずかに遅れている場合はその分の書き込みが失われる可能性があります。失ってはいけないデータは DynamoDBRDS などの永続ストアにも書くのが前提です。

Valkey への移行と Global Datastore

Valkey は既存の Redis クライアントライブラリやコマンドセットをそのまま使用でき、ライセンス上の懸念なく Redis 互換環境を利用できます。稼働中の Redis OSS クラスタからはエンジンのアップグレード操作で Valkey へ移行でき、購入済みリザーブドノードの割引も引き継げます。Global Datastore を使用するとリージョン間でデータを非同期レプリケーションし、災害復旧 (DR) とグローバルな読み取りレイテンシの改善を実現します。プライマリリージョンの障害時はセカンダリリージョンを昇格でき、AWS 公式 FAQ の記載値 (2026 年 8 月時点) では RPO が通常 1 秒未満、RTO も通常 1 分未満 (フェイルオーバー開始後、セカンダリが読み書き両方を担えるようになるまで通常 1 分以内) です。リージョン間のレプリケーションで送出したデータには転送量課金がかかるため、書き込み量の多いクラスタでは料金の見積もりに含めておきます。

ElastiCache Serverless と運用

ElastiCache Serverless は 2023 年に登場したモードで、ノードタイプやクラスタサイズの事前設計が不要です。Valkey・Redis OSS・Memcached の 3 エンジンすべてに対応しており、エンジンを選ぶだけでキャッシュを作成できます。ワークロードに応じてキャパシティが自動スケールし、最小構成から始めてトラフィック増加に自動対応します。料金はデータストレージ量 (GB 時間) と ElastiCache Processing Units (ECPU) の使用量に基づく従量課金です。ECPU は読み書きで転送したデータ 1 KB あたり 1 ECPU が基準で、Valkey と Redis OSS では vCPU 時間を多く使うコマンドは転送量と vCPU 時間の大きい側で計算されます。なおキャッシュ 1 つあたりの最小課金ストレージが定められており、Valkey は 100 MB、Redis OSS と Memcached は 1 GB です (公式料金ページ記載値・2026 年 8 月時点)。データストレージとリクエストレートには上限と下限を設定でき、上限で想定外のコストを抑え、下限でベースラインの性能を確保できます。トラフィックパターンが予測困難な新規アプリケーションや、開発・テスト環境に特に適しています。一方、トラフィックパターンが安定している本番環境では、リザーブドノードを使用したプロビジョンド構成の方がコスト効率が高い場合があります。

ElastiCache の料金

(2026 年 8 月時点・バージニア北部 us-east-1 と東京 ap-northeast-1) ElastiCache の課金対象は、ノードベースクラスタのノード時間課金、Serverless のデータストレージと ECPU、バックアップ (スナップショット) のストレージ、Global Datastore のリージョン間データ転送、の 4 軸です。 ノード時間課金は、Valkey の cache.r7g.large がバージニア北部で 0.1752 USD/時、東京で 0.2104 USD/時です。同じノードタイプでも Redis OSS と Memcached はバージニア北部で 0.219 USD/時のため、Valkey は 2 割ほど安く設定されています。Serverless はデータストレージが GB 時間 (GB-Hours) 単位で、Valkey がバージニア北部 0.084 USD/GB 時間・東京 0.101 USD/GB 時間、Redis OSS と Memcached はバージニア北部 0.125 USD/GB 時間です。ECPU は 100 万 ECPU あたりの単価で、Valkey がバージニア北部 0.0023 USD・東京 0.0027 USD、Redis OSS と Memcached はバージニア北部 0.0034 USD です。バックアップは無料割当を超えた保存量に対して 0.085 USD/GB 月 (GB-months) が両リージョン共通でかかります。Global Datastore のリージョン間レプリケーションで送出したデータは、バージニア北部発が 0.02 USD/GB、東京発が 0.09 USD/GB です。 最小課金と例外は 3 点あります。Serverless にはキャッシュ 1 つあたりの最小課金ストレージ (Valkey 100 MB / Redis OSS と Memcached 1 GB) があり、アイドル状態でもこの分は課金されます。Valkey の耐久性オプション (同期書き込み) を有効にしたノードには、ノード料金とは別の課金項目が立ち、cache.r7g.large ではバージニア北部 0.0315 USD/時・東京 0.0379 USD/時です。標準サポートが終了したエンジンバージョンを使い続ける場合は延長サポートの課金項目が加わり、バージニア北部の cache.r7g.large では 1〜2 年目が 0.175 USD/時、3 年目が 0.35 USD/時です。無料利用枠は登録時期で内容が分かれ、2025 年 7 月 15 日より前に AWS 無料利用枠に登録した場合は cache.t3.micro のノード使用量 750 時間/月が最大 12 ヶ月無料 (Serverless は対象外)、それ以降の登録では Free Plan / Paid Plan の選択制でクレジットによる利用になります。 トラフィックが断続的なワークロードでは Serverless が低コストで、常時高スループットのワークロードではプロビジョンドノードの方が有利です。プロビジョンド構成ではリザーブドノードで大きく下げられ、Valkey cache.r7g.large の 3 年全額前払いはバージニア北部 2,071.92 USD・東京 2,488.19 USD です。3 年 (26,280 時間) で割ると 1 時間あたりはオンデマンドの約 45%、つまり実質 55% ほどの割引になります。

まとめ

ElastiCache はデータベースの負荷軽減とアプリケーションの応答速度改善に直結するキャッシュサービスです。新規構築では既定エンジンの Valkey を出発点とし、Lazy Loading と Write-Through の組み合わせでキャッシュ戦略を設計します。クラスタモードのシャーディングとリードレプリカでスケーラビリティを確保し、Global Datastore でグローバル展開と災害復旧にも対応できます。Serverless モードで手軽に始め、ワークロードが安定したらリザーブドノードを使ったプロビジョンド構成への移行を検討するアプローチが有効です。

参考資料 (AWS 公式)

本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。

本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。