このページでは、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 使用率は、
メインスレッド CPU 秒 /instance/cpu/maximum_utilization 指標を使用してモニタリングする必要があります。
ノードごとにプロビジョニングするレプリカの数に応じて、次の /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 コマンドの例と、リソース効率の高い代替コマンドを示します。
| カテゴリ | リソースを大量に消費するコマンド | リソース効率の高い代替コマンド |
|---|---|---|
| キースペース全体で実行する | KEYS |
SCAN |
| 可変長のキーセットで実行する | LRANGE |
クエリに使用する範囲のサイズを制限します。 |
ZRANGE |
クエリに使用する範囲のサイズを制限します。 | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| スクリプトの実行をブロックする | EVAL |
スクリプトが無限に実行されないようにします。 |
EVALSHA |
スクリプトが無限に実行されないようにします。 | |
| ファイルとリンクを削除する | DELETE |
UNLINK |
| パブリッシュとサブスクライブ | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
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% をオーバーヘッド用に予約します。スナップショットのモニタリングに加え、このメモリ オーバーヘッドにより、ワークロードのスナップショットを正常に処理できます。また、レプリカを追加する場合は、書き込みトラフィックをできるだけ減らします。詳細については、インスタンスのメモリ使用量をモニタリングするをご覧ください。
古いスナップショット
古いスナップショットからノードを復元すると、大量の古くなったキー、またはスキーマの変更などのデータベースに対するその他の変更を調整しようとするため、アプリケーションのパフォーマンスに問題が発生する可能性があります。古いスナップショットからの復元が心配な場合は、RDB 永続性機能を無効にできます。 永続性を再度有効にすると、次のスケジュールされたスナップショット間隔でスナップショットが作成されます。
RDB スナップショットのパフォーマンスへの影響
ワークロード パターンによっては、RDB スナップショットがインスタンスのパフォーマンスに影響し、アプリケーションのレイテンシが増加する可能性があります。スナップショットの頻度が低くても問題ない場合は、インスタンス トラフィックが少ない期間に実行するように RDB スナップショットをスケジュールすることで、RDB スナップショットのパフォーマンスへの影響を最小限に抑えることができます。
たとえば、インスタンスのトラフィックが午前 1 時から午前 4 時まで少ない場合は、開始時刻を午前 3 時に設定し、間隔を 24 時間に設定します。
システムの負荷が一定で、スナップショットが頻繁に必要な場合は、パフォーマンスへの影響を慎重に評価し、ワークロードに RDB スナップショットを使用するメリットを比較検討することをおすすめします。
レプリカを追加する
レプリカを追加するには、RDB スナップショットが必要です。RDB スナップショットの詳細については、メモリ管理をご覧ください。
シングルゾーン インスタンスを使用する場合
レプリカを使用しないようにインスタンスを構成する場合は、 シングルゾーン インスタンスを使用することをおすすめします。 その理由は次のとおりです。
費用とパフォーマンス
コストを最小限に抑え、同じリージョンにあるクライアントのパフォーマンスを最大にすることが主な目的である場合は、シングルゾーン インスタンスを選択することをおすすめします。
停止の影響を最小限に抑える
シングルゾーン インスタンスを選択すると、ゾーンの停止がインスタンスに影響する可能性が低くなります。すべてのノードを 1 つのゾーンに配置すると、ゾーンの停止がサーバーに影響する可能性が 100% から 33% に低下します。使用できないゾーンにあるノードが影響を受ける可能性は 100% ですが、インスタンスが配置されているゾーンが停止する可能性は 33% です。
迅速なリカバリー
シングルゾーン インスタンスでゾーンの停止が発生した場合、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 再開を有効にすると、接続の確立のオーバーヘッドが軽減されます。クライアントとサーバー間の接続は、最初の接続でのみ必要です。ただし、クライアントのインスタンス サイズが急激に拡大すると、新しいクライアント ホストの最初の完全な handshake が原因で、一時的な中断が発生する可能性があります。
- 一部の クライアント ライブラリでは、TLS を有効にする組み込みの制御が提供されていない場合がありますが、カスタムコードを使用して この機能をインスタンスに統合できます。