次の方法で共有

自動スケーリングのスループットを使用して Azure Cosmos DB コンテナーとデータベースを作成する

  • [アーティクル]

適用対象: NoSQL MongoDB Cassandra Gremlin Table

Azure Cosmos DB では、データベースとコンテナーに対して標準 (手動) または自動スケーリングのプロビジョニング スループットを構成できます。 Azure Cosmos DB で自動スケーリング プロビジョニング スループットを使用すると、お使いのデータベースまたはコンテナーのスループット (RU/秒) を自動的かつ即座にスケーリングできます。

自動スケーリングのプロビジョニング スループットは、トラフィック パターンが変動し予測できないミッション クリティカルなワークロードに最適であり、ハイ パフォーマンスとスケーリングに対する SLA を必要とします。 既定では、自動スケーリングは、最もアクティブなリージョンとパーティションに基づいてワークロードをスケーリングします。 リージョンとパーティション間で異なるワークロード パターンを持つ一様でないワークロードの場合、このスケーリングによって不要なスケールアップが発生する可能性があります。 動的スケーリング (動的自動スケーリング) は自動スケーリングによりプロビジョニングされるスループットの強化機能で、リージョンごとおよびパーティション レベルごとの使用状況に基づいて、このような均一ではないワークロードを個別にスケーリングするのに役立ちます。 動的スケーリングを使用すると、ホット パーティションが頻繁に発生する場合や複数のリージョンがある場合にコストを削減できます。

自動スケールの利点

自動スケーリングのプロビジョニング スループットが構成された Azure Cosmos DB データベースとコンテナーには、次の利点があります。

  • Simple の場合: 自動スケーリングを利用すると、カスタム スクリプトの作成や手動による容量のスケーリングに伴う RU/秒の管理の複雑さが解消されます。

  • スケーラブル: データベースとコンテナーでは、必要に応じて、プロビジョニング スループットが自動的にスケーリングされます。 クライアント接続やアプリケーションは中断されず、Azure Cosmos DB SLA への影響もありません。

  • コスト効率: 自動スケーリングを利用すると、使用されていないときにスケールダウンすることで、RU/秒の使用率とコストの使用状況を最適化できます。 ワークロードで必要とされるリソースに対してのみ、時間単位で料金を支払います。 自動スケーリングの最大 RU/秒 (Tmax) を設定しており、1 か月の全時間数のうち、全 Tmax 量を使用している時間が 66% 以下の場合、オートスケールによって節約できます。 動的スケーリングに加えて、高可用性を実現するためにセカンダリ リージョンを追加すると、各リージョンとパーティションが実際の使用状況に基づいて個別にスケーリングされるため、コスト効率が高くなります。 詳細については、「標準 (手動) および自動スケーリングのプロビジョニング スループットから選択する方法」を参照してください。

  • 高可用性: 自動スケーリングを使用するデータベースおよびコンテナーでは、グローバルに分散されたフォールト トレラントで可用性の高い同一の Azure Cosmos DB バックエンドが使用され、データの持続性と高可用性が保証されます。

自動スケーリングのユース ケース

自動スケーリングのユース ケースを以下に示します。

  • 変動する予測不可能なワークロード: ワークロードの使用率が変動したり、急増を予測できなかったりする場合には、自動スケーリングを利用して、使用状況に基づいて自動的にスケールアップおよびスケールダウンすることができます。 例としては、小売の Web サイトで季節性に応じてトラフィック パターンが異なる場合、IOT ワークロードが 1 日のさまざまな時間に急増する場合、基幹業務アプリケーションにおいて 1 か月や 1 年に数回、ピーク時の使用率が見られる場合などがあります。 自動スケーリングを利用すると、ピーク時または平均の容量に対して手動でプロビジョニングする必要がなくなります。

  • 新しいアプリケーション: 新しいアプリケーションを開発していて、必要なスループット (RU/秒) がわからない場合は、自動スケーリングを利用して簡単に始めることができます。 自動スケーリングのエントリ ポイントである 100 から 1000 RU/秒で開始し、使用状況を監視して、時間の経過と共に適切な RU/秒を判断することができます。

  • 使用頻度の低いアプリケーション: 1 日、1 週間、または 1 か月の間に数回、数時間だけ使用されるアプリケーションがある場合 (低ボリュームのアプリケーション/Web/ブログ サイトなど)。 自動スケーリングでは、ピーク時の使用に対応できるよう容量が調整され、ピーク時が過ぎるとスケールダウンされます。

  • 開発およびテストのワークロード: 自身やチームで Azure Cosmos DB データベースとコンテナーを業務時間中は使うが、夜間や週末には必要ない場合、自動スケーリングにより、使っていないときに最小にスケールダウンすることで、コストを節約できます。

  • スケジュールされた運用ワークロード/クエリ: アイドル期間中に実行することを検討しているスケジュールされた一連の要求、操作、またはクエリがある場合には、自動スケーリングを利用して簡単に実行できます。 ワークロードを実行する必要がある場合、スループットは必要な値まで自動的にスケーリングされ、その後スケールダウンされます。

これらの問題に対処するカスタム ソリューションを構築する場合、膨大な時間を必要とするだけでなく、アプリケーションの構成やコードが複雑になります。 自動スケーリングを利用すれば、上述したシナリオをすぐに実現でき、容量をカスタムまたは手動でスケーリングする必要がなくなります。

動的スケーリングのユース ケース

動的スケーリングのユース ケースには、次のような場合があります。

  • ディザスター リカバリーのために、トラフィックの多いプライマリ リージョンとセカンダリ パッシブ リージョンを持つデータベース ワークロード。
    • 動的スケーリングを使用する場合、複数のリージョンで高可用性を実現するほうがコスト効率が高くなります。 アイドル状態では、セカンダリ リージョンは個別に自動的にスケールダウンします。 また、セカンダリ リージョンは、アクティブになった場合や、プライマリ リージョンからの書き込みレプリケーション トラフィックを処理するときに自動的にスケールアップされます。
  • 複数リージョンのデータベース ワークロード。
    • 多くの場合、これらのワークロードでは 1 日を通して、自然なトラフィックの増加と急減により、リージョン間の要求の不均一な分散が観察されます。 たとえば、グローバルに分散したタイム ゾーン全体で営業時間中にデータベースがアクティブになる場合があります。

自動スケーリングのプロビジョニング スループットのしくみ

コンテナーとデータベースを自動スケーリングに構成するときは、必要な最大スループット Tmax を指定します。 Azure Cosmos DB では、0.1*Tmax <= T <= Tmax のように、スループット T がスケーリングされます。 たとえば、最大スループットを 20,000 RU/秒に設定すると、スループットは 2,000 から 20,000 RU/秒の間でスケーリングされます。 スケーリングは自動的かつ瞬時に行われるため、どの時点でも、プロビジョニングされた Tmax まで遅延なく使用できます。

料金は、1 時間の枠内でシステムがスケーリングされた最大スループット T に対して、時間単位で請求されます。 動的スケーリングが有効になっている場合、スケーリングは各物理パーティションとリージョンでの RU/秒の使用量に基づいて行われます。 各パーティションとリージョンが個別にスケーリングされるため、不要なスケールアップが回避され、均一ではないワークロードのコスト削減につながる可能性があります。

自動スケーリングの最大スループット Tmax のエントリ ポイントは 1000 RU/秒で開始され、100 から 1000 RU/秒の間でスケーリングされます。 Tmax は 1000 RU/秒の増分で設定でき、値はいつでも変更できます。

たとえば、1000 RU/秒のコレクションと 2 つのパーティションがある場合、各パーティションを最大 500 RU/秒にできます。 1 時間のアクティビティでは、使用率は次のようになります。

リージョン パーティション スループット 稼働率 メモ
書き込み P1 <= 500 RU/秒 100% 書き込み操作の 50 RU/秒、読み取り操作の 450 RU/秒で構成される 500 RU/秒。
書き込み P2 <= 200 RU/秒 40% すべて読み取り操作で構成される 200 RU/秒。
既読 P1 <= 150 RU/秒 30% 書き込みリージョンからレプリケートされた書き込みに使用される 50 RU/秒で構成される 150 RU/秒。 このリージョンの読み取り操作には、100 RU/秒が使用されます。
既読 P2 <= 50 RU/秒 10%

動的スケーリングを使用しない場合、すべてのパーティションが、最もアクセスが集中しているパーティションに基づいて均一にスケーリングされることになります。 この場合、最もアクセスが集中しているパーティションは 100% の使用率であるため、書き込みリージョンと読み取りリージョンの両方で、すべてのパーティションが 1,000 RU/秒にスケーリングされ、合計のスループットは 2,000 RU/秒にスケーリングされることになります。

動的スケーリングを使用すれば、各パーティションとリージョンのスループットは個別にスケーリングされるため、合計のスループットは 900 RU/秒にスケーリングされると考えられます。これは、実際のトラフィック パターンをより適切に反映するもので、コストを削減できます。

既存のリソースに対する自動スケーリングの有効化

Azure portal、CLI、または PowerShell を使用して、既存のデータベースまたはコンテナーで自動スケーリングを有効にできます。 自動スケーリングと標準 (手動) のプロビジョニング スループット間の切り替えは、いつでも行うことができます。 詳細については、こちらのドキュメントを参照してください。

自動スケーリングのスループットとストレージ制限

Tmax の値に応じて、データベースまたはコンテナーでは合計 0.1 * Tmax GB を保存できます。 このストレージ容量に達すると、アプリケーションに影響を与えることなく、新しいストレージ値に基づいて最大 RU/秒が自動的に増やされます。

たとえば、50,000 RU/秒の最大 RU/秒で開始した場合 (5000 から 50,000 RU/秒の間でスケーリングされます)、最大で 5000 GB のデータを格納できます。 5,000 GB を超えると (現在、ストレージが 6,000 GB になっているなど)、新しい最大 RU/秒は 60,000 RU/秒になります (6,000 から 60,000 RU/秒の間でスケーリングされます)。

自動スケーリングによるデータベース レベルのスループットを使用する場合は、100 GB のストレージを超えない限り、最初の 25 個のコンテナーによって、自動スケーリングの最大の 1000 RU/秒 (100 から 1000 RU/秒の間でスケーリングされます) を共有できます。 詳細については、こちらのドキュメントを参照してください。

動的スケーリングの有効化

動的スケーリングは、2024 年 9 月 25 日以降に作成されたすべての Azure Cosmos DB アカウントに対して既定で有効になります。 古いアカウントでこの機能を有効にする場合は、Azure PowerShell/CLI/Rest API を使ってプログラムで、または Azure portal の機能ウィンドウから有効にすることができます。

  1. Azure portal で Azure Cosmos DB アカウントに移動します。

  2. 機能のページに移動します。

  3. [動的スケーリング (リージョンごとおよびパーティションごとのオートスケール)] の機能を見つけて有効にします。

    Azure portal の [動的スケーリング (リージョンごとおよびパーティションごとのオートスケール)] 機能のスクリーンショット。

    重要

    この機能はアカウント レベルで有効になっているため、アカウント内のすべてのオートスケール コンテナーと共有スループット データベースにこの機能が自動的に適用されます。 この機能を有効にしても、手動スループットを使用しているアカウント内のリソースには影響しません。 動的スケーリングを利用するには、手動リソースをオートスケールに変更する必要があります。 この機能を有効にしても、ダウンタイムやパフォーマンスへの影響はありません。 この機能は、サーバーレス アカウントには適用できません。

監視 メトリック

次のメトリックを使用して、自動スケーリングと動的スケーリングを監視できます。

メトリックの名前 Definition メトリックの使用方法
プロビジョニングされたスループット 1 時間の間にスケーリングされた最も高い RU/秒の集計値を示し、その時間にスケーリングされた RU/秒の合計を表します。 Provisioned Throughput メトリックを使用して、各時間に課金される RU/秒を確認できます。 自動スケーリングでは、各時間の最もアクティブなパーティションに基づいて課金され、同じ設定がすべてのパーティションとリージョンに適用されます。 動的オートスケールでは、各パーティション レベルとリージョン レベルで、各時間にスケーリングされた最も高い RU/秒の集計値に対して課金されます。
Normalized RU Consumption (正規化された RU 消費量) このメトリックは、各パーティション レベルおよびリージョン レベルでプロビジョニングされた RU/秒と消費された RU/秒の比率を表します。 このメトリックを使用して、オートスケールの最大スループットが過少にプロビジョニングされているか、過剰にプロビジョニングされているかどうかを判断します。

メトリック値が常に 100% であり、アプリケーションでレート制限 (429 エラー コード) が表示されている場合は、さらに RU/秒が必要である可能性があります。 これに対し、このメトリック値が低く、レート制限がない場合は、RU/秒を最適化してスケールダウンする余地がある可能性があります。 コード 429 レート制限エラーを解釈してデバッグする方法の詳細を確認してください。

Normalized RU Consumption メトリックには、セカンダリ リージョンの読み取りトラフィックに加えて、プライマリ リージョンからの書き込みレプリケーション トラフィックが原因でセカンダリ リージョンで消費された RU/秒が反映されます。
オートスケール RU 動的オートスケールが有効なアカウントに対してのみ、各パーティション レベルとリージョン レベルで動的にスケーリングされたプロビジョニング済みスループットを表示します。 このメトリックを使用して、各リージョンのパーティションの使用状況に基づいて個別にスケーリングする方法を確認できます。

Azure Monitor メトリック - Autoscaled RUを使用して、パーティションとリージョン間で新しい自動スケーリングがどのように適用されているかを分析します。 目的のデータベース アカウントとコンテナーにフィルターを適用し、物理パーティション ID メトリックでフィルター処理または分割します。 このメトリックは、さまざまなリージョンのすべてのパーティションを示します。

比較 – 手動または自動スケーリングのスループットで構成されたコンテナー

標準 (手動) および自動スケーリングのスループットから選択する方法の詳細については、こちらのドキュメントを参照してください。

標準 (手動) のスループットを利用したコンテナー 自動スケーリングのスループットを利用したコンテナー
プロビジョニング スループット (RU/秒) 手動でプロビジョニングします。 ワークロードの使用パターンに基づいて、自動的に瞬時にスケーリングされます。
要求/操作のレート制限 (429) 使用量がプロビジョニング済みの容量を超えた場合、発生する可能性があります。 構成したオートスケールのスループットの範囲内で RU/秒を使用する場合は、発生しません。
容量計画 キャパシティ プランニングを行い、必要なスループットを正確に設定する必要があります。 容量計画と容量管理は、システムによって自動的に行われます。
料金 1 時間あたりの標準 (手動) の RU/秒レートを使用して、手動でプロビジョニングされた RU/秒に対して、時間単位で料金を支払います。 システムによって 1 時間の枠内でスケールアップされた最大 RU/秒に対して、時間単位で料金を支払います。

単一の書き込みリージョンのアカウントの場合、1 時間あたりの自動スケーリングの RU/秒レートを使用して、使用された RU/秒に対して時間単位で料金を支払います。

書き込みリージョンが複数あるアカウントの場合、自動スケーリングに対する追加料金は発生しません。 同じ 1 時間あたりの複数リージョン書き込み RU/秒レートを使用して、使用されたスループットに対して時間単位で料金を支払います。

最適なワークロードの種類 予測可能で安定したワークロード 予測不可能で変動するワークロード

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

大規模なリソースを標準プロビジョニング スループットからオートスケールに移行するユーザーは、Azure CLI スクリプトを使用して、Azure サブスクリプション内のすべてのスループット リソースをオートスケールに移行できます。 詳細については、「オートスケールへの変換」を参照してください。

次のステップ