Cloud SQL のメンテナンスを理解する: 所要時間は？
Google Cloud Japan Team
※この投稿は米国時間 2021 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。
今後データベースにパッチを適用する必要が一切なくなると想像してみてください。本番環境のデータベースを停止してオペレーティング システムを更新したことがある方なら、パッチ適用は手間のかかる作業であることをご存じのはずです。Cloud SQL を使用している場合、Cloud SQL が代わりにデータベースを定期的にメンテナンスしてくれるので、この面倒な作業をタスクリストから消し去ることができます。しかし、メンテナンスではどのような作業が行われ、完了までにどれくらい時間がかかるのでしょうか。
このブログシリーズの 1 回目では、ユーザーのインスタンスの最適な動作を維持するため、メンテナンスが Cloud SQL の他のシステム更新とどのように組み合わせられているのかをご紹介しました。このシリーズの 2 回目では、Cloud SQL のメンテナンス中に行われる変更、所要時間、アプリケーションのダウンタイムを最小化するためのメンテナンスの設計方法について詳しくご説明します。
Cloud SQL のメンテナンス中に行われる変更
メンテナンス イベントは、Cloud SQL インスタンスのオペレーティング システムとデータベース エンジンを更新する、ソフトウェアのロールアウトです。Cloud SQL がメンテナンスを実行するのは、ユーザーのデータベースの信頼性、安全性、性能を維持するとともに、機能を常に最新の状態に保つためです。メンテナンスを通して、新しい Cloud SQL の機能、データベース バージョンのアップグレード、オペレーティング システムのパッチを提供しています。
Cloud SQL の機能。IAM データベース認証やデータベース監査などの新機能をリリースするために、Google がデータベース エンジンを更新して新しいプラグインをデータベースにインストールします。
データベース バージョンのアップグレード。MySQL、PostgreSQL、SQL Server を開発したデータベース ソフトウェア プロバイダは、1 年に複数回、新しいリリースをデプロイしています。新しい各マイナー バージョンには、バグ修正、セキュリティ パッチ、パフォーマンス改善、データベースの新機能が含まれます。ユーザーは、MySQL、PostgreSQL、SQL Server のリリースノートでこれらを確認できます。Google は、Cloud SQL インスタンスをリリース後すぐに最新のマイナー バージョンにアップグレードし、ユーザーが最新のデータベース エンジンを活用できるようにしています。
オペレーティング システムのパッチ。Google は、VM オペレーティング システムで新たに見つかるセキュリティ脆弱性を継続的に監視しています。こうした脆弱性が見つかると、オペレーティング システムにパッチを適用し、新たな侵害からお客様を保護します。
このような更新を行う際には、データベース インスタンスを一時的に切断する必要があります。メンテナンスはアプリケーションをスムーズに実行するために必要不可欠なものではありますが、お客様にとってサービスの中断は望ましいことではありません。そのため通常は、数か月おきに行う定期メンテナンスでこうした改善をまとめて適用します。
メンテナンス中のデータベースのダウン時間
2021 年 8 月時点で、データベース インスタンスの一般的な接続中断時間は次のようになっています。
PostgreSQL - 30 秒以内
MySQL - 60 秒以内
SQL Server - 120 秒以内
データベースを自己管理し、クラスタ全体でローリング アップデートを使用してメンテナンスを実施している場合は、Database as a Service で現在可能な時間よりも短い時間でのメンテナンスに慣れていらっしゃるかもしれません。Google は、Cloud SQL のメンテナンスによるダウンタイムをゼロに近づけるための取り組みを続けており、今年メンテナンスのワークフローの再設計を完了し、メンテナンスのダウンタイムを大幅に短縮しました。メンテナンスのダウンタイムは、12 か月前と比較して平均で 80% 短縮されています。2021 年 8 月現在、オンライン ドキュメントで公開された数値によると、MySQL と PostgreSQL については、Cloud SQL のメンテナンスの平均ダウンタイムは、Amazon RDS と Azure Database のダウンタイムよりも短くなっています。
メンテナンスのダウンタイム中の動作
メンテナンスにダウンタイムが伴う理由を理解するには、Cloud SQL のメンテナンスのワークフローを理解する必要があります。Cloud SQL ではメンテナンス用に共有ディスク フェイルオーバーのワークフローが利用されており、これは高可用性インスタンス用の自動フェイルオーバーのワークフローとよく似ています。簡単に説明すると、新しいソフトウェアを含む更新されたデータベースを設定し、元のデータベースを停止して、更新されたデータベースを起動してから、ディスクと静的 IP を更新されたデータベースに切り替えます。
図を使って順に説明します。メンテナンス前の状態（以下の図を参照）では、クライアントが静的 IP アドレスを介して元の VM に通信します。データは、元の VM にアタッチされている永続ディスクに保存されます。この例では、Cloud SQL インスタンスは高可用性で構成されています。つまり、計画外の停止が発生した場合に引き継げるよう、別の VM がスタンバイしています。Cloud SQL インスタンスは、アプリケーションへのトラフィックを処理しています。
ステップ 1 では、以下のように、最新のデータベース エンジンと OS ソフトウェアを使用して更新された VM を設定します。更新された VM は完全に起動していますが、データベース エンジンはまだ起動していません。高可用性インスタンスでは、新しいスタンバイ VM も設定します。更新された VM は元の VM と同じゾーンで設定されているため、Cloud SQL インスタンスはメンテナンス後もメンテナンス前と同じゾーンからアプリケーションに通信できるようになっています。
Cloud SQL インスタンスがトラフィックを処理している間に別の VM にソフトウェアの更新をインストールすることで、合計のダウンタイムが大幅に短縮されます。
ステップ 2 では、元の VM でデータベース エンジンを正常にシャットダウンします。データベース エンジンをシャットダウンして、ディスクを元の VM から切断して更新された VM にアタッチできるようにする必要があります。データベース エンジンは、進行中のトランザクションが commit され、既存の接続からのリクエストがドレインされるまで数秒待機してからシャットダウンされます。その後、オープン トランザクション、または長時間実行されているトランザクションはロールバックされます。このプロセスの間、データベースは新しい接続を受け付けなくなり、既存の接続は破棄されます。ステップ 2 でインスタンスが利用できなくなり、メンテナンスのダウンタイムが始まります。
ステップ 3 では、ディスクが元の VM から切断され、更新された VM にアタッチされます。更新された VM も参照するように静的 IP アドレスが再構成されます。これにより、メンテナンス前にアプリケーションが使用したのと同じ IP アドレスが、メンテナンス後も保持されます。データベース キャッシュは元の VM で循環されます。つまり、データベース キャッシュはメンテナンス中に実質的にクリアされます。
ステップ 4 では、更新されたデータベース エンジンが、アタッチされたばかりのディスクで起動します。単一のディスクを使用すると、メンテナンス前にインスタンスに書き込まれたすべてのトランザクションが、メンテナンス後も更新されたインスタンスで保持されます。データベース エンジンのシャットダウン中に、不完全なトランザクションがロールバックを終了しなかった場合、データベース エンジンは自動で障害復旧を行いデータベースが使用可能な状態に復元されるようにします。障害復旧が行われるため、メンテナンス開始時にアクティビティが多いインスタンスの場合、ダウンタイムが長くなります。
ステップ 4 を完了すると、Cloud SQL インスタンスで接続が再度許可され、アプリケーションへのトラフィック処理に戻ります。
アプリケーションから見ると、ソフトウェアが更新された点を除いて Cloud SQL インスタンスはまったく同じように見えます。アプリケーションは前と同じ静的 IP アドレスを使用して Cloud SQL インスタンスに接続し、更新された VM は元の VM と同じゾーンで実行されます。元のデータベースに書き込まれたデータはすべて保持されます。
これらの図で、改善後にもメンテナンスにダウンタイムが伴う理由をご理解いただけたでしょうか。Google は、メンテナンスをさらに高速化するよう引き続き取り組んでまいります。最新のメンテナンスのダウンタイムのデータについては、ドキュメントをご覧ください。
メンテナンスの影響をさらに低減するために、Cloud SQL ユーザーはどのような工夫をしているのでしょうか。3 回目では、Cloud SQL のメンテナンス設定を活用してメンテナンスからの復元性を持つように設計することで、メンテナンスに対してアプリケーションを最適化する方法をご紹介します。
-プロダクト マネージャー Akhil Jariwala
