本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Azure Database Migration Serviceを使ってDB移行を試してみた」を再編集したものです。
はじめに
お久しぶりです。石川です。Quest2を買ったりDDJ-FLX4を買ったりして遊んでるうちに年末ですね。こわい。
さて先日、Azure PortalよりAzure Database Migration Serviceが利用できるようになりました。
（General availability: Azure Portal experience for Azure Database Migration Service参照）
今回はこのサービスを早速試してみようと思います。
データベースのマイグレーションということで、オンプレミスで保有しているSQL ServerからAzure SQL Databaseへの移行が考えられるので、そのストーリーを想定した環境を立ててやってみます。
環境準備
偶然にも家にサーバーが転がっていたのでそいつらを活用します。
今回使うサーバーはこちら
・Dell PowerEdge R430（Intel Xeon E5-2620v4 8×2CPU／DDR4-2400T 8GB×8）
環境準備 - WindowsとSQL Server
PowerEdgeにVMware ESXiが入っているので良い感じに準備します。
用意したものがこちら。
for Advent Calendarと書いてある方のWindows ServerにSQL Server 2022 Expressがインストールしてあります。
ダミーテーブルを用意し、5000件のダミーデータを投入してあります。
Azure Migrate - アセスメント
Azure Database Migration Serviceにかける前にAzure Migrateを使ってアセスメントをします。
しなくてもいいっぽいですが、せっかくなのでしておきましょう。
データベース（のみ）を選択してプロジェクトの作成をします。
画面がちょっと崩れてますが、中央の“プロジェクト…”となっているボタンを押下するとプロジェクトの作成画面に進めます。
必要項目を埋めて作成します。
5分程度待ちました。
作成が完了すると、画面が変化するので評価ツールなるものをDLして環境にインストールしてみます。
インストールしたら手順に沿ってやってねとのことなので手順に従い進めます。
手順の最後で、Azure Migrateへ結果をアップロードするところでエラーとなってしまいました。
テナントの問題っぽく、アセスメントは成功しているのでスルーして進めます。
（結果を見れないのでAzure Migrateのプロジェクトはデプロイしても使わず仕舞いになりました…）で
Azure Database Migration Service - デプロイ
では本題のAzure Database Migration Serviceを進めます。
まずはリソースのデプロイです。
今回はオンプレミスのSQL ServerからAzure SQL Databaseへの移行なので上記の選択で進めます。
入力項目はリソースグループとリソース名なので上記選択を間違えなければOKです。
デプロイが完了したら、早速マイグレーションの開始をかけま……………
無理でした。
セルフホステッド統合ランタイムが必要と出ていますね。
Azure Database Migration Service - セルフホステッド統合ランタイムの準備
英語だとSelf hosted integration runtimeですかね。
統合ランタイムのページに遷移すると、インストールしてキーを入れてくれとのことなのでやっていきます。
インストールが完了すると以下のような表示になるので、Azure Portalに表示されている認証キーをコピペして登録します。
繋がったっぽいですね。
ポータルからも見えてます。
複数台に入れていいらしいのでもう一台生やしてみましょう（複数ノードの場合はイントラネットからのリモートアクセスを有効にする必要があるようです）。
増えました。おもろい。
では移行を実行していこうと思います。
Azure Database Migration Service - 移行の作成
早速作成をしていきます。
SQL Server → Azure SQL Database の場合、現在はオンラインでの移行が不可能なようです。
今回は致し方なく、オフラインで実行します。
ちなみにオンラインとオフラインどちらを選ぶか迷う場合は以下の点で判断すると良いかなーと思います。
・オンライン: 移行中にDBのダウンタイムが許容できない場合に選択
・移行中に発生した移行元DBへの書き込みが反映されない可能性がある
・オフライン: 移行中にダウンタイムが許容できる場合に選択
・メンテナンス時間など移行作業中にDBへの処理が発生しないならこっち
では早速SQL Databaseへのオフライン移行を進めます。
ウィザードが用意されてますので必要な情報を入力しましょう。
・ソースサーバー名: SQL Serverが実行されているマシンのFQDN または ホスト名
注：統合ランタイムが実行されているマシンから接続可能であること
・認証の種類：SQL認証、Windows認証から選択
・ユーザー名
・パスワード
・接続のプロパティ
・接続の暗号化：要件に応じて選択
・サーバー証明書を信頼する： 基本オンのままで問題なさそう
入力したら次の画面へ、SQL ServerのエディションがExpressの場合は注意点があります（※1）。
移行するデータベースを選択します。
選択したら次の画面へ。
ここで移行先となるSQL Databaseの接続情報を求められます。
入力するだけです。
入力するだけですが、SQL Databaseのファイアウォールルールに統合ランタイムが動いているマシンのIPアドレスを追加しなければエラーとなります（1敗）。
パスワードの入力も間違えないようにしましょう（2敗）。
次に移行先のSQL Databaseを指定します。ドロップダウンから選ぶだけ。
移行するテーブルも選びます。
移行先側にテーブルがない場合は作成した上で移行してくれそうです。
最終の確認画面ですね。長かった。
問題なければ移行の開始を押しましょう。
開始を押すとDatabase Migration Serviceの画面に戻されて、移行タブに移行タスクが作成されている最中というのが確認できます。
この画面のソース名をクリックすると詳細画面に遷移できます。
Azure Database Migration Service - 完了を待つ
待ちます。
開始3分後くらいの詳細画面
1テーブルだけなので数分でスキーマの移行は完了したみたいですね。
全て完了となるまで待ち続けます。
………
……
…
終わってました。
前の画面に戻ると7.4分で完了しているのが確認できます。
1テーブル6カラム5000行程度だとさほど時間はかからないっぽいですね。
もっと大量のデータを動かした時の必要時間が気になりますが、機会があれば試してみようと思います。
おわり
ということで、オンプレミスのSQL ServerからAzure SQL DatabaseへのマイグレーションがAzure Portalでやりやすくなったよーという紹介でした。
個人的にはそこそこ使いやすかったので実案件でも動かせるといいなーと思います。
bacpacでの移行という手段などと一緒にDB移行時の検討に加えれると思います。
時間があればPrivate LinkやVPNを併用して閉じたネットワークの中でやれないか検証記事を書きたいですね。
それでは。
補足
※1: インストール時に無効になっている TCP/IPプロトコル を有効にする必要があります。
石川 順平／FIXER
九州のとある高専卒のFIXER5年目。
