Azure AI Search でクエリ要求を監視する

[アーティクル]
02/24/2024

この記事では、組み込みのメトリックとリソースログを使用してクエリのパフォーマンスと量を測定する方法について説明します。また、アプリケーションユーザーが入力したクエリ文字列を取得する方法についても説明します。

Azure portal には、クエリの待ち時間、クエリ負荷 (QPS)、スロットリングに関する基本的なメトリックが表示されます。これらのメトリックにフィードされる履歴データには、ポータルで 30 日間アクセスできます。データ保持期間を延長したり、オペレーショナルデータとクエリ文字列についてレポートしたりする場合は、ログされた操作とメトリックの保持に関するストレージオプションを指定する診断設定を追加する必要があります。ログされる操作の格納先としては Log Analytics ワークスペースをお勧めします。 Kusto クエリとデータ探索のターゲットは Log Analytics ワークスペースです。

データ測定の整合性を最大化する条件には、次のようなものがあります。

課金対象のサービス (Basic または Standard レベルで作成されたサービス) を使用します。無料のサービスは、複数のサブスクライバーによって共有されます。そのため、負荷の変化に応じて一定量の変動性が生じます。
可能であれば、単一のレプリカとパーティションを使用して、独立した分離された環境を作成します。複数のレプリカを使用する場合、クエリメトリックは複数のノード間で平均化されるため、結果の精度が低下する可能性があります。同様に、複数のパーティションはデータが分割されることを意味し、インデックス作成も進行中の場合、一部のパーティションには異なるデータが含まれている可能性があります。クエリのパフォーマンスを調整する場合、ノードとパーティションを単一にすると、テスト用の環境の安定性が高まります。

ヒント

追加のクライアント側コードと Application Insights を使用すると、何がアプリケーションユーザーの関心を引くかについてより深い分析情報を得るために、クリックスルーデータをキャプチャすることもできます。詳しくは、「検索トラフィックの分析」をご覧ください。

クエリ量 (QPS)

量は、1 秒あたりの検索クエリ数 (QPS) として測定されます。これは組み込みメトリックであり、1 分という時間枠内で実行されるクエリの平均値、カウント値、最小値、または最大値としてリポートできます。メトリックの 1 分間隔 (TimeGrain = "PT1M") は、システム内で固定されています。

クエリはミリ秒単位で実行されるのが一般的であるため、秒として測定されるクエリのみがメトリックに表示されます。

集計の種類	説明
Average	クエリの実行が行われた、1 分以内の平均秒数。
Count	1 分の間隔内でログに生成されたメトリックの数。
最大値	1 分間に登録された、1 秒あたりの検索クエリの最大数。
最小	1 分間に登録された、1 秒あたりの検索クエリの最小数。
SUM	1 分以内に実行されたすべてのクエリの合計。

たとえば、1 分間のうち、1 秒は非常に負荷が高く、続く 58 秒は平均的な負荷で、最後の 1 秒はクエリが 1 つだけというパターンがあるとします。この場合、最初の 1 秒の値が SearchQueriesPerSecond の最大値、最後の１秒の値が最小値となります。

別の例として、ノードが 100 メトリックを生成し、各メトリックの値が 40 である場合、"カウント" は 100、"合計" は 4,000、"平均" は 40、"最大" は 40 になります。

クエリパフォーマンス

サービス全体のクエリパフォーマンスは、検索の待ち時間 (クエリが完了するまでに要する時間) と、リソースの競合の結果として削除された、スロットルされたクエリ数として測定されます。

検索の待ち時間

集計の種類	Latency
Average	平均クエリ期間 (ミリ秒単位)。
Count	1 分の間隔内でログに生成されたメトリックの数。
最大値	サンプル内で実行時間が最長のクエリ。
最小	サンプル内で実行時間が最短のクエリ。
Total	間隔 (1 分) 内に実行される、サンプル内のすべてのクエリの合計実行時間。

次の検索の待機時間メトリックの例を考えてみます。86 件のクエリがサンプリングされ、平均時間は 23.26 ミリ秒であるとします。最小値 0 は、一部のクエリが削除されたことを示します。実行時間の最も長いクエリは、完了までに 1,000 ミリ秒かかりました。合計実行時間は 2 秒でした。

スロットルされたクエリ

スロットルされたクエリとは、処理されずに削除されたクエリのことです。ほとんどの場合、スロットリングは通常のサービス実行の一部です。必ずしも、何か問題があることを示しているわけではありません。

スロットリングは、実行中の要求の数が容量を超えると発生します。レプリカがローテーションから外されたときまたはインデックス作成時に、スロットルされた要求が増加する場合があります。クエリ要求もインデックス作成要求も、同じリソースのセットによって処理されます。

サービスは、リソース消費量に基づいて、要求を削除するかどうかを決定します。メモリ、CPU、ディスク IO 全体で消費されるリソースの割合は、一定期間で平均化されます。この割合がしきい値を超えると、インデックスに対するすべての要求は、要求の量が減少するまでスロットルされます。

クライアントに応じて、スロットルされた要求は次の方法で示されます。

サービスはエラー "You are sending too many requests. Please try again later." を返します
サービスから、現在サービスが利用できないことを示す 503 エラーコードが返されます。
ポータル (検索エクスプローラーなど) を使っている場合、クエリは通知なしで削除されるため、もう一度 [検索] を選ぶ必要があります。

スロットルされたクエリを確認するには、スロットルされた検索クエリ メトリックを使用します。この記事で説明されているように、メトリックをポータルで調べるか、アラートメトリックを作成することができます。サンプリング間隔内で削除されたクエリについては、"合計" を使って、実行されなかったクエリの割合を取得します。

集計の種類	調整
Average	間隔内で削除されたクエリの割合。
Count	1 分の間隔内でログに生成されたメトリックの数。
最大値	間隔内で削除されたクエリの割合。
最小	間隔内で削除されたクエリの割合。
Total	間隔内で削除されたクエリの割合。

Throttled Search Queries Percentage の場合は、最小値、最大値、平均値、および合計値はすべて同じ値になります。これは、スロットルされた検索クエリの割合であり、1 分間の検索クエリの合計数に基づきます。

次のスクリーンショットでは、最初の数はカウント (つまり、ログに送信されるメトリックの数) です。上部に、またはメトリックにカーソルを合わせたときに表示されるその他の集計には、平均、最大、合計などがあります。このサンプルでは、要求は削除されませんでした。

ポータルでメトリックについて調べる

現在の数値を簡単に確認できるように、サービスの [概要] ページの [監視] タブには、3 つのメトリック (検索の待ち時間、秒あたりの検索クエリ数 (検索ユニットごと)、スロットルされた検索クエリの割合) が表示されます。これらは、一定の間隔で時間、日、および週単位で測定されるほか、集計の種類を変更するオプションが用意されています。

さらに詳しく調べるには、[監視] メニューからメトリックスエクスプローラーを開き、データを階層化、拡大、および視覚化して、傾向や異常を確認します。メトリックスエクスプローラーの詳細を確認するには、このメトリックのグラフの作成に関するチュートリアルを完了してください。

[監視] セクションの下で、[メトリックス] を選択し、スコープがお使いの検索サービスに設定されているメトリックスエクスプローラーを開きます。
[メトリック] でドロップダウンリストからいずれかを選択し、選択した種類で使用可能な集計の一覧を確認します。集計では、収集された値を期間ごとにサンプリングする方法を定義します。
右上隅で、期間を設定します。
視覚化方法を選択します。既定では折れ線グラフになっています。
階層化する集計を増やすには、[メトリックの追加] を選んで、異なる集計を選びます。
折れ線グラフ上で、関心領域を拡大します。領域の先頭にマウスポインターを置き、マウスの左ボタンを押したまま領域のもう一方の側にドラッグしてボタンを離します。その時間範囲のグラフが拡大されます。

ユーザーによって入力されたクエリ文字列を返す

リソースログを有効にすると、システムによってクエリ要求が AzureDiagnostics テーブルにキャプチャされます。前提条件として、ログされる操作の格納先として、Log Analytics ワークスペースまたは別のストレージオプションを既に指定してある必要があります。

[監視] セクションで [ログ] を選択し、Log Analytics で空のクエリウィンドウを開きます。
次の式を実行して Query.Search 操作を検索し、操作名、クエリ文字列、クエリ対象のインデックス、検出されたドキュメントの数で構成される表形式の結果セットを返します。最後の 2 つのステートメントは、サンプルインデックス全体から、空または未指定の検索から成るクエリ文字列を除外し、結果に含まれるノイズを削減します。
```
   AzureDiagnostics
| project OperationName, Query_s, IndexName_s, Documents_d
| where OperationName == "Query.Search"
| where Query_s != "?api-version=2023-07-01-preview&search=*"
| where IndexName_s != "realestate-us-sample-index"
```
必要に応じて、Query_s に列フィルターを設定して、特定の構文または文字列を検索します。たとえば、?api-version=2023-11-01&search=*&%24filter=HotelName "に等しい" というフィルターを設定できます。

この手法はその場限りの調査に有用ですが、レポートを作成すると、分析しやすいレイアウトでクエリ文字列を統合して表示できます。

実行時間の長いクエリを特定する

実行時間列を追加して、メトリックとして取得されたクエリだけでなく、すべてのクエリの数値を取得します。このデータを並べ替えると、どのクエリが完了までに最も時間がかかるかがわかります。

[監視] セクションで [ログ] を選択して、ログ情報に対してクエリを実行します。
次の基本的なクエリを実行すると、ミリ秒単位の実行時間で並べ替えられたクエリが返されます。実行時間が最も長いクエリは一番上にあります。
```
AzureDiagnostics
| project OperationName, resultSignature_d, DurationMs, Query_s, Documents_d, IndexName_s
| where OperationName == "Query.Search"
| sort by DurationMs
```

メトリックアラートの作成

メトリックアラートでは、通知を送信したり、事前に定義した是正措置をトリガーしたりするための、しきい値を設定します。クエリの実行に関連するアラートを作成できますが、リソースの正常性、検索サービスの構成の変更、スキルの実行、ドキュメントの処理 (インデックス作成) について作成することもできます。

すべてのしきい値はユーザー定義であるため、アラートをトリガーすべきアクティビティレベルをユーザーが考える必要があります。

クエリの監視の場合、検索の待ち時間とスロットルされたクエリに関するメトリックアラートを作成するのが一般的です。クエリが "いつ" 削除されるかわかっている場合は、負荷を軽減したり容量を増やしたりする対処方法を探すことができます。たとえば、スロットルされたクエリがインデックスの作成中に増加する場合は、クエリアクティビティが減少するまでインデックス作成を延期できます。

レプリカとパーティションの特定の構成の制限に達しそうな場合は、クエリの量のしきい値 (QPS) に対してアラートを設定するのも役に立ちます。

[監視] で [アラート] を選んでから、[アラートルールの作成] を選びます。
[条件] で [追加] を選びます。
シグナルロジックを構成します。シグナルの種類として [メトリック] を選択した後、シグナルを選択します。
シグナルを選択した後、グラフを使用して履歴データを視覚化し、条件の設定を進める方法に関して、情報に基づいた決定を行うことができます。
次に、[アラートロジック] まで下へスクロールします。概念実証の場合、テスト目的で人為的に低い値を指定できます。
次に、アクショングループを指定するか作成します。これは、しきい値に達したときに呼び出される応答です。これには、プッシュ通知または自動応答を指定できます。
最後に、アラートの詳細を指定します。アラートに名前と説明を指定し、重要度の値を割り当てて、ルールを有効な状態と無効の状態のどちらで作成するかを指定します。

メール通知を指定した場合、"Microsoft Azure" から "Azure: Activated Severity: 3 <your rule name>" という件名のメールを受け取ります。

次のステップ

まだ行っていない場合は、検索サービスの監視の基礎を確認し、すべての監視機能について理解してください。

Azure AI Searchでの操作とアクティビティの監視