はじめに
Cloud SQLにはEnterprise Plusというエディションがあります。その特徴の1つとして計画メンテナンス時のダウンタイムの短さがあります。本稿ではこのメンテナンス時間の短縮がどのような仕組みで実現されているかを解説します。マニュアルなどではこのメンテナンスの方式のことを「ダウンタイムがほぼゼロの計画的メンテナンス（Near-zero downtime planned maintenance）」と呼んでいます。そのままでは少々長いので本稿では以降、ニアゼロダウンタイムと記載します。
Cloud SQL Enterprise Plusを使うだけであればメンテナンス時の利用できない時間が短いのだなという理解でも十分です。その中で実際に何が行われているか興味がある方のための解説です。
ニアゼロダウンタイムの仕組み詳細
これ以降の説明はCloud SQL Enterprise Plus for MySQLを前提にします。データベースエンジンでの用語などの違いはありますが、基本的にはPostgreSQLでも同様のプロセスで実行されます。
ニアゼロダウンタイムはHA構成が前提となっているので、構成要素は大きく以下の通りです。
- プライマリ：HA構成のアクティブ側のVM
- スタンバイ：HA構成のスタンバイ側のVM
- リージョナルPD（Regional Persistent Disk）：ゾーン間で冗長構成となっているブロックストレージ、いわゆるディスクデバイス
- IPアドレス：データベースエンジンにアクセスするためのIPアドレスで、その時点のプライマリを指しています
準備
このステップではストレージも含めて、既存のインスタンスの構成と同じ構成を再現します。
ここでは新たに作られるプライマリとスタンバイの複製はそれぞれここではシャドーレプリカ、シャドースタンバイと呼びます。ストレージはメンテナンス対象のストレージの内容を複製します。ハードウェアなどの構成を行ったあとにプライマリとシャドーレプリカの間でバイナリログレプリケーションを構成します。これによりシャドースタンバイはストレージの複製により作られた以降の更新内容も受け取れます。
シャドーレプリカはこの時点ではユーザーからアクセス可能なIPアドレスを持っていません。
このステップは言い換えると、外からはアクセスできないHA構成のリードレプリカを作成する動作とも言えます。
シャドーレプリカへのメンテナンスの適用
この時点でシャドーレプリカを対象にメンテナンスを実行します。
データベースエンジンの更新など適用後にデータベースエンジンの再起動を必要とする場合もありますが、メンテナンスの適用対象はアクセスできないシャドーレプリカであるため実際のサービスへの中断は発生しません。
メンテナンス適用の復帰後、レプリケーションは再開され再起動中の更新差分も受け取とることでシャドーレプリカの内容はプライマリに追いついた状態となります。
サービスの中断
このステップが実際のサービスの中断となります。先のステップの完了後でレプリケーションが追いついていることを確認してから実行されます。
プライマリで新規のコネクションの受付を止めて、IPアドレスをプライマリからシャドーレプリカに切り替えます。
次に、プライマリとシャドーレプリカ間でのレプリケーションを解消します。これによりシャドーレプリカが新たなプライマリへと昇格されます。
新規のコネクション受付停止から昇格後の新たなプライマリがコネクションを受け付けるまでがダウンタイムとなります。この間の時間は通常、1秒程度です。
片付け
シャドーレプリカが昇格したため、元のプライマリは不要となります。それらのリソースの順次片付けが行われます。
このステップはもちろんデータベースエンジンの動作には影響ありません。
よくある（かもしれない）疑問点
メンテナンスの前提条件はなぜあるのか
この方式が適用できる前提条件の各項目については、マニュアルの該当箇所をご覧ください。ここではなぜそのような前提があるのかを解説します。ニアゼロダウンタイムの仕組みを理解すると、このメンテナンスの前提条件や制約は理解しやすいと思います。
次のフラグについて、デフォルト値から変更していないことが前提条件の1つになっています。
-
sync_binlog値: 1 -
innodb_flush_log_at_trx_commit値: 1 -
replica_skip_errors値: OFF -
binlog_order_commit値: ON
これらのフラグの設定は安全なバイナリログレプリケーションで求められる一般的な内容です。これはプライマリとシャドーレプリカの間でバイナリログレプリケーションを実行しているためです。
メンテナンス対象のインスタンスが外部のリードレプリカを持っている場合、メンテナンスの前後でレプリケーションも追従する必要があるため、GTIDによる自動ポジショニングが有効であることも求められます。メンテナンス中にログが二重に出るタイミングがある理由も、メンテナンス時にプライマリとシャドーレプリカでVM間での切り替わりがあることで説明できます。
対象となるメンテナンス
現時点（2024年6月時点）では以下のメンテナンスがニアゼロダウンタイムの対象となります。
- OSへのパッチ適用
- DBエンジンのマイナーバージョンアップ
- インスタンスサイズのスケールアップ
メンテナンスの全体の時間
ニアゼロダウンタイムのメンテナンスはダウンタイムを短くするため、事前に追加のリソースを使い準備期間を長めにとります。そのためメンテナンス適用本体が十秒で終わる内容であっても、事前の準備と片付けも含めると数分程度と傾向があります。
メンテナンス後のパフォーマンス
メンテナンスの前後で異なるVMに切り替わるため、メモリ上のキャッシュがクリアされます。そのためメモリ上のキャッシュに再びデータが十分にロードされるまでストレージへのアクセスが増える可能性があります。
ストレージについてもメンテナンス前後で別のストレージボリュームが使用されますが、Cloud SQLのストレージとして使っているリージョナルPDは複製後の初回アクセス時にレイテンシが高くなるといった症状は一般的に発生しません（いわゆるファースタッチレイテンシがない）。そのためストレージの性能はメンテンナンス前後で同程度の性能であることが期待されます。
メンテナンス内容によってダウンタイムは差があるか？
メンテナンス方法の解説の通り、ニアゼロダウンタイムでは準備段階でメンテナンスで必要な変更作業を行います。そしてダウンタイムはその後の切り替え時に発生します。そのためメンテナンス内容とダウンタイムの長さは一般的に影響はないはずです。
ただし、ダウンタイム以外も含めた全体の適用時間はメンテナンスでの変更内容によって多少の長短が生じる可能性があります。
通常のメンテナンスとニアゼロダウンタイムの違い
（Enterprise Plusではない）Cloud SQL Enterpriseでは通常のメンテナンス方法を実施しています。この方式でもフェイルオーバーの仕組みをつかってダウンタイムを短くする努力が払われています。スタンバイのVMを作成し、そちらへメンテナンスを適用しフェイルオーバーします。基本的なコンセプトはニアゼロダウンタイムと似ています。通常のメンテナンスで行っている内容についてはマニュアルに各ステップを詳細に解説しています。
これに対して、ニアゼロダウンタイムではストレージも複製を行ってそちらに切り替えます。この方式のメリットはプライマリでのデータベースエンジンのシャットダウンとその後に行うストレージの引き継ぎを行うステップを省略できる点があります。この変更によりダウンタイムがさらに短くすることが可能となります。ただし、準備すべき内容が増えるためメンテナンスプロセス全体の時間は長くなる傾向にあります。
アプリケーションから見たときのメンテナンス
接続先のIPアドレスを引き継ぐため、メンテナンス中での切り替えの前後でアプリケーションからの接続先に変更はありません。
ただし、VMとその上で動作するデータベースエンジンが切り替わるためメンテナンス以前から確立していたコネクションは使えなくなり、その瞬間に実行されていたトランザクションは中断されます。
また、切り替わりが短時間で実行されるため、データベースエンジンへのコネクションが正しく切断されたことを検出できていない場合があります。コネクションプーリングなどでコネクションを維持している場合は、空のSELECT文を発行するなどのキープアライブでコネクションの死活管理が有効です。
参考リンク
- Cloud SQL Enterprise Plusエディションにおけるマイナーバージョンアップ時のダウンタイムについて実際にメンテナンス時のダウンタイムを計測されています。この記事の時点から処理の最適化が進んだため、より短くなっているはずです
Discussion