コンテンツに移動
データベース

Cloud SQL のメンテナンスを理解する: メンテナンスの管理方法

2021年10月7日
Google Cloud Japan Team

※この投稿は米国時間 2021 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

次のような状況を想定します。Cloud SQL にミッション クリティカルなデータベースを設定していて、ライブ トラフィックを有効にする準備に取り組んでいます。最終のリリース チェックリストを確認しているとき、Cloud SQL には定期的なメンテナンスがスケジュールされていることを思い出しました。システムが、このメンテナンス更新を考慮したうえで適切に設定されているかどうかを検討するため、作業を一時中断します。

このブログシリーズのパート 2 では、Cloud SQL のメンテナンス プロセスを段階的に確認して、メンテナンスによるダウンタイムを可能限りな短時間にするために、Google がどのようにメンテナンス ワークフローを設計したかについて説明しました。パート 3 となるこの投稿では、メンテナンスがスケジュールされた際に管理しなければならない設定と、メンテナンスによるアプリケーションへの影響を最小限に抑えるために、システムを設計する方法について説明します。

メンテナンスを管理するための設定とは

ミッション クリティカルなサービスの一部には、どんなに短い中断であっても、中断の影響を特に受けやすいサービスがあります(特にピークタイム時)。ダウンタイムを短くし、アプリケーションへの影響を最小限に抑えるようにメンテナンスを構成できます。インスタンスごとに、メンテナンスの時間枠、更新順序、メンテナンス拒否期間を構成できます。

  • メンテナンスの時間枠は、ロールアウト中に Cloud SQL によってメンテナンスがスケジュールされている曜日と時間です。メンテナンスは、1 時間の時間枠の間にいつでも行われるようにスケジュールできますが、メンテナンス更新自体にかかる時間は、通常 1 分未満です。

  • 更新順序は、Cloud SQL インスタンスの更新順序を、同じリージョン内の他のインスタンスとの相対的な順序で設定します。更新順序は、Any、Earlier、Later のいずれかに設定できます。Later に設定したインスタンスは、同じリージョンで Earlier に設定されたインスタンスの 1 週間後に更新されます。

  • メンテナンス拒否期間は、Cloud SQL によってメンテナンスがスケジュールされないようにする期間です。メンテナンス拒否期間は最長 90 日間まで設定できます。

この設定の有効性は、例を使用して説明するのが一番です。たとえば、ご自身が BuyLots という e コマースストアの開発者であると仮定しましょう。本番環境と開発環境に Cloud SQL インスタンスが 1 つずつあります。トラフィックが最も少ない時間帯(日曜日の深夜 0 時)にメンテナンスを行いたいと考えています。また、BuyLots の繁忙期である年末のホリデー ショッピング シーズンは、メンテナンスを避けたいと考えています。

本番環境のインスタンスには、インスタンスのメンテナンスの時間枠を米国東部標準時の日曜日午前 0 時から午前 1 時に、更新順序を Later に、メンテナンス拒否期間を 11 月 1 日から 1 月 15 日に、それぞれ設定します。この例の場合、コンソールのインスタンス概要ページにあるメンテナンス カードには、次のように表示されます。

開発環境のインスタンスのメンテナンス設定は、更新順序が Earlier に設定されること以外は、同じです。この設定により、本番環境のインスタンスにメンテナンスを展開する前に、開発環境のインスタンスで、新しいメンテナンス リリースの運用受入テストを 7 日間実施できるようになります。開発環境のインスタンスでなんらかの異常が発生した場合は、本番環境で影響を受けないように、問題の診断と修正を行う時間を持つことができます。必要に応じて、問題への対応を支援してもらうために、Cloud SQL のサポートに連絡を取る時間もあります。

メンテナンス通知の仕組み

ミッション クリティカルなサービスを開発している場合、事前にサービスの停止を計画する必要がある場合があります。カスタマー サポートの準備や、メンテナンスの時間枠のエンドユーザーへの伝達が必要になる場合もあります。コンソールのユーザー設定にある [通信] ページから、今後のメンテナンスに関するメール通知の受け取りを選択できます。

今後のメンテナンスに関するメール通知は、少なくともメンテナンスの 1 週間前には、Cloud Identity のメールアドレスに配信されます。このメールアドレスには、メンテナンスされるインスタンス名とメンテナンス時間が含まれます。今後のメンテナンスに関する情報は、コンソールのインスタンス リストのページとインスタンスの概要ページにある上部のバナーにも表示されます。

ときには、元のメンテナンス時間との競合や、開発環境におけるメンテナンス更新のテストに時間が必要な場合があります。この場合は、メンテナンスのスケジュール変更を行い、メンテナンスをすぐに実施する、または元のスケジュール日時の 1 週間後のメンテナンスの時間枠で実施する、もしくはその間の任意の時点で実施する、のいずれかを選択できます。コンソールでは、インスタンス リストのページか、インスタンスの概要ページからスケジュールを変更できます。

Cloud SQL メンテナンスによる影響を最小限にするためのアプリケーションの設定方法

クラウドでアプリケーションを実行している場合、一般的には、一時的なエラー(一時的に使用できないことによるサービス間の一時的な通信の問題)に耐えられるシステムを構築することをおすすめします。パート 2 では、接続の切断や処理中のトランザクションの失敗など、メンテナンス中に発生する一時的なエラーに注目しました。結論から言えば、一時的なエラーに耐えられるようにシステムを設計してアプリケーションを調整することで、データベースのメンテナンスによる影響を最小限に抑えられるようになります。

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

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

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

メンテナンス後にデータベースのキャッシュをウォームアップするためにスクリプトを使用したり、MySQL データベースのテーブル数を合理化したり、メンテナンスの影響を最小限に抑えるための有意義なソリューションは、ほかにも数多くあります。メンテナンスがスムーズに行われるように、データベース管理のベスト プラクティスを確認することをおすすめします。

-

これで、Cloud SQL メンテナンスのブログシリーズは終わりです。「メンテナンスとは何か」、「Google はメンテナンスをどのように実施するか」、そして「メンテナンスの影響をどのように最小限に抑えるか」について、学んでいただくことができたら幸いです。このブログで取り上げていない問題がある場合は、メンテナンスのドキュメントで、その答えを見つけられます。Google は、メンテナンスに対する新しい改善と設定に、常に投資を続けていますので、最新情報を入手するためにリリースノートにご注目ください。Cloud SQL を初めてご利用になる場合は、こちらで新しいインスタンスの使用を開始してください。

-         プロダクト マネージャー Akhil Jariwala

投稿先