Amazon MemoryDBの耐久性、クラスター構成、料金

Amazon MemoryDBは、ValkeyとRedis OSSに互換性のあるフルマネージドのインメモリデータベースです。メモリ上でデータを処理して低レイテンシーと高スループットを実現しながら、データを複数のアベイラビリティーゾーン（AZ）にまたがるトランザクションログへ記録します。キャッシュを別の永続データベースと組み合わせる構成に限らず、耐久性と高速な応答の両方が必要なアプリケーションのプライマリデータベースとして利用できます。

たとえば、自転車シェアサービスが車両の現在地や貸し出し状態を保持する場合、アプリケーションはValkeyまたはRedis OSS互換のデータ構造やコマンドを使って高速に読み書きできます。MemoryDBでは、このインメモリの処理経路と、障害時にデータを復旧するための永続化経路をあわせて設計します。

インメモリ性能と耐久性

MemoryDBは、アプリケーションから受けたコマンドをメモリ上のデータに適用します。成功した書き込みは、クライアントへ成功を返す前に分散されたMulti-AZトランザクションログへ保存されます。プライマリノードの再起動や障害からの復旧では、このログを使って状態を再構成できます。データの永続性をノード内のローカルファイルだけに依存させないことが重要です。

この設計により、MemoryDBは高速なインメモリ処理と、マルチAZにまたがる耐久性を組み合わせます。ログが書き込みの耐久性を支え、レプリカは読み取り容量と同一クラスター内の可用性を補います。読み取りレプリカへの非同期複製そのものが永続化の唯一の仕組みではありません。

Redis OSSのAOF（Append Only File）は、Redisエンジンで使われる永続化方式です。MemoryDBの耐久性を考えるときは、AOFのローカルファイルと、MemoryDBが管理するMulti-AZトランザクションログを混同しないようにします。MemoryDBでは、サービスが提供するトランザクションログとスナップショットを使って耐久性や復旧要件を設計します。

プライマリとレプリカの整合性

シャードのプライマリは読み取りと書き込みを処理します。成功した書き込みの後にプライマリから読み取ると、それ以前に成功した書き込みを反映した最新の状態が返ります。これは強整合性であり、プライマリのフェイルオーバー後も維持されます。

レプリカは読み取り専用で、プライマリのトランザクションログを使って非同期に更新されます。そのため、ある書き込みが成功した直後にレプリカを読むと、その書き込みがまだ反映されていないことがあります。レプリカの読み取りは結果整合性です。ただし、同じレプリカから順に読む操作は逐次整合性を持ち、プライマリで実行された書き込みの順序は保たれます。レプリカへの複製遅延はCloudWatchメトリクスで監視できます。

読み取り先	主な用途	整合性
プライマリ	最新の書き込み結果を直ちに確認する読み取り、書き込み	強整合性
レプリカ	最新値である必要がない読み取りの分散	結果整合性。単一レプリカ内では逐次整合性

注文確定など直前の書き込みを必ず読み直す処理はプライマリへ送ります。車両一覧の表示のように短い複製遅延を許容できる読み取りは、レプリカへ分散させる設計を検討できます。すべての読み取りをレプリカへ送れば読み取り負荷を下げられますが、読み取り直後の値が古い可能性をアプリケーションが扱えることが前提です。

クラスター、シャード、ノード

MemoryDBの配置は、クラスター、シャード、ノードの階層で考えます。

• クラスターは1つのデータセットを提供するデプロイの単位です。クラスター内のデータはシャードに分割されます。
• シャードはキー空間の一部を持つデータ分割単位です。各シャードには1つのプライマリがあり、必要に応じて最大5つのレプリカを配置します。
• ノードは最小の計算・メモリ単位です。Amazon EC2インスタンス上で選択したエンジンバージョンが動作し、ノードタイプによってメモリと計算容量が決まります。クラスター内のノードタイプは同一です。

自転車の識別子をキーにしてデータを分散する構成なら、複数のシャードが異なる自転車データを持ちます。各シャードではプライマリが書き込みを受け付け、レプリカが複製データの読み取りを分担します。シャードを増やすとデータを分割して書き込み処理を広げられます。レプリカを増やすと、そのシャードの読み取り先とフェイルオーバー候補が増えます。

MemoryDBは最大500ノード、最大500シャードをサポートします。シャード数の上限とノード総数の上限は別の制約です。最大500ノードを使う例では、各シャードがプライマリ1台だけなら500シャードを構成できます。各シャードにプライマリ1台とレプリカ5台を置く場合は6台ずつ必要になるため、500台の範囲に収まるのは83シャード（合計498ノード）です。実際に利用できる上限はサービスクォータやサブネットのIPアドレス数などにも左右されます。

AWSは1レプリカ/シャード構成で100 TBを超えるストレージを持つクラスターをサポートしています。実際に保持できる容量はノードタイプ、シャード数、レプリカ数などの構成で決まります。固定の「500 TB」をクラスター容量上限として覚えるのではなく、必要なデータ量に応じて対応ノードタイプとクォータを確認してください。

複数シャードにキー空間を分割し、クラスター対応クライアントで接続する考え方は、ElastiCache for Redis OSSのクラスターモード有効構成と共通しています。一方、MemoryDBではMulti-AZトランザクションログによる耐久性を備えたデータベースとして設計します。両サービスは似たデータ構造やコマンドを使えても、耐久性、利用機能、料金の考え方まで同じではありません。

クラスターエンドポイントとアプリケーション接続

アプリケーションは、クラスターのクラスターエンドポイントを接続先として使用します。ノードの追加、置き換え、フェイルオーバーにともなって個別ノードのアドレスが変化しても、クラスターエンドポイントを利用することで接続先を固定したままにできます。

ただし、エンドポイントがすべてのコマンドを代理実行するわけではありません。アプリケーションはValkeyまたはRedis OSSのクラスター接続に対応するクライアントを用意し、クラスターの構成に追従できる必要があります。接続プール、タイムアウト、再試行、フェイルオーバー後の再接続が適切かを確認します。

スケーリングの選び方

変更方法	変わる資源	主な目的
ノードタイプを変更	各ノードのメモリ・計算容量	個々のノードの処理能力やデータ保持量を増減する（垂直スケーリング）
シャードを追加・削除	データ分割数とプライマリ数	データを水平分割し、合計の書き込み処理能力や容量を調整する
レプリカを追加・削除	読み取り先と複製先	読み取りスループットやシャード内の障害耐性を調整する

ノードタイプの変更は垂直スケーリングです。アプリケーションのデータや書き込み負荷が1シャードの能力を超える場合は、シャードを増やす水平スケーリングを検討します。MemoryDBはシャードの追加・削除によってデータをオンラインで再配置できますが、処理中の負荷やキー分布によって完了時間は異なります。アプリケーションの接続クライアントが構成変更に追随することも確認します。

レプリカの追加は読み取りを分散し、プライマリ障害時に昇格できるノードを用意しますが、シャード内の書き込みを分割するものではありません。書き込み能力を広げる目的なら、レプリカ追加ではなくシャード追加が候補です。読み取りが多いサービスではレプリカを使い、データ量や書き込み能力を広げたいサービスではシャード数を調整する、というように目的を分けて選びます。

MemoryDBクラスターはリージョン単位で作成され、1クラスターのノードは1つのリージョン内に配置されます。利用可能なリージョンやノードタイプは変わるため、デプロイ先で選べるエンジンバージョンやノードファミリーも事前に確認します。Multi-AZ構成では、プライマリとレプリカを複数のAZに置き、ノード障害時にレプリカへ自動フェイルオーバーできるようにします。リージョン障害への復旧が必要な場合は、スナップショットを別リージョンへコピーするなど、リージョン単位の復旧手順も別途設計します。

自動バックアップとスナップショット

MemoryDBのトランザクションログは、稼働中のデータ耐久性と障害からの復旧を支えます。スナップショットは、ある時点のクラスター全体を再作成したり、新しいクラスターへデータを投入したりするためのコピーです。両者は用途が異なるため、レプリカやトランザクションログだけを長期保管・誤操作復旧の代わりにしないようにします。

自動スナップショットは日次で作成し、Amazon S3に保存できます。保持期間は最大35日です。保持期間を0日にすると自動スナップショットは無効になりますが、トランザクションログによるMemoryDBのデータ耐久性は維持されます。スナップショットの保存期間は、復旧時点の要件や誤操作への備えに合わせて設定します。

スナップショットはノード単位やシャード単位ではなく、クラスター全体を対象に作成します。手動スナップショットは連続する24時間あたり1クラスターにつき最大20個です。スナップショット作成中は、そのクラスターに対してほかのAPIまたはCLI操作を実行できない制約があります。削除前に最終スナップショットを作成する場合、最新データを含めるためにプライマリノードから取得されます。

セキュリティとアクセス制御

MemoryDBのアクセス制御は、管理操作とデータ操作を分けて考えます。

• IAMは、クラスターの作成・変更などMemoryDBの管理APIを実行できるAWSアイデンティティを制御します。タグベースのアクセス制御も管理APIで利用できます。
• ACLとユーザーは、クラスターへ接続するアプリケーションや利用者が実行できるValkeyまたはRedis OSSコマンドを制御します。クラスターにはACLを関連付けます。
• VPCとセキュリティグループは、クラスターのエンドポイントとポートにネットワーク接続できる送信元を絞ります。MemoryDBクラスターはVPC内に作成します。
• 暗号化は、転送中のTLS暗号化と、保管時のAWS KMSキーによる暗号化を利用できます。

IAM認証だけでアプリケーションのRedisコマンドやデータへのアクセスを制御するわけではありません。AWS管理APIの権限にはIAM、クラスター内のユーザー権限にはACL、ネットワーク到達性にはVPCとセキュリティグループを使い分けます。

料金の考え方

MemoryDBの費用はノードの稼働時間だけでは決まりません。主な費用項目を分け、実際のエンジン、リージョン、ノードタイプ、構成に対応する料金表で見積もります。

費用項目	見積もりで確認すること
ノード	プライマリとレプリカの合計台数、ノードタイプ、稼働時間。シャードやレプリカを増やすとノード費用も増える
書き込みデータ量	クラスターへ書き込むデータ量。キー、値、コマンドも計算対象になり、読み取りデータ量にはこの書き込み料金が発生しない
スナップショットストレージ	自動・手動スナップショットの容量と保持期間。無料枠や追加のGB-month課金条件は料金表で確認する
予約ノード	1年または3年の契約期間、リージョン、ノードファミリー、前払い方法。対象ノードの利用がなくても契約期間中は料金が発生する

予約ノードは実体のあるノードではなく、対象となるオンデマンドノードの料金に適用する割引です。長期利用が見込める場合に検討しますが、クラスターのノードを自動で確保したり構成変更したりする仕組みではありません。予約ノードの契約条件や対象範囲は購入時の公式料金ページで確認します。

自動スナップショットの保持日数、追加ストレージ、データ書き込み量の単価は料金に影響します。料金体系や無料枠は変更されるため、固定額を暗記せず、AWSの料金ページとAWS Pricing Calculatorでリージョンと想定構成を指定して比較してください。

試験で押さえるポイント

• MemoryDBは単なるキャッシュではなく、Multi-AZトランザクションログで耐久性を備えるインメモリデータベースです。プライマリの成功した書き込みは、成功応答の前にログへ保存されます。
• プライマリは強整合性、読み取りレプリカは結果整合性です。直前の書き込み結果が必要な読み取りはプライマリへ送ります。
• クラスターはシャードにデータを分け、各シャードは1つのプライマリと最大5つの読み取りレプリカを持てます。最大500シャードという仕様と最大500ノードの制約を混同しません。
• 書き込み能力やデータ容量を水平に増やすときはシャードを追加します。レプリカ追加は主に読み取り能力とフェイルオーバー先の拡張です。
• 自動スナップショットの保持期間は最大35日です。スナップショットはログやレプリカとは異なり、過去時点からの復元に使います。
• IAMは管理API、ACLはデータベースユーザーとコマンド、セキュリティグループはネットワーク接続元を制御します。
• MemoryDBの料金には、ノード時間のほか、書き込みデータ量とスナップショットストレージが関係します。予約ノードは料金割引の契約です。

AWS公式ドキュメント

• Amazon MemoryDBとは
• MemoryDBの機能
• MemoryDBの構成要素
• MemoryDBの整合性
• MemoryDBの複製
• MemoryDBのスナップショットと復元
• 自動スナップショットのスケジュール
• MemoryDBのセキュリティ
• MemoryDBのリージョンとアベイラビリティーゾーン
• MemoryDBの予約ノード
• Amazon MemoryDBの料金