Amazon MemoryDB

Amazon MemoryDB は、Redis（および互換エンジン）のデータ構造とコマンドをそのまま利用しながら、インメモリの高速性とディスク永続化レベルの耐久性を両立させたフルマネージドのデータベースサービスです。一般的なインメモリキャッシュとは異なり、プライマリデータベースとして単独で使えるよう設計されている点が最大の特徴です。

解決する課題

従来、低レイテンシが必要なアプリケーションでは「永続データベース（リレーショナルや NoSQL）」の前段に「インメモリキャッシュ（Redis や Memcached）」を置く二層構成が定番でした。この構成にはいくつかの課題があります。

• キャッシュとデータベースの間でデータの整合性を保つロジックを自前で実装する必要がある。
• キャッシュはあくまで揮発性であり、ノード障害や再起動でデータが失われ得るため、真実の源（source of truth）にはできない。
• 二つのデータストアを運用・監視・スケールする手間とコストがかかる。

MemoryDB はインメモリの速度を保ちながらデータを永続化するため、キャッシュ層と永続層を一つに統合できます。これにより、整合性管理のロジックを単純化し、運用対象を減らしつつ、読み取りはマイクロ秒、書き込みはミリ秒オーダーの応答性を実現できます。

主要概念と用語

• クラスター: MemoryDB の最上位リソース。1 つ以上のシャードで構成され、Redis 互換のエンドポイントを提供する。
• シャード: データを分割保持する単位。各シャードは 1 つのプライマリノードと、任意の数のレプリカノードを持つ。
• プライマリノード: 書き込みを受け付けるノード。シャードごとに 1 つ存在する。
• レプリカノード: プライマリの内容を複製し、読み取りをスケールさせるノード。プライマリ障害時には昇格してフェイルオーバー先となる。
• トランザクションログ: 書き込みを複数のアベイラビリティーゾーンへ分散して記録する仕組み。これが MemoryDB の耐久性と一貫性の中核を担う。
• スナップショット: クラスターのデータをある時点で取得したバックアップ。復元や別クラスターへの移行に利用する。
• パラメータグループ: エンジンの動作設定をまとめた構成。クラスター作成時や変更時に適用する。
• サブネットグループ: クラスターを配置する VPC 内のサブネットの集合。複数 AZ に跨らせることで高可用性を高める。

仕様・制限・クォータ

• データはメモリ上に保持されるため、データセットサイズはノードのメモリ容量とシャード数の積に概ね制約される。大規模データはシャードを増やして水平分割する。
• 1 クラスターあたりのシャード数やシャードあたりのレプリカ数には上限があり、これらはサービスのクォータとして定められている。具体的な値はリージョンやアカウント設定で異なり、緩和申請が可能な項目もある。
• 書き込みはトランザクションログへ確定してから応答するため、純粋な揮発キャッシュよりは書き込みレイテンシが大きい（それでもミリ秒オーダー）。読み取りはメモリから返るためマイクロ秒オーダーになる。
• Redis 互換のコマンドやデータ型をサポートするが、エンジンのバージョンによって利用可能な機能やコマンドが異なるため、採用前に対象バージョンの対応状況を確認する。

具体的なノードタイプ別のメモリ量、シャード上限、サポートコマンドの一覧などは変動するため、最新の公式ドキュメントで確認してください。

内部の仕組み

MemoryDB の耐久性は、各シャードのプライマリノードが受け付けた書き込みを、メモリへ反映する前後で複数 AZ にまたがる分散トランザクションログへ確定させることで担保されます。書き込みクライアントへの成功応答は、このログへの確定後に返されます。これにより、プライマリノードが突然失われても、確定済みの書き込みは失われません。

レプリカノードはプライマリからデータを複製し、読み取りトラフィックを分散します。プライマリに障害が発生すると、最新のレプリカが自動的にプライマリへ昇格してフェイルオーバーが行われます。トランザクションログがあるため、昇格後も整合性のあるデータが維持されます。

データはシャードによって水平分割され、各キーは特定のシャードに割り当てられます。シャードを追加・削除することでクラスター全体のスループットとメモリ容量をスケールさせられます。

設計パターン / ベストプラクティス

• プライマリデータベースとしての利用: セッションストア、リーダーボード、メッセージング、地理空間データなど、Redis のデータ構造が活きるワークロードで、永続性を捨てずに高速性を得たい場合に適する。
• 高可用性構成: 各シャードに少なくとも 1 つ、できれば複数のレプリカを別 AZ に配置し、自動フェイルオーバーを有効にする。
• スケール戦略: 読み取り負荷はレプリカ追加で、書き込み負荷とデータ量はシャード追加（再シャーディング）で対応する。
• 適切なシャードキー設計: ホットキーが特定シャードに偏らないよう、キー設計とデータ分布を意識する。

運用・監視

• メトリクスは Amazon CloudWatch に連携され、CPU 使用率、メモリ使用量、接続数、レイテンシ、置き換え（evictions）などを監視できる。
• メモリ使用量が上限に近づくと、設定によってはキーの追い出しが発生したり書き込みが失敗したりするため、使用率にしきい値アラームを設定する。
• スナップショットを定期取得し、復元手順を事前に検証しておくことで、論理的なデータ破損や誤操作からの回復に備える。
• エンジンのマイナーバージョン更新やパッチはメンテナンスウィンドウで適用される。メンテナンスウィンドウは業務影響の少ない時間帯に設定する。

コスト

MemoryDB のコストは主に次の要素から構成されます。

• ノードの稼働時間: 選択したノードタイプとノード数（プライマリ＋レプリカ）に応じた時間課金。
• データ書き込み量: トランザクションログへ書き込まれたデータ量に応じた課金が発生する点が、純粋なキャッシュとの違い。
• スナップショットのストレージ: バックアップとして保持するデータ量に応じた課金。
• データ転送: リージョンをまたぐ転送などに対する課金。

レプリカを増やすほど可用性と読み取り性能は上がりますが、その分ノード課金も増えます。可用性要件とコストのバランスを取って構成を決めてください。料金は変動するため、見積もりは公式の料金ページと料金計算ツールで確認してください。

セキュリティ

• ネットワーク分離: クラスターは VPC 内に配置し、サブネットグループとセキュリティグループでアクセス範囲を制御する。
• 保管時の暗号化: データは保管時に暗号化でき、AWS Key Management Service の鍵を利用した管理が可能。
• 転送時の暗号化: クライアントとクラスター間の通信は TLS で保護できる。
• 認証とアクセス制御: アクセスコントロールリストにより、ユーザーごとに接続可能なキーや実行可能なコマンドを制限できる。あわせて IAM でリソース管理操作の権限を制御する。

Well-Architected の観点

• パフォーマンス効率: メモリからの読み取りによりマイクロ秒級の応答を実現し、シャードとレプリカの追加でスループットを線形に近い形で拡張できる。データ構造に最適化された Redis 互換コマンドで処理を効率化できる。
• 信頼性: 複数 AZ に分散したトランザクションログと自動フェイルオーバーにより、ノード障害時もデータと可用性を維持する。永続性があるためプライマリデータストアとして単体で機能できる。

試験で問われるポイント

関連サービス・比較

最もよく比較されるのは、同じく Redis 互換のキャッシュサービスである ElastiCache です。両者はインターフェースが近い一方で、永続性とユースケースの位置づけが異なります。

永続性が必須でデータストアを一本化したいなら MemoryDB、既存の永続 DB の前段で純粋に高速化したいなら ElastiCache、という整理が基本になります。

ハンズオン / CLI例

以下は、サブネットグループとアクセス制御を指定して MemoryDB クラスターを作成し、状態を確認する例です。実際のノードタイプ名やパラメータグループ名、ACL 名は環境に合わせて置き換えてください。

# クラスターを作成する（ノードタイプ・シャード数・レプリカ数は要件に合わせる）
aws memorydb create-cluster \
  --cluster-name my-memorydb-cluster \
  --node-type db.r6g.large \
  --num-shards 2 \
  --num-replicas-per-shard 1 \
  --acl-name my-acl \
  --subnet-group-name my-subnet-group \
  --tls-enabled

# 作成したクラスターの状態とエンドポイントを確認する
aws memorydb describe-clusters \
  --cluster-name my-memorydb-cluster