はじめに
ビットキーで bitkey platform を開発している @otakakot です。
bitkey platform では Cloud SQL for PostgreSQL を活用しています。
Cloud SQL では紆余曲折事情があり複数のデータベース[1]をひとつのインスタンスで管理しています。
今回 Cloud SQL for PostgreSQL のメジャーバージョン更新の機会があり、Database Migration Service (DMS) の利用を検討しました。
システムは 24/365 で稼働しているため、バージョン更新に伴うダウンタイムはなるべく短くしたいです。
また、移行に際してデータの欠損は無くしたいです。
DMS を使えば下記の図に示すように、古いバージョンの Cloud SQL インスタンスから新しいバージョンの Cloud SQL インスタンスに少しのダウンタイムだけでメジャーバージョン移行ができるだろうと考えていました。
しかし、実際に検証を進めると、DMS はひとつのデータベースでしかジョブが作成できず、Cloud SQL 内に複数データベースがある場合はそう簡単に移行できないことが判明しました。
本記事では、DMS を使った PostgreSQL のバージョン更新と、DMS を使う上で考えた移行のシナリオについて共有しようと思います。
TL;DR
PostgreSQL のバージョニングポリシー
PostgreSQL は約 1 年ごとにメジャーバージョンがリリースされます。
Cloud SQL は PostgreSQL の一般提供リリースから 5 ヶ月以内に新しいメジャーバージョンがサポートされます。
また、メジャーバージョンが EOL に達した場合でも、Cloud SQL は拡張サポートが提供され、追加で 3 年間サポートされます。[2]
ただし、延長サポートは追加で料金が発生するので注意が必要です。
Database Migration Service : DMS
Database Migration Service はオンプレミス、Google Cloud、または他のクラウドからクラウドのオープンソースデータベースへの移行をサポートしてくれるサービスです。
データ移行だけでなく、Cloud SQL インスタンスのインプレースアップグレードも実行できます。
DMS を使ったメジャーバージョンアップの更新
実際に行う場合は、下記の公式ドキュメントを参照の上実施することをおすすめします。
おおまかな手順は以下のようになります。
- 移行元インスタンスのフラグを設定し再起動（ダウンタイム）
- 移行先インスタンスを構築
- DMS の接続プロファイルを作成
- DMS の移行ジョブを作成
- DMS の移行ジョブを開始（移行先インスタンスはレプリカへと降格）
- データロストを避けるために移行元インスタンスへの書き込みを停止（ダウンタイム開始）
- DMS の移行ジョブをプロモートし、移行先インスタンスをプライマリへと昇格
- アプリケーションの書き込み先を移行先インスタンスへと変更し再開（ダウンタイム終了）
公式ドキュメントに従って実行していけば、ダウンタイムはあるものの Cloud SQL のバージョンアップは比較的簡単に行えます。
しかし、検証を行なっていく中で以下の課題が発覚しました。
DMS (接続プロファイル) はデータベース単位での実行
この仕様をもとに 3 つのシナリオを考えてみました。
複数データベース を DMS を使って移行するシナリオ
A. サービスを停止した上での移行
A 案は、移行作業が完了するまでサービスを全て停止する方針です。
※ 斜線で示した部分がサービス停止期間です。
1 つ目のサービスのデータ移行を終え、移行先インスタンスをプロモートしたあとから 3 つ目のサービスのプロモートが完了するまでサービスを停止します。
この場合、ジョブの設定を含む 2 つ目と 3 つ目のデータ移行期間もダウンタイムとなります。
データ量や作業手順の迅速さに依存するかと思いますが、Cloud SQL の公式ドキュメントに記載があるデータベースのメジャーバージョンをインプレースでアップグレードするのと同じくらいのダウンタイムになりそうな気がします。
B. DMS 実行ごとにダウンタイムするサービスが増える移行
B 案は、サービスごとに DMS を使ってデータを移行する方針です。
一見よさそうに見えますが、DMS が移行先インスタンスをレプリカに降格させる影響で、順に書き込みができなくなるサービスが増えていきます。
※ 斜線で示した部分がサービス停止期間です。
1 つ目のサービスは DMS を実行し、アプリケーションの書き込みを停止しプロモート、アプリケーションの再接続をする間ダウンタイムが発生します。
2 回目以降は DMS のデータ移行期間もダウンタイムとなります。
C. 移行先インスタンスをサービスごとに立ち上げる移行
C 案は、サービスごとに新たにインスタンスを立ち上げるようにしダウンタイムを抑える方針です。
※ 斜線で示した部分がサービス停止期間です。
これまでの案と比べてダウンタイムの時間はもっとも抑えられます。
（アプリケーションの接続切り替え時のみです。）
そして、次回以降のバージョンアップでは今回のような問題は発生しません。
ただし、管理するインスタンスが増えるためコストが増大します。
それぞれのインスタンス性能をこれまでよりもスペックを下げることは可能かと思いますが、レプリカインスタンスを複数ゾーンで構築している場合にはコストが増加してしまいます。
おわりに
検証した結果、複数データベース持ちのプロダクトでは DMS を使った Cloud SQL for PostgreSQL はそれなりのダウンタイムもしくはコストアップが避けられないのだと分かりました。
単一のデータベースを扱っているのであれば DMS に頼って問題ないかと思います。
今回の記事が同じようにメジャーバージョン更新を検討している方の知見になったら幸いです。
P.S. クラウド環境でデータベースを使う場合には、1 インスタンス 1データベースがベストなのでしょうか...？
-
データベースは
CREATE DATABASEコマンドで作成するものを指します。 ↩︎ -
https://cloud.google.com/sql/docs/postgres/extended-support?hl=ja ↩︎
Discussion