Azure Cosmos DBでHTTP 429が出ても、すぐにRU/sを増やすとは限りません。まずエラーメッセージを読み、アプリで最終的に失敗しているか、再試行を含む応答時間が許容範囲か、特定のパーティションへ負荷が偏っていないかを確認します。
429には、データ操作のRU/s不足のほか、メタデータ要求の過多、一時的なサービスエラー、同じ論理パーティションでのトランザクション競合があります。原因を分けると、効果のないスループット増強や料金の増加を避けやすくなります。以下の切り分けは、Azure Cosmos DB for NoSQLのプロビジョニング済みスループット（手動・自動スケーリング）が対象です。
429の原因と最初の確認を分ける
| メッセージ・発生箇所 | 最初に調べること |
|---|---|
| データ操作の要求レート超過 | 429の割合、最終失敗、応答時間、パーティション別のRU使用率 |
| メタデータ操作の制限 | データベース・コンテナーの一覧取得やクライアント初期化を頻繁に行っていないか |
| 一時的なサービスエラー | 再試行後の結果と継続時間。RU/s増加では改善しない原因 |
| トランザクションの待機・競合 | 同じ論理パーティションに対する同時処理、処理時間、トランザクションの範囲 |
同じ429でも対処は異なります。発生日時、対象アカウント・データベース・コンテナー、操作の種類、SDKのバージョン、例外のメッセージと診断情報を控え、公式の429切り分け手順の該当する分岐へ進みます。
RUとRU/s、料金の基本
Request Unit（RU）は、データベース操作に必要なCPU・メモリ・IOPSなどを共通の単位で表したものです。RUは操作で消費する量、RU/sは1秒間に利用できるスループットを示します。約1KBの項目をIDとパーティションキーでポイント読み取りする操作が、1RUの基準です。項目サイズ、インデックス、クエリ、取得件数、整合性などで消費量は変わります。Request Unitsの公式説明
| 方式 | 確認する容量と費用 |
|---|---|
| 手動プロビジョニング | 設定したRU/s。時間内の最大プロビジョニング量が課金の基準になる |
| 自動スケーリング | 最大RU/sと実際のスケール状況。最大値を設定しても429が必ずなくなるわけではない |
| サーバーレス | 実際に消費したRUが課金の基準。この記事のプロビジョニング向け判断をそのまま適用しない |
費用はスループットだけでなく、ストレージ、リージョン、構成、契約条件でも変わります。RU/sを一時的に上げて戻した場合も、実行した時間の料金に影響するため、変更前後の設定と時刻を記録してください。金額は対象リージョンの現行条件を、請求の公式説明と料金案内で確認します。
1．SDKの再試行後に成功しているか確認する
Azure Cosmos DBのクライアントSDKは、通常、429に対して内部で再試行します。そのためAzure Monitorに429があっても、後続の試行で成功し、アプリ側では429の例外を受け取っていない場合があります。
- Azure portalで対象のCosmos DBアカウントを開き、［Insights］→［Requests］の［Total Requests by Status Code］を確認する。
- データベース・コンテナーと時間帯を絞り、総要求数に対する429の割合を見る。
- 同じ時間帯のアプリログで、最終的な失敗件数、タイムアウト、再試行を含む処理時間を確認する。
- 再試行の回数・待ち時間に関するSDK設定と、業務として許容できる応答時間を照合する。
公式資料では、パーティションへの負荷が均等で、処理全体の遅延が許容範囲なら、429が1～5％程度あることはRU/sを有効利用している状態の場合があると説明されています。この数字は「5％未満なら必ず安全」という合格基準ではありません。全体の割合が低くても、一部の顧客やキーに失敗が集中している可能性があるため、次の確認も行います。
2．パーティション別にRUの偏りを見る
［Insights］→［Throughput］の［Normalized RU Consumption (%) By PartitionKeyRangeID］を開き、対象のデータベースとコンテナーを絞ります。これは物理パーティションごとの利用状況を見る手がかりです。全体の平均だけで判断せず、特定の範囲が継続して高い状態になっていないか確認してください。
アクセスが一部の論理パーティションキーに集中すると、それを収容する物理パーティションが先に制限へ達することがあります。単発のアクセス増なのか、特定の顧客・日付などへ常に集中する設計なのかを分けます。
| 確認結果 | 対応の方向 |
|---|---|
| 負荷が均等で、遅延・最終失敗が問題になる | 操作ごとのRUを見直したうえで、RU/sの増加を検討する |
| 特定のキー・パーティションへ集中する | 処理の分散、キー設計、同時実行の調整を検討する。RU/s増加だけを恒久策にしない |
| 短い時間帯だけ集中する | 処理開始時刻や要求の集中を調べ、分散できる処理を見直す |
| 一部の利用者だけ遅い | 全体の429率に加え、その利用者のキーとアプリ処理を追う |
どの論理キーがRUを使っているか、どの操作が429になっているかを調べるには、診断ログが必要になる場合があります。Log Analyticsへの取り込みには別料金が生じるため、収集対象と調査期間を決めます。キー設計を変更する場合も、単に稼働中の設定を書き換えて終わるとは考えず、データ移行やアプリへの影響を含めて計画してください。
3．自動スケーリングでも429が出る理由
自動スケーリングでも、最大RU/sを超える要求やホットパーティションによって429が発生します。また、瞬間的な負荷上昇では、正規化RU使用率が100％になっても、設定した最大RU/sまでスケールしない場合があります。
「最大RU/sに到達していないから容量には余裕がある」とは断定せず、429の発生時刻、パーティション別の利用状況、継続時間、アプリの処理時間を並べて判断します。手動方式と同じく、偏りを残したまま最大値だけを増やすと、必要以上の費用につながり得ます。
4．RU/s増加で解決しない原因を確認する
メタデータ要求を頻繁に繰り返している
データベース・コンテナーの作成や一覧取得、スループット情報の照会などには、データ操作とは別のシステム予約済みの上限があります。この制限に対して、コンテナーのRU/sを増やすことは有効ではありません。
［Insights］→［System］の［Metadata Requests By Status Code］を確認します。リクエストごとにCosmosClientを作り直していないか、コンテナー名の取得や存在確認を繰り返していないかを調べ、クライアントの再利用、構成情報のキャッシュ、必要なバックオフを検討してください。
一時的なサービスエラーが続いている
メッセージが一時的なサービスエラーを示す場合も、RU/s増加は対処になりません。再試行後の結果を確認し、数分にわたり継続する場合は、発生時間と診断情報を添えてAzure portalからサポートへ問い合わせます。
同じキーでトランザクションが競合している
メッセージにTXN_WAIT_FOR_TRANSACTION_ENDがある場合は、同じ論理パーティションキーに対する同時トランザクションを調べます。トランザクションバッチやストアドプロシージャの範囲・実行時間を小さくし、指数バックオフを伴う再試行、書き込み先の分散、必要な場合の同一キーへの書き込み直列化を検討します。
アプリ全体を一律に直列化するのではなく、競合が起きるキーと処理を特定して変更します。変更後は、処理の正しさと待ち時間の両方を確認してください。
変更前後に同じ条件で確認する
- 対象のAPI、手動・自動スケーリング、データベース共有・コンテナー専用の区分を記録する。
- 変更前のRU/sまたは最大RU/s、429率、最終失敗率、処理時間を控える。
- SDKの応答からRequest Chargeを確認し、同じデータ・操作・取得件数で比較する。
- ポイント読み取り、取得する項目、インデックス、処理の集中を見直し、必要な変更を選ぶ。
- 変更後も全体の平均だけでなく、問題のあったキー・利用者・時間帯を確認する。
- エラーの改善と費用への影響を確認し、追加した診断ログの扱いも見直す。
AIコーディング支援を使う場合は、Azure Cosmos DB Agent Kitも、パーティション設計やクエリ、SDKの使い方をレビューする補助にできます。提案を適用する前に、自社のアクセスパターンと要件に合うかを確認し、同じ条件で変更前後を比較してください。
429への対応は、件数をゼロにすることだけが目的ではありません。業務の成功率と応答時間を満たしながら、原因に合う設定・設計へ直すことが判断の軸です。MongoDB APIやサーバーレスについては、それぞれの制限と診断手順を確認し、この記事の割合やRU/sの判断を一律に当てはめないでください。
コメント