Azure Database Migration Service の使用に関する FAQ

Azure Database Migration Service は、複数のデータベース ソースから Azure Data プラットフォームへのシームレスな移行を最小限のダウンタイムで実現できるように設計された、フル マネージドのサービスです。 このサービスは、現在一般公開されていますが、以下に重点を置いた開発が進行中です。

• 信頼性とパフォーマンス。
• ソースとターゲットのペアの反復的追加。
• スムーズな移行を実現するための継続的な投資。

このサービスは現在、さまざまなソースとターゲットのペアまたは移行シナリオをサポートしています。 利用可能な移行シナリオごとの状態の完全な一覧については、記事「Azure Database Migration Service によってサポートされる移行シナリオの状態」をご覧ください。

SQL Server から移行する場合、Azure Database Migration Service でサポートされているソースは SQL Server 2008 以降のバージョンです。 SQL Migration 拡張機能で Azure Data Studio を使用する場合、サポートされているソースは SQL Server 2008 から SQL Server 2022 です。

Azure Database Migration Service は、オフライン移行およびオンライン移行を行うことができます。 オフライン移行では、アプリケーションのダウンタイムが、移行の開始時に開始されます。 オンライン移行では、ダウンタイムが移行の最後の切り替え時だけに限定されます。 オフライン移行をテストして、ダウンタイムが許容可能かどうかを判断することをお勧めします。許容できない場合は、オンライン移行を行います。

Azure Database Migration Service は、Microsoft Azure への大規模なデータベース移行に適しています。 Azure Database Migration Service を他の Microsoft データベース移行ツールと比較したときの違いの詳細、およびさまざまなシナリオでサービスを使用するときの推奨事項については、「Microsoft のデータベース移行ツールとサービスの差別化」を参照してください。

Azure Migrate は、オンプレミスの仮想マシンから Azure IaaS への移行を支援します。 このサービスは、移行の適合性を評価し、パフォーマンスに基づくサイズを評価して、オンプレミスの仮想マシンを Azure で実行するためのコストを見積もることができます。 Azure Migrate は、オンプレミスの VM ベースのワークロードを Azure IaaS VM にリフトアンドシフト移行する場合に便利です。 ただし、Azure Database Migration Service とは異なり、Azure Migrate は、Azure SQL Database や Azure SQL Managed Instance などの Azure PaaS リレーショナル データベース プラットフォーム向けに特化したデータベース移行サービス オファリングではありません。

いいえ。 Database Migration Service は顧客データを格納しません。

Azure SQL VM と Azure SQL MI のターゲットの場合、DMS は物理的な移行、つまりバックアップと復元を使います。 以下で説明するように、選んだ移行モードによって、ソースとターゲットの間でデータの整合性どのように維持されるかが決まります。

• オフライン移行: Azure SQL VM と Azure SQL MI ターゲットへのオフライン移行の間は、移行が開始した時点で、アプリケーションのダウンタイムが始まります。 ソースからの最新のバックアップ ファイルが (移行構成に従って) SMB ネットワーク ストレージまたは Azure BLOB コンテナーに転送されている限り、DMS はすべてのバックアップ ファイルをターゲットに復元します。 バックアップが CHECKSUM オプションを使って作成されている場合、DMS 復元操作で検証が自動的に実行されます。 チェックサムがない場合は、復元の前にバックアップの整合性が明示的にチェックされます。 これにより、復元ファイルがバックアップ ファイルと同一であること、したがって同じデータが含まれることが確認されます。 DMS 移行監視ページに表示される、ターゲットに適用および復元されたバックアップ ファイルで、ソースからの最後のバックアップ ファイル名を含むすべてのバックアップ ファイルを確認し、それぞれのチェックサムを検証できます。

• オンライン移行: Azure SQL VM と Azure SQL MI ターゲットへのオンライン移行の間は、アプリケーションの停止と共に一括移行を開始すると、ダウンタイムが始まります。 ソースからの最新のバックアップ ファイルが (移行構成に従って) SMB ネットワーク ストレージまたは Azure BLOB コンテナーに転送されている限り、DMS はすべてのバックアップ ファイルをターゲットに復元します。 一括移行ボタンを選んだ後、DMS には、SMB ネットワーク ストレージまたは Azure BLOB コンテナーに存在し、ターゲットにまだ適用または復元されていない保留中のバックアップ ファイル (存在する場合) の数が示されます。 バックアップが CHECKSUM オプションを使って作成されている場合、DMS 復元操作で検証が自動的に実行されます。 チェックサムがない場合は、復元の前にバックアップの整合性が明示的にチェックされます。 これにより、復元ファイルがバックアップ ファイルと同一であること、したがって同じデータが含まれることが確認されます。 DMS 移行監視ページに表示される、ターゲットに適用および復元されたバックアップ ファイルで、ソースからの最後のバックアップ ファイル名を含むすべてのバックアップ ファイルを確認し、それぞれのチェックサムを検証できます。

Azure SQL DB がターゲットの場合、DMS は Azure SQL DB への論理的な移行を行います。つまり、ソースの SQL データベースのテーブルからデータをコピーし、それをターゲットの Azure SQL DB のテーブルに書き込みます。 DMS では Azure SQL DB へのオフライン移行のみがサポートされているため、移行が開始するとアプリケーションのダウンタイムが始まります。 (ソース データベースのテーブルから) 読み取られた行数と、コピーされた (ターゲットの Azure SQL DB テーブルに書き込まれた) 行数を、移行監視ページで監視して検証できます。 追加の確認として、次の TSQL を実行し、ソースとターゲット両方のデータベースでチェックサムを取得して、ソースと復元のデータが同一であることを検証できます。

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

注: ソースまたはターゲット DB に書き込んでいるアプリケーションがない場合。 データベース比較ツールのようなツールを利用して、データを比べることもできます。

次のリストには、データ移行を実行するためにバックグラウンドで作成される可能性のある Azure リソースが含まれています。 使用されるサービスは、移行シナリオによって異なる場合があります。

• Azure Monitor
• Azure VM
• Azure Storage
• Azure Service Bus
• Azure Data Factory

DMS は内部的に、ネットワークの場所、資格情報、バックアップ ファイル、完了したタスクに関する情報を含むメタデータ ストアを維持しています。 アカウント キーなどの資格情報と選択されたフィールドは暗号化されます。 テレメトリに含まれている可能性があるテーブル名などのデータはハッシュされます。 ユーザー名はサービス ログにプレーンテキストで表示される場合がありますが、パスワードがプレーンテキストで表示されることはありません。 テレメトリはリージョン別にサイロ化され、リテンション期間ポリシーによって管理され、Microsoft 内の権限のある担当者のみが有効なトラブルシューティングの目的で利用できます。 サーバー名やデータベース名などの Azure リソース名は Azure リソースの規則に従います。

DMS (クラシック) では、Azure Service Bus トピックを利用して、コンピューティング レイヤー間の通信を容易にします。 Azure Service Bus トピックは各 DMS インスタンスに固有であり、すべての個人データは暗号化されます。

Azure 仮想マシン上の Azure SQL Managed Instance と SQL Server

スキーマとデータは、バックアップと復元を使用して移行されます。 お客様は、ネットワーク共有から復元するか、ストレージ コンテナーから直接復元するかを選択できます。 Windows パフォーマンス データを含むファイルを使用して、オプションの (ただし強く推奨される) ワークロードのサイズ設定に関する推奨事項を提供することができます。

Azure SQL データベース

Azure SQL Database への移行は、2 つの手順で実行されます。 最初の手順は、スキーマの移行です。 DMS (クラシック) は、スキーマの移行に SQL 管理オブジェクト (SMO) を使用します。 2 番目の手順は、実際のデータ移行です。 SqlBulkCopy がデータ移行の実行に使用されます。 DMS はスキーマの移行をサポートしていません。 データは Azure Data Factory を使用して移行されます。 Windows パフォーマンス データを含むファイルを使用してワークロードのサイズ設定に関する推奨事項を提供することはオプションですが、強くお勧めします。

Azure Database for PostgreSQL

このシナリオで、エンド ユーザーは、pg_dump および pg_restore というコマンド ライン ユーティリティを使用して、メタデータ (この場合はスキーマ) を抽出します。 PostgreSQL の変更データ キャプチャを構成する場合、DMS は内部的に pg_dump と pg_restore を使用して CDC の初期シード処理を実行します。 データは、DMS インスタンスのみがアクセスできる暗号化された一時ストレージに格納されます。 Windows パフォーマンス データを含むファイルを使用して、オプションの (ただし強く推奨される) ワークロードのサイズ設定に関する推奨事項を提供することができます。

Azure Database for MySQL

このシナリオでは、スキーマの抽出と移行は、mysql-net/MySqlConnector を使用して DMS (クラシック) によって行われます。 可能であれば、MySQL binlog レプリケーションを使用して、データとスキーマの両方の変更をレプリケートします。 binlog レプリケーションが使用できない場合は、カスタム コードを使用して変更を同期します。

MongoDB から Azure Cosmos DB

DMS は、MongoDB からデータを抽出して Cosmos DB に挿入します。 BSON ダンプまたは JSON ダンプからデータを抽出するオプションも用意されています。

BSON ダンプの場合、DMS は BLOB コンテナー内の同じフォルダー内の bsondump 形式のデータを使用します。 DMS は、collection.metadata.json 形式を使用してメタデータ ファイルのみを検索します。

JSON ダンプの場合、DMS は、含まれるデータベースに由来する名前が付いた BLOB コンテナー フォルダー内のファイルを読み取ります。 各データベース フォルダー内で、DMS は data サブフォルダーに配置されたデータ ファイルのみを使用します。 DMS は、metadata サブフォルダーに配置され、メタデータの形式 collection.json を使用して名前が付けられたファイルのみを検索します。

Oracle から Azure SQL Database

このシナリオでは、AWR レポートまたは Windows perfmon ファイルを使用して、オプションの (ただし強く推奨される) ワークロード サイズ設定の推奨事項を提供します。 移行を実行するユーザーは、データベース スキーマ変換ツールキットを使用してスキーマの移行を実行し、ターゲット データベースを準備します。

Oracle から Azure Database for PostgreSQL

Oracle から Azure SQL Database への移行と同様に、このシナリオでは、AWR レポートまたは Windows perfmon ファイルを使用して、オプションの (ただし強く推奨される) ワークロード サイズ設定の推奨事項を提供します。 ora2pg ライブラリは、移行を実行するユーザーがスキーマを抽出し、手動でデータを移行するために使用されます。

DMS (クラシック) は、お客様のネットワーク構成に依存します。 移行元がプライベート エンドポイントを使用している場合は、プライベート エンドポイントを使用します。これが推奨される構成です。 パブリック エンドポイントが唯一のオプションである場合は、パブリック エンドポイントを使用します。

DMS は、データ移動のスケジュール設定と調整のために、バックグラウンドで ADF を頻繁に使用します。 さらに、セルフホステッド統合ランタイムは、お客様が独自の ADF パイプラインに既に使用している可能性があるものと変わりありません。 ファイアウォールとプロキシ サーバーの問題の詳細については、「セルフホステッド統合ランタイムを作成して構成する」を参照してください。

顧客データはすべて保存時に暗号化されます。 一部のメタデータ (論理サーバー名やデータベース名を含みますがこれらに限定されません)、移行の状態および移行の進行状況は、暗号化されていないサービス ログに表示されます。

既定では、転送中のすべてのデータは TLS 1.2 暗号化で保護されます。 以前のバージョンの TLS を必要とするレガシ クライアントでは、DMS (クラシック) ポータル ページで必要なバージョンが有効になっている必要があります。 DMS の場合、セルフホステッド統合ランタイムがインストールされているマシンは、レガシ クライアントに対応するために必要な TLS 設定を許可するように構成することができます。 SQL Server の TLS 構成の詳細については、「KB3135244 - Microsoft SQL Server の TLS 1.2 サポート」を参照してください。

可能な限り、プライベート エンドポイントが使用されます。 プライベート エンドポイントがオプションでない場合は、サービス レイヤー間の通信にパブリック エンドポイントが使用されます。 エンドポイントの種類に関係なく、すべてのリソースは DMS の特定のインスタンス専用であるか、特定のインスタンスにスコープ指定されており、一意の資格情報でセキュリティ保護されます。

データ プレーンまたはコントロール プレーン内のデータを暗号化するためのカスタマー マネージド キーはサポートされていません。 ただし、すべての顧客データは、サービスによって管理されるキーを使用して保存時に暗号化されます。 一部のメタデータ (論理サーバー名やデータベース名を含みますがこれらに限定されません)、移行の状態および移行の進行状況は、暗号化されていない形式でサービス ログに表示されます。

既定では、転送中のすべてのデータは TLS 1.2 暗号化で暗号化されます。 DMS (クラシック) ポータル ページでは、以前のバージョンの TLS をレガシ クライアントに使用できます。 DMS の場合、セルフホステッド統合ランタイムがインストールされているマシンは、レガシ クライアントに対応するための TLS 設定の管理を許可するように構成することができます。 SQL Server の TLS 構成の詳細については、「KB3135244 - Microsoft SQL Server の TLS 1.2 サポート」を参照してください。

カスタマー マネージド キーを使用してコントロール プレーンまたはデータ プレーン上のデータを暗号化する機能は公開していません。 DMS インスタンスが削除されると、ただちにサービス ログを除くすべての顧客データが削除されます。 DMS サービス ログは 30 日間だけ保持されます。

TDE

DMS は、Transparent Database Encryption (TDE) を実装するために、Azure SQL へのカスタマー マネージド キー (CMK) の移行をサポートしています。 TDE キーを移行する手順については、「チュートリアル: Azure Data Studio で TDE 対応データベース (プレビュー) を Azure SQL に移行する」を参照してください。

セルの暗号化

セル レベルの暗号化はスキーマ レベルで処理されます。 スキーマ移行ツールは、セル レベルの暗号化を実装するために必要な関数やストアド プロシージャを含むすべてのスキーマ オブジェクトを移行します。

常に暗号化

DMS では現在、ソースとターゲットの間で個々のデータ行が移行されるシナリオを使用した Always Encrypted の移行はサポートされていません。 Always Encrypted を使用して暗号化された列は、既存の SQL Server インスタンスから Azure SQL VM または Azure SQL Managed Instance への移動など、バックアップ/復元を使用するシナリオで想定どおりに移行されます。

Azure で既に利用できるもの以外の位置情報対応のアクセス制御は実装されていません。 DMS インスタンスに関連付けられているすべてのデータは、DMS リソースと同じリージョンに存在します。

当社のサービスは、それぞれ内部制御やビジネスプロセスが異なるさまざまな環境で使用されています。 DMS は、使用しているアカウントがアクセスできる任意の場所との間でデータを移動します。 自分が作業している環境のアクセス許可と内部制御を理解するのはユーザーの責任です。 DMS がソースへの接続に使用しているアカウントが、ソースから移行される予定のすべてのデータを表示するためのアクセス権を持っていることを確認することが特に重要です。

VNET インジェクションは、Microsoft テナント内に存在する Azure リソースを、顧客テナントの下の VNet 内のサブネットに追加するアクションです。 お客様のリソースへのアクセスを維持しながら、お客様に代わってコンピューティングを管理できるように、DMS ではこのアプローチを採用しました。 ネットワークはお客様のサブスクリプションに含まれているため、Microsoft は、Start、Stop、Delete、Deploy の各コマンドを発行する以外に VM を管理することはできません。 VM へのアクセスを必要とする他のすべての管理アクションには、お客様が開始したサポート リクエストと承認が必要です。

データベースを移行するときに Azure Database Migration Service を円滑に動作させるには、いくつかの前提条件があります。 いくつかの前提条件は、サービスでサポートされているすべてのシナリオ (ソースとターゲットのペア) に適用されますが、その他の前提条件は特定のシナリオに固有のものです。

サポートされているすべての移行シナリオで共通の、Azure Database Migration Service の前提条件は、次のとおりです。

• Azure Resource Manager デプロイ モデルを使用して、Azure Database Migration Service 用の Microsoft Azure 仮想ネットワークを作成します。これで、ExpressRoute または VPN を使用したオンプレミスのソース サーバーとのサイト間接続を確立します。
• 仮想ネットワークのネットワーク セキュリティ グループの規則によって、ServiceBus、Storage、AzureMonitor の ServiceTag のポート 443 がブロックされていないことを確認します。 仮想ネットワークの NSG トラフィックのフィルター処理の詳細については、ネットワーク セキュリティ グループによるネットワーク トラフィックのフィルター処理に関する記事を参照してください。
• ソース データベースの前でファイアウォール アプライアンスを使用する場合は、Azure Database Migration Service が移行のためにソース データベースにアクセスできるように、ファイアウォール規則を追加することが必要な場合があります。

Azure Database Migration Service を使用して特定の移行シナリオを試すために必要なすべての前提条件の一覧については、Azure Database Migration Service ドキュメントの関連チュートリアルを参照してください。

Azure Database Migration Service が移行のためにソース データベースにアクセスできるように、ファイアウォール規則を追加することが必要な場合があります。 サービスの IP アドレスは動的ですが、ExpressRoute を使用している場合、このアドレスは企業ネットワークによってプライベートに割り当てられます。 適切な IP アドレスを特定する最も簡単な方法は、プロビジョニングされた Azure Database Migration Service リソースと同じリソース グループを検索して、関連付けられているネットワーク インターフェイスを見つけることです。 通常、ネットワーク インターフェイス リソースの名前は、NIC プレフィックスで始まり、その後に一意の文字と数字のシーケンスが続きます (例: NIC-jj6tnztnmarpsskr82rbndyp)。 このネットワーク インターフェイス リソースを選択すると、Azure portal のリソースの概要のページに、許可リストに含める必要がある IP アドレスが表示されます。

また、SQL Server がリッスンしているポート ソースも許可リストに含めなければならないことがあります。 既定ではポート 1433 ですが、ソース SQL Server が他のポートもリッスンするように構成されていることがあります。 その場合、それらのポートも許可リストに含める必要があります。 次の動的管理ビュー クエリを使用すると、SQL Server がリッスンしているポートを特定できます。

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

SQL Server エラー ログに対して次のクエリを実行して、SQL Server がリッスンしているポートを特定することもできます。

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

仮想ネットワークのセットアップ手順を説明する複数の Microsoft チュートリアルがありますが、公式ドキュメントは Azure Virtual Network に関する記事に掲載されています。

一般的な単純なデータベース移行では、以下の作業を行います。

1. ターゲット データベースを作成します。
2. ソース データベースを評価します。
   • 同種移行を行う場合は、DMA を使用して既存のデータベースを評価します。
   • 異種移行 (競合ソースから) を行う場合は、SSMA を使用して既存のデータベースを評価します。 SSMA は、データベース オブジェクトを変換してスキーマをターゲット プラットフォームに移行する場合にも使用します。
3. Azure Database Migration Service のインスタンスを作成します。
4. ソース データベース、ターゲット データベース、および移行するテーブルを指定する移行プロジェクトを作成します。
5. 完全読み込みを開始します。
6. 後続の検証を選択します。
7. 運用環境を新しいクラウドベースのデータベースに手動で切り替えます。

移行作業中にソース データベース システムへの接続で問題が発生した場合は、DMS インスタンスを設定するために使用する仮想ネットワークの同じサブネット内に仮想マシンを作成します。 その仮想マシンでは、UDL ファイルを使用して SQL Server への接続をテストする、または Robo 3T をダウンロードして MongoDB の接続をテストするなど、接続テストを実行できるはずです。 接続テストに成功した場合、ソース データベースへの接続に問題はありません。 接続テストが成功しなかった場合は、ネットワーク管理者に問い合わせてください。

ユーザーが明示的に Azure Database Migration Service (DMS) を停止した場合、またはサービスが 24 時間非アクティブな場合、サービスは停止状態または自動一時停止状態になります。 いずれの場合も、サービスは利用できず、停止状態になります。 アクティブな移行を再開するには、サービスを再起動します。

このサービスによるデータベースの移行を高速化するために、次のようなことができます。

DMS (クラシック) の場合

• サービス インスタンスを作成するときにマルチ CPU の汎用価格レベルを使用して、サービスが並列化とデータ転送の高速化のために複数の vCPU を活用できるようにします。
• データ移行操作中に Azure SQL Database ターゲット インスタンスを一時的に Premium レベル SKU にスケールアップして、下位レベルの SKU を使用するときにデータ転送アクティビティに影響を与える可能性がある Azure SQL Database の調整を最小限に抑えます。

DMS の場合

• ローカル ファイル共有から Azure Blob Storage にバックアップをコピーする場合、またはターゲット Azure SQL DB への移行の実行中に、DMS は SHIR ノードをコンピューティングとして使います。 ですので、その SHIR ノードのリソース使用状況を監視してください。
• データ移行操作中に Azure SQL Database ターゲット インスタンスを一時的に Premium レベル SKU にスケールアップして、下位レベルの SKU を使うとデータ転送アクティビティに影響する可能性がある Azure SQL Database ディスクのスロットリングを最小限に抑えます。
• 詳しくは、ブログを参照してください。

次のステップ

• Azure Database Migration Service とは何ですか。