ますます多くの組織が、オンサイトのデータベースインフラストラクチャのみからクラウドまたはハイブリッドクラウドインフラストラクチャに移行することの利点を認識しています。 Microsoft Azureのようなクラウドコンピューティングプラットフォームには、オンプレミスのセットアップに比べて次のようないくつかの利点があります。
- コスト削減： 購入および保守するオンサイトハードウェアがほとんどまたはまったくなく、低コストのストレージオプションがあるため、Azureに移行すると、直接の費用がすぐに削減されます。
- スケーラビリティの向上： クラウドでは、低速時に高価なリソースをアイドル状態のままにすることなく、必要に応じてコンピューティングのニーズを拡大または縮小できます。
- セキュリティの強化： Azureは、クラウドと物理データセンターの両方で最先端のデータセキュリティ対策を採用しています。ほとんどの組織は、そのレベルの保護に匹敵する余裕はありません。
- 管理が簡単： データのセキュリティと管理はAzureを介して一元的に処理できるため、DBAが反復的なタスクに費やす時間を削減できます。
- より信頼性の高いディザスタリカバリ： Azureデータセンターは地理的に独立しているため、壊滅的なイベントが1つのデータセンターに発生した場合、データやサービスを失うことなく、影響を受けていないデータセンターに自動的にフェイルオーバーします。
オンプレミスSQLServerからAzureSQLDatabaseに移行する準備ができている場合、移行プロセスには4つの主要なステップをナビゲートする必要があります。ここでは、それぞれの概要と詳細なリソースへのリンクを示します。
ステップ1：移行方法を選択する
SQL ServerのAzureへの移行を開始する前に、Azure DatabaseMigrationServiceを使用したオフライン移行とオンライン移行のどちらが最適なオプションであるかを判断する必要があります。このプロセスで考慮すべきことがいくつかあります。
オフライン移行では、移行が始まるとダウンタイムが始まります。オンライン移行では、ダウンタイムは移行後に新しい環境に切り替わるのに必要な時間に制限されます。したがって、最小限のダウンタイムがホットボタンの問題である場合は、オンライン移行の方が適しています。
また、Always On可用性グループオプションまたはトランザクションレプリケーションオプションを使用してデータをAzure仮想マシン（VM）に転送することにより、移行プロセス中のダウンタイムを最小限に抑えることができます。ただし、データを転送する最善の方法は、圧縮されたバックアップファイルを使用してデータベースファイルをAzureVMに移行することです。
これらの方法のいずれも使用できない場合は、次のいずれかの方法を使用して、データベースをAzureVMに手動で移行する必要があります。
- 圧縮を使用してオンプレミスバックアップを実行してから、バックアップファイルをAzureVMに手動でコピーします
- URLにバックアップしてから、URLからAzureVMに復元します
- デタッチ、データ、ログファイルをAzure BLOBストレージにコピーしてから、URLからAzureVMのSQLServerに接続します
- オンプレミスマシンをHyper-VVHDに変換し、Azure Blobストレージにアップロードしてから、新しいVMとしてデプロイします
- Windowsインポート/エクスポートサービスを使用してハードドライブを発送します
- Azureレプリカウィザードの追加
- SQLServerトランザクションレプリケーションを使用する
ステップ2：既存のデータソースを特定し、オンプレミスインスタンスを評価する
ステップ2は「移行前」と見なされ、これらのインスタンス評価アクティビティは、移行を容易にするために現在のシステムを構成するのに役立ちます。
まず、移行する必要のあるデータベースのインベントリを作成して、すべてのデータベースが移動用に最適化されていることを確認する必要があります。すべてのデータベースを特定したら、潜在的な移行の問題またはブロッカーについてデータベースを評価し、見つかった問題を解決する必要があります。
次に、組織のすべてのSQLServerインスタンスとそのバージョンおよび使用中の機能を特定する必要があります。データソースが特定されたら、Data Migration Assistant（DMA）を使用してソースデータベースを評価します。
DMAを使用してインスタンスを評価するときに従う手順は次のとおりです。
- DMAで新しい評価プロジェクトを作成する
- プロジェクトに名前を付けて、SQL Serverをソースサーバーの種類にし、AzureSQLデータベースをターゲットサーバーの種類にします
- 生成する評価レポートを選択します
- SQL Serverのソース接続の詳細を特定し、ソースデータベースに接続して、評価を開始します
- 終了したら、ブロックの問題と機能の同等性について評価レポートを確認します
- データベースの互換性レベルを選択します
- オンプレミスワークロード用のAzureSQLデータベースマネージドインスタンスSKUを選択します
評価プロセスの実行方法の詳細については、こちらをご覧ください。
ステップ3：移行時間です！
前提条件が満たされたら、Azureへの移行を開始します。最初のスキーマです。次にデータ。
Microsoftは、DMAを使用してスキーマを移行する方法について次のような概要を提供しています。
- DMAを開き、新しい移行プロジェクトの作成を開始します
- プロジェクト名を指定し、ソースサーバーの種類としてSQL Serverを選択してから、ターゲットサーバーの種類としてAzureSQLDatabaseを選択します。
- 移行スコープをスキーマのみとして指定してから、プロジェクトを作成します
- SQL Serverのソース接続の詳細を指定してから、ソースデータベースに接続します
- Azure SQLデータベースのターゲット接続の詳細を指定してから、AzureSQLデータベースで事前にプロビジョニングしたデータベースに接続します
- AzureSQLデータベースにデプロイする必要があるソースデータベースのスキーマオブジェクトを指定します
- SQLスクリプトを生成し、エラーがないか確認します
- DMA評価によって提供される推奨事項を活用して、エラーを報告するオブジェクトを修正します
- スキーマをAzureSQLDatabaseにデプロイしてから、ターゲットサーバーに異常がないか確認します
オンラインおよびオフラインのスキーマ移行の具体的な手順は次のとおりです。
Microsoftは、AzureDMSを使用してデータを移行する方法に関するこの概要を提供しています：
- Microsoft.DataMigrationリソースプロバイダーを登録する
- DMSのインスタンスを作成する
- DMSで移行プロジェクトを作成する
- 移行のソースの詳細を指定します
- 移行のターゲットの詳細を指定します
- 移行を実行する
- 移行を監視する
オンラインおよびオフラインのデータ移行の具体的な手順は次のとおりです。
ステップ4：移行後の新しい環境のテスト
SQLServerデータベースをAzureSQLDatabaseに移動したので、新しい環境を徹底的にテストして、ソースデータベースが適切に移行されたことを確認する4つの方法を次に示します。
検証テストの開発：ソースデータベースとターゲットデータベースに対して実行する検証クエリを作成します。
テスト環境のセットアップ：ソースデータベースのコピーとターゲットデータベースのコピーを分離されたテスト環境に配置します。
- 検証テストを実行します： ソースデータベースとターゲットデータベースに対して検証テストを実行してから、結果を調べます。
- パフォーマンステストを実行する： ソースデータベースとターゲットデータベースのパフォーマンスを確認し、結果を比較して分析します。
戦略的計画は、データベースをクラウドまたはハイブリッドクラウド環境に正常に移行するために重要です。移行が完了すると、クラウドベースのデータベースを使用するメリットを享受できるようになります。