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

Azure Search サービスを作成すると、サービスの有効期間にわたって固定される価格レベル (つまり SKU) でリソースが作成されます。When you create an Azure Search service, a resource is created at a pricing tier (or SKU) that's fixed for the lifetime of the service. レベルには、Free、Basic、Standard、および Storage Optimized があります。Tiers include Free, Basic, Standard, and Storage Optimized. Standard と Storage Optimized は、いくつかの構成および容量で利用できます。Standard and Storage Optimized are available with several configurations and capacities.

ほとんどのお客様は、サービスを評価できるように、Free レベルから始めます。Most customers start with the Free tier so they can evaluate the service. 評価後には、開発および運用環境用のデプロイのために上位レベルのいずれかに 2 つ目のサービスを作成するのが一般的です。Post-evaluation, it's common to create a second service at one of the higher tiers for development and production deployments. すべてのクイック スタートとチュートリアルは、リソースを集中的に使用するコグニティブ検索に関するものも含めて、Free レベルを利用して実行できます。You can complete all quickstarts and tutorials by using the Free tier, including the ones for resource-intensive cognitive search.

注意

7 月 1 日時点で、すべてのレベルは、ストレージ最適化レベルを含め、一般的に利用できます。As of July 1, all tiers are generally available, including the Storage Optimized tier. すべての価格は、価格の詳細に関するページを参照してください。All pricing can be found on the Pricing Details page.

レベルは (機能ではなく) サービスをホストしているハードウェアの特性を反映していて、以下によって差別化されています。Tiers reflect the characteristics of the hardware hosting the service (rather than features) and are differentiated by:

  • 作成可能なインデックスの数。The number of indexes you can create.
  • パーティション (物理ストレージ) のサイズと速度。The size and speed of partitions (physical storage).

一般に、Free レベルを含むすべてのレベルで機能パリティが提供されますが、ワークロードが大きいほど、より高いレベルが必要になる可能性があります。Although all tiers, including the Free tier, generally offer feature parity, larger workloads can dictate a need for higher tiers. たとえば、Cognitive Services を利用した AI エンリッチメントには、データセットのサイズが小さい場合を除いて Free サービスではタイムアウトになってしまう、実行時間の長いスキルがあります。For example, AI enrichment with Cognitive Services has long-running skills that time out on a free service unless the dataset is small.

注意

機能パリティの例外はインデクサーで、これは S3 HD では利用できません。The exception to feature parity is indexers, which are not available on S3 HD.

レベル内では、レプリカとパーティションのリソースを調整することによって、スケールを大きくしたり小さくしたりできます。Within a tier, you can adjust replica and partition resources to increase or decrease scale. それぞれ 1、2 個から始めて、大きなインデックス作成ワークロード用に一時的に計算能力を高めることができます。You could start with one or two of each and then temporarily raise your computational power for a heavy indexing workload. レベル内でリソース レベルを調整する機能により、柔軟性が加わりますが、分析もやや複雑になります。The ability to tune resource levels within a tier adds flexibility, but also slightly complicates your analysis. 下位レベルでより多いリソースやレプリカを使用する方が、上位レベルでより少ないリソースを使用するよりも優れた値とパフォーマンスを得られるかどうかについて、確認する実験が必要になる可能性があります。You might have to experiment to see whether a lower tier with more resources/replicas offers better value and performance than a higher tier with fewer resources. 容量を調整するタイミングと理由の詳細については、「Azure Search のパフォーマンスと最適化に関する考慮事項」を参照してください。To learn more about when and why you would adjust capacity, see Performance and optimization considerations.

次の表は使用できるレベルの一覧です。The following table lists the available tiers. さまざまなレベルの詳細については、価格に関するページ、「Azure Search サービスの制限」、サービスのプロビジョニング時のポータル ページを参照してください。You can find out more about the various tiers on the pricing page, in the Service limits in Azure Search article, and on the portal page when you're provisioning a service.

レベルTier 容量Capacity
無料Free 他のサブスクライバーと共有されます。Shared with other subscribers. スケーラブルではありません。Not scalable. 3 つのインデックスと 50 MB のストレージまでに制限されています。Limited to three indexes and 50 MB of storage.
BasicBasic 小規模の運用ワークロードのための専用コンピューティング リソースです。Dedicated computing resources for production workloads at a smaller scale. 1 個の 2 GB パーティションと、最大 3 個のレプリカです。One 2-GB partition and up to three replicas.
Standard 1 (S1)Standard 1 (S1) S1 以上では、すべてのレベルでさらに多くのストレージや処理能力を持つ専用マシンです。For S1 and higher, dedicated machines with more storage and processing capacity at every level. S1 では、パーティション サイズは 25 GB/パーティション (サービスあたり最大 300 GB) です。For S1, partition size is 25 GB/partition (with a maximum of 300 GB per service).
Standard 2 (S2)Standard 2 (S2) S1 に似ていますが、100 GB パーティション (サービスあたり最大 1.2 TB) です。Similar to S1, but with 100-GB partitions (and a maximum of 1.2 TB per service).
Standard 3 (S3)Standard 3 (S3) 200 GB パーティション (サービスあたり最大 2.4 TB) です。200-GB partitions (with a maximum of 2.4 TB per service).
Standard 3 High Density (S3 HD)Standard 3 High Density (S3 HD) 高密度は、S3 用の "ホスティング モード" です。High density is a hosting mode for S3. 基になるハードウェアは多数の小さいインデックス用に最適化されており、マルチテナント シナリオ向けです。The underlying hardware is optimized for a large number of smaller indexes and is intended for multitenancy scenarios. S3 HD のユニットあたりの料金は S3 と同じですが、ハードウェアは数多くの小さいインデックスでの高速ファイル読み取り用に最適化されています。S3 HD has the same per-unit charge as S3, but the hardware is optimized for fast file reads on a large number of smaller indexes.
Storage Optimized 1 (L1)Storage Optimized 1 (L1) 1 TB パーティション (サービスあたり最大 12 TB) です。1-TB partitions (with a maximum of 12 TB per service).
Storage Optimized 2 (L2)Storage Optimized 2 (L2) 2 TB パーティション (サービスあたり最大 24 TB) です。2-TB partitions (with a maximum of 24 TB per service).

注意

Storage Optimized レベルでは、Standard レベルより安い TB あたりの価格で、大容量のストレージが提供されます。The Storage Optimized tiers offer larger storage capacity at a lower price per TB than the Standard tiers. 主なトレードオフとしてクエリの待ち時間が長くなるので、特定のアプリケーションの要件に対して妥当かどうかを確認する必要があります。The primary tradeoff is higher query latency, which you should validate for your specific application requirements. このレベルのパフォーマンスに関する考慮事項の詳細については、パフォーマンスと最適化の考慮事項に関するページを参照してください。To learn more about the performance considerations of this tier, see Performance and optimization considerations.

請求体系についてHow billing works

Azure Search でコストが発生する場合は 3 つあります。There are three ways to incur costs in Azure Search. このセクションでは、3 つの課金コンポーネントについて説明します。This section describes the three billing components:

  • コア サービス コストcore service cost
  • データ エグレス (または帯域幅) 料金data egress (or bandwidth) charges
  • AI エンリッチメントAI enrichments

コア サービスのコスト (固定および可変)Core service costs (fixed and variable)

サービス自体については、最低料金は最初の検索単位 (1 レプリカ x 1 パーティション) です。For the service itself, the minimum charge is the first search unit (1 replica x 1 partition). これより小さい構成ではサービスは実行できないため、この最低料金はサービスの有効期間を通して一定です。This minimum is fixed for the lifetime of the service because the service can't run on anything less than this configuration.

最小構成を超える場合は、レプリカとパーティションを個別に追加できます。Beyond the minimum, you can add replicas and partitions independently. たとえば、レプリカだけ、またはパーティションだけを追加できます。For example, you can add only replicas or only partitions. レプリカとパーティションによる容量の増分が、可変コストの構成要素となります。Incremental increases in capacity through replicas and partitions make up the variable cost component.

課金は、数式 (レプリカ数 x パーティション数 x レート) に基づきます。Billing is based on a formula (replicas x partitions x rate). 課金されるレートは、選択した価格レベルにより異なります。The rate you're charged depends on the pricing tier you select.

次のスクリーンショットは、Free、Basic、S1 のユニット単位価格を示したものですIn the following screenshot, per-unit pricing is indicated for Free, Basic, and S1. (S2、S3、L1、および L2 は示されていません)。Basic サービスを作成した場合、月間のコストは price-1 に表示される値の平均になります。(S2, S3, L1, and L2 aren't shown.) If you create a Basic service, your monthly cost will average the value that appears for price-1. Standard サービスの場合、月間のコストは price-2 に表示される値の平均になります。For a Standard service, your monthly cost will average the value that appears for price-2. レベルが上がるごとにコンピューティング能力とストレージ容量が大きくなるため、ユニット コストはレベルに従って増えます。Unit costs increase for each tier because the computational power and storage capacity is greater at each consecutive tier. Azure Search のレートは、Azure Search の価格のページでご覧いただけます。The rates for Azure Search are available on the Azure Search pricing page.

ユニットあたりの価格Per-unit pricing

検索ソリューションのコストを見積もる際には、価格と容量は直線的に比例するものではないことに注意してくださいWhen you're estimating the cost of a search solution, keep in mind that pricing and capacity aren't linear. (容量を 2 倍にすると、コストは 2 倍より多くなります)。数式による計算の例については、「レプリカとパーティションを割り当てる方法」を参照してください。(Doubling capacity more than doubles the cost.) For an example of how of the formula works, see How to allocate replicas and partitions.

検索ユニット数に基づく課金Billing based on search units

Azure Search の操作について理解するための最も重要な課金の概念は、"検索ユニット" (SU) です。The most important billing concept to understand for Azure Search operations is the search unit (SU). Azure Search は、インデックス作成とクエリについてレプリカとパーティションの両方に依存しているため、この片方のみを基準に課金しても意味がありません。Because Azure Search depends on both replicas and partitions for indexing and queries, it doesn't make sense to bill by just one or the other. このため、この両方を合わせた単位に基づいて課金されます。Instead, billing is based on a composite of both.

SU は、サービスによって使用される "レプリカ" と "パーティション" の積です (R x P = SU)SU is the product of the replicas and partitions used by a service: (R x P = SU).

すべてのサービスは、最小値として、1 SU (1 つのレプリカと 1 つのパーティションの積) から開始します。Every service starts with one SU (one replica multiplied by one partition) as the minimum. どのサービスも、最大値は 36 SU です。The maximum for any service is 36 SUs. この最大値に達するパターンは、いくつかあります。たとえば、6 パーティション x 6 レプリカ、3 パーティション x 12 レプリカなどです。This maximum can be reached in multiple ways: 6 partitions x 6 replicas, or 3 partitions x 12 replicas, for example. 一般には、総容量よりも少ない量を使用します (たとえば、3 レプリカと 3 パーティションのサービスで、9 SU の課金)。It's common to use less than total capacity (for example, a 3-replica, 3-partition service billed as 9 SUs). 有効な組み合わせについては、「パーティションとレプリカの組み合わせ」の表を参照してください。See the Partition and replica combinations chart for valid combinations.

課金レートは、SU ごとの 1 時間単位です。The billing rate is hourly per SU. レベルごとに、レートが高くなっていきます。Each tier has a progressively higher rate. レベルが高いほど、パーティションは大きく高速になり、そのレベルの時間あたりの料金が全体的に高くなります。Higher tiers come with larger and speedier partitions, and this contributes to an overall higher hourly rate for that tier. 各レベルのレートは、価格の詳細に関するページでご覧いただけます。You can view the rates for each tier on the pricing details page.

ほとんどのお客様は、総容量の一部だけをオンラインにし、残りを取っておきます。Most customers bring just a portion of total capacity online, holding the rest in reserve. 課金については、オンラインにするパーティションとレプリカの数 (SU 式を使用して計算) によって、時間単位で支払う金額が決まります。For billing, the number of partitions and replicas that you bring online, calculated by the SU formula, determines what you pay on an hourly basis.

インデックス作成時のデータ エグレス料金Data egress charges during indexing

Azure Search インデクサーを使用すると、サービスの場所によっては、課金に影響することがあります。Using Azure Search indexers might affect billing, depending on the location of your services. Azure Search サービスをデータと同じリージョンに作成すれば、データ エグレス料金が発生する事態を回避できます。You can eliminate data egress charges entirely if you create the Azure Search service in the same region as your data. 以下に、帯域幅の価格に関するページの情報の一部を示します。Here's some information from the bandwidth pricing page:

  • Azure 上のあらゆるサービスへのインバウンド データと、Azure Search からのアウトバウンド データには料金が課金されません。Microsoft doesn't charge for any inbound data to any service on Azure, or for any outbound data from Azure Search.

  • マルチサービス ソリューションでは、すべてのサービスが同じリージョンにあれば、伝送データに料金はかかりません。In multiservice solutions, there's no charge for data crossing the wire when all services are in the same region.

それらのサービスが別々のリージョンにある場合は、アウトバウンド データに料金が適用されます。Charges do apply for outbound data if services are in different regions. これらの料金は、実際には Azure Search の課金の一部ではありません。These charges aren't actually part of your Azure Search bill. データまたは AI によって強化されたインデクサーを使用して異なるリージョンからデータをプルする場合、それらのコストが全体の請求書に反映されるため、ここで言及しています。They're mentioned here because if you're using data or AI-enriched indexers to pull data from different regions, you'll see costs reflected in your overall bill.

Cognitive Services を使用する AI エンリッチメントAI enrichments with Cognitive Services

Cognitive Services を使用する AI エンリッチメントの場合は、従量課金制の処理について、有料の Azure Cognitive Services リソースを Azure Search と同じリージョンの S0 価格レベルにアタッチするように計画することをお勧めします。For AI enrichment with Cognitive Services, you should plan to attach a billable Azure Cognitive Services resource, in the same region as Azure Search, at the S0 pricing tier for pay-as-you-go processing. Cognitive Services のアタッチには、関連する固定コストはありません。There's no fixed cost associated with attaching Cognitive Services. 課金の対象となるのは、必要な処理の分だけです。You pay only for the processing you need.

ドキュメントの解析時の画像抽出は、Azure Search の課金対象です。Image extraction during document cracking is an Azure Search charge. ドキュメントから抽出された画像の数に基づいて課金されます。It's billed according to the number of images extracted from your documents. 現在、テキストの抽出は無料です。Text extraction is currently free.

自然言語処理など、他のエンリッチメントは組み込みのコグニティブ スキルに基づいており、Cognitive Services リソースに対して課金されます。Other enrichments, like natural language processing, are based on built-in cognitive skills and billed against a Cognitive Services resource. エンリッチメントは、Cognitive Services を直接使用してそのタスクを実行した場合と同じレートで課金されます。They're billed at the same rate as if you had performed the task by using Cognitive Services directly. 詳細については、Cognitive Services リソースをスキルセットにアタッチする方法に関するページを参照してください。For more information, see Attach a Cognitive Services resource with a skillset.

コグニティブ検索のインデックス作成パイプラインでファイルから画像を抽出する場合、Azure Search の請求書でその操作に対する料金が課金されます。If you extract images from files in a cognitive search indexing pipeline, you'll be charged for that operation in your Azure Search bill. インデクサー構成で、imageAction は、画像抽出をトリガーするパラメーターです。In an indexer configuration, imageAction is the parameter that triggers image extraction. imageAction が "none" (既定値) に設定されている場合、画像の抽出に対して課金されません。If imageAction is set to "none" (the default), you won't be charged for image extraction.

価格は変更されることがあります。Pricing is subject to change. Azure Search の価格の詳細に関するページに記載されています。It's documented on the pricing details page for Azure Search.

エンリッチメント パイプラインを設定すると、そのパイプラインで使用される組み込みスキルはすべて機械学習モデルに基づきます。When you set up an enrichment pipeline, any built-in skills used in the pipeline are based on machine learning models. これらのモデルは Cognitive Services に用意されています。These models are provided by Cognitive Services. インデックス作成時にこれらのモデルを使用すると、リソースを直接要求した場合と同じレートで課金されます。If you use these models during indexing, you'll be billed at the same rate as you would be if you requested the resource directly.

たとえば、スキャンされた JPEG ファイルに対して光学式文字認識 (OCR) を使用し、結果のテキストは自由形式の検索クエリのために Azure Search インデックスにプッシュされるパイプラインがあるとします。For example, say you have a pipeline that uses optical character recognition (OCR) against scanned JPEG files and the resulting text is pushed into an Azure Search index for free-form search queries. インデックス作成パイプラインには OCR スキルを持つインデクサーが含まれ、そのスキルが Cognitive Services リソースにアタッチされます。Your indexing pipeline would include an indexer with the OCR skill, and that skill would be attached to a Cognitive Services resource. インデクサーを実行すると、OCR の実行に関する料金は Cognitive Resources の請求書に記載されます。When you run the indexer, charges for OCR execution will appear on your Cognitive Resources bill.

コスト削減のためのヒントTips for reducing costs

課金を抑えるためにサービスをシャットダウンすることはできません。You can't shut down the service to reduce your bill. 専用リソースは常に動作し、サービスの有効期間中、お客様専用として割り当てられています。Dedicated resources are always operational, allocated for your exclusive use for the lifetime of your service. 課金を抑える唯一の方法は、レプリカとパーティションを、まだ許容可能なパフォーマンスと SLA コンプライアンスを提供する低いレベルに下げることです。The only way to lower your bill is to reduce replicas and partitions to a level that still provides acceptable performance and SLA compliance.

コストを削減する 1 つの手段は、時間あたりの料金が低いレベルを選択することです。One way to reduce costs is to choose a tier with a lower hourly rate. S1 の時間あたりの料金は S2 または S3 の料金よりも低くなります。S1 hourly rates are lower than S2 or S3 rates. 負荷予測の下限でサービスをプロビジョニングすると仮定した場合、サービスが拡大したら、2 番目に高いレベルのサービスを作成し、その 2 番目のサービスでインデックスを再構築してから、最初のサービスを削除することができます。Assuming you provision your service at the lower end of your load projections, if you outgrow the service, you can create a second larger-tiered service, rebuild your indexes on the second service, and then delete the first one.

オンプレミスのサーバーで容量計画を行った場合、予測される成長に対応できるように、"買い増し" することは普通です。If you've done capacity planning for on-premises servers, you know it's common to "buy up" so you can handle projected growth. クラウド サービスなら、特定の購入に固定されないため、より積極的にコスト節約を追求できます。With a cloud service, you can pursue cost savings more aggressively because you're not locked in to a specific purchase. 現在のサービスが不十分であれば、より高いレベルのサービスにいつでも切り替えることができます。You can always switch to a higher-tiered service if the current one isn't sufficient.

容量Capacity

Azure Search では、容量はレプリカパーティションで構成されています。In Azure Search, capacity is structured as replicas and partitions.

  • レプリカは、検索サービスのインスタンスです。Replicas are instances of the search service. 各レプリカは、負荷分散されたインデックスのコピーを 1 つホストします。Each replica hosts one load-balanced copy of an index. たとえば、6 つのレプリカが存在するサービスでは、各インデックスの 6 つのコピーがサービスに読み込まれています。For example, a service with six replicas has six copies of every index loaded in the service.

  • パーティションにインデックスが格納され、検索可能なデータが自動的に分割されます。Partitions store indexes and automatically split searchable data. パーティションが 2 つの場合、インデックスは 2 つに分割され、パーティションが 3 つの場合は 3 分の 1 に分割されるといったぐあいです。Two partitions split your index in half, three partitions split it into thirds, and so on. 容量の点では、"パーティション サイズ" が、レベル間で大きな違いのある機能です。In terms of capacity, partition size is the primary differentiating feature among tiers.

注意

すべての Standard および Storage Optimized レベルで、レプリカとパーティションを柔軟に組み合わせることができます。そのバランスを変更することにより、システムを速度またはストレージ量の点で最適化できます。All Standard and Storage Optimized tiers support flexible combinations of replicas and partitions so you can optimize your system for speed or storage by changing the balance. Basic レベルでは、最大で 3 つのレプリカが使用できるため可用性が高くなりますが、パーティションは 1 つのみです。The Basic tier offers up to three replicas for high availability but has only one partition. Free レベルでは、専用のリソースが提供されません。コンピューティング リソースは複数のサブスクライバー間で共用されます。Free tiers don't provide dedicated resources: computing resources are shared by multiple subscribers.

サービスの制限の詳細More about service limits

サービスでは、インデックス、インデクサーなどのリソースがホストされます。Services host resources like indexes and indexers. 各レベルには、作成できるリソースの数に対するサービス制限があります。Each tier imposes service limits on the number of resources you can create. そのため、インデックス (およびその他のオブジェクト) の最大数は、レベル間の第 2 の差別化要素です。So the maximum number of indexes (and other objects) is the second differentiating feature among tiers. ポータルで各オプションを確認するときに、インデックスの数の制限に注意してください。As you review each option in the portal, note the limits on the number of indexes. インデクサー、データ ソース、スキルセットなど、その他のリソースは、インデックスの制限に固定されています。Other resources, like indexers, data sources, and skillsets, are affixed to index limits.

消費パターンConsumption patterns

ほとんどのお客様が、Free サービスから始め、これを無期限に維持しながら、重要な開発または運用ワークロードのために Standard または Storage Optimized レベルを選択します。Most customers start with the Free service, which they keep indefinitely, and then choose one of the Standard or Storage Optimized tiers for serious development or production workloads.

Azure Search の価格レベルAzure Search pricing tiers

ロー エンドとハイ エンドでは、重要であるものの一般的な消費パターンのために Basic と S3 HD が存在します。On the low and high ends, Basic and S3 HD are for important but atypical consumption patterns. Basic は、小規模な運用ワークロード用です。Basic is for small production workloads. SLA、専用のリソース、および高可用性を提供しますが、ストレージは合計 2 GB を上限としており、大きくはありません。It offers SLAs, dedicated resources, and high availability, but it provides modest storage, topping out at 2 GB total. このレベルは、使用する容量が利用可能な容量を一貫して下回るお客様のために設計されています。This tier was engineered for customers that consistently underutilize available capacity. ハイ エンドでは、小さなインデックスを大量に必要とする構成、ISV、パートナー、マルチテナント ソリューションで典型的なワークロードのために、S3 HD があります。At the high end, S3 HD is for workloads typical of ISVs, partners, multitenant solutions, or any configuration that calls for a large number of small indexes. 多くの場合、Basic または S3 HD が適切なレベルであるかどうかは明確です。It's often clear when Basic or S3 HD is the right tier. 確認のためにガイダンスが必要な場合は、StackOverflow に投稿するか、Azure サポートに問い合わせてください。If you want confirmation, you can post to StackOverflow or contact Azure support for guidance.

より一般的に使用される Standard レベルである S1 から S3 では、容量の水準が段階的に増えていきます。The more commonly used standard tiers, S1 through S3, make up a progression of increasing levels of capacity. パーティション サイズには変曲点があり、インデックス、インデクサー、および推論リソースの数には制限があります。There are inflection points on partition size and limits on numbers of indexes, indexers, and corollary resources:

S1S1 S2S2 S3S3
パーティション サイズPartition size 25 GB25 GB 100 GB100 GB 200 GB200 GB
インデックスとインデクサーの制限Index and indexer limits 5050 200200 200200

S1 は、専用のリソースと複数のパーティションが必要なお客様にとって、一般的な選択肢です。S1 is a common choice for customers that need dedicated resources and multiple partitions. S1 は 25 GB のパーティションを最大 12 パーティションまで提供します。複数のレプリカにわたってパーティションを最大にした場合、サービスあたりの制限は 300 GB になりますS1 offers partitions of 25 GB and up to 12 partitions, providing a per-service limit of 300 GB if you maximize partitions over replicas. (よりバランスのとれた割り当てについては、パーティションとレプリカの割り当てに関するページを参照してください)。(See Allocate partitions and replicas for more balanced allocations.)

ポータルと価格のページでは、パーティションのサイズとストレージが強調されていますが、各レベルのすべてのコンピューティング機能 (ディスク容量、速度、CPU) は一般には価格と共に直線的に増加します。The portal and pricing pages put the focus on partition size and storage, but, for each tier, all compute capabilities (disk capacity, speed, CPUs) generally increase linearly with price. S2 レプリカは S1 より高速で、S3 は S2 より高速です。An S2 replica is faster than S1, and S3 is faster than S2. S3 レベルでは、格段に I/O が速いため、コンピューティング機能と価格の直線的なパターンから逸脱します。S3 tiers break from the linear compute-pricing pattern with disproportionately faster I/O. I/O がボトルネックになると予想される場合は、S3 を使用すると、より低いレベルを使用するよりもはるかに多くの IOPS が得られることに注意してください。If you expect I/O to be the bottleneck, keep in mind that you can get much more IOPS with S3 than you can get with lower tiers.

S3 と S3 HD は同一の大容量インフラストラクチャを使用していますが、上限に達する方法が異なります。S3 and S3 HD are backed by identical high-capacity infrastructure, but they reach their maximum limits in different ways. S3 は少数の非常に大きなインデックスを対象としているため、その上限はリソースに左右されます (サービスごとに 2.4 TB)。S3 targets a smaller number of very large indexes, so its maximum limit is resource-bound (2.4 TB for each service). S3 HD の対象は、非常に小さな多数のインデックスです。S3 HD targets a large number of very small indexes. インデックスが 1,000 個になった時点で、S3 HD は、インデックス制約という形でその制限に達します。At 1,000 indexes, S3 HD reaches its limits in the form of index constraints. S3 HD を使用しているお客様で、1,000 を超えるインデックスが必要な場合は、Microsoft サポートに対応方法についてお問い合わせください。If you're an S3 HD customer and you need more than 1,000 indexes, contact Microsoft Support for information about how to proceed.

注意

一時はドキュメントの制限が考慮事項となっていましたが、新しいサービスには該当しなくなりました。Document limits were a consideration at one time, but they're no longer applicable for new services. ドキュメントの制限が引き続き適用される条件については、「ドキュメントの制限」を参照してください。For information about conditions in which document limits still apply, see Document limits.

Storage Optimized レベル (L1 および L2) は、必要なデータは多くても、エンド ユーザーの数は比較的少なく、クエリの待ち時間を最小に抑えることが最優先事項ではないアプリケーションに最適です。Storage Optimized tiers, L1 and L2, are ideal for applications with large data requirements but a relatively low number of end users, when minimizing query latency isn't the top priority.

L1L1 L2L2
パーティション サイズPartition size 1 TB (テラバイト)1 TB 2 TB2 TB
インデックスとインデクサーの制限Index and indexer limits 1010 1010

L2 で提供されるストレージ容量の総量は、L1 の 2 倍です。L2 offers twice the overall storage capacity of L1. インデックスで必要と思われる最大データ量に基づいて、レベルを選択してください。Choose your tier based on the maximum amount of data that you think your index needs. L1 レベルのパーティションは、1 TB 単位の増分で最大 12 TB までスケールアップします。The L1 tier partitions scale up in 1-TB increments to a maximum of 12 TB. L2 パーティションは、パーティションごとに 2 TB ずつ、最大 24 TB まで増加します。The L2 partitions increase by 2 TBs per partition up to a maximum of 24 TB.

容量の評価Evaluating capacity

容量とサービスの実行コストは直接関係しています。Capacity and the costs of running the service are directly related. レベルによって、ストレージとリソースという 2 つの要素に制限が設けられます。Tiers impose limits on two levels: storage and resources. 先に上限に達した方が実質的な制限になるため、両方を考慮する必要があります。You should think about both because whichever limit you reach first is the effective limit.

通常、必要となるインデックスの数は、ビジネス要件によって規定されます。Business requirements typically dictate the number of indexes you'll need. たとえば、ドキュメントの大規模なリポジトリ用にグローバル インデックスが必要な場合があります。For example, you might need a global index for a large repository of documents. また、リージョン、アプリケーション、またはビジネス分野に基づいて複数のインデックスが必要な場合があります。Or you might need multiple indexes based on region, application, or business niche.

インデックスのサイズを特定するには、インデックスを 1 つ構築する必要があります。To determine the size of an index, you have to build one. Azure Search のデータ構造は、主に転置インデックス構造であり、ソース データとは異なる特性があります。The data structure in Azure Search is primarily an inverted index structure, which has different characteristics than source data. 転置インデックスのサイズと複雑性はコンテンツによって決まり、必ずしもそれにフィードするデータ量によって決まるものではありません。For an inverted index, size and complexity are determined by content, not necessarily by the amount of data that you feed into it. 冗長性の高い大規模なデータ ソースは、変動の多いコンテンツを含む小さいデータセットよりも、インデックスのサイズが小さくなることがあります。A large data source with high redundancy could result in a smaller index than a smaller dataset that contains highly variable content. そのため、元のデータ セットのサイズに基づいてインデックスのサイズを推測できることはほとんどありません。So it's rarely possible to infer index size based on the size of the original dataset.

注意

インデックスとストレージの将来のニーズの見積もりは、当て推量のように感じられるかもしれませんが、行う価値があります。Even though estimating future needs for indexes and storage can feel like guesswork, it's worth doing. あるレベルの容量が少なすぎることがわかった場合は、それより上のレベルで新しいサービスをプロビジョニングしたうえで、インデックスを再読み込みする必要があります。If a tier's capacity turns out to be too low, you'll need to provision a new service at a higher tier and then reload your indexes. 特定の SKU から別の SKU へのサービスのインプレース アップグレードを実行することはできません。There's no in-place upgrade of a service from one SKU to another.

手順 1:Free レベルを使用して大まかな見積もりを作成するStep 1: Develop rough estimates by using the Free tier

容量を見積もる方法の 1 つは、まず Free レベルを使用することです。One approach for estimating capacity is to start with the Free tier. Free サービスでは、最大 3 つのインデックス、50 MB のストレージ、および 2 分間のインデックス作成時間が提供されます。Remember that the Free service offers up to three indexes, 50 MB of storage, and 2 minutes of indexing time. これらの制約の中で予想インデックス サイズを見積もることは簡単ではない可能性があります。It can be challenging to estimate a projected index size with these constraints. 以下に、1 つの方法を示します。Here's an approach that you can take:

サンプルが代表的でデータ ソース全体の 10% だとすると、すべてのドキュメントのインデックスが作成された場合、30 MB のインデックスは約 300 MB になります。If the sample is representative and 10 percent of the entire data source, a 30-MB index becomes approximately 300 MB if all documents are indexed. この予備的な数値を基にして、2 つのインデックス (開発用と運用用) の量を予測するために、この数値を 2 倍にします。Armed with this preliminary number, you might double that amount to budget for two indexes (development and production). これで、ストレージの必要量が合計で 600 MB になります。This gives you a total of 600 MB in storage requirements. この必要量は Basic レベルで簡単に満たせるため、そこから利用を開始します。This requirement is easily satisfied by the Basic tier, so you would start there.

手順 2:課金対象レベルを使用して詳細な見積もりを作成するStep 2: Develop refined estimates by using a billable tier

お客様によっては、大量のサンプリングと処理時間に対応できる専用リソースから始め、開発段階でインデックスの量、サイズ、クエリ量の現実的な予想を立てることを選択することもできます。Some customers prefer to start with dedicated resources that can accommodate larger sampling and processing times and then develop realistic estimates of index quantity, size, and query volumes during development. 最初に、サービスは、最も確度の高い見積もりに基づいてプロビジョニングされます。Initially, a service is provisioned based on a best-guess estimate. その後、開発プロジェクトが成熟するに伴って、チームは通常、既存のサービスの容量が予想される運用ワークロードを上回るか下回るかを予想することができます。Then, as the development project matures, teams usually know whether the existing service is over or under capacity for projected production workloads.

  1. 各レベルのサービス制限を確認して、より低いレベルで、必要なインデックス数に対応できるかどうかを判断してください。Review service limits at each tier to determine whether lower tiers can support the number of indexes you need. Basic、S1、S2 レベルでのインデックス制限は、それぞれ 15、50、200 です。Across the Basic, S1, and S2 tiers, index limits are 15, 50, and 200, respectively. Storage Optimized レベルは、少数の非常に大きいインデックスをサポートするように設計されているため、10 インデックスに制限されています。The Storage Optimized tier has a limit of 10 indexes because it's designed to support a low number of very large indexes.

  2. 課金対象レベルでサービスを作成しますCreate a service at a billable tier:

    • 学習曲線の初めの段階では、Basic または S1 の低レベルから始めます。Start low, at Basic or S1, if you're at the beginning of your learning curve.
    • サイズの大きなインデックスの作成とクエリの負荷への対応が必要になることがわかっている場合は、S2 または S3 の高レベルから始めます。Start high, at S2 or even S3, if you know you're going to have large-scale indexing and query loads.
    • 社内のビジネス アプリケーションのように、インデックスを付けるデータの量が多く、クエリの負荷が比較的低い場合は、Storage Optimized (L1 または L2) から始めます。Start with Storage Optimized, at L1 or L2, if you're indexing a large amount of data and query load is relatively low, as with an internal business application.
  3. 最初のインデックスを構築して、ソース データがどのようにインデックスに変換されるかを特定します。Build an initial index to determine how source data translates to an index. これは、インデックスのサイズを推測する唯一の方法です。This is the only way to estimate index size.

  4. ポータルで、ストレージ、サービス制限、クエリ量、および待機時間を監視します。Monitor storage, service limits, query volume, and latency in the portal. 秒あたりのクエリ数、調整されたクエリ数、および検索の待ち時間がポータルに表示されます。The portal shows you queries per second, throttled queries, and search latency. これらすべての値が、適切なレベルを選択したかどうかを判断するために役立ちます。All of these values can help you decide if you selected the right tier. 検索トラフィック分析を有効にすることで、クリックスルー分析など、値の詳細な監視も構成できます。You also can configure deep monitoring of values like clickthrough analysis by enabling search traffic analytics.

インデックスの数とサイズは、分析にとってどちらも同様に重要です。Index number and size are equally important to your analysis. ストレージ (パーティション) を使い果たしたか、リソース (インデックス、インデクサーなど) の上限に達したか、どちらか早い方で上限に達したとされるためです。This is because maximum limits are reached through full utilization of storage (partitions) or by maximum limits on resources (indexes, indexers, and so forth), whichever comes first. ポータルの [概要] ページでは、現在の使用状況と最大制限が並んで表示されるため、両方を追跡できます。The portal helps you keep track of both, showing current usage and maximum limits side by side on the Overview page.

注意

ドキュメントに余分なデータが含まれている場合は、ストレージの必要量が多くなる可能性があります。Storage requirements can be inflated if documents contain extraneous data. ドキュメントには、検索機能に必要なデータのみが含まれていることが理想的な状態です。Ideally, documents contain only the data that you need for the search experience. バイナリ データは検索できないため、別途保存する必要があります (おそらく Azure テーブルまたは BLOB ストレージに)。Binary data isn't searchable and should be stored separately (maybe in an Azure table or blob storage). その後、外部データへの URL 参照を保持するためのフィールドをインデックスに追加する必要があります。A field should then be added in the index to hold a URL reference to the external data. 個々のドキュメントの最大サイズは 16 MB です (1 回の要求で複数のドキュメントを一括アップロードする場合は、それより小さくなります)。The maximum size of an individual document is 16 MB (or less if you're bulk uploading multiple documents in one request). 詳細については、「Azure Search サービスの制限 」を参照してください。For more information, see Service limits in Azure Search.

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

クエリ/秒 (QPS) は、パフォーマンスのチューニング中の重要なメトリックですが、一般に、最初からクエリ数が多いことが予想される場合は、レベルに関する考慮事項に過ぎません。Queries per second (QPS) is an important metric during performance tuning, but it's generally only a tier consideration if you expect high query volume at the outset.

Standard レベルでは、レプリカとパーティションのバランスを取ることができます。The Standard tiers can provide a balance of replicas and partitions. 負荷分散用のレプリカを追加したり、並列処理用のパーティションを追加したりすることで、クエリのターンアラウンドを向上させることができます。You can increase query turnaround by adding replicas for load balancing or add partitions for parallel processing. その後、サービスがプロビジョニングされた後に、パフォーマンスをチューニングできます。You can then tune for performance after the service is provisioned.

最初から大量のクエリ数が継続することが予想される場合は、より強力なハードウェアを使用する、より高い Standard レベルを検討してください。If you expect high sustained query volumes from the outset, you should consider higher Standard tiers, backed by more powerful hardware. その後、これらのクエリ数が発生しなかった場合は、パーティションとレプリカをオフラインにするか、より低いレベルのサービスに切り替えることができます。You can then take partitions and replicas offline, or even switch to a lower-tier service, if those query volumes don't occur. クエリ スループットの計算方法の詳細については、「Azure Search のパフォーマンスと最適化に関する考慮事項」を参照してください。For more information on how to calculate query throughput, see Azure Search performance and optimization.

Storage Optimized レベルは、大規模なデータ ワークロードに適しており、クエリの待ち時間要件がそれほど重要でない場合に、より全体的に利用可能なインデックス ストレージをサポートします。The Storage Optimized tiers are useful for large data workloads, supporting more overall available index storage for when query latency requirements are less important. それでも、負荷分散のためにはレプリカを追加し、並列処理のためにはパーティションを追加する必要があります。You should still use additional replicas for load balancing and additional partitions for parallel processing. その後、サービスがプロビジョニングされた後に、パフォーマンスをチューニングできます。You can then tune for performance after the service is provisioned.

サービスレベル アグリーメントService-level agreements

Free レベルおよびプレビュー機能には、サービスレベル アグリーメント (SLA) がありません。The Free tier and preview features don't provide service-level agreements (SLAs). 課金対象のすべてのレベルで、SLA が有効になるのは、サービスにとって十分な冗長性がプロビジョニングされるときです。For all billable tiers, SLAs take effect when you provision sufficient redundancy for your service. クエリ (読み取り) の SLA には複数のレプリカが必要です。You need to have two or more replicas for query (read) SLAs. クエリとインデックス作成 (読み取り/書き込み) の SLA には 3 つ以上のレプリカが必要です。You need to have three or more replicas for query and indexing (read-write) SLAs. パーティションの数は、SLA に影響しません。The number of partitions doesn't affect SLAs.

レベルの評価に関するヒントTips for tier evaluation

  • 効率的なインデックスを構築する方法と、どの更新方法が最も影響が少ないかについて説明します。Learn how to build efficient indexes, and learn which refresh methods have the least impact. 検索トラフィック分析を使用して、クエリ アクティビティに関する分析情報を取得します。Use search traffic analytics to gain insights on query activity.

  • クエリに関するメトリックを構築し、利用パターン (業務時間中のクエリ数、オフピーク時のインデックス作成) に関するデータを収集します。Allow metrics to build around queries, and collect data around usage patterns (queries during business hours, indexing during off-peak hours). このデータを使用して、サービス プロビジョニングに関する決定に役立つ情報を提供します。Use this data to inform service provisioning decisions. 時間ごと、または毎日の周期では実用的でありませんが、パーティションやリソースを動的に調節して、クエリ数の計画された変化に対応できます。Though it's not practical at an hourly or daily cadence, you can dynamically adjust partitions and resources to accommodate planned changes in query volumes. 計画外ではあっても持続した変化に対応することもできます。ただし、対処する間、そのレベルが保持される場合です。You can also accommodate unplanned but sustained changes if levels hold long enough to warrant taking action.

  • 過小なプロビジョニングの唯一の欠点として、実際の要件が予測より大きかった場合にサービスを中断する必要があるということに注意してください。Remember that the only downside of underprovisioning is that you might have to tear down a service if actual requirements are greater than your predictions. サービスの中断を回避するには、同じサブスクリプション内のより高いレベルで新しいサービスを作成し、すべてのアプリと要求が新しいエンドポイントを指すようになるまで並行して実行します。To avoid service disruption, you would create a new service in the same subscription at a higher tier and run it side by side until all apps and requests target the new endpoint.

次の手順Next steps

Free レベルから始め、データのサブセットを使用して最初のインデックスを構築することで、その特性を理解します。Start with a Free tier and build an initial index by using a subset of your data to understand its characteristics. Azure Search のデータ構造は、転置インデックス構造です。The data structure in Azure Search is an inverted index structure. 転置インデックスのサイズと複雑性はコンテンツによって決まります。The size and complexity of an inverted index is determined by content. 冗長性の高いコンテンツでは、不規則なコンテンツよりもインデックスのサイズが小さくなる傾向があります。Remember that highly redundant content tends to result in a smaller index than highly irregular content. そのため、インデックス ストレージの要件を決定するのは、データ セットのサイズではなく、コンテンツの特性です。So content characteristics rather than the size of the dataset determine index storage requirements.

インデックス サイズの最初の見積もり後、この記事で説明されているレベルのいずれかの課金対象のサービスをプロビジョニングします (Basic、Standard、または Storage Optimized)。After you have an initial estimate of your index size, provision a billable service on one of the tiers discussed in this article: Basic, Standard, or Storage Optimized. データのサイズ決定に対する人為的な制約を緩和し、検索可能にする必要があるすべてのデータが含まれるよう、インデックスを再構築します。Relax any artificial constraints on data sizing and rebuild your index to include all the data that you want to be searchable.

必要なパフォーマンスとスケールに合わせてパーティションとレプリカを割り当てます。Allocate partitions and replicas as needed to get the performance and scale you require.

パフォーマンスと容量に問題なければ完了です。If performance and capacity are fine, you're done. 問題がある場合は、より密接にニーズに適合するよう、別のレベルで検索サービスを再作成します。Otherwise, re-create a search service at a different tier that more closely aligns with your needs.

注意

ご不明な点がある場合は、StackOverflow に投稿するか、Azure サポートにお問い合わせください。If you have questions, post to StackOverflow or contact Azure support.