🎯 1. DMS vs Datastream を完全理解
| 観点 | DMS | Datastream |
|---|
| 目的 | DB の完全移行（プライマリ切替） | CDC イベントの継続流し込み |
| ターゲット | Cloud SQL / AlloyDB | BigQuery / GCS / Pub/Sub |
| プライマリ切替 | あり (Promote) | なし (ソースが Primary のまま) |
| 用途 | リフトアンドシフト | ハイブリッド・分析統合 |
| 対応ソース | MySQL / PG / SQL Server / Oracle 等 | MySQL / PG / Oracle / SQL Server / MongoDB |
一発判定: 「DBを移行する」 = DMS。「変更を他システムに流す」 = Datastream。
🚀 2. ゼロダウンタイム移行: 完全フロー
┌─ Phase 0: 準備 ────────────────────────────────────────┐
│ ├ ソース DB バックアップ │
│ ├ ターゲット DB 構築 (HA 構成) │
│ ├ ネットワーク確立 (VPN / Cloud Interconnect) │
│ ├ DMS ジョブ準備 (Continuous モード) │
│ └ アプリ側で「読み取り用」「書き込み用」接続を分離 │
└─────────────────────────────────────────────────────────┘
↓
┌─ Phase 1: 初期移行 ────────────────────────────────────┐
│ ├ DMS スナップショット取得 (数時間〜) │
│ ├ CDC 開始 (バイナリログ / WAL から継続適用) │
│ └ レプリ遅延を継続監視 (< 5秒目標) │
└─────────────────────────────────────────────────────────┘
↓
┌─ Phase 2: テスト ──────────────────────────────────────┐
│ ├ ステージング環境でカットオーバー リハーサル │
│ ├ 整合性チェック (行数・サンプル・ハッシュ) │
│ └ アプリ E2E テスト (読み取りを新DBへ) │
└─────────────────────────────────────────────────────────┘
↓
┌─ Phase 3: カットオーバー (実行) ───────────────────────┐
│ ├ アプリの書き込みを一時停止 (数秒) │
│ ├ 残りのバイナリログが適用完了まで待機 │
│ ├ DMS Promote (新DBを Primary に昇格) │
│ ├ アプリの接続先を新DBへ切替 │
│ └ 書き込み再開 │
└─────────────────────────────────────────────────────────┘
↓
┌─ Phase 4: 後処理 ──────────────────────────────────────┐
│ ├ リバースレプリケーション開始 (新→旧、保険) │
│ ├ 監視強化 (CPU/接続/エラー) │
│ ├ 数日〜数週間の様子見 │
│ └ 問題なければ旧DB廃止 │
└─────────────────────────────────────────────────────────┘
📋 3. カットオーバー時のチェックリスト
- レプリ遅延 < 5秒
- アプリの書き込みフラグを停止モードに
- DMS が「ready to promote」状態
- DNS / 接続文字列の変更準備完了
- ロールバック手順を関係者で共有
- 監視・アラート画面をリアルタイム表示
- カットオーバー時の責任者 + コミュニケーションチャネル確定
🌐 4. AWS RDS → Cloud SQL 移行（クロスクラウド）
手順
- AWS RDS でバイナリログ有効化（automated backups 有効が前提）
- AWS RDS → GCP の VPN または Cloud Interconnect 接続確立
- AWS RDS に replica ユーザー 作成
- Google Cloud で DMS Continuous ジョブ 作成（ソース = AWS RDS）
- 初期スナップショット + CDC レプリ開始
- カットオーバー
注意点: AWS DMS（Amazon の DMS）ではなく、Google Cloud の DMS が AWS RDS をソースに対応している。
🛡 5. Oracle → AlloyDB 異種移行
必要なステップ
- DMA (Database Migration Assessment) で変換難易度を評価
- Ora2Pg / DMS Migration Assistant でスキーマ変換
- 手動移行が必要なもの:
- PL/SQL ストアドプロシージャ → PL/pgSQL に書き換え
- DBMS_* パッケージ → 代替関数
- マテリアライズドビュー（更新仕様差注意）
- カスタムドメイン型
- DMS Heterogeneous ジョブで初期 + CDC
- カットオーバー後、リバースレプリは Striim で実装
🔄 6. リバースレプリケーション パターン
同種 DB の場合
新 Primary
↓ DMS (逆方向ジョブ)
旧 DB (リードレプリカ状態)
数日〜数週間運用後、問題なければ停止。シンプル。
異種 DB の場合
新 PostgreSQL
↓ Striim or 手動 CDC
旧 Oracle
商用ツール (Striim) や手動構築。複雑度高、テスト必須。
🔍 7. 整合性検証 4 階層
- 行数チェック —
SELECT COUNT(*) を旧新で比較（最も基本）
- ハッシュチェック —
MD5(STRING_AGG(column1::text, '' ORDER BY id)) で全体を厳密比較
- サンプリングチェック — ランダム n 行を抽出し詳細比較（NULL/空文字に注意）
- アプリ E2E テスト — 主要業務フローを実行（最終確認）
🚫 8. 移行プロジェクトで起きやすい失敗 TOP 5
- 事前テスト不足 → 本番でアプリが動かない
- ロールバック計画なし → 問題発生時に詰む
- DDL/DML 互換性確認漏れ → ストアドプロシージャが動かない
- DMS 遅延の監視不足 → カットオーバーで詰む
- コミュニケーション不足 → カットオーバー中にアプリ側が動けない
💡 9. シナリオ別の正解パターン
| シナリオ | 正解 |
|---|
| MySQL → Cloud SQL MySQL (ニアゼロ) | DMS Continuous |
| PostgreSQL → AlloyDB | DMS Continuous |
| SQL Server → Cloud SQL PostgreSQL (異種) | DMS Heterogeneous |
| Oracle → AlloyDB | DMS Heterogeneous / Ora2Pg + DMS |
| Oracle 移行で固有機能フル活用 | Bare Metal Solution (リフトアンドシフト) |
| Oracle の変更を BigQuery 分析 | Datastream |
| MySQL の変更を Pub/Sub に流す | Datastream |
| >10TB のオフライン転送 | Transfer Appliance |
| S3 → GCS | Storage Transfer Service |
| MongoDB アプリ移行 | Firestore (MongoDB-compatible) + mongodump/restore |
| AWS RDS → Cloud SQL | Google Cloud DMS (AWS RDS をソース対応) |