Amazon MemoryDB for Redis
Redis 互換のインメモリデータベースで、マルチ AZ のトランザクションログによりデータの耐久性を保証しつつマイクロ秒の読み取りレイテンシを実現する
概要
Amazon MemoryDB for Redis は、Redis 互換の API を提供するフルマネージドインメモリデータベースサービスです。ElastiCache for Redis と異なり、マルチ AZ のトランザクションログにデータを永続化するため、ノード障害やフェイルオーバー時にもデータが失われません。読み取りはマイクロ秒、書き込みは一桁ミリ秒のレイテンシで、1 日あたり数兆リクエストの処理に対応します。Redis のデータ構造 (String、Hash、List、Set、Sorted Set、Stream) をすべてサポートし、既存の Redis クライアントライブラリをそのまま使用できます。
ElastiCache for Redis との決定的な違い
MemoryDB と ElastiCache for Redis は同じ Redis 互換 API を提供しますが、データの耐久性モデルが根本的に異なります。ElastiCache はキャッシュとして設計されており、データの永続性は保証されません。レプリケーションは非同期で、プライマリノードの障害時にレプリカへのフェイルオーバーが発生すると、最後のレプリケーション以降の書き込みが失われる可能性があります。スナップショットによるバックアップは可能ですが、スナップショット間のデータは復元できません。MemoryDB はデータベースとして設計されており、すべての書き込みがマルチ AZ のトランザクションログに同期的に永続化されます。プライマリノードが障害を起こしても、トランザクションログからデータが完全に復元されるため、データ損失はゼロです。この違いは、MemoryDB をプライマリデータベースとして使えることを意味します。従来の「RDS + ElastiCache」の 2 層構成を「MemoryDB のみ」の 1 層に統合できるケースがあり、アーキテクチャの簡素化とレイテンシの改善を同時に実現できます。ただし、書き込みレイテンシは ElastiCache の方が低い (MemoryDB はトランザクションログへの同期書き込みがある分、数ミリ秒遅い) ため、書き込み性能が最優先のキャッシュ用途では ElastiCache が依然として適しています。
プライマリデータベースとしての活用パターン
MemoryDB をプライマリデータベースとして使う典型的なパターンは、セッションストア、リーダーボード、リアルタイムの在庫管理、ショッピングカートです。これらのワークロードは、高速な読み書きが必要で、データ構造が Redis のデータ型にフィットし、かつデータの永続性が求められます。セッションストアでは、従来 DynamoDB や RDS に格納していたセッションデータを MemoryDB に移行することで、読み取りレイテンシをミリ秒からマイクロ秒に短縮できます。リーダーボードでは Sorted Set を使い、スコアの更新と上位 N 件の取得を O(log N) で実行できます。ゲームのランキングや EC サイトの売上ランキングで、数百万ユーザーのリアルタイム順位付けが可能です。一方、MemoryDB が適さないケースもあります。複雑なクエリ (JOIN、集約、サブクエリ) が必要なワークロードは RDB が適切です。また、データ量がメモリに収まらない場合はコストが急激に増加するため、ホットデータのみを MemoryDB に格納し、コールドデータは DynamoDB や S3 に退避する設計が現実的です。
クラスター設計とコスト最適化
MemoryDB のクラスターはシャードとレプリカで構成されます。シャード数はデータ量と書き込みスループットに基づいて決定し、各シャード内のレプリカ数は読み取りスループットと可用性要件で決定します。本番環境では最低 2 シャード、各シャード 1 レプリカ (合計 4 ノード) が推奨されます。ノードタイプは db.r7g (Graviton3) が最新で、db.r6g に対して最大 20% のパフォーマンス向上を実現しています。メモリサイズの選定では、Redis のメモリオーバーヘッド (データサイズの約 1.5-2 倍) を考慮する必要があります。たとえば 10 GB のデータを格納する場合、15-20 GB のメモリを持つノードタイプを選択します。コスト最適化のポイントとして、リザーブドノードの活用が効果的です。1 年予約で約 30%、3 年予約で約 50% のコスト削減が可能です。データ圧縮は MemoryDB ではサポートされていないため、アプリケーション側で圧縮してから格納するか、データモデルを工夫してメモリ使用量を削減します。Hash データ型は小さなフィールド数 (ziplist エンコーディングが適用される範囲) であれば、個別の String キーよりもメモリ効率が高くなります。