Database Migration方式を選択する

データベース移行では、

AWS DMSを使うか
Native Database Toolを使うか

をサービス名だけで決めません。

最初に確認するのは、

データベースエンジンが変わるか

許容できる業務停止時間はどの程度か

移行中も書き込みが継続するか

初期データをどの方法で効率よく移せるか

その方式が移行元と移行先で利用できるか

です。

そのうえで、

Native Database Tool

AWS DMS Full Load

AWS DMS Full Load + CDC

Schema Conversion + AWS DMS

などを選択します。

重要なのは、1つのツールへ固定するのではなく、Downtime Requirementと移行条件を満たす方式を選ぶことです。

1. Database Transfer SelectionはDowntime Requirementから逆算する

同じデータベースでも、許容できる業務停止時間によって移行方式は変わります。

例えば、

業務停止
6時間まで許容

できる場合と、

業務停止
15分以内

では同じ方法を選ぶとは限りません。

長い停止時間を許容でき、

移行元への書き込み停止
↓
データをコピー
↓
移行先へ復元
↓
アプリケーション切り替え

を停止時間内に完了できるなら、Native Database Toolによるバックアップ / 復元やエクスポート / インポートが候補になります。

一方、

移行中も業務継続
+
最終停止時間を短くする

必要があるなら、継続変更を移行先へ反映できる方式が必要です。

2. Native Database Toolが適する場合

Native Database Toolは、データベースエンジンが提供する移行機能です。

例として、

Oracle Data Pump

SQL Serverのバックアップ / 復元

PostgreSQLの
pg_dump / pg_restore

などがあります。

Native Database Toolは、

同じデータベースエンジン間

移行先がその方式をサポート

許容停止時間内に
コピー / 復元を完了可能

DBAがその方式を運用可能

といった条件では有力な候補です。

特にエンジン固有の仕組みを利用できるため、同種データベース間では効率的な場合があります。

ただし、

Native Database Tool
=
常に最適

ではありません。

3. 単純なバックアップ / 復元では停止時間が長くなりやすい

単純なバックアップ / 復元では、

移行元への書き込み停止
↓
バックアップ
↓
バックアップデータを転送
↓
移行先へ復元
↓
検証
↓
切り替え

という処理を業務停止中に行う場合があります。

データ量が大きいほど、

バックアップ時間
+
転送時間
+
復元時間

がDowntime Requirementへ影響します。

例えば、

必要時間 8時間

許容停止時間 12時間

なら成立する可能性があります。

しかし、

必要時間 8時間

許容停止時間 20分

なら、そのままでは成立しません。

Database Transfer Selectionでは、ツールが利用可能かだけでなく、停止時間要件を満たすかを確認します。

4. 移行中も更新が続くならCDCを評価する

24時間稼働するデータベースでは、

移行開始
↓
数時間かけて既存データをコピー

している間にも、新しい更新が発生します。

短い業務停止を求められる場合、

既存データ
→ 事前に移行

移行中の変更
→ CDCで継続反映

する構成が候補になります。

AWS DMSでは、

Full Load + CDC

を使うことで、

既存データを移行
+
継続変更を反映

できます。

ここで重要なのは、

CDCを使う理由
=
AWS DMSだから

ではなく、

移行元を長時間停止できない
+
移行中にも変更が発生する

というDowntime Requirementです。

5. Full Loadだけで十分な場合もある

AWS DMSを使う場合でも、

常にCDCが必要

ではありません。

例えば、

移行開始前に書き込み停止可能

Full Load完了まで
業務停止を許容可能

移行中の変更を追従する必要なし

であれば、

Full Load

だけで要件を満たせる場合があります。

つまり、

AWS DMS
=
必ずFull Load + CDC

ではありません。

Downtime Requirementと更新継続の有無によって移行タイプを選択します。

6. Engine Changeがある場合はSchema Conversionを別軸で考える

異なるデータベースエンジンへ移行する場合、

データをどう運ぶか

だけでは完成しません。

例えば、

Oracle Database
↓
Aurora PostgreSQL

では、

スキーマ / コード変換

と、

業務データ移行

の両方が必要です。

考え方は、

Schema Conversion
+
Database Transfer

です。

既存のAWS SCT変換プロジェクトを利用する場合なら、

AWS SCT
→ スキーマ / コードの変換を支援

AWS DMS
→ 業務データと継続変更を移行

のように役割を分けられます。

2026年現在、新しくスキーマ変換を開始する場合はAWSがDMS Schema Conversionを推奨していますが、AWS SCTも引き続き利用可能でSAP-C02の対象です。

重要なのは、

AWS SCT
=
業務データを継続Replicationするサービス

とは考えないことです。

7. Native Database Toolだから必ず長時間停止するわけではない

Native Database Toolという分類だけを見て、

Native Database Toolを使う
=
必ずオフライン
=
長時間停止

と固定するのも誤りです。

データベース製品によっては、

ネイティブの高可用性機能
ログ転送
ネイティブReplication
CDC

などを使って短い停止時間を目指せる場合があります。

したがって、

Minimal Downtime
→ 必ずAWS DMSだけ

とは判断しません。

確認するのは、

候補となるNative Database Toolが
どの移行方式をサポートするか

です。

8. Native Database Toolは移行先で利用できるか確認する

DBAが使い慣れているツールでも、

移行元では利用可能

というだけでは不十分です。

確認する必要があるのは、

移行元エンジン

移行先エンジン

バージョン

エディション

マネージドサービス側の制約

バックアップ形式や復元方式

です。

例えば、

使い慣れたバックアップ方式
↓
予定している移行先では復元不可

であれば、そのNative Database Toolだけでは移行方式として成立しません。

この場合は、

AWS DMSが移行元 / 移行先を
サポートしているか

など、別の方式を評価します。

9. Data VolumeだけでDatabase Transfer Selectionを決めない

大容量データベースだからといって、

必ずNative Database Tool

でも、

必ずAWS DMS

でもありません。

Data Volumeは、

初期ロード時間

へ影響する判断条件の1つです。

例えば、

大容量
+
AWS DMS Full Loadで
必要期間内に移行可能
+
運用を単純化したい

なら、AWS DMSを利用する方式が成立する可能性があります。

反対に、

Native Database Toolを利用可能
+
要求される停止時間内に
移行を完了できる

なら、Native Database Toolが候補になる場合もあります。

重要なのは、

Data Volumeだけ
↓
ツールを確定

しないことです。

10. Database Transfer Selectionで確認する条件

方式を選択するときは、少なくとも次を確認します。

1つの条件だけでは決めません。

11. 代表的な選択パターン

パターンA：停止時間を十分確保できる

同じエンジン
+
Native Database Tool利用可能
+
バックアップ / 復元を
停止時間内に完了可能
+
継続変更の追従不要

↓

Native Database Tool

パターンB：移行中も更新が続き、停止時間が短い

初期データ
+
継続更新
+
短いDowntime Requirement

↓

CDCを利用できる移行方式を評価

AWS DMSが移行元 / 移行先をサポートし、要件を満たすならFull Load + CDCが候補になります。

パターンC：Engine Changeがある

異なるデータベースエンジン
↓
Schema Conversion
+
データ移行方式を選択

必要に応じて、

AWS SCTなどによる
スキーマ / コード変換

+

AWS DMSによる
データ移行

のように責任を分けます。

12. 最終判断フロー

移行元 / 移行先エンジンを確認
↓
Engine Changeがあるか
├─ YES
│  → Schema Conversionを計画
│
└─ NO
   → 同種移行として継続
↓
Downtime Requirementを確認
↓
移行中も書き込みが続くか
↓

長い停止を許容
+
Native Database Toolで
期間内に完了可能
↓
Native Database Toolを候補

短い停止が必要
+
継続変更あり
↓
CDCを利用できる方式を候補

↓

AWS DMSを利用する場合
├─ 継続変更の追従不要
│  → Full Loadを候補
│
└─ 継続変更の追従必要
   → Full Load + CDCを候補

↓

移行元 / 移行先で
候補方式が利用可能か確認
↓
Database Transfer Selection

SAP-C02では、AWS DMS、AWS SCT、Native Database Toolを個別暗記するだけでなく、Engine Change・Downtime Requirement・更新継続・利用可否から適切な方式を選択できることが重要です。