Amazon ElastiCacheの基本とエンジン選択
インメモリーデータベースが高速な理由、ElastiCacheで選べるValkey・Redis OSS・Memcachedの違い、MemoryDBとの役割分担、クラスターによる拡張を解説します。
インメモリーデータベースが速い理由
インメモリーデータベースは、データの主要な作業領域をメモリーに置き、メモリー上のデータ構造を使って要求を処理します。ストレージ装置からデータを読み込む回数を減らせるため、繰り返し参照される値を短い時間で返せます。Amazon ElastiCacheは、アプリケーションの近くにこのようなインメモリーのデータストアを配置するマネージドサービスです。
コンピューターの記憶階層は、CPUに近い小容量・低遅延の領域から、容量が大きくなる代わりにアクセス時間が長い領域へと続きます。CPU内部のレジスターやキャッシュにはSRAMが使われ、主記憶にはDRAMが使われます。その先には、電源断後も内容を保持する不揮発性メモリー（NVRAM）のような選択肢があり、さらにSSDやHDDなどのブロックストレージが続きます。製品や負荷によって値は変わりますが、DRAMへのアクセスはSSDやHDD上のデータを読むより大幅に低遅延です。
ディスクを主な永続化先とするリレーショナルデータベースも、通常はメモリーを使います。SQLを解析し、実行計画を作成し、バッファーマネージャーやストレージエンジンを介してページを読み書きします。頻繁に使うページはバッファーキャッシュに残るため、毎回ディスクアクセスが発生するわけではありません。ただし、データの正本は永続ストレージにあり、キャッシュミスや書き込み、トランザクション処理ではデータベースエンジンとストレージの仕組みが働きます。
インメモリーエンジンは、用途に合わせたデータ構造をメモリー上に展開し、キーを使った参照や更新を効率よく処理します。ネットワーク越しの要求を受け付ける処理やコマンドの実行は残りますが、値の取得で毎回ディスク上のデータページを読み込む必要がないことが高速化の大きな理由です。ディスク中心のデータベースとインメモリーエンジンの応答時間を単一の倍率で比べることはできません。データ量、キャッシュヒット率、ネットワーク、コマンド、ノード構成などで実際のレイテンシーは変わります。
エンジンによって内部実装は異なります。キー・バリューエンジンでは、イベントループで要求を処理し、ハッシュテーブルなどのデータ構造から値を得る構成が代表例です。一方、Memcachedは複数のスレッドで要求を並列に処理できます。どちらもメモリー上の値にすばやくアクセスしますが、単純なインメモリー処理だけでなく、同時要求の扱い方、データ構造、複製やバックアップ機能も性能と可用性を左右します。永続化や障害復旧にストレージを使う場合でも、通常のキャッシュ参照で必ず永続ストレージを読み込むという意味ではありません。
DRAMは高速ですが、電源を失うと通常は内容が消え、容量あたりのコストも永続ストレージと異なります。そのためキャッシュでは、元となるデータベースや他の永続データストアを別に持ち、キャッシュの消失や再起動後にもデータを再構築できるようにします。永続化やバックアップ機能を持つエンジンでも、その機能がアプリケーションの耐久性要件を満たすかを個別に設計します。
ElastiCacheをキャッシュとして使う
典型的な構成では、アプリケーションがElastiCacheを先に調べ、値がなければ正本となるデータベースから取得します。取得した値をキャッシュへ格納しておけば、次の同種の要求ではデータベースへのアクセスを省けます。
キャッシュに目的の値が存在する状態をキャッシュヒット、存在しない状態をキャッシュミスと呼びます。ミス時にはアプリケーションがデータベースへフォールバックし、得た値をキャッシュに登録してから応答する設計がよく使われます。たとえば、社内のデプロイ管理画面がプロジェクトの表示設定を何度も読み込む場合、その設定を短い有効期間でキャッシュし、設定変更時にはキャッシュを更新または無効化できます。
キャッシュは正本と同じ最新性を自動的に保証するものではありません。更新後の古い値をいつまで許容するか、TTL（有効期間）をどう決めるか、書き込み後にキャッシュを更新・削除するかをアプリケーション側で選びます。キャッシュの値が失われても正本から再構築できる設計にすることが、ElastiCacheをキャッシュ用途で使う基本です。また、ヒット率が低い場合や値の再生成コストが小さい場合には、キャッシュが複雑さや費用に見合わないこともあります。
ElastiCacheはインメモリーエンジンのキャッシュをAWSが管理するサービスです。アプリケーションはネットワーク経由でエンドポイントへ接続し、選択したエンジンが受け付けるプロトコルやコマンドを使います。ElastiCacheはサーバーレスキャッシュとノードベースのクラスターを提供します。サーバーレスではキャッシュ容量の監視やインフラのスケーリングをサービスに任せ、ノードベースではノードの種類・数やAZ配置などを選んで制御します。利用できるエンジンのバージョンやバックアップ機能などは方式によって異なります。サービスがマネージドであっても、データの鮮度、接続再試行、キー設計、アクセス制御などアプリケーションと運用側が担う設計は残ります。
Valkey、Redis OSS、Memcachedを比較する
ElastiCacheではValkey、Redis OSS、Memcachedのエンジンを選べます。ValkeyとRedis OSSは多様なデータ構造と機能を必要とする用途に向き、Memcachedは単純なキー・バリューのキャッシュを並列に処理する用途に向きます。選択時は「インメモリーだから速い」という共通点だけでなく、データ構造、複製、ノード障害時の動作、永続化・バックアップ、クライアント側の分散方法を比べます。
| 観点 | Valkey | Redis OSS | Memcached |
|---|---|---|---|
| データモデル | 文字列、ハッシュ、リスト、セット、ソート済みセットなどのデータ構造 | 多様なデータ構造に対応 | 基本はキーに対する値の保存 |
| 代表的な強み | オープンソースのRedis互換エンジン。ElastiCacheで利用できる | 成熟したコマンドやクライアントのエコシステム | シンプルなキャッシュ処理とマルチスレッドによる並列処理 |
| レプリケーション・可用性 | レプリカやフェイルオーバーなどの構成を選べる | レプリカやフェイルオーバーなどの構成を選べる | エンジン自体にデータ複製や自動フェイルオーバーを備えない |
| スケーリングの考え方 | クラスター設定によりレプリカ追加やシャーディングを利用 | クラスター設定によりレプリカ追加やシャーディングを利用 | 複数ノードへキーを振り分ける処理をクライアント側で行う |
| データ保護の考え方 | Valkey 9.0以降のノードベース・クラスターモード有効構成では、マルチAZトランザクションログを使う耐久性を選択可能 | バックアップと復元に対応するが、キャッシュ消失を前提に正本を設計する | エンジン内の永続化・複製はない。サービスのバックアップと復元はサーバーレスキャッシュで利用可能 |
ValkeyとRedis OSSの関係
ValkeyはRedis OSSの7.2.4から派生し、Linux Foundationの管理下で開発されるオープンソースのインメモリーエンジンです。基本的なデータ型や多くのコマンドが共通するため、Redis OSS向けに作られたアプリケーションやクライアントから移行できる場合があります。ただし、互換性はコマンド、モジュール、エンジンのバージョン、ElastiCacheの提供機能に依存します。すべての設定や拡張機能が無変更で動くと決めつけず、AWSの対応状況とアプリケーションを確認します。
名称とライセンスの変化も区別が必要です。Redis OSSはElastiCacheが提供するエンジンの名称であり、Redis上流のすべての現行バージョンと同一ではありません。上流Redisはバージョン7.4以降でライセンスを変更しました。ValkeyはRedis OSS 7.2.4を起点とする別のオープンソースプロジェクトです。Redis OSS 7.2で使える機能はValkey 7.2以降でも基本的に利用できますが、以後のバージョンでは機能追加や差分があります。AWSはElastiCacheとMemoryDBの両方でValkeyを提供しています。既存のRedis OSS環境を移行する場合は、移行先エンジンのバージョン、必要な機能、クライアント互換性、切り戻し方を事前に検討します。
Redis OSSとValkeyは、Memcachedより豊富なデータ構造やレプリケーション、クラスター機能を必要とする場合に候補になります。Valkey 9.0以降のノードベースのクラスターでは、クラスターモードを有効にしたうえで、マルチAZトランザクションログによる耐久性オプションを利用できます。同期書き込みは応答前に複数AZのログへ保持するため、データ損失ゼロを設計目標とする代わりに書き込みレイテンシーが1桁ミリ秒になります。非同期書き込みはマイクロ秒の書き込みレイテンシーを保ちますが、障害時に直近最大10秒分の未記録データを失うリスクがあります。この機能は全エンジン・全デプロイ方式に共通する機能ではありません。バージョン、クラスターモード、書き込みモードを確認し、スナップショットやバックアップ機能とも区別します。
Memcachedが適するケース
Memcachedはシンプルなキー・バリューキャッシュに特化したエンジンです。複雑なデータ構造やエンジン内レプリケーションを必要とせず、同じキーの値を多数の要求から高速に参照するような用途で使えます。マルチスレッドで要求を並列処理でき、クライアントライブラリーは複数ノードへキーを分散してキャッシュ容量と処理能力を広げます。
一方、MemcachedはRedis OSSやValkeyのようなデータ構造、レプリケーション、組み込みの自動フェイルオーバーを提供しません。ノードが失われると、そのノードに割り当てられたキャッシュ値は失われるものとして扱います。クライアントがどのノードを参照するかを管理し、キャッシュミス後に正本へ戻る経路を用意します。ElastiCacheのバックアップと復元はサーバーレスキャッシュではサポートされますが、ノードベースのMemcachedクラスターでは利用できません。高可用性や複製されたデータ構造が必要なら、Memcachedが単純な方が速いという理由だけで選ばず、ValkeyまたはRedis OSSとの機能差を考慮します。
MemoryDBとの違い
Amazon MemoryDBとAmazon ElastiCacheは、どちらもインメモリー技術を使いますが、主な役割が異なります。ElastiCacheは既存のデータベースなどを高速化するキャッシュ、MemoryDBは耐久性のあるインメモリーデータベースとしてアプリケーションのプライマリデータストアになれるサービスです。
| 比較点 | Amazon ElastiCache | Amazon MemoryDB |
|---|---|---|
| 主な役割 | 既存データベースを補うキャッシュが基本。ノードベースのValkeyではバージョンと設定により耐久性を持たせたデータストアにもできる | アプリケーションが直接データを読み書きする耐久性重視のデータベース |
| データ消失時の基本設計 | キャッシュ用途では正本から再構築できるようにする。Valkey耐久性の同期・非同期モードは、それぞれのデータ保護条件を確認する | マルチAZの耐久性機能でデータを保護する設計 |
| 主な選択理由 | 既存データベースの読み取り負荷や応答時間を改善する。Valkeyの耐久性を使う場合は書き込み性能とデータ損失リスクを選択する | インメモリーアクセスの低レイテンシーと耐久性を備えたプライマリDBを使う |
| レイテンシーの考え方 | インメモリー処理は通常マイクロ秒級を狙う。Valkeyの同期耐久性では書き込みが1桁ミリ秒になる | AWSは読み取りをマイクロ秒、書き込みを数ミリ秒のレイテンシーとして説明している |
| エンジンと設計 | Valkey、Redis OSS、Memcachedから選ぶ。耐久性機能は現行のValkeyの一部構成に限られる | ValkeyまたはRedis OSS互換のエンジンを使い、トランザクションログでデータを保護する |
| 設計上の確認事項 | TTL、キャッシュミス、無効化、レプリカ、バックアップ、耐久性の対応バージョンと書き込みモード | データベースとしての耐久性・整合性要件、クラスター構成、エンジン互換性 |
MemoryDBはValkeyとRedis OSSに互換性を持ち、マルチAZに分散したトランザクションログを使って耐久性を提供する、プライマリデータベース向けのサービスです。AWSの現行ElastiCacheガイドでは、Valkey 9.0以降のノードベース・クラスターモード有効クラスターにも耐久性機能が加わっています。したがって「耐久性が必要なら必ずMemoryDB、ElastiCacheは耐久性がない」と一般化するのは正確ではありません。ElastiCache Valkeyでは、同期書き込みは応答前に複数AZのログへ記録してデータ損失ゼロを目標とし、非同期書き込みは応答を速める代わりに直近のデータ損失リスクを許容します。MemoryDBは耐久性のあるプライマリDBとしてのサービス設計、ElastiCacheはキャッシュとノードベースValkeyの耐久性オプションという位置づけを比べ、対象構成と書き込みレイテンシー、許容RPOを基準に選びます。
たとえば、検索結果を短期間保持して基幹データベースの負荷を下げるならElastiCacheが自然です。一方、アプリケーションの主要な状態をインメモリーで扱い、データベース自体に耐久性を求めるならMemoryDBを評価します。ElastiCacheでValkey耐久性機能を選ぶ場合は、機能対応バージョン、クラスター条件、同期・非同期書き込みの違いを要件と照らし合わせます。バックアップやレプリカがあることと、トランザクションログによる耐久性が有効であることも混同しないようにします。
MemoryDBもクラスターで拡張する
MemoryDBのクラスターは1つ以上のノードで構成され、データセットをシャードへ分割します。各シャードには書き込みを処理するプライマリノードと、必要に応じて読み取りを処理するレプリカを配置できます。プライマリに障害が起きると、レプリカを新しいプライマリへ昇格させられます。シャードを増やすとデータを複数のノード群へ分散でき、ノードタイプを変更すればシャードあたりの計算資源やメモリー容量を調整できます。
クラスタリングは容量と要求を分散する方法ですが、無制限の容量やアクセスを保証するものではありません。シャード数やレプリカ数にはサービス上限があり、ノード配置に必要なVPCサブネットのIPアドレスも確保する必要があります。アプリケーションとクライアントがクラスター接続に対応していること、キーの分布が一部シャードへ集中しないことも確認します。
クラスタリングとデータの分散
クラスタリングは、複数のノードを連携させ、容量や処理要求を分散する構成です。単にサーバー台数を増やすことと同じではなく、データの配置、複製、障害時の切り替え、クライアントの接続先まで考慮します。ElastiCacheではエンジンによりクラスタリングの仕組みが異なります。
ValkeyとRedis OSSでは、クラスターをシャードに分けてキー空間を複数のノードグループへ分配する構成が可能です。各シャードにレプリカを置けば読み取りを分担し、プライマリ障害時の昇格候補にもできます。クラスターに必要なメモリーを超えるデータ量を扱う場合、シャード数を増やすことで複数ノードへデータを分散できます。ただし、単一キーのホットスポット、複数キーをまたぐ操作、クライアントのクラスター対応などを考慮する必要があります。クラスター構成やモードによって利用できる機能、オンラインで変更できる範囲も異なります。
Memcachedも複数ノードのクラスターを構成できますが、Valkey／Redis OSSのシャードやレプリカと同じものではありません。クライアントライブラリーがハッシュなどの方法でキーを各ノードへ割り当てます。エンジン内に複製されたシャードがあるわけではないため、ノード数を増やしたりノードが入れ替わったりすると、キーの配置やキャッシュミス率に影響します。クライアントのノード検出とキー配置が正しく機能することを確認します。
要件からエンジンを選ぶ
- データの主な役割が既存DBの読み取りを速めるキャッシュならElastiCacheを検討する。
- 複数のデータ型、コマンド、複製、フェイルオーバー、シャードを使いたい場合はValkeyまたはRedis OSSを比較する。
- 必要なのが単純なキー・バリュー値の並列キャッシュで、クライアント側の分散と値の再生成を設計できるならMemcachedが候補になる。
- インメモリーの速度に加え、サービス自体を耐久性のあるプライマリデータベースとして使いたいならMemoryDBを検討する。Valkey 9.0以降のElastiCache耐久性も候補になる場合は、同期・非同期書き込みのデータ保護条件とレイテンシーを比較する。
- 可用性や永続化を要件に含める場合、エンジン名だけで判断せず、バックアップ、レプリカ、マルチAZ、フェイルオーバー、復元手順の条件を確認する。
料金の考え方
料金はエンジンだけで決まるものではありません。選択したデプロイ方式、ノードまたはキャッシュの使用量、メモリー容量、レプリカやシャード、バックアップ、データ転送など、利用する構成要素に応じて発生します。サーバーレス型とノードベースでは課金単位や利用料金の構造も異なり、耐久性の設定も構成を左右します。実際の利用形態に合わせてAWS公式料金表で見積もります。料金や提供条件は更新されるので、固定額ではなく最新の料金ページを確認してください。
公式ドキュメント
重要ポイント
- ▸インメモリーデータベースは主にDRAM上のデータ構造を処理し、ディスク中心のデータベースより低いレイテンシーを実現する
- ▸ElastiCacheは既存データベースを補うキャッシュとして使うのが基本だが、ノードベースのValkey 9.0以降では設定により耐久性を有効化できる
- ▸ValkeyとRedis OSSは豊富なデータ構造、レプリケーション、クラスター機能を備え、Memcachedはシンプルなキー・バリューとマルチスレッド処理に向く
- ▸ValkeyはRedis OSS 7.2.4から派生したオープンソースエンジンだが、全コマンドや機能があらゆるバージョンで同一とは限らない
- ▸MemoryDBは耐久性のあるプライマリDBとして設計されている。Valkeyの耐久性機能を持つElastiCacheとの比較では、エンジン、書き込みモード、要件を確認する
- ▸Valkey／Redis OSSのクラスターは設定によりシャードへ分割でき、Memcachedはクライアント側で複数ノードへキーを分散する
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
AWSデータベースサービス に関連するトピックを続けて確認できます。