このページでは、Memorystore for Redis Cluster インスタンスのクラスタとノードの仕様について説明します。インスタンスを作成する手順については、インスタンスを作成するをご覧ください。
ノードタイプを選択する
クラスタ内のすべてのシャードは、選択した同じノードタイプを使用します。クラスタに最適なノードタイプは、料金、パフォーマンス、キースペース容量の要件によって異なります。
redis-shared-core-nano ノードタイプは小規模なワークロード用です。このノードタイプはパフォーマンスが変動し、SLA がないため、本番環境のワークロードには適していません。
redis-standard-small ノードタイプを使用すると、小規模なクラスタをプロビジョニングし、他のノードタイプよりも低コストでクラスタを小規模な増分で拡張できます。redis-standard-small には、合計 vCPU 数が多いノードにキースペースを分散できるという利点もあります。小さいノードの合計キースペース容量がデータのニーズを満たすのに十分である限り、redis-highmem-medium よりも価格性能比が向上します。
redis-highmem-medium で提供されるクラスタ容量よりも多くの容量が必要な場合にのみ、redis-highmem-xlarge ノードタイプを選択することをおすすめします。redis-highmem-xlarge ノードタイプはサイズ redis-highmem-medium の 4 倍ですが、vCPU がより大きなノードに追加されたときに（スケールアップ）、Redis のパフォーマンスは直線的にスケーリングされないため、パフォーマンスは 4 倍になりません。代わりに、価格パフォーマンスを向上させるには、クラスタにノードを追加してスケールアウトする必要があります。
ノードタイプの仕様
ノードの容量と特性は、使用可能な 4 つのノードタイプのうち、どれを選択するかによって異なります。
キースペースの容量と予約済みオーバーヘッド
| ノードタイプ | デフォルトの書き込み可能なキースペース容量 | ノードの合計容量 |
|---|---|---|
| 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-highmem-xlarge | 46.4 GB | 58 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 | 12% |
| redis-standard-small | 2 | ○ | 16,000（デフォルト）。最大値は 32,000 | 7% |
| redis-highmem-medium | 2 | ○ | 32,000（デフォルト）。最大値は 64,000 | 7% |
| redis-highmem-xlarge | 8 | ○ | 64,000 | 4% |
クラスタに選択する仮想 CPU（vCPU）が多いほど、パフォーマンスが向上します。クラスタでリソースを大量に消費するワークロードを実行する場合は、vCPU が多いノードタイプ（redis-highmem-xlarge など）を選択します。クラスタで負荷の低いタスクを実行する場合は、vCPU が少ないノードタイプ（redis-highmem-medium など）を選択します。
インスタンスをスケーリングする
Memorystore for Redis Cluster インスタンスの作成の一環として、インスタンスのノードタイプを選択し、インスタンスのシャード数を指定します。インスタンスを作成した後、インスタンスの容量のニーズが変化するにつれて、次の方法でインスタンスをスケーリングする必要が生じる可能性があります。
- インスタンスのシャード数を変更します。これは水平方向のスケーリングです。インスタンスを水平方向にスケーリングするには、次のいずれかの操作を行います。
- インスタンスにシャードを追加します。これは、インスタンスをスケールアウトしています。
- インスタンスからシャードを削除します。これはインスタンスのスケールインです。
- インスタンスのノードタイプを変更します。これが垂直方向のスケーリングです。インスタンスを垂直方向にスケーリングするには、インスタンスのノードタイプを次のいずれかのノードタイプに変更します。
- より大きなノードタイプに変更します。これは、インスタンスをスケールアップしています。
- より小さなノードタイプに変更します。これは、インスタンスのスケールダウンです。
クラスタ仕様
このセクションには、クラスタの形状、ノードタイプ、レプリカ数に基づいて、クラスタの最小容量と最大容量が表示されます。
最小書き込み可能容量
書き込み可能な容量は、鍵の書き込みに使用できるストレージの量です。これは、1 つのインスタンス ノードのサイズと同じです。したがって、ノードタイプに応じて、最小書き込み可能容量は 1.4 GB、6.5 GB、13 GB、58 GB のいずれかになります。最小書き込み可能容量は、選択したレプリカ数に影響されません。
最大書き込み可能容量
| ノードのタイプとサイズ | 250 個のプライマリ ノードと ノードあたり 0 個のレプリカのクラスタ形状での最大容量 | 125 個のプライマリ ノードとノードあたり 1 個のレプリカのクラスタ形状での最大容量 | 83 個のプライマリ ノードとノードあたり 2 個のレプリカのクラスタ形状での最大容量 |
|---|---|---|---|
| redis-shared-core-nano - 1.4 GB | 350 GB | 175 GB | 116.2 GB |
| redis-standard-small - 6.5 GB | 1,625 GB | 812.5 GB | 539.5 GB |
| redis-highmem-medium - 13 GB | 3,250 GB | 1,625 GB | 1,079 GB |
| redis-highmem-xlarge - 58 GB | 14,500 GB | 7,250 GB | 4,814 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 がクライアント接続に使用する Private Service Connect データ エンドポイントもあります。これに直接接続すべきではありませんが、Memorystore for Redis Cluster は、クライアントをクラスタノードに接続するためにこのエンドポイントを使用します。