メンテナンスについて

このページでは、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 アカウントに関連付けられているメールアドレスに通知を送信します。カスタムメール エイリアス(チームのメール エイリアスなど)を構成することはできません。また、別のメールアドレスに通知を送信することはできません。

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

スケジュールされたメンテナンスの検索について詳しくは、スケジュールされたメンテナンスを検索するをご覧ください。

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

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

メンテナンスのスケジュールは、最初にスケジュールされた時刻から 14 日以内に変更できます。 メンテナンスのスケジュールを変更する際は、次のいずれかのオプションを選択します。

  • 今すぐ更新: スケジュールされたメンテナンスの時間枠を待つのではなく、 更新をすぐにインスタンスに適用できます。
  • カスタムの日時: 最初にスケジュールされたメンテナンス時刻から14 日以内の任意の時刻を選択します。

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

  • 現在のスケジュールされたメンテナンス時刻まで 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 週間延期できます。

次のステップ

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