Limitation du débit dans Microsoft Fabric

Microsoft Fabric utilise la limitation pour maintenir les performances et la fiabilité du service lorsque les charges de travail dépassent la capacité ou les limites de requête de l’API REST. Cet article explique comment la limitation fonctionne, comment interpréter les réponses HTTP 429 et comment concevoir des applications qui gèrent efficacement les quotas d’API Fabric.

Limites de quota de l’API

Microsoft Fabric introduit un quota unifié pour les API REST pour ses API REST. Dans ce modèle, les demandes d’API sont régies par des quotas au niveau de l’identité appliqués par utilisateur ou principal de service.

L’objectif est d’offrir une expérience cohérente et prévisible en matière de limitation du débit pour les groupes d’API soumis à gouvernance, dans les scénarios d’automatisation, de CI/CD et pilotés par des agents.

Auparavant, chaque API REST Microsoft Fabric appliquait ses propres règles indépendantes de limitation du débit, ce qui entraînait souvent un comportement incohérent d’un point de terminaison à l’autre. Par conséquent, il était difficile de prédire quand une charge de travail peut être limitée, en particulier pour les scénarios d’automatisation qui interagissent avec plusieurs API et sont soumis à différentes limites.

Avec l’introduction du quota d’API, Fabric passe à une approche plus cohérente basée sur l’identité. La consommation d’API est désormais régie par un quota unifié appliqué par identité, fournissant un modèle de limitation plus clair et plus prévisible entre les API Fabric. Toutefois, il est important de noter que certaines limites de limitation spécifiques à l’API peuvent toujours s’appliquer en plus du quota global des API.

Note

Le quota d’API existe uniquement pour régir et limiter les demandes d’API. Elle ne représente pas la capacité de calcul, de stockage ou de facturation de Fabric, et cela n’a aucun effet sur votre consommation de capacité Fabric ni sur son coût.

Lorsqu’une page de référence d’API documente un quota, traitez cette limite spécifique au point de terminaison comme faisant autorité pour cette API. Si une page de référence d’API ne répertorie pas de quota numérique, concevez votre application pour gérer 429 réponses en respectant Retry-After, en appliquant des nouvelles tentatives limitées et en évitant les rafales.

Fonctionnement du modèle de quota

Diagramme concéputal de la façon dont les quotas circulent.

Chaque identité , qu’il s’agisse d’un utilisateur ou d’un principal de service, est affectée à plusieurs compartiments de quota indépendants qui régissent différentes catégories de trafic d’API. Lorsque l’identité envoie une requête, la requête est évaluée par rapport au quota de la catégorie d’API utilisée.

Il existe trois quotas unifiés :

  1. Quota unifié pour les API de plateforme : dédié aux API de plateforme.
  2. Quota unifié pour les API du planificateur de travaux : dédié aux API du planificateur de travaux.
  3. Quota unifié pour les API d'opérations de longue durée — dédié aux API d'opérations de longue durée.
Quota Limit
Quota unifié pour les API de plateforme 200 appels/min
Quota unifié pour les API de l’ordonnanceur de tâches 200 appels/min
Quota unifié pour les API d’opérations de longue durée 200 appels/min

Étant donné que ces quotas sont indépendants, l’activité dans une catégorie ne consomme pas de quota d’une autre catégorie. Par exemple, un principal de service peut consommer son quota unifié complet pour les API du planificateur de travaux sans affecter son quota unifié disponible pour les API de plateforme. Cette séparation garantit que les charges de travail à volume élevé dans les zones d’API spécialisées n’ont pas d’impact sur les opérations d’API générales et permettent un comportement de limitation plus prévisible entre différents types de requêtes.

Application de l’API

Le quota d’API est appliqué par identité, ce qui signifie que chaque utilisateur, principal de service ou identité managée reçoit son propre allocation de quota indépendante. Les quotas ne sont jamais partagés entre les identités, et toutes les API éligibles Fabric consomment à partir d’un compartiment de quota commun associé à cette identité.

Par conséquent, l’utilisation de l’API par une identité n’a aucun impact sur une autre identité. Par exemple, un principal de service fortement utilisé peut épuiser son propre quota d’API sans affecter les quotas d’autres utilisateurs ou applications.

De même, si une identité atteint sa limite de quota et est limitée, cette limitation s’applique uniquement à cette identité, tandis que d’autres identités continuent de fonctionner normalement. Cette isolation fournit une consommation d’API plus prévisible et gérable entre les charges de travail.

Hiérarchie d’application des quotas

Diagramme conceptuel de la hiérarchie de quota.

Chaque demande d’API commence par une identité ( un compte d’utilisateur ou un principal de service). Lorsque cette identité appelle une API Fabric, la requête consomme d’abord la capacité à partir du quota d’API partagées, qui est appliquée par identité plutôt que par API. Ce quota agit comme un mécanisme de limitation centralisé qui est partagé entre toutes les API participantes, ce qui garantit qu’une identité unique ne peut pas dépasser son taux de requête alloué.

Une fois la requête évaluée par rapport au quota d’API partagées, toutes les limites de limitation spécifiques à l’API sont également appliquées. Ces limites sont indépendantes du quota partagé et peuvent exister uniquement pour certaines API. Par conséquent, une demande doit satisfaire à la fois le quota d’API au niveau de l’identité et toutes les limites d’API individuelles applicables pour être traitées avec succès.

En pratique, le quota d’API partagées offre une expérience de limitation cohérente entre les API, tandis que les limites d’API individuelles continuent de protéger des services spécifiques qui nécessitent des protections supplémentaires. Un appel d’API peut donc être limité, soit parce que l’identité a épuisé son quota partagé, soit parce qu’elle a atteint la limite d’un point de terminaison d’API particulier.

Concepts clés :

  • Application basée sur l’identité : le quota est suivi séparément pour chaque utilisateur ou principal de service.
  • Commun à toutes les API : les requêtes envoyées à différentes API puisent dans le même pool de quota d’API.
  • Limitation du débit uniquement : le quota des API contrôle le débit des requêtes, mais n’affecte ni l’autorisation ni les droits d’accès.
  • Application double : le quota d’API partagées et toutes les limites spécifiques à l’API sont évaluées pour chaque requête.
  • La limite la plus restrictive prévaut : une requête est soumise à une limitation de débit dès que le quota partagé ou une limite propre à l’API concernée est dépassé.

Comment le quota est consommé

Chaque requête API consomme du quota dans le compartiment de quota des API de l’identité appelante. Toutes les requêtes effectuées par cette identité comptent vers le même quota partagé, quelle que soit l’API appelée.

Période de quota et renouvellement

Le quota d’API est appliqué à l’aide d’une fenêtre fixe de 60 secondes. La réserve de quota est réapprovisionnée en une seule fois lorsque la fenêtre actuelle prend fin. Le quota ne se reconstitue pas progressivement sur la période.

Note

Si une identité consomme son quota entier au début de la fenêtre, elle ne peut pas effectuer de requêtes supplémentaires jusqu’à ce que la fenêtre de 60 secondes suivante commence.

Exemple de chronologie

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.

Implications pratiques

  • Il est autorisé d’envoyer des requêtes en rafale au début d’une fenêtre, mais cela peut ensuite soumettre l’identité à une limitation de débit pendant le reste de cette fenêtre.
  • Répartir les requêtes uniformément sur une période de 60 secondes permet d’éviter la limitation du débit.
  • Respectez toujours l’en-tête de réponse Retry-After. Il indique combien de temps attendre avant de réessayer une requête soumise à une limitation de débit.

Détails de la limite de débit par API

Bien que Microsoft Fabric fournit des catégories de limitation unifiées et des concepts de quota partagé, les limites de débit réelles peuvent varier selon l’API. Vérifiez toujours la section Limites de limitation du débit de l’API concernée.

Note

Vérifiez toujours la section Limites de limitation du débit de l’API concernée.

Message de limitation du débit

En cas de limitation du débit, Fabric renvoie un code d’état HTTP 429 (Trop de requêtes). Fabric retourne un code d’état 429 pour deux raisons distinctes, chacune identifiée par un autre errorCode dans le corps de la réponse :

Inspectez la errorCode valeur dans la réponse pour déterminer quelle condition s’est produite et comment répondre.

Limite de débit dépassée (RequestBlocked)

Lorsqu’un utilisateur envoie de nombreuses requêtes qui dépassent une limite prédéterminée pendant une fenêtre de temps, Fabric limite les demandes supplémentaires de cet utilisateur pendant une courte période.

Dans ce cas, Fabric retourne un code d’état HTTP 429 (Trop de requêtes) avec un Retry-After en-tête HTTP dans la réponse, indiquant le nombre de secondes pendant lesquelles l’application appelante doit attendre avant de réessayer l’appel. Le corps de la réponse utilise le code d’erreur RequestBlocked :

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

Lorsque vous recevez cette erreur, attendez la durée spécifiée dans l’en-tête Retry-After avant de réessayer la demande.

La capture d’écran suivante montre un exemple de réponse, ce qui suggère que l’utilisateur attend 55 secondes avant de réessayer l’appel.

Capture d’écran montrant un en-tête de réponse HTTP.

Limite de capacité dépassée (CapacityLimitExceeded)

Fabric retourne également un code d'état HTTP 429 (trop de requêtes) lorsque la capacité de Fabric de votre organisation a dépassé ses limites. Contrairement à la limitation de débit, cette limitation n’est pas due au nombre d’appels d’API effectués par un appelant spécifique. En revanche, cela se produit lorsque la capacité de calcul (unités de capacité) consommée dans votre capacité dépasse les limites du SKU Fabric que vous avez acheté. Le corps de la réponse utilise le code d’erreur CapacityLimitExceeded :

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

Lorsque vous recevez cette erreur, réessayez la demande ultérieurement. Étant donné que cette limitation dépend des ressources de calcul globales consommées par votre capacité plutôt que de votre taux de requêtes individuel, il est peu probable qu’une nouvelle tentative immédiate réussisse tant que l’utilisation des ressources de calcul de la capacité n’est pas revenue dans les limites autorisées. Si vous rencontrez cette erreur fréquemment, envisagez d’effectuer un scale-up ou d’effectuer un scale-out de votre capacité de Fabric. Pour plus d’informations sur les unités de capacité, les références SKU et la manière dont la capacité Fabric est consommée, consultez Planifier la taille de votre capacité.

Considérations et limitations

Chaque API d’administration Fabric et chaque API publique principale peuvent faire l’objet d’une limitation de débit.

Gardez ces considérations à l’esprit lorsque vous concevez des applications qui appellent Fabric API REST :

  • Les quotas s’appliquent à l’identité de l’appelant et à l’API appelée. Les identités distinctes ne partagent pas nécessairement le même compteur de requête, mais chaque appelant doit toujours suivre les limites documentées de l’API.
  • De nombreuses limites de débit sont évaluées sur des fenêtres d’une minute. Si vous dépassez une limite, attendez la Retry-After valeur avant d’envoyer plus de demandes.
  • La limitation de capacité est différente de la limitation du taux de requêtes. CapacityLimitExceededindique que la capacité Fabric est surchargée, et non que l’appelant a dépassé un quota d’API par minute.
  • Réessayer immédiatement après une erreur de limitation de capacité a peu de chances d’aboutir. Utilisez une stratégie de nouvelle tentative limitée et examinez l’utilisation de la capacité si l’erreur persiste.
  • Pour les intégrations à volume élevé, préférez les opérations de liste, de bloc ou de traitement par lots lorsqu’elles sont disponibles, cachez les métadonnées qui changent rarement et répartissez les demandes uniformément au fil du temps.
  • Pour les API qui prennent en charge la pagination, utilisez des jetons de continuation au lieu d’effectuer des requêtes étendues répétées à partir du début.

Questions fréquemment posées

Comment savoir si j’ai atteint un quota d’API ou une limite de capacité ?

Vérifiez le errorCode dans le corps de la réponse 429. RequestBlocked signifie que le taux de requête a dépassé les limites de limitation du service. CapacityLimitExceededsignifie que le calcul consommé sur la capacité de Fabric a dépassé les limites de la référence SKU achetée.

Quand mon quota est-il réinitialisé ?

De nombreuses limites de débit de l’API REST Fabric sont évaluées sur des périodes d’une minute. Si la réponse inclut un Retry-After en-tête, utilisez cette valeur comme temps d’attente faisant autorité avant de réessayer.

Puis-je vérifier mon quota d’API restant avant d’effectuer une demande ?

Les réponses de l’API REST de Fabric ne fournissent pas de compteur général du quota restant pour toutes les API. Créez des clients afin qu’ils puissent détecter les réponses 429, tenir compte de Retry-After et réduire le volume des requêtes en cas de limitation du débit.

Comment puis-je réduire les risques de faire l’objet d’une limitation de débit ?

Utilisez des opérations en bloc et par lots lorsqu’elles sont disponibles, préférez les API de liste par rapport à de nombreux appels à ressource unique, cachez les métadonnées fréquemment sollicitées et évitez les rafales soudaines de trafic. Pour une limitation de capacité persistante, utilisez l’application Microsoft Fabric Métriques de capacité pour identifier les capacités et charges de travail surchargées.

Dois-je réessayer toutes les 429 réponses de la même façon ?

Non. Pour RequestBlocked, attendez l’en-tête Retry-After, puis réessayez avec une stratégie de nouvelle tentative bornée. Pour CapacityLimitExceeded, réessayez ultérieurement avec une temporisation exponentielle et vérifiez l’utilisation de la capacité si le problème persiste.

Contenu connexe

  • Last updated on