Azure Cosmos DBの「Provision Throughput for Containers and Databases」でまず押さえるべき結論は、新規または成長中の多くのワークロードでは、データベース単位ではなくコンテナー単位でスループットを設定するのが基本という点です。データベース単位の共有スループットはコストや初期構成を簡略化できる一方、特定コンテナーの性能保証が弱く、マルチテナント環境では「一部の利用者が他の利用者に影響する」リスクがあります。
今回の公式情報で実務上重要なのは、単なる設定手順ではなく、共有データベーススループットの使いどころがより限定的に整理されたことです。特に、Deployment Stampsを使うマルチテナント構成では、低トラフィックのstampでは共有スループットを初期選択肢にできる一方、高トラフィックやテナント間の性能分離が必要な場面では、専用コンテナースループットを使うべきと明確に読む必要があります。Microsoft Learn上のページ表示では最終更新日が2026年4月29日、GitHub履歴では2026年5月13日にDeployment Stamps関連の加筆と整形が確認できます。(Microsoft Learn)
Azure Cosmos DBのプロビジョニング済みスループットとは
Azure Cosmos DBのプロビジョニング済みスループットは、データベース操作に使える処理能力をRU/s、つまりRequest Units per secondで事前に割り当てる仕組みです。読み取り、書き込み、クエリなどの操作はRUを消費し、アイテムサイズ、インデックス設定、整合性レベル、クエリの複雑さによって消費量が変わります。たとえば、同じデータに対する同じクエリは同じRUを消費するため、RUは性能設計とコスト見積もりの共通単位として使えます。(Microsoft Learn)
Azure Cosmos DBでは、プロビジョニング済みスループットを主に次の2つの粒度で設定できます。
| 設定単位 | 特徴 | 向いている用途 |
|---|---|---|
| コンテナー単位 | 各コンテナーに専用のRU/sを割り当てる | 本番環境、性能予測が必要なAPI、重要な業務データ、テナント分離が必要な構成 |
| データベース単位 | データベース内の複数コンテナーでRU/sを共有する | 低トラフィックの複数コンテナー、移行初期、性能分離が不要な検証環境や一部のマルチテナント構成 |
この違いは、料金だけで判断すると失敗しやすいポイントです。コンテナー単位は最低RU/sが複数コンテナー分必要になるため高く見えることがありますが、負荷の高いコンテナーが他のコンテナーを巻き込まないため、運用時の安定性を確保しやすくなります。
変更点の要点は「共有スループットを安易に選ばない」こと
公式ドキュメントでは、共有データベーススループットは「ほとんどのワークロードでは推奨されない」と説明されています。理由は、複数コンテナーが同じスループットとパーティションを共有するため、あるコンテナーの負荷増加が他のコンテナーの応答時間や429エラーに影響する可能性があるためです。(Microsoft Learn)
特に注意したいのは、共有データベーススループットが「複数コンテナーをまとめれば安くなる便利な設定」ではなく、性能保証を個別コンテナーに求めない高度な設計上の選択肢として扱われている点です。
| 観点 | 従来よくある判断 | 2026年5月中旬時点での実務的な判断 |
|---|---|---|
| コスト | 複数コンテナーなら共有した方が安い | 低トラフィックで性能分離が不要な場合のみ検討する |
| 本番API | 共有スループットでも全体RU/sが足りればよい | 重要コンテナーは専用スループットを優先する |
| マルチテナント | テナントごとにコンテナーを作って共有する | noisy neighborを許容できるか確認する |
| 移行 | 既存DBの構造をそのまま移せる | 移行後にコンテナー単位へ切り替える計画を持つ |
| Deployment Stamps | stampごとに同じ設計を使う | 低トラフィックstampは共有、高トラフィックstampは専用を検討する |
共有データベーススループットは、オンプレミスやVM上のNoSQLデータベースからAzure Cosmos DBへ移行する初期段階では便利な場合があります。ただし、ワークロードが安定した後は、重要なコンテナーを専用スループットへ移すかどうかを再評価するべきです。(Microsoft Learn)
コンテナー単位のスループットが推奨される理由
コンテナー単位でスループットを設定すると、そのRU/sは対象コンテナー専用として予約されます。つまり、別コンテナーの負荷増加によって性能が奪われにくく、予測可能なスケーリングをしやすくなります。Microsoftの手順ページでも、コンテナー単位の設定は多くのワークロードで推奨されるアプローチと説明されています。(Microsoft Learn)
たとえば、ECサイトで次のようなコンテナーがあるとします。
| コンテナー | 主な用途 | 推奨される考え方 |
|---|---|---|
orders | 注文処理 | 専用スループットを設定し、ピーク時の遅延を防ぐ |
products | 商品参照 | 読み取りが多ければ専用またはautoscaleを検討する |
auditLogs | 監査ログ | 書き込み量が安定していればmanual、変動が大きければautoscaleを検討する |
settings | 設定値 | 低負荷なら共有候補。ただし重要処理と同居させない |
このように、業務上の重要度と負荷パターンが異なるコンテナーを同じ共有スループットに入れると、障害時の切り分けが難しくなります。特に注文、決済、認証、在庫更新のような遅延に弱い処理では、専用コンテナースループットを基本にするのが安全です。
データベース単位の共有スループットを使ってよいケース
共有データベーススループットが不要になったわけではありません。次のような条件を満たす場合は、選択肢として検討できます。
| 利用シーン | 使える理由 | 注意点 |
|---|---|---|
| 低トラフィックの複数コンテナー | それぞれに専用RU/sを割り当てるより初期コストを抑えやすい | 一部コンテナーの急増が他に影響する |
| 移行初期 | 既存のMongoDBやCassandraなどの構成を大きく変えずに始めやすい | 本番安定後に再設計が必要 |
| 低負荷のDeployment Stamp | stamp単位で小さく始めやすい | 高負荷stampでは専用コンテナーへ切り替える |
| 検証環境・開発環境 | 予測可能な性能よりコストや簡便性を優先できる | 本番と同じ前提で性能評価しない |
重要なのは、共有スループットを「永続的な本番標準」として採用しないことです。低負荷のうちは問題が見えにくくても、特定コンテナーのデータ量やアクセス数が増えると、HTTP 429エラーや応答時間のばらつきとして表面化します。
共有データベーススループットの制限と影響範囲
共有スループットのデータベースでは、標準、つまりmanual throughputの場合、最小400 RU/sで最大25個のコンテナーを共有できます。autoscaleの場合も共有スループットデータベース内で共有できるコンテナー数は25個までです。25個を超えて追加するコンテナーは、共有スループットとは別に専用スループットを設定する必要があります。既存の共有スループットデータベースで25個以上のコンテナーがあるアカウントについては、例外扱いが説明されています。(Microsoft Learn)
管理者は、まず次の環境を棚卸ししてください。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| 共有スループットDBの有無 | データベース単位でRU/sが設定されているか | 重要コンテナーが共有リソースに依存する |
| コンテナー数 | 25個に近い、または超えていないか | 将来の追加時に専用スループットが必要になる |
| 429エラー | 特定コンテナーやパーティションで集中していないか | 利用者から見ると遅延や失敗に見える |
| Normalized RU Consumption | 100%近辺が継続していないか | RU不足またはhot partitionを見逃す |
| パーティションキー | 値が偏っていないか | RUを増やしてもスロットリングが解消しない |
| IaC定義 | Bicep、Terraform、ARM、CLIで設定が明示されているか | 手動変更による構成ドリフトが起きる |
特に、Azure Portalの手順では、以前含まれていた「Share throughput across containers」オプションに関する説明が変更され、共有スループットが必要な高度なシナリオではSDKによる作成が案内されています。運用手順書や社内Wikiに古いポータル画面を前提にした記述がある場合は、更新が必要です。(Microsoft Learn)
manual throughputとautoscale throughputの選び方
Azure Cosmos DBのプロビジョニング済みスループットには、standard、つまりmanualと、autoscaleの2種類があります。manualは固定RU/sを割り当てる方式、autoscaleは最大RU/sであるTmaxを指定し、実際のスループットが0.1 * TmaxからTmaxの範囲で自動的に変動する方式です。(Microsoft Learn)
判断基準は次のように整理できます。
| ワークロード | 推奨候補 | 判断基準 |
|---|---|---|
| 常に高い負荷が続く | manual | 月内の多くの時間でRU/s使用率が高い |
| 日中だけ負荷が高い | autoscale | 夜間や休日に使用率が下がる |
| ピークが読めない | autoscale | セール、IoT、業務バッチなどで急増する |
| 新規アプリ | autoscaleまたは低めのmanual | 最初は実測値がないため、過剰割り当てを避ける |
| マルチリージョンかつ負荷が地域で偏る | dynamic autoscale | リージョンやパーティションごとに使用量が違う |
Microsoftの判断基準では、平均利用率が約66%を下回るならautoscaleがコスト面で有利になりやすく、66%を上回るならmanualが有利になりやすいとされています。ただし、これは利用パターンを見たうえでの目安です。実際にはAzure Monitorで7日から30日以上の履歴を確認し、最高利用率を時間単位で集計して判断すると失敗しにくくなります。(Microsoft Learn)
dynamic autoscaleで確認すべきポイント
autoscaleを使う場合は、dynamic autoscaleも確認しておきたい機能です。dynamic autoscaleは、リージョンや物理パーティションごとに独立してスケールするため、負荷が均一でないマルチリージョン構成やhot partitionが起きやすい構成で、不要なスケールアップを抑えやすくなります。2024年9月25日以降に作成されたAzure Cosmos DBアカウントでは既定で有効になっており、それ以前のアカウントではAzure Portal、CLI、PowerShell、REST APIなどで有効化できます。(Microsoft Learn)
確認すべきメトリックは次の3つです。
| メトリック | 目的 |
|---|---|
| Provisioned Throughput | autoscaleでその時間に課金対象となるRU/sを確認する |
| Normalized RU Consumption | スケールアップ、スケールダウン、RU不足の判断に使う |
| Autoscaled RU | dynamic autoscaleで各パーティションやリージョンがどうスケールしたか確認する |
プログラムで独自にスケーリング判断を行う場合も、SDKで読み取ったProvisionedThroughputをそのまま使うのではなく、Azure MonitorのNormalized RU Consumptionを基準にするのが安全です。公式FAQでも、ProvisionedThroughputは遅延を含む課金寄りの値であり、スケーリング判断には不正確になる可能性があると説明されています。(Microsoft Learn)
パーティションキーを見直さないとRU/sを増やしても解決しない
Azure Cosmos DBのスループット設計でよくある失敗は、429エラーを見てすぐRU/sだけを増やすことです。コンテナーに割り当てたスループットは物理パーティションに分散されますが、特定の論理パーティションキーにリクエストが集中すると、いわゆるhot partitionが発生します。この場合、全体のRU/sに余裕があっても、特定パーティションだけが上限に達して429エラーが発生することがあります。(Microsoft Learn)
たとえば、マルチテナントSaaSでパーティションキーにtenantIdを使う場合、大口テナントだけアクセスが突出すると、そのテナントの論理パーティションがhot partitionになりやすくなります。対策としては、次のような設計を検討します。
| 問題 | 対策例 |
|---|---|
| 一部テナントだけ極端にアクセスが多い | 大口テナントを専用コンテナーや専用stampへ移す |
| 時系列データで最新日時に書き込みが集中する | tenantId + 日付範囲など分散しやすいキーを検討する |
| 1つの論理パーティションが大きくなりすぎる | 階層型パーティションキーやデータモデル見直しを検討する |
| クエリが広範囲に散らばる | クエリパターンから逆算してパーティションキーを決める |
RU/sを増やす前に、Azure Monitorの「Normalized RU Consumption by PartitionKeyRangeID」や429エラーの発生箇所を確認し、問題が全体容量不足なのか、パーティション偏りなのかを切り分けることが重要です。
スケールアップ時は即時反映とは限らない
Azure Cosmos DBのスループット増加は、多くの場合すぐに反映されます。ただし、要求したRU/sが現在の物理パーティション構成で支えられない場合は、物理パーティションの分割が必要になり、非同期のスケールアップになることがあります。この処理は典型的に4〜6時間かかる場合があり、処理中にさらにスループット変更を行うとHTTP 423が返ることがあります。(Microsoft Learn)
大規模なデータ投入、移行、キャンペーン開始、バッチ処理の前には、直前にRU/sを上げるのではなく、事前にスケールアップして完了状態を確認しておくべきです。
| 作業 | 推奨タイミング | 理由 |
|---|---|---|
| 大量データ移行 | 移行開始前 | スケールアップ完了前に投入すると429が増える |
| セール開始 | ピーク前 | 当日の急な変更では間に合わない可能性がある |
| 新リージョン追加 | スケール操作と重ねない | スケールアップが一時停止する可能性がある |
| RU/s削減 | ピーク終了後 | レイテンシと429の落ち着きを確認してから下げる |
現在の物理パーティション数を確認し、現在の物理パーティション数 * 10,000 RU/sの範囲内であれば即時スケールしやすい、という考え方も実務では役立ちます。これを超える場合は、パーティション分割を前提に作業計画を立ててください。(Microsoft Learn)
共有と専用は後から直接変換できない
見落としやすい制約として、専用スループットを持つコンテナーを共有データベーススループットのコンテナーへ直接変換することはできません。逆に、共有データベーススループット上のコンテナーを専用スループットへ直接変換することもできません。目的のスループット設定を持つ新しいコンテナーへデータを移動する必要があり、NoSQL、MongoDB、Cassandra APIではContainer copy jobsが移行支援として案内されています。(Microsoft Learn)
一方で、manual throughputとautoscale throughputの切り替えは可能です。ただし、すべてをクライアントSDKだけで完結できるわけではありません。autoscale FAQでは、既存リソースのmanualとautoscaleの切り替えはAzure Portal、Azure CLI、PowerShell、Azure Management SDKなどで行い、Azure Cosmos DBクライアントSDKやARMテンプレートでは移行に使えないと説明されています。(Microsoft Learn)
移行計画では、次の順序で整理すると安全です。
| 手順 | 実施内容 |
|---|---|
| 現状確認 | データベース単位かコンテナー単位か、manualかautoscaleかを確認する |
| 重要度分類 | 注文、決済、認証など遅延に弱いコンテナーを洗い出す |
| メトリック確認 | 429、Normalized RU Consumption、ストレージ量、RU消費を確認する |
| 移行先設計 | 共有のまま残すコンテナーと専用化するコンテナーを分ける |
| データ移動 | 新コンテナー作成、データコピー、検証、切り替えを計画する |
| 切り戻し準備 | 旧コンテナー保持期間、読み書き停止手順、整合性確認を定義する |
Deployment Stamps構成での考え方
Deployment Stampsは、複数のテナントやワークロードを独立したstamp、つまりスケール単位に分けて展開するアーキテクチャパターンです。Azure Architecture Centerでは、stampごとに独立して管理・監視し、テナント数の増加に合わせて複数stampへスケールアウトする考え方が説明されています。(Microsoft Learn)
Azure Cosmos DBのスループット設計では、Deployment Stampsを使う場合に次のように判断すると実務的です。
| stampの状態 | 推奨構成 |
|---|---|
| 新規stampでテナント数が少ない | 共有データベーススループットを初期選択肢にできる |
| テナントごとの負荷差が小さい | 共有スループットでも運用しやすい |
| 特定テナントが急成長している | 専用コンテナーまたは専用stampへ分離する |
| SLAや性能分離が必要 | コンテナー単位の専用スループットを使う |
| 高トラフィックstamp | sharedではなくdedicatedを基本にする |
このとき、stampごとに設定がばらつくと、障害時の切り分けやコスト比較が難しくなります。BicepやTerraformなどのInfrastructure as Codeで、Cosmos DBアカウント、データベース、コンテナー、スループット、メトリック、アラートを定義し、stamp間の設定差分を管理することが重要です。Deployment Stampsの公式ガイドでも、複数stampの展開では自動化と構成ドリフトの抑制が重要とされています。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
Azure Cosmos DBを運用している管理者は、今回の公式情報を受けて、少なくとも次の確認を行ってください。
| チェック | 確認方法 | 判断 |
|---|---|---|
| 共有スループットDBがあるか | Azure Portal、CLI、IaC定義を確認 | 本番重要系なら専用化を検討 |
| 共有DB内のコンテナー数 | データベース配下のコンテナー数を確認 | 25個に近ければ今後の追加方針を決める |
| 429エラーの発生率 | Azure Monitorで確認 | 継続的ならRU不足またはhot partitionを疑う |
| RU使用率の履歴 | Normalized RU Consumptionを1時間粒度で確認 | autoscale/manualの見直し材料にする |
| ストレージ増加 | コンテナー別のデータ量を確認 | autoscale最大RU/sの下限上昇に注意 |
| パーティション偏り | PartitionKeyRangeID別の使用率を見る | 偏りが大きければデータモデルを見直す |
| 手順書の古さ | Portal画面や「Share throughput」の記述を確認 | 古い手順は更新する |
特に、共有スループットを使っている本番環境では、「いま問題がない」だけでは不十分です。今後のコンテナー追加、テナント増加、リージョン追加、データ移行、大量バッチの予定を含めて、どの時点で専用スループットへ移すかを決めておく必要があります。
開発者が実装で注意すべきポイント
開発者側では、RU/sの設定だけでなく、アプリケーションのリクエスト設計も見直す必要があります。
| 項目 | 実装上の注意点 |
|---|---|
| 429エラー | SDKのリトライに頼りきらず、継続発生時は設計を見直す |
| クエリ | クロスパーティションクエリや大量スキャンを避ける |
| インデックス | 不要なプロパティまで自動インデックス対象にしない |
| 整合性レベル | 強い整合性が必要な箇所と不要な箇所を分ける |
| バッチ処理 | 本番APIのピーク時間と重ねない |
| データ投入 | 事前にスループットを上げ、完了後に下げる |
| テナント分離 | 大口テナントを同じ共有リソースに置き続けない |
429エラーは、短時間であれば必ずしも障害ではありません。公式FAQでも、SDKやデータインポートツールは429に対して自動リトライを行うため、少量の429はRU/sを有効活用しているサインになり得ると説明されています。ただし、継続的な429やレイテンシ悪化がある場合は、RU/s増加、autoscale最大値の見直し、パーティションキー変更、専用コンテナー化のいずれかを検討してください。(Microsoft Learn)
どの構成を選ぶべきか
最後に、実務で使いやすい判断基準を整理します。
| 条件 | 推奨する選択 |
|---|---|
| 新規の本番ワークロード | コンテナー単位のスループットから始める |
| 負荷が安定している | manual throughputを検討する |
| 負荷が読みにくい | autoscale throughputを検討する |
| リージョンやパーティションごとの負荷差が大きい | dynamic autoscaleを確認する |
| 低負荷の複数コンテナー | 共有データベーススループットを検討できる |
| 重要コンテナーや大口テナント | 専用コンテナースループットに分離する |
| 移行初期 | 共有で始めても、安定後に専用化を再評価する |
| Deployment Stamps | 低トラフィックstampは共有、高トラフィックstampは専用を基本にする |
Azure Cosmos DBのスループット設計は、RU/sをいくつにするかだけの問題ではありません。コンテナー単位かデータベース単位か、manualかautoscaleか、パーティションキーが偏っていないか、移行後に直接変換できない設定を選んでいないかまで含めて判断する必要があります。
まずは既存環境の共有スループットDB、429エラー、Normalized RU Consumption、コンテナー数を確認してください。そのうえで、重要コンテナーは専用スループットへ、変動が大きいワークロードはautoscaleへ、低トラフィックのstampや検証環境は共有スループットへ、というように用途ごとに分けて設計するのが、2026年時点のAzure Cosmos DB運用で失敗しにくい進め方です。
コメント