Azure SQL Managed Instance の使用を開始する

適用対象:Azure SQL Managed Instance

Azure SQL Managed Instance は、最新の SQL Server (Enterprise Edition) データベース エンジンとの 100% 近い互換性を持つデータベースを作成し、一般的なセキュリティ上の懸念事項に対処するネイティブの仮想ネットワーク (VNet) の実装と、SQL Server の既存のお客様にとって有利なビジネス モデルを提供します。

この記事では、SQL Managed Instance の構成と作成、およびデータベースの移行を迅速に行う方法を説明したコンテンツへのリファレンスを紹介します。

クイック スタートの概要

次のクイック スタートを使用すると、SQL Managed Instance をすばやく作成し、クライアント アプリケーション用に仮想マシンやポイント対サイト VPN 接続を構成し、.bak ファイルを使用して新しい SQL Managed Instance にデータベースを復元することができます。

環境を構成する

最初の手順として、最初の SQL Managed Instance をその配置先のネットワーク環境で作成し、クエリを実行するコンピューターまたは仮想マシンから SQL Managed Instance への接続を有効にする必要があります。 次のガイドを使用できます。

• Azure portal を使用して SQL Managed Instance を作成します。 Azure portal で、必要なパラメーター (ユーザー名/パスワード、コア数、最大ストレージ容量) を構成します。また、Azure ネットワーク環境を自動的に作成できます。ネットワークの詳細やインフラストラクチャの要件を把握している必要はありません。 現在 SQL Managed Instance の作成が許可されているサブスクリプションの種類を使用していることを確認します。 使用したい独自のネットワークがある場合、またはネットワークをカスタマイズする場合は、「Azure SQL Managed Instance の既存の仮想ネットワークを構成する」または「Azure SQL Managed Instance の仮想ネットワークを作成する」を参照してください。

• SQL Managed Instance は、パブリック エンドポイントを持たない独自の VNet に作成されます。 クライアント アプリケーションのアクセスのために、以下のクイック スタートのいずれかを使用して、同じ VNet (異なるサブネット) 内に VM を作成するか、クライアント コンピューターから VNet へのポイント対サイト VPN 接続を作成することができます。

  • お使いの環境からデータに直接アクセスするために、SQL Managed Instance でパブリック エンドポイントを有効にします。
  • SQL Server Management Studio などのクライアント アプリケーション接続のために、SQL Managed Instance VNet に Azure 仮想マシンを作成します。
  • SQL Server Management Studio とその他のクライアント接続アプリケーションがあるクライアント コンピューターから、SQL Managed Instance へのポイント対サイト VPN 接続を設定します。 これは、SQL Managed Instance とその VNet への接続に関する 2 つのオプションのうちの 1 つです。

  注意

  • ローカル ネットワークから Express Route またはサイト間接続を使用することもできますが、このような方法はこれらのクイック スタートでは扱いません。
  • リテンション期間を 0 (無制限のリテンション期間) から他の値に変更した場合、リテンション期間は、リテンション期間の値が変更された後に書き込まれたログにのみ適用されることに注意してください (リテンション期間が無制限に設定されている間に書き込まれたログは、リテンション期間が有効になった後も保持されます)。

SQL Managed Instance を手動で作成する代わりに、PowerShell、PowerShell と Resource Manager テンプレート、または Azure CLI を使用して、このプロセスをスクリプト化して自動化することもできます。

データベースを移行する

SQL Managed Instance を作成してアクセスを構成したら、SQL Server データベースの移行を開始できます。 移行するソース データベースに、サポートされていない機能がある場合、移行が失敗することがあります。 失敗を回避して互換性をチェックするために、Data Migration Assistant (DMA) を使用して SQL Server 上のデータベースを分析し、FileStream や複数のログ ファイルの存在など、SQL Managed Instance への移行を妨げる可能性のある問題を見つけることができます。 これらの問題を解決すると、データベースを SQL Managed Instance に移行する準備が整います。 Database Experimentation Assistant は、SQL Server 上のワークロードを記録し、SQL Managed Instance で再生できるもう 1 つの便利なツールです。これにより、SQL Managed Instance に移行した場合にパフォーマンス上の問題が発生するかどうかを判断できます。

データベースを SQL Managed Instance に移行できることを確認したら、ネイティブ SQL Server の復元機能を使用して、データベースを .bak ファイルから SQL Managed Instance に復元できます。 この方法を使用して、オンプレミスまたは Azure Virtual Machines にインストールされている SQL Server データベース エンジンからデータベースを移行することができます。 クイック スタートについては、バックアップから SQL Managed Instance への復元に関するページを参照してください。 このクイック スタートでは、RESTORE Transact-SQL コマンドを使用して、Azure Blob Storage に格納されている .bak ファイルから復元します。

これらのクイック スタートを使用すると、データベース バックアップを迅速に作成、構成し、SQL Managed Instance に復元することができます。 一部のシナリオでは、SQL Managed Instance と必要なネットワーク環境のデプロイをカスタマイズまたは自動化する必要があります。 ここでは、これらのシナリオについて説明します。

ネットワーク環境をカスタマイズする

VNet/サブネットは、インスタンスが Azure portal を使用して作成されるときに自動的に構成できますが、VNet とサブネットのパラメーターを構成できるため、SQL Managed Instance でインスタンスの作成を開始する前に作成しておくことをお勧めします。 ネットワーク環境を作成して構成する最も簡単な方法は、インスタンスが配置されるネットワークとサブネットを作成して構成する Azure リソースの展開テンプレートを使用することです。 必要な操作は、Azure Resource Manager のデプロイ ボタンを押し、フォームにパラメーターを入力することのみです。

別の方法として、この PowerShell スクリプトを使用してネットワークの作成を自動化することもできます。

SQL Managed Instance をデプロイする VNet とサブネットが既にある場合は、VNet とサブネットがネットワーク要件を満たしていることを確認する必要があります。 この PowerShell スクリプトを使用して、サブネットが正しく構成されていることを確認します。 このスクリプトはネットワークを検証し、問題を報告し、VNet/サブネットでどのような変更を行うべきかを伝え、必要な変更を行うことを提示します。 VNet/サブネットを手動で構成しない場合は、このスクリプトを実行します。 ネットワーク インフラストラクチャの大規模な再構成後にも、これを実行できます。 独自のネットワークを作成して構成する場合は、接続アーキテクチャに関するページと、こちらの SQL Managed Instance 環境の作成と構成に関する完全ガイドをお読みください。

SQL Managed Instance に移行する

前述のクイックスタートを使用すると、SQL Managed Instance を迅速にセットアップし、ネイティブ RESTORE 機能を使用してデータベースを移動することができます。 これは、簡単な概念実証を完了し、ソリューションが Managed Instance で動作することを確認する場合の手始めとして適しています。

ただし、運用データベース移行する場合、または何らかのパフォーマンス テストに使用する開発/テスト データベースを移行する場合であっても、次のような追加の手法を使用することを検討する必要があります。

• パフォーマンス テスト - ソース SQL Server インスタンスのベースライン パフォーマンス メトリックを測定し、データベースの移行先である SQL Managed Instance のパフォーマンス メトリックと比較する必要があります。 詳しくは、best practices for performance comparison (パフォーマンス比較のベスト プラクティス) に関する記事をご覧ください。
• オンライン移行 - この記事で説明されているネイティブの RESTORE の場合、データベースが復元される (そして、まだ Azure Blob Storage に格納されていない場合は Azure Blob Storage にコピーされる) まで待つ必要があります。 このため、特に大規模なデータベースでは、アプリケーションに多少のダウンタイムが発生します。 運用データベースを移動するには、データ移行サービス (DMS) を使用して、最小限のダウンタイムでデータベースを移行します。 DMS は、ソース データベースで行われた変更を、復元する SQL Managed Instance データベースに増分方式でプッシュすることによってこれを実現します。 この方法であれば、最小限のダウンタイムでアプリケーションをソースからターゲットのデータベースにすばやく切り替えることができます。

推奨される移行プロセスの詳細を確認してください。

次のステップ

• SQL Managed Instance でサポートされている機能の概要の一覧についてはこちら、詳細情報と既知の問題についてはこちらを確認します。
• SQL Managed Instance の技術的特性について確認します。
• より高度な操作方法については、SQL Managed Instance の使用方法に関するページを参照してください。
• オンプレミス データベースの適切な Azure SQL Managed Instance SKU を特定します。