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

Azure AI 検索には、容量を異なる方法で処理する 2 つの価格モデルが用意されています。

• 専用: レプリカとパーティションのサイズを設定し、サービス レベルを選択して容量を計画します。

  • レプリカとパーティションを使用して容量を直接事前プロビジョニングします。
  • 必要なストレージ (パーティション) と必要なスループット (レプリカ) を見積もります。
  • 予想されるピーク需要に基づいて必要な容量をプロビジョニングするサービス レベルを選択します。
  • 容量を事前に構成したら、使用量に関係なく、検索ユニット (SU) によって測定された時間単位の料金を支払います。

• サーバーレス (プレビュー):サービスは、使用量とサービスの制限に基づいて容量を自動的に管理します。 容量を事前にプロビジョニングする必要はありません。 代わりに、ワークロードの効率を最適化してコストを管理します。

  • 容量は需要に応じて自動的にスケーリングされます (アイドル時にはゼロにスケーリングできます)。
  • コンピューティング ユニット (CU) とストレージによって測定された実際の使用量に基づいて課金されます。
  • 計画では、インフラストラクチャではなく、クエリ パターン、インデックスのサイズと増加、データ インジェスト パターンなどのコスト 要因に重点を置いています。 サーバーレス モデルのコストの最適化を参照してください。

詳細については、次の方法を参照してください。

• コストの計画と管理
• 価格モデルとサービス レベルを選択する
• サーバーレス価格モデルを使用してコストを最適化する

専用モデルの容量を計画する

専用モデルでは、 検索ユニット (SU) を使用して容量をプロビジョニングします。

• 検索ユニット (SU) = パーティション×レプリカ
• レプリカ: 検索エンジンのコピー。 クエリのスループットと高可用性を提供します。
• パーティション: ストレージの単位。 ストレージとインデックス作成のスループットを提供します。

各サービスは、1 つのレプリカ × 1 つのパーティション (1 SU) で開始されます。 変動するワークロードに対応するために、レプリカとパーティションを個別に追加または削除できます。 容量を追加すると、検索サービスを実行するコストが増加します。

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

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

専用モデルの容量を追加するタイミング

次の場合は、レプリカまたはパーティションを追加することを検討してください。

• クエリのレイテンシが増加する、またはサービス レベル アグリーメントの基準が満たされない。
• HTTP 503 (サービス利用不可) エラーの頻度が増加します。
• HTTP 429（リクエストが多すぎます）エラーの発生頻度が増加しており、リクエストのスロットリングが行われていることを示しています。
• 大規模なクエリ ボリュームが必要です。
• インデックス作成ジョブの処理が遅いか、追いついていません。
• ストレージまたはインデックス作成のスループットが不十分です。

スケーリングガイダンス:

• レプリカを追加して、クエリのスループットと可用性を向上させます。
• パーティションを追加して、ストレージとインデックス作成のパフォーマンスを向上させます。
• クエリ負荷の高いワークロードでは、通常、より多くのレプリカが必要です。
• 大規模なインデックスでは、パフォーマンスを維持するために追加のレプリカが必要になる場合があります。

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

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

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

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

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

サービスの制限と有効なスケーリング範囲については、次を参照してください。

• レベルと SKU のサービス制限
• 価格モデルとサービス レベルを選択する

容量を管理および調整する方法

容量の変更は瞬時には行われません。 データ量と操作の種類によっては、スケーリングに数分から数時間かかる場合があります。

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

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

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

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

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

1. Azure ポータルで検索サービスに移動します。

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

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

   

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

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

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

   

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

   

   この操作の完了には数時間かかることがあります。 これはバックグラウンドで発生するため、検索サービスは引き続き完全に動作し、読み取りおよび書き込み操作に使用できます。

   操作を取り消したり、進行状況を監視したりすることはできません。 ただし、変更中は次のメッセージが表示されます。

   

価格レベルを変更する

価格レベルによって、専用価格モデルの検索サービスの最大ストレージが決まります。 容量を増減する必要がある場合は、ストレージのニーズに合わせて別の価格レベルに切り替えることができます。 (これは専用価格モデルレベルにのみ適用されます。サーバーレス モデルの開発者層は、一度選択した後は変更できません)。

容量に加えて、価格レベルによって、インデックス、インデクサー、その他の検索オブジェクトの制限が決まります。 続行する前に、現在のレベルのサービス制限と目的のレベルを比較してください。 一般に、より高いレベルに切り替えると、ストレージの制限とベクターの制限が増加し、要求スループットが増加し、待機時間が減少しますが、下位レベルに切り替えると、それと反対の効果があります。

より高い価格レベルに切り替えると、検索サービスを実行するコストも増加します。 詳細については、 価格に関するページを参照してください。

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

1. Azure ポータルで検索サービスに移動します。

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

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

   Azure portal の [価格レベルの変更] ボタンのスクリーンショット

4. [価格レベルの選択] ページで、一覧から別のレベルを選択します。

   Basic、S1、S2、S3 を切り替えることができますが、Free、S3HD、L1、または L2 に切り替えることはできません。 これらのレベルは選択できず、淡色表示されます。

   

5. スケーリング操作を開始するには、[保存] を選択します。

   

   この操作の完了には数時間かかることがあります。 これはバックグラウンドで発生するため、検索サービスは引き続き完全に動作し、読み取りおよび書き込み操作に使用できます。

   操作を取り消したり、進行状況を監視したりすることはできません。 ただし、変更中は次のメッセージが表示されます。

   

専用モデルに対するスケール要求の処理方法

検索サービスがスケール要求を受け取ると、次のようになります。

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

サービスのサイズと要求のスコープによっては、サービスのスケーリングには数分から数時間かかることがあります。 バックアップ期間も、データの量とパーティションとレプリカの数によって異なります。

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

スケーリング中のエラー

次の表に、スケーリング操作中に発生する可能性があるエラーの原因と解決策の一覧を示します。

¹ バックアップの状態がありません。これは内部操作であり、スケーリング操作を妨げる可能性は低いです。

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

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

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

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

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

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

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

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

専用価格モデル レベルを使用して容量を見積もる

ストレージのニーズは、ビルドするインデックスのサイズによって異なります。 見積もりに役立つ強固なヒューリスティックや一般的なガイドラインはありません。 インデックスのサイズを決定する唯一の方法は、インデックスを 作成することです。 そのサイズは、トークン化と埋め込み、サジェスター、フィルター処理、並べ替えを有効にするか、 ベクター圧縮を利用できるかによって異なります。

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

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

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

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

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

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

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

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

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

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

4. Azure ポータルでストレージ、サービス制限、クエリボリューム、待機時間を監視する。 Azure ポータルには、1 秒あたりのクエリ数、調整されたクエリ、検索待ち時間が表示されます。 これらの値は、適切なレベルを選択したかどうかを判断するのに役立ちます。

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

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

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

検索しないデータを含める場合は、ストレージ要件を増やすことができます。 ドキュメントには、検索機能に必要なデータのみが含まれていることが理想的な状態です。

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

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

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

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

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

サーバーレス モデルのコストを最適化する

サーバーレス価格モデルでは、次の手順を実行します。

• サービスは容量を自動的に管理します。
• レプリカ、パーティション、または検索単位を構成する必要はありません。
• コンピューティングはワークロード (クエリとインデックス作成の需要) に基づいて動的にスケーリングされ、アイドル時にはゼロにスケーリングできます。

サーバーレス モデルの制限の詳細については、「 サービスの制限」を参照してください。

課金は、次の 2 つのディメンションに基づいています。

• コンピューティング使用量 (CU): クエリ操作とインデックス作成操作に基づいて課金されます。
• インデックス付きストレージ: 1 か月あたり GB ごとに課金されます。

課金は従量課金ベースであるため、コストは使用量に直接関連付けられます。

• 複雑なクエリは、より多くのコンピューティングを消費します。
• 非効率的なスキーマ設計では、インデックス作成とクエリのコストの両方が増加します。
• インデックスが大きい、または頻繁に更新されるクエリ パターンが不適切な場合は、ストレージとコンピューティングの使用量が増加します。

ワークロードの効率を最適化する

サーバーレス モデルでは非効率性がコストとして表示されるため、ワークロード対応の設計を実践しない場合は、同じ作業に対してより多くの料金が発生します。 サーバーレス支出を制御する最善の方法は、インデックスとクエリを最初から効率的に設計することです。

サーバーレス価格モデルを使用するときに効率を高めるためにワークロードを設計するには、次の点を考慮してください。

インデックスの設計

• クエリで使用されるフィールドのみを含めます。
• 可能な限りベクトル次元を減らします。
• 不必要なフィルター、ソート、またはファセット機能の対象となる属性は避けてください。

クエリ パターン

• $selectを使用して、返されるフィールドを制限します。
• フィルターを早期に適用して結果セットを減らします。
• 深いページング ($skip) は避けてください。
• 広範なフルテキスト クエリよりも対象のクエリを優先します。
• コンピューティング コストが高いため、ハイブリッド検索は慎重に使用してください。

Monitoring

• CU 消費量を監視して、コストの高いクエリを特定します。
• ストレージの増加を追跡し、未使用のデータを削除します。

サーバーレスでは、パフォーマンスの向上 (より高速で対象となるクエリ) が通常、コストを削減します。

詳細については、 Azure AI 検索 のサーバーレス価格モデルを使用してコストを最適化する方法に関するページを参照してください。

リージョンの容量に関する考慮事項

容量と可用性は、 サポートされているリージョンによって異なる場合があります。 一部のリージョンでは、新しいサービスのプロビジョニングや既存のサービスのスケーリングに制約がある場合があります。

容量の制約のために優先Azure AI 検索リージョンが使用できない場合は、「 Azure AI 検索を参照してください。

次のステップ