標準 (手動) および自動スケーリングのプロビジョニング スループットから選択する方法
適用対象: 
NoSQL MongoDB Cassandra Gremlin Table
Azure Cosmos DB では、標準 (手動) と自動スケーリングの 2 つのプロビジョニング スループットの種類 (プラン) がサポートされています。 どちらのスループットの種類も、ハイ パフォーマンスとスケールを必要とするミッション クリティカルなワークロードに適しており、スループット、可用性、待機時間、および整合性に関する同じ Azure Cosmos DB SLA によって支えられています。
この記事では、ワークロードに対して標準 (手動) と自動スケーリングのプロビジョニング スループットから選択する方法について説明します。
プロビジョニング スループットの種類の概要
標準 (手動) と自動スケーリングの違いに進む前に、まず、プロビジョニング スループットが Azure Cosmos DB でどのように動作するかを理解しておくことが重要です。
プロビジョニング スループットを使用する場合は、ワークロードに必要な 1 秒あたりの要求ユニット数 (RU/秒) で測定されるスループットを設定します。 サービスによって、スループット要件をサポートするために必要な容量がプロビジョニングされます。 読み取り、書き込み、クエリなどのサービスに対するデータベース操作では、一定量の要求ユニット (RU) が消費されます。 詳細については、要求ユニットに関する記事を参照してください。
次の表は、標準 (手動) と自動スケーリング間の大まかな比較を示しています。
| 説明 | 標準 (手動) | 自動スケール |
|---|---|---|
| 最も適しているデータ | ワークロードのトラフィックが安定しているか、または予測できる | ワークロードのトラフィックが変動するか、または予測できない。 「自動スケーリングのユース ケース」を参照してください。 |
| しくみ | 手動で変更しない限り、静的な一定の RU/秒 T を経時的にプロビジョニングします。 1 秒あたり、最大 T RU/秒のスループットを使用できます。 たとえば、標準 (手動) の 400 RU/秒を設定した場合、スループットは 400 RU/秒のままになります。 |
システム上で超えてはいけない最高 (最大) RU/秒 Tmax を設定します。 システムでは、0.1* Tmax <= T <= Tmax のように、スループット T が自動的にスケーリングされます。 たとえば、自動スケーリングの最大 RU/秒を 4000 RU/秒に設定した場合、システムでは 400 から 4000 RU/秒の間でスケーリングが行われます。 |
| いつ使用するか | スループット容量 (RU/秒) を手動で管理し、自分でスケーリングしたいと考えている。 プロビジョニングされた RU/秒の使用率が一貫して高い。 プロビジョニングされた RU/秒 T を設定しており、1 か月の全時間数のうち、全容量を使用している時間が 66% 以上の場合、標準 (手動) のプロビジョニングされた RU/秒によって節約できると推定されます。これは、標準 (手動) で T を設定した場合と、自動スケーリングで同じ量の Tmax を設定した場合の比較に基づいています。 |
Azure Cosmos DB によって、使用率に基づいてスループット容量 (RU/秒) とスケールを管理したいと考えている。 RU/秒の使用率が変動するか、予測が難しい。 自動スケーリングの最大 RU/秒 Tmax を設定しており、1 か月の全時間数のうち、全 Tmax 量を使用している時間が 66% 以下の場合、自動スケーリングによって節約できると推定されます。これは、自動スケーリングの Tmax を設定した場合と、標準 (手動) スループットで同じ量の T を設定した場合の比較に基づいています。 |
| 課金モデル | 消費された RU 数に関係なく、プロビジョニングされた RU/ 秒に対して 1 時間ごとに課金が行われます。 例: 時間 1 と 2 の両方について、どちらの時間に対しても標準 (手動) のレートで 400 RU/秒の料金が請求されます。 |
その時間内にシステム上でスケーリングされた最高の RU/秒に対して、1 時間ごとに課金が行われます。 例: Tmax の 10%)自動スケーリングのプロビジョニング スループット レートでは、時間 1 での 3500 RU/秒、時間 2 での 400 RU/秒に対して料金が請求されます。 RU/秒あたりの自動スケーリング レートは、1.5 * 標準 (手動) レートです。 |
| プロビジョニングされた RU/秒を超えた場合の動作 | プロビジョニング対象に対して、RU/秒は静的なままです。 プロビジョニングされた RU を超えて瞬時に消費する要求では、レートが制限され、再試行までの待機時間を推奨する応答が返されます。 必要に応じて、RU/秒を手動で増減できます。 | システムによって、RU/秒が自動スケーリングの最大 RU/秒にスケールアップされます。 自動スケーリングの最大 RU/秒を超えて瞬時に消費する要求では、レートが制限され、再試行までの待機時間を推奨する応答が返されます。 |
トラフィック パターンを理解する
新しいアプリケーション
新しいアプリケーションを構築しており、トラフィック パターンをまだ把握していない場合は、最初にプロビジョニングの過多を避けるために、エントリ ポイント RU/秒 (最小 RU/秒) から始めることができます。 また、高いスケールを必要としない小規模なアプリケーションの場合は、コストを最適化するために最低限のエントリ ポイント RU/秒だけをプロビジョニングしてもかまいません。 予想されるトラフィックが少ない小規模なアプリケーションの場合は、サーバーレス容量モードを検討することもできます。
標準 (手動) と自動スケーリングのどちらを使用するかにかかわらず、次の点を考慮する必要があります。
400 RU/秒のエントリ ポイントで標準 (手動) RU/秒をプロビジョニングした場合、手動でスループットを変更しない限り、400 RU/秒を超えて消費することはできません。 料金は、標準 (手動) のプロビジョニング スループット レートで、1 時間あたり 400 RU/秒に対して請求されます。
最大 RU/s を 4000 RU/s にして自動スケーリングのスループットをプロビジョニングした場合、リソースは 400 から 4000 RU/s の間でスケーリングされます。 自動スケーリングのスループットでは RU/秒あたりの課金レートが標準 (手動) レートの 1.5 倍になるため、システムが最小の 400 RU/秒までスケールダウンされた時間数に対する請求額は、400 RU/秒を手動でプロビジョニングした場合よりも高くなります。 ただし、自動スケーリングでは、アプリケーション トラフィックが急増した場合、ユーザーの操作を必要とせずに最大 4000 RU/秒まで消費することができます。 一般的には、自動スケーリングでは 1.5 倍のレートで最大の RU/秒までいつでも消費できるというメリットを重視する必要があります。
スループットの要件を見積もるには、Azure Cosmos DB の容量計算ツールを使用します。
既存のアプリケーション
既存のアプリケーション上で標準 (手動) のプロビジョニング スループットを使用している場合は、Azure Monitor のメトリックを使用して、トラフィック パターンが自動スケーリングに適しているかどうかを判断できます。
まず、データベースまたはコンテナーの正規化された要求ユニット消費量メトリックを調べます。 正規化された使用率は、現在、標準 (手動) のプロビジョニング スループットをどの程度の量まで使用しているかを示す尺度です。 この数値が 100% に近いほど、プロビジョニングされた RU/秒をほぼすべて使用しています。 メトリックに関する詳細を確認してください。
次に、正規化された使用率が経時的にどのように変化するかを見極めます。 1 時間あたりの最も高い正規化された使用率を確認します。 次に、すべての時間における正規化された使用率の平均を計算します。 平均使用率が 66% 未満である場合は、データベースまたはコンテナーで自動スケーリングを有効にすることを検討してください。 これに対して、平均使用率が 66% を超えている場合は、標準 (手動) のプロビジョニング スループットのままにすることをお勧めします。
ヒント
マルチリージョン書き込みを使用するようにアカウントが構成されていて、複数のリージョンがある場合、手動と自動スケーリングの 100 RU/秒あたりのレートは同じです。 これは、自動スケーリングを有効にしても、使用率にかかわらず、追加コストが発生しないことを意味します。 そのため、複数のリージョンがある場合は、マルチリージョン書き込みで自動スケーリングを使用することをお勧めします。これにより、アプリケーションがスケーリングした RU/秒のみを支払うことによって節約できます。 マルチリージョン書き込みと 1 つのリージョンがある場合は、平均使用率を使用して、自動スケーリングによってコストを節約できるかどうかを判断します。
例
2 つの異なるワークロードの例を見て、手動または自動スケーリングのスループットに適しているかどうかを分析してみましょう。 一般的なアプローチを示すために、3 時間分の履歴を分析して、手動と自動スケーリングを使用した場合のコストの違いを判別します。 運用ワークロードの場合は、RU/秒の使用パターンを確認するために、7 から 30 日分 (可能な場合はより長い期間) の履歴を使用することをお勧めします。
注意
このドキュメントに示されているすべての例は、米国の非政府リージョンにデプロイされている Azure Cosmos DB アカウントの価格に基づいています。 価格と計算は、お客様が使用しているリージョンによって異なります。最新の価格情報については、「Azure Cosmos DB の価格」ページを参照してください。
想定:
- 現在、30,000 RU/秒の手動スループットがあるとします。
- リージョンは、シングルリージョン書き込みと 1 つのリージョンで構成されています。 複数のリージョンがある場合は、時間単位のコストをリージョンの数で乗算します。
- シングルリージョン書き込みのアカウントの手動のスループット (1 時間あたりの 100 RU/秒あたり 0.008 米ドル) と自動スケーリングのスループット (1 時間あたりの 100 RU/秒あたり 0.012 米ドル) には、公開されている価格レートを使用します。 詳細については、価格に関するページをご覧ください。
例 1:変動するワークロード (自動スケーリングを推奨)
まず、正規化された RU 消費量を確認します。 このワークロードには、正規化された RU 消費量が 6% から 100% である変動するトラフィックがあります。 100% に急増することがありますが、これは予測が困難です。ただし、多くの時間は使用率が低い状態です。
30,000 RU/秒の手動スループットのプロビジョニングと、最大 RU/秒を 30,000 に設定 (3000 - 30,000 RU/秒の間でスケーリングします) した自動スケーリングのコストを比較してみましょう。
履歴を分析してみましょう。 使用率が次の表に示されている状態であるとします。 これらの 3 時間の平均使用率は 39% です。 正規化された RU 消費量の平均は 66% 未満であるため、自動スケーリングを使用することによって節約できます。
時間 1 では、使用量が 6% の場合、自動スケーリングでは、最大 RU/秒の 10% (1 時間あたりの最小値) の RU/秒が請求されることに注意してください。 自動スケーリングのコストは、特定の時間において手動スループットよりも高くなることがありますが、すべての時間における平均使用率が 66% 未満である限り、全体では安くなります。
| 期間 | 使用率 | 自動スケーリングで課金される RU/秒 | オプション 1: 手動 30,000 RU/秒 | オプション 2:自動スケーリング 3000 - 30,000 RU/秒 |
|---|---|---|---|---|
| 時間 1 | 6% | 3000 | 30,000 * 0.008 / 100 = 2.40 ドル | 3000 * 0.012 / 100 = 0.36 ドル |
| 時間 2 | 100% | 30,000 | 30,000 * 0.008 / 100 = 2.40 ドル | 30,000 * 0.012 / 100 = 3.60 ドル |
| 時間 3 | 11% | 3300 | 30,000 * 0.008 / 100 = 2.40 ドル | 3300 * 0.012 / 100 = 0.40 ドル |
| 合計 | 7\.20 ドル | 4\.36 ドル (39% の節約) |
例 2:安定したワークロード (手動スループットを推奨)
このワークロードには、正規化された RU 消費量が 72% から 100% である安定したトラフィックがあります。 30,000 RU/秒がプロビジョニングされており、これは 21,600 から 30,000 RU/秒が消費されていることを意味します。
30,000 RU/秒の手動スループットのプロビジョニングと、最大 RU/秒を 30,000 に設定 (3000 - 30,000 RU/秒の間でスケーリングします) した自動スケーリングのコストを比較してみましょう。
使用率の履歴が次の表に示されている状態であるとします。 これらの 3 時間の平均使用率は 88% です。 正規化された RU 消費量の平均は 66% を超えているため、手動スループットを使用することによって節約できます。
一般に、1 か月の 730 時間全体の平均使用率が 66% を超える場合は、手動スループットを使用することによって節約できます。
| 期間 | 使用率 | 自動スケーリングで課金される RU/秒 | オプション 1: 手動 30,000 RU/秒 | オプション 2:自動スケーリング 3000 - 30,000 RU/秒 |
|---|---|---|---|---|
| 時間 1 | 72% | 21,600 | 30,000 * 0.008 / 100 = 2.40 ドル | 21600 * 0.012 / 100 = 2.59 ドル |
| 時間 2 | 93% | 28,000 | 30,000 * 0.008 / 100 = 2.40 ドル | 28,000 * 0.012 / 100 = 3.36 ドル |
| 時間 3 | 100% | 30,000 | 30,000 * 0.008 / 100 = 2.40 ドル | 30,000 * 0.012 / 100 = 3.60 ドル |
| 合計 | 7\.20 ドル | 9\.55 ドル |
ヒント
標準 (手動) のスループットでは、正規化された使用率メトリックを使用して、自動スケーリングに切り替えた場合に使用できる実際の RU/秒を見積もることができます。 特定の時点での正規化された使用率に、現在プロビジョニングされている標準 (手動) の RU/秒を乗算します。 たとえば、5000 RU/秒をプロビジョニングしており、正規化された使用率が 90% の場合、RU/秒の使用率は 0.9 * 5000 = 4500 RU/秒になります。 トラフィック パターンが変動するのに、プロビジョニングは過多または過少になっていると判断した場合は、自動スケーリングを有効にし、状況に応じて自動スケーリングの最大 RU/秒の設定を変更することができます。
平均使用率を計算する方法
自動スケーリングでは、1 時間の間にスケーリングされた最も高い RU/秒で課金されます。 経時的な正規化された RU 消費量を分析する場合は、平均を計算するときに、1 時間あたりの最も高い使用率を使用することが重要です。
すべての時間における最も高い使用率の平均を計算するには:
- 正規化された RU 消費量メトリックの [集計] を [最大] に設定します。
- [時間の粒度] に 1 時間を選択します。
- グラフのオプションに移動します。
- 縦棒グラフ オプションを選択します。
- [共有] で、 [Excel にダウンロード] オプションを選択します。 生成されたスプレッドシートから、すべての時間における平均使用率を計算します。
![時間あたりの正規化された RU 消費量を確認するには、1) [時間の粒度] で 1 時間を選択します。2) グラフの設定を編集します。3) 縦棒グラフ オプションを選択します。4) [共有] で、[Excel にダウンロード] オプションを選択して、すべての時間における平均を計算します。](media/how-to-choose-offer/variable-workload-highest-util-by-hour.png)
使用率を測定して監視する
スループットの種類を選択した後は、経時的にアプリケーションを監視し、必要に応じて調整を行う必要があります。
自動スケーリングを利用している場合は、Azure Monitor を使用して、プロビジョニングされた自動スケーリングの最大 RU/秒 (自動スケーリングの最大スループット) と、システム上で現在スケーリングされている RU/秒 (プロビジョニングされているスループット) を確認します。 以下に示す例は、ワークロードが変動するかまたは予測できず、自動スケーリングを使用している場合です。 トラフィックが存在しないときは、システム上で RU/秒が最大 RU/秒のうちの最小 10% までスケーリングされることに注意してください (ここでは、それぞれ 50,000 RU/秒と 5,000 RU/秒です)。
注意
標準 (手動) のプロビジョニング スループットを使用する場合、プロビジョニングされたスループットのメトリックとは、ユーザーが設定した値のことを言います。 自動スケーリングのスループットを使用する場合、このメトリックは、システム上で現在スケーリングされている RU/秒のことです。
次のステップ
- RU 計算ツールを使用して、新しいワークロードのスループットを見積もる。
- Azure Monitor を使用して、既存のワークロードを監視する。
- Azure Cosmos DB データベースまたはコンテナー上で自動スケーリングのスループットをプロビジョニングする方法を確認する。
- 自動スケーリングに関する FAQ を確認する。
- Azure Cosmos DB への移行のための容量計画を実行しようとしていますか? 容量計画のために、既存のデータベース クラスターに関する情報を使用できます。
- 既存のデータベース クラスター内の仮想コアとサーバーの数のみがわかっている場合は、仮想コア数または仮想 CPU 数を使用した要求ユニットの見積もりに関するページを参照してください
- 現在のデータベース ワークロードに対する通常の要求レートがわかっている場合は、Azure Cosmos DB Capacity Planner を使用した要求ユニットの見積もりに関するページを参照してください