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