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 マネージド インスタンスの全面的な使用が妨げられることはないはずです。

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

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

展開

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

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

サーバー

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

この論理サーバーを使用しても、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 は論理サーバーに含まれており、接続先の情報を提供します。 また、特定のアクセス許可と構成をまとめてグループ化し、管理することもできます。 各論理サーバー内には、インスタンス レベルの診断を提供できる論理プライマリ データベースがあります。

Hyperscale サービス レベル

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

デプロイ フェーズで考慮すべき点の 1 つは、データベースを Hyperscale レベルに移動した後、General Purpose レベルまたは Business Critical レベルに "戻す" ことができないということです。

リソース管理

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

• Windows ジョブ オブジェクト を使用すると、プロセスのグループを 1 つの単位として管理および管理できます。 ジョブ オブジェクトは、ファイルの仮想メモリのコミット、ワーキング セットの上限、CPU のアフィニティ、レートの上限を制御するために使用されます。 sys.dm_os_job_object 動的管理ビューを使用すると、設けられている制限を確認できます。
• Resource Governor は、ユーザーを支援する SQL Server 機能です。この場合、Azure は CPU、物理 I/O、メモリなどのリソースを管理します。 また、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 の場合、エラー ログを確認できます。これは、オンプレミスの SQL Server または Azure 仮想マシンで行う一般的な操作です。 この機能は、Azure SQL Database では使用できません。

最後に、ネットワークが正しく構成されていることを確認し、サーバー名を取得し、SQL Server Management 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 をデプロイします。 デプロイ後、さまざまな検証クエリを使用して、SQL Database、SQL Managed Instance、および SQL Server 2019 を比較します。