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