メンテナンスについて

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

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

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

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

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

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

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

定期メンテナンス

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

データ損失のない調整されたフェイルオーバー
グレースフルノードの削除により、クライアントが可用性に影響を与えることなくノードトポロジの更新に対応できるようにする
インスタンスの PSC エンドポイントはメンテナンスの影響を受けない。PSC エンドポイントの詳細については、インスタンスエンドポイントをご覧ください。

次のセクションで説明するサービスの動作は、定期メンテナンスにのみ適用されます。ハードウェア障害などの計画外のイベントの影響については、計画外のフェイルオーバー時のクライアントの動作をご覧ください。

デフォルトのメンテナンスの時間枠

デフォルトでは、Memorystore はインスタンスのタイムゾーンに応じて、次の時間枠でインスタンスを更新します。

平日（月～金）: 午後 10 時～午前 6 時
週末: 金曜日の午後 10 時～月曜日の午前 6 時

段階的デプロイ戦略

Memorystore for Valkey のデプロイは、影響を軽減し、安定性の信頼性を確立するために、早期の障害検出を可能にする速度で、対象範囲を徐々に広げて実行されます。ベイク時間（更新が適用され、更新が成功と判断されて進む前にモニタリングされる時間）は、サービススケールで Memorystore のインスタンスフリート全体に統合されます。さらに、ベイク時間は、リージョン内のゾーン（複数の障害ドメイン）にまたがるインスタンス内に統合され、存在する場合は影響の範囲を狭めることができます。

高可用性向けに構成されたインスタンスの場合、常に最大 1 つのフォールトドメイン / ゾーンが更新されます。これは、更新全体を通して、プライマリとレプリカの両方を含むインスタンスシャードの高可用性を確保します。また、常に少数の Valkey ノードのみが更新されます。更新では、インスタンスの安定性を最大化するために、create-before-destroy のライフサイクルメカニズムを使用します。この方式は、多数のシャードを持つインスタンスを更新する場合に最も効果的です。常にユーザーキースペース全体のごく一部にのみ更新を適用すると、データの可用性が最大化されます。

Create-Before-Destroy ライフサイクル戦略

Valkey インスタンスには複数のシャードがあります。各シャードには、1 つのプライマリノードと 0 個以上のレプリカノードがあります。Memorystore は、次のプロセスを使用して、シャード内の既存のプライマリまたはレプリカの Valkey ノードを更新します。

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

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

手順 1: Valkey レプリカを追加する

create-before-destroy メカニズムの最初のステップでは、完全同期 OSS Valkey メカニズムを使用して、最新のソフトウェアでレプリカノードを追加し、プライマリからレプリカノードにデータをコピーします。これを行うには、子プロセスをフォークし、ディスクレスレプリケーションを活用してレプリカをブートストラップします。

より多くのシャードをプロビジョニングしてノード内のキースペースサイズを減らすことで、インスタンスの水平スケールアーキテクチャを最大限に活用できます。ノードあたりのデータセットを小さくすると、完全な同期オペレーションによるフォークレイテンシの影響を軽減できます。また、ノード間でのデータのコピーも高速化します。

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

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

受信クライアントからの要求はプライマリノードで一時的にブロックされ、既存のレプリカがプライマリと 100% 同期していることを確認するための時間枠が提供されます。
レプリカは、プライマリの役割を引き継ぐために、選出プロセスを完了します。
以前のプライマリノード（現在はレプリカ）は、既存のリクエストのブロックを解除し、OSS Valkey クラスタプロトコルを使用して、新しく選択されたプライマリにリダイレクトします。以前のレプリカノードに送信された新しいリクエストは、引き続き新しいプライマリノードにリダイレクトされます。
Valkey に適したクライアントが、メモリ内トポロジを更新します。新しいプライマリエンドポイントのアドレスを学習するため、リダイレクトの必要がなくなります。

調整されたフェイルオーバーには、通常、数十ミリ秒かかります。ただし、処理中のデータがレプリカにフラッシュされるまで保留中のため、インスタンスの合計サイズが原因でフェイルオーバーのレイテンシが増加する可能性があります。インスタンスのサイズは、プライマリノード間の収束に影響を与える可能性があります。これは、新しいプライマリの選択に関する決定に影響します。

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

create-before-destroy メカニズムの最後の手順は、以前のソフトウェアのレプリカノードを削除することです。ノードの突然の削除は、クライアントがエンドポイント情報とインスタンストポロジをキャッシュに保存するため、クライアントアプリケーションに影響します。Memorystore for Valkey では、ハードノードシャットダウンが発生する前にクライアントアプリケーションがトポロジを更新できるように、Valkey レプリカの削除を適切に行うように設計されています。トポロジは、クライアントが新しいレプリカを認識できるだけでなく、事前に削除されていたレプリカを忘れるようにカスタマイズされています。

以前のソフトウェアを実行しているレプリカノードは、一定のドレイン期間（通常は数分程度）の間維持され、その間受信読み取りリクエストのシャードのプライマリノードへのリダイレクトを開始します。これにより、サードパーティクライアントはノードトポロジを更新し、新しいレプリカエンドポイントを認識できるようになります。ドレイン期間の経過後にクライアントが削除されたノードにアクセスしようとすると、失敗します。これにより、接続するクライアントでノードトポロジの更新がトリガーされ、レプリカの変更が認識されます。ノードトポロジを新しく更新しても、削除対象のレプリカノードは表示されません。