検索サービスの容量を見積もって管理する
Azure AI Search では、容量はワークロードに合わせてスケーリングできる "レプリカ" と "パーティション" に基づいています。 レプリカは検索エンジンのコピーです。 パーティションはストレージの単位です。 新しい検索サービスはそれぞれ 1 つずつ開始されますが、変動するワークロードに対応するために、レプリカとパーティションの追加または削除を個別に行うことができます。 容量を追加すると、検索サービスを実行するコストが増加します。
処理速度やディスク IO など、レプリカとパーティションの物理的な特性は、サービス レベルによって異なります。 標準の検索サービスでは、レプリカとパーティションは基本サービスにあるものよりも高速で大きくなります。
容量の変更は瞬時には行われません。 特に大量のデータが含まれているサービスでは、パーティションのコミッションまたは使用停止に最大で 1 時間かかることがあります。
検索サービスをスケーリングする場合は、次のツールと方法で選択できます。
概念: 検索単位、レプリカ、パーティション、シャード
容量は、パーティションとレプリカの組み合わせで割り当てられる検索単位で表され、基になるシャーディング メカニズムを使用して柔軟な構成をサポートします。
| 概念 | 定義 |
|---|---|
| 検索単位 | 使用可能な合計容量の単一増分 (36 ユニット)。 これは、Azure AI Search サービスの課金単位でもあります。 サービスを実行するには、少なくとも 1 つの単位が必要です。 |
| [レプリカ] | 主にクエリ操作の負荷分散に使用される Search サービスのインスタンスです。 各レプリカは、インデックスの 1 つのコピーをホストします。 3 つのレプリカを割り当てると、クエリ要求のサービスに使用できるインデックスのコピーが 3 つ作成されます。 |
| パーティション | 読み取り/書き込み操作 (たとえば、インデックスを再構築または更新する場合など) のための物理ストレージと I/O。 各パーティションにインデックス全体のスライスがあります。 3 つのパーティションを割り当てると、インデックスは 3 つに分割されます。 |
| シャード | インデックスのチャンク。 Azure AI Search は、各インデックスをシャードに分割し、(シャードを新しい検索単位に移動することによって) パーティションを追加するプロセスを高速化しています。 |
次の図は、レプリカ、パーティション、シャード、および検索単位間の関係を示しています。 ここでは、2 つのレプリカと 2 つのパーティションを持つサービスで、どのように 1 つのインデックスが 4 つの検索単位にわたっているかを例で示しています。 4 つの検索単位それぞれには、インデックスのシャードの半分だけが格納されます。 左側の列の検索単位は、シャードの前半を格納して最初のパーティションを構成し、右側の列の検索単位は、シャードの後半を格納して 2 番目のパーティションを構成しています。 レプリカが 2 つあるため、各インデックス シャードのコピーは 2 つあります。 上部の行の検索単位は、1 つのコピーを格納して最初のレプリカを構成し、下部の行の検索単位は、別のコピーを格納して 2 番目のレプリカを構成しています。
上の図は 1 つの例にすぎません。 パーティションとレプリカはさまざまに組み合わせることができ、最大で合計 36 の検索単位が可能です。
Azure AI Search では、シャード管理は実装の詳細であり、構成できませんが、インデックスがシャード化されているとわかっていれば、順位付けやオートコンプリートの動作で不定期に発生する異常を理解する場合に役立ちます。
異常のランク付け: 検索スコアは最初にシャード レベルで計算され、続いて単位の結果セットに集計されます。 シャード コンテンツの特性に応じて、あるシャードからの一致が別のシャードの一致よりも高い順位になる場合があります。 検索結果の順位付けが直観に反しているように感じられる場合は、シャーディングの影響が原因である可能性が最も高いです (特にインデックスが小さい場合)。 インデックス全体でグローバルにスコアを計算するように選択すれば、これらの順位付けの異常を回避できますが、その場合、パフォーマンスが低下します。
オートコンプリートの異常: オートコンプリート クエリでは、部分的に入力された語句の最初のいくつかの文字で照合が行われますが、スペルの少しの間違いを許容するあいまいパラメーターが使用されます。 オートコンプリートの場合、あいまい一致は現在のシャード内の用語に限定されます。 たとえば、シャードに "Microsoft" が含まれており、"micro" という部分的な語句が入力された場合、検索エンジンはそのシャード内の "Microsoft" と一致しますが、インデックスの残りの部分を保持した他のシャードでは一致しません。
推定のターゲット
容量計画には、オブジェクトの制限 (サービスで許可されるインデックスの最大数など) とストレージの制限を含める必要があります。 サービス レベルによって、オブジェクトとストレージの制限が決定されます。 最初に達した制限が、有効な制限になります。
インデックスとその他のオブジェクトの数は、通常、ビジネスおよびエンジニアリングの要件によって決まります。 たとえば、アクティブな開発、テスト、および運用において、同じインデックスの複数のバージョンを保持する場合があります。
ストレージのニーズは、構築する予定のインデックスのサイズによって決まります。 見積もりに役立つような、信頼できる経験則や一般原則はありません。 インデックスのサイズを見極める唯一の方法は、1 つ構築することです。 そのサイズは、インポートされたデータ、テキスト分析、およびインデックス構成 (suggester、フィルタリング、並べ替えを有効にするかどうかなど) に基づきます。
全文検索の場合、主要データ構造は転置インデックス構造であり、ソース データとは異なる特性があります。 転置インデックスのサイズと複雑性はコンテンツによって決まり、必ずしもそれにフィードするデータ量によって決まるものではありません。 冗長性の高い大規模なデータ ソースは、変動の多いコンテンツを含む小さいデータセットよりも、インデックスのサイズが小さくなることがあります。 そのため、元のデータ セットのサイズに基づいてインデックスのサイズを推測できることはほとんどありません。
フィルターや並べ替えを有効にするなどした、インデックスの属性はストレージの要件に影響を与えます。 suggester の使用も、ストレージに影響します。 詳細については、属性とインデックス サイズに関する記事を参照してください。
Note
インデックスとストレージの将来のニーズの見積もりは、当て推量のように感じられるかもしれませんが、行う価値があります。 あるレベルの容量が少なすぎることがわかった場合は、それより上のレベルで新しいサービスをプロビジョニングしたうえで、インデックスを再読み込みする必要があります。 特定のレベルから別のレベルへのサービスのインプレース アップグレードを実行することはできません。
Free レベルでの見積もり
容量を見積もる方法の 1 つは、まず Free レベルを使用することです。 Free サービスでは、最大 3 つのインデックス、50 MB のストレージ、および 2 分間のインデックス作成時間が提供されます。 これらの制約の中で予想インデックス サイズを見積もることは簡単ではない可能性がありますが、その手順は次のとおりです。
Free サービスを作成します。
小さな代表的なデータセットを準備します。
インデックスを作成し、データを読み込みます。 インデクサーでサポートされている Azure データ ソース内でデータセットをホストできる場合は、ポータルにあるデータのインポート ウィザードを使用して、インデックスの作成と読み込みの両方を行うことができます。 それ以外の場合は、REST API を使ってインデックスを作成し、データをプッシュできます。 プッシュ モデルでは、データを JSON ドキュメントの形式にする必要があります。そのドキュメント内のフィールドは、インデックス内のフィールドに対応します。
インデックスに関する情報 (サイズなど) を収集します。 特徴と属性はストレージに影響します。 たとえば、suggester (Search-as-you-type クエリ) を追加すると、ストレージ要件が増加します。
同じデータ セットを使用する場合、各フィールドに異なる属性を設定してインデックスの複数のバージョンを作成し、ストレージ要件がどのように変化するかを確認してみてください。 詳細については、基本的なインデックスの作成に関するページの「ストレージへの影響」を参照してください。
大まかな見積もりが得られたら、2 つのインデックス (開発用と運用用) の量を予測するためにこの値を 2 倍にし、それに応じてレベルを選択します。
課金対象レベルでの見積もり
専用のリソースでは、より長いサンプリングと処理時間に対応でき、開発段階でのインデックスの量、サイズ、クエリ量についてより現実的な見積もりを求めることができます。 課金対象のレベルから始め、開発プロジェクトが成熟するのに応じて再評価するお客様もいます。
各レベルのサービス制限を確認して、より低いレベルで、必要なインデックス数に対応できるかどうかを判断してください。 Basic、S1、S2 レベルでのインデックス制限は、それぞれ 15、50、200 です。 Storage Optimized レベルは、少数の非常に大きいインデックスをサポートするように設計されているため、10 インデックスに制限されています。
-
- 予想される負荷がわからない場合は、Basic または S1 の低いレベルで始めます。
- テストに大規模なインデックス作成とクエリの負荷が含まれている場合は、S2 または S3 の高レベルから始めます。
- 社内のビジネス アプリケーションのように、インデックスを付けるデータの量が多く、クエリの負荷が比較的低い場合は、Storage Optimized (L1 または L2) から始めます。
最初のインデックスを構築して、ソース データがどのようにインデックスに変換されるかを特定します。 これは、インデックスのサイズを推測する唯一の方法です。
ポータルで、ストレージ、サービス制限、クエリ量、および待機時間を監視します。 秒あたりのクエリ数、調整されたクエリ数、および検索の待ち時間がポータルに表示されます。 これらすべての値が、適切なレベルを選択したかどうかを判断するために役立ちます。
可用性を高めたり、クエリのパフォーマンス低下を軽減したりするためにレプリカを追加します。
クエリの負荷に対応するために必要なレプリカの数に関するガイドラインはありません。 クエリのパフォーマンスは、クエリおよび競合するワークロードの複雑さによって異なります。 レプリカを追加するとパフォーマンスが向上しますが、厳密に線形に向上するわけではありません。3 つのレプリカを追加しても、スループットが 3 倍になるとは限りません。 ソリューションの QPS を推定する方法のガイダンスについては、パフォーマンスのための分析と、クエリの監視に関する記事を参照してください。
Note
検索されることのないデータが含まれていると、ストレージの要件が増大することがあります。 ドキュメントには、検索機能に必要なデータのみが含まれていることが理想的な状態です。 バイナリ データは検索できないため、別途保存する必要があります (おそらく Azure テーブルまたは BLOB ストレージに)。 その後、外部データへの URL 参照を保持するためのフィールドをインデックスに追加する必要があります。 個々の検索ドキュメントの最大サイズは 16 MB です (1 回の要求で複数のドキュメントを一括アップロードする場合は、それより小さくなります)。 詳細については、Azure AI Search サービスの制限に関するページを参照してください。
クエリ数に関する考慮事項
クエリ/秒 (QPS) は、パフォーマンスのチューニング中の重要なメトリックですが、キャパシティ プランニングでは、最初からクエリ数が多いことが予想される場合にのみ、それが考慮事項になります。
Standard レベルでは、レプリカとパーティションのバランスを取ることができます。 負荷分散用のレプリカを追加したり、並列処理用のパーティションを追加したりすることで、クエリのターンアラウンドを向上させることができます。 その後、サービスがプロビジョニングされた後に、パフォーマンスをチューニングできます。
最初から大量のクエリ数が継続することが予想される場合は、より強力なハードウェアを使用する、より高い Standard レベルを検討してください。 その後、これらのクエリ数が発生しなかった場合は、パーティションとレプリカをオフラインにするか、より低いレベルのサービスに切り替えることができます。 クエリのスループットを計算する方法の詳細については、クエリの監視に関するページを参照してください。
Storage Optimized レベルは、大規模なデータ ワークロードに適しており、クエリの待ち時間要件がそれほど重要でない場合に、より全体的に利用可能なインデックス ストレージをサポートします。 それでも、負荷分散のためにはレプリカを追加し、並列処理のためにはパーティションを追加する必要があります。 その後、サービスがプロビジョニングされた後に、パフォーマンスをチューニングできます。
サービス レベル アグリーメント
Free レベルおよびプレビュー機能は、サービス レベル アグリーメント (SLA) の対象ではありません。 課金対象のすべてのレベルで、SLA が有効になるのは、サービスにとって十分な冗長性がプロビジョニングされるときです。 クエリ (読み取り) の SLA には複数のレプリカが必要です。 クエリとインデックス作成 (読み取り/書き込み) の SLA には 3 つ以上のレプリカが必要です。 パーティションの数は、SLA に影響しません。
容量計画に関するヒント
クエリに関するメトリックを構築し、利用パターン (業務時間中のクエリ数、オフピーク時のインデックス作成) に関するデータを収集します。 このデータを使用して、サービス プロビジョニングに関する決定に役立つ情報を提供します。 時間ごと、または毎日の周期では実用的でありませんが、パーティションやリソースを動的に調節して、クエリ数の計画された変化に対応できます。 計画外ではあっても持続した変化に対応することもできます。ただし、対処する間、そのレベルが保持される場合です。
過小なプロビジョニングの唯一の欠点として、実際の要件が予測より大きかった場合にサービスを中断する必要があるということに注意してください。 サービスの中断を回避するには、より高いレベルで新しいサービスを作成し、すべてのアプリと要求が新しいエンドポイントを指すようになるまで並行して実行します。
容量をいつ追加するか
最初に、1 つのパーティションと 1 つのレプリカで構成される最小限のリソースがサービスに割り当てられます。 選択するレベルによってパーティションのサイズと速度が決まり、各レベルはさまざまなシナリオに適した一連の特性に対して最適化されます。 ハイエンド レベルを選択した場合は、S1 を使用する場合よりもパーティション数を減らす必要がある場合があります。 自己指示型のテストを通じて回答する必要がある質問の 1 つは、より大きなパーティションの方が、低いレベルでプロビジョニングされたサービス上の 2 つの安価なパーティションよりもパフォーマンスが優れているかどうかということです。
1 つのサービスに、すべてのワークロード (インデックスおよびクエリ) を処理するための十分なリソースが必要です。 どちらのワークロードもバックグラウンドで実行されません。 クエリ要求の頻度が低い時間帯にインデックスを作成するようにスケジュールできますが、それ以外の時間帯では、特定のタスクが別のタスクより優先されることはありません。 さらに、ある程度の冗長性により、サービスまたはノードが内部的に更新されるときのクエリのパフォーマンスの問題を解決します。
容量を追加するかどうかを判断するためのガイドラインを次に示します。
- サービス レベル アグリーメントの高可用性条件を満たす
- HTTP 503 エラーの頻度が増加している
- 大規模なクエリ ボリュームが想定される
一般的な規則として、検索アプリケーションでは、パーティションよりもレプリカの方が多く必要となる傾向があります。特に、サービス操作でクエリ ワークロードの比重が高い場合は、その傾向が強まります。 各レプリカは、インデックスの 1 コピーです。これにより、サービスでは、複数のコピーに対して要求を負荷分散できます。 インデックスの負荷分散とレプリケーションはすべて Azure AI Search によって管理されます。サービスに割り当てられたレプリカの数はいつでも変更できます。 Standard Search サービスでは最大 12 個、Basic Search サービスでは最大 3 個のレプリカを割り当てることができます。 レプリカの割り当ては、Azure portal またはプログラム オプションの 1 つのいずれかから行うことができます。
ほぼリアルタイムのデータ更新を要求する検索アプリケーションでは、レプリカよりも多くのパーティションが比例して必要になります。 パーティションを追加すると、読み取り/書き込み操作がより多くのコンピューティング リソースに分散されます。 また、追加のインデックスとドキュメントを格納するためのディスク領域も増加します。
最後に、インデックスが大きくなると、クエリの実行に時間がかかります。 そのため、パーティションで段階的な増加が発生するたびに、レプリカでは小規模であるが比例的な増加が必要となる場合があります。 クエリの複雑さとボリュームは、クエリの実行が完了するまでの速度の要因となります。
Note
レプリカやパーティションを追加すると、サービスの実行コストが増加し、結果の並べ替え方法が少し変化する可能性があります。 ノードを追加した場合の課金の影響を理解するには、料金計算ツール を必ず確認してください。 下のグラフは、特定の構成に必要な検索単位の数を相互参照するのに役立ちます。 レプリカの追加によるクエリ処理への影響について詳しくは、「結果の並べ替え」をご覧ください。
レプリカとパーティションの追加または削減
Azure Portal にサインインし、Search サービスを選択します。
[設定] で、[スケール] ページを開いてレプリカとパーティションの数を変更します。
次のスクリーンショットは、1 つのレプリカとパーティションでプロビジョニングされる Basic Standard を示しています。 下部の式は、使用される検索ユニットの数 (1) を示しています。 ユニットの価格が 100 ドル (実際の価格ではありません) の場合、このサービスを実行するための毎月のコストは平均 100 ドルになります。
![現在の値が表示されている [スケール] ページ](media/search-capacity-planning/1-initial-values.png)
スライダーを使ってパーティションの数を増減します。 [保存] を選択します。
この例では、2 つ目のレプリカおよびパーティションを追加します。 請求の計算式では、レプリカ数とパーティション数が乗算されるため (2 x 2)、検索ユニット数が 4 になっていることに注意してください。 容量を 2 倍にすると、サービスを実行するためのコストが 2 倍以上になります。 検索ユニットのコストが 100 ドルの場合、新しい毎月の請求額は 400 ドルになります。
各レベルの現在のユニットあたりのコストについては、価格のページをご覧ください。
保存した後、通知を確認して、操作が成功したことを確認できます。
容量の変更が完了するまでに 15 分から最大で数時間かかることがあります。 プロセスが開始されたらキャンセルすることはできません。また、レプリカとパーティションの調整のリアルタイムの監視はありません。 ただし、変更が行われている間、次のメッセージが常に表示されています。
Note
サービスをプロビジョニングした後は、上位のレベルにアップグレードすることはできません。 新しいレベルで Search Service を作成し、インデックスを再度読み込む必要があります。 サービス プロビジョニングについては、「ポータルで Azure AI Search サービスを作成する」を参照してください。
スケーリング要求を処理する方法
スケーリング要求を受け取ると、検索サービスでは次のことを行います。
- 要求が有効であるかどうかを確認します。
- データとシステム情報のバックアップを開始します。
- サービスが既にプロビジョニング状態になっているかどうかを確認します (現在、レプリカまたはパーティションの追加または削除を実行中)。
- プロビジョニングを開始します。
サービスのスケーリングには、サービスのサイズと要求の範囲に応じて、わずか 15 分しかかからないこともあれば、1 時間以上かかることもあります。 バックアップには、データ量とパーティションおよびレプリカの数に応じて、数分かかることがあります。
上記の手順は完全に連続しているわけではありません。 たとえば、システムでは、安全に行えるようになったときに、プロビジョニングを開始します。それは、バックアップが終わり近づいているときかもしれません。
スケーリング中のエラー
"前の要求を処理中であるため、現時点ではサービスの更新操作は許可されません" というエラー メッセージが表示される原因は、サービスによって既に前の要求の処理が開始されているときに、スケール ダウンまたはスケール アップの要求が繰り返されたことにあります。
このエラーを解決するには、サービスの状態を調べてプロビジョニングの状態を確認します。
- 管理 REST API、Azure PowerShell 、またはAzure CLI を使用してサービス ステータスを取得します。
- Get Service (REST) または PowerShell または CLI でそれに相当するものを呼び出します。
- 応答を調べて、"provisioningState": "provisioning" を確認します。
状態が "Provisioning" である場合は、要求が完了するまで待ちます。 別の要求が試行されるには、状態が "Succeeded" または "Failed" のいずれかになっている必要があります。 バックアップの状態は存在しません。 バックアップは内部操作であって、スケーリング演習の中断の要因になる可能性はほとんどありません。
検索サービスがプロビジョニング状態で停止しているように見られる場合は、クエリ ボリュームが 0 でインデックスが更新されていない状態の、使用できない孤立したインデックスがないか確認します。 使用できないインデックスがある場合、サービス容量の変更がブロックされることがあります。 特に、キーが無効になっている、CMK で暗号化されたインデックスを探します。 インデックスを削除するか、キーを復元してインデックスをオンラインに戻し、スケール操作のブロックを解除する必要があります。
パーティションとレプリカの組み合わせ
2024 年 4 月 3 日より前に作成された検索サービスの場合: Basic では、パーティションを 1 つのみ、レプリカを 3 つまで持つことができ、SU の上限は 3 つです。 調整可能なリソースはレプリカだけです。
サポートされているリージョンに 2024 年 4 月 3 日より後に作成された検索サービスの場合: Basic では最大 3 つのパーティションと 3 つのレプリカを持つことができます。 パーティションとレプリカを完全にサポートするために、SU の上限は 9 です。
作成日に関係なく、どの課金対象レベルの検索サービスでも、クエリの高可用性を実現するには少なくとも 2 つのレプリカが必要です。
すべての Standard および Storage Optimized 検索サービスでは、これらのレベルで許可されている 36 SU の制限のもとで、レプリカとパーティションの次の組み合わせを想定できます。
| 1 個のパーティション | 2 個のパーティション | 3 個のパーティション | 4 個のパーティション | 6 個のパーティション | 12 個のパーティション | |
|---|---|---|---|---|---|---|
| 1 つのレプリカ | 1 SU | 2 SU | 3 SU | 4 SU | 6 SU | 12 SU |
| 2 つのレプリカ | 2 SU | 4 SU | 6 SU | 8 SU | 12 SU | 24 SU |
| 3 つのレプリカ | 3 SU | 6 SU | 9 SU | 12 SU | 18 SU | 36 SU |
| 4 つのレプリカ | 4 SU | 8 SU | 12 SU | 16 SU | 24 SU | 該当なし |
| 5 つのレプリカ | 5 SU | 10 SU | 15 SU | 20 SU | 30 SU | 該当なし |
| 6 つのレプリカ | 6 SU | 12 SU | 18 SU | 24 SU | 36 SU | 該当なし |
| 12 レプリカ | 12 SU | 24 SU | 36 SU | 該当なし | 該当なし | 該当なし |
SU、価格、および容量の詳細については、Azure Web サイトをご覧ください。 詳細については、「料金の詳細」をご覧ください。
Note
レプリカとパーティションの数は、均等に 12 分割されます (具体的には、1、2、3、4、6、12)。 Azure AI Search では各インデックスを 12 のシャードに事前に分割して、それぞれがすべてのパーティションに均等に分散されるようにします。 たとえば、サービスに 3 つのパーティションがあり、インデックスを作成する場合、各パーティションにはインデックスの 4 つのシャードを含めます。 Azure AI Search でインデックスがどのようにシャードされるかは実装の詳細であり、今後のリリースで変更される場合があります。 今日 12 個であっても、今後も必ず 12 個になるとは限りません。