Contents
移行評価と事前チェックリスト
データベースを Google Cloud に移行する際は、「ネットワーク」「認証・権限」「データ容量」の3 つの観点で徹底的に評価することが成功の鍵です。本節では、Google が公開している Database Migration assessment guide（日本語） に沿って、チェック項目と推奨設定を具体例付きで示します。
ネットワーク要件
データベース移行サービス (DMS) は、オンプレミス側と GCP 側の両方に直接アクセスできる必要があります。そのため VPC ピアリング／VPN の構成 と ファイアウォールルール が正しく設定されていなければ、接続テストすら通りません。
VPC ピアリングと VPN の基本構成
以下は一般的なオンプレミス ↔ GCP 接続パターンです。
| 項目 | 推奨設定例 |
|---|---|
| VPC | dms-vpc（カスタムサブネット）を作成し、プライベート IP 範囲 10.0.0.0/24 を割り当てる。 |
| VPN / Interconnect | Cloud VPN (IKEv2) または Dedicated Interconnect を用意し、オンプレミス側のルータと接続する。 |
| ピアリング | gcloud compute networks peerings create dms-to-onprem --network=dms-vpc --peer-network=onprem-vpc --auto-create-routes で相互ルートを自動生成。 |
| ファイアウォール | ソース DB のポート（PostgreSQL:5432、MySQL:3306、SQL Server:1433）へのインバウンド許可と、DMS が使用するサービス アカウントの IP 範囲だけを許可。 |
| DNS | Private DNS ゾーンで Cloud SQL のプライベート IP を名前解決できるように設定。 |
接続テストの実施方法
VPC ピアリングが完了したら、GCP 上の任意の Compute Engine インスタンスから 標準 ping コマンドで接続確認を行います。
|
1 2 3 |
# VM に SSH し、オンプレミス DB のプライベート IP に対して ping を実行 ping -c 3 10.1.2.34 # 例: PostgreSQL が稼働するサーバーの IP |
ping が成功すれば L3 通信は確立しています。続いて telnet（または nc）で DB ポートが開通しているかを確認しましょう。
|
1 2 3 |
# PostgreSQL の 5432 番ポートに対する接続テスト例 nc -zv 10.1.2.34 5432 |
認証・権限確認
DMS がデータ取得・書き込みを行うには、適切な IAM ロール と サービス アカウント の設定が必須です。誤ったロールや過剰な権限はセキュリティリスクにつながります。
必要な IAM ロール
| ロール | 主な権限 | 用途 |
|---|---|---|
roles/datamigration.admin |
DMS のジョブ作成・管理全般 | 移行プロジェクトの中心ロール |
roles/cloudsql.admin |
Cloud SQL インスタンスの作成・設定 | ターゲット DB 操作 |
roles/datastream.admin |
Datastream の CDC 設定・ストリーム管理 | 継続レプリケーション時に必須 |
roles/compute.networkAdmin（または roles/vpcaccess.user） |
VPC ピアリングや VPN の設定権限 | ネットワーク構築担当者向け |
サービス アカウントの作成とロール付与例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# 1. サービスアカウント作成 gcloud iam service-accounts create dms-sa \ --display-name="Database Migration Service SA" # 2. 必要ロールを一括で付与 gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:dms-sa@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/datamigration.admin" gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:dms-sa@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/cloudsql.admin" gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:dms-sa@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/datastream.admin" gcloud projects add-iam-policy-binding $PROJECT_ID \ --member="serviceAccount:dms-sa@$PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/compute.networkAdmin" |
ロール付与後は、gcloud iam test-permissions で実際に必要な権限が有効か検証できます。
|
1 2 3 |
gcloud iam test-permissions dms-sa@$PROJECT_ID.iam.gserviceaccount.com \ --permissions=datamigration.jobs.create,cloudsql.instances.update |
データサイズとスキーマ把握
データ容量とスキーマの複雑度は、一次ロードか継続レプリケーションか の選択基準となります。正確な測定ができていないと、予算超過やダウンタイム延長のリスクがあります。
容量測定の実践例
- PostgreSQL:
SELECT pg_total_relation_size('public.my_table') AS size; - MySQL:
SELECT table_schema, SUM(data_length + index_length) / 1024/1024 AS mb FROM information_schema.tables GROUP BY table_schema; - SQL Server:
EXEC sp_spaceused;
取得した合計サイズが 200 GB 超 の場合は、一次ロードだけでは時間がかかりすぎるため Datastream + 継続レプリケーション を検討します。
スキーマ変更頻度の評価
スキーマが頻繁に変わる環境（例: 毎週 DDL 追加）がある場合は、移行前に DDL 差分抽出ツール（pg_dump --schema-only、mysqldump --no-data）で差分を取得し、ターゲット側に事前適用しておくと、本番切り替え時のエラーを防げます。
移行対象データベースの選定と GCP 推奨先
ソース DB の種類と業務要件（レイテンシ、可用性、分析ニーズ）に応じて、最適なマネージドサービスを選択します。以下は主要 DB と推奨 GCP 先の比較表です。
| ソース DB | 推奨 GCP 先 | 主なメリット | 注意点 |
|---|---|---|---|
| PostgreSQL (9.6‑13) | Cloud SQL for PostgreSQL / AlloyDB for PostgreSQL | フルマネージド、パラメータ互換性が高い。AlloyDB は高速 OLTP＋分析向けに最適化。 | バージョン差異がある場合は事前テスト必須 |
| MySQL (5.7‑8.0) | Cloud SQL for MySQL | 自動スケーリング、Read Replica による負荷分散 | 一部 InnoDB 固有機能（例: 表領域圧縮）が非対応 |
| Microsoft SQL Server (2016‑2019) | Cloud SQL for SQL Server | Windows ライセンス不要、バックアップ自動化 | datetime2 など一部データ型変換に注意 |
| Oracle (12c‑19c) | AlloyDB (PostgreSQL 互換) + 外部フェデレーション | 高性能分析、Google AI/ML とシームレス連携 | 完全な Oracle 互換は不可。スキーマ変換が必要 |
選定の指針
- トランザクション中心か分析中心か → AlloyDB が有利。
- レガシー機能が多いか → Cloud SQL の方が互換性が高い。
Database Migration Service のセットアップ手順
DMS を本格運用するまでに必要な工程は 「プロジェクト／サービスアカウント作成」→「VPC ピアリング構築」→「ジョブ作成」 の 3 段階です。ここでは実際のコンソール操作と CLI コマンドを交えて、最小権限かつ安全な構成例を示します。
プロジェクト・サービス アカウント作成
まずは DMS 専用のプロジェクトを立ち上げ、最小特権で動作するサービス アカウントを作ります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# 1. プロジェクト作成（例: dms-migration-2026） gcloud projects create dms-migration-2026 --name="DMS Migration Project" # 2. 請求先アカウントの紐付け（必要に応じて） gcloud beta billing projects link dms-migration-2026 --billing-account=012345-6789AB-CDEF01 # 3. DMS API 有効化 gcloud services enable datamigration.googleapis.com # 4. サービス アカウント作成 gcloud iam service-accounts create dms-sa \ --display-name="Database Migration Service SA" # 5. 必要ロール付与（前節参照） for ROLE in roles/datamigration.admin roles/cloudsql.admin roles/datastream.admin roles/compute.networkAdmin; do gcloud projects add-iam-policy-binding dms-migration-2026 \ --member="serviceAccount:dms-sa@dms-migration-2026.iam.gserviceaccount.com" \ --role="$ROLE" done |
ポイント
キーは不要です。DMS は Cloud IAM の認可情報を直接参照するため、キー管理の負荷が減ります。
VPC ピアリング構築
オンプレミスと GCP 間のプライベート接続を確立し、ファイアウォールで必要ポートだけを許可します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# 1. GCP 側 VPC 作成（カスタムサブネット） gcloud compute networks create dms-vpc --subnet-mode=custom gcloud compute networks subnets create dms-subnet \ --network=dms-vpc \ --range=10.0.0.0/24 \ --region=asia-northeast1 # 2. Cloud VPN（例: 静的ルート方式）をオンプレミス側と協議の上作成 # → ここでは省略。VPN 接続が完了したことを前提に進めます。 # 3. VPC ピアリング設定 gcloud compute networks peerings create dms-to-onprem \ --network=dms-vpc \ --peer-network=onprem-vpc \ --auto-create-routes # 4. 接続テスト（VM 上で実行） ping -c 3 <オンプレミス DB のプライベート IP> nc -zv <オンプレミス DB のプライベート IP> 5432 # PostgreSQL の例 |
ピアリングが正常に機能すれば、ファイアウォールで許可したポートだけが通過し、安全に DMS がデータ取得できる状態です。
移行ジョブの作成と実行
DMS コンソール（または gcloud datamigration jobs）から 一次ロード と 継続レプリケーション のどちらかを選択します。ここでは代表的な 2 パターンを示します。
一次ロード（ダンプ方式）
- 対象データが 100 GB 以下、スキーマ変更頻度が低いケースに最適です。
- ジョブ作成後は DMS が自動で
pg_dump/mysqldumpを実行し、Cloud Storage 経由でターゲットにインポートします。
|
1 2 3 4 5 6 |
# コンソール例（GUI 操作）： # 1. 「Database Migration」→「ジョブ作成」→「一次ロード」を選択 # 2. ソース接続情報（例: postgresql://user@10.0.0.5:5432/db） # 3. ターゲットは Cloud SQL for PostgreSQL のインスタンスを指定 # 4. 「開始」ボタンでジョブが走り、完了後に検証レポートが表示される |
継続レプリケーション + Datastream
- 300 GB 超 の大規模 DB や ダウンタイムゼロ が要求される場合は、Datastream による CDC と組み合わせます。
- ソースとターゲットの接続プロファイルを作成し、ストリームを起動するだけでリアルタイムにデータが同期します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
# 1. Datastream 用ソース接続（MySQL on-prem の例） gcloud datastream connection-profiles create mysql-source \ --display-name="OnPrem MySQL" \ --type=mysql \ --hostname=10.0.1.20 \ --port=3306 \ --username=db_user \ --password=******** # 2. Cloud SQL for PostgreSQL 用ターゲット接続 gcloud datastream connection-profiles create cloudsql-target \ --display-name="Target PG" \ --type=postgresql \ --hostname=<cloudsql-private-ip> \ --port=5432 \ --username=pg_user \ --password=******** # 3. ストリーム作成・実行 gcloud datastream streams create mysql-to-pg \ --source=mysql-source \ --destination=cloudsql-target \ --display-name="MySQL→PostgreSQL CDC" \ --state=RUNNING |
ポイント
datastream logs readでエラーログを随時確認し、スキーマ変更が発生した場合は DMS コンソールの「スキーマ変換マッピング」から事前にマッピング定義を追加しておきます。
カットオーバーとロールバック手順
- 最終増分取得
- Datastream を一時停止し、残り差分を
pg_dumpで取得。 - ソース DB のリードオンリー化（例: PostgreSQL）
sql
ALTER DATABASE mydb SET default_transaction_read_only = on; - ターゲット側に増分インポート
- アプリケーションの接続文字列を GCP エンドポイントへ切替
- 正常稼働確認後、ソース DB を停止（ロールバックが必要な場合は事前にスナップショット取得）
上記手順は本番環境で実施する前に ステージング環境でリハーサル し、所要時間と障害時の復旧フローを文書化しておくことが重要です。
ポストマイグレーションタスクと代替手段比較
移行完了後も パフォーマンス最適化・IAM ガバナンス・監視設定 が欠かせません。また、DMS 以外の従来手法との比較表を示し、選択基準を明確にします。
インデックス再構築と統計情報更新
一次ロードではテーブルデータのみが転送され、インデックスや統計は自動で作成されません。以下のコマンドで最適化しましょう。
|
1 2 3 4 5 6 |
-- 統計情報の更新（PostgreSQL の例） VACUUM ANALYZE; -- 大規模テーブルのインデックス再構築 REINDEX TABLE large_table; |
実施タイミングは 移行完了後 1〜2 時間以内 が推奨です。ベンチマーク（pgbench 等）で平均レイテンシが約 20 % 改善することが報告されています。
IAM と監視設定
| 項目 | 推奨内容 |
|---|---|
| IAM ロール | アプリケーションのサービス アカウントに roles/cloudsql.client のみ付与し、管理者権限は別アカウントで保持。 |
| モニタリング | Cloud Monitoring で CPU 使用率 > 80 %（5 分間連続）やスロークエリ数増加時に Slack / PagerDuty へ通知するアラートポリシーを作成。 |
| ログエクスポート | Cloud Logging の cloudsql.googleapis.com/mysql_slow.log を BigQuery にエクスポートし、月次でスロークエリ分析レポートを生成。 |
公式ドキュメントは Cloud Monitoring 監視設定ガイド（日本語） を参照してください。
代替手段との比較指針
| 手法 | 主なメリット | デメリット・留意点 |
|---|---|---|
| DMS（一次ロード） | 設定がシンプル、フルマネージドで運用負荷低減 | 大容量データでは時間がかかる。増分同期は別途構築必要 |
| DMS + Datastream（継続レプリケーション） | ダウンタイム最小化、リアルタイム CDC が可能 | 初期設定がやや複雑、Datastream の課金が追加で発生 |
手動ダンプ／インポート（mysqldump, pg_dump） |
ツールが汎用的で自由度高い | 手作業が多く、リトライやエラーハンドリングが自己責任 |
| 従来レプリケーション（MySQL Replication, Oracle GoldenGate 等） | 既存ノウハウ活用可能、リアルタイム性が高い | 管理対象が増える。GCP 側で受信側を自前で構築する必要あり |
選定の目安
- データサイズ ≤ 100 GB・ダウンタイム許容 1 h 以上 → 一次ロードが最もコスト効率的。
- データサイズ > 300 GB・ダウンタイムを数分に抑えたい → DMS + Datastream がベストプラクティス。
記事まとめ
- 移行前チェック：ネットワーク（VPC ピアリング／VPN、ファイアウォール）、認証・権限（
roles/datamigration.adminなどの最小ロール）、データ容量とスキーマを評価し、抜け漏れ防止リストを作成する。 - ターゲット選定：ソース DB の特性に合わせて Cloud SQL または AlloyDB を選び、バージョン互換テストを実施。
- 安全な基盤構築：専用プロジェクトと最小権限のサービス アカウントで DMS 環境を作り、VPC ピアリングでプライベート接続を確立。接続は VM 上の標準
ping/ncで検証。 - ジョブタイプ選択：データサイズとダウンタイム要件に応じて一次ロードか継続レプリケーション（Datastream）を決定し、カットオーバー手順とロールバックプランをリハーサル。
- ポストマイグレーション：インデックス再構築・統計情報更新でパフォーマンス最適化、IAM の最小権限化と Cloud Monitoring で運用監視を設定。
- 代替手段比較：コスト・ダウンタイム・管理負荷の観点から DMS 系列と従来手法を比較し、自社要件に最適な方法を選択する。
上記ステップを体系的に実施すれば、GCP へのデータベース移行に伴うリスクは大幅に低減し、スムーズな本番切り替えが可能です。
参考リンク（日本語）
- Database Migration assessment guide
- VPC ピアリングの概要
- Database Migration Service 公式ページ
- Datastream ドキュメント
- Cloud Monitoring アラート設定ガイド