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

検索サービスを作成し、特定の価格レベルを確定する前に、容量のしくみと、ワークロードの変動に対応するためのレプリカとパーティションの調整方法について少し時間を取って理解しておいてください。

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

処理速度やディスク IO など、レプリカとパーティションの物理的な特性は、サービス レベルによって異なります。 Standard でプロビジョニングした場合、レプリカとパーティションが Basic の場合よりも高速で大きくなります。

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

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

概念: 検索単位、レプリカ、パーティション、シャード

容量は、パーティションレプリカの組み合わせで割り当てられる検索単位で表され、基になるシャーディング メカニズムを使用して柔軟な構成をサポートします。

概念 定義
検索単位 使用可能な合計容量の単一増分 (36 ユニット)。 Azure Cognitive Search サービスの課金単位でもあります。 サービスを実行するには、少なくとも 1 つの単位が必要です。
[レプリカ] 主にクエリ操作の負荷分散に使用される Search サービスのインスタンスです。 各レプリカは、インデックスの 1 つのコピーをホストします。 3 つのレプリカを割り当てると、クエリ要求のサービスに使用できるインデックスのコピーが3つ作成されます。
パーティション 読み取り/書き込み操作 (たとえば、インデックスを再構築または更新する場合など) のための物理ストレージと I/O。 各パーティションにインデックス全体のスライスがあります。 3 つのパーティションを割り当てると、インデックスは 3 つに分割されます。
シャード インデックスのチャンク。 Azure Cognitive Search は、各インデックスをシャードに分割し、(シャードを新しい検索単位に移動することによって) パーティションを追加するプロセスを高速化しています。

次の図は、レプリカ、パーティション、シャード、および検索単位間の関係を示しています。 ここでは、2 つのレプリカと 2 つのパーティションを持つサービスで、どのように 1 つのインデックスが 4 つの検索単位にわたっているかを例で示しています。 4 つの検索単位それぞれには、インデックスのシャードの半分だけが格納されます。 左側の列の検索単位は、シャードの前半を格納して最初のパーティションを構成し、右側の列の検索単位は、シャードの後半を格納して 2 番目のパーティションを構成しています。 レプリカが 2 つあるため、各インデックス シャードのコピーは 2 つあります。 上部の行の検索単位は、1 つのコピーを格納して最初のレプリカを構成し、下部の行の検索単位は、別のコピーを格納して 2 番目のレプリカを構成しています。

検索インデックスはパーティション間でシャード化されます。

上の図は 1 つの例にすぎません。 パーティションとレプリカはさまざまに組み合わせることができ、最大で合計 36 の検索単位が可能です。

Cognitive Search では、シャード管理は実装の詳細であり、構成できませんが、インデックスがシャード化されているとわかっていれば、順位付けやオートコンプリートの動作で不定期に発生する異常を理解する場合に役立ちます。

  • 順位付けの異常:検索スコアは最初にシャード レベルで計算され、続いて単位の結果セットに集計されます。 シャード コンテンツの特性に応じて、あるシャードからの一致が別のシャードの一致よりも高い順位になる場合があります。 検索結果の順位付けが直観に反していることに気付いた場合は、シャーディングの影響が原因である可能性が最も高いです (特にインデックスが小さい場合)。 インデックス全体でグローバルにスコアを計算するように選択すれば、これらの順位付けの異常を回避できますが、その場合、パフォーマンスが低下します。

  • オートコンプリートの異常:オートコンプリート クエリでは、部分的に入力された語句の最初のいくつかの文字で照合が行われますが、スペルの少しの間違いを許容するあいまいパラメーターが使用されます。 オートコンプリートの場合、あいまい一致は現在のシャード内の用語に限定されます。 たとえば、シャードに "Microsoft" が含まれており、"micor" という部分的な語句が入力された場合、検索エンジンはそのシャード内の "Microsoft" と一致しますが、インデックスの残りの部分を保持した他のシャードでは一致しません。

見積もりへの取り組み

容量とサービスの実行コストは密接に関係しています。 サービス レベルにより、ストレージとコンテンツ (サービスのインデックスの数など) の 2 つのレベルで制限が課されます。 先に上限に達した方が実質的な制限になるため、両方を考慮することが重要です。

インデックスとその他のオブジェクトの数は、通常、ビジネスおよびエンジニアリングの要件によって決まります。 たとえば、アクティブな開発、テスト、および運用において、同じインデックスの複数のバージョンを保持する場合があります。

ストレージのニーズは、構築する予定のインデックスのサイズによって決まります。 見積もりに役立つような、信頼できる経験則や一般原則はありません。 インデックスのサイズを見極める唯一の方法は、1 つ構築することです。 そのサイズは、インポートされたデータ、テキスト分析、およびインデックス構成 (suggester、フィルタリング、並べ替えを有効にするかどうかなど) に基づきます。

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

フィルターや並べ替えを有効にするなど、インデックスの属性はストレージの要件に影響を与えます。 suggester の使用も、ストレージに影響します。 詳細については、属性とインデックス サイズに関する記事を参照してください。

注意

インデックスとストレージの将来のニーズの見積もりは、当て推量のように感じられるかもしれませんが、行う価値があります。 あるレベルの容量が少なすぎることがわかった場合は、それより上のレベルで新しいサービスをプロビジョニングしたうえで、インデックスを再読み込みする必要があります。 特定のレベルから別のレベルへのサービスのインプレース アップグレードを実行することはできません。

Free レベルでの見積もり

容量を見積もる方法の 1 つは、まず Free レベルを使用することです。 Free サービスでは、最大 3 つのインデックス、50 MB のストレージ、および 2 分間のインデックス作成時間が提供されます。 これらの制約の中で予想インデックス サイズを見積もることは簡単ではない可能性がありますが、その手順は次のとおりです。

  • Free サービスを作成します。

  • 小さな代表的なデータセットを準備します。

  • インデックスを作成し、データを読み込みます。 インデクサーでサポートされている Azure データ ソース内でデータセットをホストできる場合は、ポータルにあるデータのインポート ウィザードを使用して、インデックスの作成と読み込みの両方を行うことができます。 それ以外の場合は、REST と Postman を使ってインデックスを作成し、データをプッシュできます。 プッシュ モデルでは、データを JSON ドキュメントの形式にする必要があります。そのドキュメント内のフィールドは、インデックス内のフィールドに対応します。

  • インデックスに関する情報 (サイズなど) を収集します。 機能と属性はストレージに影響を与えます。 たとえば、suggester (Search-as-you-type クエリ) を追加すると、ストレージ要件が増加します。

    同じデータ セットを使用する場合、各フィールドに異なる属性を設定してインデックスの複数のバージョンを作成し、ストレージ要件がどのように変化するかを確認してみてください。 詳細については、基本的なインデックスの作成に関するページの「ストレージへの影響」を参照してください。

大まかな見積もりが得られたら、2 つのインデックス (開発用と運用用) の量を予測するためにこの値を 2 倍にし、それに応じてレベルを選択します。

課金対象レベルでの見積もり

専用のリソースでは、より長いサンプリングと処理時間に対応でき、開発段階でのインデックスの量、サイズ、クエリ量についてより現実的な見積もりを求めることができます。 課金対象のレベルから始め、開発プロジェクトが成熟するのに応じて再評価するお客様もいます。

  1. 各レベルのサービス制限を確認して、より低いレベルで、必要なインデックス数に対応できるかどうかを判断してください。 Basic、S1、S2 レベルでのインデックス制限は、それぞれ 15、50、200 です。 Storage Optimized レベルは、少数の非常に大きいインデックスをサポートするように設計されているため、10 インデックスに制限されています。

  2. 課金対象レベルでサービスを作成します

    • 予想される負荷がわからない場合は、Basic または S1 の低いレベルで始めます。
    • テストに大規模なインデックス作成とクエリの負荷が含まれている場合は、S2 または S3 の高レベルから始めます。
    • 社内のビジネス アプリケーションのように、インデックスを付けるデータの量が多く、クエリの負荷が比較的低い場合は、Storage Optimized (L1 または L2) から始めます。
  3. 最初のインデックスを構築して、ソース データがどのようにインデックスに変換されるかを特定します。 これは、インデックスのサイズを推測する唯一の方法です。

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

  5. 高可用性が必要な場合や、クエリ パフォーマンスの低下が発生する場合は、レプリカを追加します。

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

注意

検索されることのないデータが含まれていると、ストレージの要件が増大することがあります。 ドキュメントには、検索機能に必要なデータのみが含まれていることが理想的な状態です。 バイナリ データは検索できないため、別途保存する必要があります (おそらく Azure テーブルまたは BLOB ストレージに)。 その後、外部データへの URL 参照を保持するためのフィールドをインデックスに追加する必要があります。 個々の検索ドキュメントの最大サイズは 16 MB です (1 回の要求で複数のドキュメントを一括アップロードする場合は、それより小さくなります)。 詳細については、Azure Cognitive Search サービスの制限に関する記事を参照してください。

クエリ数に関する考慮事項

クエリ/秒 (QPS) は、パフォーマンスのチューニング中の重要なメトリックですが、一般に、最初からクエリ数が多いことが予想される場合は、レベルに関する考慮事項に過ぎません。

Standard レベルでは、レプリカとパーティションのバランスを取ることができます。 負荷分散用のレプリカを追加したり、並列処理用のパーティションを追加したりすることで、クエリのターンアラウンドを向上させることができます。 その後、サービスがプロビジョニングされた後に、パフォーマンスをチューニングできます。

最初から大量のクエリ数が継続することが予想される場合は、より強力なハードウェアを使用する、より高い Standard レベルを検討してください。 その後、これらのクエリ数が発生しなかった場合は、パーティションとレプリカをオフラインにするか、より低いレベルのサービスに切り替えることができます。 クエリ スループットの計算方法の詳細については、Azure Cognitive Search のパフォーマンスと最適化に関する記事を参照してください。

Storage Optimized レベルは、大規模なデータ ワークロードに適しており、クエリの待ち時間要件がそれほど重要でない場合に、より全体的に利用可能なインデックス ストレージをサポートします。 それでも、負荷分散のためにはレプリカを追加し、並列処理のためにはパーティションを追加する必要があります。 その後、サービスがプロビジョニングされた後に、パフォーマンスをチューニングできます。

サービスレベル アグリーメント

Free レベルおよびプレビュー機能は、サービス レベル アグリーメント (SLA) の対象ではありません。 課金対象のすべてのレベルで、SLA が有効になるのは、サービスにとって十分な冗長性がプロビジョニングされるときです。 クエリ (読み取り) の SLA には複数のレプリカが必要です。 クエリとインデックス作成 (読み取り/書き込み) の SLA には 3 つ以上のレプリカが必要です。 パーティションの数は、SLA に影響しません。

容量計画に関するヒント

  • クエリに関するメトリックを構築し、利用パターン (業務時間中のクエリ数、オフピーク時のインデックス作成) に関するデータを収集します。 このデータを使用して、サービス プロビジョニングに関する決定に役立つ情報を提供します。 時間ごと、または毎日の周期では実用的でありませんが、パーティションやリソースを動的に調節して、クエリ数の計画された変化に対応できます。 計画外ではあっても持続した変化に対応することもできます。ただし、対処する間、そのレベルが保持される場合です。

  • 過小なプロビジョニングの唯一の欠点として、実際の要件が予測より大きかった場合にサービスを中断する必要があるということに注意してください。 サービスの中断を回避するには、より高いレベルで新しいサービスを作成し、すべてのアプリと要求が新しいエンドポイントを指すようになるまで並行して実行します。

容量をいつ追加するか

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

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

容量を追加するかどうかを判断するためのガイドラインを次に示します。

  • サービス レベル アグリーメントの高可用性条件を満たす
  • HTTP 503 エラーの頻度が増加している
  • 大規模なクエリ ボリュームが想定される

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

ほぼリアルタイムのデータ更新を要求する検索アプリケーションでは、レプリカよりも多くのパーティションが比例して必要になります。 パーティションを追加すると、読み取り/書き込み操作がより多くのコンピューティング リソースに分散されます。 また、追加のインデックスとドキュメントを格納するためのディスク領域も増加します。

最後に、インデックスが大きくなると、クエリの実行に時間がかかります。 そのため、パーティションで段階的な増加が発生するたびに、レプリカでは小規模であるが比例的な増加が必要となる場合があります。 クエリの複雑さとボリュームは、クエリの実行が完了するまでの速度の要因となります。

注意

レプリカやパーティションを追加すると、サービスの実行コストが増加し、結果の並べ替え方法が少し変化する可能性があります。 ノードを追加した場合の課金の影響を理解するには、料金計算ツール を必ず確認してください。 下のグラフは、特定の構成に必要な検索単位の数を相互参照するのに役立ちます。 レプリカの追加によるクエリ処理への影響について詳しくは、「結果の並べ替え」をご覧ください。

レプリカとパーティションの追加または削減

  1. Azure Portal にサインインし、Search サービスを選択します。

  2. [設定] で、 [スケール] ページを開いてレプリカとパーティションの数を変更します。

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

    現在の値が表示されている [スケール] ページ

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

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

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

    レプリカとパーティションの追加

  4. 保存した後、通知を確認して、操作が成功したことを確認できます。

    変更を保存

    容量の変更が完了するまでに 15 分から最大で数時間かかることがあります。 プロセスが開始されたらキャンセルすることはできません。また、レプリカとパーティションの調整のリアルタイムの監視はありません。 ただし、変更が行われている間、次のメッセージが常に表示されています。

    ポータルのステータス メッセージ

注意

サービスをプロビジョニングした後は、上位のレベルにアップグレードすることはできません。 新しいレベルで Search Service を作成し、インデックスを再度読み込む必要があります。 サービス プロビジョニングについては、ポータルで Azure Cognitive Search サービスの作成に関する記事を参照してください。

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

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

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

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

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

スケーリング中のエラー

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

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

  1. 管理 REST APIAzure PowerShell 、またはAzure CLI を使用してサービス ステータスを取得します。
  2. Get サービスを呼び出します。
  3. 応答を調べて、"provisioningState": "provisioning" を確認します。

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

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

Basic サービスは、3 SU の上限に対して厳密に 1 個のパーティションと最大 3 個のレプリカを持つことができます。 調整可能なリソースはレプリカだけです。 クエリの高可用性のためには、少なくとも 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 サイトをご覧ください。 詳細については、「料金の詳細」をご覧ください。

注意

レプリカとパーティションの数は、均等に 12 分割されます (具体的には、1、2、3、4、6、12)。 Azure Cognitive Search では各インデックスを 12 のシャードに事前に分割して、それぞれがすべてのパーティションに均等に分散されるようにします。 たとえば、サービスに 3 つのパーティションがあり、インデックスを作成する場合、各パーティションにはインデックスの 4 つのシャードを含めます。 Azure Cognitive Search でインデックスがどのようにシャードされるかは実装の問題であり、今後のリリースで変更される場合があります。 今日 12 個であっても、今後も必ず 12 個になるとは限りません。

次のステップ