（この記事は2018年11月2日にHybrid Cloud Best Practices blogに掲載された記事Migration from SQL Server to Azure SQL Database Managed Instanceの翻訳です。最新情報についてはリンク元のページをご参照ください。）

今回は、SQL Server 上で実行されているデータベースを新しい Azure SQL Database Managed Instance に移行する方法についてご説明します。

Azure SQL Database Managed Instance (SQL MI) は、 の新しいデプロイメント モデルです。SQL Server データベース エンジンとほぼ 100% の互換性があり、PaaS のメリットを活用できます。そのため、SQL Server データベースのパブリック クラウドへの移行をお考えの場合は、SQL MI を優先的に検討されることをお勧めします。特に、SQL Server 2008 を現在もご利用の場合は、サポート終了まで 1 年を切っていますので、お早めにご対応をお願いいたします。

SQL MI は、Azure インフラストラクチャにデプロイされ、マイクロソフトによって管理される特別なバージョンの SQL Server です。とは言え、SQL Server インスタンスがお客様専用であり、他のお客様とは共有されないため、SQL MI と現在ご利用になっている通常の SQL Server は、今日の市場に出回っている他の DBaaS サービスに比べればそれほど大きな違いはありません。

今回は、ワークロード レベルの変更を最小限に抑えながら、既存の SQL Server から SQL MI にワークロードを移行する方法をご紹介します。

準備

SQL Server データベースの Azure SQL MI への移行は以下の手順で行います。

Data Migration Assistant (DMA) を使用して環境を評価します。DMA は、使用中の SQL Server データベースと SQL MI の互換性の有無を分析するためにお客様の環境内で実行できる軽量なツールです。

1. Data Migration Assistant (DMA) を使用して環境を評価します。DMA は、使用中の SQL Server データベースと SQL MI の互換性の有無を分析するためにお客様の環境内で実行できる軽量なツールです。
2. 移行後のアプリと SQL MI の接続方法を決めます。ベスト プラクティスとしては、可能な限りフロントエンドをバックエンドの近くに確保することが推奨されます。したがって、データベースをオンプレミスの SQL Server から SQL MI に移行する場合は、フロントエンド サーバーも Azure VM や Azure App Service に移行することを検討してください。たとえば、Azure Migrate や別のリフト & シフト ツールを使用して、フロントエンド サーバーとオンプレミスの SQL Server の両方をまとめて Azure に移行した後、Azure VM 内の SQL Server から SQL MI にデータベースを移行することができます。
3. Azure ポータルで新規の SQL MI を作成します。最初の SQL MI インスタンスのデプロイメントには最大 6 時間かかるため、この作業を最初に行うことをお勧めします。ただし、追加のインスタンスのデプロイメントには 1 時間もかかりません。
4. 新規の Azure Database Migration (DMS) インスタンスを作成します。DMS は、さまざまなデータベースを各種 Azure データベース サービスに移行できる無料のサービスです。MySQL、PostgreSQL、MariaDB データベースを Azure Database for MySQL/PostgreSQL/MariaDB に移行できるほか、SQL MI などへの SQL Server の移行もサポートしています。
5. DMS を移行元の SQL Server と移行先の SQL MI に接続します。
6. 移行を実行します (オンラインまたはオフライン)。
7. アプリの接続文字列を変更して、SQL MI のホスト名を接続先に指定します。

SQL MI についての重要ポイント

1. SQL MI は、SQL Server 2008 以降との下位互換性がある SQL Server 2017 Enterprise Edition をベースにしています。ここで非常に重要な点として、SQL Server を使用しているアプリの最新の互換性レベル (80 ～ 150 までの数字で表される) を確認する必要があります。SQL Server の各バージョンでは機能の追加や更新が行われているため、アプリで適切な構文の T-SQL クエリを使用して、適切な方法でストアド プロシージャを呼び出すために、互換性レベルという概念が採用されています。SQL Server 2000 の互換性レベルは 80 に設定されており、以降のバージョンごとに 10 ずつ増加します (最大は SQL Server 2019 の 150)。下位互換性を確保するために、新しいバージョンの SQL Server では以前のバージョンの SQL Server の互換性レベルがサポートされます。たとえば、SQL Server 2017 では、互換性レベル 100 (SQL Server 2008) から 140 (SQL Server 2017) がサポートされています。そのため、アプリで必要な互換性レベルが 100 (SQL Server 2008) で、SQL Server 2014 を使用している場合は、問題なく SQL MI に移行できます。しかし、互換性レベル 80 (SQL Server 2000) のアプリを使用しており、そのレベルがサポートされている SQL Server 2008 で実行している場合、SQL MI では互換性レベル 100 以上しかサポートされていないため、SQL MI に移行することはできません。このような状況が生じる可能性があるのは、10 年近く前に作成した非常に古いワークロードを更新せずに使用し続けているような場合です。また、インプレース アップグレードを使用すれば互換性レベル 90 から 100 にアップグレードすることができますが、必ず互換性レベル 90 と 100 の相違点をご確認いただき、アプリへの影響がないようにしてください。
2. SQL MI は SQL Server データベース エンジンです。SQL Server エージェントは含まれていますが、以下のような SQL Server 製品の他のコンポーネントは含まれません。
   1. SQL Server Reporting Services (SSRS): Azure には SSRS の従来の改ページ調整されたレポートに代わる機能はなく、VM 内で SQL Server を実行するしかありません。ただし、改ページ調整されたレポートから Power BI 形式のレポートへの切り替えを済ませている場合は、それらのレポートを Power BI に問題なく移行できます。
   2. SQL Server Analysis Services (SSAS): Azure では、SSAS をベースにした PaaS ソリューションである Azure Analysis Services が提供されているため、既存の SSAS の代わりに使用することができます。SSAS には独自の互換性レベルがあり、Azure Analysis Services では 1200 以上 (SQL Server 2016 以降) がサポートされます。
   3. SQL Server Integration Services (SSIS): アプリで SSIS を利用している場合は、Azure Data Factory にデプロイできます。
3. アプリと SQL MI 間の接続オプションについては、こちらの記事をご確認ください。また、以下の点に留意してください。
   1. SQL MI を使用するには、特定の要件に準拠するサブネットを新規または既存の VNet 内に作成する必要があります。SQL MI のデプロイメント中に Azure ポータルで VNet を新規作成することを選択すると、アドレス空間 10.0.0.0/16、サブネット 10.0.0.0/24 の VNet が作成されます。SQL MI の既定のクラスター IP は 10.0.0.254 です。既存の SQL Server 環境のアドレス空間が 192.168.x.x など、10.x.x.x の範囲外である場合は、そのまま使用することができます。ただし、既にアドレス空間 10.x.x.x を使用している場合は、アドレス空間の競合により、既存のネットワークを SQL MI の VNet に接続することができません。そのような場合は、こちらのスクリプトを使用して、必要なすべてのルールが適用された新規の VNet を作成することを検討してください。
   2. SQL MI は、インターネットに公開できず、IP を指定して直接アクセスすることはできません。SQL MI は Azure VNet 内に割り当てられたプライベート IP (既定では 10.0.0.254) と、パブリックに解決可能なホスト名 (<mi-name>.<unique-id>.database.windows.net という形式) を持ちます。ただし、このプライベート IP は SQL MI のものではなく、Managed Instance Gateway (GW) にトラフィックを転送する内部ロード バランサーの IP です。同じ IP の同一クラスター内で複数の Managed Instance を実行することが可能なため、トラフィックを適切な SQL エンジン サービスに転送するために、GW で Managed Instance のホスト名 (<mi-name>.<unique-id>.database.windows.net) が使用されます。詳細はこちらのページをご覧ください。要するに、アプリを SQL MI に接続するには、ホスト名を使用する必要があります。プライベート IP を使用して直接接続しようとすると、GW で接続先のインスタンスを特定することができないため、接続が拒否されます。
   3. 上記の理由から、アプリ レベルで接続文字列を変更して、既存の SQL Server の IP/FQDN から SQL MI のホスト名に切り替える必要があります。IP を指定して SQL MI に直接アクセスすることはできないため、ホスト ファイルを変更する方法は利用できません。DNS CNAME を使用して (接続文字列を変更することなく) SQL MI に接続する機能は、SQL MI の今後のバージョンで追加される予定です。
   4. SQL MI では、名前付きパイプ (英語) による接続はサポートされていません。そのため、アプリが名前付きパイプを使用して SQL Server に接続している場合は、TCP/IP ソケットに切り替える必要があります。
   5. 現在、SQL MI では SQL Server ログイン資格情報のみがサポートされています。Azure AD ログイン資格情報のサポートは、今後のバージョンで追加される予定です。Windows ログイン資格情報はサポートされていません。そのため、アプリが Windows 認証を使用して SQL Server に接続している場合は、SQL Server 認証に切り替える必要があります。または、SQL MI で Azure AD ログイン資格情報がサポートされるまで待ってから、既存の Windows ログイン資格情報を Azure AD ログイン資格情報に変更してください。
4. SQL Server Management Studio (SSMS) 18 を使用することをお勧めします。SSMS 17.9 では、SQL MI の管理に関する問題が発生するからです。たとえば、SSMS 17.9 では、UI を使用して新規データベースを作成しようとするとエラーがスローされます。原因としては、CREATE DATABASE コマンドの構文が SQL MI と異なることが考えられます。クエリを使用したコマンドの実行は正常に機能します。このバグは SSMS 18 で修正されました。

SQL MI への移行に関連する DMS の重要ポイント

1. Azure Database Migration Service には、SQL MI の General Purpose と Business Critical に対応する 2 種類の価格レベルがあります。General Purpose には、vCore 数が 1、2、4 のインスタンス サイズを選択できます。Business Critical には、vCore 数が 4 のインスタンス サイズのみが提供されています。インスタンス サイズが大きくなると、データ レプリケーションや移行元から移行先への転送を実行するために使用できるコンピューティング性能が向上し、移行を短時間で実施することができます。2018 年 12 月 31 日までは無料となっていますので、Business Critical のレベルでご利用になり、ダウンタイムを短縮することをお勧めします。
2. DMS では、オフラインでもオンラインでも SQL MI への移行が可能です。オンライン モードは、Business Critical レベルの DMS インスタンスでのみ利用できます。
   1. オフライン移行モードでは、DMS が移行元データベースの完全バックアップを実行し、そのバックアップをローカルのネットワーク共有から Azure Storage Blob にコピーして、SQL MI に復元します。DMS で最終の完全バックアップを開始する前に、移行元データベースに対するすべての書き込みトランザクションを停止する必要があります。つまり、完全バックアップを作成し始めてから、Azure Blob にアップロードして、MI に復元するまでの間は、データベースへの書き込みを行うことができません。この時間はデータベースのサイズによって異なり、データベースのサイズが小さければ数分、大きければ数時間かかります。SQL Server ログイン資格情報と現在のパスワードも、SQL Server から SQL MI にコピーされます。移行中にデータベースを読み取り専用モードにしてもかまわない場合は、オフライン移行モードを使用することをお勧めします。
   2. オンライン移行モードでは、完全バックアップとトランザクション ログの増分バックアップをユーザーが実行する必要があります。その後、DMS がこれらのファイルをローカルのファイル共有から Azure ストレージ アカウントにアップロードして、SQL MI にデータベースを復元します。このとき、まずは完全バックアップを復元してから、トランザクション ログのすべての増分バックアップを適用します。つまり、ユーザーが移行の直前にデータベースを読み取り専用モードにして、最終のトランザクション ログ バックアップを実行すると、それが DMS で自動的にアップロードされ、SQL MI の最新のデータベース コピーに適用されます。この処理が完了したら、すぐに DMS でフェールオーバーを実行して、SQL MI データベースに読み取りと書き込みを行えるようにします。大きなサイズのデータベースでも、完全バックアップを実行して Azure Blob へのアップロードが完了するまで待つ必要がないため、ダウンタイムはオフライン移行モードよりも大幅に短くなります。ただし、SQL Server に対して DMS のオンライン移行モードを使用する場合はデメリットもあります。
      1. 1 つの DMS インスタンスにつき最大 2 つのアクティビティ、1 つのアクティビティにつき最大 4 つのデータベースを移行できます。つまり、同時に移行、切り替えできるデータベースは 8 つまでとなります。
      2. Business Critical レベルの DMS インスタンスを使用する必要があり、DMS のキャンペーン期間が終了すると、移行コストが増える可能性があります。
      3. SQL Server ログイン資格情報は、手動で移行する必要があります。
      4. 単純復旧モデルのデータベースでは利用できません。
3. 現時点では、オフライン モードとオンライン モードのエクスペリエンスは異なりますが、DMS チームは UI の統合に取り組んでいます。
4. DMS では、データベース バックアップのチェックサムを実行する必要があります。既存のバックアップに対してその設定を有効にしていなかった場合は、バックアップを再度実行する必要があります。
5. SQL Server ログイン資格情報は、オフライン モードでのみ移行されます。Windows ログイン資格情報は、SQL MI ではサポートされないため移行されません。Windows ログイン資格情報を Azure AD ログイン資格情報に変換する機能は、DMS の今後のバージョンで追加される予定です。
6. SQL Server エージェントのジョブは、DMS の UI では移行されませんが、PowerShell を使用して移行できます。DMS の UI でのジョブの移行は、今後のバージョンで追加される予定です。
7. 移行に時間がかかりすぎる場合や失敗する場合は、大きなサイズの DMS インスタンス (4 vCore) を使用するか、Business Critical のレベルに切り替えることをお勧めします。

それでは、移行作業を始めましょう。

移行元の環境

今回は、移行元の環境として懐かしの Windows Azure Pack (WAP) を使用します。WAP を Azure に移行するのは実用的ではありませんが、DMS を使用した SQL MI への移行のメリットは確認できます。WAP では、管理データベースや各テナントのデータベースなど、相互接続された複数のデータベースを利用しています。SQL Server 認証がサポートされており、データベース エンジン以外の SQL Server のコンポーネントは必要ありません。そのため、実世界のワークロードをオンプレミスの SQL Server から SQL MI に移行するデモにはうってつけです。

移行元の環境は 2 つの VM で構成されています。

1. フロント エンド: すべての Windows Azure Pack コンポーネント (テナント ポータル、管理ポータル、リソース プロバイダー)、Windows Server 2012、プライベート IP (10.0.1.4)、インターネット アクセス用のパブリック IP
2. バックエンド: Windows Server 2012 上の SQL Server 2012、Windows Azure Pack の 7 つの管理データベースと 1 つのテナント データベース (db01)、プライベート IP 10.0.1.5、パブリック IP なし

2 つの VM は、SQLMigrationRG-vnet という VNet 経由で相互接続されています。

今回の目標は、すべてのデータベースをバックエンド VM から SQL MI に移行し、フロントエンド VM の Windows Azure Pack の接続文字列を変更して、バックエンド VM の利用を止めることです。すべての手順は Windows Server 2008 と SQL Server 2008 で同一であるため、これを参考にして、サポート終了に対応することができます。

手順 1: DMA を使用した評価

SQL Server Database Migration Assistant を使用して、データベースと SQL MI の互換性があることを確認します。SQL Server にネットワーク アクセス可能な Windows マシン上で、または SQL Server 上で実行します。手順は簡単です。[Assessment] を選択し、[Source server type] で [SQL Server]、[Target server type] で [Azure SQL Database Managed Instance] を指定します。

次に、サーバーの IP/FQDN を入力し、sysadmin ロールを持つユーザーの資格情報を指定します。

評価したいプロセスを選択します。

数分待ってから結果を確認します。移行に影響する問題がないことを確認し、すべての警告に目を通します。この例では、すべて問題ありません。

手順 2: SQL MI インスタンスの作成

Azure Portal にアクセスし、[Create a resource]、[Databases]、[Azure SQL Database Managed Instance] の順にクリックします。

Managed Instance 名と管理者のログイン資格情報を入力したら、ウィザードで VNet を新規作成するか、要件を満たしたサブネットを指定するか (以前に手動で作成している場合) を選択します。

[Create new] を選択した場合は、アドレス空間 10.0.0.0/16 の VNet が標準名で作成されます。

デプロイメントが完了するまで数時間待ちます。

手順 3: DMS インスタンスの作成

Azure Portal にアクセスし、[Create a resource] をクリックして、「Database Migration Service」と検索し、[Create] をクリックします。

DMS インスタンス名を入力し、移行元の SQL Server が存在する仮想ネットワークを指定して、価格レベルを選択します。今回はオンライン データベース移行モードを使用するため、[Business Critical] レベルを選択することにします。

DMS インスタンスが作成されるまで 1 時間待ちます。

手順 4: 移行元 SQL Server、SQL MI、DMS の接続

DMS を使用して移行するためには、ネットワーク経由で移行元の SQL Server と移行先の SQL MI に接続できるようにする必要があります。この例では、移行元サーバーと移行先サーバーが同じ Azure リージョン内の別々の VNet に存在するため、VNet ピアリングを使用します。

ここで、移行元 SQL Server が存在する VNet のアドレス空間は 10.0.1.0/24 であるため、SQL MI VNet のアドレス空間 10.0.0.0/16 と競合しています。これを解決するために、SQL MI VNet のアドレス空間を 10.0.0.0/24 に変更します。これで、2 つの VNet に 10.0.0.0/24 (SQL MI VNet) と 10.0.1.0/24 (移行元の SQL Server が存在する VNet) という 2 つのアドレス空間が指定されました。

先ほどの VNet 設定に戻り、[Peerings] を選択して、SQL MI VNet から別の VNet へのピアリング要求を作成します。次に、もう一方の VNet 側でも同じ操作を行い、SQL MI VNet へのピアリング要求を作成します。

両側でリクエストを作成すると、ピアリングの状態が [Connected] になります。

これで、SQL Server Management Studio を使用して、移行元 SQL Server が存在する VNet 内の任意の VM から SQL MI に接続できるようになりました。

以下のスクリーンショットのように、SQL MI では互換性レベル 100 (SQL Server 2008) から 140 (SQL Server 2017) までのデータベースがサポートされます。

SQL MI では Windows 認証ログインがサポートされていないため、[New Login] メニューでは Windows 認証が灰色で表示されます。

手順 5: DMS の構成

Azure Portal にアクセスし、[All services] をクリックして、「Azure Database Migration Service」で検索します。[New migration project] をクリックし、プロジェクト名を入力して、[Online data migration] を選択します (オンライン モードとオフライン モードの違いについては、この記事の冒頭をご覧ください)。

移行元 SQL Server の FQDN/IP と sysadmin のユーザー資格情報を指定します。ほとんどの場合、[Trust server certificate] を選択しないと DMS の接続が失敗します。

接続に成功すると、次の手順として移行元サーバーで実行されているすべてのデータベースが表示されます。すべてのデータベースを選択します。

SQL MI の FQDN とユーザー資格情報を入力します。

[Save] をクリックして、この移行プロジェクトを保存します。

手順 6a: オンライン モードでのデータベースの移行

DMS のオンライン モードを使用するには、Azure Active Directory でアプリの登録を作成する必要があります。Azure AD の設定から [App Registrations]、[Create] の順にクリックし、任意の名前と解決可能なサインオン URL (例: https://portal.azure.com) を指定します。

次に、[Keys] に移動してキーを新規作成します。[Save] をクリックすると、キー値が表示されます。そのキーとアプリケーション ID は後で必要になるため、メモしておきます。

次に、Azure サブスクリプションの設定に移動して、このアプリに [Owner] のアクセス許可を割り当てます。

移行するデータベースのバックアップを作成していない場合は、この時点で行います。[Perform checksum before writing to media] を忘れずに有効にしてください。これは、SQL Server バックアップに関する DMS 側の要件です。実際にはこの時点で、移行するデータベースの完全バックアップとトランザクション ログ バックアップは既に済んでいる状態かと思います。

バックアップが保存されているフォルダーを共有します。UNC パスを使用して、SQL Server サービスのユーザーがアクセスできるようにするか、念のために [Everyone] を選択します。

これで、すべてのバックアップが同じフォルダーに確保され、SQL Server サービスからアクセス可能になりました。

DMS のページに戻り、[New Activity]、[Online data migration] の順にクリックします。

移行元 SQL Server を選択し、移行先について入力するページで、先ほど取得したアプリケーション ID とキーを指定します。

移行するデータベースを最大 4 つ選択します (オンライン モードの DMS の単一アクティビティにおける現時点での制限)。

データベース バックアップが保存されているファイル共有のパスを指定します。このファイル共有には、移行元 SQL Server からアクセスできる必要があります。バックアップを Azure ストレージ アカウントにアップロードするためのユーザー資格情報を指定し (この例では移行元 SQL Server VM のローカル管理者の資格情報を使用)、データベース バックアップをコピーする Azure ストレージ アカウントを選択します。

すべてのバックアップが Azure ストレージ アカウントにアップロードされ、SQL MI のデータベース レプリカに適用されるまでしばらく待ちます。処理が完了したら、すぐにデータベースを選択し、[Complete cutover] をクリックします。

次に、そのデータベースに対するすべての受信トランザクションを停止し、最終のトランザクション ログ バックアップを実行して、レプリカに適用されるまで待ちます。処理が完了すると、[Pending log backups] が 0 になります。

[Confirm]、[Apply] の順にクリックします。しばらくすると、移行の状態が [Completed] になります。残りのデータベースに対して同じ手順を繰り返します。

手順 6b: オフライン モードでのデータベースの移行

もう一方のモードの手順を説明するために、残りの 4 つのデータベースは DMS のオフライン モードを使用して移行します。

オフライン モードの UI は、オンライン モードの場合と多少異なります。Azure AD でアプリの登録を作成する必要はありませんが、Azure Storage Explorer から操作する必要があります。Azure Storage Explorer をインストールしたら、Azure サブスクリプションにログインして、新規または既存の Azure ストレージ アカウント内にコンテナーを新規作成し、[Get Shared Access Signature] をクリックします。

[Read]、[Write]、[Delete]、[List] のアクセス許可を選択します。後で必要になるため SAS の URI をメモしておきます。

Azure Portal に戻り、DMS ページを開いて、[New Activity]、[Offline data migration] の順にクリックします。

オンライン モードのときの説明と同様に、移行元の SQL Server と移行先の SQL MI を選択します。

移行するデータベースを選択します。次に、SQL MI に移行するログイン資格情報を選択します (注: ログイン資格情報の移行は、現時点ではオフライン モードのみで実行できます)。SQL MI では Windows 認証ログインがサポートされていないため、SQL Server ログイン資格情報のみを選択できます。

DMS でデータベースの完全バックアップを実行するか、既存の完全バックアップを再利用するかを選択します。バックアップを保存する (または既に保存されている) ネットワーク共有を指定します。バックアップを Azure ストレージ アカウントにアップロードするためのユーザー資格情報を指定し (この例では移行元 SQL Server VM のローカル管理者の資格情報を使用)、先ほど取得したストレージ コンテナーの SAS URI を入力します。

最後の手順で [Validate my databases] を選択して、移行の完了後にテスト クエリを実行します。

移行元 SQL Server から SQL MI へのデータベースおよびログイン資格情報の移行の進行状況を確認します。処理にかかる時間は、データベース バックアップの合計サイズによって異なります。処理が完了すると、状態が [Restoring] から [Completed] に変わります。

これで、移行対象の 8 つのデータベースがすべて SQL MI に移行されたため、両方の移行アクティビティの状態が [Completed] になります。SQL Server Management Studioを使用して SQL MI に接続し、すべてのデータベースと SQL Server ログイン資格情報が移行されたこと、エラーがないことを確認します。

手順 7: SQL MI へのアプリの接続先の変更

最後に、アプリ内の接続文字列を SQL MI のホスト名に変更します。ユーザーのログイン資格情報とパスワードなど、接続文字列の他の設定を変更する必要はありません。移行元サーバーの FQDN/IP を SQL MI のホスト名に置き換えてから、アプリを再起動します。この例では、Windows Azure Pack のすべての Web サイトの接続文字列を更新する必要があります。

手順は以上です。これで、Windows Azure Pack のテスト環境は、SQL MI で実行され相互接続された 8 つのデータベースに切り替わりました。今回、アプリ レベルで行う必要のある変更は、接続文字列だけというわずかな調整のみでした。

上記の手順は複雑なように見えるかもしれませんが、1 回目の移行を完了すれば慣れるでしょう。SQL MI への移行にはそれなりの労力がかかりますが、それに見合うだけのメリットが得られます。多少の時間をかけて一度データベースを移行すれば、その後は OS 修正プログラムのインストール、VM のサイズ変更、新しいバージョンの SQL Server への更新といった作業が不要になります。