Azure Cosmos DB でプロビジョニング済みのスループット コストを最適化するOptimize provisioned throughput cost in Azure Cosmos DB

Azure Cosmos DB では、プロビジョニング済みスループット モデルにより、あらゆる規模で予測可能なパフォーマンスを提供します。By offering provisioned throughput model, Azure Cosmos DB offers predictable performance at any scale. スループットを事前に予約またはプロビジョニングすると、パフォーマンスでの "迷惑な隣人効果" を排除できます。Reserving or provisioning throughput ahead of time eliminates the “noisy neighbor effect” on your performance. 必要なスループットの量を正確に指定すると、Azure Cosmos DB で SLA によって裏付けられた構成済みのスループットが保証されます。You specify the exact amount of throughput you need and Azure Cosmos DB guarantees the configured throughput, backed by SLA.

最小スループットの 400 RU/秒から始めて、毎秒数千万要求あるいはそれ以上までスケールアップできます。You can start with a minimum throughput of 400 RU/sec and scale up to tens of millions of requests per second or even more. Azure Cosmos コンテナーまたはデータベースに対して発行する各要求 (読み取り要求、書き込み要求、クエリ要求、ストアド プロシージャなど) には対応するコストがあり、プロビジョニング済みスループットから差し引かれます。Each request you issue against your Azure Cosmos container or database, such as a read request, write request, query request, stored procedures have a corresponding cost that is deducted from your provisioned throughput. 400 RU/秒をプロビジョニングしてコストが 40 RU のコストを発行する場合、1 秒間にそのようなクエリを 10 個発行することができます。If you provision 400 RU/s and issue a query that costs 40 RUs, you will be able to issue 10 such queries per second. それを超えるすべての要求はレート制限を受け、要求を再試行する必要があります。Any request beyond that will get rate-limited and you should retry the request. クライアント ドライバーを使用している場合、それらでは自動再試行ロジックがサポートされています。If you are using client drivers, they support the automatic retry logic.

スループットはデータベースまたはコンテナーに対してプロビジョニングでき、各戦略はシナリオに応じてコスト削減に役立ちます。You can provision throughput on databases or containers and each strategy can help you save on costs depending on the scenario.

異なるレベルでスループットをプロビジョニングすることにより最適化するOptimize by provisioning throughput at different levels

  • データベースでスループットをプロビジョニングした場合は、そのデータベース内のすべてのコンテナー (コレクション/テーブル/グラフなど) が負荷に基づいてスループットを共有できます。If you provision throughput on a database, all the containers, for example collections/tables/graphs within that database can share the throughput based on the load. データベース レベルで予約されたスループットは、特定のコンテナーのセットでのワークロードに応じて不均一に共有されます。Throughput reserved at the database level is shared unevenly, depending on the workload on a specific set of containers.

  • コンテナーでスループットをプロビジョニングした場合は、そのコンテナーに対して SLA で裏付けられたスループットが保証されます。If you provision throughput on a container, the throughput is guaranteed for that container, backed by the SLA. コンテナーのすべての論理パーティションに負荷を均等に分散させるには、論理パーティション キーの選択が非常に重要です。The choice of a logical partition key is crucial for even distribution of load across all the logical partitions of a container. 詳しくは、パーティション分割および水平スケーリングに関する記事をご覧ください。See Partitioning and horizontal scaling articles for more details.

プロビジョニング済みスループットの戦略の決定に関するガイドラインを次に示します。The following are some guidelines to decide on a provisioned throughput strategy:

次の場合は、(コンテナーのセットを含む) Azure Cosmos DB データベースでのスループットのプロビジョニングを検討しますConsider provisioning throughput on an Azure Cosmos DB database (containing a set of containers) if:

  1. 数十個の Azure Cosmos コンテナーがあり、それらの一部または全部の間でスループットを共有したい場合。You have a few dozen Azure Cosmos containers and want to share throughput across some or all of them.

  2. IaaS でホストされた VM 上またはオンプレミス上で実行するように設計されているシングル テナントのデータベース (NoSQL やリレーショナル データベースなど) から、Azure Cosmos DB に移行する場合。You are migrating from a single-tenant database designed to run on IaaS-hosted VMs or on-premises, for example, NoSQL or relational databases to Azure Cosmos DB. そして、多くのコレクション/テーブル/グラフがあり、データ モデルをまったく変更したくない場合。And if you have many collections/tables/graphs and you do not want to make any changes to your data model. オンプレミスのデータベースから移行するときにデータ モデルを更新しないと、Azure Cosmos DB によって提供されるベネフィットの一部を犠牲にしなければならない場合があることに注意してください。Note, you might have to compromise some of the benefits offered by Azure Cosmos DB if you are not updating your data model when migrating from an on-premises database. 常にデータ モデルに再アクセスして、パフォーマンスを最大限に活用し、コストも最適化することをお勧めします。It's recommended that you always reaccess your data model to get the most in terms of performance and also to optimize for costs.

  3. データベース レベルでスループットをプールすることより、ワークロードの予期しない急増に対処する場合。You want to absorb unplanned spikes in workloads by virtue of pooled throughput at the database level subjected to unexpected spike in workload.

  4. コンテナーごとに個別に特定のスループットを設定するのではなく、データベース内の一連のコンテナー全体の集計スループットを取得することが大事な場合。Instead of setting specific throughput on individual containers, you care about getting the aggregate throughput across a set of containers within the database.

次の場合は、個々のコンテナーでスループットをプロビジョニングすることを検討しますConsider provisioning throughput on an individual container if:

  1. Azure Cosmos コンテナーの数が少ない場合。You have a few Azure Cosmos containers. Azure Cosmos DB はスキーマに依存しないため、スキーマが異なるアイテムを 1 つのコンテナーに格納でき、お客様はエンティティごとに複数の種類のコンテナーを作成する必要はありません。Because Azure Cosmos DB is schema-agnostic, a container can contain items that have heterogeneous schemas and does not require customers to create multiple container types, one for each entity. たとえば 10 ~ 20 個の個別のコンテナーを 1 つのコンテナーにグループ化することに意味があるかどうかを検討するのは、常にオプションの 1 つです。It is always an option to consider if grouping separate say 10-20 containers into a single container makes sense. コンテナーは最小 400 RU なので、10 ~ 20 個のコンテナーすべてを 1 つにプールすると、コスト効率がよくなる可能性があります。With a 400 RUs minimum for containers, pooling all 10-20 containers into one could be more cost effective.

  2. 特定のコンテナーでスループットを制御し、SLA によって裏付けられている保証されたスループットを取得したい場合。You want to control the throughput on a specific container and get the guaranteed throughput on a given container backed by SLA.

上記の 2 つの戦略のハイブリッドを検討しますConsider a hybrid of the above two strategies:

  1. 前に説明したように、Azure Cosmos DB では上記の 2 つの戦略を混在させることができるので、Azure Cosmos データベース内の一部のコンテナーについてはデータベースのプロビジョニング済みスループットを共有し、同時に、同じデータベース内の他のコンテナーでは専用のプロビジョニング済みスループット量を利用することができます。As mentioned earlier, Azure Cosmos DB allows you to mix and match the above two strategies, so you can now have some containers within Azure Cosmos database, which may share the throughput provisioned on the database as well as, some containers within the same database, which may have dedicated amounts of provisioned throughput.

  2. 上記の戦略を適用してハイブリッド構成を実現し、データベース レベルのプロビジョニング済みスループットと、コンテナー専用のスループットを併用できます。You can apply the above strategies to come up with a hybrid configuration, where you have both database level provisioned throughput with some containers having dedicated throughput.

次の表に示すように、API の選択に応じて、異なる細かさでスループットをプロビジョニングできます。As shown in the following table, depending on the choice of API, you can provision throughput at different granularities.

APIAPI 共有スループットの場合の構成対象For shared throughput, configure 専用スループットの場合の構成対象For dedicated throughput, configure
SQL APISQL API DatabaseDatabase コンテナーContainer
Azure Cosmos DB の MongoDB 用 APIAzure Cosmos DB's API for MongoDB DatabaseDatabase コレクションCollection
Cassandra APICassandra API キースペースKeyspace テーブルTable
Gremlin APIGremlin API データベース アカウントDatabase account GraphGraph
テーブル APITable API データベース アカウントDatabase account テーブルTable

異なるレベルでスループットをプロビジョニングすることにより、ワークロードの特性に基づいてコストを最適化できます。By provisioning throughput at different levels, you can optimize your costs based on the characteristics of your workload. 前に説明したように、プログラムを使用していつでも、個々のコンテナーについて、またはコンテナーのセットで集合的に、プロビジョニング済みスループットを増やしたり減らしたりできます。As mentioned earlier, you can programmatically and at any time increase or decrease your provisioned throughput for either individual container(s) or collectively across a set of containers. ワークロードの変化に応じてスループットを弾力的にスケーリングすることで、支払いは構成したスループットに対するものだけで済みます。By elastically scaling throughput as your workload changes, you only pay for the throughput that you have configured. コンテナーまたはコンテナーのセットが複数のリージョンに分散されている場合、そのコンテナーまたはコンテナーのセットで構成するスループットがすべてのリージョンで使用可能になることが保証されます。If your container or a set of containers is distributed across multiple regions, then the throughput you configure on the container or a set of containers is guaranteed to be made available across all regions.

要求のレート制限で最適化するOptimize with rate-limiting your requests

待ち時間が重要ではないワークロードの場合は、プロビジョニングするスループットを少なくし、実際のスループットがプロビジョニング済みスループットを超えたときはアプリケーションでレート制限を処理することができます。For workloads that aren't sensitive to latency, you can provision less throughput and let the application handle rate-limiting when the actual throughput exceeds the provisioned throughput. サーバーはいち早く RequestRateTooLarge (HTTP 状態コード 429) で要求を終了させ、要求を再試行するまでにユーザーが待機しなければならない時間 (ミリ秒) を示す x-ms-retry-after-ms ヘッダーを返します。The server will preemptively end the request with RequestRateTooLarge (HTTP status code 429) and return the x-ms-retry-after-ms header indicating the amount of time, in milliseconds, that the user must wait before retrying the request.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

SDK での再試行ロジックRetry logic in SDKs

ネイティブ SDK (.NET/.NET Core、Java、Node.js、Python) ではこの応答が暗黙的にキャッチされて、サーバーが指定した retry-after ヘッダーを優先して要求が再試行されます。The native SDKs (.NET/.NET Core, Java, Node.js and Python) implicitly catch this response, respect the server-specified retry-after header, and retry the request. アカウントに複数のクライアントが同時アクセスしている状況でなければ、次回の再試行は成功します。Unless your account is accessed concurrently by multiple clients, the next retry will succeed.

累積的に動作する複数のクライアントがあり、要求レートを常に超えている場合は、現在 9 に設定されている既定の再試行回数では十分ではない可能性があります。If you have more than one client cumulatively operating consistently above the request rate, the default retry count currently that is currently set to 9 may not be sufficient. このような場合、クライアントではアプリケーションに対して状態コード 429 の DocumentClientException がスローされます。In such case, the client throws a DocumentClientException with status code 429 to the application. 既定の再試行回数は、ConnectionPolicy インスタンスで RetryOptions を設定することで変更できます。The default retry count can be changed by setting the RetryOptions on the ConnectionPolicy instance. 既定では、要求レートを超えて要求が続行されている場合に、30 秒の累積待機時間を過ぎると、状態コード 429 を含む DocumentClientException が返されます。By default, the DocumentClientException with status code 429 is returned after a cumulative wait time of 30 seconds if the request continues to operate above the request rate. これは、現在の再試行回数が最大再試行回数 (既定値の 9 またはユーザー定義の値) より少ない場合でも発生します。This occurs even when the current retry count is less than the max retry count, be it the default of 9 or a user-defined value.

MaxRetryAttemptsOnThrottledRequests は 3 に設定されているので、このケースでは、コレクションの予約済みスループットを超えることによって要求操作がレート制限された場合、要求操作では 3 回再試行してからアプリケーションに例外がスローされます。 MaxRetryWaitTimeInSeconds は 60 に設定されているので、このケースでは、最初の要求からの累積再試行待機時間 (秒数) が 60 秒を超えると、例外がスローされます。MaxRetryAttemptsOnThrottledRequests is set to 3, so in this case, if a request operation is rate limited by exceeding the reserved throughput for the collection, the request operation retries three times before throwing the exception to the application. MaxRetryWaitTimeInSeconds is set to 60, so in this case if the cumulative retry waits time in seconds since the first request exceeds 60 seconds, the exception is thrown.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 

connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 

connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

パーティション分割戦略とプロビジョニング済みスループット コストPartitioning strategy and provisioned throughput costs

Azure Cosmos DB でのコストを最適化するには、適切なパーティション分割戦略が重要です。Good partitioning strategy is important to optimize costs in Azure Cosmos DB. パーティションの不均衡がないことを確認します。これはストレージのメトリックで公開されます。Ensure that there is no skew of partitions, which are exposed through storage metrics. パーティションに対してスループットの不均衡がないことを確認します。これは、スループットのメトリックで公開されます。Ensure that there is no skew of throughput for a partition, which is exposed with throughput metrics. 特定のパーティション キーに対する不均衡がないことを確認します。Ensure that there is no skew towards particular partition keys. ストレージでの主要なキーはメトリックを通じて公開されますが、キーはアプリケーションのアクセス パターンに依存します。Dominant keys in storage are exposed through metrics but the key will be dependent on your application access pattern. 適切な論理パーティション キーについて考慮するのが最善です。It's best to think about the right logical partition key. 適切なパーティション キーは、次のような特性を持つことが期待されます。A good partition key is expected to have the following characteristics:

  • すべてのパーティションと時間で均等にワークロードが分散されるパーティション キーを選択します。Choose a partition key that spreads workload evenly across all partitions and evenly over time. つまり、一部のキーにデータの多くが集中し、他のキーにはデータがほとんど、またはまったくないということがあってはなりません。In other words, you shouldn't have some keys to with majority of the data and some keys with less or no data.

  • アクセス パターンが論理パーティション間で均等に分散されるパーティション キーを選択します。Choose a partition key that enables access patterns to be evenly spread across logical partitions. ワークロードをすべてのキーの間である程度一定にします。The workload is reasonably even across all the keys. つまり、ワークロードの大部分が少数の特定のキーに集中してはなりません。In other words, the majority of the workload shouldn't be focused on a few specific keys.

  • 値の範囲が広いパーティション キーを選択します。Choose a partition key that has a wide range of values.

基本的な考え方は、コンテナー内のデータとアクティビティを一連の論理パーティションに分散し、データ ストレージとスループットのリソースを論理パーティション間に分散できるようにすることです。The basic idea is to spread the data and the activity in your container across the set of logical partitions, so that resources for data storage and throughput can be distributed across the logical partitions. パーティション キーの候補には、クエリ内でフィルターとして頻繁に出現するプロパティが含まれる場合があります。Candidates for partition keys may include the properties that appear frequently as a filter in your queries. フィルターの述語にパーティション キーを含めることで、クエリ呼び出しを効率的にルーティングできます。Queries can be efficiently routed by including the partition key in the filter predicate. このようなパーティション分割戦略では、プロビジョニング済みスループットの最適化がずっと容易になります。With such a partitioning strategy, optimizing provisioned throughput will be a lot easier.

スループットが高いほどアイテムが小さくなるように設計するDesign smaller items for higher throughput

特定の操作の要求の使用量または要求処理コストは、アイテムのサイズに直接関係します。The request charge or the request processing cost of a given operation is directly correlated to the size of the item. 大きいアイテムの操作には小さいアイテムの操作よりコストがかかります。Operations on large items will cost more than operations on smaller items.

データ アクセス パターンData access patterns

データへのアクセス頻度に基づいて論理カテゴリにデータを論理的に分割するのは、常によい方法です。It is always a good practice to logically separate your data into logical categories based on how frequently you access the data. それをホット データ、ミディアム データ、コールド データに分類することによって、消費されるストレージと必要なスループットを細かく調整できます。By categorizing it as hot, medium, or cold data you can fine-tune the storage consumed and the throughput required. アクセスの頻度に応じて、データを異なるコンテナー (たとえば、テーブル、グラフ、コレクション) に配置し、それらのプロビジョニング済みスループットを微調整して、データのそのセグメントのニーズに対応できます。Depending on the frequency of access, you can place the data into separate containers (for example, tables, graphs, and collections) and fine-tune the provisioned throughput on them to accommodate to the needs of that segment of data.

さらに、Azure Cosmos DB を使用していて、特定のデータ値で検索を行わないこと、またはほとんどアクセスしないことがわかっている場合は、これらの属性の圧縮された値を格納する必要があります。Furthermore, if you're using Azure Cosmos DB, and you know you are not going to search by certain data values or will rarely access them, you should store the compressed values of these attributes. このようにすると、ストレージ領域、インデックス領域、プロビジョニング済みスループットが節約されて、コストを削減できます。With this method you save on storage space, index space, and provisioned throughput and result in lower costs.

インデックス作成ポリシーを変更することで最適化するOptimize by changing indexing policy

Azure Cosmos DB では既定で、すべてのレコードのすべてのプロパティに自動的にインデックスが付けられます。By default, Azure Cosmos DB automatically indexes every property of every record. これは、開発を容易にし、さまざまな種類のアドホック クエリで優れたパフォーマンスを確保するために行われます。This is intended to ease development and ensure excellent performance across many different types of ad hoc queries. 何千ものプロパティを含む大きいレコードがある場合、すべてのプロパティにインデックスを付けるためにスループットのコストを払うのは無益なことがあります。そのようなプロパティの 10 個とか 20 個に対してしかクエリを行わない場合は特にそうです。If you have large records with thousands of properties, paying the throughput cost for indexing every property may not be useful, especially if you only query against 10 or 20 of those properties. 特定のワークロードについての理解が深まったら、インデックス ポリシーを調整することをお勧めします。As you get closer to getting a handle on your specific workload, our guidance is to tune your index policy. Azure Cosmos DB でのインデックス作成ポリシーについて詳しくは、こちらをご覧ください。Full details on Azure Cosmos DB indexing policy can be found here.

プロビジョニング済みスループットと消費済みスループットを監視するMonitoring provisioned and consumed throughput

プロビジョニングされた RU の総数、レート制限された要求の数、および消費された RU の数を、Azure portal で監視できます。You can monitor the total number of RUs provisioned, number of rate-limited requests as well as the number of RUs you’ve consumed in the Azure portal. 次の図では使用量メトリックの例を示します。The following image shows an example usage metric:

Azure portal で要求ユニットを監視する

レート制限された要求の数が特定のしきい値を超えたかどうかを確認するアラートを設定することもできます。You can also set alerts to check if the number of rate-limited requests exceeds a specific threshold. 詳しくは、Azure Cosmos DB の監視方法に関する記事をご覧ください。See How to monitor Azure Cosmos DB article for more details. これらのアラートでは、アカウント管理者にメールを送ること、またはカスタム HTTP Webhook や Azure 関数を呼び出して自動的にプロビジョニング済みスループットを増やすことができます。These alerts can send an email to the account administrators or call a custom HTTP Webhook or an Azure Function to automatically increase provisioned throughput.

弾力的にオンデマンドでスループットをスケーリングするScale your throughput elastically and on-demand

プロビジョニングされたスループットに対して課金されるので、プロビジョニング済みスループットをニーズと一致させることが、未使用のスループットに課金されるのを防ぐのに役立ちます。Since you are billed for the throughput provisioned, matching the provisioned throughput to your needs can help you avoid the charges for the unused throughput. 必要に応じていつでも、プロビジョニング済みスループットをスケールアップまたはスケールダウンできます。You can scale your provisioned throughput up or down any time, as needed.

  • RU の消費量と、レート制限された要求の割合を監視することで、日または週を通してプロビジョニング済みスループットを一定に保つ必要がないことがわかる場合があります。Monitoring the consumption of your RUs and the ratio of rate-limited requests may reveal that you do not need to keep provisioned throughout constant throughout the day or the week. 夜間や週末は、受け取るトラフィックが減ることがあります。You may receive less traffic at night or during the weekend. Azure portal または Azure Cosmos DB のネイティブ SDK や REST API を使用すると、いつでもプロビジョニング済みスループットをスケーリングできます。By using either Azure portal or Azure Cosmos DB native SDKs or REST API, you can scale your provisioned throughput at any time. Azure Cosmos DB の REST API では、コンテナーのパフォーマンス レベルをプログラムで更新するためのエンドポイントが提供されており、時間帯や曜日に応じてコードから簡単にスループットを調整できます。Azure Cosmos DB’s REST API provides endpoints to programmatically update the performance level of your containers making it straightforward to adjust the throughput from your code depending on the time of the day or the day of the week. 操作はダウンタイムなしで実行され、通常は 1 分未満で有効になります。The operation is performed without any downtime, and typically takes effect in less than a minute.

  • スループットのスケーリングが必要になる場合の 1 つは、Azure Cosmos DB にデータを取り込むときです (たとえば、データ移行中)。One of the areas you should scale throughput is when you ingest data into Azure Cosmos DB, for example, during data migration. 移行が完了したら、プロビジョニング済みスループットをスケールダウンして、ソリューションの安定した状態を処理できます。Once you have completed the migration, you can scale provisioned throughput down to handle the solution’s steady state.

  • 課金の最小単位が 1 時間であることを思い出してください。そのため、1 時間に複数回プロビジョニング済みスループットを変更した場合、コストの節約にはなりません。Remember, the billing is at the granularity of one hour, so you will not save any money if you change your provisioned throughput more often than one hour at a time.

新しいワークロードに必要なスループットを判断するDetermine the throughput needed for a new workload

新しいワークロードのプロビジョニング済みスループットを決定するには、次の手順を使用できます。To determine the provisioned throughput for a new workload, you can use the following steps:

  1. 最初に容量計画ツールを使用して大まかに評価し、Azure portal で Azure Cosmos Explorer を使用して見積もりを調整します。Perform an initial, rough evaluation using the capacity planner and adjust your estimates with the help of the Azure Cosmos Explorer in the Azure portal.

  2. 予想より高いスループットでコンテナーを作成し、必要に応じてスケールダウンすることをお勧めします。It's recommended to create the containers with higher throughput than expected and then scaling down as needed.

  3. いずれかの Azure Cosmos DB ネイティブ SDK を使用して、要求がレート制限を受けたときに自動再試行されるようにすることをお勧めします。It's recommended to use one of the native Azure Cosmos DB SDKs to benefit from automatic retries when requests get rate-limited. サポートされていないプラットフォームで作業していて、Cosmos DB の REST API を使用する場合は、x-ms-retry-after-ms ヘッダーを使用して独自の再試行ポリシーを実装します。If you’re working on a platform that is not supported and use Cosmos DB’s REST API, implement your own retry policy using the x-ms-retry-after-ms header.

  4. アプリケーションのコードで、すべての再試行が失敗した場合が適切にサポートされていることを確認します。Make sure that your application code gracefully supports the case when all retries fail.

  5. レート制限に対する通知を受け取るように、Azure portal からのアラートを構成することができます。You can configure alerts from the Azure portal to get notifications for rate-limiting. 過去 15 分間にレート制限された要求が 10 件のような控え目な制限から始めて、実際の消費量を把握したら、さらに積極的な制限に切り替えることができます。You can start with conservative limits like 10 rate-limited requests over the last 15 minutes and switch to more eager rules once you figure out your actual consumption. ときどきレート制限が発生しても問題ありません。それは設定した制限が動作していて、意図したとおりになっていることを示します。Occasional rate-limits are fine, they show that you’re playing with the limits you’ve set and that’s exactly what you want to do.

  6. 日または週の間にスループットのプロビジョニングを動的に調整する必要があるかどうかを検討できるよう、監視を使用してトラフィックのパターンを把握します。Use monitoring to understand your traffic pattern, so you can consider the need to dynamically adjust your throughput provisioning over the day or a week.

  7. プロビジョニング済みスループットと消費済みスループットの比率を定期的に監視し、必要な数より多くのコンテナーおよびデータベースをプロビジョニングしていないことを確認します。Monitor your provisioned vs. consumed throughput ratio regularly to make sure you have not provisioned more than required number of containers and databases. スループットを少しだけオーバー プロビジョニングすることは、適切な安全性チェックです。Having a little over provisioned throughput is a good safety check.

プロビジョニング済みスループットの最適化に関するベスト プラクティスBest practices to optimize provisioned throughput

以下の手順は、Azure Cosmos DB を使用するときにソリューションのスケーラビリティとコスト効率を高くするのに役立ちます。The following steps help you to make your solutions highly scalable and cost-effective when using Azure Cosmos DB.

  1. コンテナーやデータベースに大幅にオーバー プロビジョニングされたスループットがある場合は、プロビジョニングされた RU と消費された RU を確認して、ワークロードを微調整する必要があります。If you have significantly over provisioned throughput across containers and databases, you should review RUs provisioned Vs consumed RUs and fine-tune the workloads.

  2. アプリケーションに必要な予約済みスループットの量を推定するには、典型的な操作の実行に関連する要求ユニット (RU) の料金を記録し、アプリケーションが使用する代表的な Azure Cosmos コンテナーまたはデータベースに基づいて、1 秒ごとに実行される操作数を推定します。One method for estimating the amount of reserved throughput required by your application is to record the request unit RU charge associated with running typical operations against a representative Azure Cosmos container or database used by your application and then estimate the number of operations you anticipate to perform each second. さらに、通常のクエリとそれらの使用量も忘れずに測定し、考慮に入れます。Be sure to measure and include typical queries and their usage as well. プログラムまたはポータルでクエリの RU コストを見積もる方法については、クエリのコストの最適化に関する記事をご覧ください。To learn how to estimate RU costs of queries programmatically or using portal see Optimizing the cost of queries.

  3. 操作とその RU コストを取得するもう 1 つの方法は、Azure Monitor ログを有効にすることで、操作/継続時間と要求の料金の明細が提供されます。Another way to get operations and their costs in RUs is by enabling Azure Monitor logs, which will give you the breakdown of operation/duration and the request charge. Azure Cosmos DB では、すべての操作に対して要求の料金が提供されるので、すべての操作の料金を応答から保存して、分析に使用できます。Azure Cosmos DB provides request charge for every operation, so every operation charge can be stored back from the response and then used for analysis.

  4. プロビジョニング済みスループットを弾力的にスケールアップおよびスケールダウンして、ワークロードのニーズに対応できます。You can elastically scale up and down provisioned throughput as you need to accommodate your workload needs.

  5. 必要に応じて Azure Cosmos アカウントに関連付けられているリージョンを追加および削除し、コストを管理できます。You can add and remove regions associated with your Azure Cosmos account as you need and control costs.

  6. コンテナーの論理パーティション間にデータとワークロードが均等に分散されていることを確認します。Make sure you have even distribution of data and workloads across logical partitions of your containers. パーティション間の分散が均等でない場合、スループットのプロビジョニング量が必要な値より高くなる可能性があります。If you have uneven partition distribution, this may cause to provision higher amount of throughput than the value that is needed. 不均衡な分散があることを特定した場合は、パーティション間に均等にワークロードを再分配するか、またはデータを再パーティション分割することをお勧めします。If you identify that you have a skewed distribution, we recommend redistributing the workload evenly across the partitions or repartition the data.

  7. 多くのコンテナーがあり、それらのコンテナーで SLA が必要ない場合は、コンテナー単位のスループット SLA が適用されないデータベースに基づくオファーを使用できます。If you have many containers and these containers do not require SLAs, you can use the database-based offer for the cases where the per container throughput SLAs do not apply. データベース レベルのスループット オファーに移行する Azure Cosmos コンテナーを特定した後、変更フィード ベースのソリューションを使用してそれらを移行する必要があります。You should identify which of the Azure Cosmos containers you want to migrate to the database level throughput offer and then migrate them by using a change feed-based solution.

  8. 開発/テストのシナリオには、"Cosmos DB Free レベル" (1 年間無料)、Cosmos DB を試す (最大 3 リージョン)、またはダウンロード可能な Cosmos DB エミュレーターを使用することを検討します。Consider using the “Cosmos DB Free Tier” (free for one year), Try Cosmos DB (up to three regions) or downloadable Cosmos DB emulator for dev/test scenarios. テストや開発にこれらのオプションを使用すると、コストを大幅に削減できます。By using these options for test-dev, you can substantially lower your costs.

  9. バッチ サイズの拡大、複数リージョンへの読み取りの負荷分散、データの重複除去など、該当する場合は、ワークロード固有のコスト最適化をさらに実行できます。You can further perform workload-specific cost optimizations – for example, increasing batch-size, load-balancing reads across multiple regions, and de-duplicating data, if applicable.

  10. Azure Cosmos DB の予約容量を利用すると、3 年間最大 65% という大幅な割引を受けることができます。With Azure Cosmos DB reserved capacity, you can get significant discounts for up to 65% for three years. Azure Cosmos DB の予約容量モデルは、一定期間に必要な要求ユニットに対する前払いのコミットメントです。Azure Cosmos DB reserved capacity model is an upfront commitment on requests units needed over time. 割引は、要求ユニットの使用期間が長いほど、割引額が大きくなるように、階層化されています。The discounts are tiered such that the more request units you use over a longer period, the more your discount will be. これらの割引は、すぐに適用されます。These discounts are applied immediately. プロビジョニングされた値を超えて使用された RU は、予約容量ではないコストに基づいて課金されます。Any RUs used above your provisioned values are charged based on the non-reserved capacity cost. 詳しくは、Cosmos DB の予約容量に関する記事をご覧ください。See Cosmos DB reserved capacity) for more details. プロビジョニング済みスループットのコストをさらに下げるには、予約容量の購入を検討してください。Consider purchasing reserved capacity to further lower your provisioned throughput costs.

次の手順Next steps

次は、先に進み、以下の各記事で Azure Cosmos DB でのコストの最適化の詳細について学習することができます。Next you can proceed to learn more about cost optimization in Azure Cosmos DB with the following articles: