Azure AI 検索 で大規模なデータ セットのインデックスを作成する

この記事では、検索ソリューションで大規模または複雑なデータ セットのインデックスを作成する必要がある場合に、Azure AI 検索で実行時間の長いプロセスに対応するための戦略について説明します。

このような戦略では、データをインポートするための 2 つの基本的な方法 (インデックスへのデータの "プッシュ"、または検索インデクサーを使用したサポートされているデータ ソースからのデータの "プル") について理解していることを前提としています。 計算負荷の高い AI エンリッチメントがシナリオに含まれている場合、スキルセットがインデクサーに依存していることを考えると、インデクサーが必要になります。

この記事では、インデックスとクエリの設計に関するベスト プラクティスを提供する、パフォーマンス向上のためのヒントを補完します。 必要なフィールドと属性のみを含む適切に設計されたインデックスは、大規模なインデックス作成の重要な前提条件です。

2024 年 4 月 3 日以降に作成された検索サービスを使用して、 パーティションあたりのストレージを増やします。 古いサービスをアップグレードして、より高いパーティション ストレージを利用することもできます。

プッシュ API を使用してデータのインデックスを作成する

Documents Index REST API や IndexDocuments メソッド (Azure SDK for .NET) などの "プッシュ" API は、Azure AI 検索で最も一般的な形式のインデックス作成です。 プッシュ API を使用するソリューションの場合、実行時間の長いインデックス作成の戦略には、次のコンポーネントのいずれかまたは両方があります。

• ドキュメントのバッチ処理
• スレッドの管理

要求ごとに複数のドキュメントをバッチ処理する

大量のデータにインデックスを付ける簡単なメカニズムは、複数のドキュメントまたはレコードを 1 つの要求で送信するというものです。 ペイロード全体が 16 MB を超えない限り、1 つの要求によって、一括アップロード操作で最大 1,000 個のドキュメントを処理できます。 これらの制限は、Documents Index REST API または .NET SDK の IndexDocuments メソッドのどちらを使用しているかに関係なく適用されます。 どちらの API を使用しても、各要求の本文に 1,000 個のドキュメントをパッケージ化できます。

ドキュメントをバッチ処理すると、大量のデータを処理するのにかかる時間が大幅に短縮されます。 実際のデータに最適なバッチ サイズを見極めることが、インデックスの作成速度を最適化するうえで重要な要素となります。 最適なバッチ サイズは主に、次の 2 つの要因によって左右されます。

• インデックスのスキーマ
• データのサイズ

最適なバッチ サイズはインデックスとデータによって異なるため、さまざまなバッチ サイズをテストしながら、実際のシナリオにおいてインデックスの作成速度が最速となるサイズを見極めるのが最善のアプローチとなります。 .NET SDK を使用してバッチ サイズをテストするためのサンプル コードについては、「チュートリアル: プッシュ API を使用してインデックス作成を最適化する」を参照してください。

スレッドと再試行戦略の管理

インデクサーには組み込みのスレッド管理がありますが、プッシュ API を使用する場合は、アプリケーション コードでスレッドを管理する必要があります。 使用可能な容量を最大限に活用するのに十分なスレッドがあることを確認します。特に、 最近サービスをアップグレードした場合、 より高い価格レベルに切り替えた場合、または パーティションを増やした場合。

1. クライアント コードで同時スレッドの数を増やします。

2. 検索サービスに対する要求を増やしていくと、要求が完全には成功しなかったことを示す HTTP 状態コードが返されることがあります。 インデックスの作成時によく発生する HTTP 状態コードは次の 2 つです。

   • 503 Service Unavailable: このエラーは、システムに大きな負荷がかかっており、この時点では要求を処理できないことを意味します。

   • 207 Multi-Status: このエラーは、一部のドキュメントは成功しましたが、少なくとも 1 つは失敗したことを意味します。

3. 失敗を処理するには、エクスポネンシャル バックオフの再試行戦略を使用して、要求を再試行する必要があります。

503 などで失敗した要求は、Azure .NET SDK によって自動的に再試行されますが、207 の再試行には独自のロジックを実装する必要があります。 Polly などのオープンソース ツールを使用して、再試行戦略を実装することもできます。

インデクサーおよびプル API を使用する

インデクサー には、実行時間の長いプロセスに役立ついくつかの機能が用意されています。

• ドキュメントのバッチ処理
• パーティション分割されたデータに対する並列インデックス作成
• 新規および変更されたドキュメントのみのインデックス作成のためのスケジュール設定と変更の検出

インデックスのスケジュールにより、最後の既知の停止ポイントから処理を再開できます。 データが処理ウィンドウ内で完全にインデックス付けされていない場合、インデクサーは、変更検出を提供するデータ ソースを使用していると仮定して、次回の実行時に中断した場所を取得します。

データをより小さな個々のデータ ソースにパーティション分割することにより、並列処理が実現されます。 Azure Blob Storage 内の複数のコンテナーなどにソース データを分割し、各パーティションのデータ ソースを作成してから、検索サービスの検索単位の数に従ってインデクサーを並列に実行できます。

インデクサーのバッチ サイズを確認する

Push API と同様に、インデクサーを使用すると、バッチごとに項目の数を構成できます。 インデクサー REST API の作成に基づくインデクサーの場合は、batchSize引数を設定して、データの特性に合わせてこの設定をカスタマイズします。

既定のバッチ サイズは、データ ソースによって異なります。 Azure SQL Database と Azure Cosmos DB の既定のバッチ サイズは 1,000 です。 これに対し、AZURE BLOB と SharePoint (プレビュー) インデックス作成では、より大きな平均ドキュメント サイズを認識して、バッチ サイズが 10 個のドキュメントに設定されます。

実行時間の長いプロセスのためにインデクサーをスケジュールする

インデクサーのスケジュール設定は、大容量のデータ セットの処理や、エンリッチメント パイプラインでの画像分析などの低速実行処理に適応する上で重要なメカニズムです。

通常、インデクサー処理は 2 時間以内に実行されます。 インデックス作成ワークロードの完了に、数時間ではなく数日かかる場合は、2 時間ごとに開始される連続する定期的なスケジュールをインデクサーに設定できます。 データ ソースで変更の追跡が有効になっているとすると、インデクサーは最後に中断した場所で処理を再開します。 この頻度で、インデクサーでは、すべての未処理ドキュメントが処理されるまで、ドキュメントのバックログに従って数日にわたり処理を継続できます。 このパターンは、初回実行時または大規模な BLOB コンテナーのインデックス作成時に特に重要です。BLOB 一覧表示フェーズだけでは、数時間または数日かかる場合があります。 この間、インデクサーは処理中の BLOB を表示しませんが、エラーが報告されない限り、BLOB リストを反復処理している可能性があります。 ドキュメントの処理とエンリッチメントは、このフェーズが完了した後にのみ開始され、この動作が想定されます。

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

データ ソースに新しいドキュメントまたは更新されたドキュメントが存在しなくなった場合、インデクサーの実行履歴に処理されたドキュメント数 0/0 が報告され、処理は行われません。

スケジュールの設定の詳細については、「Create Indexer REST API」を参照するか、「Azure AI 検索でインデクサーのスケジュールを設定する」を参照してください。

インデクサーがエンリッチメント キャッシュを備えたスキルセットを使用している場合は、大規模なワークロードのキャッシュを有効にする前に、次の情報を確認してください。

インデクサーを並列で実行する

データをパーティション分割する場合は、各データ ソースからプルして同じ検索インデックスに書き込むインデクサーとデータ ソースの組み合わせを作成できます。 各インデクサーは個別であるため、同時に実行できるため、検索インデックスを順番に実行した場合よりもすばやく入力できます。

十分な容量があることを確認します。 サービス内の 1 つの検索単位は、特定の時点で 1 つのインデクサーを実行できます。 複数のインデクサーの作成は、並列で実行できる場合にのみ有効です。

同時に実行できるインデックス作成ジョブの数は、テキストベースおよびスキルベースのインデックス作成によって異なります。 詳細については、「インデクサーの実行」を参照してください。

データ ソースが Azure Blob Storage コンテナーまたは Azure Data Lake Storage Gen 2 の場合、大量の BLOB を列挙すると、この操作が完了するまでに長い時間 (数時間) に及ぶこともあります。 その結果、インデクサーの 成功したドキュメント 数はその間増加していないように見え、実際には進行しているにもかかわらず、まったく進捗していないように思える場合があります。 大量の BLOB でドキュメント処理を高速化する場合は、データを複数のコンテナーにパーティション分割し、1 つのインデックスを指す並列インデクサーを作成することを検討してください。

1. Azure portal で、Search サービスに移動します。

2. 検索サービスで使用される検索単位の数を確認します。 [設定]>[スケール] を選択して、ページの上部の数値を表示します。 並列で実行されるインデクサーの数は、検索ユニットの数とほぼ等しくなります。

3. 複数のコンテナーまたは同じコンテナー内の複数の仮想フォルダーにソース データをパーティション分割します。

4. パーティションごとに 1 つ、独自のインデクサーとペアの複数のデータ ソースを作成します。

5. 各インデクサーで同じターゲット検索インデックスを指定します。

6. インデクサーをスケジュールします。

7. インデクサーの状態と実行履歴を確認します。

並列インデックス作成にはいくつかのリスクがあります。 まず、インデックス作成はバックグラウンドでは実行されないため、クエリがスロットリングされたり破棄されたりする可能性が高くなることに注意してください。

2 つ目に、Azure AI 検索 ではインデックスの更新がロックされません。 初回試行で特定の書き込みが成功しなかった場合に再試行を呼び出すことで同時書き込みが管理されますが、インデックス作成エラーが増加する可能性があります。

インデクサーとデータ ソースの複数のセットで同じインデックスをターゲットにすることはできますが、インデックスの既存の値を上書きできるインデクサーの実行にご注意ください。 2 番目のインデクサーとデータ ソースで同じドキュメントとフィールドがターゲットになっている場合、最初の実行の値がすべて上書きされます。 フィールドの値は完全に置き換えられます。インデクサーは、複数の処理の値を同じフィールドにマージすることはできません。

Spark でビッグ データのインデックスを作成する

ビッグ データ アーキテクチャがあり、データが Spark クラスター上にある場合は、 SynapseML を使用してデータの読み込みとインデックス作成を行います。 このチュートリアルには、Foundry Tools for AI エンリッチメントを呼び出す手順が含まれていますが、テキスト インデックス作成に AzureSearchWriter API を使用することもできます。

関連するコンテンツ

• チュートリアル: プッシュ API を使用してインデックス作成を最適化する
• チュートリアル: SynapseML と Azure AI 検索 を使用して Apache Spark からの大規模データのインデックスを作成する
• Azure AI 検索のパフォーマンス向上に関するヒント
• Azure AI 検索 でのパフォーマンスを分析
• Azure AI 検索 のインデクサー
• Azure AI 検索でインデクサーの状態と結果を監視する