Azure Monitor を使用して Azure Cosmos DB for NoSQL アカウントを分析する

Azure Monitor は、Azure のフル スタックの監視サービスです。Azure リソースを監視するためのあらゆる機能を備えています。 Azure Cosmos DB では、Azure Monitor を使用して監視データが作成されます。 Cosmos DB のメトリックやテレメトリ データは、Azure Monitor によって収集されます。

このラボでは、Azure Cosmos DB コンテナーに対してシミュレートされたワークロードを実行し、そのワークロードが Azure Cosmos DB アカウントにどのように影響するかを分析します。

開発環境を準備する

このラボで作業する環境に DP-420 のラボ コード リポジトリをまだクローンしていない場合は、次の手順に従ってそれを行います。 それ以外の場合は、以前にクローンしたフォルダーを Visual Studio Code で開きます。

  1. Visual Studio Code を起動します。

    📝 Visual Studio Code インターフェイスについてまだよく理解していない場合は、Visual Studio Code の入門ガイドを参照してください

  2. コマンド パレットを開き、Git: Clone を実行して、任意のローカル フォルダーに https://github.com/microsoftlearning/dp-420-cosmos-db-dev GitHub リポジトリをクローンします。

    💡 Ctrl + Shift + P キーボード ショートカットを使用してコマンド パレットを開くことができます。

  3. リポジトリが複製されたら、Visual Studio Code で選択したローカル フォルダーを開きます。

Azure Cosmos DB for NoSQL アカウントを作成する

Azure Cosmos DB は、複数の API をサポートするクラウドベースの NoSQL データベース サービスです。 Azure Cosmos DB アカウントを初めてプロビジョニングするときに、アカウントでサポートする API を選択します (たとえば、Mongo API や NoSQL API)。 Azure Cosmos DB for NoSQL アカウントのプロビジョニングが完了したら、エンドポイントとキーを取得できます。 エンドポイントとキーを使用して、Azure Cosmos DB for NoSQL アカウントにプログラムで接続します。 Azure SDK for .NET またはその他の SDK の接続文字列でエンドポイントとキーを使用します。

  1. 新しい Web ブラウザー ウィンドウまたはタブで、Azure portal (portal.azure.com) に移動します。

  2. ご利用のサブスクリプションに関連付けられている Microsoft 資格情報を使用して、ポータルにサインインします。

  3. [+ リソースの作成] を選択し、Cosmos DB を検索して、新しい Azure Cosmos DB for NoSQL アカウント リソースを作成します。以下を設定して、残りの設定はすべて既定値のままにします。

    設定 Value
    サブスクリプション ’‘既存の Azure サブスクリプション’’
    リソース グループ ’‘既存のリソース グループを選択するか、新しいものを作成します’’
    アカウント名 ’‘グローバルに一意の名前を入力します’’
    場所 ’‘使用可能なリージョンを選びます’’
    容量モード プロビジョニング済みスループット
    Apply Free Tier Discount (Free レベル割引の適用) 適用しない
    このアカウントでプロビジョニングできるスループットの総量を制限する オフ

    📝 ご利用のラボ環境には、新しいリソース グループを作成できない制限が存在する場合があります。 その場合は、事前に作成されている既存のリソース グループを使用します。

  4. デプロイ タスクが完了するまで待ってから、このタスクを続行してください。

  5. 新しく作成された Azure Cosmos DB アカウント リソースに移動し、 [キー] ペインに移動します。

  6. このペインには、SDK からアカウントに接続するために必要な接続の詳細と資格情報が含まれています。 具体的な内容は次のとおりです。

    1.[URI] フィールドに注目してください。 このエンドポイントの値は、この演習で後ほど使用します。

    1.[主キー] フィールドに注目してください。 このキーの値は、この演習で後ほど使用します。

  7. 最小化しますが、ブラウザー ウィンドウは閉じません。 次の手順でバックグラウンド ワークロードを開始してから数分後に、Azure portal に戻ります。

Microsoft.Azure.Cosmos および Newtonsoft.Json ライブラリを .NET スクリプトにインポートする

.NET CLI には、事前構成済みのパッケージ フィードからパッケージをインポートするための add package コマンドが含まれています。 .NET インストールでは、既定のパッケージ フィードとして NuGet が使用されます。

  1. Visual Studio Code の [エクスプローラー] ペインで、25-monitor フォルダーを参照します。

  2. 25-monitor フォルダーのコンテキスト メニューを開き、[統合ターミナルで開く] を選択して新しいターミナル インスタンスを開きます。

    📝 このコマンドを実行すると、ターミナルが開き、開始ディレクトリが既に 25-monitor フォルダーに設定されています。

  3. 次のコマンドを使用して、NuGet から Microsoft.Azure.Cosmos パッケージを追加します。

     dotnet add package Microsoft.Azure.Cosmos --version 3.22.1

  4. 次のコマンドを使用して、NuGet から Newtonsoft.Json パッケージを追加します。

     dotnet add package Newtonsoft.Json --version 13.0.1

スクリプトを実行してコンテナーとワークロードを作成する

これで、ワークロードを実行して、Azure Cosmos DB アカウントの使用状況を監視する準備ができました。 実行するスクリプトは、バックグラウンドで動作します。 このスクリプトで 3 つのコンテナーを作成し、それらのコンテナーにデータを読み込みます。 その後、スクリプトはいくつかの SQL クエリをランダムに実行し、Azure Cosmos DB アカウントにアクセスする複数のユーザー アプリケーションをエミュレートします。

  1. Visual Studio Code の [エクスプローラー] ペインで、25-monitor フォルダーを参照します。

  2. Program.cs コード ファイルを開きます。

  3. endpoint という名前の既存の変数を、先ほど作成した Azure Cosmos DB アカウントの endpoint に設定された値で更新します。

     private static readonly string endpoint = "<cosmos-endpoint>";

    📝 たとえば、エンドポイントが https­://dp420.documents.azure.com:443/ の場合、C# ステートメントは private static readonly string endpoint = “https­://dp420.documents.azure.com:443/”; になります。

  4. key という名前の既存の変数を、先ほど作成した Azure Cosmos DB アカウントの key に設定された値で更新します。

     private static readonly string key = "<cosmos-key>";

    📝 たとえば、キーが fDR2ci9QgkdkvERTQ== の場合、C# ステートメントは private static readonly string key = “fDR2ci9QgkdkvERTQ==”; になります。

  5. Program.cs ファイルを保存します。

  6. 統合ターミナルに戻ります。

  7. dotnet run コマンドを使用して、プロジェクトをビルドして実行します。

     dotnet run

    📝 このスクリプトの最初の部分では、3 つのコンテナーを作成し、データを読み込みます。これには約 2 分かかります。 次に、いくつかのレート制限イベントをエミュレートするために、プロビジョニングされたスループットをスクリプトで 400 RU/秒に設定します。 すると、”Creating simulated background workload, wait 5-10 minutes and go to the next step of the exercise” (シミュレートされたバックグラウンドのワークロードを作成しています。5 - 10 分待ってから、次の手順に進んでください) というメッセージが表示されます。 Azure リソースから Azure Monitor には監視データが非同期的にアップロードされるため、Azure Monitor のメトリックと分析情報で診断データが得られるようになるまで、少しの間待つ必要があります。 5 から 10 分後、次の手順に進みます。 必要に応じて追加の診断データを収集する場合、5 から 10 分後にスクリプトを停止する必要はありません。それはラボの最後に行いますので、それまで待ってください。

    📝 いくつかの警告が黄色で表示されていることがわかります。これは、スクリプトが多数の操作を同期的に実行し、操作の応答を待機しないことがコンパイラで検出されたことによります。 これらの警告は無視してかまいません。複数の SQL スクリプトを同時に実行することは、想定された動作であるためです。

Azure Monitor を使用して Azure Cosmos DB アカウントの使用状況を分析する

演習のこの部分では、ブラウザーに戻り、Azure Monitor の分析情報とメトリックを表すレポートの一部を確認します。

Azure Monitor メトリックのレポート

  1. 前に最小化した開いているブラウザー ウィンドウに戻ります。 それを閉じた場合は、新しいものを開き、portal.azure.com の Azure Cosmos DB アカウント ページに移動します。

  2. Azure Comsos DB の左側のメニューで、[モニター] の [メトリック] を選択します。 [スコープ] および [メトリック名前空間] フィールドに、正しい情報があらかじめ入力されていることがわかります。 以降の手順では、[メトリック] のいくつかのオプションと、フィルターの追加 と 分割の適用 の機能を見ていきます。

  3. 既定では、[メトリック] セクションに過去 24 時間の診断情報が表示されます。 前の手順で作成したワークロードの間のメトリックを確認するには、さらに細かくする必要があります。 右上隅にある [ローカル時刻: 過去 24 時間 (自動)] というラベルの付いたボタンを選択すると、複数のラジオ ボタンの時間範囲オプションを含むウィンドウが表示されます。 [過去 30 分] というラベルの付いたラジオ ボタンを選択し、[適用] ボタンを選択します。 必要に応じて、[カスタム] ラジオ ボタンを選択し、開始および終了日時を選択することで、さらに細かく設定できます。

  4. 診断グラフの適切な時間範囲を設定したので、いくつかのメトリックを見てみましょう。 まず、一般的なメトリックから始めます。 [メトリック] プルダウンから [要求ユニットの合計] を選択します。 既定では、このメトリックは RU の合計として表示されます。 または、[集計] プルダウンを avg または max に変更できます。これらの 2 つの集計を確認したら、以降の手順のために [合計] に戻します。

  5. このメトリックにより、Azure Cosmos DB アカウントで使用された要求ユニットの数を把握できます。 ただし、アカウントに複数のデータベースまたはコンテナーがあるとき、現在のグラフでは問題に的を絞りにくい可能性があります。 これを変更し、データベースによる RU の消費量がどのようであったかを確認しましょう。 グラフのタイトルの下のメニューで [分割の適用] を選択し、[値] プルダウンで [DatabaseName] を選び、グラフ上の任意の場所を選択すると変更が反映されます。 [分割基準 = DatabaseName] ボタンがグラフのすぐ上に配置されます。

  6. かなり良くなりました。これで、どのデータベースで作業の大部分が実行されているのか、わかるようになりました。 この情報はこれで良いのですが、すべての作業がどのコンテナーで行われているのかは不明です。 分割基準を変更するために [分割基準 = DatabaseName] ボタンを選択し、[値] プルダウンから [CollectionName] を選びます。 これで、customer および salesOrder コレクションのデータが表示されます。 このグラフには、1 つだけ問題があります。salesOrder コレクションは database-v2 と database-v3 という 2 つのデータベースに存在するため、この値は両方のデータベースにあるそのコレクション名の集計になっています。

  7. これを修正するのは簡単です。[フィルターの追加] ボタンを選択し、[プロパティ] プルダウンで [DatabaseName] を選び、[値] で [database-V3] を選びます。

  8. さらに 2 つのメトリックを見てみましょう。 既存のグラフを編集します。必要に応じて新しいグラフを作成することもできます。 グラフの上で、[Azure Cosmos DB アカウント名] と [要求ユニットの合計] ラベルを含むボタンを選択します。 [メトリック] プルダウンから [要求の合計] を選択します。使用可能な集計が カウント だけであることに注意してください。

  9. ここに示す 2 つの主要なフィルターは、さまざまな種類の問題のトラブルシューティングに役立ちます。 プロパティ StatusCode を使用したフィルターを追加しましょう (詳細の種類が異なる類似したフィルターとして Status があることに注意してください)。[値] として 200 と 429 を選びます。 StatusCode を使用するように分割を変更します。 状態 200 の成功した要求と比較して、膨大な量の 429 またはレート制限要求がある点に注意してください。 429 の例外は、プロビジョニングされたスループットを 400 RU/秒に設定しているのに、スクリプトが 1 秒あたり数千の要求を送信しているために発生しました。 成功した要求と比較したこの 429 例外の数の多さは、運用環境では通常のことではありません。運用環境では、正常な Azure Cosmos DB アカウントで 429 の例外が発生することはまれです。 また、要求ユニットの合計に対する同様のトラブルシューティング方法で StautusCode または Status という プロパティ を使用することもできます

  10. 引き続き要求ユニットの合計を見ていきましょう。ただし、分割を OperationType に変更します。 このプロパティは、どの読み取りまたは書き込み操作によって作業の大部分が実行されているかを判断するのに役立ちます。 繰り返しになりますが、このプロパティは要求ユニットの合計に対しても同様に使用できます

  11. 要求ユニットの合計で行ったのと同様に、さまざまなフィルターの選択と分割オプションを試します。

  12. この演習で確認する最後のメトリックは、正規化された RU 消費量メトリックです。 分割を PartitionKeyRangeId に変更します。 このメトリックは、どのパーティション キー範囲の使用量が多いかを識別するのに役立ちます。 このメトリックは、パーティション キーの範囲に対するスループットの偏りを示します。 先に進み、[メトリック] プルダウンからそのメトリックを 選択します。 このグラフに表示されるシステムはかなり異常で、正規化された RU 消費量が一定して 100% に達しています。

📝 一度に複数のグラフを表示する場合は、グラフ名の上にある [+ 新しいグラフ] オプションをクリックします。

📝 メトリックを直接保存することはできませんが、ダッシュボードを作成するか既存のものを使用し、それにこのグラフを追加できます。そのためには、グラフの右上隅にある [ダッシュボードにピン留めする] ボタンをクリックします。 このボタンをクリックし、[新規作成] タブを選択して、DP-420 labs という名前を付け、[作成してピン留めする] をクリックします。 プライベート ダッシュボードを表示するには、左上隅にあるポータル メニューに移動し、Azure リソース オプションから [ダッシュボード] を選択する必要があります。 ダッシュボードが初めて表示されるのに数分かかる場合があります。

📝 グラフを共有するもう 1 つの方法は、[共有] プルダウンをクリックし、Excel ファイルまたは [リンクのコピー] オプションとしてダウンロードすることです。

Azure Monitor 分析情報のレポート

Azure Monitor メトリック診断レポートの微調整にもう少し時間をかける必要があります。 Cosmos DB の分析情報を使用すると、Azure Cosmos DB リソースの全体的なパフォーマンス、障害、操作の正常性を表示できます。 これらの分析情報グラフは、メトリックのものと同様に、事前構築されたグラフです。 その一部を見てみましょう。

  1. Azure Comsos DB の左側のメニューの [モニター] で、[分析情報] を選択します。 [概要] から [管理オプション] まで、複数のタブがあることがわかります。 これらの分析情報グラフのいくつかを見ていきます。 最初のタブである [概要] タブには、使用できる最も一般的なグラフの概要が表示されます。 たとえば、要求の合計、データとインデックスの使用量、429 の例外、正規化された RU 消費量のようなグラフです。 これらのグラフの大部分は、前のセクションで確認しました。

  2. グラフの上部にある [時間の範囲] で的を絞ることができます。この演習のワークロードを評価するために、15 または 30 分を選択します。

  3. “各” グラフの右上隅に、[メトリック エクスプローラーを開く] オプションが表示されます。** 次に、[要求の合計] グラフの [メトリック エクスプローラーを開く] オプションを選択しましょう。 このオプションを選択すると、前に確認したメトリックのレポートが表示されます。 メトリック エクスプローラーを開く利点は、グラフのかなりの部分が既に構築済みであることです。

  4. メトリック グラフの右上にある [X] を選択して、分析情報ページに戻りましょう。

  5. [スループット] タブを選択します。これらのグラフは、スループットの問題を特定する場合に便利です。 ホット パーティションの検出に使用できる PartitionKeyRangeID ごとの正規化された RU 消費量のグラフを詳しく見てみましょう。

  6. [要求] タブを選択します。これらのグラフは、アカウントに発生した制限イベントの数 (429 と 200) を分析したり、操作の種類ごとに要求の数を確認したりするために最適です。

  7. [ストレージ] タブを選択します。これらのグラフは、コレクションの増加と、データとインデックスの使用量の両方を示しています。

  8. [システム] タブを選択します。アプリケーションでアカウント メタデータの作成、削除、またはクエリを頻繁に実行していた場合は、429 の例外が発生している可能性があります。 これらのグラフは、その頻繁なメタデータ アクセスが 429 例外の原因かどうかを判断するのに役立ちます。 さらに、メタデータ要求の状態を確認できます。

Azure Monitor 分析情報のレポート

  1. プログラムがまだ実行されている場合は、Visual Studio Code コマンド ターミナルに戻ります。

  2. 統合ターミナルを閉じます。

  3. Visual Studio Code を閉じます。