このページでは、Memorystore for Valkey がインスタンスのメンテナンスを行う方法について説明します。また、Memorystore for Valkey のゼロダウンタイム メンテナンス設計を活用するために、クライアント アプリケーションが認識する必要がある情報と構成の推奨事項についても説明します。これらの推奨事項は、高可用性インスタンスとレプリカのないインスタンスの両方に適用されます。ただし、すべての本番環境のユースケースでは、高可用性構成を使用することを強くおすすめします。
Memorystore for Valkey はインスタンスを定期的に更新し、サービスの信頼性、パフォーマンス、セキュリティ、最新性を確保します。こうした更新はメンテナンスと呼ばれます。メンテナンスはサービスによって完全に管理され、ダウンタイムの影響がゼロになるように設計されています。
メンテナンスは通常、以下のカテゴリに分類されます。
- Memorystore の機能。Memorystore の機能の中には、起動するためにメンテナンス更新が必要なものがあります。
- オペレーティング システムのパッチ。Google では、オペレーティング システムに存在する新たなセキュリティ脆弱性を継続的に監視しています。こうした脆弱性が見つかると、オペレーティング システムにパッチを適用し、新たなリスクからシステムを保護します。
- データベース パッチ。メンテナンスには、インスタンスのセキュリティ、パフォーマンス、信頼性を向上させる Valkey の更新が含まれる場合があります。これは、OSS Valkey が提供する機能を超えています。
クライアント アプリケーションを構成する
メンテナンス中にクライアント アプリケーションのパフォーマンスと可用性を最適化するには、次の操作を行います。
- Valkey クライアントのベスト プラクティスのガイダンスに沿ってサードパーティ クライアントを使用および構成し、スケジュール設定されたメンテナンスがクライアント アプリケーションに影響しないようにします。推奨されるクライアント構成では、定期的なインライン トポロジの更新とバックグラウンドでの接続のローテーションにより接続のリセットを回避できます。
- プライマリ ノードとレプリカノードで代表的なワークロードを実行しながら、一連の更新オペレーション（スケールイン、スケールアウト、レプリカ数の変更など）でクライアント アプリケーションをテストし、クライアントへの影響をモニタリングします。これらの更新により、クライアントのインライン トポロジ更新ロジック、完全同期の影響、新しいノードの検出、既存のノードの削除機能がテストされます。テストにより、サードパーティ クライアントが正しく構成されていることを確認し、アプリケーションへの悪影響を回避できます。
クラスタモードが無効になっているインスタンス
メンテナンス中に、クラスタモードが無効になっているインスタンスがフェイルオーバーを実行し、接続がリセットされます。このフェイルオーバーは通常 15 秒間続きます。フェイルオーバー後にクライアント アプリケーションをインスタンスに再接続するには、指数バックオフを使用する再試行メカニズムを作成することをおすすめします。今後のメンテナンスを通知するメールが届いたら、非本番環境インスタンスでシミュレートされたメンテナンスを実行して、メンテナンスがインスタンスに与える影響をテストできます。詳細については、インスタンスでメンテナンス シミュレーションを実行するをご覧ください。
また、定期メンテナンスの開始時に /instance/memory/maximum_utilization 指標を 50% 以下に保つことをおすすめします。この指標のガイダンスでは、メモリ管理のしきい値が 80% となっています。ただし、メンテナンス中は 50% 以下の比率を目標にすることをおすすめします。指標の詳細については、Cloud Monitoring の指標をご覧ください。
この比率は、次のいずれかの方法で確保できます。
- インスタンスのトラフィックが少ない時間帯にメンテナンスをスケジュール設定する。
- メンテナンスの時間枠でインスタンスのサイズを一時的にスケールアップする。
定期メンテナンス
Memorystore for Valkey は、段階的なデプロイと create-before-destroy のライフサイクル戦略を活用して、Valkey インスタンスへの Memorystore 定期メンテナンスによるダウンタイムの影響を回避します。Memorystore for Valkey は、OSS Valkey インスタンス プロトコルのリクエスト リダイレクト機能と次の Memorystore メカニズムを使用して、ダウンタイムなしのメンテナンスを実現します。
- データを損失することなく、調整されたフェイルオーバー。
- グレースフル ノードの削除により、クライアントが可用性に影響を与えることなくノードトポロジの更新に対応できるようにする。
- インスタンスの Private Service Connect エンドポイント。メンテナンスの影響を受けません。これらのエンドポイントの詳細については、インスタンス エンドポイントをご覧ください。
以降のセクションで説明するサービスの動作は、定期メンテナンスにのみ適用されます。ハードウェア障害などの計画外のイベントの影響については、計画外のフェイルオーバー中のクライアントの動作をご覧ください。
デフォルトのメンテナンスの時間枠
デフォルトでは、Memorystore は、インスタンスのタイムゾーンに応じて、次の時間枠でインスタンスを更新します。
- 平日（月～金）: 午後 10 時～午前 6 時
- 週末: 金曜日の午後 10 時～月曜日の午前 6 時
段階的なデプロイ戦略
Memorystore for Valkey は、スコープを段階的に拡大しながらデプロイを実行します。また、障害を早期に検出して影響を軽減し、安定性を確保できる速度でデプロイを実行します。ベイク時間（更新が適用され、成功と見なされて次に進む前にモニタリングされる時間）は、サービス規模で Memorystore のインスタンス フリート全体に統合されます。さらに、ベイク時間はリージョン内のゾーン（複数の障害ドメイン）にまたがるインスタンスに統合され、影響の範囲を縮小します。
高可用性向けに構成されたインスタンスの場合、Memorystore for Valkey は常に最大 1 つのフォールト ドメインまたはゾーンを更新します。これは、更新全体を通して、プライマリとレプリカの両方を含むインスタンス シャードの高可用性を確保します。さらに、Memorystore for Valkey は一度に数個のノードのみを更新します。更新では、インスタンスの安定性を最大化するために、create-before-destroy のライフサイクル メカニズムを使用します。この戦略は、多数のシャードを含むインスタンスを更新する場合に最も効果的です。常にユーザー キースペース全体の一部にのみ更新を適用することで、データの可用性を最大化します。
create-before-destroy ライフサイクル戦略
Valkey インスタンスには複数のシャードがあります。各シャードには、1 つのプライマリ ノードと 0 個以上のレプリカノードがあります。Memorystore は、次のプロセスを使用して、シャード内の既存のプライマリ Valkey ノードまたはレプリカ Valkey ノードを更新します。
- Memorystore for Valkey は、最新のソフトウェア アップデートを含む新しいレプリカをシャードに追加します。Memorystore は、既存のノードを更新するのではなく、新しいノードを作成します。これにより、予期しないブートストラップ障害が発生した場合でも、プロビジョニングされた容量が保持されます。
- 更新対象のシャード内のノードがプライマリ ノードの場合、プライマリ ノードは、協調フェイルオーバーを使用してノードを削除する前に、まずレプリカに変換されます。
- Memorystore は、以前のソフトウェアを使用するレプリカを削除します。
- Memorystore は、インスタンス内のノードごとにこのプロセスを繰り返します。
create-before-destroy 戦略では、インプレースで更新する一般的なローリング デプロイと比較すると、インスタンスのプロビジョニングされた容量を保持できますが、クライアント アプリケーションの可用性が停止する（場合によってはデータ損失）ことになります。レプリカのないシャードの場合、Memorystore for Valkey はまず新しいレプリカをプロビジョニングし、フェイルオーバーを調整して、最後にシャードの既存のプライマリ ノードを置き換えます。
ステップ 1: レプリカを追加する
create-before-destroy メカニズムの最初のステップでは、完全同期 OSS Valkey メカニズムを使用して、最新のソフトウェアでレプリカノードを追加し、プライマリからレプリカノードにデータをコピーします。これは、子プロセスをフォークし、ディスクレス レプリケーションを利用してレプリカをブートストラップすることで行われます。Memorystore for Valkey は、ディスクレス レプリケーションをサポートしています。永続性を有効にしない限り、Memorystore for Valkey はレプリケーション中にディスクを使用しません。
ノード内のキースペース サイズを縮小するために、より多くのシャードをプロビジョニングすることで、インスタンスの水平スケール アーキテクチャを最大限に活用できます。ノードあたりのデータセットを小さくすると、完全同期オペレーションのフォーク レイテンシの影響を軽減できます。また、ノード間でのデータのコピーも高速化されます。
ステップ 2: 調整されたプライマリ フェイルオーバーを実行する
更新が必要な Valkey ノードがプライマリ ノードの場合、Memorystore は新しく追加されたレプリカノードへの協調フェイルオーバーを実行します。その後、Memorystore はノードを削除します。協調フェイルオーバー中、クライアントと Valkey ノードは連携して、次の戦略を使用してアプリケーションのダウンタイムを回避します。
- 受信したクライアント リクエストはプライマリ ノードで一時的にブロックされ、既存のレプリカがプライマリ ノードと 100% 同期されるようにするためのウィンドウが提供されます。
- レプリカが選出プロセスを完了してプライマリ ロールを引き継ぎます。
- 以前のプライマリ ノード（現在はレプリカノード）は、既存のリクエストのブロックを解除し、OSS Valkey インスタンス プロトコルを使用してリクエストを新しいプライマリ ノードにリダイレクトします。以前のレプリカノードに送信された新しいリクエストは、引き続き新しいプライマリ ノードにリダイレクトされます。
- Valkey 対応クライアントがインメモリ トポロジを更新します。新しいプライマリ エンドポイントのアドレスを学習するため、リダイレクトの必要がなくなります。
調整されたフェイルオーバーには、通常、数十ミリ秒かかります。ただし、レプリカにフラッシュされるのを待機している処理中のデータとインスタンスの合計サイズによって、フェイルオーバーのレイテンシが増加する可能性があります。インスタンス サイズは、プライマリ ノード間の収束に影響する可能性があります。これは、新しいプライマリ ノードの選出に関する意思決定に影響します。
ステップ 3: レプリカを削除する
create-before-destroy メカニズムの最後のステップでは、以前のソフトウェアのレプリカノードを削除します。Memorystore for Valkey がクライアントをドロップするため、ノードの削除はクライアント アプリケーションに影響します。トポロジの更新はクラスタモードが無効なインスタンスには適用されないため、指数バックオフを使用する再試行メカニズムを使用して、新しいレプリカ エンドポイントが使用可能になった後にアプリケーションを再接続することをおすすめします。
クラスタモードが有効なインスタンスの場合、Memorystore for Valkey は、Valkey レプリカの削除を正常に処理するように設計されています。これにより、クライアント アプリケーションは、ハードノードのシャットダウンが発生する前にトポロジを更新できます。トポロジは、クライアントが新しいレプリカを認識できるようにカスタマイズされていますが、削除されるレプリカを事前に忘れることもできます。
Memorystore for Valkey は、以前のソフトウェアを実行しているレプリカノードを、通常は数分単位の特定のドレイン期間にわたって保持します。この期間中に、受信した読み取りリクエストをシャードのプライマリ ノードにリダイレクトし始めます。このプロセスにより、サードパーティ クライアントはノードトポロジを更新し、新しいレプリカ エンドポイントを認識できるようになります。ドレイン期間の経過後にクライアントが削除されたノードにアクセスしようとすると、失敗します。この失敗により、接続するクライアントでノードトポロジの更新がトリガーされ、レプリカの変更が認識されます。ノード トポロジの新しい更新では、削除されるレプリカノードは表示されません。
メンテナンスの設定
Memorystore for Valkey では、アプリケーションのニーズに合わせてメンテナンス スケジュールをカスタマイズし、中断を最小限に抑えることができます。メンテナンス スケジュールをカスタマイズするには、インスタンスのメンテナンスの時間枠を構成します。
メンテナンスの時間枠は、Memorystore for Valkey インスタンスごとに設定します。次の構成オプションがあります。
- 曜日: メンテナンスが実施される曜日
- 開始時間: メンテナンスの開始時間
メンテナンスの時間枠は 1 時間です。場合によっては、メンテナンスが選択した時間枠を超えて延長されることがあります。
インスタンスのメンテナンスの時間枠を構成すると、Memorystore for Valkey は、メンテナンスの時間枠に設定した設定に従って、将来の自動メンテナンスをスケジュールします。
デフォルトのメンテナンスの時間枠
メンテナンスの時間枠を設定しない場合、Memorystore for Valkey は、インスタンスのタイムゾーンに応じて、次のいずれかの時間枠でインスタンスを更新します。
- 平日（月～金）: 午後 10 時～午前 6 時
- 週末: 金曜日の午後 10 時～月曜日の午前 6 時
メンテナンスの例
小売店のショッピング カート サービスを管理するデベロッパーは、Memorystore for Valkey インスタンスを含む本番環境を管理します。メンテナンス中のパフォーマンスを最適化するには、インスタンスのトラフィックが最小になる時間帯にメンテナンスをスケジュールします。これは通常、日曜日の深夜 0 時頃に発生します。
この場合、本番環境インスタンスのメンテナンスの時間枠を次の日時に設定します。
- 曜日: 日曜日
- 開始時間: 午前 1 時
今後のメンテナンスに関する通知
インスタンスのメンテナンス イベントに関する情報を常に把握できるように、メンテナンスがスケジュールされている少なくとも 1 週間前に、今後のメンテナンスに関するメール通知を設定します。これらの通知の件名は "Upcoming
maintenance for your Cloud Memorystore instance [your-instance-name]" です。
Memorystore for Valkey は、インスタンスのメンテナンスが開始されるときにも通知を送信します。メールの件名は "Maintenance
is undergoing for your Cloud Memorystore instance [your-instance-name]" です。
Memorystore for Valkey は、メンテナンスが完了すると、完了通知を送信します。メールの件名は "Completed Maintenance
for your Cloud Memorystore instance [your-instance-name]" です。
Memorystore for Valkey がメンテナンスのスケジュールを変更すると、メンテナンスのキャンセルを通知するメールが届きます。このメールの件名は "Canceled maintenance for your Cloud Memorystore instance [your-instance-name]" です。
メンテナンス通知を受け取るには、オプトインする必要があります。メンテナンス通知に登録する手順は次のとおりです。
Memorystore for Valkey からメンテナンス通知を受け取るには、インスタンスのメンテナンス更新がスケジュールされる少なくとも 1 週間前に、次の手順を完了します。そうしないと、Memorystore for Valkey から今後のメンテナンスに関する通知を送信する時間までに通知の登録が完了しなかったことになります。
Memorystore for Valkey は、Google アカウントに関連付けられているメールアドレスに通知を送信します。カスタムのメール エイリアス（チームのメール エイリアスなど）を構成することはできません。また、別のメールアドレスへの通知の送信はサポートされていません。
メンテナンス通知に登録すると、 Google Cloud プロジェクト内でメンテナンスがスケジュールされているすべての Memorystore for Valkey インスタンスに関するアラートを受け取ります。インスタンスごとに個別の通知が届きます。
定期メンテナンスの確認方法については、定期メンテナンスを確認するをご覧ください。
メンテナンス スケジュールの再設定
このセクションでは、メンテナンスのスケジュールを変更する方法について説明します。たとえば、現在のメンテナンスの時間枠中に新しいサービスをリリースする予定がある場合は、メンテナンスの時間枠をリリースの数日後に延期することをおすすめします。
メンテナンスのスケジュールは、元のスケジュール日時から 14 日以内であれば変更できます。[メンテナンスのスケジュール変更] の一環として、次のいずれかのオプションを選択します。
- 今すぐ更新: 定期メンテナンスの時間枠を待つのではなく、更新をすぐにインスタンスに適用できます。
- カスタムの日時: 元の定期メンテナンス時刻から 14 日以内の任意の時間を選択します。
メンテナンスのスケジュールを変更する場合、次の制限が適用されます。
- 現在の定期メンテナンスまでの時間が 1 時間未満の場合、メンテナンスのスケジュールを変更することはできません。
- メンテナンスのスケジュールを再設定すると、Memorystore for Valkey からメール通知が届き、以前のメンテナンスのキャンセルが確認されます。また、更新されたスケジュールが記載された新しいメンテナンス通知が届きます。
メンテナンスのスケジュール変更の詳細については、メンテナンスのスケジュールを変更するをご覧ください。
よくある質問
このセクションでは、Memorystore for Valkey のメンテナンスに関するよくある質問（FAQ）を紹介します。
インスタンスのメンテナンスがいつスケジュールされているかを確認するにはどうすればよいですか？
インスタンスのメンテナンスがスケジュールされる時期を確認するには、通知を登録してメンテナンスの時間枠を構成することをおすすめします。maintenanceSchedule パラメータがレスポンスに表示されるかどうかを手動で確認することもできます。
Memorystore for Valkey が今後のメンテナンスについて通知するのはいつですか？
メンテナンス通知に登録してメンテナンスの時間枠を設定すると、メンテナンス イベントの 1 週間前までに Memorystore for Valkey からメールで通知が届きます。
メンテナンスはいつまで延期できますか？
インスタンスのメンテナンスをスケジュールすると、インスタンスの更新をすぐに開始するか、最初にスケジュールされたメンテナンス日時から最大 2 週間更新を延期できます。
たとえば、10 月 11 日午後 11 時 15 分にメンテナンスをスケジュールした場合、10 月 25 日午後 11 時 15 分までメンテナンスを延期できます。何も操作を行わない場合、メンテナンスはスケジュールされた日時に実行されます。
詳細については、メンテナンスのスケジュールを変更するをご覧ください。
メンテナンス更新をスムーズに行うためのベスト プラクティスを教えてください。
メンテナンス更新をスムーズに行うために、次のことをおすすめします。
- 手順に沿ってクライアント アプリケーションを構成します。
- インスタンスのトラフィックが最小になる日時（日曜日の深夜など）にメンテナンスの時間枠を設定します。
- メンテナンス通知をオンにする。その結果、Memorystore for Valkey は、インスタンスのメンテナンス更新がスケジュールされる少なくとも 7 日前にメールで通知します。
- アプリケーションの使用に影響が少ない時間帯や影響がない時間帯がない場合は、段階的なロールアウトのサービス デフォルトを使用します。このデフォルトには、メンテナンス更新のベスト プラクティスが含まれています。詳しくは、定期メンテナンスをご覧ください。
メンテナンス アップデートを直ちに適用すべきタイミングは？
テスト インスタンスにメンテナンス更新をすぐに適用して、更新がアプリケーションに与える影響を確認できます。この更新による影響を観察できます。更新に問題がある場合は、問題が解決するまで本番環境インスタンスのメンテナンスを延期できます。
現在の曜日と時刻がインスタンスに適していて、今後インスタンスに高い負荷が予想される場合は、メンテナンス更新をすぐに実行できます。
メンテナンスの更新は常にメンテナンスの時間枠内に完了していますか？
Memorystore for Valkey は、指定したメンテナンスの時間枠内でメンテナンス更新を開始します。Memorystore for Valkey は通常、時間枠内で更新を完了しますが、常にそうなるとは限りません。
メンテナンスをオプトアウトしたり、特定のインスタンスのメンテナンスを先にスケジュールしたりできますか？
メンテナンスのオプトアウトや、インスタンスのメンテナンス順序の制御はできません。ただし、最初のメンテナンス通知を受け取った後、メンテナンスのスケジュールを変更して、最大 2 週間延期できます。
次のステップ
- インスタンスのメンテナンスの時間枠の管理に必要な権限を表示する。