先日、Cloud SQL for PostgreSQL のバックアップから AlloyDB for PostgreSQL へ移行する機能がプレビューで追加されました。
これまではマイグレーションサービスを使う必要がありましたが、この機能により簡単に移行することが可能となります。
今回はその機能の仕様と実際に設定してみた所感を紹介いたします。
AlloyDB と Cloud SQL について
AlloyDB と Cloud SQL のユースケースの違いを簡単にまとめました。
AlloyDB の方が高コストですが高性能なため、基本的にサービスの規模によって使い分けているイメージが強いです。
特徴 | AlloyDB | Cloud SQL |
---|---|---|
性能 | 高性能を求める場合 | 標準的な性能で十分な場合 |
スケーリング要件 | 自動スケーリングが必要な場合 | 定常的なワークロードの場合 |
データベースタイプ | PostgreSQL のみ | MySQL, PostgreSQL, SQL Server |
ワークロード | 大量データ処理、HTAPワークロード | トランザクション処理中心 |
コスト | 高コストでもパフォーマンス重視 | 初期コストを抑えたい場合 |
運用負担 | 低 (フルマネージド) | 低 (フルマネージド) |
制限事項
以下についてはサポート対象外となります。
- プロジェクト間、およびリージョン間を跨ぐ移行
- 顧客管理暗号化キー (CMEK) を使用したインスタンス
- IAM グループ認証を備えたインスタンス
- 1 TB を超えるバックアップからの移行
- 異なる PostgreSQL メジャーバージョンへの移行 ※
- AlloyDB でサポートされていないバージョンの PostgreSQL からの移行
- データベースフラグとリソースレベルの権限の移行
※ 拡張機能のバージョンと PostgreSQL のマイナーバージョンは異なる場合があります。
必要な権限
以下のプロジェクト IAM ロールが付与されている必要があります。
- 閲覧者 (roles/viewer)
- Cloud AlloyDB 管理者 (roles/alloydb.admin)
また、以下の API を有効化します。
- AlloyDB API
- Compute Engine API
- Service Networking API
今回の検証では、サンプルデータを入れた Cloud SQL for PostgreSQL のバックアップを取得した状態から始めます。
Cloud SQL Studio から見ると大体こんな感じになっていました。
移行後もちゃんと同様のデータが入っているかどうかを確認したいと思います。
設定方法
早速検証してみましょう。
まずは AlloyDB for PostgreSQL のページにアクセスし、以下の「CLOUD SQL バックアップからコピー」を選択します。
今回は無料トライアルで作成していきますが、本番環境のクラスタを作成する場合や既存クラスタに移行する場合は「データを移行」から同じように進めます。
遷移先でもう一度クラスタタイプを選択したら、次のページでコピー元の Cloud SQL インスタンスを選択します。
ここに表示されるのは、AlloyDB と互換性のある PostgreSQL バージョンのインスタンスのみとなりますので注意。
バックアップがないインスタンスも表示されますが、もちろん選択はできません。
続いて、コピー元のバックアップを選択します。
最後に AlloyDB のクラスタ設定を行って完了です。
以下のように表示されれば正常に作成されています。
AlloyDB Studio でデータを確認してみても、ちゃんと移行されていそうですね。
たったの 4 ステップで移行できました。
終わりに
Cloud SQL でスモールスタートし、規模が大きくなってきたら AlloyDB を利用すると言ったケースも少なくないと思います。
そういった場合に簡単に移行できるのは非常にありがたいですね。
また、AlloyDB は最近 GA された機能も多く、今後より使いやすくなるかと思いますので、ますます需要が高まっているのかもしれません。
引き続き、注目していきたいサービスです。