このページでは、Memorystore for Valkey インスタンスのインスタンスとノードの仕様について説明します。インスタンスを作成する手順については、インスタンスを作成するをご覧ください。
ノードタイプを選択する
インスタンス内のすべてのノードは、選択した同じノードタイプを使用します。インスタンスに最適なノードタイプは、料金、パフォーマンス、キースペース容量の要件によって異なります。
shared-core-nano ノードタイプは小規模なワークロード用です。このノードタイプはパフォーマンスが変動し、SLA がないため、本番環境のワークロードには適していません。
standard-small ノードタイプを使用すると、小規模なインスタンスをプロビジョニングし、他のノードタイプよりも低コストでインスタンスを小規模な増分で拡張できます。standard-small には、合計 vCPU 数が多いノードにキースペースを分散できるという利点もあります。小さいノードの合計キースペース容量がデータのニーズを満たすのに十分である限り、highmem-medium よりも価格性能比が向上します。
highmem-medium で提供されるインスタンス容量よりも多くの容量が必要な場合にのみ、highmem-xlarge ノードタイプを選択することをおすすめします。highmem-xlarge ノードタイプはサイズ highmem-medium の 4 倍ですが、vCPU がより大きなノードに追加されたときに（スケールアップ）、Valkey のパフォーマンスは直線的にスケーリングされないため、パフォーマンスは 4 倍になりません。代わりに、価格パフォーマンスを向上させるには、インスタンスにノードを追加してスケールアウトする必要があります。
ノードタイプの仕様
ノードの容量と特性は、使用可能な 4 つのノードタイプのうち、どれを選択するかによって異なります。
キースペースの容量と予約済みのオーバーヘッド
| ノードタイプ | デフォルトの書き込み可能なキースペース容量 | ノードの合計容量 |
|---|---|---|
| shared-core-nano | 1.12 GB | 1.4 GB |
| standard-small | 5.2 GB | 6.5 GB |
| highmem-medium | 10.4 GB | 13 GB |
| highmem-xlarge | 46.4 GB | 58 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 | 12% |
| standard-small | 2 | ○ | 16,000（デフォルト）。最大値は 32,000 | 7% |
| highmem-medium | 2 | ○ | 32,000（デフォルト）。最大値は 64,000 | 7% |
| highmem-xlarge | 8 | ○ | 64,000 | 4% |
インスタンスに選択する仮想 CPU（vCPU）が多いほど、パフォーマンスが向上します。インスタンスでリソースを大量に消費するワークロードを実行する場合は、vCPU が多いノードタイプ（highmem-xlarge など）を選択します。インスタンスで負荷の少ないタスクを実行する場合は、vCPU が少ないノードタイプ（highmem-medium など）を選択します。
インスタンスをスケーリングする
Memorystore for Valkey インスタンスの作成の一環として、インスタンスのノードタイプを選択し、インスタンスのシャード数を指定します。インスタンスを作成した後、インスタンスの容量のニーズが変化するにつれて、次の方法でインスタンスをスケーリングする必要が生じる可能性があります。
- インスタンスのシャード数を変更します。これは水平方向のスケーリングです。インスタンスを水平方向にスケーリングするには、次のいずれかの操作を行います。
- インスタンスにシャードを追加します。これは、インスタンスをスケールアウトしています。
- インスタンスからシャードを削除します。これはインスタンスのスケールインです。
- インスタンスのノードタイプを変更します。これが垂直方向のスケーリングです。インスタンスを垂直方向にスケーリングするには、インスタンスのノードタイプを次のいずれかのノードタイプに変更します。
- より大きなノードタイプに変更します。これは、インスタンスをスケールアップしています。
- より小さなノードタイプに変更します。これは、インスタンスのスケールダウンです。
インスタンスの仕様
このセクションには、インスタンスの形状、ノードタイプ、レプリカ数に基づいて、インスタンスの最小容量と最大容量が表示されます。
最小書き込み可能容量
書き込み可能な容量は、鍵の書き込みに使用できるストレージの量です。これは、1 つのインスタンス ノードのサイズと同じです。したがって、ノードタイプに応じて、最小書き込み可能容量は 1.4 GB、6.5 GB、13 GB、58 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 |
| highmem-xlarge - 58 GB | 14,500 GB | 7,250 GB | 4,814 GB | 3,596 GB | 2,900 GB | 2,378 GB |
クラスタモードが無効になっているインスタンス
次の表に、クラスタモードが無効になっているインスタンスの最大書き込み可能容量を示します。
| ノードのタイプとサイズ | 最大容量 |
|---|---|
| shared-core-nano - 1.4 GB | 1.12 GB |
| standard-small - 6.5 GB | 5.2 GB |
| highmem-medium - 13 GB | 10.4 GB |
| highmem-xlarge - 58 GB | 46.4 GB |
パフォーマンス
us-central1 リージョンで OSS メモリ階層ベンチマーク ツールを使用して、2 vCPU ノード（standard-small と highmem-medium）ごとに、マイクロ秒のレイテンシと 1 KiB のデータサイズで、1 秒あたり 120,000 ～ 130,000 のオペレーションが実行されました。
本番環境トラフィックに似た実際のワークロードまたは疑似ワークロードを使用して、独自のベンチマークを実施することをおすすめします。また、ワークロードの急増や予期しないトラフィックに備えて、バッファ（ヘッドルーム）を考慮してインスタンスのサイズを設定することをおすすめします。詳しくは、ベスト プラクティスをご覧ください。
クラスタモードが有効なインスタンスのエンドポイント
このセクションでは、クラスタモードが有効なインスタンスにある検出エンドポイントとデータ エンドポイントについて説明します。
検出エンドポイント
各インスタンスには、クライアントが接続する検出エンドポイントがあります。これは、IP アドレスとポート番号の組み合わせです。インスタンスの検出エンドポイントを見つける方法については、インスタンスの検出エンドポイントを表示するをご覧ください。
クライアントはノードの検出にもこれを使用します。クライアントは検出エンドポイントを使用してインスタンスのノード トポロジを取得し、サードパーティ クライアントをブートストラップし、更新を安定した状態で維持します。結果のノード トポロジは、サードパーティ クライアントによってメモリ内にキャッシュに保存されるノード エンドポイント（IP とポートの組み合わせ）を提供します。クライアントは、他のアプリケーションの変更を必要とせずに、更新とリダイレクトを自動的に処理します。クライアント検出の動作とベスト プラクティスについては、クライアント検出をご覧ください。
検出エンドポイントは、複数のゾーンにまたがる複数のノードによって支えられており、インスタンス トポロジを提供するため、可用性が高くなります。エンドポイントを介したトポロジの提供は、バックエンド ノードの障害やノードの更新が発生した場合でも堅牢です。
検出エンドポイントの動作は次のとおりです。
インスタンスの検出エンドポイントは、インスタンスのライフサイクル全体を通じて変更されません。メンテナンス中や、スケールイン / スケールアウト、レプリカ数の変更などのアクションを実行した場合でも変更されません。
ノード エンドポイントは変更される可能性があり、ノードが追加または削除されると再利用される可能性があります。理想的には、トポロジの更新とリダイレクトによってこれらの変更を自動的に処理できるサードパーティ クライアントを使用する必要があります。サードパーティ クライアントの例については、クライアント ライブラリのコードサンプルをご覧ください。アプリケーションには、依存関係や特定のインスタンスでノード エンドポイントが変更されないという前提があってはなりません。
データ エンドポイント
各インスタンスには、Memorystore for Valkey がクライアント接続に使用する Private Service Connect データ エンドポイントもあります。このエンドポイントに直接接続しないでください。代わりに、Memorystore for Valkey は、クライアントをインスタンス内のノードに接続するためにこのエンドポイントを使用します。
クラスタモードが無効なインスタンスのエンドポイント
このセクションでは、クラスタモードが無効な各インスタンスにあるプライマリ エンドポイントとリーダー エンドポイントについて説明します。
プライマリ エンドポイント
プライマリ エンドポイントは、アプリケーションが接続する IP アドレスです。このエンドポイントは、トラフィックを現在のプライマリ ノードに転送します。プライマリ エンドポイントへの接続は、書き込みクエリと読み取りクエリの両方を送信できます。
プライマリ エンドポイントの動作は次のとおりです。
- プライマリ エンドポイントの IP アドレスは、インスタンスのライフサイクル全体を通して変更されません。基盤となるノードで障害が発生した場合や、自動フェイルオーバーが発生した場合、Memorystore for Valkey は IP アドレスを自動的に調整します。クライアントはエンドポイントを変更する必要はありません。ただし、計画外のイベントによって接続が失敗した場合、クライアントは接続の再確立を試みます。
- プライマリ ノードがレプリカになると、このレプリカノードへの接続が終了し、Memorystore for Valkey は自動フェイルオーバーによって新しい接続を新しいプライマリ ノードにリダイレクトします。クライアントは、指数バックオフを使用して接続を再試行することが想定されています。
- インスタンスにレプリカが 1 つある場合、プライマリ エンドポイントの可用性はリーダー エンドポイントよりも高くなります。インスタンスに 2 つのレプリカがプロビジョニングされている場合、プライマリ エンドポイントとリーダー エンドポイントの両方に高可用性があります。
リーダー エンドポイント
リーダー エンドポイントは、アプリケーションが接続する IP アドレスです。このエンドポイントは、インスタンス内のレプリカ間で接続を均等にロードバランスします。リードレプリカへの接続は、読み取りクエリを送信できますが、書き込みクエリは送信できません。リーダー エンドポイントは、スループットを向上させ、プライマリ ノードからのトラフィック分離を提供します。リスクの高いスクリプトやオフライン ジョブなど、運用アクセスを必要とするアプリケーションでは、リーダー エンドポイントを使用してプライマリ ノードからのトラフィックを分離することをおすすめします。
リーダー エンドポイントの動作は次のとおりです。
- インスタンスにリードレプリカがプロビジョニングされていない場合でも、Memorystore for Valkey は、リードレプリカの動的な追加を可能にするために、リーダー エンドポイントの IP アドレスをプロビジョニングします。
- トラフィックを転送できるリードレプリカがシステムにない場合、リーダー エンドポイントへの接続は終了します。ただし、リーダー エンドポイントへの接続はプライマリ ノードにルーティングされません。
- レプリカノードがプライマリ ノードになると、このプライマリ ノードへの接続が終了し、Memorystore for Valkey は新しい接続を新しいレプリカノードにリダイレクトします。クライアントは、指数バックオフを使用してこれらの接続を再試行します。
クラスタモードが無効になっているエンドポイントへの接続中に発生する一般的なエラーの処理については、クラスタモードが無効になっている場合のエラーの処理をご覧ください。