1. DMS vs Datastream の本質的差
| 観点 | DMS | Datastream |
|---|
| 目的 |
DB の完全移行（プライマリ切替） |
CDC イベントの継続配信 |
| ターゲット |
Cloud SQL / AlloyDB |
BigQuery / Cloud Storage / Pub/Sub |
| プライマリ切替 |
あり (Promote) |
なし（ソースは Primary のまま） |
| ソース DB |
MySQL / PG / SQL Server / Oracle (Hetero) |
Oracle / MySQL / PG / SQL Server / MongoDB / Salesforce / Spanner |
| 料金 |
無料（ターゲットDB のリソース費のみ） |
GiB 単位の従量課金 |
| 用途 |
リフトアンドシフト、Blue-Green |
分析統合、イベント駆動、ハイブリッド |
シンプルな見極め: 「DB を別の DB に置き換える」のが目的なら DMS。「DB の変更を別のサービスに流したい」のが目的なら Datastream。
2. DMS の動作モデルと前提条件
2-1. DMS の 2 つのモード
| モード | 動作 | ダウンタイム | 用途 |
|---|
| One-time (Snapshot) |
一括スナップショット転送のみ |
転送中はソースを止める |
夜間メンテで完了する小〜中規模 |
| Continuous (CDC) |
初期スナップショット + 継続 CDC |
カットオーバー時のみ数秒〜数分 |
業務クリティカル |
2-2. Continuous モードの動作タイムライン
-
準備 (Setup)
ソース DB の logical replication 有効化、replica ユーザー作成、ネットワーク確立
-
初期 Dump 開始
DMS がソースから論理ダンプを抽出し、ターゲット DB に流し込む（数時間〜）
-
CDC 開始
WAL / binary log の特定 LSN から CDC が走り、ダンプ完了後のデータ変更を継続適用
-
Replicas Sync 状態
ターゲットは Read-only Replica として動作。レプリ遅延を継続監視
-
Promote
アプリの書き込みを停止 → 残ログ適用完了を待つ → Promote ボタン → 新 DB が Primary に
3. PostgreSQL ソースの設定詳細
pglogical 拡張は必須。これは PostgreSQL の標準 logical replication とは別。
DMS は pglogical を使うため、ソース DB に拡張をインストールし、shared_preload_libraries に追加する必要がある。
必要な PostgreSQL パラメータ（公式）
# postgresql.conf
shared_preload_libraries = 'pglogical'
wal_level = logical
wal_sender_timeout = 0
max_replication_slots = 10 # 必要な slot 数
max_wal_senders = 10 # slot 数 + 余裕
max_worker_processes = 8 # 並列ワーカー
必要な権限
-- DMS 用ユーザーに付与
GRANT USAGE ON SCHEMA <schema> TO dms_user;
GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO dms_user;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA <schema> TO dms_user;
ALTER USER dms_user WITH REPLICATION; -- 非 RDS のみ
-- AWS RDS の場合
GRANT rds_replication TO dms_user;
Primary Key 非保有テーブル:
PK のないテーブルは「初期スナップショット + INSERT のみ」しか CDC されない。UPDATE / DELETE は手動対応が必要。事前に必ず PK を付与する。
Excluded Databases:
template0, template1, rdsadmin, azure_maintenance などシステム DB は自動除外される。これは意図された動作だが「移行されない」と勘違いしやすい。
4. MySQL ソースの設定詳細
必要な MySQL パラメータ
# my.cnf
log_bin = mysql-bin
binlog_format = ROW # 必須 (STATEMENT/MIXED は NG)
binlog_row_image = FULL
expire_logs_days = 7 # CDC ラグより長く保持
server_id = 1 # 一意の ID
gtid_mode = ON # 推奨
必要な権限
CREATE USER 'dms_user'@'%' IDENTIFIED BY '...';
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dms_user'@'%';
GRANT SELECT, RELOAD, LOCK TABLES, SHOW VIEW ON *.* TO 'dms_user'@'%';
5. Heterogeneous Migration（異種DB）
DMS は近年、異種 DB 間移行（特に Oracle/SQL Server → PostgreSQL）に対応拡大している。
対応マトリクス（2026年5月時点）
| ソース | ターゲット | 状態 |
|---|
| Oracle | Cloud SQL for PostgreSQL | GA |
| Oracle | AlloyDB | GA |
| SQL Server | Cloud SQL for PostgreSQL | Preview / GA 拡大中 |
| SQL Server | AlloyDB | Preview |
DMS Migration Assistant がスキーマ変換とコード変換を自動実行。
変換できない部分（複雑な PL/SQL、DBMS_* パッケージ等）はレポートとして提示され、手動修正が必要。
Oracle → PostgreSQL 変換でよくある修正項目
- NUMBER → NUMERIC （精度・スケール明示）
- DATE → TIMESTAMP（PostgreSQL DATE は時刻含まず）
- SEQUENCE → 互換性高（ただし NEXTVAL 構文）
- DBMS_OUTPUT.PUT_LINE → RAISE NOTICE
- PL/SQL → PL/pgSQL（変数宣言・例外処理が異なる）
- カスタム TYPE → 手動変換
- ROWID → 代替主キー設計
6. Datastream のアーキテクチャ
┌─ ソース DB (Oracle / MySQL / PG / SQL Server / MongoDB) ─┐
│ CDC ログ (LogMiner / binlog / pglogical / ...) │
└───────────────────────┬──────────────────────────────────┘
│
▼
┌─ Datastream Stream ────────────────────────────────────┐
│ - Connection Profile (Source) │
│ - Connection Profile (Target) │
│ - Backfill 設定 (初期データ全件転送) │
│ - CDC 設定 (継続変更キャプチャ) │
└───────────────────────┬──────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
BigQuery Cloud Storage Pub/Sub
(UPSERT) (Avro/JSON files) (events)
主要コンポーネント
| コンポーネント | 役割 |
|---|
| Connection Profile | ソース/ターゲット への接続情報（再利用可） |
| Private Connectivity | VPC ピアリングを設定（オプション） |
| Stream | 具体的な移行ジョブ。Backfill + CDC を含む |
| Object | Stream 内の各テーブル/コレクション |
7. Datastream 対応ソース全リスト
2026年現在の対応ソース（公式）:
- Oracle (LogMiner ベース CDC)
- MySQL (binlog)
- PostgreSQL (含む AlloyDB) - pglogical / pgoutput
- SQL Server
- MongoDB ← 2024年頃追加
- Salesforce ← SaaS データ統合
- Spanner ← Spanner → BigQuery の専用パイプライン
接続方法
| 方式 | 用途 | セキュリティ |
|---|
| IP allowlist | シンプル、公開 IP のソース | 基本 |
| Forward SSH tunnel | オンプレ、SSH 経由 | 中 |
| Private Service Connect Interface | VPC 内ターゲットでのプライベート接続 | 高 |
| VPC Peering | VPC 間接続 | 高 |
8. ターゲット別の振る舞い
8-1. BigQuery
Datastream → BigQuery は UPSERT 動作。CDC イベント（INSERT/UPDATE/DELETE）が BigQuery テーブルに反映される。
遅延: 通常 数秒〜数分（ニアリアルタイム）。
スキーマ変更: 一部の DDL は自動伝播するが、複雑な変更は手動で BigQuery 側も合わせる必要あり。
8-2. Cloud Storage
イベントを Avro/JSON ファイルとして書き出し。Dataflow や Dataproc でバッチ処理する用途。
8-3. Pub/Sub
各 CDC イベントを 1 メッセージとして Pub/Sub トピックに publish。Cloud Functions / Cloud Run でリアルタイム駆動。
9. ゼロダウンタイム移行 完全フロー
-
Phase 0: 準備
ターゲット DB（Cloud SQL/AlloyDB）を HA 構成で構築、ネットワーク・IAM・監視設定、ソース DB の CDC 前提条件を整える、テスト環境でリハーサル
-
Phase 1: 初期同期
DMS Continuous Job 開始、初期 Dump（数時間）+ CDC 開始、レプリ遅延を継続監視（< 5s 目標）
-
Phase 2: 並行運用
数日〜数週間、レプリの遅延・整合性を監視、アプリの「読み取り」のみターゲットに向けてテスト
-
Phase 3: カットオーバー
アプリの書き込みを一時停止（数秒〜数分）→ 残ログ適用完了待ち → DMS Promote → アプリ接続文字列切替 → 書き込み再開
-
Phase 4: 逆方向レプリ（保険）
新 → 旧 へのリバースレプリケーション開始、数日〜数週間運用後、問題なければ旧 DB 廃止
カットオーバー時の最大リスク: アプリ書き込み停止中に 残ログ適用に時間がかかると、ダウンタイムが想定を超える。
対策: 事前に「現在のレプリ遅延 + 残ログサイズ」から所要時間を見積もり、レプリ遅延を 必ず数秒以下に維持してからカットオーバー開始。
10. リスク・落とし穴 TOP 10
- DDL は CDC されない。カットオーバー前に DDL 凍結、手動で同期。
- Primary Key 非保有テーブルは UPDATE/DELETE 同期不可。事前に PK 付与。
- ストアドプロシージャ・トリガー・FK 制約は自動移行されない。手動で適用。
- 大きな BLOB は CDC 遅延が大きい。LOB は別経路移行を検討。
- WAL/binlog の保持期間 < レプリ遅延になるとログロストで CDC 中断。
- カットオーバー時の手順は事前にドライラン。本番一発勝負は危険。
- リバースレプリの構築忘れ。ロールバック手段を失う。
- DMS Continuous モードのコストはターゲット DB のリソース費。長期間維持はコスト要注意。
- Datastream ターゲットに BigQuery を選んでも DB 移行にならない。試験頻出ひっかけ。
- 異種 DB 移行は完全自動ではない。Migration Assistant のレポートを必ず確認。
試験頻出のひっかけ
| 問題 | NG 回答 | 正解 |
|---|
| 「Oracle の変更を BigQuery 分析へ」 |
DMS |
Datastream → BigQuery |
| 「MySQL → Cloud SQL ニアゼロダウンタイム」 |
mysqldump |
DMS Continuous |
| 「PB 級オフライン転送」 |
DMS |
Transfer Appliance |
| 「Oracle 完全機能 + リフトアンドシフト」 |
DMS Heterogeneous → AlloyDB |
Bare Metal Solution |
| 「PostgreSQL → AlloyDB 移行」 |
pg_dump |
DMS Continuous |
| 「Pub/Sub に DB 変更を流す」 |
DMS |
Datastream → Pub/Sub |