Azure SQL を計画、デプロイ、検証する

Azure SQL で移行または作成するワークロードを選択したら、デプロイを計画し、それに従ってデプロイし、デプロイが成功したことを確認する必要があります。 このユニットでは、プロセスの各ステップについてさまざまな方法を学習します。

デプロイ前の計画

Azure に何かをデプロイするときは、始める前に、要件と、それらが Azure SQL のオファリングにどのように対応するかを理解することが重要です。 Azure SQL の概要モジュールで学習した内容を使用して、計画を立てます。 以下の質問に答える必要があります。

• デプロイ方法: Azure portal またはコマンド ライン インターフェイス?
• デプロイ オプション:仮想マシン、データベース、エラスティック プール、マネージド インスタンス、またはインスタンス プール?
• 購入モデル (Azure SQL Database のみ): DTU または仮想コア?
• サービス レベル: General Purpose、Business Critical、または Hyperscale?
• ハードウェア: Gen5、または何か新しいもの?
• サイズ設定:仮想コア数とデータ最大サイズ?

おそらく、上記の質問に答える前に、ワークロードを Azure SQL に移行するか、または "クラウド生まれ" にするかを選択することも必要でしょう。 移行する場合は、データベースとアプリケーションの計画、評価、移行、最適化に役立つさまざまなツールとリソースが使用できます。 リソースは、このモジュールの最後に示します。

リソースの制限

Azure SQL 導入モジュールでは、制限、料金、機能 (IOPS やインメモリ OLTP など) について説明しました。 Azure SQL Managed Instance、Azure SQL Database、または次の選択項目の中のオプションの選択によって影響を受けるリソース制限は他にもあります。

• メモリ
• 最大ログ サイズ
• トランザクション ログのレート
• データ IOPS
• tempdb のサイズ
• 最大同時 worker 数
• バックアップ保持期間

Azure SQL Managed Instance および Azure SQL Database の制限は、購入モデル、サービス レベル、仮想コアの数、または DTU (Azure SQL Database の場合のみ) の選択によって異なります。

Azure SQL Managed Instance と SQL Database は、サービスとしてのプラットフォーム (PaaS) オファリングです。 これらの選択肢を制限しても、SQL Server マネージド インスタンスの全面的な使用が妨げられることはないはずです。

General Purpose Azure SQL Database インスタンス内では、プロビジョニング済みコンピューティングまたはサーバーレス コンピューティングの選択も、これらの制限に影響します。 デプロイする前に、予定したデプロイに含まれるものを確認し、必ず必要なものから始めるようにします。

Azure SQL リソースには、"サブスクリプションごと" および "リージョンごと" にリソース全体の制限があります。 制限を増やす必要がある場合は、Azure portal でクォータの増量を要求することができます。

展開

デプロイ前の計画が完了したら、計画を実行に移します。 このステージでは、Azure portal またはコマンド ラインを使用して Azure SQL をデプロイし、ネットワーク構成を決定して、初期接続を行います。

Azure SQL Database と Azure SQL Managed Instance の場合、Azure portal には基本的に 6 つのペインがあり、デプロイの間に入力します。

サーバー

Azure SQL マネージド インスタンスを作成するときに、サーバー名を指定することは SQL Server と同じです。 データベースとエラスティック プールの場合は、Azure SQL Database サーバーが必要です。 Azure SQL Database サーバーは "論理的な" サーバーであり、単一またはプールされたデータベースの中央管理ポイントとして機能します。 これには、ログイン、ファイアウォール規則、監査規則、脅威検出ポリシー、およびフェールオーバー グループが含まれます これらの要素については、このモジュールで後ほど詳しく学習します。

この論理サーバーを使用しても、Azure SQL Managed Instance のようにインスタンスレベルのアクセスや機能が公開されることはありません。 Azure SQL Database サーバーの場合、サーバー名はすべての Azure 全体で一意である必要があります。

コンピューティングとストレージ

このラーニング パスの前のモジュールでは、サービス レベル、購入モデル、ハードウェアの世代など、コンピューティングとストレージのオプションと推奨事項について学習しました。 デプロイ中、必要な構成を選択する必要があります。 また、仮想コアの数とデータの最大サイズも決定する必要があります。

通常、移行する場合は、オンプレミスで使用しているものと同様のサイズを使用します。 Data Migration Assistant SKU レコメンダーなどのツールを使用して、現在のワークロードに基づいて、仮想コアの数とデータの最大サイズを見積もることもできます。

データの最大サイズは、現在のデータのサイズであるとは限りません。 これは、データベースに割り当てることができるデータ スペースの最大量です。 これは、データの最大サイズに応じてスケーリングされる、ログ領域の割り当てを把握するのにも役立ちます。

ネットワークの構成

Azure SQL Database と Azure SQL Managed Instance では、ネットワークの選択肢が異なります。 Azure SQL Database をデプロイする場合、現在の既定値は [アクセスなし] です。

パブリック エンドポイントまたはプライベート エンドポイントを選択できます。 このユニットの後の演習では、パブリック エンドポイントを使用し、[Azure サービスおよびリソースにこのサーバーへのアクセスを許可する] オプションを [はい] に設定します。 その後、Azure Data Factory や Azure Virtual Machines などの他の Azure サービスでは、データベースにアクセスできます。 また、Azure SQL Database のデプロイに使用したクライアント コンピューターの IP アドレスから接続できるようにする場合は、[現在のクライアント IP アドレスを追加する] を選択することもできます。

Azure SQL Managed Instance では、Azure 仮想ネットワークと、マネージド インスタンス専用のサブネットの中でデプロイします。それにより、安全なプライベート IP アドレスが与えられます。 Azure SQL Managed Instance では、オンプレミスのネットワークをマネージド インスタンスに接続し、マネージド インスタンスをリンク サーバーまたは他のオンプレミスのデータ ストアに接続し、マネージド インスタンスを他のリソースに接続できます。

また、仮想プライベート ネットワーク (VPN) を使用せずにインターネットからマネージド インスタンスに接続できるよう、パブリック エンドポイントを有効にすることもできます。 既定では、このアクセスは無効になっています。

データ ソース

Azure SQL Database では、Azure portal でのデプロイ時にサンプルとして AdventureWorksLT データベースを選択できます。 Azure SQL Managed Instance では、最初にインスタンスをデプロイした後、その中にデータベースをデプロイします。 SQL Server と同様に、デプロイ時にサンプル データベースを用意することはできません。 GitHub の AdventureWorks サンプル データベースについてさらに詳しく学習できます。

また、空のデータベースをデプロイしたり、geo レプリケートされたバックアップからの復元に基づいてデータベースを作成したりすることもできます。

データベースの照合順序

SQL Server および Azure SQL での照合順序により、特定の文字と言語の扱い方がデータベース エンジンに指示されます。 照合順序により、データの並べ替え規則、大文字と小文字の区別、アクセントの区別のプロパティが提供されます。

新しい SQL データベースまたは SQL Managed Instance を作成する場合は、データのロケール要件を考慮します。 照合順序セットは、データベース内の多くの操作の特性に影響します。 SQL Server ボックス製品では、通常、オペレーティング システムのロケールによって既定の照合順序が決まります。

Azure SQL Managed Instance では、インスタンスの作成時にサーバーの照合順序を設定します。 これは後で変更することはできません。 サーバーの照合順序では、その SQL Managed Instance 内にあるすべてのデータベースの既定値が設定されますが、データベースおよび列レベルで照合順序を変更できます。

Azure SQL Database では、サーバーの照合順序を設定することはできません。 これは SQL_Latin1_General_CP1_CI_AS の既定の最も一般的な照合順序で設定されますが、データベースの照合順序は設定することができます。 その値をチャンクに分割する場合は、次のようになります。

• SQL は、Windows またはバイナリの照合順序ではなく、SQL Server の照合順序であることを意味します。
• Latin1_General は、並べ替え時に使用するアルファベットまたは言語を指定します。
• CP1 は、照合順序で使用されるコード ページを参照します。
• CI は、大文字と小文字を区別しないことを意味します。 CS は、大文字と小文字を区別することを意味します。
• AS は、アクセントを区別することを意味します。 AI は、アクセントを区別しないことを意味します。

使用可能なオプションは他にもあります。 例として、文字幅と UTF-8 エンコードがあります。 Azure SQL でできることとできないことについては、このドキュメントに詳しく説明されています。

Microsoft Defender for Cloud にオプトインする

Azure portal で Azure SQL Database をデプロイすると、無料試用版で Microsoft Defender for Cloud を有効にするかどうかを確認するメッセージが表示されます。 無料試用版の開始を選択します。 無料試用後、Microsoft Defender for Cloud に対しては、Defender for Cloud の Standard レベルの価格に従って課金されます。

これを有効にすると、データベースの潜在的な脆弱性の特定と軽減、および脅威の検出に関連する機能を利用できるようになります。 これらの機能の詳細については、このラーニング パスの次のセキュリティに関するモジュールで学習します。

Azure SQL Managed Instance で、デプロイ後にインスタンスに対して Microsoft Defender for Cloud を有効にできます。

選択内容の確認

[確認および作成] ペインでは、デプロイの選択と Azure Marketplace の使用条件を確認します。

主要なデプロイの実装の詳細

デプロイは Azure によって自動的に処理されますが、注意する必要のあるデプロイの実装の詳細がいくつかあります。 すべてのサービスは、Azure Service Fabric と呼ばれる Azure バックボーン上に構築されています。 これらのサービスの一部が Azure Service Fabric でデプロイおよびスケーリングされる方法のバックエンドを理解すると、発生する可能性のあるさまざまな動作を理解するのに役立ちます。

Azure SQL Managed Instance

Azure によって、お使いのサービスのために Azure SQL Managed Instance の専用リング ("仮想クラスター" と呼ばれることもあります) がバックグラウンドでデプロイされます。 このアーキテクチャは、セキュリティとネイティブ仮想ネットワークのサポートを提供するのに役立ちます。

このアーキテクチャのため、デプロイとスケーリングの操作に時間がかかることがあります。 たとえば、スケールアップまたはスケールダウンすると、Azure によって新しい仮想クラスターがデプロイされて、データがシードされます。 すべてのインスタンスは、単一の仮想マシンで実行されていると考えることができます。

Azure SQL のインスタンス プールは、長いデプロイ時間に役立つように導入されました。 専用リソースの "プール" を事前にデプロイできます。 プールに対してデプロイを行い、プール内でスケーリングすると、従来のデプロイよりも高速化できます また、単一の仮想マシン内に複数のインスタンスをデプロイできるため、パッキング密度も高くなります。

Azure SQL Database

Azure SQL Database は、論理データベース サーバーに含まれています。 ほとんどの場合、SQL データベースは専用の SQL Server インスタンスによってホストされますが、インスタンスの管理について心配する必要はありません。

論理データベース サーバーにより接続先が提供されます。 また、特定のアクセス許可と構成をまとめてグループ化し、管理することもできます。 各論理データベース サーバー内には、インスタンス レベルの診断を提供できる論理プライマリ データベースがあります。

Azure SQL Database - Hyperscale

Azure SQL Database 内の Hyperscale レベル (Azure SQL Managed Instance では使用できません) には、Azure SQL 固有のアーキテクチャがあります。 Azure SQL チームは、クラウド用の Hyperscale を再設計しました。 このアーキテクチャには、速度とスケールの両方に役立つ多層キャッシュ システムが含まれています。 スケーリングや他の操作はデータのサイズに関係しなくなり、一定の時間 (数分) で完了できます。 リモート ストレージの使用も、スナップショット バックアップに対応しています。

Azure SQL の基礎に関するラーニング パスの後続のモジュールでは、アーキテクチャと、それがパフォーマンスと可用性に与える影響について、さらに詳しく学習します。 デプロイ フェーズで考慮すべき点の 1 つは、データベースを Hyperscale レベルに移動した後、General Purpose レベルまたは Business Critical レベルに "戻す" ことができないということです。

リソース管理

サービス レベル内でリソースを増減すると、CPU、ストレージ、メモリなどのディメンションの制限が特定のしきい値に変更される可能性があります。 Azure SQL でのガバナンスには多面的なアプローチがありますが、Azure SQL でリソースの使用を管理するには次の 3 つのテクノロジを主に使用します。

• Windows ジョブ オブジェクトを使用すると、プロセスのグループを 1 つの単位として管理および制御することができます。 ジョブ オブジェクトは、ファイルの仮想メモリのコミット、ワーキング セットの上限、CPU のアフィニティ、レートの上限を制御するために使用されます。 sys.dm_os_job_object 動的管理ビューを使用すると、設けられている制限を確認できます。
• Resource Governor は、ユーザーと、この場合は Azure が、CPU、物理 I/O、メモリなどのリソースを管理するのに役立つ SQL Server の機能です。 また、Azure SQL Managed Instance では、Resource Governor に対してユーザー定義のワークロード グループとプールも許可されます。
• ファイル サーバー リソース マネージャーは、Windows Server で使用できます。 データの最大サイズの管理に使用されるファイル ディレクトリ クォータを管理します。

トランザクション ログのレートを管理するためのその他の実装が、"トランザクション ログのレートのガバナンス" を通じてデータベース エンジンに組み込まれています。 このプロセスでは、BULK INSERT、SELECT INTO、インデックス構築などのワークロードに対する高インジェスト レートが制限されます。 これらは、秒未満のレベルで追跡および適用されます。 現在は、サービス レベル内で直線的にスケーリングされます。

検証

デプロイが完了したら、そのデプロイを検証します。 このステージでは、通常、Azure portal または Azure CLI で結果を確認し、デプロイの構成を確認するクエリをいくつか実行し、必要に応じて調整します。

Azure SQL Managed Instance と Azure SQL Database の場合は、最初に Azure portal または Azure CLI を使用してデータベースまたはインスタンスの状態を確認することがあります。 次に、デプロイの詳細とアクティビティ ログを確認すると、エラーやアクティブな問題がないことを確認できます。

Azure SQL Managed Instance の場合は、エラー ログを確認できます。これは、オンプレミスまたは Azure 仮想マシンの SQL Server で一般的に行われることです。 この機能は、Azure SQL Database では使用できません。

最後に、ネットワークが正しく構成されていることを確認し、サーバー名を取得して、SQL Server Management Studio や Azure Data Studio などのツールで接続します。 次のクエリを実行すると、デプロイした内容をより深く理解し、正しくデプロイされたことを確認できます。

SELECT @@VERSION
SELECT * FROM sys.databases
SELECT * FROM sys.objects
SELECT * FROM sys.dm_os_schedulers
SELECT * FROM sys.dm_os_sys_info
SELECT * FROM sys.dm_os_process_memory --Not supported in Azure SQL Database
SELECT * FROM sys.dm_exec_requests
SELECT SERVERPROPERTY('EngineEdition')
SELECT * FROM sys.dm_user_db_resource_governance -- Available only in Azure SQL Database and SQL Managed Instance
SELECT * FROM sys.dm_instance_resource_governance -- Available only in Azure SQL Managed Instance
SELECT * FROM sys.dm_os_job_object -- Available only in Azure SQL Database and SQL Managed Instance

OS プロセス メモリに関連する 1 つのクエリが、動作しているように見えるにもかかわらず、Azure SQL Database ではサポートされていません。 このクエリはサポートされていません。Azure SQL Database では、オペレーティング システムに関連する一部のものをユーザーから見えないように抽象化して、ユーザーがデータベースに集中できるようにするためです。

最後の 3 つのクエリは Azure SQL Database と Azure SQL Managed Instance でのみ使用できます。 最初の sys.dm_user_db_resource_governance では、現在のデータベースまたはエラスティック プールのリソース ガバナンス メカニズムによって使用されている構成と容量の設定が返されます。 2 つ目の sys.dm_instance_resource_governance を使用すると、Azure SQL Managed Instance について同様の情報を取得できます。 3 つ目の sys.dm_os_job_object を使用すると、SQL Server プロセスを管理するジョブ オブジェクトの構成と、リソース消費の統計を示す単一の行が返されます。

次の 2 つの演習では、Azure SQL Database または Azure SQL Managed Instance のデプロイに関連するすべての詳細について説明します。 Azure サブスクリプションを使用して、Azure SQL Database をデプロイします。 デプロイの後、Azure Data Studio でさまざまな検証クエリと事前実行 SQL ノートブックを使用して、SQL Database、SQL Managed Instance、SQL Server 2019 を比較します。