メンテナンス ポリシー

このページでは、Memorystore for Memcached のメンテナンスの概要について説明します。

メンテナンスの時間枠のスケジュールについては、メンテナンスの時間枠の検索と設定をご覧ください。

概要

Memorystore for Memcached はインスタンスを定期的に更新し、サービスの信頼性、パフォーマンス、セキュリティ、最新性を確保します。これらの更新のほとんどは、Memcached インスタンスの稼働中に行われます。ただし、一部のシステム更新では短時間サービスの中断が必要になります。 こうした更新はメンテナンスと呼ばれます。メンテナンスは通常、以下のカテゴリに分類されます。

  • Memorystore の機能。Memorystore の機能の中には、起動するためにメンテナンス更新が必要なものがあります。

  • オペレーティング システムのパッチ。Google では、オペレーティング システムに存在する新たなセキュリティ脆弱性を継続的に監視しています。こうした脆弱性が見つかると、オペレーティング システムにパッチを適用し、新たなリスクからシステムを保護します。

  • データベースのバージョン アップグレード。メンテナンスには、互換性を破る変更や互換性のない変更を含まない OSS Redis パッチのマイナー バージョン アップデートが含まれます。

ユーザーには、メンテナンスを実行する 2 つの方法があります。自動と手動です。メンテナンスの時間枠機能を使用すると、ユーザーはメンテナンスを自動的にスケジューリングして実行できる繰り返しの時間枠を指定できます。インスタンスのメンテナンスをより細かく制御したいユーザーの場合は、手動メンテナンスが、希望するスケジュールとロジックに基づいてインスタンスを更新するための gcloud インターフェースを提供します。

メンテナンスの影響

メンテナンス中、Memorystore for Memcached クラスタでは接続の切断とキャッシュの完全なフラッシュが発生します。

クラスタ内のノードは、メンテナンスの時間枠全体にわたり、順次かつ均等に更新されます。ノードが更新されると、キャッシュはフラッシュされ、メンテナンスの後でデータは復元されません。通常、ダウンタイムはノードあたり 5 分程度です。

ノードでメンテナンスが行われると、そのノードの接続は切断され、リセットされます。メンテナンスの発生後にアプリケーションをノードに再接続するには、指数バックオフを使用する再試行メカニズムを作成する必要があります。

手動メンテナンスを選択したユーザーの場合は、クラスタの個々のノードの更新タイミングを制御します。

メンテナンスの設定

Memorystore では、アプリケーションに最適なタイミングでメンテナンスが行われるように構成できます。これを行うには、メンテナンスの時間枠を構成します。

メンテナンスの時間枠は Memorystore インスタンスごとに設定され、次の構成オプションを使用できます。

  • 曜日。 メンテナンスが発生する日を指定します。
  • 開始時間。メンテナンスの開始時間。
  • 期間。メンテナンスの時間枠の長さ。3 時間から 8 時間まで。

インスタンスでメンテナンスの時間枠が構成されている場合、将来の自動メンテナンスはこれらを優先するようにスケジューリングされます。インスタンスにメンテナンスの時間枠が指定されていない場合、メンテナンスは事前通知なしでいつでも開始できます。

メンテナンスの例

ショッピング カート サービスを管理する小売業の開発者を例に考えてみましょう。ここでは、本番環境用の Memorystore for Memcached インスタンスが 1 つあります。インスタンスのトラフィック処理量が最も少ない時間帯(日曜日の深夜 0 時頃)にメンテナンスを行いたいと考えています。

この場合、本番環境のインスタンスのメンテナンスを次のように設定します。

  • 曜日。 Sunday
  • 開始時間。1 AM
  • 期間。3 hours

この例では、許容される最短期間を選択しています。これにより、トラフィックの少ない期間中にメンテナンスが実行されます。定常的な 24 時間 365 日のトラフィックがあるアプリケーションの場合は、キャッシュのフラッシュの影響を均等に分散するため、より長い期間を指定することをおすすめします。サービスへの影響に特に鋭敏なアプリケーションの場合は、手動でメンテナンスを実行することをおすすめします。

今後のメンテナンスに関する通知

メンテナンスが予定されている少なくとも 1 週間前に、今後のメンテナンスに関する通知をメールで受け取るよう設定できます。通知のメールフィルタを設定する場合、メールのタイトルは "Upcoming maintenance for your Cloud Memorystore instance [your-instance-name]" です。

メンテナンス通知は、デフォルトでは送信されません。今後の中断を伴うメンテナンス更新に関する通知を受け取るには、次の両方を行う必要があります。

  1. メンテナンスの時間枠を設定します
  2. メンテナンス通知をオプトインする

通知は Google アカウントに関連付けられているメールアドレスに送信されます。チームのメール エイリアスなどのカスタムメール エイリアスは構成できません。また、お客様自身のもの以外の別のメールアドレスを登録することもできません。

登録すると、特定のプロジェクト内でメンテナンスの時間枠が設定されているすべての Memorystore インスタンスのメンテナンス通知にオプトインします。インスタンスごとに 1 つの通知が届きます。

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

メンテナンスのスケジュール変更

インスタンスのメンテナンスの時間枠が設定されている場合、メンテナンスが現在スケジュールされている時刻以前に、いつでもメンテナンスのスケジュールを変更できます。たとえば、現在スケジュールされているメンテナンス時間内に新しいサービスをリリースする場合は、メンテナンスの時間枠をリリースの数日後に変更することをおすすめします。

元のスケジュール日時から 1 週間以内であれば、メンテナンスのスケジュールを複数回変更できます。 新しいメンテナンスの時間枠には、次のようなスケジュールのオプションがあります。

  • 今すぐ更新定期メンテナンスの時間枠を待つのではなく、更新をすぐにインスタンスに適用できます。

  • 次の予定時間枠まで延期します。これにより、メンテナンスが 1 週間延期されます。

  • カスタムの日時このオプションでは、当初スケジュールされていたメンテナンス時刻の 1 週間以内の特定の時間を選択できます。

メンテナンスのスケジュール変更による追加の動作は次のとおりです。

  • 現在の定期メンテナンスまでの時間が 1 時間未満の場合、メンテナンスのスケジュールを変更することはできません。

  • 1 回のオペレーションで複数の Memcached インスタンスのスケジュールを変更することはできません。個別にスケジュールを変更する必要があります。

メンテナンスのスケジュールを変更する手順については、計画的なメンテナンスのスケジュールを変更するをご覧ください。

おすすめの方法

  • メンテナンスの時間枠を設定し、すべての本番環境のインスタンスの通知に登録します。
  • 適切な期間を選択します。ノードは、指定された期間にわたり順次更新されます。長い期間を選択すると、ノード キャッシュのフラッシュが長期間にわたって分散され、アプリケーションへの影響が少なくなります。ただし、短い期間を選択すると、更新をより迅速に完了できます。これは、トラフィック期間が短いアプリケーションやキャッシュ中断の影響を受けやすいアプリケーションに適しています。
  • 定期メンテナンス時に [システム メモリ使用率] 指標が 50% 以下になるように対策を講じます。これを行うには、インスタンスのトラフィックが少ない時間のスケジュールを設定するか、メンテナンスの時間枠でインスタンス サイズを一時的にスケールアップして、システム メモリ使用率の指標が 50% 以下になるようにします。
  • 指数バックオフで再試行メカニズムを実装し、メンテナンス後にアプリケーションをインスタンスに再接続します。
  • 更新が利用可能になったら、再スケジュール機能を使用して、非本番環境インスタンスで更新をテストします。

手動メンテナンス

メンテナンスの時間枠による自動メンテナンスは、大部分の Memorystore ユーザーの要件を満たすことを想定していますが、手動メンテナンスにはインスタンスを更新するための gcloud インターフェースが用意されています。このインターフェースを使用すると、アプリケーションに最適な速度と時間でクラスタノードを個別に更新できます。gcloud インターフェースの呼び出しによって各ノードが更新されると、個々のノード キャッシュがフラッシュされ、自動メンテナンスと同様に接続が切断されます。

手動メンテナンスを実行するには、まず、インスタンスのメンテナンスの時間枠を設定し、メンテナンス通知に登録する必要があります。更新が利用可能になると、インスタンスの定期メンテナンス時間が記載されたメール通知が送信されます。この時点で、インスタンスへの更新の手動適用を開始できます。Memorystore for Memcached クラスタが定期メンテナンスまでに完全に更新されない場合、残りのクラスタノードがメンテナンスの時間枠内に自動的に更新されます。定期メンテナンスの時間枠より前にインスタンスを完全に更新した場合、定義したメンテナンスの時間枠内にあるインスタンスには影響しません。

よくある質問

Memorystore for Memcached のメンテナンス ポリシーに関するよくある質問は次のとおりです。

Memcached インスタンスのメンテナンスによる影響はどのようなものですか?

メンテナンス中は、クラスタ内のノードがメンテナンスの時間枠で順次更新されます。各ノードでは、キャッシュ フラッシュが実行されます。ダウンタイムはノードあたり約 5 分です。影響について詳しくは、メンテナンスの影響をご覧ください。

メンテナンスによる更新にかかる時間はどのくらいですか?

ウィンドウの期間は 3~8 時間の間でユーザーが構成できます。ノードの更新は、指定された期間にわたり均等に実行されます。

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

インスタンスのメンテナンスがスケジュールされる時期を確認するために、通知を登録することをおすすめします。また、Cloud コンソールで手動で確認することもできます。 Cloud コンソールが空白で、メンテナンスの時間枠がすでに設定されている場合、スケジュールされた今後のメンテナンスはまだありません。

今後のメンテナンスに関する通知はいつ届きますか?

メンテナンス通知に登録していて、メンテナンスの時間枠を設定している場合は、メンテナンス イベントの 7 日前までにメールでアラートが送信されます。

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

インスタンスのメンテナンスがスケジュールされると、インスタンスはすぐに更新を開始できます。または、更新を延期(最初にスケジュールされたメンテナンス時間から最大 7 日間)できます。たとえば、10 月 11 日午後 11 時 15 分にメンテナンスがスケジュールされている場合、10 月 18 日午後 11 時 15 分まで延期できます。何もしなければ、メンテナンスはスケジュールされた時間に適用されます。

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

メンテナンス中にインスタンスの IP アドレスは変更されますか?

いいえ。Memcached インスタンスの IP アドレスは変更されません。

メンテナンスの時間枠の設定または調整はインスタンスに影響しますか?

いいえ。メンテナンスの時間枠を設定または調整しても、インスタンスのダウンタイムは一切発生しません。また、インスタンスの IP アドレスの変更や、インスタンスに対するその他の変更も行われません。

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

メンテナンスの更新については、ベスト プラクティスのセクションのガイダンスに従うことをおすすめします。

メンテナンスを直ちに適用すべきタイミングは?

メンテナンスを直ちに適用すべき状況の 1 つは、テスト インスタンス上で本番環境インスタンスへの影響を確認する場合です。計画メンテナンスのスケジュールを変更して、それをテスト インスタンスに直ちに適用できます。これにより、その影響を確認し、必要に応じて本番環境インスタンスのメンテナンスを延期できます。

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

更新は指定したメンテナンスの時間枠で開始されます。ほとんど常に、更新は時間枠内で完了します。

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

いいえ。メンテナンスのオプトアウトや、メンテナンスの初期スケジュールの制御はできません。ただし、メンテナンスのスケジュールを変更して、最大 7 日間延期することは可能です。

メンテナンスの時間枠外にも更新を適用できますか?

非常にまれですが、時間的制約のある脆弱性に対する保護のために、指定されたメンテナンス時間枠外で、メンテナンスが Memcached インスタンスに適用されることがあります。

Memorystore でメンテナンスをキャンセルすると、どうなりますか?

Memorystore によってメンテナンス イベントがキャンセルされると、メンテナンスがキャンセルされたという通知が送られます。まれに、Memorystore で事前にキャンセル通知が送信されないことがあります。この場合、スケジュールが設定されているメンテナンスの時間枠が経過した後、メンテナンスが適用されなかったことが通知されます。

メンテナンスは、選択した設定に基づいて今後のメンテナンスの時間枠に変更されます。メンテナンス イベントのスケジュールが変更されると、新しいメンテナンス通知を受け取ります。

メンテナンスの時間枠にはどの時刻形式が使用されますか?

Google Cloud コンソールを使用する場合、メンテナンスの時間枠はローカル タイムゾーンに表示および設定されますが、UTC 時間で保存されます。そのため、Google Cloud コンソールには、UTC 時間を基準にしたメンテナンス時間枠の時間も表示されます。Google Cloud CLI で時間枠を設定するときは、UTC 時間を使用して時間を設定します。

Google Cloud コンソールでは閲覧者のローカル タイムゾーンで時間枠が表示されるため、時間枠は UTC 時間に基づいてスケジュールする必要があります。そのため、ユーザーが別のタイムゾーンで時間枠を設定していると、混乱を招く可能性があります。

メンテナンスの時間枠には夏時間への変更は適用されません。

次のステップ

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