AWS Database Migration Service
オンプレミスや他クラウドのデータベースを AWS へ移行するサービスで、同種・異種エンジン間の移行と継続的レプリケーションに対応する
概要
AWS Database Migration Service (DMS) は、リレーショナルデータベース、NoSQL データベース、データウェアハウスを AWS に移行するためのフルマネージドサービスです。ソースデータベースを稼働させたまま移行を実行でき、ダウンタイムを最小限に抑えます。同種エンジン間 (Oracle to Oracle など) の移行に加え、AWS Schema Conversion Tool (SCT) と組み合わせることで異種エンジン間 (Oracle to Aurora PostgreSQL など) の移行も実現します。
フルロード + CDC で実現するゼロダウンタイム移行の原理
DMS の移行は 3 つのモードで実行できます。フルロード (Full Load) はソーステーブルの全データを一括転送するモードで、初回移行に使用します。変更データキャプチャ (CDC: Change Data Capture) はソースデータベースのトランザクションログを読み取り、移行開始後の変更をリアルタイムでターゲットに反映するモードです。実務で最も多用されるのは「フルロード + CDC」の組み合わせで、まず全データを転送し、転送中に発生した変更を CDC で追いかけることで、ソースとターゲットの同期を維持します。カットオーバー時にはアプリケーションの接続先をターゲットに切り替えるだけで済み、ダウンタイムは数分から数十分に抑えられます。CDC はデータベースエンジンごとに異なるメカニズムを利用しており、Oracle では LogMiner または Binary Reader、MySQL では binlog、PostgreSQL では論理レプリケーションスロットを使用します。ソースデータベース側で CDC に必要な設定 (binlog の有効化、アーカイブログの保持期間など) を事前に行う必要がある点は、移行計画の初期段階で確認すべき重要事項です。
異種エンジン移行と Schema Conversion Tool の実践
Oracle から Aurora PostgreSQL、SQL Server から Aurora MySQL といった異種エンジン間の移行では、スキーマの変換が最大の課題になります。AWS Schema Conversion Tool (SCT) はソースデータベースのスキーマを分析し、ターゲットエンジンに対応した DDL を自動生成します。自動変換できない箇所 (ストアドプロシージャの PL/SQL 固有構文、Oracle の CONNECT BY 階層クエリなど) はアクションアイテムとして報告され、手動での書き換えが必要です。SCT の評価レポートは移行の工数見積もりに直結するため、移行プロジェクトの最初期に実行することが推奨されます。データベース移行の関連書籍 (Amazon) では、異種エンジン移行のスキーマ変換パターンが体系的に解説されています。DMS 自体はデータの移行を担当し、SCT がスキーマの変換を担当するという役割分担を理解しておくことが重要です。Azure Database Migration Service も同様の移行機能を提供していますが、DMS は対応するソース・ターゲットの組み合わせが幅広く、特に Oracle からの移行パスが充実しています。
レプリケーションインスタンスのサイジングと移行パフォーマンス最適化
DMS はレプリケーションインスタンスと呼ばれる EC2 ベースの中間サーバーでデータ変換と転送を実行します。インスタンスサイズの選択は移行パフォーマンスに直結し、テーブル数が多い場合やLOB (Large Object) カラムを含む場合は、メモリとネットワーク帯域に余裕のあるインスタンスを選ぶ必要があります。並列ロードの設定も重要で、テーブル単位の並列度 (MaxFullLoadSubTasks) を増やすことでフルロードの所要時間を短縮できます。ただし、ソースデータベースへの負荷も比例して増加するため、本番環境からの移行ではソース側の CPU・I/O 使用率を監視しながら調整します。LOB カラムの移行モードは「フル LOB モード」と「制限付き LOB モード」があり、制限付きモードでは指定サイズ以下の LOB のみを移行するため大幅に高速化できます。事前にソースデータベースの LOB カラムの最大サイズを調査し、適切な閾値を設定することがパフォーマンス最適化の鍵です。DMS Serverless を使えばレプリケーションインスタンスのサイジングが不要になり、ワークロードに応じて自動スケールするため、移行の計画と実行がさらに簡素化されます。