Azure Database Migration Service Public Preview が発表されました で、日本でもデプロイできることが確認できたので、Azure Database Migration Service (DMS) を検証してみました。
DMS のドキュメントについては、次の 2 種類を確認しておくとよいかと。
最終的には次のような複数のデータソースに対応する予定となっています。
(Announcing the Azure Database Migration Service Public Preview! の内容から)
現状の Public Preview では、「SQL Server 2005 ～ 2016 -> SQL Database への移行」のみ対応したサービスとなっています。
DMS のサービスは必ず仮想ネットワークに参加させる必要のあるサービスとなっており、その仮想ネットワークからアクセス可能な SQL Serverからデータの移行を実施することができます。
そのため、移行元の SQL Server については、DMS の仮想ネットワークからアクセスできる必要があります。
- DMS と同一の仮想ネットワーク内の SQL Server
- DMS の仮想ネットワークと VPN 接続されたネットワーク内の SQL Server
- DMS の仮想ネットワークと Express Route で接続されたネットワーク内の SQL Server
- DMS からアクセス可能なパブリック IP を付与されている SQL Server
というようなパターンが考えられそうですね。
最初に「DMS からどのようにして移行元の環境に接続を行うか」がポイントになってくるのではないでしょうか。
■移行作業の基本的な流れ
DMS を使用した SQL Server から SQL Database への移行ですが、現状はいくつかの作業を組み合わせて実施する必要があります。
現状公開されている情報としては、次のような方法になるのかと。
| SQL Server -> SQL Database | Data Migration Assistant (DMA) + Database Migration Service |
| SQL Server -> Managed Instance | ネイティブバックアップ + Database Migration Service |
| Oracle -> SQL Server | SQL Server Migration Assistant (SSMA) + Database Migration Service |
SQL Server から SQL Database に DMS で移行する場合、DMA と組み合わせて使用する必要があります。
この組み合わせの場合、DMS はデータの移行のみ対応をしており、スキーマの移行については、DMA を使用する必要があります。
DMA では二つの機能をサポートしています。
最初に「Assesment」を実行し、SQL Database に移行する際の問題を調査します。
問題が無ければ「Migration」でスキーマの移行を実行します。
最新の DMA であれば、次の 3 種類の操作を行うことができます。
- Schema and data
- Schema only
- Data only
最新の DMA であれば、データの移行にも対応しているため、DMS を使わなくても、実は DMA だけで移行を実施することも可能となっています。
単純なものであれば DMS を使わず、DMA のみで完結させることも考えるとよいのではないでしょうか。
実際のデータの移行では、次のようなことも考える必要があります。
- 移行ツールを実行する環境の構築
- 複数回のデータの移行を実行
- 移行ツールを実行する環境の性能
- 移行データの保存先
DMS はこれらをマネージドサービスとして利用することが可能なものとなりますので、DMS を使用するメリットも考えれば出てくるかと。
(SQL Server -> SQL Database 以外の移行に対応した場合は観点が変わってくることもあるかと思います)
現時点の基本的な流れとしては、次のようになるかと。
- DMA を使用してアセスメントを実行
- DMA のアセスメントで検出された問題を解消したデータベースを作成
- DMA を使用して、問題を解消したデータベースからスキーマを移行
- DMS を使用してデータの移行を実行
DMA では SQL Database への移行用スクリプトを生成するための機能があります。
アセスメントにより検出された問題が解決したら移行用のスクリプトを生成します。
作成したスクリプトは、DMA から実行することができますので、「Deploy schema」から SQL DB にスキーマの作成を行います。
これでスキーマの移行が完了したら、DMS を使用してデータの移行を実施します。
DMS では、「Database Migration Project」という移行用のプロジェクトを作成することができるようになっており、作成した DMS では、プロジェクトを作成して、データの移行を実行することになります。
(SSMA で対応している組み合わせについては、SSMA で作成したプロジェクトを DMS のプロジェクトとしてアップロードできるようになるのではないかと)
プロジェクトを作成すると、次のようなブレードから、移行の組み合わせを設定することができます。
投稿を書いている時点では、Source として「SQL Server」、Target として「Azure SQL Database」の組み合わせのみが選択できるようになっています。
移行の組み合わせを選択が完了したら、Source / Target を指定した、プロジェクトの基本的な設定を行います。
これで、プロジェクトが作成されますので、次のステップとして移行対象を選択します。
ポータルから作成したプロジェクトを選択すると「New Activity」の「Run Database Migration」から、実際の移行の設定を作成することができます。
移行対象の接続設定を再度実行する必要があるのですが、接続を実施した後は、移行元 / 移行先のデータベースを設定することになります。
DMS を使用する際の注意点として、移行先のデータベースにはすでにテーブルが作成されている必要がある点です。
現状、スキーマとテーブルのマッピングを変更するということはできないようで、移行元に同一のスキーマ / テーブルが存在していない場合は、移行を実施することはできません。
移行を実行できるテーブルについては選択ができるようになっていますので、選択できるテーブルについて移行を実施します。
一通り設定が完了すると「Run Migration」で移行を実行することができます。
移行を実行すると、以降状況を確認することができるようになります。
移行の結果については、PDF でもダウンロードできるようになっています。
現状、かなり機能が限定されている Preview ですが、今後も情報のキャッチアップをしていきたいですね。