Cloud SQL インスタンスでのメンテナンスについて

このページでは、Cloud SQL インスタンスでメンテナンスを更新する方法と、更新のタイミングを制御する方法について説明します。開始するには、メンテナンスの時間枠の検索と設定をご覧ください。

概要

Cloud SQL はマネージド サービスとして、インスタンスを自動的に更新し、基盤となるハードウェア、オペレーティング システム、データベース エンジンの信頼性、パフォーマンス、安全、最新性を確保します。これらの更新のほとんどは、Cloud SQL インスタンスの稼働中に行われます。ただし、一部のシステム更新では短時間サービスの中断が必要になります。こうした更新はメンテナンスと呼ばれます。

メンテナンスにより、オペレーティング システムとデータベース エンジンが更新されます。この更新ではインスタンスの再起動が必要になるため、ダウンタイムが発生します。メンテナンス更新には次の利点があります。

  • Cloud SQL の機能。新しい機能をリリースするために、データベース エンジンが更新され、データベースへの新しいプラグインがインストールされます。

  • データベースのバージョン アップグレード。SQL Server を開発するデータベース ソフトウェア プロバイダは、年に数回新しいマイナー バージョンをリリースしています。新しいバージョンごとに、バグの修正、セキュリティ パッチ、パフォーマンスの向上、新しいデータベース機能が提供されます。Cloud SQL for SQL Server でサポートされている最新のマイナー バージョンを確認するには、リリースノートまたはデータベースのバージョンとバージョン ポリシーをご覧ください。Cloud SQL インスタンスは、リリース直後に最新のデータベース バージョンにアップグレードされるため、最新のデータベース ソフトウェアを実行できます。

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

メンテナンスへの影響

メンテナンス イベント中の Cloud SQL for SQL Server インスタンスの平均切断時間は 120 秒未満です。

メンテナンス中のアクティビティが多いインスタンスや、非常に大規模なデータセットを持つインスタンスの場合、ダウンタイムが長くなる可能性があります。Cloud SQL は通常、数か月に一度の頻度でメンテナンスを行います。

メンテナンスの設定を利用したり、一時的なエラーに強いシステムに変更することで、メンテナンスによる影響を最小限に抑えることができます。

メンテナンスの設定

Cloud SQL では、一連のメンテナンス設定を使用してメンテナンス更新を構成できます。

ダウンタイムを短くし、アプリケーションへの影響を最小限に抑えるようにメンテナンスを構成できます。Cloud SQL インスタンスごとに、次の構成を行うことができます。

  • メンテナンスの時間枠。Cloud SQL がメンテナンスをスケジュールする曜日と時間。メンテナンスの時間枠は 1 時間です。メンテナンスの時間枠の構成方法を確認してください。

  • 更新の順序。Cloud SQL インスタンスの更新順序を、同じリージョン内の他のインスタンスとの相対的な順序で設定します。更新の順序は、Any、Earlier、Later のいずれかに設定できます。Later インスタンスは、同じリージョンで同じメンテナンスの時間枠を持つ Earlier インスタンスから 1 週間後に更新されます。更新の順序は、メンテナンスの時間枠を構成する際に設定します。

  • メンテナンス拒否期間。Cloud SQL がメンテナンスをスケジュールしない日数のブロック。メンテナンス拒否期間は最長 90 日間まで設定できます。メンテナンス拒否期間の構成方法をご確認ください。

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

メンテナンスの時間枠を設定しない場合、Cloud SQL は、インスタンスのタイムゾーンに応じて、次のデフォルトの時間枠でインスタンスを更新します。

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

メンテナンスの例

ショッピング カート サービスを管理する小売業の開発者を例に考えてみましょう。ここでは、本番環境用とステージング環境用の Cloud SQL インスタンスが 1 つずつあり、インスタンスのトラフィック処理量が最も少ない時間帯（日曜日の深夜 0 時頃）にメンテナンスを行いたいと考えています。また、年末商戦の繁忙期はメンテナンスを避ける必要があります。

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

  • メンテナンスの時間枠: 日曜午前 12 時～午前 1 時（米国東部時間）
  • 更新の順序: Later
  • メンテナンス拒否期間: 11 月 1 日から 1 月 15 日。

更新の順序が Earlier に設定されること以外は、ステージング環境のメンテナンスの設定も同じです。これにより、メンテナンスが本番環境にロールアウトされる 7 日前までに、メンテナンス リリースの運用承認テストを行うことができます。ステージング環境でなんらかの問題が発生した場合は、問題を診断して修正し、本番環境に影響が及ばないようにします。

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

メンテナンスが予定されている少なくとも 1 週間前に、今後のメンテナンスに関する通知をメールで受け取るよう設定できます。通知のメールフィルタを設定する場合、メールのタイトルは「Cloud SQL インスタンス（インスタンス名）の今後のメンテナンス」となります。

デフォルトでは、メンテナンス通知は送信されません。メンテナンス通知を有効にする必要があります。通知を受信するには、メンテナンスの時間枠も選択する必要があります。

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

特定のプロジェクトで、メンテナンスの時間枠が設定されている Cloud SQL インスタンスごとに、メンテナンス通知を有効にします。インスタンスごとに 1 つの通知が届きます。リードレプリカには、今後のメンテナンス通知は送信されません。

Google Cloud Console で今後のメンテナンス情報を確認することもできます。

  • [インスタンス] リストの [メンテナンス] 列。メンテナンスのスケジュール設定されている場合、メンテナンスの開始日時が表示されます。「メンテナンス」という用語を使用して [インスタンス] リストをフィルタすると、メンテナンスのスケジュールが設定されているすべてのインスタンスを検索できます。[メンテナンス] 列は、プロジェクト内の 1 つ以上のインスタンスでメンテナンスがスケジュールされている場合にのみ表示されます。メンテナンスのスケジュールが設定されていない場合、この列は非表示になります。
  • [メンテナンス] ペインの [インスタンスの詳細] ページ。メンテナンスが予定されている場合は、[近日公開] の下にメンテナンスの開始日時が表示されます。

  • Google Cloud コンソールの [アクティビティ] ページでは、メンテナンスがスケジュールされているインスタンスのリストを表示できます。メンテナンスのスケジュールが設定されている場合、インスタンスの「SQL Maintenance」というメッセージと、メンテナンスの開始日時が表示されます。

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

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

元のスケジュール日時から 28 日以内であれば、メンテナンスのスケジュールを複数回変更できます。

新しいメンテナンスの時間枠には、次のようなスケジュールのオプションがあります。

  • すぐに更新を適用する。定期メンテナンスの時間枠を待つのではなく、更新をすぐにインスタンスに適用できます。この場合、通常 5 分以内にメンテナンスが開始されます。

  • スケジュールを別の時間に変更する。スケジュールが設定されたメンテナンス イベントは、次の 2 つの方法で延期できます。

    • 次回の利用可能な時間枠。このオプションでは、現在の定期メンテナンス時刻から次に利用可能なメンテナンスの時間枠までメンテナンスを延期します（通常は 1 週間後）。
    • 特定の時間。このオプションでは、元の定期メンテナンス時刻から 28 日以内の特定の時間を選択できます。

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

メンテナンスの仕組み

メンテナンス時間を短縮するため、Cloud SQL では、高可用性インスタンスの自動フェイルオーバー ワークフローにほぼ同じメンテナンス フェイルオーバー ワークフローが使用されます。

簡単に説明すると、次のような手順になります。

  1. 新しいソフトウェアで更新後の VM を設定します。
  2. 元の VM を停止します。
  3. ディスクと静的 IP を更新後の VM に切り替えます。
  4. 更新された VM を起動します。

以下のタブの手順に沿って、メンテナンスの前後を含むワークフローの詳細を確認します。

メンテナンス前

メンテナンス前は、クライアントは静的 IP アドレスを使用して元の VM と通信しています。データは、元の VM にアタッチされている永続ディスクに保存されます。この例では、Cloud SQL インスタンスは高可用性で構成されています。これは、計画外の停止が発生した場合に引き継ぐために、別の VM がスタンバイ状態にあることを意味します。Cloud SQL インスタンスは、アプリケーションへのトラフィックを処理しています。

メンテナンス前の状態を示す図

ステップ 1

新しい VM を設定します。

新しい仮想マシン（VM）に、最新のデータベース ソフトウェアと VM オペレーティング システム（OS）が設定されます。更新された VM OS が起動します。この時点では、データベース エンジンはまだ起動していません。高可用性インスタンスの場合、新しいスタンバイ VM も設定されます。

元の Cloud SQL インスタンスがトラフィックを処理している間、別の VM にソフトウェアの更新をインストールすることで、合計のダウンタイムが大幅に短縮されます。

VM の設定中であることを示す図

ステップ 2

元の VM をシャットダウンします。

データベース エンジンがシャットダウンされるため、ディスクは元の VM から切断され、更新された VM にアタッチされます。データベース エンジンは、進行中のトランザクションが commit され、既存の接続からのリクエストがドレインされるまで数秒待機してからシャットダウンされます。その後、オープンまたは長時間実行されているトランザクションはロールバックされます。データベースは新しい接続を受け付けなくなり、既存の接続は破棄されます。インスタンスが利用できなくなり、メンテナンスのダウンタイムが開始されます。

フェイルオーバー後のインスタンスを示す図

ステップ 3

更新された VM に切り替えます。

ディスクが元の VM から切断され、更新された VM にアタッチされます。更新された VM を参照するように静的 IP アドレスが再構成されます。これにより、メンテナンス後もアプリケーションは以前と同じ IP アドレスを使用できます。データベース キャッシュは元の VM で循環されます。つまり、データベース キャッシュはメンテナンス中に実質的にクリアされます。

更新された VM への切り替えを示す図

ステップ 4

更新された VM を起動します。

更新されたデータベース エンジンがデータディスク上で起動します。共通のデータディスクを使用すると、メンテナンス前に元のインスタンスに書き込まれたすべてのトランザクションが、メンテナンス後も更新されたデータベースで維持されます。データベースのシャットダウン中に未完了のトランザクションのロールバックが完了しなかった場合、データベースは自動的にクラッシュ リカバリを行い、データベースを使用可能な状態に復元します。

更新された VM の起動を示す図

メンテナンス後

ステップ 4 を完了すると、Cloud SQL インスタンスで接続が許可され、アプリケーションへのトラフィック処理に戻ります。

アプリケーションから見ると、ソフトウェアが更新された点を除いて Cloud SQL インスタンスはまったく同じように見えます。アプリケーションは前と同じ静的 IP アドレスを使用して Cloud SQL インスタンスに接続し、更新された VM は元の VM と同じゾーンで実行されます。元のデータベースに書き込まれたデータはすべて保持されます。

メンテナンス後の図

セルフサービス メンテナンス

Cloud SQL は、ソフトウェアの改善を、新しいメンテナンス バージョンを通じて定期的にリリースしています。新しいメンテナンス バージョンでは、Cloud SQL の新機能、既知の脆弱性に対するセキュリティ パッチ、バグの修正、パフォーマンスの改善などがリリースされます。Cloud SQL では、データベース エンジンのメジャー バージョンごとに Cloud SQL メンテナンス変更履歴が保持されます。詳細については、Cloud SQL メンテナンス変更履歴をご覧ください。

Cloud SQL は、最新のメンテナンス バージョンを確実にお届けするため、数か月に 1 回の頻度でメンテナンス更新を実施していますが、次の場合はセルフサービスのメンテナンスでインスタンスを最新の状態に保つことができます。

  • 次回の定期メンテナンス イベントよりも前に更新が必要な場合。
  • 直近のメンテナンス更新をスキップして、最新のソフトウェアを取得した場合。

メンテナンスに関するよくある質問

メンテナンスによるダウンタイムは SLA の対象になりますか？

通常のメンテナンスによるダウンタイムは SLA の対象になりません。ただし、Cloud SQL では、時間的制約のあるメンテナンスによるダウンタイムが SLA の対象となります。

メンテナンスはリードレプリカにどのように影響しますか？

  • Cloud SQL は、プライマリ インスタンスの前にリードレプリカを常に保持します。プライマリ インスタンスにメンテナンスの時間枠がある場合、リードレプリカは同じメンテナンスの時間枠に従います。
  • リードレプリカは、プライマリ インスタンスに設定されているメンテナンス拒否期間に従います。プライマリ インスタンスに複数のリードレプリカがある場合、Cloud SQL は一部のレプリカを同時に更新することがあります。

定期メンテナンスをキャンセルできますか？

スケジュール設定されたメンテナンスの時間枠はキャンセルできませんが、スケジュールの変更は可能です。また、定期メンテナンスと重複するメンテナンス拒否期間を構成すると、メンテナンスを効果的にスキップできます。

再スケジュールの制限事項

スケジュールの変更については、次の点にご注意ください。

  • 元の定期メンテナンス イベントが発生する 24 時間以上前にメンテナンスのスケジュールを変更する必要があります。

  • プロジェクトの 1 つまたは複数のインスタンスに対してメンテナンスのスケジュールを変更できます。ただし、一度に変更できるのは 1 つのインスタンスのみです（スケジュールの一括変更は使用できません）。

  • 再スケジューリングの期限内（28 日間）であれば、メンテナンスのスケジュールを、メンテナンス拒否期間だけでなくメンテナンスの時間枠外にも変更できます。

  • メンテナンス オペレーションが実行中の場合、オペレーションが完了するまで再スケジュールが遅延します。

メンテナンス イベントがキャンセルされた場合はどうなりますか？

Cloud SQL でメンテナンス イベントがキャンセルされると、可能な限り事前にメンテナンスがキャンセルされたという通知を受け取ります。

メンテナンス イベントのスケジュールが変更されると、新しいメンテナンス通知を受け取ります。

メンテナンス拒否期間の制限

メンテナンス拒否期間について、次のことを知っておく必要があります。

  • インスタンスにメンテナンスの時間枠が構成されていない場合でも、メンテナンス拒否期間を設定できます。メンテナンス拒否期間は 1～90 日の範囲で設定できます。

  • メンテナンス拒否期間は、予定されたメンテナンスの時間枠よりも優先されます。メンテナンスの時間枠のタイミングとメンテナンス拒否期間の間に矛盾がある場合は、メンテナンスの時間枠よりもメンテナンス拒否期間が優先されます。

  • メンテナンス拒否期間と相対スケジューリングは独立した機能です。Earlier インスタンスで指定されたメンテナンス拒否期間は、Later インスタンスのスケジュール決定には影響しません。メンテナンスのスケジュールが Earlier インスタンスまたは Later インスタンスのメンテナンス拒否期間内である場合、通知は送信されません。

  • プライマリ インスタンスで拒否期間が設定されている場合、プライマリ インスタンスに関連付けられたすべてのレプリカのメンテナンスも拒否されます。たとえば、リージョン A に配置されたプライマリ インスタンスに 3 つのリードレプリカがあるとします（リージョン A に 2 つ、リージョン B に 1 つ）。プライマリ インスタンスで拒否期間が設定されている場合、リージョン B のレプリカを含む各レプリカのメンテナンスは、プライマリ インスタンスの拒否期間が終了するまで拒否されます。

  • メンテナンス スケジュールが設定された後にメンテナンス拒否期間が設定され、メンテナンスの拒否期間がスケジュールされたメンテナンス時間と重複している場合、更新はスキップされます。

  • 開始日時と終了日のパラメータに年を含めることなく、毎年のメンテナンス拒否期間を設定できます。年を指定すると、その年だけメンテナンス拒否期間が設定されます。

  • 1 年間にメンテナンス拒否期間を複数設定できます。拒否期間を連鎖させ、スケジュールされたメンテナンス イベントを連続してスキップしないことをおすすめします。Cloud SQL のメンテナンスを最新の状態に保つことは、インスタンスを確実に動作させるうえで重要です。通常、Cloud SQL のメンテナンスは数か月に 1 回スケジュールされます。

  • サービスの信頼性を確保するために、Cloud SQL は、12 か月以上経過したメンテナンス リリースを実行しているインスタンスで次のメンテナンス ロールアウトが必要なことをユーザーに通知します。

  • メンテナンス拒否期間が終了すると、通常のメンテナンス動作が再開されます。

メンテナンスの影響を最小限に抑える

一般に、Google Cloud では、クラウドでアプリケーションを実行しているユーザーは、一時的なエラー（一時的な使用不能状態による一時的なサービス間通信の問題）に対するシステムの復元力を高めることをおすすめします。時折発生する一時的なエラーはクラウドでは回避できません。

メンテナンス中に発生する一時的なエラーには、接続の切断や処理中のトランザクションの失敗などがあります。一時的なエラーに対する復元性を高めるようにシステムを設計し、調整することで、データベースのメンテナンスによる影響を最小限に抑えることもできます。

接続の中断による影響を最小限に抑えるには、接続プールを使用します。メンテナンス中にプーラーとデータベース間の接続は切断されますが、アプリケーションとプーラーの間の接続は保持されます。これにより、接続の再確立がアプリケーションに対して透過的になり、接続プーラーにオフロードされます。

長時間実行トランザクションの数を制限することで、トランザクションの失敗を減らすことができます。クエリを小さくして、より効率的に書き換えることで、メンテナンスのダウンタイムが短縮されるだけでなく、データベースのパフォーマンスと信頼性も向上します。

接続の切断やトランザクション エラーから効率的に復旧するには、効率的にデータベース接続を管理します。指数バックオフを使用して、アプリケーションと接続プーラーに接続とクエリの再試行ロジックを構築できます。クエリが失敗した場合、または接続が切断された場合、システムは再試行の前に待機期間を設定します。待機時間は、後続の再試行ごとに増加します。たとえば、最初の再試行ではシステムは数秒しか待機しませんが、4 回目の再試行では最大で 1 分間待機する場合があります。このパターンに従うことで、サービスに過大な負荷をかけることなく、これらの問題を確実に修正できます。

また、スクリプトを使用したメンテナンス後のデータベース キャッシュのウォーミングや、データベース内のテーブル数の合理化など、その他のクリエイティブなソリューションにより、メンテナンスの影響を最小限に抑えることもできます。メンテナンスがスムーズに行われるように、データベース管理のベスト プラクティスとオペレーション ガイドラインをご確認ください。

時間的制約のあるメンテナンス

非常にまれですが、Cloud SQL では、時間的制約のある重大な安定性の問題や脆弱性にパッチを適用するために、メンテナンス設定以外のメンテナンスをスケジュールする必要がある場合があります。こうした更新はすぐにロールアウトされ、Cloud SQL では SLA に対するダウンタイムとしてカウントされるためです。

Cloud SQL のメンテナンスは累積的ですか？

メンテナンス更新は累積的です。実施しなかった可能性のある各メンテナンスを適用する必要はありません。次回の定期メンテナンスでは、最新のメンテナンスが適用されます。また、セルフサービス メンテナンスを使用して最新のメンテナンスを適用することもできます。

次のステップ