AWS DMS（Database Migration Service）とは？基本概念と特徴

「今動いているデータベースを、どうやって安全にAWSへ移せばいいのだろう？」 システム運用を担当していると、一度はこのような悩みに直面するはずです。データの移行は、一歩間違えるとサービス停止やデータ消失のリスクを伴う、非常に神経を使う作業です。

そんな時に頼りになるのが、AWS Database Migration Service（以下、AWS DMS）です。

Note

この記事では、移行元のデータベースを「ソース」、移行先のデータベースを「ターゲット」と呼びます。これらの用語は以降のセクションでも頻出するため、あらかじめ頭に入れておいてください。

AWS DMSとは？データベースの引っ越しを支援するサービス

一言で言えば、AWS DMSは「データベースの引っ越し作業を強力にサポートしてくれる専門業者」のようなサービスです。

具体的には、オンプレミス（自社運用）のサーバーや、他のクラウド環境にあるデータベースから、AWS上のデータベースへデータを移し替える役割を担います。ここで重要なのが、単にデータをコピーするだけでなく、「最小限のダウンタイム（システム停止時間）」で移行できるという点です。

通常、大量のデータを移行しようとすると、その間システムを止めておく必要が出てきます。しかし、AWS DMSはデータの移行中もソースのデータベースを動かし続け、変更された差分だけを後から追いかける仕組みを持っているため、サービスへの影響を極限まで抑えることができます。

AWS DMSのメリット：マネージドサービスだからできること

「自分で移行用のサーバーを用意して、複雑な設定をするのは大変そう」と感じるかもしれませんが、AWS DMSは完全なマネージドサービスです。インフラの面倒な管理をAWS側が肩代わりしてくれるため、以下のようなメリットがあります。

  • 導入が圧倒的に早い: 自分でハードウェアを買ったり、OSやデータベースソフトをインストールしたりする必要はありません。数分で移行用の環境を立ち上げることができます。
  • 運用の手間が省ける: 移行用サーバーのセキュリティパッチ適用や、エラーの監視といった「地味だけど重要な作業」をAWSが自動で行ってくれます。
  • 柔軟なスケーリング: 「データの量が多いからもっとパワーが必要だ」となったときも、設定変更だけで簡単にリソース（処理能力）を増強できます。

Tip

移行作業は「一度きりのイベント」になりがちですが、AWS DMSを使えば、将来的なデータ連携やレプリケーション（複製）にもそのまま活用できるため、拡張性が高い状態を維持できます。

対応データベースの幅広さと異種間移行の可能性

AWS DMSのもう一つの強みは、対応しているデータベースの幅広さです。例えば、以下のようなケースでも活躍します。

  • 商用DBからOSSへの移行: 高価なライセンス料がかかるOracleなどの商用データベースから、コストを抑えられるPostgreSQLなどのオープンソース系へ移す。
  • リレーショナルからNoSQLへ: 構造が決まった「表形式」のデータ（SQL）から、柔軟な構造を持つDynamoDBのようなNoSQLへと形を変えて移行する。
  • データ分析基盤への集約: 日々の業務データを、Amazon Redshiftのようなデータウェアハウス（大量のデータを高速に分析するための専用DB）へ流し込む。

このように、「Aという種類のデータベースから、Bという全く別の種類へ」といった異種間移行がスムーズに行えるのが大きな特徴です。

Important

異なる種類のデータベースへ移行する場合、データの持ち方（スキーマ）が変わるため、単純なコピーだけではエラーになることがあります。その場合は、後ほど解説する「スキーマ変換」の機能と組み合わせて使うのが定石です。

AWS DMSの全体アーキテクチャとデータ移行の仕組み

AWS DMSは、データを賢く効率的に転送するために、独自のアーキテクチャとプロセスを採用しています。ここでは「具体的にどうやってデータを運んでいるのか」という中身の部分を解説します。

データ移行の基本プロセス（抽出・変換・ロード）

AWS DMSがデータを動かす際、中心的な役割を果たすのが「レプリケーションインスタンス」というサーバーです。このインスタンスが司令塔となり、以下の3つのステップでデータを転送します。

  1. 抽出: ソースとなるデータベースから、必要なデータを読み取ります。
  2. 変換: 読み取ったデータを、ターゲットとなるデータベースの形式に合わせて整えます。データ型の微調整やフォーマットの変換が行われます。この処理の多くはメモリ上で実行されるため、非常にスピーディです。
  3. ロード: 整えられたデータを、ターゲットのデータベースへと書き込みます。

Tip

ターゲットにテーブルやプライマリキー（データの重複を防ぐ識別子）が存在しない場合、AWS DMSが自動的に作成してくれる設定もあります。スピード重視であれば、この機能を活用すると良いでしょう。

AWS DMSで採用される論理レプリケーション

データの読み取り方式には、大きく分けて「物理レプリケーション」と「論理レプリケーション」の2つがあります。物理レプリケーションはデータベースのファイルそのものをコピーする方式で高速ですが、同じ構造のデータベース間でしか使えません。

AWS DMSが採用しているのは論理レプリケーションです。これは、データベースの中身を「SQL文のようなデータの意味内容」として読み取る方法です。データを意味のある形で解釈し直して運ぶため、「オンプレミスのOracleからAWS上のAuroraへ」といった、異なるエンジン間（異種間）の移行を実現できます。

ダウンタイムを最小限に抑えるCDC（Change Data Capture）の仕組み

システムの移行において、エンジニアが最も恐れるのが「サービスを止める時間（ダウンタイム）」です。数テラバイトもある巨大なデータを一度にコピーしようとすれば、何時間もシステムを止め続けなければなりません。

AWS DMSは、この問題を解決するためにCDC（Change Data Capture：変更データキャプチャ）という仕組みを持っています。移行のプロセスは大きく2段階に分かれます。

  1. フルロード: 現時点にあるすべてのデータを一括でコピーします。
  2. 継続的レプリケーション（CDC）: フルロードが終わった後、ソース側で発生した「新しい追加・更新データ」だけをリアルタイムで検知し、ターゲットへ送り続けます。

これにより、ソースとターゲットのデータがほぼ同期された状態を維持できます。最後にアプリケーションの接続先をパッと切り替えるだけで済むため、ユーザーへの影響を極限まで短くできるのです。

Important

CDCを利用する場合、ソース側のデータベースで「トランザクションログ」の出力設定を有効にしておく必要があります。この設定がないと、AWS DMSは「何が変更されたか」を追跡できません。

AWS DMS移行前の評価とスキーマ変換のアプローチ

データベースの移行を成功させるには、「今、どんなデータがどこにあるのか」を正確に把握し、新しい環境で動くための設計図（スキーマ）を整える準備が不可欠です。AWS DMSには、この「準備段階」を強力にサポートするツールが用意されています。

DMS Fleet Advisorによる移行前の検出と評価

大規模なシステム移行の際、最初に直面するのが「どのサーバーにどんなデータベースが入っているのか、正確なリストがない」という問題です。手作業での調査は時間がかかり、見落としのリスクも高いです。

そこで活躍するのが DMS Fleet Advisor です。オンプレミスの環境からデータを自動的に収集し、「移行候補となるサーバーやデータベースのインベントリ（目録）」を自動で作成してくれます。

  • 現状の可視化: どのデータベースがどれくらいの容量を使っているのかを自動で把握します。
  • 移行計画の策定: 収集したデータに基づき、「このサーバーはAWSに持っていける」「このスキーマは変換が必要だ」といった判断材料を提供します。

Tip

移行プロジェクトの初期段階では、いきなりデータを動かすのではなく、まずはFleet Advisorで「現状の棚卸し」を徹底するのが、後のトラブルを防ぐ一番の近道です。

DMS Schema Conversionを用いたスキーマの自動変換

異種間移行（例：OracleからAmazon Auroraへ移行する場合）では、データの形式や関数の書き方が異なるため、スキーマの書き換えが必要です。

現在は DMS Schema Conversion という機能により、AWSのマネジメントコンソール（ブラウザ上の操作画面）だけでスキーマ変換が完結します。

  1. 移行プロジェクトを作成し、ソースとなるデータベースを指定します。
  2. 自動評価を実行して、「どこが変換できないか」のレポートを確認します。
  3. スキーマの変換コードを生成し、ターゲットに適用します。

AWS SCT（Schema Conversion Tool）との使い分け

ブラウザ上で完結するDMS Schema Conversionが便利な一方で、AWS SCT (Schema Conversion Tool) という、ローカルPCにインストールして使う専用ツールも依然として重要な役割を持っています。

どちらを使うべきかは、プロジェクトの規模や複雑さによって判断します。

特徴DMS Schema ConversionAWS SCT (Schema Conversion Tool)
操作方法ブラウザ（マネジメントコンソール）ローカルPCへのインストールが必要
主な用途標準的なスキーマ変換、手軽な作業非常に複雑な変換、大規模プロジェクト
利便性環境構築不要ですぐに始められる高度なカスタマイズや詳細な検証が可能

Important

基本的には「DMS Schema Conversion」で手軽に試し、どうしても自動変換できない複雑なロジックがある場合は「AWS SCT」に切り替えるというアプローチが効率的です。

Warning

スキーマの変換が100%完璧に自動で行われるわけではありません。変換後のレポートを必ず確認し、手動での修正が必要な箇所がないかチェックしてください。

AWS DMSで実現できる3つの主要ユースケース

AWS DMSは単なる「データの引っ越し屋さん」ではありません。用途に合わせて、大きく分けてMigrate（移行）、Replicate（複製）、Modernize（近代化）という3つの役割を使い分けることができます。

Migrate：データベースやDWHの確実な移行

「Migrate」は、既存のデータを新しい場所へ移し替える、最も標準的な使い方です。オンプレミスからAWSへの環境移行や、データベースのバージョンアップの際に力を発揮します。

  • データの統合とアーカイブ: 複数の異なるデータベースにあるデータを一つにまとめたり、古いデータを安価なストレージへ移動して整理したりします。
  • 異種間移行: SQL形式のデータベースからNoSQL形式へといった、データの構造が異なるもの同士の移行もサポートしています。

Replicate：継続的なデータ連携とレプリケーション

「Replicate」は、常にデータを同期させ続けることを目的とした使い方です。本番データベースに負荷をかけずに、別の場所にリアルタイムに近い形でコピーを提供し続けます。

  • データレイク・DWHへの連携: 業務データをAmazon S3（データレイク）やAmazon Redshift（データウェアハウス）へ継続的に流し込み、分析専用の環境を安全に構築します。
  • クロスリージョンでのディザスタリカバリ（DR）対策: 遠隔地へのデータ同期を行いたい場合、AWS DMSを用いて異なるリージョンのデータベースへ継続的にレプリケーションすることが可能です。（※同一エンジン間の読み取りレプリカ作成は、Amazon RDSの標準機能でも実現できます）

Modernize：モダンデータベースへのアップグレード

「Modernize」は、システムの構造そのものを進化させるための戦略的な使い方です。運用管理の手間がかかる独自構築のデータベースから、AWSのマネージドサービスへと切り替えます。

  • Amazon Auroraへの移行: 高いパフォーマンスと可用性を備えたリレーショナルデータベースへ移行し、運用の負担を減らします。
  • Amazon DynamoDBへの移行: 大量のリクエストを高速に処理する必要がある場合、NoSQLであるDynamoDBへ構造を変えて移行することで、スケーラビリティを手に入れます。

Important

Modernizeのようにデータベースエンジン自体が変わるケースでは、データ構造（スキーマ）も変わります。前節で紹介したスキーマ変換ツールを用いて、設計図を正しく作り変える工程が必須です。

AWS DMSのレプリケーションインスタンスとは？役割と高可用性設計

AWS DMSを実際に構築・運用する上で、避けて通れないのが「レプリケーションインスタンス」の存在です。ここでは、よりエンジニアリングに近い視点で、その役割と設計のポイントを深掘りします。

レプリケーションインスタンスの基本概念とリソース設計

前述の「抽出・変換・ロード」というデータ移行の基本プロセスを実際に実行するエンジン部分が、このレプリケーションインスタンスです。AWS DMSを利用する際、ユーザーは自身のVPC内にこのインスタンスをプロビジョニング（確保）します。実態としてはAmazon EC2インスタンスに近い存在です。

インスタンスに求められるリソースは移行の規模によって異なります。具体的なインスタンスタイプ選択の目安は以下の通りです。

  • 小規模データやCDCの動作確認: dms.t3.medium などのバーストパフォーマンスクラスから開始するのがおすすめです。
  • 大規模データのFull Load（一括転送）: 大量データの読み書きにはCPUリソースが強く求められるため、dms.c5.large などのコンピューティング最適化クラスへのスケールアップを検討してください。

また、CDCを利用する際の重要なノウハウとして、ソースデータベース側の「トランザクションログの保持期間」が挙げられます。Full Loadの完了に時間がかかった場合、その間にソース側で発生した変更履歴が古い順から上書き（ローテート）されてしまうと、CDCの開始時にエラーが発生します。これを防ぐため、移行期間中はログの保持期間を十分に長く（例：24時間以上など）設定しておくことが強く推奨されます。

Note

大きなトランザクションが発生した場合、メモリだけでは処理しきれず、ディスク上で一時的にデータを保持する（バッファリング）動きをします。このため、ストレージ容量も適切に割り当てる必要があります。

マルチAZ構成によるフェイルオーバーと高可用性

データベースの移行は、ダウンタイムを最小限に抑えるために長時間のCDCが行われることがよくあります。もし移行の途中でレプリケーションインスタンスが止まってしまうと、移行作業が中断し、リカバリ作業に膨大な時間を要することになります。

これを防ぐための強力な武器が「マルチAZ（Multi-AZ）構成」です。このオプションを有効にすると、メインとは別のアベイラビリティーゾーン（物理的に離れたデータセンター群）に「スタンバイレプリカ」という予備のインスタンスが自動的に用意されます。

  • 自動フェイルオーバー: メインのインスタンスに障害が発生すると、AWSが自動的にスタンバイへ切り替えます。
  • データの冗長性: プライマリとスタンバイの間でデータが同期されるため、万が一の際もデータ損失を最小限に抑えられます。

Important

本番環境のデータを扱う移行や、ダウンタイムを許容できないプロジェクトにおいて、マルチAZ構成の選択は実質的な必須要件となります。

リソースのスケーリングとストレージの考慮点

移行の進捗状況やデータの量に合わせて、インスタンスのパワーを柔軟に変更できる「スケーラビリティ」も重要なポイントです。

設計・運用時に意識すべきポイントは以下の2点です。

  1. メモリ消費量: 複雑なデータ変換や大量の同時トランザクションが発生すると、メモリを激しく消費します。メモリ不足は処理速度の低下に直結するため、CloudWatchでメモリ使用率を監視し、余裕を持ったリソース選択を心がけてください。
  2. ディスクI/O性能: ディスクへのバッファリングが発生する際、ストレージのパフォーマンス（I/O性能）が低いと、そこがボトルネックになって移行全体のスピードを下げてしまいます。

Tip

本番移行の前に少量のデータでテストを実施し、CloudWatchを用いてリソース使用率の実測値を把握しておくのが、失敗しないリソース設計の近道です。

AWS DMSの料金体系と運用時のベストプラクティス

最後に、実際のプロジェクトで欠かせない「お金の話」と、現場で役立つ「運用時のベストプラクティス」を解説します。

AWS DMSの従量課金モデルと料金の最適化

AWS DMSの料金体系は、使った分だけ支払う「従量課金モデル」です。具体的には、主に以下の要素に対して料金が発生します。

  • レプリケーションインスタンス: 稼働させているコンピューティングリソース（インスタンスタイプ）に応じた料金です。
  • ログストレージ: 大容量データをバッファリングするためのディスク容量に対する料金です。
  • データ転送料金: ソースまたはターゲットとの間でデータを通信する際のネットワーク転送料金です。（※AWS外への転送やリージョン間を跨ぐ場合に発生します）
  • ログ保存料金: DMSのタスクログやメトリクスをAmazon CloudWatchへ出力・保存する際の標準料金です。

Tip

コストを抑えるための鉄則は「必要な時だけ動かす」ことです。移行作業が終わったら、レプリケーションインスタンスはすぐに削除しましょう。放置すると移行完了後も維持費がかかり続けます。

移行タスクのパフォーマンスを最適化する設定

「データの移行に時間がかかりすぎている」という場面で直面したボトルネックは、DMSのチューニング設定で解消できることがあります。

テーブルマッピングと並列処理

全てのテーブルを一律の設定で流すのではなく、データの性質に合わせて「テーブルマッピングルール」を設定します。巨大なテーブルに対しては並列処理（マルチスレッド）を有効にすることで、全体の完了時間を大幅に短縮できます。

ボトルネックの特定

パフォーマンスが出ないときは、以下のポイントを確認します。

  • レプリケーションインスタンスのスペック不足: CPUやメモリが限界に達していないか。
  • ネットワーク帯域: ソースとターゲット間の通信速度が制限されていないか。
  • ターゲット側の書き込み負荷: ターゲットのデータベースが大量のデータ流入に耐えられているか。

セキュリティとモニタリングの重要性

データを安全に移行し、移行中の不安を払拭するためには、セキュリティとモニタリングの体制が不可欠です。

データの保護と安全な接続

移行中のデータが第三者に覗き見られるリスクを防ぐため、AWS KMS（Key Management Service）を活用してレプリケーションインスタンス内のデータを暗号化してください。また、パブリックなインターネットを経由せず、VPCエンドポイントなどを利用してプライベートな通信経路を確保するのがベストプラクティスです。

CloudWatchによる「健康診断」

移行タスクの状況はAmazon CloudWatchで継続的に監視します。特に以下の指標に注意を払ってください。

  • CDCの遅延: ソースで発生した変更がターゲットに反映されるまでのタイムラグです。この値が大きくなり続けている場合は、インスタンスのスケールアップやタスク設定の見直しが必要です。

Important

移行作業は「やりっぱなし」が一番危険です。CloudWatchのアラームを設定しておき、遅延やエラーが発生した際にすぐに通知が届くようにしておくことで、トラブルの早期発見と迅速な対応が可能になります。

Warning

セキュリティ設定を疎かにすると、機密性の高いデータが漏洩するリスクがあります。必ず「最小権限の原則」に基づき、必要な通信経路と暗号化設定を設計段階から組み込んでください。

データベース移行はシステムの根幹に関わる重要な作業ですが、AWS DMSの機能やベストプラクティスを正しく理解・活用することで、ダウンタイムやリスクを最小限に抑えた確実な移行が実現します。ぜひ本番環境での構築に向けて、まずは小さなテスト環境で本記事の内容を試してみてください。