Amazon ElastiCache for Redis OSSのクラスタリングとGlobal Datastore
ElastiCache for Redis OSSのシャード、プライマリとレプリカ、クラスターモード、エンドポイント、スケーリング、Global Datastoreの設計を学びます。
Amazon ElastiCache for Redis OSSは、Redis OSSエンジンのノード、レプリカ、データ分割をマネージドクラスターとして提供します。構成を選ぶ際は、データセットを1つのシャードで扱うか複数のシャードへ分散するか、読み取りレプリカや別リージョンへの複製が必要かを決めます。
Redis OSSクラスターは、単に複数台のノードを並べる構成ではありません。プライマリが書き込みを受け付け、必要に応じてレプリカが読み取り要求を受け持ちます。クラスターモードを有効にすると、キー空間をシャードへ分割します。データの配置、接続先の見つけ方、障害時の切り替え方は、このモードによって変わります。
シャードとノードの役割
ノードグループ（シャード）は、データの一部を保持する単位です。各シャードには書き込みを処理するプライマリノードが1つあり、必要に応じて読み取り専用のレプリカノードを追加します。レプリカはプライマリからデータを複製し、読み取り処理を分担できます。プライマリが故障したときは、適切な構成であればレプリカを新しいプライマリに昇格させ、クラスターの書き込みを再開できます。
シャードあたりのレプリカ数は0〜5個です。レプリカを置かない場合は複製先がなく、プライマリ障害時に同じシャードのレプリカへ切り替える構成を取れません。レプリカを置けば可用性や読み取り能力を高められますが、レプリカの分もノード容量と料金が必要です。レプリカはバックアップそのものではなく、誤更新やアプリケーションによる削除も複製されるため、別途バックアップを検討します。
ノードには個別のエンドポイントがあります。運用者がすべてのノードへ固定的に接続するのではなく、クラスターのモードに応じたエンドポイントとRedis Cluster対応クライアントを使います。ただし、エンドポイントを使えばAWSがアプリケーションの全コマンドを代理実行する、という意味ではありません。特にクラスターモード有効では、クライアントがクラスターの配置情報を理解する必要があります。
クラスターモード無効と有効の違い
| 比較点 | クラスターモード無効 | クラスターモード有効 |
|---|---|---|
| データ配置 | 1つのシャードに全データを保持する | キー空間を複数のシャードへ分割する |
| プライマリ数 | 1つ | シャードごとに1つ |
| レプリカ | 0〜5個。読み取り分散とプライマリ障害時の昇格候補に使う | シャードごとに0〜5個。各シャードの読み取り分散と昇格候補に使う |
| 容量の広げ方 | 主にノードタイプを大きくする。レプリカ追加で読み取り処理を分担できるが、書き込みとデータ容量は水平分割されない | ノードタイプ変更に加え、シャード追加でデータと処理を分散できる |
| クライアント接続 | プライマリエンドポイント、リーダーエンドポイント、または個別ノードの用途を選ぶ | 構成エンドポイントで初期接続し、Redis Cluster対応クライアントがノードとスロットの配置に従って要求を送る |
| 主な注意点 | 1シャード内の最大データ量・処理能力が上限となる | クライアントのクラスターモード対応、キー分散、シャードをまたぐ操作を設計する |
クラスターモード無効は「ノードが1台だけ」という意味ではありません。シャードは1つですが、その中にプライマリとレプリカを置けます。単一シャード内のレプリカは読み取りを助け、フェイルオーバーに利用できます。しかし、データ自体を複数シャードに分けるわけではないため、レプリカを増やしてもプライマリの書き込み能力や1シャードのデータ容量は水平には拡張しません。
クラスターモード有効では複数シャードにデータを分割できます。より大きなデータセットや高い書き込み処理能力が必要な場合に選びます。シャードを増やすと利用可能な合計メモリーや並列処理能力を広げられますが、キーの偏りによって一部シャードに負荷が集中すると、クラスター全体の資源を活用しきれません。データ分割により、バックアップ、復元、運用変更では複数シャードを扱うことになります。所要時間はデータ量、シャード数、処理内容などに依存するため、一律に短時間で終わるとは限りません。
エンドポイントと接続先の決まり方
クラスターモード無効では、用途に応じてエンドポイントを使い分けます。
- プライマリエンドポイントは書き込みを受け付けるプライマリへ接続するために使います。フェイルオーバー後もアプリケーションが新しいプライマリへ到達できるよう、個別ノード名を固定する代わりにこのエンドポイントを利用します。
- リーダーエンドポイントは読み取りレプリカへの接続に使います。読み取り要求を分散できますが、レプリカの複製には遅れがあり得るため、直前の書き込みを必ず読めるといった強い整合性を前提にしてはいけません。
- ノードエンドポイントは特定ノードへ直接接続する場合に使います。個別ノードを指定する必要があるツールや運用作業などで利用します。
クラスターモード有効では、構成エンドポイントがクラスター対応クライアントの初期接続先になります。クライアントは構成情報からキーのハッシュスロットと担当シャードを把握し、要求を該当ノードへ送ります。AWSはシャードの追加・削除に伴うスロット再配置を管理しますが、すべてのRedisクライアントがクラスタートポロジー変更に追従できるわけではありません。採用するライブラリーがRedis Clusterプロトコルと配置変更後の再接続に対応するかを確認してください。
クラスターモード無効のリーダーエンドポイントはロードバランサーではありません。DNSが読み取りレプリカのアドレスを順番に返し、接続を分散します。クライアントが接続を作る頻度や接続を再利用する方法によって、実際の要求数が均等になるとは限りません。読み取りの偏りを避けるには、接続プールやレプリカごとの負荷も監視します。
Memcachedではクライアントがキーから接続ノードを選ぶのに対し、Redis ClusterではRedisのスロット配置とクラスター対応クライアントが接続先を扱います。どちらもアプリケーションが接続設計を不要にできるわけではありません。Memcachedではクライアント側のキー分散方式、Redis Clusterではクラスタープロトコルへの対応が重要です。
シャード数とノード上限
クラスターモード有効では最大500シャードまでのデータ分割が可能です。ただし、サービスクォータはプライマリだけでなくレプリカを含むノード総数にも適用されます。したがって「500シャード」と「500ノード」は同じ意味ではありません。
AWSの現行ガイドでは、クラスターは通常90ノードまで作成でき、クォータ引き上げによって1クラスターあたり最大500ノードまで拡張できるとしています。ValkeyとRedis OSS 5.0.6以降が最大500ノードの対象で、それより前のRedis OSSバージョンでは上限が250ノードです。クォータ上限の範囲でも、レプリカが多い構成ほど作成できるシャード数は少なくなります。
500ノードの上限まで引き上げた例では、プライマリのみなら500シャード、プライマリ1台とレプリカ5台の構成なら floor(500 ÷ 6) = 83 シャード、合計498ノードまでです。84シャードでは504ノードとなり上限を超えます。AWSのガイドではシャード数自体を最大500としていますが、レプリカを設定する場合はノード総数の制約が先に効くことがあります。
これらは最大値であり、利用アカウントやリージョンで最初から作成できる数を保証するものではありません。サービスクォータの引き上げ、利用可能なノードタイプ、サブネットのIPアドレス数などの前提があります。設計時はElastiCacheの現在のサービスクォータとリージョンごとの対応条件を確認してください。
スケーリング
クラスターモード無効
1シャードのプライマリがデータと書き込みを担うため、データ容量やプライマリ性能を高めたい場合は、より大きなノードタイプへの変更（スケールアップ）を検討します。読み取り要求が多い場合はレプリカを追加して分散できます。不要なレプリカを削除すれば、読み取り能力や冗長性と引き換えにノード数を減らせます。
クラスターモード無効の構成では、シャードを増やしてキー空間を分割する水平拡張はできません。データセットまたは書き込み負荷が1シャードの能力を超える場合は、クラスターモード有効の構成を検討します。クラスターモードを変更できる条件や切り替え手順は、現在のエンジンとクラスター設定を確認して計画します。
レプリカの追加・削除やノードタイプの変更は、AWS Management Console、AWS CLI、またはAPIから行えます。変更による再起動・フェイルオーバー・クライアント再接続の必要性は操作ごとに異なります。
クラスターモード有効
クラスターモード有効では、必要に応じてシャードを追加または削除することで、データ分散先と処理能力を水平方向に調整します。各シャードのノードタイプを変更すれば、個々のノードのメモリーや計算資源も変更できます。シャード数とノードタイプの変更を組み合わせて、データ量・処理量に合わせます。
ElastiCacheはシャードの再配置を行います。Memcachedのようにアプリケーションが独自に各ノードへキーを割り当て直す方式ではありませんが、アプリケーションがクラスターモードに対応している必要は残ります。スケーリング中は再配置、ノードの交換、クライアントのトポロジー更新が発生し得ます。キーの配置が偏っていないか、再配置後にクライアントが新しい構成を認識できるか、接続再試行やタイムアウトを含めて確認します。
変更を反映するタイミング
変更内容によっては、すぐに適用するか次のメンテナンスウィンドウで適用するかを選べます。選択肢や停止・フェイルオーバーの影響は、ノードタイプ変更、レプリカ操作、シャード変更、エンジンバージョン、クラスター状態によって異なります。「即時」を指定できても、すべての操作が無停止で終わるという意味ではありません。AWSの変更手順と影響を確認し、必要に応じてクライアント再接続、監視、メンテナンス時間を計画します。
バックアップと復元
クラスターモード有効ではデータが複数シャードへ分散されるため、バックアップと復元はクラスター全体の構成を考慮して実施します。スナップショットにはシャードごとのRDBファイルが作成されます。クラスターモード無効の単一シャードからは単一のRDBファイルが使われます。データ量やシャード数はバックアップ・復元時間に影響します。復元先のシャード数を変える場合や、別リージョンへ展開する場合は、エンジンバージョン、ノードタイプ、クライアントの接続先も含めた手順を確認します。
高可用性のレプリカとバックアップは役割が違います。レプリカは同じクラスター内の読み取り分散やプライマリ障害時の切り替えを助けますが、長期保管や誤操作からの復旧用コピーではありません。必要な保持期間と復旧時点に合わせてスナップショットを構成し、復元を実際に試します。
Global Datastoreによるリージョン間複製
Global Datastoreは、ノードベースのValkeyまたはRedis OSSクラスターをリージョン間で複製する仕組みです。1つのプライマリリージョンから、別の最大2リージョンにあるセカンダリークラスターへデータを非同期複製します。プライマリ側は読み書き可能で、セカンダリー側は通常、ローカルアプリケーションの読み取りや災害復旧に使います。
主な目的は2つあります。利用者に近いリージョンのレプリカから読み取ることで、遠距離のネットワーク遅延を抑えること、そしてプライマリリージョンに障害が起きたときに別リージョンへ切り替えることです。後者は自動で書き込み先が変わる単一のマルチリージョン・プライマリ構成ではありません。障害時には運用者がセカンダリーを新しいプライマリとして昇格させ、アプリケーションの書き込み接続先やDNS、設定を切り替えます。
複製は非同期のため、プライマリへの書き込みがセカンダリーへ反映されるまでに遅延が生じます。リージョン障害の直前に行われた更新がセカンダリーへ届いていなければ、昇格後にその更新を失う可能性があります。リージョン間レイテンシーと複製遅延を監視し、許容できるRPO、障害検知、昇格判断、アプリケーション切り替え、旧プライマリの再参加手順を決めておきます。
Global Datastoreを構成するには、対応エンジン、エンジンバージョン、ノードタイプ、クラスターモードなどの組み合わせを満たす必要があります。プライマリとセカンダリーを追加・更新する際にも、リージョン間の構成互換性が求められます。旧資料にある「Redis OSS 5.0.6以上」「R5世代以上」といった最低条件は、サービスの進化で変わり得るため固定条件として暗記せず、Global Datastoreの現在の要件と制約を確認します。利用できない機能や操作もあるので、採用する機能を個別に検証します。
現在のAWSガイドはValkeyとRedis OSSの両方を対象としているため、「Redis OSSだけが使える」と限定しないようにします。Global Datastoreのリージョンメンバーは、プライマリノード数、ノードタイプ、エンジンバージョン、クラスターモード有効時のシャード数を揃える必要があります。ローカル読み取り量に合わせてレプリカ数はリージョンごとに変えられます。サービスの対応リージョンとノードファミリーは随時更新されるため、設計時に公式の互換条件を確認してください。
Global Datastoreはインターネットプロトコルバージョン6（IPv6）、Local Zone、クロスアカウント構成、および耐久性が有効なクラスターには対応しません。自動フェイルオーバーを有効にする場合は、プライマリとセカンダリーの各クラスターに少なくとも1つのレプリカが必要です。既存の単一ノードクラスターをプライマリにする場合は、レプリケーションを有効にします。セカンダリーへの昇格自体は手動で行い、フェイルオーバー時の読み書き停止や複製遅延を踏まえた運用手順が必要です。
Global Datastore配下のクラスターをスケーリングするときは、Global Datastoreを通じてリージョン間の構成をまとめて変更します。AWSは各リージョンのクラスターを順に調整します。スケールアップではセカンダリーが先、プライマリが後になり、スケールダウンではプライマリが先です。リージョン間複製を継続できるよう、変更中の監視とアプリケーション側の再接続も計画します。
要件に合う構成を選ぶ
| 要件 | 構成の考え方 |
|---|---|
| データセットを1ノードグループで扱い、読み取りを分散したい | クラスターモード無効でプライマリとレプリカを構成する |
| 1シャードのメモリーや書き込み能力を超えるデータを保持したい | クラスターモード有効にして複数シャードへ分割する |
| シャード内のプライマリ障害へ備えたい | シャードごとにレプリカを置き、自動フェイルオーバーの条件を確認する |
| 利用者に近いリージョンから読み取りたい | Global Datastoreのセカンダリーリージョンを検討し、複製遅延を許容できる読み取りに使う |
| リージョン障害時に書き込みを継続したい | Global Datastoreの手動昇格とアプリケーション切り替えを含めた復旧手順を用意する |
| Redisクライアントを変更できない | クライアントのクラスターモード対応を先に確認し、非対応の場合はシャーディングが必要な構成を避ける |
試験で押さえるポイント
- クラスターモード無効は「レプリカを作れない」ではなく、データを1シャードに置く構成です。レプリカは読み取りを分担し、プライマリ障害時に昇格できます。
- クラスターモード有効は、複数シャードにキー空間を分散する構成です。レプリカ数を増やすと冗長性や読み取り能力が高まる一方、ノード総数の上限内で使えるシャード数は減ります。
- クラスターモード有効の構成エンドポイントはクライアントの入口です。Redis Cluster対応クライアントがスロット配置を使って担当シャードへ接続するため、AWSの単一エンドポイントがすべてのRedis要求を透過的に振り分けると考えないようにします。
- クラスターモード無効の主な容量拡張はノードタイプ変更、クラスターモード有効の拡張はノードタイプ変更とシャード追加・削除です。レプリカ追加は読み取りと可用性を補いますが、シャード内の書き込みを水平分割しません。
- Global Datastoreは最大3リージョン（プライマリ1、セカンダリー最大2）の構成で、ValkeyとRedis OSSのノードベースクラスターを非同期複製します。リージョン間フェイルオーバーは自動ではなく、セカンダリー昇格とアプリケーションの接続先変更が必要です。
公式ドキュメント
重要ポイント
- ▸シャードはプライマリノードと0〜5個のレプリカで構成され、レプリカは読み取り専用でプライマリ障害時の昇格先にもなる
- ▸クラスターモード無効は1シャードでデータを分割しない。レプリカを配置して読み取りを分散し、障害時の可用性を高められる
- ▸クラスターモード有効はデータを複数シャードへ分割する。構成エンドポイントを使うクラスター対応クライアントがスロット情報を取得して各ノードへ接続する
- ▸クラスターモード有効では最大500シャードを構成できるが、レプリカを含むノード上限とサービスクォータのため、実際のシャード数はレプリカ数に左右される
- ▸クラスターモード無効では主にノードタイプ変更とレプリカ数で調整し、有効ではノードタイプ変更に加えてシャードを追加・削除して水平拡張する
- ▸Global Datastoreはプライマリリージョンから最大2つのセカンダリーリージョンへ非同期複製する構成で、フェイルオーバー時の昇格はアプリケーション切り替えを含めて手動で行う
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
AWSデータベースサービス に関連するトピックを続けて確認できます。