Partager via

Opérations de limitation dans Azure Service Bus

  • Article

Les solutions cloud natives laissent à penser qu’elles procurent des ressources illimitées adaptables à votre charge de travail. Même si cette idée vaut plus pour le cloud que pour les systèmes locaux, le cloud présente quand même des limites. Ces limites peuvent occasionner une limitation des requêtes pour les applications clientes aussi bien au niveau standard qu’au niveau premium, comme nous le verrons dans cet article.

Limitation au niveau Standard

Le niveau standard de Service Bus fonctionne comme une installation multilocataire avec un modèle tarifaire basé sur le paiement à l’utilisation. Ici, les différents espaces de noms présents dans un même cluster partagent les ressources allouées. Le niveau Standard est recommandé pour les environnements de développement et d’assurance qualité équipés de systèmes de production à faible rendement.

Par le passé, Service Bus imposait des limitations grossières qui dépendaient strictement de l’utilisation des ressources. Ceci dit, il est possible d’affiner la logique de limitation et de définir un comportement de limitation prévisible pour tous les espaces de noms qui partagent ces ressources.

Pour assurer une utilisation et une répartition équitables des ressources entre les différents espaces de noms Service Bus Standard qui utilisent les mêmes ressources, Service Bus standard utilise actuellement la logique de limitation basée sur les crédits.

Remarque

Il est important de noter que la limitation n’est pas une nouveauté, que ce soit pour Azure Service Bus ou n’importe quel service cloud natif.

La limitation basée sur les crédits consiste simplement à affiner la façon dont différents espaces de noms partagent des ressources dans un environnement multilocataire de niveau Standard, ce qui permet une utilisation équitable des ressources partagées par tous les espaces de noms.

Qu’est-ce que la limitation basée sur les crédits ?

La limitation basée sur les crédits limite le nombre d’opérations qui peuvent être effectuées dans un espace de noms donné au cours d’une période déterminée. Voici le workflow de la limitation basée sur les crédits.

  • Au début de chaque période, Service Bus attribue des crédits à chaque espace de noms.
  • Les opérations exécutées par les applications clientes expéditrices ou réceptrices sont comptabilisées au titre de ces crédits (et soustraites des crédits disponibles).
  • Si les crédits sont épuisés, les opérations suivantes sont limitées jusqu’au début de la période suivante.
  • Les crédits sont réapprovisionnés au début de la période suivante.

Quelles sont les limites de crédit ?

Les limites de crédit actuellement définies sont de 1000 crédits par seconde (par espace de noms). Toutes les opérations ne sont pas égales. Voici le coût en crédits de chacune des opérations.

Opération Coût en crédits
Opérations de données (Send, SendAsync, Receive, ReceiveAsync, Peek) 1 crédit par message
Opérations de gestion (Create, Read, Update, Delete sur les files d’attente, les rubriques, les abonnements, les filtres) 10 crédits

Notes

Lors de l’envoi à une rubrique, chaque message est évalué par rapport à un ou plusieurs filtres avant d’être mis à disposition sur l’abonnement. Chaque évaluation de filtre est également décomptée de la limite de crédit (c’est-à-dire 1 crédit par évaluation de filtre).

Comment savoir si je suis limité ?

Lorsque les requêtes d’application cliente sont limitées, l’application cliente reçoit la réponse suivante du serveur.

The request was terminated because the entity is being throttled. Error code: 50009. Please wait 2 seconds and try again.

Comment éviter d’être limité ?

Dans le cas des ressources partagées, il est important d’instaurer une utilisation équitable entre les différents espaces de noms Service Bus qui partagent ces ressources. La limitation est l’assurance qu’en cas de pic dans une charge de travail, les autres charges de travail utilisant les mêmes ressources ne seront pas limitées. Comme nous le verrons plus loin dans cet article, le fait que les Kits de développement logiciel (SDK) clients et autres produits PaaS Azure intègrent la stratégie de nouvelle tentative par défaut écarte tout risque de limitation. Les requêtes limitées font l’objet de nouvelles tentatives avec un backoff exponentiel, et finissent par passer une fois les crédits réapprovisionnés.

Bien entendu, certaines applications peuvent être sensibles à la limitation. Dans ce cas, nous vous recommandons de migrer votre espace de noms Service Bus actuel de standard à premium . Pour la migration, vous pouvez allouer des ressources dédiées à votre espace de noms Service Bus et effectuer un scale-up sur les ressources de telle sorte que si votre charge de travail connaît un pic, vous aurez moins de risques d’être limité. Par ailleurs, une fois que votre charge de travail est redescendue à des niveaux normaux, vous pouvez effectuer un scale-down sur les ressources allouées à votre espace de noms.

Limitation dans le niveau Premium

Le niveau Premium de Service Bus alloue des ressources dédiées, sous la forme d’unités de messagerie, à chaque espace de noms configuré par le client. Ces ressources dédiées offrent un débit et une latence prévisibles et sont recommandées pour les systèmes de production sensibles ou à haut rendement. De plus, le niveau Premium permet aussi aux clients d’effectuer le scale-up de leur capacité de rendement quand la charge de travail connaît un pic. Pour plus d’informations, consultez Mettre à jour automatiquement les unités de messagerie d’un espace de noms Azure Service Bus.

Comment fonctionne la limitation dans Service Bus Premium ?

Du fait de l’allocation exclusive de ressources dans le cas du niveau Premium, la limitation est intimement liée aux limites des ressources allouées à l’espace de noms. Si le nombre de requêtes est supérieur à la capacité de traitement actuelle des ressources, les requêtes sont limitées.

Comment savoir si je suis limité ?

Il existe différentes façons d’identifier la limitation dans le niveau Premium.

  • Les demandes limitées figurent dans les métriques des demandes d’Azure Monitor pour identifier le nombre de demandes qui ont été limitées.
  • Une utilisation du processeur élevée indique que l’allocation de ressources actuelle est élevée et que les requêtes risquent d’être limitées si la charge de travail actuelle ne diminue pas.
  • Une utilisation de la mémoire élevée indique que l’allocation de ressources actuelle est élevée et que les requêtes risquent d’être limitées si la charge de travail actuelle ne diminue pas.

Comment éviter d’être limité ?

Étant donné que l’espace de noms Service Bus Premium a déjà des ressources dédiées, vous pouvez réduire la possibilité d’être limité en effectuant un scale-up sur le nombre d’unités de messagerie allouées à votre espace de noms dans l’hypothèse (ou en anticipation) d’un pic dans la charge de travail. Pour plus d’informations, consultez Mettre à jour automatiquement les unités de messagerie d’un espace de noms Azure Service Bus.

FAQ

En quoi la limitation affecte-t-elle mon application ?

Quand une demande est limitée, cela sous-entend que le service est occupé ; il fait face à plus de demandes que les ressources ne l’autorisent. Si la même opération est retentée après quelques instants, la demande est honorée une fois que le service est sorti de sa charge de travail actuelle.

La limitation étant le comportement attendu de tous les services cloud natifs, nous avons mis en place la logique de nouvelle tentative dans le SDK Service Bus lui-même. Par défaut, les nouvelles tentatives automatiques sont définies avec un backoff exponentiel pour éviter qu’une même demande soit limitée à chaque fois. La logique de nouvelle tentative par défaut s’applique à chaque opération.

Remarque

Le code de traitement des messages qui appelle d’autres services tiers peut également être limité par ces autres services. Pour plus d’informations sur la façon de gérer ces scénarios, consultez la documentation sur le modèle de limitation.

La limitation entraîne-t-elle une perte de données ?

Azure Service Bus est optimisé pour la persistance. Nous veillons en effet à ce que toutes les données envoyées à Service Bus soient validées dans le stockage avant que le service ne reconnaisse l’issue favorable de la requête.

Une fois que Service Bus a accusé réception de la demande, cela signifie que Service Bus a correctement traité la demande. Si Service Bus retourne un échec, cela signifie que Service Bus n’a pas pu traiter la demande et que l’application cliente doit tenter à nouveau la demande.

Cependant, quand une demande est limitée, cela sous-entend que le service ne peut pas accepter et traiter la demande dans l’immédiat en raison des limites de ressources. Cela n’est pas le signe d’une perte de données ; cela signifie simplement que Service Bus n’a pas examiné la demande. Dans ce cas, la stratégie de nouvelle tentative par défaut du SDK Service Bus offre la garantie que la demande finit par être traitée.

Contenu connexe

Pour plus d’informations et des exemples d’utilisation de la messagerie Service Bus, consultez les rubriques avancées suivantes :