このページでは、Memorystore for Valkey を最適に使用するためのガイダンスを提供します。このページでは、回避すべき潜在的な問題についても説明します。
メモリ管理のベスト プラクティス
このセクションでは、Memorystore for Valkey がアプリケーションで効率的に動作するようにインスタンスのメモリを管理する戦略について説明します。
メモリ管理のコンセプト
メモリ使用量: インスタンスが使用するメモリの量。メモリ容量は固定されています。指標を使用して、使用しているメモリの量をモニタリングできます。
エビクション ポリシー: Memorystore for Valkey は
volatile-lruエビクション ポリシーを使用します。EXPIREコマンドなどの Valkey コマンドを使用して、キーの削除を設定できます。
インスタンスのメモリ使用量をモニタリングする
Memorystore for Valkey インスタンスのメモリ使用量をモニタリングするには、/instance/memory/maximum_utilization 指標を表示することをおすすめします。インスタンスのメモリ使用量が 80% に近づき、データ使用量の増加が見込まれる場合は、新しいデータ用の領域を確保するためにインスタンスのサイズをスケールアップします。
インスタンスのメモリ使用率が高い場合は、次の手順でパフォーマンスを改善します。
- インスタンス サイズをスケールアップする。
maxmemory構成パラメータの値を小さくします。
問題が発生した場合は、Google Cloud カスタマーケアにお問い合わせください。
クラスタモードが有効になっているシャードをスケーリングする
インスタンス内のシャード数をスケーリングする場合は、書き込みが少ない期間にスケーリングすることをおすすめします。使用率が高い期間にスケーリングを行うと、レプリケーションまたはスロット移行によるメモリのオーバーヘッドが原因で、インスタンスにメモリの負荷がかかります。
Valkey のユースケースでキーの強制排除を使用している場合、インスタンス サイズを小さくすると、キャッシュ ヒット率が低下する可能性があります。ただし、この状況ではキーの削除が想定されているため、データが失われる心配はありません。
キーを失いたくない Valkey のユースケースでは、データを格納するのに十分な容量がある小さなインスタンスにのみスケールダウンする必要があります。新しいターゲット シャード数は、データで使用されるメモリの 1.5 倍以上にする必要があります。つまり、インスタンスに現在あるデータの 1.5 倍の量のシャードをプロビジョニングする必要があります。/instance/memory/total_used_memory 指標を使用すると、インスタンスに保存されているデータ量を確認できます。
CPU 使用率のベスト プラクティス
予期しないゾーンの停止が発生すると、使用できないゾーンのノードから容量が失われるため、インスタンスの CPU リソースが減少します。高可用性インスタンスを使用することをおすすめします。シャードごとに複数のレプリカを使用すると（シャードごとに 1 つのレプリカを使用するのではなく）、停止時に追加の CPU リソースが提供されます。シャードごとに最大 5 個のレプリカを作成できます。
また、予期しないゾーン停止が発生した場合に、ノードが失われた容量からの追加トラフィックを処理するのに十分な CPU オーバーヘッドを確保できるように、ノードの CPU 使用率を管理することをおすすめします。メインスレッド CPU 秒 /instance/cpu/maximum_utilization 指標を使用して、プライマリとレプリカの CPU 使用率をモニタリングする必要があります。
ノードごとにプロビジョニングするレプリカの数に応じて、次の /instance/cpu/maximum_utilization CPU 使用率の目標値をおすすめします。
- ノードごとに 1 つのレプリカがあるインスタンスの場合は、プライマリの
/instance/cpu/maximum_utilization値を 0.5 秒、レプリカの/instance/cpu/maximum_utilization値を 0.5 秒に設定します。 - ノードあたり 2 つ以上のレプリカがあるインスタンスでは、プライマリの
/instance/cpu/maximum_utilization値を 0.9 秒、各レプリカの/instance/cpu/maximum_utilization値を 0.5 秒に設定します。
指標の値がこれらの推奨事項を超える場合は、インスタンスのシャード数をスケールアップすることをおすすめします。インスタンスのレプリカが 5 つ未満の場合は、レプリカの数を最大 5 つまでスケールアップすることもできます。
リソースを大量に消費する Valkey コマンド
リソースを大量に消費する Valkey コマンドは使用しないことを強くおすすめします。これらのコマンドを使用すると、次のパフォーマンスの問題が発生する可能性があります。
- レイテンシが高く、クライアントがタイムアウトする
- メモリ使用量を増やすコマンドによるメモリ負荷
- Valkey のメインスレッドがブロックされているため、ノードのレプリケーションと同期中にデータ損失が発生する
- ヘルスチェック、オブザーバビリティ、レプリケーションの不足
次の表に、リソースを大量に消費する Valkey コマンドの例と、リソース効率の高い代替コマンドを示します。
| カテゴリ | リソースを大量に消費するコマンド | リソース効率の高い代替手段 |
|---|---|---|
| キースペース全体で実行する | KEYS |
SCAN |
| 可変長キーセットで実行する | LRANGE |
クエリに使用する範囲のサイズを制限します。 |
ZRANGE |
クエリに使用する範囲のサイズを制限します。 | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| スクリプトの実行をブロックする | EVAL |
スクリプトが無限に実行されないようにします。 |
EVALSHA |
スクリプトが無限に実行されないようにします。 | |
| ファイルとリンクを削除する | DELETE |
UNLINK |
| パブリッシュとサブスクライブ | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Valkey クライアントのベスト プラクティス
Valkey での接続の過負荷を回避する
接続の急増による影響を軽減するには、次のことをおすすめします。
最適なクライアント接続プールサイズを決定します。各クライアントの適切な開始サイズは、Valkey ノードごとに 1 つの接続です。次に、ベンチマークを実行して、最大許容接続数を超えずに接続数を増やすことができるかどうかを確認します。
サーバーのタイムアウトによりクライアントがサーバーから切断された場合は、ジッター付きの指数バックオフで再試行します。これにより、複数のクライアントが同時にサーバーに過負荷をかけることを回避できます。
クラスタモードが有効なインスタンスの場合
Memorystore for Valkey クラスタモードが有効になっているインスタンスに接続する場合、アプリケーションはクラスタ対応の Valkey クライアントを使用する必要があります。クラスタ対応クライアントの例と構成例については、クライアント ライブラリのコードサンプルをご覧ください。クライアントは、ハッシュスロットとインスタンス内の対応するノードのマップを維持して、リクエストを正しいノードに送信する必要があります。これにより、リダイレクトによるパフォーマンスのオーバーヘッドが防止されます。
クライアント マッピング
クライアントは、次の状況でスロットとマッピングされたノードの完全なリストを取得する必要があります。
クライアントが初期化されるときに、初期スロットからノードへのマッピングを設定する必要があります。
サーバーから
MOVEDリダイレクトを受信した場合。たとえば、以前のプライマリ ノードによって提供されていたすべてのスロットがレプリカに引き継がれたフェイルオーバーの場合や、スロットがソース プライマリからターゲット プライマリ ノードに移動されている再シャーディングの場合などです。サーバーから
CLUSTERDOWNエラーが返された場合、または特定のサーバーへの接続が繰り返しタイムアウトした場合。サーバーから
READONLYエラーを受信した場合。これは、プライマリがレプリカに降格された場合に発生することがあります。また、クライアントはトポロジを定期的に更新して、変更に備えてクライアントをウォームアップし、新しいレプリカノードが追加された場合など、サーバーからのリダイレクトやエラーが発生しない可能性のある変更について学習する必要があります。トポロジ更新の一環として、古い接続もすべて閉じる必要があります。これにより、コマンドの実行中に接続の失敗を処理する必要性が軽減されます。
クライアントの開拓
クライアントの検出は通常、Valkey サーバーに SLOTS、NODES、CLUSTER SHARDS コマンドを発行して行われます。CLUSTER SHARDS コマンドを使用することをおすすめします。CLUSTER SHARDS は、インスタンスのより効率的で拡張可能な表現を提供することで、SLOTS コマンド（非推奨）を置き換えます。
クライアント検出コマンドのレスポンスのサイズは、インスタンスのサイズとトポロジによって異なります。ノード数の多い大規模なインスタンスでは、レスポンスが大きくなります。そのため、ノード トポロジ検出を行うクライアントの数が無制限に増えないようにすることが重要です。
これらのノード トポロジの更新は Valkey サーバーではコストがかかりますが、アプリケーションの可用性にとっても重要です。したがって、各クライアントが任意の時点で 1 回の検出リクエストを行うこと（結果をメモリにキャッシュに保存すること）、リクエストを行うクライアントの数を制限してサーバーの過負荷を回避することが重要です。
たとえば、クライアント アプリケーションが起動したときや、サーバーからの接続が切断されてノード検出を実行する必要があるときに、クライアント アプリケーションが再試行時に指数バックオフを追加せずに、再接続と検出のリクエストを複数回行うというよくある間違いがあります。これにより、Valkey サーバーが長時間応答しなくなり、CPU 使用率が非常に高くなる可能性があります。
ノード検出に検出エンドポイントを使用する
Memorystore for Valkey ディスカバリー エンドポイントを使用して、ノード ディスカバリーを実行します。ディスカバリ エンドポイントは可用性が高く、インスタンス内のすべてのノード間でロード バランシングされます。また、検出エンドポイントは、ノード検出リクエストを最新のトポロジ ビューを持つノードに転送しようとします。
クラスタモードが無効になっているインスタンスの場合
クラスタモードが無効なインスタンスに接続する場合、アプリケーションはプライマリ エンドポイントに接続してインスタンスに書き込み、最新の書き込みを取得する必要があります。アプリケーションは、レプリカからの読み取りとプライマリ ノードからのトラフィックの分離のために、リーダー エンドポイントに接続することもできます。
永続性に関するベスト プラクティス
このセクションでは、永続性に関するベスト プラクティスについて説明します。
RDB 永続性とレプリカの追加
RDB スナップショットを使用してインスタンスをバックアップする場合や、インスタンスにレプリカを追加する場合は、次のベスト プラクティスに従ってください。
メモリ管理
RDB スナップショットは、プロセス フォークと「コピーオンライト」メカニズムを使用して、ノードデータのスナップショットを作成します。ノードへの書き込みパターンに応じて、書き込みによってアクセスされたページがコピーされると、ノードの使用済みメモリが増加します。メモリ フットプリントは、ノード内のデータの最大 2 倍になることがあります。
ノードにスナップショットを完了するのに十分なメモリがあることを確認するには、maxmemory をノード容量の 80% に維持または設定して、20% をオーバーヘッド用に予約します。スナップショットのモニタリングに加え、このメモリ オーバーヘッドにより、ワークロードのスナップショットを正常に処理できます。また、レプリカを追加するときは、書き込みトラフィックをできるだけ減らしてください。詳細については、インスタンスのメモリ使用量をモニタリングするをご覧ください。
古いスナップショット
古いスナップショットからノードを復元すると、大量の古くなったキー、またはスキーマの変更などのデータベースに対するその他の変更を調整しようとするため、アプリケーションのパフォーマンスに問題が発生する可能性があります。古いスナップショットからの復元が懸念される場合は、RDB 永続化機能を無効にできます。永続性を再度有効にすると、次のスケジュールされたスナップショット間隔でスナップショットが取得されます。
RDB スナップショットのパフォーマンスへの影響
ワークロード パターンによっては、RDB スナップショットがインスタンスのパフォーマンスに影響し、アプリケーションのレイテンシが増加する可能性があります。スナップショットの頻度が低くても問題ない場合は、インスタンス トラフィックが少ない期間に実行するようにスケジュール設定することで、RDB スナップショットのパフォーマンスへの影響を最小限に抑えることができます。
たとえば、インスタンスのトラフィックが午前 1 時から午前 4 時まで少ない場合は、開始時刻を午前 3 時に設定し、間隔を 24 時間に設定します。
システムの負荷が一定で、スナップショットが頻繁に必要な場合は、パフォーマンスへの影響を慎重に評価し、ワークロードに RDB スナップショットを使用するメリットを比較検討してください。
レプリカを追加する
レプリカを追加するには、RDB スナップショットが必要です。RDB スナップショットの詳細については、メモリ管理をご覧ください。
インスタンスがレプリカを使用しない場合は、シングルゾーン インスタンスを選択する
レプリカなしでインスタンスを構成する場合は、信頼性を高めるために単一ゾーン アーキテクチャをおすすめします。その理由を説明します。
停止の影響を最小限に抑える
ゾーンの停止がインスタンスに影響する可能性は低くなります。すべてのノードを単一のゾーンに配置すると、サーバーに影響するゾーン停止の可能性が 100% から 33% に低下します。これは、インスタンスが配置されているゾーンがダウンする可能性が 33% であるのに対し、使用できないゾーンにあるノードが影響を受ける可能性は 100% であるためです。
迅速な回復
ゾーンの停止が発生した場合、復旧が効率化されます。機能しているゾーンに新しいインスタンスを迅速にプロビジョニングし、アプリケーションをリダイレクトすることで、オペレーションの中断を最小限に抑えながら対応できます。
Transport Layer Security（TLS）を有効にする
このセクションでは、Transport Layer Security（TLS）を使用するセキュリティ上のメリットとパフォーマンスへの影響について説明し、TLS を有効にするための推奨事項を示します。
セキュリティ上のメリット
TLS を使用すると、次のようなセキュリティ上のメリットが得られます。
- Identity and Access Management（IAM）認証: TLS は、このタイプの認証を使用して、中間者攻撃などのサーバー スプーフィング攻撃から保護します。
- 転送データの暗号化:Google Cloudの組み込み暗号化により、Google のネットワーク内のトラフィックがインフラストラクチャ レベルで保護されます。ただし、これには Google のホストとネットワーク スタックの両方を信頼する必要があります。この暗号化は透過的でデフォルトで有効になっていますが、エンドツーエンドではありません。一方、TLS はアプリケーション レイヤで転送中の暗号化を使用します。このエンドツーエンドの暗号化により、暗号鍵とプロセスをより詳細に制御できます。
- 認証トークンの保護: IAM 認証を使用している場合、TLS を有効にすると、認証トークンの漏洩リスクを最小限に抑えることができます。
パフォーマンスへの影響
TLS は、次のようにパフォーマンスに影響します。
接続を確立する: TLS セッションを確立したクライアントとサーバーは、クライアントとサーバー間の接続を確立するリソース集約型のプロセスを繰り返すことなく、セッションを再開できます。TLS 再開を有効にすると、クライアントとサーバー間の接続確立のオーバーヘッドが削減されます。
TLS 再開を確立しない場合、接続の確立には多くのリソースが必要になります。新規と既存の接続の両方で、クライアントとサーバー間の接続が多いと、接続タイムアウトが発生する可能性があります。Memorystore for Valkey はタイムアウトした接続の再確立を試みるため、接続の確立に使用するリソースが増加し、スノーボール効果が発生する可能性があります。
データの暗号化と復号: データの暗号化と復号には、クライアントとサーバーの両方に影響する CPU 使用率の高いオペレーションが含まれます。これにより、インスタンスの容量が減少し、インスタンスのレイテンシが増加する可能性があります。
推奨事項
TLS を有効にするかどうかを検討する際は、TLS のメリットとデメリットを考慮しながら、セキュリティ ポリシーを評価することをおすすめします。TLS を有効にする場合は、次の点に注意してください。
- TLS 再開を有効にすると、接続確立のオーバーヘッドが軽減されます。クライアントとサーバー間の接続は、最初の接続でのみ必要です。ただし、クライアントのインスタンス サイズが突然拡大すると、新しいクライアント ホストの初期の完全なハンドシェイクが原因で、短時間の中断が発生する可能性があります。
- 一部のクライアント ライブラリには TLS を有効にする組み込みの制御機能がない場合がありますが、カスタムコードを使用してこの機能をインスタンスに統合できます。