Microsoft Fabric でのスロットリング

Microsoft Fabricでは、ワークロードが容量または REST API 要求の制限を超えたときに、調整を使用してサービスのパフォーマンスと信頼性を維持します。 この記事では、調整のしくみ、HTTP 429 応答を解釈する方法、およびFABRIC API クォータを効果的に処理するアプリケーションを設計する方法について説明します。

API クォータ制限

Microsoft Fabricでは、REST API の統合クォータを REST API 用に導入しています。 このモデルでは、API 要求は、ユーザーまたは サービス プリンシパルごとに適用される ID レベルのクォータによって制御されます。

目標は、自動化、CI/CD、エージェント駆動型のシナリオ全体で、管理された API グループの 一貫した予測可能な調整エクスペリエンス です。

以前は、各Microsoft Fabric REST API によって独自の独立した調整規則が適用され、多くの場合、エンドポイント間で一貫性のない動作が発生していました。 その結果、ワークロードが調整される可能性がある時期を予測することは困難でした。特に、複数の API と対話し、異なる制限の対象となった自動化シナリオの場合です。

API クォータの導入により、Fabricはより一貫性のある ID ベースのアプローチに移行します。 API の使用量は、ID ごとに適用される統合クォータによって制御されるようになりました。これにより、FABRIC API 全体で、より明確で予測可能な調整モデルが提供されます。 ただし、API 全体のクォータに加えて、個々の API 固有の調整制限が引き続き適用される場合があることに注意してください。

API リファレンス ページでクォータが文書化されている場合は、そのエンドポイント固有の制限をその API に対して権限のあるものとして扱います。 API リファレンス ページに数値クォータが一覧表示されない場合は、 Retry-Afterを受け入れ、有界再試行を適用し、バーストを回避することで、429 応答を処理するようにアプリケーションを設計します。

クォータ モデルのしくみ

各 ID (ユーザーまたはサービス プリンシパル) には、API トラフィックのさまざまなカテゴリを管理する複数の独立したクォータ バケットが割り当てられます。 ID が要求を送信すると、要求は、使用されている API カテゴリのクォータに対して評価されます。

次の 3 つの統合クォータがあります。

1. プラットフォーム API の統合クォータ - プラットフォーム API 専用。
2. ジョブ スケジューラ API の統合クォータ - ジョブ スケジューラ API 専用。
3. 長時間実行オペレーション API 向けの統合クォータ — 長時間実行オペレーション API 専用。

これらのクォータは独立しているため、あるカテゴリのアクティビティは別のカテゴリのクォータを消費しません。 たとえば、サービス プリンシパルは、使用可能なプラットフォーム API の統合クォータに影響を与えることなく、ジョブ スケジューラ API の完全な統合クォータを使用できます。 この分離により、特殊な API 領域の大量のワークロードが一般的な API 操作に影響を与えなくなり、さまざまな種類の要求で予測可能な調整動作が可能になります。

API の適用

API クォータは ID ごとに適用されます。つまり、すべてのユーザー、サービス プリンシパル、またはマネージド ID が独自の独立したクォータ割り当てを受け取ります。 クォータは ID 間で共有されることはなく、対象となるすべてのFabric API は、その ID に関連付けられている共通クォータ バケットから消費されます。

その結果、1 つの ID による API の使用は、他の ID には影響しません。 たとえば、頻繁に使用されるサービス プリンシパルは、他のユーザーやアプリケーションのクォータに影響を与えることなく、独自の API クォータを使い果たすことができます。

同様に、ID がクォータ制限に達し、調整された場合、その調整はその ID にのみ適用され、他の ID は引き続き正常に動作します。 この分離により、ワークロード間でより予測可能で管理しやすい API 使用量が提供されます。

クォータの適用階層

すべての API 要求は、ユーザー アカウントまたはサービス プリンシパルのいずれかの ID で始まります。 その ID が Fabric API を呼び出すと、要求は最初に共有 API クォータからの容量を消費します。これは、API ごとではなく ID ごとに適用されます。 このクォータは、参加しているすべての API で共有される一元化された調整メカニズムとして機能し、1 つの ID が割り当てられた要求レートを超えないようにします。

共有 API クォータに対して要求が評価されると、API 固有の調整制限も適用されます。 これらの制限は共有クォータとは無関係であり、特定の API にのみ存在する場合があります。 その結果、要求が正常に処理されるようにするには、ID レベルの API クォータと該当する個々の API 制限の両方を満たす必要があります。

実際には、共有 API クォータは API 全体で一貫した調整エクスペリエンスを提供しますが、個々の API の制限では、追加の保護を必要とする特定のサービスが引き続き保護されます。 そのため、API 呼び出しは、ID エンティティが共有クォータを使い果たしたため、または特定の API エンドポイントの上限に達したために、スロットリングされることがあります。

主な概念:

• ID ベースの適用: クォータは、ユーザーまたはサービス プリンシパルごとに個別に追跡されます。
• 複数の API 間で共有: 異なる API へのリクエストは、同一の API クォータ プールを消費します。
• 調整のみ: API クォータは要求レートを制御しますが、承認やアクセス許可には影響しません。
• 二重適用: 共有 API クォータと API 固有の制限の両方が、要求ごとに評価されます。
• 最も制限の厳しい制限が優先されます。共有クォータまたは該当する API 固有の制限を超えると、要求が調整されます。

クォータが消費される仕組み

すべての API 要求は、呼び出し元 ID の API クォータ バケットからのクォータを使用します。 その ID によって行われたすべての要求は、呼び出される API に関係なく、同じ共有クォータにカウントされます。

クォータ ウィンドウと更新

API クォータは、固定の 60 秒のウィンドウを使用して適用されます。 現在のウィンドウが終了すると、クォータ バケットがすべて一度に補充されます。 ウィンドウ期間中、クォータが徐々に回復することはありません。

タイムラインの例

Second 0   → Quota window begins. Bucket is full (300 requests available).
Second 1   → 300 requests are made. Bucket is exhausted.
             Additional requests receive HTTP 429 (Too Many Requests).

Seconds 2-59 → All additional requests continue to receive HTTP 429.
               No quota is restored during the window.

Second 60  → New quota window begins.
             Bucket is fully replenished (300 requests available).
             Requests are accepted again.

実用的な影響

• ウィンドウの開始時にリクエストをバースト的に送信することは許可されていますが、そうすると、そのウィンドウの残り時間はその ID にスロットル制限がかかる可能性があります。
• 60秒間全体にリクエストを均等に分散することで、スロットリングを回避できます。
• 常に Retry-After レスポンスヘッダーに従ってください。 スロットリングされたリクエストを再試行するまでにどのくらい待機するかを示します。

API別のレート制限の詳細

Microsoft Fabricでは統一された調整カテゴリと共有クォータの概念が提供されますが、実際のレート制限は API によって異なる場合があります。 呼び出す特定の API の [調整制限] セクションを常に確認してください。

スロットリング メッセージ

調整が発生すると、Fabricは HTTP 状態コード 429 (要求が多すぎます) を返します。 Fabricは、2 つの異なる理由で 429 状態コードを返します。それぞれは、応答本文で異なるerrorCodeによって識別されます。

• レート制限を超えました (RequestBlocked)
• 容量の上限を超えました (CapacityLimitExceeded)

応答の errorCode 値を調べて、発生した条件と応答方法を判断します。

レート制限を超えました (RequestBlocked)

ユーザーが時間枠内に事前に定義された制限を超える要求を多数送信すると、Fabricはそのユーザーからの要求をさらに短時間調整します。

この場合、Fabricは HTTP 状態コード 429 (要求が多すぎます) を返し、応答に Retry-After HTTP ヘッダーが含まれています。呼び出し元のアプリケーションが呼び出しを再試行するまでに待機する秒数を示します。 応答本文では、 RequestBlocked エラー コードが使用されます。

{
    "errorCode": "RequestBlocked",
    "message": "Request is blocked by the upstream service until: 2/18/2026 10:45:04 PM (UTC)"
}

このエラーが発生したら、要求を再試行する前に、 Retry-After ヘッダーで指定された期間待機します。

次のスクリーンショットは応答の例を示しています。この例では、呼び出しを再試行する前にユーザーが 55 秒待機していることを示しています。

容量の制限を超えました (CapacityLimitExceeded)

Fabricは、組織のFabric容量が制限を超えた場合に、HTTP 状態コード 429 (要求が多すぎます) も返します。 レート制限とは異なり、この調整は、特定の呼び出し元が行う API 呼び出しの数によって発生することはありません。 代わりに、ご利用の容量で消費されるコンピューティング（容量ユニット）が、購入した Fabric SKU の上限を超えたときに発生します。 応答本文では、 CapacityLimitExceeded エラー コードが使用されます。

{
    "errorCode": "CapacityLimitExceeded",
    "message": "Your organization's Fabric compute capacity has exceeded its limits. Try again later."
}

このエラーが発生したら、後でもう一度要求を試してください。 このスロットリングは、個々の要求頻度ではなく、お使いのキャパシティ全体で消費されるコンピューティング リソースに依存するため、キャパシティのコンピューティング使用量が上限内に戻るまで、すぐに再試行しても成功する可能性は低いです。 このエラーが頻繁に発生する場合は、Fabric容量のスケールアップまたはスケールアウトを検討してください。 容量ユニット、SKU、および Fabric 容量の消費方法の詳細については、容量サイズを計画するを参照してください。

考慮事項と制限事項

すべての Fabric 管理 API とコア パブリック API は、スロットルされる可能性があります。

Fabric REST API を呼び出すアプリケーションを設計するときは、次の考慮事項に注意してください。

• 呼び出される呼び出し元 ID と API に対してクォータが適用されます。 個別の ID が必ずしも同じ要求カウンターを共有するとは限りませんが、各呼び出し元は API の文書化された制限に従う必要があります。
• 多くのレート制限は、1 分間に評価されます。 制限を超えた場合は、 Retry-After 値を待ってから、さらに多くの要求を送信します。
• 容量調整は、要求レート調整とは異なります。 CapacityLimitExceededは、呼び出し元が 1 分あたりの API クォータを超えたのではなく、Fabric容量がオーバーロードされていることを示します。
• 容量調整エラーをすぐに再試行しても成功する可能性は低くなります。 制限付き再試行ポリシーを使用し、エラーが解決しない場合は容量の使用状況を調査します。
• 大量の統合の場合は、リスト操作、一括操作、またはバッチ操作が使用可能な場合に優先し、変更頻度の低いメタデータをキャッシュし、時間の経過と同時に要求を均等に分散させます。
• ページネーションをサポートする API では、先頭から広範囲なクエリを繰り返し実行するのではなく、継続トークンを使用してください。

よく寄せられる質問

API クォータまたは容量制限に達したかどうかを確認するにはどうすればよいですか?

429 応答本文の errorCode を確認します。 RequestBlocked は、要求レートがサービスのスロットル制限を超えたことを意味します。 CapacityLimitExceededは、Fabric容量で消費されたコンピューティングが、購入した SKU の制限を超えた場合を意味します。

クォータはいつリセットされますか?

多くのFabric REST API レート制限は、1 分間のウィンドウで評価されます。 応答に Retry-After ヘッダーが含まれている場合は、再試行する前にその値を権限のある待機時間として使用します。

要求を行う前に、残りの API クォータを確認できますか?

Fabric REST API 応答では、すべての API に対する一般的な残りのクォータ カウンターは提供されません。 クライアントが 429 応答を検出し、Retry-After に従い、スロットリングが発生した場合にリクエスト量を減らせるように実装します。

速度制限を受ける可能性を減らすには、どうすればよいですか?

使用可能な場合は一括操作とバッチ操作を使用し、多くの単一リソース呼び出しよりもリスト API を優先し、頻繁にアクセスされるメタデータをキャッシュし、突然のトラフィック バーストを回避します。 永続的な容量調整の場合は、Microsoft Fabric容量メトリック アプリを使用して、過負荷の容量とワークロードを識別します。

429 応答ごとに同じように再試行する必要がありますか?

No. RequestBlockedの場合は、Retry-After ヘッダーを待ってから、有界再試行ポリシーを使用して再試行します。 CapacityLimitExceededの場合は、指数バックオフで後で再試行し、問題が解決しない場合は容量使用率を調査します。

関連コンテンツ

• Microsoft Fabric REST API の使用
• スコープ
• MICROSOFT FABRIC REST API のトラブルシューティング
• 容量のサイズを計画する
• Fabric容量の調整について理解する
• Microsoft Fabric 容量メトリック アプリ