Azure Cosmos DB の自動スケーリングでプロビジョニングされたスループットについてよく寄せられる質問

オートスケールまたはオートスケールでプロビジョニングされたスループットでは、最もアクティブなリージョンとパーティションに基づいてワークロードがスケーリングされます。 これに対し、動的オートスケールでは、ワークロードのリージョンとパーティションを、使用状況に基づいて個別にスケーリングできます。 オートスケールの使用を計画しているすべてのお客様には、動的オートスケールをお勧めします。

プロパティ enablePerRegionPerPartitionAutoscale を true に設定するには、API バージョン 2023-11-15-preview 以降のプレビュー バージョンを使用する Resource Manager テンプレートを使用します。 このプロパティは、プレビュー バージョン 2023-11-15-preview 以降のプレビュー バージョンを使用して JSON ビューで確認できます。 Azure CLI または PowerShell を使用することもできます。

// Add Azure Cosmos DB extension 2.0.6-preview for PowerShell
Install-Module -Name Az.CosmosDB -RequiredVersion 2.0.6-preview -AllowPrerelease -AllowClobber -Force

// update the account using this command to enable or disable the property
Update-AzCosmosDBAccount -EnablePerRegionPerPartitionAutoscale $true -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"

// Run this command to see the enablement or disablement status:
Get-AzCosmosDBAccount -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"

// Add Azure Cosmos DB extension for CLI
az extension add --name cosmosdb-preview --allow-preview true

// update the account using this command to enable or disable the property
az cosmosdb update --enable-prpp-autoscale true --name '<cosmos-account-name>' --resource-group '<resource-group-name>'

// Run this command to see the enablement or disablement status:
az cosmosdb show --name '<cosmos-account-name>' --resource-group '<resource-group-name>'

以前の階層モデルで作成されたリソースは、自動的に新しい自動スケーリングのカスタム最大 RU/秒モデルでサポートされます。 階層の上限は新しい最大 RU/秒になり、結果として同じスケール範囲になります。

たとえば、以前に 400 RU/秒から 4,000 RU/秒の間でスケーリングされる階層を選んだ場合、データベースまたはコンテナーの最大 RU/秒は現在 4,000 RU/秒 (400 RU/秒から 4,000 RU/秒の間でのスケーリング) になります。 次に、最大 RU/秒をワークロードに基づいたカスタム値に変更できます。

2022 年 4 月以降、設定できる自動スケーリングの最大 RU/s は最低 1,000 RU/s からになります (スケールは 100 RU/s から 1,000 RU/s の間)。 200 RU/秒から 2,000 RU/秒、または 300 RU/秒から 3,000 RU/秒のスケール範囲を設定することもできます。 以前のエントリ ポイントは 400 RU/秒から 4,000 RU/秒でした。

この構成は、スループット要件は低いものの、最大 RU/秒までスケーリングされる可能性があるワークロードに推奨されます。

自動スケーリングでは、システムは受信トラフィックに基づいて、0.1 × Tmax から Tmax の範囲内でスループット (RU/秒) を T アップまたは T ダウンします。 スケーリングは自動的かつ瞬時に行われるため、どの時点でも、プロビジョニングされた Tmax まで遅延なく使用できます。

Azure Monitor メトリックを使用して、プロビジョニングされた自動スケーリングの最大 RU/秒と、システムがスケーリングされている現在のスループット (RU/秒) の両方を監視できます。

料金は、その 1 時間でシステムがスケーリングした最大スループット T に対して、時間単位で請求されます。 1 時間の間にリソースに対する要求がなかった場合、または 0.1 × Tmax を超えてスケーリングされなかった場合は、最小の 0.1 × Tmax に対して課金されます。 詳細については、Azure Cosmos DB の価格に関するページを参照してください。

単一書き込みリージョン アカウントの場合、100 RU/秒あたりの自動スケーリングのレートは、Standard (手動) プロビジョニング スループットのレートの 1.5 倍です。 請求書には、既存の Standard プロビジョニング スループット測定が表示されます。 この測定の数量に 1.5 が掛けられます。 たとえば、システムがスケーリングされ、1 時間以内の最大 RU/秒が 6,000 RU/秒であった場合、その 1 時間の測定の 60 × 1.5 = 90 単位が請求されます。

複数書き込みリージョンを持つアカウントの場合、100 RU/秒あたりの自動スケーリングのレートは、Standard (手動) プロビジョニングの複数書き込みリージョンのスループットのレートと同じです。 請求書には、既存の複数書き込みリージョンの測定が表示されます。 レートは同じであるため、自動スケーリングを使用した場合は、Standard スループットと同じ数量が示されます。

はい。 単一書き込みリージョンでアカウントに対して予約容量を使用すると、自動スケーリング リソースの予約割引が測定の使用量に適用されます。比率は、1.5 × 特定リージョンの比率になります。 たとえば、10,000 自動スケーリング RU/s をカバーする予約容量を使用したい場合は、予約容量全体で 15,000 RU/s を購入する必要があります。

複数書き込みリージョンの予約容量は、自動スケーリングと Standard (手動) プロビジョニング スループットに対して同様に機能します。 詳細については、「Azure Cosmos DB の予約容量」を参照してください。

はい。 Free レベルでは、データベースまたはコンテナーで自動スケーリング スループットを利用できます。 詳細については、Free レベルでの自動スケーリングの請求のしくみに関するページを参照してください。

はい。 自動スケーリングは、すべての API (NoSQL、Gremlin、Table、Cassandra、MongoDB) でサポートされています。

はい。 最大 RU/秒は、Azure Cosmos DB アカウントに追加した各リージョンで利用できます。

自動スケーリングを有効にする方法について説明します。

はい。 自動スケーリングと Standard (手動) プロビジョニング スループットを切り替えることもできます。 現在、すべての API において、これらの操作を行うには、Azure portal、Azure CLI、または PowerShell を使用できます。 設計上、Azure Cosmos DB クライアント SDK または Azure Resource Manager テンプレートを使って、手動によるプロビジョニング スループットと自動スケーリングの間で移行を行うことはできません。 ただし、クライアント SDK または Azure Resource Manager テンプレートを使って、新しい自動スケーリング リソースを作成し、既存の自動スケーリング リソースの最大 RU/s を変更することはできます。

概念的には、スループットの種類の変更は 2 段階のプロセスです。 最初に、自動スケーリングまたは手動プロビジョニング スループットを使用するようにスループット設定を変更する要求を送信します。 どちらの場合も、現在のスループット設定とストレージに基づいて、初期 RU/秒値が自動的に決まり、設定されます。 この手順の間、ユーザーが指定した RU/秒値は受け入れられません。 その後、更新が完了したら、自分のワークロードに合わせて RU/秒を変更することができます。

Standard (手動) プロビジョニング スループットから自動スケーリングへの移行

コンテナーの場合は、次の式を使用して、初期自動スケーリングの最大 RU/秒を見積もってください。

MAX(1,000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB × 10) 最も近い 1,000 RU/s に丸められます。

実際の初期自動スケーリングの最大 RU/秒は、アカウントの構成によって異なる場合があります。

例 1: 10,000 RU/秒の手動プロビジョニング スループットと 25 GB のストレージを備えたコンテナーがあります。 自動スケーリングを有効にすると、初期自動スケーリングの最大 RU/秒は 10,000 RU/秒 (1,000 RU/秒から 10,000 RU/秒の間でスケーリング可能) です。

例 2: 50,000 RU/秒の手動プロビジョニング スループットと 25,000 GB のストレージを備えたコンテナーがあります。 自動スケーリングを有効にすると、初期自動スケーリングの最大 RU/秒は 250,000 RU/秒 (25,000 RU/秒から 250,000 RU/秒の間でスケーリング可能) です。

自動スケーリングから Standard (手動) プロビジョニング スループットへの移行

初期手動プロビジョニング スループットは、現在の自動スケーリングの最大 RU/秒と同じです。

例: 最大 RU/秒が 20,000 RU/秒 (2,000 RU/秒から 20,000 RU/秒の間でスケーリング) の自動スケーリング データベースまたはコンテナーがあります。 手動プロビジョニング スループットを使用するように更新すると、初期スループットは 20,000 RU/秒になります。

多数のスループット リソースを移行する必要がある場合は、Azure CLI スクリプト - オートスケールへの変換を使用することを検討してください。

はい。 プログラムによって既存のデータベースまたはコンテナーで自動スケーリングを有効にするには、Azure CLI または PowerShell を使用できます。

自動スケーリングを使用して新しいデータベースまたはコンテナーを作成するには、Azure CLI、PowerShell、または Azure Resource Manager テンプレートを使用できます。

はい。 共有スループット データベースの自動スケーリングを有効にするには、データベースの作成時に自動スケーリングと [プロビジョニング スループット] オプションを選択します。

Azure Cosmos DB では、共有スループット データベースに最大 25 個のコンテナーが適用されます。 最大値は、自動スケーリングまたは Standard (手動) スループットを持つデータベースに適用されます。

自動スケーリングは、データベースの整合性レベルには影響しません。

詳細については、整合性レベルに関する記事をご覧ください。

最大 RU/秒ごとのストレージ制限 (GB) は、データベースまたはコンテナーの最大 RU/秒を 10 で割った値です。 たとえば、最大 RU/秒が 20,000 RU/秒の場合、リソースは 2,000 GB のストレージをサポートできます。

使用可能な最大 RU/秒とストレージ オプションについては、「プロビジョニング スループットの自動スケーリングの制限」を参照してください。

データベースまたはコンテナーの最大スループットに関連するストレージ上限を超えた場合、Azure Cosmos DB によって、ストレージのそのレベルをサポートできる次に高い RU/秒に自動的に最大スループットが引き上げられます。

サンプル シナリオでは、50,000 RU/秒の最大 RU/秒で開始した場合 (5,000 RU/秒から 50,000 RU/秒の間でスケーリング)、最大で 5,000 GB のデータを格納できます。 ストレージ サイズが 5,001 GB に増えると、ストレージは 6,000 GB になり、新しい最大 RU/秒は 60,000 RU/秒です (6,000 RU/秒から 60,000 RU/秒の間でスケーリングされます)。

はい。 詳細については、「自動スケーリングのスループットをプロビジョニングする方法」を参照してください。

最大 RU/秒を変更すると、要求された値によっては、非同期操作が完了するまでに 4 から 6 時間かかる場合があります。 詳細については、こちらを参照してください。

最大 RU/秒 Tmax を引き上げる要求を送信すると、選択した最大 RU/秒に応じて、より高い最大 RU/秒をサポートするためにより多くのリソースがサービスによってプロビジョニングされます。 これが行われている間、既存のワークロードと操作は影響を受けません。 0.1 × Tmax_new から Tmax_new の新しいスケーリング範囲が準備できるまで、前の 0.1 × Tmax から Tmax の間でデータベースまたはコンテナーのスケーリングが引き続き実行されます。

最大 RU/秒を引き下げる場合に設定できる最小値は MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10) です (値は最も近い 1,000 RU/秒に丸められます)。

例 1: 最大 RU/秒が 20,000 RU/秒 (2,000 RU/秒から 20,000 RU/秒の間でスケーリング) の自動スケーリング コンテナーおよび 1,500 GB のストレージがあります。 最大 RU/秒に設定できる最小値は、MAX(1,000, 20,000 / 10, 1,500 × 10) = 15,000 RU/秒 (1,500 RU/秒から 15,000 RU/秒の間でスケーリング) です。

例 2: 100,000 RU/秒の最大 RU/秒と 100 GB のストレージを備えた自動スケーリング コンテナーがあります。 ここで、最大 RU/秒を最大 150,000 RU/秒 (15,000 RU/秒から 150,000 RU/秒の間でのスケーリング) までスケーリングするとします。 設定できる最大 RU/秒の最小値は、MAX(1,000, 150,000 / 10, 100 × 10) = 15,000 RU/秒 (1,500 RU/秒から 15,000 RU/秒の間でのスケーリング) です。

Shared スループット データベースの場合、最大 RU/秒を引き下げる場合に設定できる最小値は MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10, 1,000 + (MAX(Container count - 25, 0) × 1,000)) です (値は最も近い 1,000 RU/秒に丸められます)。

これらの数式と例は、設定できる最小自動スケーリングの最大 RU/秒に適用されます。 これらは、システムが自動的にスケーリングする 0.1 × Tmax から Tmax の範囲とは異なります。 最大 RU/秒に関係なく、システムは常に 0.1 × Tmax から Tmax の間でスケーリングします。

自動スケーリングでは、Time to Live (TTL) 操作は RU/秒のスケーリングには影響しません。 TTL が原因で消費された RU は、自動スケーリング コンテナーの課金対象の RU/s には含まれません。

たとえば、400 RU/秒から 4,000 RU/秒の自動スケーリング コンテナーの場合:

• 時間 1: T=0: コンテナーは使用されていません (TTL またはワークロードの要求はありません)。 課金対象の RU/秒は 400 RU/秒です。
• 時間 1: T=1: TTL は有効です。
• 時間 1: T=2: コンテナーが要求の取得を開始します。 要求は 1 秒で 1,000 RU を消費します。 200 RU/秒相当の TTL が使用されます。 請求可能の RU/秒は、引き続き 1,000 RU/秒です。 TTL の削除は、その実行タイミングに関係なく、自動スケーリング ロジックには影響しません。

最初に最大 RU/秒を選択すると、Azure Cosmos DB は、最大 RU/秒を 10,000 RU/秒で割って、必要な物理パーティションの数を取得することによってプロビジョニングを行います。 各物理パーティションは、最大 10,000 RU/秒と 50 GB のストレージをサポートできます。 ストレージのサイズが大きくなると、Azure Cosmos DB によってパーティションが自動的に分割され、ストレージの増加に対応するように物理パーティションが追加されます。 ストレージが関連する制限を超えた場合、Azure Cosmos DB は最大 RU/秒を増やします。

データベースまたはコンテナーの最大 RU/秒は、すべての物理パーティション全体で均等に分割されます。 1 つの物理パーティションでスケーリングできる合計スループットは、データベースまたはコンテナーの最大 RU/秒を物理パーティションの数で割った値です。

全ての使用された RU/秒がデータベースまたはコンテナーの最大 RU/秒を超えた場合、最大 RU/秒を超えた要求はスロットルされ、429 状態コードが返されます。 正規化された使用率が 100% を超える要求はスロットルされます。 正規化された使用率は、すべての物理パーティションにおける RU/秒の使用率の最大値として定義されます。

たとえば、最大スループットが 20,000 RU/秒で、P_1 および P_2 という 2 つの物理パーティションがあります。 各パーティションは、10,000 RU/秒にスケーリングできます。 ある 1 秒間で、P_1 が 6,000 RU を使用し、P_2 が 8,000 RU を使用した場合、正規化された使用率は MAX(6,000 RU / 10,000 RU, 8,000 RU / 10,000 RU) = 0.8 になります。

はい。 2 つのシナリオで、コード 429 エラーが表示される可能性があります。

最初に、全ての使用された RU/秒がデータベースまたはコンテナーの最大 RU/秒を超えると、サービスはそれに応じて要求をスロットルします。

2 番目に、他のパーティション キー値と比較して要求が過剰に多い論理パーティション キー値 (ホット パーティションなど) がある場合、基になる物理パーティションが RU/秒の予算を超える可能性があります。 ベスト プラクティスとして、ホット パーティションを回避するには、ストレージとスループットの両方が均等に分散される適切なパーティション キーを選択します。

たとえば、20,000 RU/秒の最大スループットのオプションを選択し、4 つの物理パーティションを含む 200 GB のストレージを使用している場合、各物理パーティションは 5,000 RU/秒に自動スケールアップできます。 ホット パーティションが特定の論理パーティション キー上にある場合、それが存在する基になる物理パーティションが 5,000 RU/秒または 100% の正規化された使用率を超えると、コード 429 エラーが表示されます。

自動スケーリングを使用するときにコード 429 エラーが発生しても、必ずしもデータベースまたはコンテナーに問題があることを示すわけではありません。 一般に、運用ワークロードで、要求の 1% から 5% にコード 429 エラーが発生し、エンド ツー エンドの待機時間が許容範囲内である場合、このエラーは RU/秒が完全に利用されているという正常な兆候です。 必要な操作はありません。

コード 429 レート制限エラーを解釈してデバッグする方法の詳細を確認してください。

はい。 詳細については、「正規化された RU/秒を監視する」を参照してください。

次のステップ

• Azure Cosmos DB データベースまたはコンテナーで自動スケーリングを有効にする方法について学習します。
• 自動スケーリングを使用したプロビジョニング スループットの利点について学習します。
• 論理および物理パーティションの詳細について学習します。