Azure Search でクエリとインデックス作成のワークロードに応じてパーティションとレプリカをスケーリングするScale partitions and replicas for query and indexing workloads in Azure Search

価格レベルを選択して Search サービスをプロビジョニングしたら、サービスで使用するレプリカまたはパーティションの数を必要に応じて増やします。After you choose a pricing tier and provision a search service, the next step is to optionally increase the number of replicas or partitions used by your service. 各レベルには固定された請求単位数が用意されています。Each tier offers a fixed number of billing units. この記事では、こうした請求単位を、クエリの実行、インデックス作成、およびストレージの要件のバランスを考慮しながら割り当てて、最適な構成を実現する方法について説明します。This article explains how to allocate those units to achieve an optimal configuration that balances your requirements for query execution, indexing, and storage.

Basic レベル、または Standard レベルと Storage Optimized レベルの 1 つでサービスを設定すると、リソース構成を使用できます。Resource configuration is available when you set up a service at the Basic tier or one of the Standard or Storage Optimized tiers. このレベルのサービスでは、容量は "検索単位" (SU) ごとに購入します。各パーティションとレプリカは 1 SU としてカウントします。For services at these tiers, capacity is purchased in increments of search units (SUs) where each partition and replica counts as one SU.

使用する SU が少なければ、課金される金額もそれに応じて少なくなります。Using fewer SUs results in a proportionally lower bill. 課金は、サービスが設定されている間、有効になっています。Billing is in effect for as long as the service is set up. サービスを一時的に使用しない場合、課金を回避する唯一の方法は、サービスを削除し、必要なときに再作成することです。If you are temporarily not using a service, the only way to avoid billing is by deleting the service and then re-creating it when you need it.

注意

サービスを削除すると、すべての機能が削除されます。Deleting a service deletes everything on it. 保持されている検索データをバックアップおよび復元するための機能は Azure Search 内にありません。There is no facility within Azure Search for backing up and restoring persisted search data. 新しいサービスに既存のインデックスを再デプロイするには、元々その作成と読み込みに使用したプログラムを実行する必要があります。To redeploy an existing index on a new service, you should run the program used to create and load it originally.

用語: レプリカとパーティションTerminology: replicas and partitions

レプリカとパーティションは、検索サービスを支える主要なリソースです。Replicas and partitions are the primary resources that back a search service.

ResourceResource 定義Definition
パーティションPartitions 読み取り/書き込み操作 (たとえば、インデックスを再構築または更新する場合など) のためにインデックスのストレージと I/O を提供します。Provides index storage and I/O for read/write operations (for example, when rebuilding or refreshing an index).
"レプリカ"Replicas 主にクエリ操作の負荷分散に使用される Search サービスのインスタンスです。Instances of the search service, used primarily to load balance query operations. 各レプリカが常にインデックスの 1 つのコピーをホストします。Each replica always hosts one copy of an index. 12 個のレプリカがある場合は、サービスに各インデックスのコピーが 12 個ずつ読み込まれます。If you have 12 replicas, you will have 12 copies of every index loaded on the service.

注意

レプリカでどのインデックスが実行されるかを直接操作または管理する方法はありません。There is no way to directly manipulate or manage which indexes run on a replica. すべてのレプリカにある各インデックスの 1 つずつのコピーが、サービスのアーキテクチャを構成します。One copy of each index on every replica is part of the service architecture.

レプリカとパーティションを割り当てる方法How to allocate replicas and partitions

Azure Search では最初に、1 つのパーティションと 1 つのレプリカで構成される最小限のリソースがサービスに割り当てられます。In Azure Search, a service is initially allocated a minimal level of resources consisting of one partition and one replica. 該当するレベルでサポートされている場合は、コンピューティング リソースを段階的に調整できます。より多くのストレージや I/O が必要な場合には、パーティションを増やします。また、より多くのクエリを実行したり、パフォーマンスを向上させたりするには、レプリカをさらに増やします。For tiers that support it, you can incrementally adjust computational resources by increasing partitions if you need more storage and I/O, or add more replicas for larger query volumes or better performance. 1 つのサービスに、すべてのワークロード (インデックスおよびクエリ) を処理するための十分なリソースが必要です。A single service must have sufficient resources to handle all workloads (indexing and queries). 複数のサービス間でワークロードを分割することはできません。You cannot subdivide workloads among multiple services.

レプリカやパーティションの割り当てを増やしたり変更したりする場合は、Azure Portal の使用をお勧めします。To increase or change the allocation of replicas and partitions, we recommend using the Azure portal. ポータルでは、上限に達しないようにするための許容される組み合わせに強制的に制限されます。The portal enforces limits on allowable combinations that stay below maximum limits. スクリプト ベースまたはコード ベースのプロビジョニング方法が必要な場合は、代わりに Azure PowerShell または管理 REST API を使用します。If you require a script-based or code-based provisioning approach, the Azure PowerShell or the Management REST API are alternative solutions.

一般的に、検索アプリケーションでは、パーティションよりもレプリカの方が多く必要となります。特に、サービス操作でクエリ ワークロードの比重が高い場合は、その傾向が強まります。Generally, search applications need more replicas than partitions, particularly when the service operations are biased toward query workloads. その理由については、高可用性に関するセクションで説明します。The section on high availability explains why.

  1. Azure Portal にサインインし、Search サービスを選択します。Sign in to the Azure portal and select the search service.

  2. [設定] で、 [スケール] ページを開いてレプリカとパーティションの数を変更します。In Settings, open the Scale page to modify replicas and partitions.

    次のスクリーンショットは、1 つのレプリカとパーティションでプロビジョニングされる標準のサービスを示しています。The following screenshot shows a standard service provisioned with one replica and partition. 下部の式は、使用される検索ユニットの数 (1) を示しています。The formula at the bottom indicates how many search units are being used (1). ユニットの価格が 100 ドル (実際の価格ではありません) の場合、このサービスを実行するための毎月のコストは平均 100 ドルになります。If the unit price was $100 (not a real price), the monthly cost of running this service would be $100 on average.

    現在の値が表示された [スケール] ページScale page showing current values

  3. スライダーを使ってパーティションの数を増減します。Use the slider to increase or decrease the number of partitions. 下部の式は、使用される検索ユニットの数を示しています。The formula at the bottom indicates how many search units are being used.

    この例では、レプリカとパーティションがそれぞれ 2 つに設定されており、容量が 2 倍になります。This example doubles capacity, with two replicas and partitions each. 請求の計算式では、レプリカ数とパーティション数が乗算されるため (2 x 2)、検索ユニット数が 4 になっていることに注意してください。Notice the search unit count; it is now four because the billing formula is replicas multiplied by partitions (2 x 2). 容量を 2 倍にすると、サービスを実行するためのコストが 2 倍以上になります。Doubling capacity more than doubles the cost of running the service. 検索ユニットのコストが 100 ドルの場合、新しい毎月の請求額は 400 ドルになります。If the search unit cost was $100, the new monthly bill would now be $400.

    各レベルの現在のユニットあたりのコストについては、価格のページをご覧ください。For the current per unit costs of each tier, visit the Pricing page.

    レプリカとパーティションの追加Add replicas and partitions

  4. [保存] をクリックして変更を確認します。Click Save to confirm the changes.

    スケールと請求の変更の確認Confirm changes to scale and billing

    容量の変更が完了するまでに数時間かかります。Changes in capacity take several hours to complete. プロセスが開始されたらキャンセルすることはできません。また、レプリカとパーティションの調整のリアルタイムの監視はありません。You cannot cancel once the process has started and there is no real-time monitoring for replica and partition adjustments. ただし、変更が行われている間、次のメッセージが常に表示されています。However, the following message remains visible while changes are underway.

    ポータルの状態メッセージStatus message in the portal

注意

サービスをプロビジョニングした後は、上位の SKU にアップグレードすることはできません。After a service is provisioned, it cannot be upgraded to a higher SKU. 新しいレベルで Search Service を作成し、インデックスを再度読み込む必要があります。You must create a search service at the new tier and reload your indexes. サービス プロビジョニングについては、「 ポータルでの Azure Search サービスの作成 」を参照してください。See Create an Azure Search service in the portal for help with service provisioning.

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

Basic サービスは、3 SU の上限に対して厳密に 1 個のパーティションと最大 3 個のレプリカを持つことができます。A Basic service can have exactly one partition and up to three replicas, for a maximum limit of three SUs. 調整可能なリソースはレプリカだけです。The only adjustable resource is replicas. クエリの高可用性のためには、少なくとも 2 個のレプリカが必要です。You need a minimum of two replicas for high availability on queries.

すべての Standard および Storage Optimized 検索サービスでは、36 SU の制限のもとで、レプリカとパーティションの次の組み合わせを想定できます。All Standard and Storage Optimized search services can assume the following combinations of replicas and partitions, subject to the 36-SU limit.

1 個のパーティション1 partition 2 個のパーティション2 partitions 3 個のパーティション3 partitions 4 個のパーティション4 partitions 6 個のパーティション6 partitions 12 個のパーティション12 partitions
1 つのレプリカ1 replica 1 SU1 SU 2 SU2 SU 3 SU3 SU 4 SU4 SU 6 SU6 SU 12 SU12 SU
2 つのレプリカ2 replicas 2 SU2 SU 4 SU4 SU 6 SU6 SU 8 SU8 SU 12 SU12 SU 24 SU24 SU
3 つのレプリカ3 replicas 3 SU3 SU 6 SU6 SU 9 SU9 SU 12 SU12 SU 18 SU18 SU 36 SU36 SU
4 つのレプリカ4 replicas 4 SU4 SU 8 SU8 SU 12 SU12 SU 16 SU16 SU 24 SU24 SU 該当なしN/A
5 つのレプリカ5 replicas 5 SU5 SU 10 SU10 SU 15 SU15 SU 20 SU20 SU 30 SU30 SU 該当なしN/A
6 つのレプリカ6 replicas 6 SU6 SU 12 SU12 SU 18 SU18 SU 24 SU24 SU 36 SU36 SU 該当なしN/A
12 レプリカ12 replicas 12 SU12 SU 24 SU24 SU 36 SU36 SU 該当なしN/A 該当なしN/A 該当なしN/A

SU、価格、および容量の詳細については、Azure Web サイトをご覧ください。SUs, pricing, and capacity are explained in detail on the Azure website. 詳細については、「料金の詳細」をご覧ください。For more information, see Pricing Details.

注意

レプリカとパーティションの数は、均等に 12 分割されます (具体的には、1、2、3、4、6、12)。The number of replicas and partitions divides evenly into 12 (specifically, 1, 2, 3, 4, 6, 12). これは、Azure Search では各インデックスがすべてのパーティションに均等に分散されるように 12 のシャードに事前に分割されるためです。This is because Azure Search pre-divides each index into 12 shards so that it can be spread in equal portions across all partitions. たとえば、サービスに 3 つのパーティションがあり、インデックスを作成する場合、各パーティションにはインデックスの 4 つのシャードを含めます。For example, if your service has three partitions and you create an index, each partition will contain four shards of the index. Azure Search でインデックスがどのようにシャードされるかは実装の問題であり、今後のリリースで変更される場合があります。How Azure Search shards an index is an implementation detail, subject to change in future releases. 今日 12 個であっても、今後も必ず 12 個になるとは限りません。Although the number is 12 today, you shouldn't expect that number to always be 12 in the future.

高可用性High availability

通常、簡単かつ比較的速くスケールアップできるため、1 つのパーティションと 1 ~ 2 つのレプリカで開始し、クエリ数の増加に合わせてスケールアップすることをお勧めします。Because it's easy and relatively fast to scale up, we generally recommend that you start with one partition and one or two replicas, and then scale up as query volumes build. クエリのワークロードは主にレプリカ上で実行されます。Query workloads run primarily on replicas. より高いスループットまたは高可用性のためには、レプリカの追加が必要となります。If you need more throughput or high availability, you will probably require additional replicas.

高可用性のための一般的な推奨事項は次のとおりです。General recommendations for high availability are:

  • 読み取り専用ワークロード (クエリ) の高可用性を実現するには 2 つのレプリカTwo replicas for high availability of read-only workloads (queries)

  • 読み取り/書き込みワークロード (クエリに加え、個々のドキュメントを追加、更新、または削除するときのインデックス作成) の高可用性を実現するには 3 つ以上のレプリカThree or more replicas for high availability of read/write workloads (queries plus indexing as individual documents are added, updated, or deleted)

Azure Search のサービス レベル アグリーメント (SLA) は、クエリ操作と、ドキュメントの追加、更新、削除から成るインデックスの更新とを対象としています。Service level agreements (SLA) for Azure Search are targeted at query operations and at index updates that consist of adding, updating, or deleting documents.

Basic レベルでは、1 つのパーティションと 3 つのレプリカが上限です。Basic tier tops out at one partition and three replicas. インデックス作成とクエリのスループットに対する需要の変動にすばやく反応する柔軟性が必要な場合は、Standard レベルのいずれかを検討してください。If you want the flexibility to immediately respond to fluctuations in demand for both indexing and query throughput, consider one of the Standard tiers. ストレージ要件がクエリ スループットよりもはるかに速く増大している場合は、Storage Optimized レベルの 1 つを検討します。If you find your storage requirements are growing much more rapidly than your query throughput, consider one of the Storage Optimized tiers.

再構築中のインデックスの可用性Index availability during a rebuild

Azure Search の高可用性は、クエリのほか、インデックスの再構築を伴わないインデックスの更新に関連しています。High availability for Azure Search pertains to queries and index updates that don't involve rebuilding an index. フィールドの削除、データ型の変更、フィールドの名前の変更を行う場合は、インデックスの再構築が必要になります。If you delete a field, change a data type, or rename a field, you will need to rebuild the index. インデックスを再構築するには、いったんインデックスを削除した後、インデックスを再作成し、データを再読み込みする必要があります。To rebuild the index, you must delete the index, re-create the index, and reload the data.

注意

Azure Search インデックスへの新しいフィールドの追加は、インデックスを再構築せずに行うことができます。You can add new fields to an Azure Search index without rebuilding the index. 既にインデックス内にあるすべてのドキュメントについては、新しいフィールドの値は null になります。The value of the new field will be null for all documents already in the index.

再構築中にインデックスの可用性を維持するには、同じサービスに対してインデックスのコピーを別の名前で用意するか、別のサービスに対してインデックスのコピーを同じ名前で用意したうえで、コードにリダイレクトまたはフェールオーバーのロジックを記述する必要があります。To maintain index availability during a rebuild, you must have a copy of the index with a different name on the same service, or a copy of the index with the same name on a different service, and then provide redirection or failover logic in your code.

障害復旧Disaster recovery

現時点では、障害復旧のための組み込みのメカニズムはありません。Currently, there is no built-in mechanism for disaster recovery. 追加のパーティションまたはレプリカは、ディザスター リカバリーの目標を達成する手段として適切ではありません。Adding partitions or replicas would be the wrong strategy for meeting disaster recovery objectives. 最も一般的なアプローチでは、別のリージョンにもう 1 つの検索サービスを設定することで、そのサービス レベルに冗長性を追加します。The most common approach is to add redundancy at the service level by setting up a second search service in another region. インデックスの再構築中の可用性の場合と同様に、リダイレクトまたはフェールオーバーのロジックをコードに用意する必要があります。As with availability during an index rebuild, the redirection or failover logic must come from your code.

レプリカでクエリ パフォーマンスを向上させるIncrease query performance with replicas

クエリの遅延は、追加のレプリカが必要かどうかの指標となります。Query latency is an indicator that additional replicas are needed. 通常、クエリ パフォーマンスを向上させるには、まずこのリソースを追加します。Generally, a first step toward improving query performance is to add more of this resource. レプリカを追加すると、インデックスの追加のコピーがオンラインになって、より多くのクエリ ワークロードに対応し、複数のレプリカ全体の要求を負荷分散できるようになります。As you add replicas, additional copies of the index are brought online to support bigger query workloads and to load balance the requests over the multiple replicas.

クエリ パフォーマンスは、クエリの複雑さや競合するワークロードに左右されるため、1 秒あたりのクエリ数 (QPS) を正確に提示できません。We cannot provide hard estimates on queries per second (QPS): query performance depends on the complexity of the query and competing workloads. レプリカを追加するとパフォーマンスが向上しますが、厳密に線形に向上するわけではありません。3 つのレプリカを追加しても、スループットが 3 倍になるとは限りません。Although adding replicas clearly results in better performance, the result is not strictly linear: adding three replicas does not guarantee triple throughput.

ワークロードの QPS を見積もる際のガイダンスについては、「Azure Search のパフォーマンスと最適化に関する考慮事項」を参照してください。For guidance in estimating QPS for your workloads, see Azure Search performance and optimization considerations.

パーティションでインデックス作成のパフォーマンスを向上させるIncrease indexing performance with partitions

ほぼリアルタイムのデータ更新を要求する検索アプリケーションでは、レプリカよりも多くのパーティションが比例して必要になります。Search applications that require near real-time data refresh will need proportionally more partitions than replicas. パーティションを追加すると、読み取り/書き込み操作がより多くのコンピューティング リソースに分散されます。Adding partitions spreads read/write operations across a larger number of compute resources. また、追加のインデックスとドキュメントを格納するためのディスク領域も増加します。It also gives you more disk space for storing additional indexes and documents.

インデックスが大きくなると、クエリの実行に時間がかかります。Larger indexes take longer to query. そのため、パーティションで段階的な増加が発生するたびに、レプリカでは小規模であるが比例的な増加が必要となる場合があります。As such, you might find that every incremental increase in partitions requires a smaller but proportional increase in replicas. クエリの複雑さとボリュームは、クエリの実行が完了するまでの速度の要因となります。The complexity of your queries and query volume will factor into how quickly query execution is turned around.

次の手順Next steps

Azure Search の価格レベルの選択Choose a pricing tier for Azure Search