検索サービスの容量を見積もって管理する

Azure AI Search では、容量はワークロードに合わせてスケーリングできる "レプリカ" と "パーティション" に基づいています。 レプリカは検索エンジンのコピーです。 パーティションはストレージの単位です。 新しい検索サービスはそれぞれ 1 つずつ開始されますが、変動するワークロードに対応するために、レプリカとパーティションの追加または削除を個別に行うことができます。 容量を追加すると、検索サービスを実行するコストが増加します。

処理速度やディスク IO など、レプリカとパーティションの物理的な特性は、 価格レベルによって異なります。 標準の検索サービスでは、レプリカとパーティションは基本サービスにあるものよりも高速で大きくなります。

容量の変更は瞬時には行われません。 特に大量のデータが含まれているサービスでは、パーティションのコミッションまたは使用停止に最大で 1 時間かかることがあります。

検索サービスをスケーリングする場合は、次のツールと方法で選択できます。

• Azure Portal
• Azure PowerShell
• Azure CLI
• 管理 REST API

概念: 検索ユニット、レプリカ、パーティション

容量は、パーティションとレプリカの組み合わせで割り当てることができる検索ユニットで表されます。

パーティションとレプリカのテーブルで、36 ユニットの制限を超えない可能性のある組み合わせを確認します。

容量をいつ追加するか

最初に、1 つのパーティションと 1 つのレプリカで構成される最小限のリソースがサービスに割り当てられます。 選択するレベルによってパーティションのサイズと速度が決まり、各レベルはさまざまなシナリオに適した一連の特性に対して最適化されます。 ハイエンド レベルを選択した場合は、S1 を使用する場合よりもパーティション数を減らす必要がある場合があります。 セルフダイレクト テストを通じて回答する必要がある質問の 1 つは、より大きくコストの高いパーティションの方が、下位レベルでプロビジョニングされたサービスで 2 つの安価なパーティションよりもパフォーマンスが向上するかどうかです。

1 つのサービスに、すべてのワークロード (インデックスおよびクエリ) を処理するための十分なリソースが必要です。 どちらのワークロードもバックグラウンドで実行されません。 クエリ要求の頻度が自然に低い時間にインデックス作成をスケジュールできますが、それ以外の場合、サービスは 1 つのタスクに優先順位を付けることはできません。 さらに、ある程度の冗長性により、サービスまたはノードが内部的に更新されるときのクエリのパフォーマンスの問題を解決します。

容量を追加するかどうかを決定するためのガイドラインは次のとおりです。

• サービスレベル合意の高可用性を満たすための基準。
• HTTP 503 (サービス利用不可) エラーの頻度が増加しています。
• HTTP 429 (要求が多すぎます) エラーの頻度が増加しており、ストレージが少なくなっていることが示されています。
• 大規模なクエリ ボリュームが必要です。
• 新しいインフラストラクチャと大規模なパーティションへの 1 回限 りのアップグレードでは不十分です。
• 現在のパーティション数は、ワークロードのインデックス作成には適していません。

一般的な規則として、検索アプリケーションでは、パーティションよりもレプリカの方が多く必要となる傾向があります。特に、サービス操作でクエリ ワークロードの比重が高い場合は、その傾向が強まります。 各レプリカは、インデックスの 1 コピーです。これにより、サービスでは、複数のコピーに対して要求を負荷分散できます。 Azure AI Search では、インデックスのすべての負荷分散とレプリケーションが管理され、サービスに割り当てられたレプリカの数はいつでも変更できます。 Standard Search サービスでは最大 12 個、Basic Search サービスでは最大 3 個のレプリカを割り当てることができます。 レプリカの割り当ては、Azure portal またはプログラム オプションの 1 つのいずれかから行うことができます。

追加のパーティションは、集中的なインデックス作成ワークロードに役立ちます。 パーティションを追加すると、読み取り/書き込み操作がより多くのコンピューティング リソースに分散されます。

最後に、インデックスが大きくなると、クエリの実行に時間がかかります。 そのため、パーティションで段階的に増加すれば、レプリカでも小規模ながら比例して増加するべきであると考えるかもしれません。 クエリの内容とその量の複雑さが、どれほど速くクエリが処理されるかに影響を与えます。

容量をアップグレードする方法

一部の Azure AI Search 機能は、新しいサービスでのみ使用できます。 このような機能の 1 つは、 2024 年 4 月以降に作成されたサービスに適用される、より高いストレージ容量です。 ただし、2024 年 4 月より前にサービスを作成した場合は、1 回限りアップグレードを実行することで、サービスを再作成せずに容量を増やすことができます。 詳細については、「 検索サービスのアップグレード」を参照してください。

容量を変更する方法

サービスの容量を増減するには、次の 2 つのオプションがあります。

• パーティションとレプリカを追加または削除する
• 価格レベルを変更する

パーティションとレプリカを追加または削除する

1. Azure portal にサインインし、検索サービスを選択します。

2. 左側のペインで [設定]>[スケール] を選択します。

   次のスクリーンショットは、1 つのレプリカとパーティションでプロビジョニングされる Standard サービスを示しています。 下部の式は、使用される検索ユニットの数 (1) を示しています。 ユニットの価格が 100 ドル (実際の価格ではありません) の場合、このサービスを実行するための毎月のコストは平均 100 ドルになります。

   

3. スライダーを使ってパーティションの数を増減します。 [保存] を選択します。

   この例では、2 つ目のレプリカおよびパーティションを追加します。 請求の計算式では、レプリカ数とパーティション数が乗算されるため (2 x 2)、検索ユニット数が 4 になっていることに注意してください。 容量を 2 倍にすると、サービスを実行するためのコストが 2 倍以上になります。 検索ユニットのコストが 100 ドルの場合、新しい毎月の請求額は 400 ドルになります。

   各レベルの現在のユニットあたりのコストについては、 価格ページを参照してください。

   

4. 通知を確認して、操作が開始されたことを確認します。

   

   この操作の完了には数時間かかることがあります。 開始後にプロセスを取り消すことはできません。また、レプリカとパーティションの調整をリアルタイムで監視することはできません。 ただし、変更中は次のメッセージが表示されます。

   

価格レベルを変更する

価格レベルによって、検索サービスの最大ストレージが決まります。 より多くの 容量が必要な場合は、ストレージのニーズに対応する別の価格レベルに切り替えることができます。

容量に加えて、価格レベルを変更すると、サービスのワークロードと上限に影響します。 先に進む前に、現在のレベルの サービス制限 と目的のレベルを比較します。 これらには、次の制限が含まれます。

• パーティション ストレージ
• 索引
• ベクトル
• インデクサー
• 共有プライベート リンク リソース
• シノニム
• インデックスの別名
• セマンティック ランカーのスロットリング

一般に、より高いレベルに切り替えると、 ストレージの制限 と ベクターの制限が増え、要求のスループットが向上し、待機時間が短縮されます。

価格レベルを変更するには:

1. Azure portal にサインインし、検索サービスを選択します。

2. 左側のペインで [設定]>[スケール] を選択します。

3. 現在のレベルで、[ 価格レベルの変更] を選択します。

   

4. [ 価格レベルの選択 ] ページで、一覧から上位レベルを選択します。 現時点では、Basic、S1、S2、S3 の間でのみ上に移動できます。 その他の価格レベルは使用できず、淡色表示されます。

5. 上位レベルに切り替えるには、[選択] を 選択します。

   

   この操作の完了には数時間かかることがあります。 開始後にプロセスを取り消すことはできません。また、階層の変更をリアルタイムで監視することはできません。 ただし、[ 概要 ] ページでは、 プロビジョニング の状態は、サービスの操作が進行中であることを示します。

   

スケーリング要求を処理する方法

スケーリング要求を受け取ると、検索サービスでは次のことを行います。

1. 要求が有効であるかどうかを確認します。
2. データとシステム情報のバックアップを開始します。
3. サービスが既にプロビジョニング状態になっているかどうかを確認します (現在、レプリカまたはパーティションの追加または削除を実行中)。
4. プロビジョニングを開始します。

サービスのスケーリングには、サービスのサイズと要求の範囲に応じて、わずか 15 分しかかからないこともあれば、1 時間以上かかることもあります。 バックアップには、データ量とパーティションおよびレプリカの数に応じて、数分かかることがあります。

上記の手順は完全に連続しているわけではありません。 たとえば、システムでは、安全に行えるようになったときに、プロビジョニングを開始します。それは、バックアップが終わり近づいているときかもしれません。

スケーリング中のエラー

"前の要求を処理中であるため、現時点ではサービスの更新操作は許可されません" というエラー メッセージが表示される原因は、サービスによって既に前の要求の処理が開始されているときに、スケール ダウンまたはスケール アップの要求が繰り返されたことにあります。

このエラーを解決するには、サービスの状態を調べてプロビジョニングの状態を確認します。

1. 管理 REST API、Azure PowerShell 、またはAzure CLI を使用してサービス ステータスを取得します。
2. Get Service (REST) または PowerShell または CLI でそれに相当するものを呼び出します。
3. 応答を調べて、"provisioningState": "provisioning" を確認します。

状態が "Provisioning" である場合は、要求が完了するまで待ちます。 別の要求が試行されるには、状態が "Succeeded" または "Failed" のいずれかになっている必要があります。 バックアップの状態は存在しません。 バックアップは内部操作であって、スケーリング演習の中断の要因になる可能性はほとんどありません。

検索サービスがプロビジョニング状態で停止しているように見られる場合は、クエリ ボリュームが 0 でインデックスが更新されていない状態の、使用できない孤立したインデックスがないか確認します。 使用できないインデックスがある場合、サービス容量の変更がブロックされることがあります。 特に、キーが無効になっている、CMK で暗号化されたインデックスを探します。 インデックスを削除するか、キーを復元してインデックスをオンラインに戻し、スケール操作のブロックを解除する必要があります。

パーティションとレプリカの組み合わせ

次のグラフは、Standard レベル以上に適用されます。 パーティションとレプリカのすべての可能な組み合わせが表示されます。サービスごとに最大 36 個の検索ユニットが適用されます。

Basic 検索サービスでは、検索ユニット数が少なくなります。

• 2024 年 4 月 3 日より前に作成された検索サービスでは、Basic サービスはパーティションを 1 つだけ持ち、最大 3 つのレプリカを 3 つの SU に制限できます。 調整可能なリソースはレプリカだけです。 ただし、 サービスをアップグレードすることで、パーティション数を増やすことができる場合があります。

• サポートされているリージョンで 2024 年 4 月 3 日以降に作成された検索サービスでは、Basic サービスには最大 3 つのパーティションと 3 つのレプリカを含めることができます。 パーティションとレプリカを完全にサポートするために、SU の上限は 9 です。

作成日に関係なく、どの課金対象レベルの検索サービスでも、クエリの高可用性を実現するには少なくとも 2 つのレプリカが必要です。

レベルごとの課金レートと通貨については、Azure AI 検索の価格に関するページを参照してください。

課金対象階層を使用した容量の見積もり

構築するインデックスのサイズによって、ストレージのニーズが決まります。 見積もりに役立つような、信頼できる経験則や一般原則はありません。 インデックスのサイズを見極める唯一の方法は、1 つ構築することです。 そのサイズは、トークン化と埋め込み、suggester、フィルター処理、並べ替えを有効にするか、ベクトル圧縮を利用できるかに基づいています。

課金対象レベル (Basic 以上) で見積もることをお勧めします。 Free レベルは、複数の顧客が共有する物理リソースで実行され、制御を超える要因の対象となります。 課金対象の検索サービスの専用のリソースでのみ、より長いサンプリングと処理時間に対応でき、開発段階でのインデックスの数量、サイズ、クエリ量についてより現実的な見積もりを求めることができます。

1. 各レベルのサービス制限を確認して、より低いレベルで、必要なインデックス数に対応できるかどうかを判断してください。 アクティブな開発、テスト、運用のためにインデックスの複数のコピーが必要かどうかを検討します。

   検索サービスには、オブジェクトの制限 (インデックス、インデクサー、スキルセットの最大数など) とストレージの制限が適用されます。 最初に達した制限が、有効な制限になります。

2. 課金対象レベルでサービスを作成します。 レベルは、特定のワークロード向けに最適化されています。 たとえば、Storage Optimized レベルでは、少数の大きなインデックスをサポートするように設計されているため、インデックスは 10 個に制限されています。

   • 予想される負荷がわからない場合は、Basic または S1 の低いレベルで始めます。

   • テストに大規模なインデックス作成とクエリの負荷が含まれている場合は、S2 または S3 の高レベルから始めます。

   • 社内のビジネス アプリケーションのように、インデックスを付けるデータの量が多く、クエリの負荷が比較的低い場合は、Storage Optimized (L1 または L2) から始めます。

3. 最初のインデックスを構築して、ソース データがどのようにインデックスに変換されるかを特定します。 これは、インデックスのサイズを推測する唯一の方法です。 フィールド定義の属性は、物理ストレージの要件に影響します。

   • キーワード検索の場合、フィールドをフィルター可能および並べ替え可能としてマークすると、インデックス サイズが大きくなります。

   • ベクトル検索の場合は、ベクトル サイズを小さくするようにパラメーターを設定できます。

4. Azure portal で、ストレージ、サービス制限、クエリ量、待機時間を監視します。 秒あたりのクエリ数、スロットルされたクエリ数、検索の待ち時間が Azure portal に表示されます。 これらすべての値が、適切なレベルを選択したかどうかを判断するために役立ちます。

5. 可用性を高めたり、クエリのパフォーマンス低下を軽減したりするためにレプリカを追加します。

   クエリの負荷に対応するために必要なレプリカの数に関するガイドラインはありません。 クエリのパフォーマンスは、クエリおよび競合するワークロードの複雑さによって異なります。 レプリカを追加するとパフォーマンスが向上しますが、厳密に線形に向上するわけではありません。3 つのレプリカを追加しても、スループットが 3 倍になるとは限りません。 ソリューションの QPS を推定する方法のガイダンスについては、パフォーマンスのための分析と、クエリの監視に関する記事を参照してください。

転置インデックスのサイズと複雑性はコンテンツによって決まり、必ずしもそれにフィードするデータ量によって決まるものではありません。 冗長性の高い大規模なデータ ソースは、変動の多いコンテンツを含む小さいデータセットよりも、インデックスのサイズが小さくなることがあります。 そのため、元のデータ セットのサイズに基づいてインデックスのサイズを推測できることはほとんどありません。

検索されることのないデータが含まれていると、ストレージの要件が増大することがあります。 ドキュメントには、検索機能に必要なデータのみが含まれていることが理想的な状態です。

サービス レベル契約に関する考慮事項

Free レベルおよびプレビュー機能は、サービス レベル アグリーメント (SLA) の対象ではありません。 課金対象のすべてのレベルで、SLA が有効になるのは、サービスにとって十分な冗長性がプロビジョニングされるときです。

• 2 つ以上のレプリカがクエリ (読み取り) の SLA を満たしている。

• 3 つ以上のレプリカがクエリとインデックス作成 (読み取り/書き込み) の SLA を満たしている。

パーティションの数は、SLA に影響しません。

次のステップ