移行で後悔しないために！AWS DMSを選んだ理由と成功・失敗の分岐点とは？

1. はじめに

企業のIT基盤は今、大きな転換期を迎えています。特にクラウドへの移行が進む中で、既存のシステムを止めずに、データベースの中身を安全に、かつ確実に移し替える方法が注目されています。

この記事では、AWS（Amazon Web Services）で提供されている「AWS Database Migration Service（DMS）」を利用して、既存のオンプレミス（社内で設置・運用している物理的なサーバ）環境から、新たに構築したAmazon RDS（Relational Database Service）環境へ、どのようにデータを移行・同期したかを具体的に解説します。

データ移行で発生する可能性のあるトラブル、設定時に陥りがちな落とし穴、そして移行後のチューニングに至るまで、クラウドアーキテクトやインフラエンジニアの視点から、実務に役立つ内容を丁寧にお届けします。

1-1 AWS DMSとは？

AWS DMS（Database Migration Service）は、既存のデータベースから新しいデータベースへ、データを移行するためのクラウドサービスです。DMSを使えば、データベースを完全に止める必要なく、移行プロセスを進めることが可能です。例えば、製品の受注情報や顧客のアカウントデータなどの重要な情報を、ほかのシステムにコピーしながら、元のシステムも利用し続けられるしくみになっています。

主にフルロード（全データ一括移行）と、CDC（変更データキャプチャ：変更があった分だけ逐次反映）という2つの方法があり、それらを組み合わせて運用することもできます。例えば初回に全データを移して、それ以降に追加・変更のあった情報だけ同期する、といった柔軟な構成が可能です。

1-2 なぜデータ移行にDMSを使うのか

AWS DMSを選ぶ最大の理由は、安全性と柔軟性です。一般的に、データベースを他のシステムに移行する際は、旧システムを完全に停止（ダウンタイム）させる必要があるため、業務に支障が出る恐れがあります。

一方で、DMSを利用することで、旧システムを動かしながらでも同期が可能になり、ダウンタイムを大幅に短縮できます。これは、24時間体制で稼働しつづける基幹業務システムなどでは、特に大きな利点です。また、多くの異なるデータベース製品をサポートしているため、異なるベンダー間（例：Oracle→MySQLなど）の移行も可能なのが特長です。

1-3 本記事の目的と背景

本記事の目的は、AWS DMSを実際に利用した移行プロジェクトの視点から、そのメリットや気をつけるべき点、運用で役立つ知見を読者と共有することです。

例えば、弊社のように300人規模の企業では、限られたエンジニアリソースの中で、いかにコストや時間を抑えた効率的な移行を実現できるかが課題となります。そこで登場したのがAWS DMSでした。

“簡単にデータ移行ができる”という触れ込みのDMSですが、実際には設定項目も多く、事前の準備を怠ると失敗や予算オーバーにもつながります。本記事では、現場での経験と実際の構築ステップを基に、より深く、役立つ解説をしていきます。

2. AWS DMS の基本構成

AWS DMSは、比較的シンプルな構成で動作しますが、その仕組みを理解することが、安全な移行を行うためには欠かせません。ここでは、DMSの構成と機能を網羅的に紹介します。

2-1 DMSのアーキテクチャ

DMSは、大きく3つの主要コンポーネント（部品）で構成されています。

1つ目は「レプリケーションインスタンス」。これは、データを移行するための「作業装置」のような役割を持っています。このサーバが、ソースとなるデータベースから情報を受け取り、ターゲットとなる新システムに転送します。

2つ目は「エンドポイント」。これは、データをどこから受け取り、どこに送るのかを指定する「入口と出口」のような設定です。エンドポイントには、接続先の認証情報やホスト名、接続ポートなどが含まれます。

3つ目は「移行タスク」。タスクは移行の内容とルールを定義する設定ファイルのようなもので、「いつ」「どれを」「どうやって」移すのかを決定します。具体的には同期対象となるテーブル、変換ルール、移行方式（後述）などを含みます。

2-2 サポートされるソースとターゲット

AWS DMSは、異なるデータベースベンダー間の移行にも対応しています。代表的には以下のような組み合わせがあります：

- Oracle → Amazon Aurora

- SQL Server → Amazon RDS for PostgreSQL

- MySQL → Amazon RDS for MySQL

- On-Premise PostgreSQL → Amazon Aurora Postgres

- MongoDB → Amazon DocumentDB

特に便利なのは、オンプレミスのデータベースからAWSクラウド側のマネージドサービスに直接移行できる点です。また、ノンリレーショナルDB（JSON形式のようにテーブル構造になっていないデータ）の移行にも部分的に対応しています。

2-3 移行タイプ（フルロード、CDC、両方）

AWS DMSでデータを移す方法は3種類あります。

フルロード（Full Load）：これは、全てのデータを始めに一括して移す方式です。小規模なDBや一時停止可能なタイミングがあるシステムでは、シンプルで効果的です。

変更データキャプチャ（CDC, Change Data Capture）：これは、元のDBで発生した新旧のデータの変更をリアルタイムでとらえて反映させる技術です。24時間稼働のシステムや、大きなDBの移行に向いています。

フルロード＋CDC：まず、すべてのデータを一括で移したあとに、それ以降に発生した変更のみをCDCで拾いながら差分を移していく、という組み合わせ方式です。このハイブリッド方式が、最も現実的かつ実用的とされる構成です。

3. 実際の利用シナリオ

ここでは、実際にAWS DMSを用いて、新たに構築したAmazon RDS環境にオンプレミスのデータを移行した事例をもとに、どのような構成で進めたかをご紹介します。

3-1 新RDS環境の構築と同期の要件

今回のプロジェクトでは、社内で長年運用してきたオンプレミスのPostgreSQL環境から、AWS上で新たに立ち上げたAmazon Aurora PostgreSQL環境への移行が目的でした。移行先となるRDSは、高可用性（いざというときにもすぐ復旧できる仕組み）を支えるため、マルチAZ（Availability Zone：複数のデータセンター）構成をとっています。

要件としては、以下のポイントが重視されました：

- ダウンタイムは最大でも3時間以内に抑えること

- データ整合性（データがズレたり壊れたりしないこと）を担保すること

- セキュリティグループのポリシーに則って、社内NWからアクセス制限付きで移行を実現すること

3-2 移行対象のデータベース構成

移行元となるDBは、テーブル数が約200、全体で1TB程度の中規模構成でした。複数のスキーマに分かれた構成をしており、アプリケーション連携部分のほとんどがトリガーによって処理されている特徴がありました。

その中でも特に注意が必要だったのは、日時の形式（timestamp）や文字コードなど、データ型に差異がある項目です。AWS DMSは、サポートされるデータ型の範囲には制限があるため、事前のマッピング設計が重要になります。

3-3 スケジュールやダウンタイムの制約

スケジュール面でも、通常業務の稼働を止められない業界特性から、実施タイミングは主に深夜〜未明にかけて行われました。移行の本番作業は、週末に実施する計画が立てられ、事前の検証を繰り返して万全な体制を整えました。

また、移行直後はデータ整合性のチェックと、クライアントアプリケーション側の切替確認も含めて、24時間体制での監視が求められました。チーム内ではチャットや電話を使い即時連携を図る体制を構築しました。

4. AWS DMS のセットアップ手順

AWS DMSの導入には、正しい順序と丁寧な確認が不可欠です。構造を理解していても、設定ミスや手順飛ばしが発生すると、期待する動作をしなかったり、データが不完全なままになってしまう危険があります。ここでは基本的なセットアップ手順を実際の利用フローに沿って解説します。

4-1 レプリケーションインスタンスの作成

DMSの中核を担うのが、レプリケーションインスタンスです。これは、ソースデータベース（移行元）とターゲットデータベース（移行先）の間でデータの転送や変換、監視などをする「橋渡し役」と言えるサーバです。

レプリケーションインスタンスを作る際には、まず適切な容量とパフォーマンスを見極める必要があります。移行するデータの量が大きい場合や転送中に並列処理が必要な場合は、より高性能なインスタンスサイズ（例えばdms.r5.large以上）を選定することで、移行の時間を短縮できます。

また、インスタンスを配置するVPC（仮想ネットワーク）のサブネットやセキュリティグループ（アクセス制御設定）を事前に構成しておくことが重要です。ログ出力設定もここで有効にしておくと、トラブル時の原因分析がしやすくなります。

4-2 ソース／ターゲットエンドポイントの設定

次に行うのが、ソース（元）とターゲット（先）のエンドポイント作成です。ここでは、それぞれのデータベースに接続するための「住所」と「鍵」を登録すると考えてください。

ここで特に重要なのは以下の2点です：

1. 接続テストは確実に行う

ソースDBやターゲットDBが正しく認識されないと、タスクが失敗する原因になります。DMSでは「テスト接続」機能がありますので、必ず成功することを確認しましょう。

2. 必要な権限の確認

例えば、PostgreSQLからAuroraに移行する場合、利用ユーザーに「REPLICATION」「SELECT」「DDL（テーブル構造の取り扱い）」などの権限が付与されているか事前確認が必要です。付与が不足すると、タスク中にアクセス拒否されるケースが多く見られます。

4-3 移行タスクの作成と実行プラン

タスク作成は、「どのデータを移すか」「変換ルールをどうするか」「どの方式を選ぶか（フルロード／CDC）」を定義する工程です。設定項目は多いですが、わかりやすいウィザード形式で進めることができます。

タスク作成時のポイント：

- 除外／対象テーブルを明示的に含める

- LOB（Large Object：大きなファイル）データの扱いを確認（制限あり）

- テーブルマッピング設定でWHERE句などの条件付けが可能

また、タスク単位でエラーハンドリングやイベント駆動（特定のタイミングで処理を止める／続ける）を定義できるため、運用の柔軟性も高まります。

実行前には、必ず「テストタスク」を行ってログ出力の確認とパフォーマンスを見ておきましょう。

5. 利用して良かった点・メリット

AWS DMSを本番運用で導入して、特に大きく感じた利点は3つあります。これらは一見すると当たり前のようですが、実際の運用においてその効果は絶大でした。インフラエンジニア・クラウドアーキテクトの観点から、実感した良さを紹介します。

5-1 ダウンタイムを最小限で移行可能

多くの企業が避けたい最大の要素が「業務を止めること」です。DMSのCDC機能を用いることで、非同期に変更を拾いながら進められたことで、システムの停止時間は実質数分程度で済みました。

これにより、日常業務を継続しながら裏で移行作業を進め、切替ポイントを柔軟に管理できたのは大きな成功要因でした。また、利用者側にも影響が出にくく、社内稟議や承認プロセスもスムーズに進むことができました。

5-2 自動リトライ機能と堅牢性

DMSには、タスクが一時停止や障害に遭遇した際に、自動でリトライ・再実行を試みる機能があります。例えば、ネットワークが数秒間不通になった場合でも、ログにその旨が記録されて処理は再開されました。

このように、恒常的な監視体制が無くても、ある程度のトラブルに対して自力で復旧してくれる構造は、信頼性の観点で非常に役立ちます。タスクの中断ポイントの記録もされるため、失敗時の回復も簡単に行なえます。

5-3 モニタリングと可視化（CloudWatchとの連携）

AWS DMSは、AWSが提供する監視ツール「CloudWatch（クラウドウォッチ）」と連携することが可能です。これにより、レプリケーションの進行状況や遅延（ラグ）の時間、エラーログの内容まで可視化され、事前に通知を受け取る仕組みも組み込めます。

また、タスク単位・エンドポイント単位で詳細データを見ることができ、性能ボトルネックや設定ミスの発見にもつながりました。運用フェーズまで見据えると、この統合性が非常に重要になります。

6. 注意点と落とし穴

利便性の高いDMSですが、誰もが一度はつまずく「思わぬ罠」が存在します。ここでは、実際に遭遇したトラブルから得た教訓や、防止策を分かりやすく紹介します。

6-1 ネットワークと接続設定の落とし穴

DMSは、AWS上の管理サービスであるため、社内オンプレミスからアクセスさせる場合はVPN（仮想プライベートネットワーク）やDirect Connectなどのネットワーク設定が必要です。

しかし、この設定を疎かにすると、エンドポイントが通信できずにタスクが失敗します。特にファイアウォールが細かく制限されている環境では、DMSのIP範囲や使用ポートをホワイトリストに入れる必要があります。セキュリティグループの方向（インバウンド／アウトバウンド）の設定ミスも要注意です。

6-2 サポートされるデータ型と制限事項

DMSは万能ではなく、すべてのデータ型をそのまま移行できるわけではありません。例えば、PostgreSQLで扱うデータ型の一部（JSONBやETLで使われるカスタム型）などは変換エラーを起こす可能性があります。

このため、初期のスキーマ検出ツール（Schema Conversion Toolなど）を用いて事前に型の互換性を確認しておく必要があります。また、LOB（サイズの大きいテキストやバイナリデータ）は、完全コピーか一部コピーかを選択しないと、移行中に中断する恐れがあります。

6-3 権限関連のトラブルと対処法

移行時に発生しやすいのが、DMSに必要なDB権限が不足していてタスクが失敗するケースです。例えば、以下の権限が必要となります：

- SELECT：読み込み

- INSERT／UPDATE：書き込み

- REPLICATION：変更の追跡

これらがDMSユーザーに付与されていないと、最悪の場合途中でタスクが止まる、あるいは一部のテーブルが空になってしまう危険もあります。DMSでは、付与されたかを事前チェックする機能がないため、必ず手動で確認するか、権限をフルで与える一時的なアカウントを活用することをおすすめします。

7. 移行後の検証と最適化

データの移行が完了したからといって、プロジェクトが終わるわけではありません。むしろ、移行後の検証とパフォーマンスの最適化こそが、成功する移行プロジェクトの鍵となります。ここでは、移行後に必ず押さえておきたい確認ポイントと最適化手法を紹介します。

7-1 データ整合性の確認手順

移行が完了したら、まず確認すべきは「本当に正しいデータが移っているか」という点です。これを「データ整合性の検証」と呼びます。例えば、件数の一致確認や、特定の値のサンプリング比較などがあります。

具体的な手順としては以下のような流れがおすすめです：

- 元DBと移行先のDBで、それぞれのテーブル件数を比較

- 重要テーブルについて、特定カラム（列）単位の値／型／NULL有無の検査

- アプリケーション側で参照するビューやJOINの再動作確認

- トランザクション系データや履歴など最新データが正しく反映されているかの確認

AWSのData Validation機能を使うことで、一部自動的に整合性チェックを行うことも可能です。ただし完璧ではないため、業務を理解している担当者による目視による検証は欠かせません。

7-2 パフォーマンスチューニングのポイント

仕様通りに移行できても、クラウド上でのパフォーマンスが想定より出なかったという声もよく聞きます。これは、オンプレミスとクラウドでインフラ構成やキャッシュの仕組みが異なるためです。

パフォーマンス向上のための基本的なチェックポイントは以下です：

- インデックスの再構築（移行時に削除される場合がある）

- クエリの実行計画（Explain）を確認し、最適化の余地があるか調査

- パラメータグループやI/O最適化設定の見直し

- キャッシュポリシー（PostgreSQLではwork_mem、shared_buffersなど）の調整

- AutoVacuumの設定状況の確認

また、Amazon RDS Performance Insightsを有効にすることで、実行クエリのボトルネックが可視化されるため、改善のヒントが得られます。

7-3 DMSタスクの停止と環境クリーンアップ

移行が完全に完了し、整合性・性能の確認まで終わったら、DMSのレプリケーションタスクやインスタンスは停止・削除するのが基本です。放置しておくと、不要な課金が発生し続けてしまいます。

具体的には：

- 移行タスクを「停止」し、不要になったら「削除」

- レプリケーションインスタンスを停止、再利用しない場合は削除

- 不要なCloudWatchメトリクスやロググループも適宜クリーンアップ

将来的に再利用の可能性がある場合は、構成テンプレートをJSONでエクスポートし、必要時に再デプロイできるよう準備しておくと便利です。

8. トラブルシューティング集

どれだけ準備していても、予期せぬ問題は発生するものです。ここでは、実際の移行プロジェクトで遭遇した問題とその解決方法を、トラブル別に紹介します。

8-1 よくあるエラーとその解決方法

移行中によく発生したエラーの代表例は以下です：

- Endpoint connection error：ネットワーク設定や認証情報が誤っていると発生。セキュリティグループやVPCピアリングの設定を再確認し、DNS解決も確認。

- Replication task failed：対象テーブルに対応しないデータ型や欠損データがある場合。特定のテーブルを除外設定し、段階的に確認。

- LOB Truncation error（大きなデータの切り捨て）：LOB設定が「Limited」にされている場合。移行中に完全コピー設定に変更。

それぞれのエラーは詳細ログに記録されるため、CloudWatch LogsまたはDMSのログコンソールから絞り込み検索を活用しましょう。

8-2 移行失敗時のロールバック戦略

万一、途中で移行が失敗した場合に備え、あらかじめ「ロールバックポリシー（元に戻す方法）」を用意しておきましょう。

一般的な対処法：

- ソースDBには影響を与えないDMSの特性を活かし、再試行可能な構成にしておく。

- ターゲットDBに反映された内容を削除するか、スナップショット取得によって巻き戻す。

- 本番移行の前に、ステージング環境でフルテストを行い、成功条件と失敗パターンを洗い出す。

DMSでは過去のタスク状態やエンドポイントの情報が保持されているため、必要に応じて再タスクの実行も比較的簡単です。

8-3 サポートケース提出前に確認すること

AWSのサポートに問い合わせる前に、以下を確認することで迅速な対応が受けられます：

- タスクID／エラーメッセージの取得と保存

- Event LogsまたはCloudWatch Logsから該当時間帯のログ抜粋

- VPC ID、インスタンスID、エンドポイント構成情報を明記

- 再現性（1回限りか、何回やっても発生するか）

これらの情報を揃えたうえでサポートケースを提出することで、調査時間を短縮でき、より本質的な回答に早くたどり着くことができます。

9. まとめと今後の展望

AWS DMSは、手軽で高機能なデータ移行の仕組みを提供してくれます。ただし、使いやすさゆえに設定ミスを招きやすく、適切な計画・検証・検知体制がなければ本番対応は危険を伴います。

AWS上のRDS移行を体験して分かったことは、DMSを単なる“移行ツール”ではなく、“移行から運用・監視まで支援する統合プラットフォーム”として活かすことが、最大活用の鍵であるということです。

9-1 AWS DMSを使った移行の振り返り

- フルロード＋CDCの組み合わせで、ダウンタイムを最小限化できた

- 権限・データ型・ネットワークの3点が重要な落とし穴

- CloudWatchとの統合により移行可視化／通知が迅速に

9-2 今後の拡張・運用戦略への活用

今後は、マルチリージョン間でのレプリケーションや、災害対策サイトDRとしての活用にも視野を広げています。DMSが持つCDC機能を応用し、データのリアルタイイム同期による高可用性アーキテクチャにも挑戦予定です。

9-3 他のAWSサービスとの組み合わせ事例

- Amazon S3へのCDCデータ連携 → 分析基盤として活用

- AWS GlueによるETL処理連携 → データ整形の自動化

- Amazon QuickSightとの連携 → リアルタイムレポート化

このように、DMSを起点として、AWS全体でのシステム連携に広げることが、より持続的かつ強固なデータ活用基盤を構築する第一歩になります。