Memorystore for Valkey のベスト プラクティス

このページでは、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 秒、レプリカの 値を 0.5 秒に設定します。
• ノードあたり 2 つ以上のレプリカがあるインスタンスの場合、プライマリの /instance/cpu/maximum_utilization 値を 0.9 秒、各レプリカの 値を 0.5 秒に設定します。

指標の値がこれらの推奨値を超える場合は、インスタンスのシャード数をスケールアップすることをおすすめします。インスタンスのレプリカが 5 つ未満の場合は、レプリカの数を最大 5 つまでスケールアップすることもできます。

インスタンスの CPU 使用率が高い場合や、インスタンスのリソースが枯渇した場合（接続数が多すぎるなど）、インスタンスが誤動作し、外部指標が欠落する可能性があります。

リソースを大量に消費する Valkey コマンド

リソースを大量に消費する Valkey コマンドは使用しないことを強くおすすめします。これらのコマンドを使用すると、次のパフォーマンスの問題が発生する可能性があります。

• レイテンシが高く、クライアントがタイムアウトする
• メモリ使用量を増やすコマンドが原因のメモリ不足
• Valkey メインスレッドがブロックされているため、ノードのレプリケーションと同期中にデータ損失が発生する
• ヘルスチェック、オブザーバビリティ、レプリケーションの不足

次の表に、リソースを大量に消費する Valkey コマンドの例と、リソース効率の高い代替コマンドを示します。

ヒント: リソースを大量に消費するだけでなく、データサイズの合計が増加すると、これらのコマンドの使用コストも増加します。

使用する長時間実行コマンドを確認するには、SLOWLOG を使用します。このツールは、実行に最も時間がかかるコマンドのリストを提供します。その結果、レイテンシの問題を引き起こすコマンドを特定できます。これらのコマンドの効率的な代替リソースを判断するには、次の表をご覧ください。

カテゴリ	リソースを大量に消費するコマンド	リソース効率の高い代替手段
キースペース全体で実行する	KEYS	SCAN
可変長鍵セットに対して実行する	LRANGE	クエリに使用する範囲のサイズを制限します。
	ZRANGE	クエリに使用する範囲のサイズを制限します。
	HGETALL	HSCAN
	SMEMBERS	SSCAN
スクリプトの実行をブロックする	EVAL	スクリプトが無限に実行されないようにします。
	EVALSHA	スクリプトが無限に実行されないようにします。
ファイルとリンクを削除する	DELETE	UNLINK
パブリッシュとサブスクライブ	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

スケーリングのしきい値に関するベスト プラクティス

スケーリングしきい値のシナリオは、次のカテゴリに分類されます。

• メモリ使用率のスケーリング
• CPU 使用率のスケーリング
• スケーリングによるホットスポットの軽減

ワークロードがキーの削除に依存している場合、Google は CPU 使用率またはメモリ使用率のスケールインをおすすめしません。このようなワークロードでは、メモリ使用率が最大容量に達してから、自動的に削除が行われることがよくあります。その結果、メモリ使用量が急増し、スケールイン オペレーションがブロックされます。

以降のセクションでは、スケーリングが必要になる可能性のある一般的なシナリオと指標のしきい値について説明します。

メモリ使用率のスケーリング

メモリ使用量に基づいてスケーリングするタイミングを判断するには、/instance/memory/average_utilization 指標と /instance/memory/maximum_utilization 指標をモニタリングします。これらの指標の詳細については、サポートされているモニタリング指標をご覧ください。

インスタンスが次のいずれかの条件を満たしている場合は、スケールアウト オペレーションのトリガーを検討してください。

• インスタンスの平均メモリ使用率が、推奨しきい値の 70% を超えています。
• 最大メモリ使用率が 80% を超え、平均メモリ使用率が 50% を超えています。

インスタンスが次のいずれかの条件を満たしている場合は、スケールイン オペレーションのトリガーを検討してください。

• インスタンスの平均メモリ使用率が、推奨されるしきい値の 50% を下回っています。
• 最大メモリ使用率が 60% を下回り、平均メモリ使用率が 40% を下回る。

CPU 使用率のスケーリング

CPU 使用率に基づいてスケーリングするタイミングを判断するには、/instance/cpu/average_utilization 指標と /instance/cpu/maximum_utilization 指標をモニタリングします。

インスタンスが次のいずれかの条件を満たしている場合は、スケールアウト オペレーションのトリガーを検討してください。

• インスタンスの平均 CPU 使用率が、推奨されるしきい値の 70% を超えています。
• 最大 CPU 使用率が 80% を超え、平均 CPU 使用率が 50% を超えている。

インスタンスが次のいずれかの条件を満たしている場合は、スケールイン オペレーションのトリガーを検討してください。

• インスタンスの平均 CPU 使用率が、推奨されるしきい値の 50% を下回る。
• 最大 CPU 使用率が 60% を下回り、平均 CPU 使用率が 40% を下回る。

スケーリングによるホットスポットの軽減

Memorystore for Valkey は、同じ指標の平均と最大値のバリエーションを提供します。これを使用して、その指標ファミリーのホットスポットを特定できます。最大値は最も負荷の高いインスタンス ノードを表し、平均値はインスタンス全体の負荷を表します。最大値が平均値よりも大幅に高い場合は、特定のノードに不均衡な負荷がかかっている（ホットスポット）ことを示します。この問題を解決するには、インスタンスをスケールアウトすることをおすすめします。詳細については、インスタンス容量をスケーリングするをご覧ください。

平均値と最大値の間に大きな差がある場合は、インスタンス ノードに対して INFO memory コマンドと INFO cpu コマンドを実行して、インスタンスからリアルタイム データを直接収集できます。これらのコマンドの詳細については、Valkey ドキュメントの INFO をご覧ください。

Valkey クライアントのベスト プラクティス

Valkey での接続の過負荷を回避する

接続の急増による影響を軽減するには、次のことをおすすめします。

• 最適なクライアント接続プールサイズを決定します。各クライアントの適切な開始サイズは、Valkey ノードごとに 1 つの接続です。次に、ベンチマークを実行して、最大許容接続数を超えずに接続数を増やすことができるかどうかを確認します。

• サーバーがタイムアウトしたためにクライアントがサーバーから切断された場合は、ジッター付きの指数バックオフで再試行します。これにより、複数のクライアントが同時にサーバーに過負荷をかけることを回避できます。

応答しない接続を検出して処理する

Memorystore for Valkey への応答のない接続を検出するようにクライアント アプリケーションを構成することを強くおすすめします。応答のない接続が検出された場合、クライアントは接続をリセットする必要があります。復元力のあるアプリケーションを構築するには、次のクライアント構成をおすすめします。

• TCP keep-alive パラメータを構成する: 接続がアイドル状態の場合でも、クライアントが応答のない接続を積極的に検出して切断するように、TCP keepalive time、TCP keepalive interval、TCP keepalive probes パラメータを設定します。たとえば、TCP keepalive time パラメータを 30 秒、TCP keepalive interval を 10 秒、TCP keepalive probes を 3 に設定すると、クライアントは 1 分以内に応答のないアイドル状態の接続をリセットします。
• TCP ユーザー タイムアウトを構成する: 未処理のリクエストがあり、応答を停止している接続をリセットするために、クライアントでこのタイムアウトを設定します。たとえば、タイムアウトを 15 秒に設定すると、クライアントは未処理のリクエストがある応答のない接続を 15 秒後にリセットします。

クラスタモードが有効なインスタンスの場合

Memorystore for Valkey クラスタ モードが有効になっているインスタンスに接続する場合、アプリケーションはクラスタ対応の Valkey クライアントを使用する必要があります。クラスタ対応クライアントと構成例については、クライアント ライブラリのコードサンプルをご覧ください。クライアントは、インスタンス内のハッシュスロットと対応するノードのマップを維持して、リクエストを正しいノードに送信する必要があります。これにより、リダイレクトによるパフォーマンスのオーバーヘッドを防ぐことができます。

クライアント マッピング

クライアントは、次の状況でスロットとマッピングされたノードの完全なリストを取得する必要があります。

• クライアントが初期化されると、初期スロットからノードへのマッピングが設定されます。

• サーバーから MOVED リダイレクトを受信した場合。たとえば、以前のプライマリ ノードによって提供されていたすべてのスロットがレプリカによって引き継がれるフェイルオーバーや、スロットがソース プライマリからターゲット プライマリ ノードに移動される再シャーディングなどです。

• サーバーから CLUSTERDOWN エラーが返された場合、または特定のサーバーへの接続が常にタイムアウトになる場合。

• サーバーから READONLY エラーを受信した場合。これは、プライマリがレプリカに降格された場合に発生することがあります。

• また、クライアントはトポロジを定期的に更新して、変更に備えてクライアントをウォームアップし、新しいレプリカノードの追加など、サーバーからのリダイレクトやエラーが発生しない可能性のある変更を認識する必要があります。トポロジ更新の一部として古い接続も閉じることで、コマンド実行時の接続失敗を処理する必要性を減らすことができます。

クライアントの開拓

クライアントの検出は通常、Valkey サーバーに SLOTS、NODES、CLUSTER SHARDS コマンドを発行して行われます。CLUSTER SHARDS コマンドを使用することをおすすめします。CLUSTER SHARDS は、インスタンスのより効率的で拡張可能な表現を提供することで、SLOTS コマンド（非推奨）を置き換えます。

クライアント検出コマンドのレスポンスのサイズは、インスタンスのサイズとトポロジによって異なります。ノードが多い大規模なインスタンスほど、レスポンスが大きくなります。そのため、ノード トポロジ検出を行うクライアントの数が無制限に増えないようにすることが重要です。

これらのノード トポロジの更新は Valkey サーバーでコストがかかりますが、アプリケーションの可用性にとっても重要です。したがって、各クライアントが任意の時点で 1 回の検出リクエストを行い（結果をメモリにキャッシュに保存）、リクエストを行うクライアントの数を制限して、サーバーの過負荷を回避することが重要です。

たとえば、クライアント アプリケーションが起動したときや、サーバーとの接続が切断されてノード検出を実行する必要があるときに、クライアント アプリケーションが再試行時に指数バックオフを追加せずに、複数の再接続リクエストと検出リクエストを行うというよくある間違いがあります。これにより、Valkey サーバーが長時間応答しなくなり、CPU 使用率が非常に高くなる可能性があります。

ノード検出に検出エンドポイントを使用する

Memorystore for Valkey 検出エンドポイントを使用して、ノード検出を行います。ディスカバリ エンドポイントは高可用性であり、インスタンス内のすべてのノード間でロード バランシングされます。また、検出エンドポイントは、ノード検出リクエストを最新のトポロジ ビューを持つノードに転送しようとします。

クラスタモードが無効になっているインスタンスの場合

クラスタモードが無効なインスタンスに接続する場合、アプリケーションはプライマリ エンドポイントに接続してインスタンスに書き込み、最新の書き込みを取得する必要があります。アプリケーションは、リーダー エンドポイントに接続してレプリカから読み取り、プライマリ ノードからのトラフィックを分離することもできます。

インスタンスでメンテナンスを実行するときに create-before-destroy 戦略を使用すると、次のエラー メッセージが表示されることがあります。

READONLY You can't write against a read only replica.

この問題を解決するには、インスタンスへの接続を停止します。その後、接続を再作成します。

永続化のベスト プラクティス

このセクションでは、永続性に関するベスト プラクティスについて説明します。

RDB 永続性とレプリカの追加

RDB スナップショットを使用してインスタンスをバックアップする場合や、インスタンスにレプリカを追加する場合は、次のベスト プラクティスに従ってください。

メモリ管理

RDB スナップショットは、プロセス フォークと「コピーオンライト」メカニズムを使用して、ノードデータのスナップショットを作成します。ノードへの書き込みパターンに応じて、書き込みによってアクセスされたページがコピーされると、ノードの使用済みメモリが増加します。メモリ使用量は、ノード内のデータのサイズの 2 倍になることがあります。

ノードにスナップショットを完了するのに十分なメモリがあることを確認するには、maxmemory をノード容量の 80% に維持または設定して、20% をオーバーヘッド用に予約します。スナップショットのモニタリングに加え、このメモリ オーバーヘッドにより、ワークロードのスナップショットを正常に処理できます。また、レプリカを追加するときは、書き込みトラフィックをできるだけ減らしてください。詳細については、インスタンスのメモリ使用量をモニタリングするをご覧ください。

注: インスタンスの最大メモリの 80% を超えるメモリを使用しているインスタンスにレプリカを追加すると、オペレーションが失敗し、エラー メッセージが表示されます。

この問題を解決するには、次のいずれかの方法でインスタンスのメモリ使用量を減らします。

• インスタンスのメモリ使用量をノードの最大許容メモリの 80% 未満に減らします。
• インスタンスのノードタイプをスケーリングして、メモリを増やします。

インスタンスのメモリ使用量が 80% のしきい値を下回ったら、レプリカを再度追加します。

古いスナップショット

古いスナップショットからノードを復元すると、大量の古くなったキー、またはスキーマの変更などのデータベースに対するその他の変更を調整しようとするため、アプリケーションのパフォーマンスに問題が発生する可能性があります。古いスナップショットからの復元が懸念される場合は、RDB 永続性機能を無効にできます。永続性を再度有効にすると、次のスケジュールされたスナップショット間隔でスナップショットが取得されます。

RDB スナップショットのパフォーマンスへの影響

ワークロード パターンによっては、RDB スナップショットがインスタンスのパフォーマンスに影響し、アプリケーションのレイテンシが増加する可能性があります。スナップショットの頻度が低くても問題ない場合は、インスタンス トラフィックが少ない期間に実行するようにスケジュールを設定することで、RDB スナップショットのパフォーマンスへの影響を最小限に抑えることができます。

たとえば、インスタンスのトラフィックが午前 1 時から午前 4 時まで少ない場合は、開始時刻を午前 3 時に設定し、間隔を 24 時間に設定します。

システムの負荷が一定で、スナップショットが頻繁に必要な場合は、パフォーマンスへの影響を慎重に評価し、ワークロードに RDB スナップショットを使用するメリットを比較検討することをおすすめします。

レプリカを追加する

レプリカを追加するには、RDB スナップショットが必要です。RDB スナップショットの詳細については、メモリ管理をご覧ください。

シングルゾーン インスタンスを使用する場合

レプリカを使用しないようにインスタンスを構成する場合は、単一ゾーン インスタンスを使用することをおすすめします。その理由は次のとおりです。

費用とパフォーマンス

コストを最小限に抑え、同じリージョンにあるクライアントのピーク パフォーマンスを確保することが主な目的である場合は、シングルゾーン インスタンスを選択することをおすすめします。

停止の影響を最小限に抑える

シングルゾーン インスタンスを選択すると、ゾーンの停止がインスタンスに影響する可能性が低くなります。すべてのノードを単一のゾーンに配置すると、サーバーに影響するゾーンの停止の可能性が 100% から 33% に低下します。インスタンスが配置されているゾーンがダウンする確率は 33% ですが、使用できないゾーンにあるノードが影響を受ける確率は 100% です。

迅速な回復

単一ゾーン インスタンスでゾーンの停止が発生した場合、Memorystore for Valkey はデータの復元を効率化します。機能しているゾーンに新しいインスタンスを迅速にプロビジョニングし、アプリケーションをリダイレクトして、オペレーションの中断を最小限に抑えることができます。

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 を有効にする組み込みの制御機能がない場合がありますが、カスタムコードを使用してこの機能をインスタンスに統合できます。