演習 - Azure SQL Database を構成する

完了

これまで、Azure portal、SQL Server Management Studio (SSMS)、および Azure Data Studio での SQL ノートブックを見てきました。 Azure SQL の管理に使用できるツールは他にもあります。 最も一般的なものの 2 つは、Azure CLI と Azure PowerShell です。 これらは機能が似ています。 このアクティビティでは、Azure CLI に重点を置いています。

このアクティビティを完了するには、PowerShell ノートブックを使用できます。これは SQL ノートブックと同じ概念ですが、コーディング言語は PowerShell です。 PowerShell ノートブックを使用すると Azure CLI または Azure PowerShell を利用できます。 この記事では、Azure CLI コマンドに重点を置いて説明します。 どちらのツールでも、Azure Cloud Shell を使用することもできます。これは、ブラウザーで Azure portal にアクセスして使用できる対話型シェル環境です。

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

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

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

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

Note

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 miaz 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 接続ポリシーには、このようなポートを開く必要があります。

    Note

    これは、ローカル デバイスで既に構成されている可能性があります。 次のステップでエラーが発生した場合は、前に説明したポートを有効にすることが必要になる場合があります。 詳細については、「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
    

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