このページでは、Memorystore for Redis Cluster インスタンスのクラスタとノードの仕様について説明します。インスタンスを作成する手順については、 インスタンスを作成するをご覧ください。
ノードタイプを選択する
クラスタ内のすべてのシャードは、選択した同じノードタイプを使用します。クラスタに最適なノードタイプは、料金、パフォーマンス、キースペース容量の要件によって異なります。
redis-shared-core-nano ノードタイプは小規模なワークロード用です。このノードタイプはパフォーマンスが変動し、SLA がないため、本番環境ワークロードには適していません。
redis-standard-small ノードタイプを使用すると、小規模なクラスタをプロビジョニングし、他のノードタイプよりも低コストでクラスタを小規模に拡張できます。redis-standard-small には、合計 vCPU 数が多いノードにキースペースを分散できるというメリットもあります。小さいノードの合計キースペース容量がデータのニーズに十分であれば、redis-highmem-medium と比較して料金とパフォーマンスが向上します。
メモリに対して高い処理能力を必要とするワークロードがある場合は、redis-highcpu-medium ノードタイプを選択します。redis-highmem-medium で提供される容量よりも多くの容量が必要な場合は、redis-standard-large、redis-highmem-xlarge、redis-highmem-2xlarge ノードタイプを選択することをおすすめします。vCPU をより大きなノードに追加すると（スケールアップ）、Redis のパフォーマンスが直線的にスケーリングされないことがあります。代わりに、料金とパフォーマンスを向上させるには、クラスタにノードを追加してスケールアウトすることをおすすめします。
ノードタイプの仕様
ノードの容量と特性は、選択するノードタイプによって異なります。
キースペース容量と予約済みのオーバーヘッド
| ノードタイプ | デフォルトの書き込み可能なキースペース容量 | ノードの合計容量 |
|---|---|---|
| redis-shared-core-nano | 1.12 GB | 1.4 GB |
| redis-standard-small | 5.2 GB | 6.5 GB |
| redis-highmem-medium | 10.4 GB | 13 GB |
| redis-highcpu-medium | 10.4 GB | 13 GB |
| redis-standard-large | 20.8 GB | 26 GB |
| redis-highmem-xlarge | 46.4 GB | 58 GB |
| redis-highmem-2xlarge | 88 GB | 110 GB |
Memorystore は、メモリ不足（OOM）エラーを防ぐために、インスタンス容量の一部を自動的に予約します。これにより、キーの読み取りと書き込みがスムーズに行われます。メモリの上限とストレージの詳細については、次のとおりです。
ストレージのカスタマイズ: デフォルト設定を使用することをおすすめしますが、
maxmemory構成を使用して予約済みストレージの量を調整することもできます。maxmemory、 については、サポートされているインスタンス構成をご覧ください。利用できるストレージはどのくらいですか？前掲の表の [デフォルトの書き込み可能なキースペース容量] 列を参照してください。 これは、デフォルトでキーに使用できるストレージの量を示しています。
ストレージの最大化 : 許容されるストレージを最大にする場合、
maxmemory構成を 100% に設定した場合に、[ノードの合計容量] 列にストレージの上限が表示されます。 ただし、デフォルト設定よりも高いmaxmemory値を選択することはおすすめしません。redis-shared-core-nanoノードタイプの上限は 1.12 GB であり、maxmemory構成で変更することはできません。
ノードの特性
| ノードタイプ | vCPU 数 | 提供される SLA | クライアント接続のデフォルト数 | クライアント接続の最大数 | クライアントの最大メモリ（maxmemory-clients 構成） |
|---|---|---|---|---|---|
| redis-shared-core-nano | 0.5 | × | 5,000 | 5,000 | 12% |
| redis-standard-small | 2 | はい | 16,000 | 32,000 | 7% |
| redis-highmem-medium | 2 | はい | 32,000 | 64,000 | 7% |
| redis-highcpu-medium | 8 | はい | 32,000 | 64,000 | 7% |
| redis-standard-large | 8 | はい | 32,000 | 64,000 | 7% |
| redis-highmem-xlarge | 8 | ○ | 64,000 | 64,000 | 4% |
| redis-highmem-2xlarge | 16 | はい | 64,000 | 64,000 | 4% |
クラスタに選択する仮想 CPU（vCPU）が多いほど、パフォーマンスが向上します。クラスタでリソースを大量に消費するワークロードを実行する場合は、vCPU が多いノードタイプ（redis-highmem-xlarge など）を選択します。クラスタで負荷の低いタスクを実行する場合は、vCPU が少ないノードタイプ（redis-highmem-medium など）を選択します。
インスタンスをスケーリングする
Memorystore for Redis Cluster インスタンスを作成する際に、インスタンスのノードタイプを選択し、インスタンスのシャード数を指定します。 インスタンスを作成した後、インスタンスの容量のニーズが変化した場合は、次のようにインスタンスをスケーリングする必要があります。
- インスタンスのシャード数を変更します。これは水平方向のスケーリングです。 インスタンスを水平方向にスケーリングするには、次のいずれかの操作を行います。
- インスタンスにシャードを追加します。これは、インスタンスのスケールアウトです。
- インスタンスからシャードを削除します。これは、インスタンスのスケールインです。
- インスタンスのノードタイプを変更します。これは垂直方向のスケーリングです。 インスタンスを垂直方向にスケーリングするには、インスタンスのノードタイプを次のいずれかのノードタイプに変更します。
- より大きなノードタイプに変更します。これは、インスタンスのスケールアップです。
- より小さなノードタイプに変更します。これは、インスタンスのスケールダウンです。
クラスタ仕様
このセクションでは、クラスタ形状、ノードタイプ、レプリカ数に応じたクラスタの最小容量と最大容量を示します。
最小書き込み可能容量
書き込み可能容量は、キーの書き込みに使用できるストレージの量です。これは、1 つのインスタンス ノードのサイズと同じです。したがって、ノードタイプに応じて、最小書き込み可能容量は 1.4 GB ～ 110 GB です。最小書き込み可能容量は、選択したレプリカ数に影響されません。
最大書き込み可能容量
| ノードタイプとサイズ | 250 個のプライマリ ノードと ノードあたり 0 個のレプリカのクラスタ形状での最大容量 | 125 個のプライマリ ノードとノードあたり 1 個のレプリカのクラスタ形状での最大容量 | 83 個のプライマリ ノードとノードあたり 2 個のレプリカのクラスタ形状での最大容量 | 62 個のプライマリ ノードとノードあたり 3 個のレプリカのクラスタ形状での最大容量 | プライマリ ノード 50 個とノードあたり 4 個のレプリカのクラスタ形状での最大容量 | 41 個のプライマリ ノードとノードあたり 5 個のレプリカのクラスタ形状での最大容量 |
|---|---|---|---|---|---|---|
| redis-shared-core-nano - 1.4 GB | 350 GB | 175 GB | 116.2 GB | 86.8 GB | 70 GB | 57.4 GB |
| redis-standard-small - 6.5 GB | 1,625 GB | 812.5 GB | 539.5 GB | 403 GB | 325 GB | 266.5 GB |
| redis-highmem-medium - 13 GB | 3,250 GB | 1,625 GB | 1,079 GB | 806 GB | 650 GB | 533 GB |
| redis-highcpu-medium - 13 GB | 3,250 GB | 1,625 GB | 1,079 GB | 806 GB | 650 GB | 533 GB |
| redis-standard-large - 26 GB | 6,500 GB | 3,250 GB | 2,158 GB | 1,612 GB | 1,300 GB | 1,066 GB |
| redis-highmem-xlarge - 58 GB | 14,500 GB | 7,250 GB | 4,814 GB | 3,596 GB | 2,900 GB | 2,378 GB |
| redis-highmem-2xlarge - 110 GB | 27,500 GB | 13,750 GB | 9,130 GB | 6,820 GB | 5,500 GB | 4,510 GB |
パフォーマンス
us-central1 リージョンで OSS メモリ階層ベンチマーク ツールを使用して、2 vCPU ノード（redis-standard-small と
redis-highmem-medium）ごとに、マイクロ秒のレイテンシと 1 KiB のデータサイズで、1 秒あたり 120,000 ～ 130,000
のオペレーションが実行されました。
本番環境のトラフィックに似た実際のワークロードまたは合成ワークロードを使用して、独自のベンチマークを実行することをおすすめします。また、ワークロードの急増や予期しないトラフィックに備えて、バッファ（または「ヘッドルーム」）を使用してクラスタのサイズを設定することをおすすめします。詳細については、 Memorystore for Redis Cluster のベスト プラクティスをご覧ください。
クラスタ エンドポイント
このセクションでは、各インスタンスにある 2 つのエンドポイントについて説明します。
検出エンドポイント
各インスタンスには、クライアントが接続する検出エンドポイントがあります。これは、IP アドレスとポート番号の組み合わせです。クラスタの検出エンドポイントを見つける方法については、クラスタの検出エンドポイントを表示するをご覧ください。
クライアントはノードの検出にもこれを使用します。クライアントは検出エンドポイントを使用してインスタンスのクラスタ トポロジを取得し、OSS Redis クラスタ クライアントをブートストラップし、更新を安定した状態で維持します。結果として得られるクラスタ トポロジは、Redis クラスタ クライアントによってメモリ内にキャッシュされる Redis ノード エンドポイント（IP とポートの組み合わせ）を提供します。その後、クライアントは更新とリダイレクトを自動的に処理するため、他のアプリケーションの変更は必要ありません。クライアント検出の動作とベスト プラクティスについては、 クライアント検出をご覧ください。
検出エンドポイントは、複数のゾーンにまたがる複数の Redis ノードによって支えられており、クラスタ トポロジを提供するため、高可用性です。バックエンド ノードの障害やノードの更新が発生した場合でも、エンドポイントを介したトポロジの提供は堅牢です。
検出エンドポイントの動作は次のとおりです。
クラスタ インスタンスのライフサイクル全体を通じて、メンテナンス中や、スケールイン、スケールアウト、レプリカ数の変更などのその他のアクションを行っても、クラスタの検出エンドポイントは変更されません。
Redis ノード エンドポイントは変更される可能性があり、ノードの追加と削除に伴って再利用される可能性があります。トポロジの更新とリダイレクトによってこれらの変更を自動的に処理できる Redis クラスタ クライアントを使用することをおすすめします。Redis クラスタ クライアントの例については、クライアント ライブラリのコードサンプルをご覧ください。アプリケーションには、依存関係や特定のクラスタでノード エンドポイントが変更されないという前提があってはなりません。
データ エンドポイント
検出エンドポイントに加えて、各クラスタにはデータ エンドポイントがあります。このエンドポイントは、クライアントをクラスタ内のノードに接続するために Memorystore for Redis Cluster で使用するために予約されています。したがって、このエンドポイントに直接接続しないでください。