Database Migration Service

解決する課題

オンプレミスや他クラウド、あるいは古いDBから Google Cloud のマネージドDBへ、サービスを止めずに移行したい場面で使います。手作業のダンプ・リストアでは長い停止時間とデータの取りこぼしが避けられません。

• 一括ダンプ＆リストアだと移行中ずっとサービスを止める必要がある → 継続レプリケーションで**最小停止（最小ダウンタイム）**にしたい
• 移行ツールの構築・運用が重い → マネージドな移行サービスに任せたい
• 古い商用DB（例: Oracle）から PostgreSQL 系へ載せ替えたい（異種移行）が、自前変換は難しい
• 移行後に継続的に同期し、切り替え（カットオーバー）のタイミングを自分で選びたい

主要概念と用語

• 移行ジョブ（Migration job）: 1回の移行を表す単位。接続プロファイルと組み合わせて作成し、開始・一時停止・昇格などを操作する
• 接続プロファイル（Connection profile）: ソースDB／デスティネーションへの接続情報（ホスト・認証・ネットワーク）を保存した再利用可能な設定
• 同種移行（Homogeneous）: 同じエンジン間の移行。例として PostgreSQL から Cloud SQL for PostgreSQL、MySQL から Cloud SQL for MySQL など
• 異種移行（Heterogeneous）: 異なるエンジン間の移行。例として Oracle から Cloud SQL for PostgreSQL や AlloyDB for PostgreSQL。スキーマや型の変換を伴う
• 初期ダンプ（フルロード）と継続的変更データ取り込み（CDC）: まず既存データを一括コピーし、その後ソースの変更をログから読み取って継続レプリケーションする2段構え
• 昇格（Promote / カットオーバー）: レプリケーションを止め、デスティネーションを独立した本番DBとして切り離す操作。これを行ったタイミングが実質の切り替え時点
• 接続方式: VPC ピアリング、プライベート接続、許可リスト方式、リバースSSHトンネルなど、ネットワーク構成に応じた経路

仕様・制限・クォータ

• ソースはオンプレミス・他クラウド・Compute Engine 上の自己管理DB・他のマネージドDBなどに対応。デスティネーションは Cloud SQL や AlloyDB for PostgreSQL といった Google Cloud のマネージドDBが中心
• 継続レプリケーションは、ソースDBの論理レプリケーションやログ（CDC）機能に依存するため、ソース側で事前設定（権限付与・ログ有効化など）が必要
• 異種移行ではすべてのオブジェクトが自動変換されるわけではない。一部のストアドプロシージャや独自機能は手動対応が必要になることがある
• 大きなオブジェクトや特定のデータ型、巨大トランザクションには扱い上の制限がある場合がある
• 同時に実行できる移行ジョブ数などにはプロジェクト単位のクォータがあり、必要に応じて引き上げを申請する
• 対応エンジンやバージョンの組み合わせは更新されるため、移行前に公式ドキュメントでサポートマトリクスを確認する

内部の仕組み

• 2段階のデータ移動: 最初に既存データを**初期ダンプ（フルロード）でコピーし、その間およびその後にソースで発生した変更をCDC（変更データ取り込み）**でログから読み取り、デスティネーションへ継続適用します
• 継続レプリケーション: フルロード完了後もソースとデスティネーションを同期し続けるため、アプリは移行作業中もソースで稼働し続けられます。差分が追いついた状態で任意の時点に切り替えられます
• 昇格（カットオーバー）: アプリの書き込みを止めてレプリケーション遅延がゼロになったのを確認し、移行ジョブを昇格するとデスティネーションが独立DBになります。以後はデスティネーション側を本番として運用します
• 異種移行の変換: ソースのスキーマ・データ型をデスティネーションのエンジンに合わせて変換し、変換できない部分は移行前に評価・通知されます

設計パターン / ベストプラクティス

• 本番移行の前に検証用の移行ジョブを一度回し、ロード時間・遅延・アプリ互換性を確認してから本番カットオーバーを計画する
• カットオーバーはレプリケーション遅延が小さくなった時間帯に実施し、アプリの書き込み停止時間を最小化する
• 接続は**プライベート接続（VPC ピアリング等）**を基本にし、ソースDBをインターネットへ広く公開しない
• 異種移行では**事前評価（アセスメント）**で変換不可オブジェクトを洗い出し、移行計画に手動対応のタスクを組み込む
• 切り替え後すぐにロールバック手順（元のソースへ戻す経路）を用意しておき、想定外の不整合に備える
• デスティネーション（Cloud SQL / AlloyDB）は移行前にHA・バックアップ・PITRを設計しておき、本番化と同時に可用性要件を満たす

運用・監視

• Cloud Monitoring / Cloud Logging で移行ジョブの状態、フルロードの進捗、レプリケーション遅延を可視化する
• 移行ジョブのステータス（実行中・一時停止・エラー・昇格済み）を監視し、エラー時はログでソース接続や権限を確認する
• 接続できないときはネットワーク経路（VPC ピアリング・許可リスト・トンネル）とソース側のレプリケーション権限を点検する
• 長時間の移行では、初期ロード完了後の遅延がゼロ付近に収束しているかを継続確認してからカットオーバーする

コスト

Database Migration Service 自体は、Google Cloud のマネージドDBをデスティネーションとする同種移行が無料で提供される範囲があります。一方で、移行に伴って次のコストが発生する点に注意します。

• デスティネーションDBの料金（Cloud SQL / AlloyDB のインスタンス・ストレージ・HA など）は通常どおり課金される
• **ネットワーク（下り/エグレスや相互接続）**の通信料が移行データ量に応じて発生し得る
• 異種移行や付随するコンピューティングリソースには別途費用がかかる場合がある

正確な料金は変動するため、移行データ量とデスティネーション構成をもとに公式の料金ページで見積もるのが確実です。

セキュリティ

• 接続情報は接続プロファイルに保存され、認証情報の取り回しを一元化できる
• 経路は**プライベート接続（VPC 内）**を基本にし、ソースを公開ネットワークへ晒さない構成を推奨
• 転送時はSSL/TLS を用い、リバースSSHトンネルなどで暗号化された経路を確保できる
• デスティネーションの Cloud SQL / AlloyDB は保存時暗号化がデフォルトで有効で、必要に応じて CMEK（Cloud KMS） も利用できる
• 移行用のユーザーには移行に必要な最小権限だけを付与し、移行完了後は権限・接続プロファイルを整理する

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: マネージドな移行ジョブにより、移行ツールの自前構築・運用を避けられる。検証ジョブとカットオーバー手順を定型化することで、移行作業を再現性高く回せる
• 信頼性（Reliability）: 継続レプリケーションで最小停止のカットオーバーを実現し、移行中もサービスを止めない。デスティネーションを HA・バックアップ込みで設計しておくことで、本番化と同時に可用性を確保できる。ロールバック経路を用意して移行失敗時の復旧性も担保する

試験で問われるポイント

関連サービス・比較

Google Cloud の Database Migration Service は、AWS の Database Migration Service（AWS DMS）に対応する位置づけです。

ハンズオン / CLI例

# ソースDB（自己管理 PostgreSQL）への接続プロファイルを作成
gcloud database-migration connection-profiles create postgresql source-pg \
  --region=asia-northeast1 \
  --host=10.0.0.10 \
  --port=5432 \
  --username=migration_user \
  --password='CHANGE_ME_USE_SECRET_MANAGER'

# デスティネーション（Cloud SQL for PostgreSQL）への接続プロファイルを作成
gcloud database-migration connection-profiles create cloudsql dest-cloudsql \
  --region=asia-northeast1 \
  --cloudsql-instance=app-db

# 継続レプリケーション（CDC）込みの移行ジョブを作成
gcloud database-migration migration-jobs create pg-to-cloudsql \
  --region=asia-northeast1 \
  --type=CONTINUOUS \
  --source=source-pg \
  --destination=dest-cloudsql

# 移行ジョブを開始（初期ロード後、継続レプリケーションへ）
gcloud database-migration migration-jobs start pg-to-cloudsql \
  --region=asia-northeast1

# 遅延が収束したらカットオーバー（昇格してデスティネーションを独立化）
gcloud database-migration migration-jobs promote pg-to-cloudsql \
  --region=asia-northeast1