1. はじめに
Azure Database for PostgreSQL は、AzureのマネージドデータベースサービスとしてのPostgreSQLで、シングルサーバとフレキシブルサーバの2種類があります。
しかし、シングルサーバは2025年3月28日に廃止予定 であり、すでに新規利用は停止さてれいて、既存の利用者はフレキシブルサーバへの移行が推奨されています。
そこで、Azure Database for PostgreSQLのシングルサーバからフレキシブルサーバへの移行を実際にやってみました。
2. 移行方法の確認
まずはフレキシブルサーバへの移行方法を確認しました。下記の2種類のデータベース移行方式がサポートされています。
| 移行方式 | オフライン移行 | オンライン移行 |
|---|---|---|
| 概要 | シングルサーバに接続しているアプリケーションを全て停止してから、シングルサーバからフレキシブルサーバにデータをコピーする | 可能な限りシングルサーバにアプリケーションを接続したまま、シングルサーバからフレキシブルサーバにデータをコピーする |
| 実行手段 | ・シングルサーバからフレキシブルサーバへの移行ツール ・PostgreSQLのコマンド(pg_dump、pg_restore) |
・シングルサーバからフレキシブルサーバへの移行ツール ・Azure Database Migration Service |
| 長所 | シンプルで失敗しにくい | アプリケーションのダウンタイムを最小限に抑えられる |
| 短所 | アプリケーションのダウンタイムが長くなる可能性がある | ・データベーススキーマとDDLコマンドは手動で複製する必要がある ・失敗の可能性が比較的高い ・移行中にかかるデータベースへの負荷が、アプリケーションに影響する可能性がある |
Azureが提供するシングルサーバからフレキシブルサーバへの移行ツールは、pg_dumpおよびpg_restoreコマンドの実行を自動化するツールで、Azure PortalまたはAzure CLIから実行できます。Azureが利用推奨しているツールなので、今回はこの移行ツールをAzure Portalから利用することにしました。
また、オフライン移行とオンライン移行では、失敗の可能性が低いオフライン移行が推奨されています。オフライン移行ではアプリケーションのダウンタイムに関する要件が満たされない場合に、オンライン移行を検討すべきとされています。
そこで、オフライン移行とオンライン移行それぞれで、移行ツールの実行時間とアプリケーションのダウンタイムについて調べることにしました。
3. 移行実践
PostgreSQLのサンプルデータベースを対象に、Azureが提供するシングルサーバからフレキシブルサーバへの移行ツールをAzure Portalから操作して、オフライン移行とオンライン移行の両方を実施してみました。今回対象としたPostgreSQLサンプルデータベースはダンプファイルのサイズが2,769KBで、ストレージの使用容量は約500MBでした。
3.1. 実行手順
実行手順を下記に示します。オフライン移行とオンライン移行の間で実行手順はほとんど差がありませんでした。
-
Azure Portalから構築済みのシングルサーバを表示すると、移行ツールの利用へ誘導するメッセージ（図中の赤枠内）が表示されたので、そのリンクから移行を開始しました。
-
移行先のフレキシブルサーバとして、構築済みのものを選択するか、新規作成ができました。フレキシブルサーバの構築については省力しますが、SKUタイプがバースト可能なフレキシブルサーバを選択すると、選択時には警告ありませんでしたが、後の実行画面でバースト可能なフレキシブルサーバには移行できないというエラーが表示されました。
-
移行方法の設定画面になり、オフライン移行かオンライン移行かを選択しました。また、実際に移行を行うか、移行可能かの事前検証のみを行うかも選択できました。
-
シングルサーバとフレキシブルサーバのそれぞれの接続情報（ホスト名、管理ユーザー名、パスワード）を入力して、接続確認を求められました。接続情報の入力画面は省略します。
-
移行の実行画面になり、事前検証および移行の実行状況が表示されました。オフライン移行の場合は移行完了まで操作不要でした。オンライン移行の場合は実行途中に、データベースに接続するアプリケーションの停止を待つ状態になったので、待ち状態を解除して移行を進める操作が必要でした。
(参考)Azure Portalでの移行ツールの操作方法と画面説明
3.2. 実行時間
オフライン移行とオンライン移行で、測定した移行ツールの実行時間と、移行中のどのタイミングでアプリケーションのダウンタイムが発生するかを図にまとめました。
アプリケーションのダウンタイムは、移行ツールの実行時間だけでなく、データ移行が正しく完了したかを検証する作業時間や、アプリケーションが接続する先のデータベースを切り替え（接続文字列の変更等）の作業時間、アプリケーションの起動にかかる時間も含まれます。
オフライン移行とオンライン移行の大きな違いは、アプリケーションの停止のタイミングです。
オフライン移行では、アプリケーションを停止してからデータ移行を開始し、データ移行完了後にアプリケーションの接続先を切り替え、アプリケーションを起動します。そのため、アプリケーションのダウンタイムの中に、データ移行にかかる時間が全て含まれています。
一方でオンライン移行では、アプリケーションを動かしたままデータ移行を開始し、移行の途中にアプリケーションを停止します。アプリケーションの停止後には、未完了だったデータの移行のみを行うため、アプリケーションのダウンタイム中に含まれるデータ移行にかかる時間は一部のみです。
今回測定した時間では、オフライン移行のツール実行時間①は3分31秒でした。一方でオンライン移行のツール実行時間は、アプリケーション停止前②に3分40秒と、アプリケーション停止後③に2分07秒でした。
データ移行の全体的な実行時間はオフライン移行の方が短くなりましたが、アプリケーションのダウンタイムに含まれる部分の実行時間では、オンライン移行の方が短い結果となりました。
また、オフライン移行のツール実行時間①と、オンライン移行のアプリケーション停止前のツール実行時間②は、全てのデータをコピーする操作の時間を含むため、移行対象のデータベースサイズが大きくなるほど時間がかかるはずです。
一方で、オンライン移行のアプリケーション停止後のツール実行時間③は、アプリケーションを停止するタイミングで未完了だったデータ同期を待つ時間だけなので、データベースサイズには影響されないはずです。
以上より、データベースサイズが大きくなほど、オンライン移行の方がアプリケーションのダウンタイムが短くなると考えられます。
4. 感想
Azure Database for PostgreSQLのシングルサーバが廃止になるため、Azureが提供する移行ツールを用いてフレキシブルサーバへの移行を実践しました。
移行実践を通して、オフライン移行よりもオンライン移行の比較では、オンライン移行の方がアプリケーションのダウンタイムが短くなりそうだという感触を得ることができました。
また、データベースの移行はハードルが高そうと思っていましたが、Azure Portal上で移行ツールを実行すると画面上に説明が表示されたため、操作に迷うことはなかったです。pg_dumpおよびpg_restoreコマンドを自力で実行するよりも簡単だったと思います。
実際に運用中のデータベースを移行する際には、アプリケーションの停止と接続先の切り替え作業や、ダウンタイムなどの考慮が必要ですが、データベースの移行操作自体は簡単に実施できそうです。
他には、フレキシブルサーバのSKUタイプとしてバースト可能を選択すると、移行時にエラーとなることも今回の実践で発見できました。