メンテナンスについて

このページでは、Memorystore for Valkey がインスタンスでメンテナンスを行う方法について説明します。また、Memorystore for Valkey のダウンタイムなしのメンテナンス設計を活用するために、クライアント アプリケーションが認識しておく必要のある情報と構成の推奨事項も提供します。これらの推奨事項は、高可用性インスタンスとレプリカのないインスタンスの両方に適用されます。ただし、すべての本番環境のユースケースでは、高可用性構成を使用することを強くおすすめします。

Memorystore for Valkey はインスタンスを定期的に更新し、サービスの信頼性、パフォーマンス、セキュリティ、最新性を確保します。こうした更新はメンテナンスと呼ばれます。 メンテナンスはサービスによって完全に管理され、ダウンタイムの影響がゼロになるように設計されています。

メンテナンスは通常、以下のカテゴリに分類されます。

  • Memorystore の機能。Memorystore の機能の中には、起動するためにメンテナンス更新が必要なものがあります。
  • オペレーティング システムのパッチ。Google では、オペレーティング システムに存在する新たなセキュリティ脆弱性を継続的に監視しています。こうした脆弱性が見つかると、オペレーティング システムにパッチを適用し、新たなリスクからシステムを保護します。
  • データベース パッチ。メンテナンスには、インスタンスのセキュリティ、パフォーマンス、信頼性を向上させるための Valkey の更新が含まれる場合があります。これは、OSS Valkey が提供する範囲を超えています。

クライアント アプリケーションを構成する

メンテナンス中に最適なパフォーマンスと可用性を実現するようにクライアント アプリケーションを構成する手順は次のとおりです。

  1. Valkey クライアントのベスト プラクティスのガイダンスに沿ってサードパーティ クライアントを使用および構成し、定期メンテナンスがクライアント アプリケーションに影響しないようにします。推奨されるクライアント構成では、定期的なインライン トポロジの更新とバックグラウンドでの接続のローテーションにより接続のリセットを回避できます。
  2. プライマリ ノードとレプリカ ノードで代表的なワークロードを実行し、クライアントへの影響をモニタリングしながら、一連の更新オペレーション(スケールイン、スケールアウト、レプリカ数の変更など)でクライアント アプリケーションをテストします。これらの更新では、クライアントのインライン トポロジ更新ロジック、完全同期の影響、新しいノードの検出、既存のノードの削除機能がテストされます。テストは、サードパーティ クライアントが正しく構成されていることを確認し、アプリケーションへの悪影響を回避するのに役立ちます。

定期メンテナンス

Memorystore for Valkey は、段階的なデプロイと create-before-destroy のライフサイクル戦略を活用して、Valkey インスタンスへの Memorystore 定期メンテナンスによるダウンタイムの影響を回避します。Memorystore for Valkey は、次の Memorystore メカニズムで OSS Valkey インスタンス プロトコルのリクエスト リダイレクト機能を使用して、ダウンタイムのないメンテナンスを実現します。

  1. データ損失のない調整されたフェイルオーバー。
  2. グレースフル ノードの削除により、クライアントが可用性に影響を与えることなくノードトポロジの更新に対応できるようにします。
  3. インスタンスの 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 ノードを更新します。

  1. Memorystore for Valkey は、最新のソフトウェア アップデートを含む新しいレプリカをシャードに追加します。Memorystore は、既存のノードを更新するのではなく、新しいノードを作成します。これは、予期しないブートストラップ エラーが発生した場合に、プロビジョニングされた容量が保持されるようにするためです。
  2. 更新するシャード内のノードがプライマリ ノードの場合、調整されたフェイルオーバーを使用してノードを削除する前に、プライマリ ノードがレプリカに変換されます。
  3. Memorystore は、以前のソフトウェアを使用するレプリカを削除します。
  4. Memorystore は、インスタンス内の各ノードに対してこのプロセスを繰り返します。

create-before-destroy 戦略では、インプレースで更新する一般的なローリング デプロイと比較すると、インスタンスのプロビジョニングされた容量を保持できますが、クライアント アプリケーションの可用性が停止する(場合によってはデータ損失)ことになります。レプリカのないシャードの場合でも、Memorystore for Valkey は最初に新しいレプリカをプロビジョニングし、フェイルオーバーを調整してから、シャードの既存のプライマリ ノードを置き換えます。

ステップ 1: レプリカを追加する

create-before-destroy メカニズムの最初のステップでは、完全同期 OSS Valkey メカニズムを使用して、最新のソフトウェアでレプリカノードを追加し、プライマリからレプリカノードにデータをコピーします。これは、子プロセスをフォークし、ディスクレス レプリケーションを利用してレプリカをブートストラップすることで行われます。Memorystore for Valkey はディスクレス レプリケーションをサポートしています。永続性を有効にしない限り、Memorystore for Valkey はレプリケーション中にディスクを使用しません。

インスタンスの水平スケーリング アーキテクチャを最大限に活用するには、シャードの数を増やして、ノード内のキースペース サイズを小さくします。ノードあたりのデータセットを小さくすると、フル同期オペレーションのフォーク レイテンシの影響を軽減できます。また、ノード間のデータコピーも高速化されます。

ステップ 2: 調整されたプライマリ フェイルオーバーを実行する

更新が必要な Valkey ノードがプライマリ ノードの場合、Memorystore は新しく追加されたレプリカノードに対して調整されたフェイルオーバーを実行します。その後、Memorystore はノードを削除します。協調フェイルオーバー中、クライアントと Valkey ノードは連携して動作し、次の戦略を使用してアプリケーションのダウンタイムを回避します。

  1. プライマリ ノードで受信クライアント リクエストが一時的にブロックされ、既存のレプリカがプライマリ ノードと 100% 同期されるまでの期間が確保されます。
  2. レプリカは選挙プロセスを完了して、プライマリ ロールを引き継ぎます。
  3. 以前のプライマリ ノード(現在はレプリカノード)は、既存のリクエストのブロックを解除し、OSS Valkey インスタンス プロトコルを使用してリクエストを新しいプライマリ ノードにリダイレクトします。以前のレプリカノードに送信された新しいリクエストは、引き続き新しいプライマリ ノードにリダイレクトされます。
  4. Valkey 対応のクライアントがインメモリ トポロジを更新します。新しいプライマリ エンドポイントのアドレスを学習するため、リダイレクトの必要がなくなります。

通常、協調フェイルオーバーには数十ミリ秒かかります。ただし、レプリカにフラッシュされるのを待機している処理中のデータとインスタンスの合計サイズによって、フェイルオーバー レイテンシが増加する可能性があります。インスタンス サイズはプライマリ ノード間のコンバージェンスに影響する可能性があり、新しいプライマリ ノードの選択に関する意思決定に影響します。

ステップ 3: レプリカを削除する

create-before-destroy メカニズムの最後のステップは、以前のソフトウェアのレプリカノードを削除することです。ノードを突然削除すると、クライアント アプリケーションに影響します。これは、クライアントがエンドポイント情報とインスタンス トポロジをキャッシュに保存するためです。Memorystore for Valkey は、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]" です。

メンテナンス通知を受け取るには、メンテナンス通知を有効にする必要があります。メンテナンス通知に登録する手順は次のとおりです。

  1. メンテナンスの時間枠を設定します
  2. メンテナンス通知を受け取るように設定する

Memorystore for Valkey からメンテナンス通知を受け取るには、インスタンスのメンテナンス更新の 1 週間前までに、次の手順を完了します。そうしないと、Memorystore for Valkey は今後のメンテナンスを通知するのに十分な時間を確保できません。

Memorystore for Valkey は、Google アカウントに関連付けられているメールアドレスに通知を送信します。チームのメール エイリアスなどのカスタムメール エイリアスは構成できません。また、別のメールアドレスに通知を送信することはできません。

メンテナンス通知に登録すると、 Google Cloud プロジェクト内でメンテナンスがスケジュールされているすべての Memorystore for Valkey インスタンスのアラートが届きます。インスタンスごとに個別の通知が届きます。

定期メンテナンスを検索する方法については、定期メンテナンスを検索するをご覧ください。

メンテナンス スケジュールの再設定

このセクションでは、メンテナンスのスケジュールを変更する方法に関するガイドラインを示します。たとえば、現在のメンテナンスの時間枠中に新しいサービスをリリースする場合は、メンテナンスの時間枠をリリースの数日後に延期することをおすすめします。

メンテナンスのスケジュールは、元のスケジュール日時から 14 日以内であれば変更できます。メンテナンスのスケジュール変更の一環として、次のいずれかのオプションを選択します。

  • 今すぐ更新: 定期メンテナンスの時間枠を待つのではなく、更新をすぐにインスタンスに適用できます。
  • [カスタムの日時] - 元の定期メンテナンス時刻から 2 週間以内の任意の時間を選択します。

メンテナンスのスケジュールを変更する場合、次の制限が適用されます。

  • 現在予定されているメンテナンス時刻まで 1 時間を切っている場合、メンテナンスのスケジュールを変更することはできません。
  • メンテナンスのスケジュール変更が完了すると、Memorystore for Valkey からメール通知が送信され、以前のメンテナンスがキャンセルされたことが確認されます。また、更新されたスケジュールが記載された新しいメンテナンス通知が届きます。

メンテナンスのスケジュール変更の詳細については、メンテナンスのスケジュールを変更するをご覧ください。

よくある質問

このセクションでは、Memorystore for Valkey のメンテナンスに関するよくある質問(FAQ)を紹介します。

インスタンスのメンテナンスがいつスケジュールされているかを確認するにはどうすればよいですか?

インスタンスのメンテナンスがスケジュールされる時期を確認するには、通知を登録してメンテナンスの時間枠を構成することをおすすめします。インスタンスを手動で確認して、maintenanceSchedule パラメータがレスポンスに表示されるかどうかを確認することもできます。

Memorystore for Valkey は、今後のメンテナンスについていつ通知しますか?

メンテナンス通知に登録してメンテナンスの時間枠を設定すると、Memorystore for Valkey はメンテナンス イベントの 1 週間以上前にメールで通知します。

メンテナンスはいつまで延期できますか?

インスタンスのメンテナンスをスケジュールした後、インスタンスの更新をすぐに開始するか、最初にスケジュールされたメンテナンスの日時から最大 2 週間まで更新を延期できます。

たとえば、10 月 11 日午後 11 時 15 分にメンテナンスをスケジュールした場合、10 月 25 日午後 11 時 15 分までメンテナンスを延期できます。何も対応しない場合、メンテナンスはスケジュールされた日時に実行されます。

詳細については、メンテナンスのスケジュールを変更するをご覧ください。

メンテナンス更新をスムーズに行うためのベスト プラクティスはどれですか?

スムーズなメンテナンス更新を有効にするために、次のアクションを行うことをおすすめします。

  1. 手順に沿ってクライアント アプリケーションを構成します。
  2. インスタンスのトラフィックが最小限になる日時(日曜日の深夜など)にメンテナンスの時間枠を設定します。
  3. メンテナンス通知を受け取るようにオプトインする。これにより、Memorystore for Valkey は、インスタンスのメンテナンス更新がスケジュールされている 7 日前までにメールで通知します。
  4. アプリケーションの使用状況に影響の少ない時間帯がない場合は、サービスのデフォルトである段階的ロールアウトを使用します。このデフォルトには、メンテナンス アップデートのベスト プラクティスが含まれています。詳しくは、定期メンテナンスをご覧ください。

メンテナンスを直ちに適用できるのはどのような場合ですか?

メンテナンス更新をテスト インスタンスに直ちに適用して、更新がアプリケーションに与える影響を確認できます。この更新による影響を確認できます。更新に問題がある場合は、問題を解決するまで本番環境インスタンスのメンテナンスを延期できます。

現在の日時がインスタンスに適していて、今後インスタンスに高負荷がかかることが予想される場合は、メンテナンス アップデートをすぐに実行できます。

メンテナンスの更新は常にメンテナンスの時間枠内に完了していますか?

Memorystore for Valkey は、指定したメンテナンスの時間枠内でメンテナンスの更新を開始します。通常、Memorystore for Valkey は時間枠内で更新を完了しますが、常にそうなるわけではありません。

メンテナンスをオプトアウトしたり、特定のインスタンスのメンテナンスを先にスケジュールしたりできますか?

インスタンスのメンテナンスをオプトアウトしたり、メンテナンスの順序を制御したりすることはできません。ただし、最初のメンテナンス通知を受け取った後、メンテナンスのスケジュールを変更して、最大 2 週間延期することは可能です。

次のステップ

  • インスタンスのメンテナンス時間枠の管理に必要な権限を表示する。