Section 3 — 基礎編：DB 移行の全体像と主要ツール

📘 対象: 全員（必読） ゴール: 移行ツールの全体像を理解し、シナリオに応じた 基本的な選定 ができる。

1. DB 移行の 5 ステップ

クラウド移行は大きく 5 ステップに分かれます。試験ではこのフェーズ単位で問題が出ます。

┌─────────────────────────────────────────────────────────┐
│ Step 1: アセスメント (Assessment)                        │
│   - 現状把握: DB 種別、サイズ、QPS、依存関係             │
│   - ダウンタイム許容度の確認                              │
│   - コンプライアンス・規制の確認                          │
├─────────────────────────────────────────────────────────┤
│ Step 2: 計画 (Planning)                                  │
│   - 移行戦略選定（リフトアンドシフト/モダナイズ）         │
│   - ツール選定（DMS / Datastream / 手動）                │
│   - スケジュール・体制・ロールバック計画                  │
├─────────────────────────────────────────────────────────┤
│ Step 3: テスト (Testing)                                 │
│   - 開発環境で移行リハーサル                              │
│   - データ整合性検証                                      │
│   - アプリ互換性確認                                      │
├─────────────────────────────────────────────────────────┤
│ Step 4: 実行 (Execution)                                 │
│   - 初期スナップショット                                   │
│   - CDC（変更データキャプチャ）でレプリケーション継続     │
│   - カットオーバー（アプリの接続先切替）                  │
├─────────────────────────────────────────────────────────┤
│ Step 5: 検証と最適化 (Validation & Optimization)         │
│   - データ整合性最終確認                                  │
│   - 性能監視・チューニング                                │
│   - 旧 DB の最終的な廃止                                  │
└─────────────────────────────────────────────────────────┘

2. 移行ツール早見表

Google Cloud のマネージド移行ツール

ツール	何をするか	推奨シナリオ
Database Migration Service (DMS)	DB 移行（同種・異種） + 連続レプリケーション	DB の完全移行（プライマリ切替を伴う）
Datastream	CDC（変更データキャプチャ）	移行 + 連携。BigQuery/GCS/Pub-Sub への流し込み
BigQuery Data Transfer Service	BigQuery へのデータ転送	他DWH/SaaS → BigQuery
Storage Transfer Service	大量オブジェクト転送	S3 → GCS、オンプレ → GCS
Transfer Appliance	物理アプライアンスで大容量データ転送	>10TB のオフライン転送、ネットワーク帯域不足

その他のツール

ツール	特徴	試験での扱い
mysqldump / pg_dump	論理ダンプ	小規模、ダウンタイム許容
mydumper / myloader	パラレル mysqldump	中規模
gh-ost / pt-online-schema-change	オンラインスキーマ変更	スキーマ変更を含む移行
Striim	パートナーCDCツール	DMS で対応していない異種移行
Ora2Pg	Oracle → PostgreSQL 変換	異種移行の DDL/DML 変換

3. Database Migration Service (DMS) 詳細

DMS の対応マトリクス（2026年5月時点）

ソース	ターゲット	同種/異種
MySQL（オンプレ・他クラウド）	Cloud SQL MySQL	同種
PostgreSQL	Cloud SQL PostgreSQL	同種
PostgreSQL	AlloyDB	同種（PG → AlloyDB）
SQL Server	Cloud SQL SQL Server	同種
Oracle	Cloud SQL PostgreSQL	異種
Oracle	AlloyDB	異種
SQL Server	Cloud SQL PostgreSQL	異種

DMS の動作モード

モード	動作
One-time (Snapshot)	一括スナップショット転送のみ。CDCなし
Continuous (Recommended)	初期スナップショット + 継続CDC。ニアゼロダウンタイム

DMS の典型的なフロー

┌─ ソース DB（オンプレ MySQL） ─┐
│                                │
│   バイナリログ有効化           │
│   replica ユーザー作成         │
└─────────────────┬──────────────┘
                  │ ① 接続情報 + クレデンシャル登録
                  ↓
┌─ Database Migration Service ──┐
│   ジョブ作成                    │
│   モード: Continuous           │
└─────────────────┬──────────────┘
                  │ ② 初期スナップショット転送
                  ↓
┌─ Cloud SQL MySQL ─────────────┐
│   ※ 移行中はリードレプリカ状態 │
│   (Migration Job が完了するまで)│
└─────────────────┬──────────────┘
                  │ ③ binary log を継続適用 (CDC)
                  ↓
              (時間経過、アプリは旧 DB を利用)
                  │
                  │ ④ Promote ボタン押下
                  ↓
┌─ Cloud SQL MySQL (Primary) ───┐
│   読み書き可能に                │
│   アプリの接続先を切替         │
└────────────────────────────────┘

DMS のメリット

Google マネージド → 運用負荷なし
連続レプリケーション → ダウンタイム数十秒〜数分
無料（コンピュート・ストレージのみ課金）
異種DB対応 が拡大中

DMS の制約

DMS は DDL を完全サポートしない（特に異種移行で）
スキーマ変換は DMS Migration Assistant や手動で対応
一部のオブジェクト（ストアドプロシージャ、トリガー）は要手動移行

4. Datastream 詳細

Datastream とは

CDC（Change Data Capture） に特化したマネージドサービス。「DB を移行する」のではなく、「DB の変更を別のサービスにストリーミングする」用途。

Datastream のソース・ターゲット

ソース	ターゲット
Oracle	BigQuery / GCS / Pub/Sub
MySQL	BigQuery / GCS / Pub/Sub
PostgreSQL	BigQuery / GCS / Pub/Sub
SQL Server	BigQuery / GCS / Pub/Sub
MongoDB	BigQuery / GCS / Pub/Sub

Datastream のユースケース 3 つ

リアルタイム分析: OLTP の変更を BigQuery にストリーミングし、即時ダッシュボード
イベント連携: DB の変更を Pub/Sub に流し、他システムを駆動
データレイク投入: DB のスナップショット + CDC を GCS に投入し、Dataproc/Dataflow で処理

Datastream と DMS の違い

観点	DMS	Datastream
目的	DB の完全移行（プライマリ切替）	CDC イベントの継続流し込み
ターゲット	Cloud SQL / AlloyDB	BigQuery / GCS / Pub/Sub
プライマリ切替	あり（Promote）	なし（ソースが Primary のまま）
用途	リフトアンドシフト	ハイブリッド・分析統合

試験パターン

「MySQL を AlloyDB に移行 + アプリの接続先を変更」→ DMS
「オンプレ Oracle の変更をリアルタイムで BigQuery 分析」→ Datastream
「PostgreSQL の変更を Pub/Sub に流して他システム駆動」→ Datastream

5. その他のシナリオ別ツール選定

シナリオ別マップ

シナリオ	推奨ツール
MySQL → Cloud SQL MySQL	DMS
PostgreSQL → AlloyDB	DMS
SQL Server → Cloud SQL SQL Server	DMS
Oracle → Cloud SQL/AlloyDB（移行）	DMS（異種、特定構成） or Striim
Oracle → BigQuery（分析統合）	Datastream
Oracle → Bare Metal Solution	リフトアンドシフト（オフライン or 物理移送）
10TB 超のオフライン転送	Transfer Appliance
S3 → Cloud Storage	Storage Transfer Service
MongoDB → Firestore (MongoDB-compatible)	mongoexport + mongoimport / Datastream + 中継

6. 移行戦略の典型パターン

パターン 1: ゼロダウンタイム（Continuous DMS）

旧 DB (Primary) ───>  DMS Continuous  ───>  Cloud SQL (Replica)
   ↑                                              ↓ ④Promote
アプリ                                        Cloud SQL (Primary)
                                                  ↑
                                              アプリ（接続先切替）

ダウンタイム: 数十秒〜数分
適用: 業務クリティカル、ECサイト、SaaS

パターン 2: 短時間ダウンタイム（一括移行）

旧 DB ───[mysqldump]───>  Cloud Storage  ───>  Cloud SQL
                              （アプリ停止中に実行）

ダウンタイム: 数時間
適用: 中小規模、夜間メンテ可能

パターン 3: ラージスケールオフライン（Transfer Appliance）

オンプレ DB ───[エクスポート]───>  Transfer Appliance（物理 RAID）
                                          ↓ 物理輸送
                                    Google データセンター
                                          ↓ アップロード
                                    Cloud Storage ───>  Cloud SQL

ダウンタイム: 数日（許容できる場合）
適用: 数十TB〜PB規模、ネットワーク帯域不足

パターン 4: ハイブリッド継続（Datastream）

オンプレ DB (Primary、変更なし) ───>  Datastream  ───>  BigQuery
                                                       Pub/Sub
                                                       GCS

ダウンタイム: ゼロ（プライマリは旧のまま）
適用: 旧 DB を残しつつ分析だけクラウドへ

7. フォールバックとリバースレプリケーション

フォールバック（Fallback）とは

移行後に 問題が発生した場合に旧 DB に戻す 仕組み。

リバースレプリケーション

移行後に 新 DB の変更を旧 DB に同期 することで、フォールバックを可能にする手段。

典型的なフロー

Step 1: DMS で旧 → 新 へ初期移行 + CDC
Step 2: カットオーバー（新 DB を Primary に昇格、アプリ切替）
Step 3: 新 → 旧 へリバースレプリケーション開始（保険）
Step 4: 数日〜数週間、新DBで運用継続
Step 5: 問題なければリバースレプリケーション停止、旧 DB 廃止

リバースレプリケーションの実装

DMS は逆方向の DMS ジョブ作成（新→旧）
異種の場合、Striim や手動の Logical Replication で対応

8. 移行のリスクと対策

よくあるリスク

リスク	対策
データ消失	移行前フルバックアップ + DMS Continuous の遅延監視
データ不整合	移行後のチェックサム比較、行数一致確認
アプリ互換性問題	テスト環境で事前検証、特に SQL 関数差
性能劣化	移行後の Query Insights で監視、必要なら最適化
コスト超過	移行中の DMS / レプリカのコスト計算、予算アラート

整合性確認のテクニック

行数比較: SELECT COUNT(*) FROM table を旧新で比較
チェックサム: pg_dump の --quote-all-identifiers で論理比較
サンプルレコード: ランダム n 行を抽出し詳細比較
アプリの実 E2E テスト が最終確認

9. このセクションのチェックリスト

移行 5 ステップを言える
DMS の対応マトリクス（ソース ⇄ ターゲット）を即答できる
DMS の Continuous モードの動作を説明できる
DMS と Datastream の違いを区別できる
Datastream のユースケース 3 つを挙げられる
Transfer Appliance を選ぶ条件を言える
ゼロダウンタイム移行のフローを言える
フォールバックとリバースレプリケーションの役割を説明できる
移行のリスク 5 つに対して対策を言える
整合性確認の手法を 3 つ挙げられる