演習 - Azure SQL Database を構成する

  • 10 分

これで、Azure portal と SQL Server Management Studio (SSMS) が表示されました。 Azure SQL 製品を管理するためのその他のツールを使用できます。 最も一般的なものの 2 つは、Azure CLI と Azure PowerShell です。 これらは機能が似ています。 どちらのツールでも、Azure Cloud Shell を使用することもできます。これは、ブラウザーで Azure portal にアクセスして使用できる対話型シェル環境です。

このアクティビティでは、Azure CLI に重点を置いています。 この演習では、Cloud Shell を使用します。 これには、Azure CLI と Azure PowerShell モジュールが既に含まれています。

Azure Cloud Shell と Azure CLI を使用した接続

次の例では、Azure SQL でさまざまな接続ポリシーを使用した場合の待機時間への影響を調べます。

Cloud Shell を使用してすべてのコマンドを実行します。 それらを簡単にコピーし、 Shift+Insert を選択してターミナルに貼り付けることができます。

注

Azure Cloud Shell を使用した PowerShell では、PowerShell Az モジュールまたは Azure CLI を使用できます。 このアクティビティでは、Azure CLI について調べますが、PowerShell Az モジュールでも同様のコマンドを使用できます。

  1. メッセージが表示されたら、shell.azure.com に移動し、Azure アカウントにサインインします。

  2. 既定のリソース グループと Azure SQL Database 論理サーバーを構成して、すべての az コマンドでそれらを指定する必要がないようにします。 次のコマンドを実行して、いくつかの変数を設定します。 <resource-group> と <your-server> を、前の演習で SQL インスタンスを作成したときに使用した値に置き換えます。

    resourceGroup="<resource-group>"
logical_server="<your-server>"
databaseName="AdventureWorks"

  3. Cloud Shell で既定値を設定して、既定のリソース グループと Azure SQL Database 論理サーバーを指定します。

    az configure --defaults group=$resourceGroup sql-server=$logical_server

  4. 既定値が設定されていることを確認するには、次のコマンドを実行します。

    az configure --list-defaults

  5. 次のコマンドを実行して、Azure SQL Database 論理サーバー内のすべてのデータベースを表示します。

    az sql db list

  6. データベースの一覧には大量の情報が表示されます。 AdventureWorks データベースの詳細を表示するだけの場合は、次のコマンドを実行します。

    az sql db show --name $databaseName

  7. 次のコマンドを実行し、データベースのサイズと使用状況を確認します。

    az sql db list-usages --name $databaseName

これらの例では、 az sql db コマンドを使用します。 Azure SQL Database 論理サーバーに関連するコマンドもあります。 これらは az sql server に分類されます。

az sql mi と az sql midb には同様のコマンドがあります。 それらは、"マネージド データベース" と呼ばれることもある、マネージド インスタンス内のデータベース用のコマンドです。

使用可能なすべてのコマンドの詳細については、 Azure CLI のドキュメントを参照してください。

Azure CLI を使用して接続ポリシーを管理する

Azure CLI または Azure PowerShell のコマンドを使用することがある場合の 1 つは、接続ポリシーを更新するときです。 この更新は、Azure CLI のようなツールを使用して Azure SQL を管理する方法の例です。 この例では、Azure SQL Database と、接続ポリシーを管理するためのコマンドについて調べます。 実装は、Azure SQL Managed Instance と似ています。

  1. Azure CLI を使用して現在のポリシーを検出します。

    az sql server conn-policy show

    結果を見ると、接続の種類が Default であることがわかります。

  2. 接続ポリシーを Proxy に設定し、ラウンドトリップ時間を決定します。

    # update policy
az sql server conn-policy update --connection-type Proxy
# confirm update
az sql server conn-policy show

  3. ラウンドトリップ時間をテストするには、SSMS を使用して接続します。 デバイスで SSMS を開き、データベースに接続します。 データベースを右クリックし、[ 新しいクエリ] を選択します。 次のテキストを使用して新しいクエリを作成し、>を選択します。 結果では、 サーバー応答の待機時間 が、ネットワーク待機時間の最適なインジケーターです。 このクエリを数回実行すると、最適な平均を得ることができます。

    -- Proxy
SELECT * FROM SalesLT.Product
GO 10

    10 回の試行後、サーバーの応答の平均待機時間は、46.6000 のようになる可能性があります。 お使いのインターネット接続により、結果は異なることがあります。 観察した時間を記録しておきます。

  4. 待機時間の短縮を試みるため、すべてを Redirect にするとどうなるでしょうか。

    Azure の外部にあるすべてのものについて、11000 から 11999 の範囲のポートで受信と送信の通信を許可する必要があります。 Redirect 接続ポリシーには、このようなポートを開く必要があります。

    注

    これは、ローカル デバイスで既に構成されている可能性があります。 次のステップでエラーが発生した場合は、前に説明したポートを有効にすることが必要になる場合があります。 詳細については、 ADO.NET 4.5 の 1433 を超えるポートを参照してください。

    次の 2 つのコマンドを使用して、接続ポリシーを更新し、更新を確認します。

    # update policy
az sql server conn-policy update --connection-type Redirect
# confirm update
az sql server conn-policy show

  5. Redirect ポリシーによるネットワーク待機時間をテストするには、ローカル デバイスで SSMS を使用して接続します。 次のテキストを使用して新しいクエリを作成し、結果の [クライアント統計を含める ] を選択します。 サーバー応答の待機時間を、Proxyのクエリと比較します。

    -- Redirect
SELECT * FROM SalesLT.Product
GO 10

    10 回試した後、サーバー応答の平均待機時間は約 25.8000 になる可能性があります。これはプロキシ接続ポリシーのおよそ半分です。 正確なタイミングは、接続によって異なります。 前のプロキシのテストと比較して、その時間は大幅に短縮されるはずです。

  6. 次のコマンドを使用して、次の演習のためにポリシーを既定値に戻します。

    # update policy
az sql server conn-policy update --connection-type Default
# confirm update
az sql server conn-policy show

最初に接続した後は、ゲートウェイをバイパスして、データベースに直接アクセスできるため、リダイレクトの方が速くなります。 このようにバイパスすると、ホップ数が少なくなるため、待機時間が短縮されます。 待機時間の短縮は、ボトルネックを防ぐことに役立ちます。これは、通信量の多いアプリケーションにとって特に重要です。 パフォーマンス モジュールでは、パフォーマンスの向上と最適化の方法についてさらに詳しく学習します。