一般的なベストプラクティス

このページは、Memorystore for Valkey の最適な使用に関するガイダンスです。このページでは、回避すべき潜在的な問題についても説明します。

メモリ管理のベストプラクティス

このセクションでは、Memorystore for Valkey がアプリケーションで効率的に機能するようにインスタンスメモリを管理する方法について説明します。

メモリ管理のコンセプト

書き込み負荷 - Valkey インスタンスでキーを追加または更新するボリュームと速度。書き込み負荷は、Valkyrie のユースケースとアプリケーションの使用パターンに応じて、通常から非常に高いまでさまざまです。
エビクションポリシー - Memorystore for Valkey は volatile-lru エビクションポリシーを使用します。EXPIRE コマンドなどの Valkey コマンドを使用して、キーの強制排除を設定できます。

通常の書き込み負荷があるインスタンスのモニタリング

/instance/cpu/maximum_utilization 指標を表示する/instance/cpu/maximum_utilization が 100% 以下の場合、通常の書き込み負荷を使用したときに Valkey インスタンスは正常に動作します。

ただし、メモリ使用量が 100% に近づき、データ使用量の増加が予想される場合は、インスタンスサイズをスケールアップして新しいデータ用のスペースを確保する必要があります。

書き込み負荷が高いインスタンスをモニタリングする

/instance/memory/maximum_utilization 指標を表示する高い書き込み負荷の重大度によっては、次のしきい値でインスタンスのパフォーマンスの問題が発生する可能性があります。

書き込み負荷が非常に高い場合、/instance/memory/maximum_utilization が 65% 以上に達すると問題が発生する可能性があります。
書き込み負荷が中程度に高い場合、/instance/memory/maximum_utilization が 85% 以上に達すると問題が発生する可能性があります。

このようなシナリオでは、インスタンスのサイズをスケールアップしてパフォーマンスを改善する必要があります。

問題が発生した場合や、インスタンスの書き込み負荷が高いと思われる場合は、Google Cloud サポートにご連絡ください。

シャードのスケーリング

インスタンスでシャードの数をスケーリングする場合は、書き込みが少ない期間にスケーリングする必要があります。書き込み負荷が高い期間にスケーリングを行うと、レプリケーションまたはスロット移行によるメモリのオーバーヘッドが原因で、インスタンスにメモリの負荷がかかります。

Valkey のユースケースでキーの強制排除を使用している場合、インスタンスサイズを小さくすると、キャッシュヒット率が低下する可能性があります。ただし、このような状況ではキーのエビクションが想定されるため、データの損失について心配する必要はありません。

鍵を失うことが許されない Valkey のユースケースでは、データに十分な容量がある小さいインスタンスにのみスケールダウンする必要があります。新しいターゲットシャード数は、データで使用されるメモリの 1.5 倍以上になるようにする必要があります。つまり、現在インスタンスにあるデータの 1.5 倍のシャードをプロビジョニングする必要があります。/instance/memory/total_used_memory 指標を使用して、インスタンスに保存されているデータの量を確認できます。

CPU 使用率のベストプラクティス

予期しないゾーンの停止が発生すると、使用できないゾーンのノードで容量が失われるため、インスタンスの CPU リソースが減少します。高可用性インスタンスを使用することをおすすめします。（シャードあたり 1 つのレプリカではなく）シャードごとに 2 つのレプリカを使用すると、停止時に追加の CPU リソースが得られます。さらに、予期しないゾーン停止が発生した場合に容量の損失による追加のトラフィックに対処できるように、ノードの CPU 使用率を管理することをおすすめします。メインスレッド CPU 秒 /instance/cpu/maximum_utilization 指標を使用して、プライマリとレプリカの CPU 使用率をモニタリングする必要があります。

ノードごとにプロビジョニングするレプリカの数に応じて、次の /instance/cpu/maximum_utilization CPU 使用率目標をおすすめします。

ノードごとに 1 つのレプリカを持つインスタンスでは、プライマリとレプリカで /instance/cpu/maximum_utilization の値を 0.5 秒に設定する必要があります。
ノードごとに 2 つのレプリカがあるインスタンスの場合、プライマリには 0.9 秒、レプリカには 0.5 秒の /instance/cpu/maximum_utilization 値をターゲットにする必要があります。

この指標の値がこれらの推奨値を超える場合は、インスタンス内のシャードまたはレプリカの数をスケールアップすることをおすすめします。

CPU の負荷の高い Valkey コマンド

さまざまな理由で実行コストが高い Valkey コマンドは使用しないでください。このセクションでは��一部のコマンドがコストが高い理由の例を示します。ただし、このリストは網羅的なものではありません。

キースペース全体を操作するコマンド

可変長の鍵セットで動作するコマンド

LRANGE
ZRANGE
HGETALL

スクリプトの実行をブロックするコマンド

EVAL
EVALSHA

コストのかかるコマンドの使用によるリスク

レイテンシが高く、クライアントがタイムアウトする。
メモリ使用量を増やすコマンドによって引き起こされるメモリ負荷。
Valkey メインスレッドのブロックにより、ノードレプリケーションと同期中にデータが失われる。
ヘルスチェック、オブザーバビリティ、レプリケーションの不足。

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

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

クライアントマッピング

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

クライアントが初期化されると、ノードマッピングに初期スロットを挿入する必要があります。
サーバーから MOVED リダイレクトを受け取った場合（以前のプライマリノードによって処理されたすべてのスロットがレプリカに引き継がれるフェイルオーバーが発生した場合など）、またはスロットが再シャーディングされた場合など移行元プライマリからターゲットプライマリへの移動が伴います。
サーバーから CLUSTERDOWN エラーを受け取った場合や、特定のサーバーへの接続が持続的にタイムアウトになった場合。
サーバーから READONLY エラーが受信された場合。これは、プライマリがレプリカに降格された場合に発生することがあります。
また、クライアントはトポロジを定期的に更新して、クライアントが変更に対してウォームアップ状態を維持し、新しいレプリカノードが追加された場合など、サーバーからのリダイレクトやエラーにつながらない変更を認識する必要があります。古い接続は、コマンドの実行時に失敗した接続を処理する必要性を減らすため、トポロジの更新の一環としても閉じる必要があります。

クライアントの開拓

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

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

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

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

Valkey での検出のオーバーロードを回避する

接続リクエストと検出リクエストの急増による影響を軽減するには、次の方法をおすすめします。

クライアントアプリケーションからの同時受信接続の数を制限するために、有限の小さなサイズのクライアント接続プールを実装します。
タイムアウトが原因でクライアントがサーバーから切断された場合は、ジッターを伴う指数バックオフで再試行します。これにより、複数のクライアントが同時にサーバーに過剰な負荷をかけることを回避できます。
Memorystore for Valkey ディスカバリエンドポイントを使用してノード調査を実行します。検出エンドポイントは高可用性で、インスタンス内のすべてのノードにロードバランスされます。さらに、検出エンドポイントは、最新のトポロジビューを持つノードにノード検出リクエストを転送しようとします。

永続性に関するベストプラクティス

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

RDB 永続性

RDB スナップショットを使用してインスタンスをバックアップする場合、最適な結果を得るには、次のベストプラクティスを使用する必要があります。

メモリ管理

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

スナップショットを完了するのに十分なメモリがノードに確保されるように、maxmemory をノードの容量の 80% に維持するか、設定して、20% をオーバーヘッド用に予約する必要があります。詳細については、書き込み負荷が高いインスタンスをモニタリングするをご覧ください。スナップショットのモニタリングに加え、このメモリオーバーヘッドにより、ワークロードのスナップショットを正常に処理できます。

古いスナップショット

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

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

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

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

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

インスタンスでレプリカを使用しない場合は、シングルゾーンインスタンスを選択します

レプリカを使用せずにインスタンスを構成する場合は、信頼性を高めるためにシングルゾーンアーキテクチャをおすすめします。その理由を説明します。

サービス停止の影響を最小限に抑える

ゾーンの停止がインスタンスに影響する可能性は低くなります。すべてのノードを 1 つのゾーンに配置すると、ゾーンの停止がサーバーに影響する可能性は 100% から 33% に低下します。これは、インスタンスが配置されているゾーンが停止する確率が 33% であるのに対し、使用できないゾーンに配置されているノードが影響を受ける確率が 100% であるためです。

迅速な回復

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