Exporter (0) Imprimer
Développer tout

Meilleures pratiques pour optimiser la rentabilité et l'extensibilité des solutions de messagerie basée sur les files d'attente sur Azure

Mis à jour: mars 2015

Rédaction : Amit Srivastava et Valery Mizonov

Révision : Brad Calder, Sidney Higa, Christian Martinez, Steve Marx, Curt Peterson, Paolo Salvatori et Trace Young

Cet article présente des descriptions normatives d'aide et les meilleures pratiques pour créer des solutions de messagerie basée sur les files d'attente évolutives, très efficaces et rentables sur la plateforme Azure. Le public visé par cet article comprend les architectes et les développeurs qui conçoivent et mettent en œuvre des solutions basées sur le cloud exploitant la plateforme de services de stockage de files d'attenteAzure.

Une solution de messagerie basée sur les files d'attente traditionnelle repose sur un emplacement de stockage des messages appelé « file d'attente de messages », qui n'est autre qu'un référentiel pour les données envoyées ou reçues depuis un ou plusieurs participants, généralement au moyen d'un mécanisme de communication asynchrone.

L'objectif de cet article est d'expliquer de quelle façon les développeurs peuvent tirer parti de certains modèles de conception, conjointement aux fonctions fournies par la plateforme Azure, pour créer des solutions de messagerie basées sur les files d'attente optimisées et rentables. L'article examine de façon détaillée les approches les plus communément utilisées pour implémenter des interactions basées sur les files d'attente dans les solutions Azure, et fournit des recommandations pour améliorer les performances et l'extensibilité, ainsi que pour réduire les charges d'exploitation.

Les paragraphes sous-jacents traitent des meilleures pratiques applicables, et fournissent des conseils et des recommandations le cas échéant. Le scénario décrit dans cet article est une implémentation technique basée sur un projet client réel.

Une solution de messagerie classique qui échange des données entre ses composants distribués en utilisant des files d'attente de messages inclut des éditeurs déposant des messages dans les files d'attente, et un ou plusieurs abonnés destinés à recevoir les messages. Dans la plupart des cas, les abonnés, parfois appelés écouteurs de la file d'attente, sont implémentés comme des processus simples ou multithread, s'exécutant en continu ou à la demande, conformément à un modèle de planification.

À un niveau supérieur, il existe deux mécanismes d'expédition principaux utilisés pour permettre à un écouteur de file d'attente de recevoir les messages stockés dans une file d'attente :

  • Interrogation (modèle de transmission de type pull) : un écouteur contrôle une file d'attente en vérifiant à intervalles réguliers la présence de nouveaux messages. Lorsque la file d'attente est vide, l'écouteur continue de l'interroger, tout en passant périodiquement à un état de veille.

  • Déclenchement (modèle transmission de type push) : un écouteur s'abonne à un événement déclenché (par l'éditeur lui-même ou par un gestionnaire de service de file d'attente) chaque fois qu'un message arrive dans la file d'attente. L'écouteur peut à son tour initier le traitement des messages ; il n'a pas besoin alors d'interroger la file d'attente afin de déterminer si un nouveau travail est disponible.

Il est également intéressant de mentionner qu'il existe différentes versions de ces deux mécanismes. Par exemple, l'interrogation peut être bloquée et non bloquée. Le blocage suspend une demande jusqu'à ce qu'un nouveau message s'affiche dans une file d'attente (ou jusqu'à l'expiration du délai d'attente), alors qu'une demande non bloquée est traitée immédiatement s'il n'y a rien sur une file d'attente. Avec un modèle de déclenchement, une notification peut être envoyée aux écouteurs de la file d'attente soit pour chaque nouveau message, uniquement lorsque le tout premier message arrive dans une file d'attente vide, soit lorsque la profondeur de la file d'attente atteint un certain niveau.

noteRemarque
Les opérations de retrait de la file d'attente prises en charge par l'API du service File d'attente de Azure sont non bloquées. Cela signifie que les méthodes de l'API telle que GetMessage ou GetMessages sont traitées immédiatement en l'absence de tout message sur une file d'attente. En revanche, les files d'attente du Service Bus de Azure permettent le blocage des opérations de réception : le thread appelant est bloqué jusqu'à ce qu'un message arrive sur une file d'attente ou que le délai d'attente spécifié se soit écoulé.

L'approche communément adoptée aujourd'hui pour implémenter des écouteurs de file d'attente dans des solutions Azure peut être résumée comme suit :

  1. Un écouteur est implémenté comme un composant d'application qui est instancié et exécuté dans le cadre d'une instance de rôle de travail.

  2. Le cycle de vie du composant d'écoute de file d'attente est souvent lié à l'exécution de l'instance de rôle hôte.

  3. La logique de traitement principale repose sur une boucle dans laquelle les messages sont enlevés de la file d'attente et distribués dans la file d'attente pour le traitement.

  4. Si aucun message n'est reçu, le thread d'écoute passe à l'état de veille pour une durée qui est souvent pilotée par un algorithme de temporisation spécifique propre à l'application.

  5. La boucle de réception est exécutée et une file d'attente est interrogée jusqu'à ce que l'écouteur soit notifié de quitter la boucle et de mettre fin à l'opération.

Le diagramme suivant illustre la logique généralement utilisée pour implémenter un écouteur de file d'attente avec un mécanisme d'interrogation dans les applications Azure :

Meilleures pratiques - Solutions de messagerie - Azure2
noteRemarque
Pour les besoins de cet article, les modèles de conception plus complexes, par exemple ceux qui nécessitent l'utilisation d'un gestionnaire de files d'attente (broker) ne sont pas considérés.

L'utilisation d'un écouteur de file d'attente classique avec un mécanisme d'interrogation peut ne pas être le choix optimal si vous utilisez les files d'attente Azure, car le modèle de tarification de Azure mesure les transactions de stockage en termes de demandes d'application exécutées sur la file d'attente, que la file d'attente soit vide ou non. Les sections suivantes traitent des techniques permettant d'optimiser les performances et de réduire le coût des solutions de messagerie basée sur les files d'attente de la plateforme Azure.

Dans cette section, nous allons améliorer la conception pour obtenir de meilleures performances, une meilleure extensibilité et une meilleure rentabilité.

Pour rendre un modèle d'implémentation « plus efficace », la conception devrait avoir les objectifs suivants :

  • Réduire les dépenses opérationnelles en supprimant une partie significative des transactions de stockage qui n'aboutissent à aucun travail exploitable.

  • Éliminer la latence excessive imposée par l'intervalle d'interrogation lorsqu'on vérifie les nouveaux messages d'une file d'attente.

  • Monter et réduire la charge de façon dynamique en adaptant la puissance de traitement aux volumes de travail volatils.

De plus, le modèle d'implémentation doit atteindre ces objectifs sans introduire une complexité qui annulerait les avantages associés.

Lors de l'évaluation du coût total de possession (TCO) et du retour sur investissement (ROI) pour une solution déployée sur la plateforme Azure, le volume des transactions de stockage est l'une des variables clés de l'équation TCO. En réduisant le nombre de transactions dans les files d'attente Azure, vous réduisez les coûts d'exploitation liés aux solutions exécutées sur Azure.

Le coût de l'espace de stockage associé à une file d'attente Azure peut être calculé ainsi :

Espace de la file d'attente : 24 octets + Len(QueueName)* 2 +  For-Each Metadata(4 octets + Len(QueueName) * 2 octets+ Len(Value) * 2 octets)

Espace de message : 12 octets + Len(Message)

Dans le contexte d'une solution de messagerie basée sur les files d'attente, le volume des transactions de stockage peut être réduit en associant les méthodes suivantes :

  1. Lorsque vous placez des messages dans une file d'attente, groupez les messages connexes dans un seul grand traitement, puis compressez et stockez l'image compressée dans un stockage d'objets blob et utilisez la file d'attente pour conserver une référence à l'objet blob contenant les données réelles. Cette approche optimise les coûts de transaction et le coût de l'espace de stockage.

  2. Lorsque vous récupérez des messages d'une file d'attente, traitez plusieurs messages par lots dans une seule transaction de stockage. La méthode GetMessages de l'API du service File d'attente permet d'extraire le nombre de messages spécifié de la file d'attente dans une transaction unique (consultez la remarque ci-dessous).

  3. Lorsque vous vérifiez la présence d'éléments de travail dans une file d'attente, évitez d'utiliser des intervalles d'interrogation trop fréquents et appliquez un délai de temporisation pour augmenter l'intervalle entre les demandes si une file d'attente demeure toujours vide.

  4. Réduisez le nombre d'écouteurs de la file d'attente si vous utilisez un modèle de transmission de type pull. Utilisez uniquement 1 écouteur de file d'attente par instance de rôle lorsqu'une file d'attente est vide. Pour réduire à zéro le nombre d'écouteurs de file d'attente par instance de rôle, utilisez un mécanisme de notification pour instancier les écouteurs de file d'attente lorsque la file d'attente reçoit des éléments de travail.

  5. Si les files d'attente restent le plus souvent vides, réduisez automatiquement le nombre d'instances de rôle et continuez à surveiller les mesures appropriées du système pour déterminer si et quand l'application doit augmenter le nombre d'instances pour gérer une charge de travail accrue.

  6. Implémentez un mécanisme pour supprimer les messages incohérents. Ces messages en général malformés ne peuvent pas être traités par les applications. S'ils ne sont pas traités, ils peuvent s'accumuler et accroître les frais de traitement et de transaction. Un mécanisme d'implémentation simple pourrait être de supprimer de la file d'attente les messages antérieurs à une certaine durée et de les écrire dans un système d'archivage en vue d'une évaluation ultérieure.

  7. Réduisez les échecs liés aux délais d'expiration attendus. Lorsque vous envoyez une requête au service, vous pouvez spécifier votre propre délai d'expiration et le définir de telle sorte qu'il soit inférieur au délai d'expiration du contrat SLA. Dans ce scénario, lorsque le délai d'expiration de la requête est dépassé, celle-ci est considérée comme un délai d'expiration attendu et est comptabilisée dans les transactions facturables.

La plupart des recommandations ci-dessus peuvent servir pour une mise en œuvre de type standard, qui gère les lots de message et encapsule plusieurs opérations sous-jacentes de stockage de files d'attente et d'objets blob et de gestion de threads. Nous aborderons la procédure à suivre plus loin dans cet article.

ImportantImportant
Lors de la récupération des messages via la méthode GetMessages, la taille de lot maximale prise en charge par l'API du service File d'attente dans une seule opération de retrait de la file d'attente est limitée à 32.

De façon générale, le coût des transactions Azure augmente linéairement à mesure que le nombre de clients du service de la file d'attente augmente, comme lors d'une montée en charge du nombre d'instances de rôle ou lorsqu'on augmente le nombre de threads de retrait de la file d'attente. Pour illustrer l'impact financier potentiel d'une conception qui ne tire pas parti ou ne suit pas les recommandations ci-dessus, voici un exemple attesté par des chiffres réels.

Si l'architecte de solutions n'implémente pas les optimisations appropriées, l'architecture décrite ci-dessus va probablement générer des dépenses opérationnelles excessives une fois la solution déployée et exécutée sur la plateforme Azure. Les raisons de ces dépenses excessives sont décrites dans cette section.

Comme souligné dans la définition du scénario, les données des transactions commerciales arrivent à intervalles réguliers. Toutefois, supposons que la solution est occupée à traiter la charge de travail 25% du temps pendant un jour ouvré de 8 heures standard. Il en résulte une « durée d'inactivité » de 6 heures (8 heures x 75 %) pendant laquelle aucune transaction ne passe par le système. En outre, la solution ne reçoit aucune donnée pendant les 16 heures non ouvrées de la journée.

Cela fait un total de 22 heures d'inactivité, pendant lesquelles la solution tente toujours d'extraire de la file d'attente le travail car elle n'a aucune connaissance explicite de l'arrivée de nouvelles données. Dans cette fenêtre temporelle, chaque thread de retrait de la file d'attente individuel exécute jusqu'à 79 200 transactions (22 heures x 60 min x 60 transactions/min) sur une file d'attente d'entrée, compte tenu de la fréquence d'interrogation par défaut d'1 seconde.

Comme indiqué précédemment, le modèle de tarification de la plateforme Azure est basé sur des « transactions de stockage » individuelles. Une transaction de stockage est une demande faite par une application utilisateur afin d'ajouter, consulter, mettre à jour ou supprimer des données dans le stockage. Au moment de la rédaction de ce livre blanc, les transactions de stockage sont facturées 0,01 dollars les 10 000 transactions (hors offres promotionnelles ou accords de tarification spéciaux).

ImportantImportant
Lorsque vous calculez le nombre de transactions de file d'attente, gardez à l'esprit que la mise en file d'attente d'un seul message est comptée comme 1 transaction, et que la consommation d'un message est souvent un processus impliquant 2 étapes : la récupération, suivie d'une demande pour supprimer le message de la file d'attente. Par conséquent, une opération de retrait de la file d'attente réussie génère deux transactions de stockage. Notez que même si une demande de retrait de la file d'attente ne génère aucune récupération de données, elle compte toujours comme une transaction facturable.

Les transactions de stockage générées par un seul thread de retrait de la file d'attente dans le scénario ci-dessus coûteront environ 2,38 dollars (79 200 / 10 000 x $0,01 x 30 jours) tous les mois. En comparaison, 200 threads de retrait de la file d'attente (ou, alternativement, 1 thread de retrait de la file d'attente dans 200 instances de rôle de travail) coûteront donc 457,20 dollars par mois. Il s'agit du coût induit lorsque la solution n'effectue aucun calcul, se contentant d'interroger les files d'attente pour déterminer si des éléments de travail sont disponibles. L'exemple ci-dessus est un exemple abstrait, car personne n'implémenterait son service de cette manière, mais il a le mérite d'expliquer pourquoi il est si important d'appliquer les optimisations décrites à la suite.

Pour optimiser les performances des solutions de messagerie basée sur les files d'attente Azure, une approche consiste à utiliser la couche de messagerie de publication/abonnement fournie avec le Service Bus de Azure, comme décrit dans cette section.

Dans cette approche, les développeurs devront se concentrer sur la création d'une combinaison de notifications d'interrogation et de type push en temps réel, permettant aux écouteurs de s'abonner à une notification d'événement (déclencheur) déclenchée à certaines conditions pour indiquer qu'une nouvelle charge de travail est mise dans une file d'attente. Cela améliore la boucle d'interrogation de file d'attente traditionnelle grâce à une couche de messagerie de publication/abonnement pour distribuer les notifications.

Dans un système distribué complexe, cette approche exige l'utilisation d'un « bus de messages » ou d'un « intergiciel orienté messages » pour s'assurer que les notifications peuvent être relayées de manière fiable à un ou plusieurs abonnés de façon faiblement couplée. Service Bus de Azure est le choix privilégié pour gérer les spécifications de messagerie entre des services distribués faiblement couplés s'exécutant sur Azure et sur site. Il s'agit également de la solution idéale pour une architecture de « bus de messages » qui permet l'échange des notifications entre les processus intervenant dans les communications basées sur une file d'attente.

Les processus impliqués dans un échange de messages basé sur une file d'attente peuvent utiliser le modèle suivant :

Meilleures pratiques - Solutions de messagerie - Azure3

Plus précisément, en ce qui concerne l'interaction entre les éditeurs du service de file d'attente et les abonnés, les mêmes principes appliqués à la communication entre les instances de rôle Azure peuvent répondre à la plupart des besoins d'échange de messages de notification de type push.

ImportantImportant
L'utilisation de Service Bus de Azure est assujettie à un modèle de tarification qui tient compte du volume des opérations de messagerie sur une entité de messagerie Service Bus comme une file d'attente ou un sujet.

Il est donc important d'effectuer une analyse du coût/bénéfice pour évaluer les avantages et les inconvénients de l'introduction de Service Bus dans une architecture spécifique. Dans ce document, il est utile d'évaluer si l'introduction de la couche de distribution de notification basée sur Service Bus aboutit réellement à une réduction du coût pouvant justifier les investissements et les efforts de développement supplémentaires.

Pour plus d'informations sur le modèle de tarification de Service Bus, consultez les sections appropriées des Questions fréquentes sur la plateforme Azure.

Alors que l'impact sur la latence est assez simple à gérer avec une couche de messagerie de publication/abonnement, la réduction des coûts peut être atteinte en utilisant une mise à l'échelle dynamique (élastique), comme expliqué dans la section suivante.

Le stockage Azure définit des objectifs d'extensibilité au niveau global des comptes et au niveau des partitions. Une file d'attente dans Azure est sa propre partition unique et peut traiter jusqu'à 2 000 messages par seconde. Lorsque le nombre de messages dépasse ce seuil, le service de stockage répond par un message HTTP 503 Serveur occupé. Ce message indique que la plateforme limite la file d'attente. Les développeurs d'application peuvent planifier les capacités pour vérifier qu'un nombre de files d'attente approprié peut supporter le taux de demandes de l'application. Si une file d'attente ne peut pas traiter le taux de demandes d'une application, créez une architecture de files d'attente partitionnée avec plusieurs files d'attente pour garantir l'extensibilité.

Une application peut également utiliser plusieurs files d'attente pour différents types de messages. Ceci garantit l'extensibilité de l'application en autorisant la coexistence de plusieurs files d'attente sans en encombrer une seule. Cela permet également un contrôle discret du traitement des files d'attente selon la sensibilité et la priorité des messages stockés dans différentes files d'attente. Les files d'attente à priorité élevée peuvent avoir plus de travailleurs dédiés que celles présentant une faible priorité.

La plateforme Azure permet aux utilisateurs de mettre à l'échelle leur solution plus rapidement et plus facilement que jamais. La capacité de gérer des charges de travail volatiles et un trafic variable est l'une des propositions phares de la plateforme du cloud. Cela met l'extensibilité à la portée de tout le monde, et en fait une fonctionnalité prête à l'emploi qui peut être activée par programme à la demande dans une solution dans le cloud bien conçue.

La mise à l'échelle dynamique est la capacité technique d'une solution donnée de gérer des charges de travail variables en augmentant et en réduisant la capacité de travail et la puissance de traitement au moment de l'exécution. La plateforme Azure prend en charge en mode natif la mise à l'échelle dynamique via la configuration d'une infrastructure de traitement distribué dans laquelle les heures de calcul peuvent être achetées en fonction des besoins.

Il est important de distinguer 2 types de mise à l'échelle dynamique sur la plateforme Azure :

  • La mise à l'échelle de l'instance de rôle fait référence à l'ajout et à la suppression d'instances de rôle web ou de rôle de travail supplémentaires pour gérer la charge de travail dans le temps. Cela implique souvent de modifier le nombre d'instances dans la configuration du service. L'augmentation du nombre d'instances entraîne le démarrage par le runtime de Azure de nouvelles instances, tandis que la réduction du nombre d'instances entraîne l'arrêt des instances en cours d'exécution.

  • La mise à l'échelle de processus (thread) fait référence au maintien d'une capacité suffisante en termes de traitement des threads dans une instance de rôle donnée en ajustant le nombre de threads en fonction de la charge de travail actuelle.

La mise à l'échelle dynamique dans une solution de messagerie basée sur les files d'attente devrait suivre un certain nombre de recommandations, notamment :

  1. La surveillance des indicateurs de performance clés, notamment l'utilisation du processeur, la longueur de la file d'attente, les temps de réponse et la latence de traitement des messages.

  2. L'augmentation ou la réduction dynamique du nombre d'instances de rôle pour faire face aux pics de charge de travail, qu'ils soient prédictibles ou non.

  3. L'extension et la réduction par programme du nombre de threads de traitement pour répondre aux charges variables gérées par une instance de rôle spécifique.

  4. Le partitionnement et le traitement de granularité fine des charges de travail simultanées grâce à Task Parallel Library dans le .NET Framework 4.

  5. Le maintien d'une capacité viable dans les solutions caractérisées par une charge de travail très volatile, en prévision des pics soudains, afin de pouvoir les gérer sans configurer des instances supplémentaires.

L'API de gestion du service permet à un service hébergé dans Azure de modifier le nombre d'instances de rôle en cours d'exécution en modifiant la configuration du déploiement au moment de l'exécution.

noteRemarque
Le nombre maximal de petites instances de calcul Azure (ou le nombre équivalent d'instances de calcul de taille différentes en termes de nombre de cœurs) dans un abonnement standard est limité à 20 par défaut. Toutes les demandes d'augmentation de quota doivent être adressées à l'équipe de Support de Azure. Pour plus d'informations, consultez Questions fréquentes sur la plateforme Azure.

Avec l'introduction de la mise à l'échelle automatique Azure, la plateforme peut mettre à l'échelle le nombre d'instances selon la profondeur des messages de la file d'attente. Il s'agit d'une manière très naturelle d'obtenir une mise à l'échelle dynamique. Par ailleurs, la plateforme Azure surveille et met à l'échelle les tâches pour l'application.

La mise à l'échelle du nombre d'instances de rôle n'est pas toujours la meilleure solution pour gérer les pics de charge. Par exemple, une nouvelle instance de rôle peut mettre plusieurs secondes à tourner à plein régime, et il n'existe actuellement aucune mesure SLA fournie à ce sujet. En revanche, il suffit parfois d'augmenter simplement le nombre de threads de travail pour gérer l'augmentation d'une charge de travail volatile. Lorsque la charge de travail est traitée, la solution surveille les mesures de charge appropriées et détermine s'il faut réduire ou augmenter dynamiquement le nombre de processus de travail.

ImportantImportant
Actuellement, l'objectif d'extensibilité pour une file d'attente Azure est « limité » à 2 000 transactions par seconde. Si une application tente de dépasser cette cible, par exemple, en effectuant des opérations de file d'attente à partir de plusieurs instances de rôle exécutant des centaines de threads de retrait de la file d'attente, une réponse HTTP 503 « Serveur occupé » peut être reçue du service de stockage. Dans ce cas, l'application doit implémenter un mécanisme de nouvelle tentative avec un algorithme de délai de temporisation exponentiel. Toutefois, si les erreurs HTTP 503 se produisent régulièrement, il est recommandé d'utiliser plusieurs files d'attente et d'implémenter une stratégie basée sur un partitionnement pour mettre à l'échelle sur plusieurs files d'attente.

Dans la plupart des cas, la mise à l'échelle automatique des processus de travail se fait au niveau de l'instance de rôle spécifique. En revanche, la mise à l'échelle d'une instance de rôle implique généralement un élément central de l'architecture de solution responsable de surveiller les mesures de performances et de déterminer les mises à l'échelle appropriées. Le schéma ci-dessous représente un composant de service appelé agent dynamique de mise à l'échelle qui rassemble et analyse les mesures de charge pour déterminer s'il doit mettre en service des instances ou libérer des instances inactives.

Meilleures pratiques - Solutions de messagerie - Azure4

Il est à noter que le service de l'agent de mise à l'échelle peut être déployé en tant que rôle de travail en cours de exécution sur Azure, ou en tant que service sur site. Indépendamment de la topologie de déploiement, le service peut accéder aux files d'attente Azure.

noteRemarque
Une alternative à la mise à l'échelle dynamique manuelle consiste à utiliser la fonctionnalité de mise à l'échelle automatique intégrée d'Azure.

Maintenant que nous avons couvert l'impact de la latence, les coûts de stockage et les spécifications de la mise à l'échelle dynamique, il est temps de consolider nos recommandations dans une implémentation technique.

Afin de fournir un exemple concret, nous allons généraliser un scénario tiré d'un cas client réel, comme suit.

Un fournisseur de solutions SaaS lance un nouveau système de facturation implémenté en tant qu'application Azure pour répondre aux besoins de traitement des transactions d'échelle du client. L'atout principal de la solution est sa capacité à réduire la charge de travail sur le cloud et à exploiter l'élasticité de l'infrastructure Azure pour effectuer des opérations qui sollicitent beaucoup de ressources.

L'élément sur site de l'architecture de bout en bout consolide et distribue de grands volumes de transactions à un service hébergé sur Azure, régulièrement pendant la journée. Les volumes varient de quelques milliers à des centaines de milliers de transactions par soumission, atteignant des millions de transactions par jour. En outre, la solution doit satisfaire des besoins opérationnels dictés par un contrat de niveau de service pour une latence de traitement maximale garantie.

L'architecture de la solution est fondée sur un modèle de conception MapReduce et comprend une couche sur le cloud basée sur des rôles de travail et sur plusieurs instances, utilisant le stockage de files d'attentes Azure pour la distribution du travail. Les lots de transactions sont reçus par instance de rôle de travail initiateur du processus, décomposés (mis hors lot) en éléments de travail plus petits et mis en file d'attente dans une collection de files d'attente Azure pour permettre la répartition des charges.

Le traitement de la charge de travail est géré par plusieurs instances du rôle de travail chargé du processus, qui extrait des éléments de travail des files d'attente et les traite par des procédures de calcul. Les instances de traitement utilisent des écouteurs multithread pour implémenter le traitement des données en parallèle afin d'optimiser les performances.

Les éléments de travail traités sont routés dans une file d'attente dédiée, puis ils sont extraits de celle-ci par l'instance de rôle de travail du contrôleur du processus ; ils sont ensuite agrégés et rendus persistants dans une banque de données pour l'exploration, la création de rapports et d'analyse.

L'architecture de la solution peut être représentée comme suit :

AzureGuidance_MaxScale

Le diagramme ci-dessus représente une architecture standard pour la mise à l'échelle de charges de travail conséquentes ou complexes. Le modèle d'échange de messages basé sur les files d'attente adopté par cette architecture est également très courant pour de nombreuses autres applications et services Azure qui doivent communiquer entre eux via des files d'attente. Il permet d'adopter une approche canonique pour analyser les composants fondamentaux spécifiques impliqués dans un échange de messages basé sur les files d'attente.

Pour optimiser la rentabilité et l'efficacité des solutions de messagerie basée sur les files d'attente qui s'exécutent sur la plateforme Azure, les architectes et les développeurs doivent prendre en compte les recommandations suivantes.

En tant qu'architecte de solution, vous devez :

  • Implémenter une architecture de messagerie basée sur les files d'attente qui utilise le service de stockage de files d'attente Azure pour la communication asynchrone à grande échelle entre les couches et les services dans les solutions basées sur le cloud ou hybrides.

  • Recommander une architecture de mise en file d'attente partitionnée capable de prendre en charge plus de 2 000 messages/s.

  • Comprendre les caractéristiques principales du modèle de tarification de Azure et optimiser la solution afin de réduire les coûts de transaction au moyen des meilleures pratiques et de modèles de conception appropriés.

  • Tirer parti de la mise à l'échelle dynamique en créant une architecture qui s'adapte aux charges de travail variables et fluctuantes.

  • Utiliser les bonnes techniques et méthodes de mise à l'échelle pour étendre ou réduire de façon élastique la puissance de calcul, et optimiser davantage les charges d'exploitation.

  • Évaluer la mise à l'échelle automatique Azure pour voir si elle convient aux besoins de l'application en termes de mise à l'échelle dynamique

  • Évaluer le ratio coût/bénéfice en ce qui concerne la réduction de la latence en exploitant le Service Bus de Azure pour la distribution de notifications de type push en temps réel.

En tant que développeur, vous devez :

  • Concevoir une solution de messagerie qui utilise la mise en lots lors du stockage et du retrait des données à partir des files d'attente Azure.

  • Évaluer la mise à l'échelle automatique Azure pour voir si elle convient aux besoins de l'application en termes de mise à l'échelle dynamique

  • Implémenter un service d'écouteur de file d'attente efficace, en mesure de garantir que les files d'attente sont interrogées par au maximum un thread de retrait de la file d'attente lorsque la file d'attente est vide.

  • Réduire dynamiquement le nombre d'instances de rôle de travail lorsque les files d'attente sont vides pendant une longue période.

  • Implémenter un algorithme de temporisation exponentiel aléatoire spécifique à l'application pour réduire l'impact de l'interrogation des files d'attente inactives sur les coûts du stockage.

  • Adopter les bonnes techniques afin d'empêcher tout dépassement des cibles d'extensibilité pour chaque file d'attente en cas d'utilisation d'éditeurs et de consommateurs de file d'attente comportant plusieurs instances et un grand nombre de processus.

  • Utiliser une stratégie de retrait fiable capable de gérer un grand nombre de conditions temporaires lors de la publication et de la consommation des données dans les files d'attente Azure.

  • Utiliser la fonction de création d'événements unidirectionnel fournie par le Service Bus de Azure pour prendre en charge les notifications de type push afin de réduire la latence et d'améliorer les performances de la solution de messagerie basée sur les files d'attente.

  • Explorer les nouvelles fonctions du .NET Framework 4 telles que TPL, PLINQ et le modèle Observateur pour optimiser le degré de parallélisme, améliorer la concurrence et simplifier la conception des services multithread.

Les exemples de code contenus dans ce document sont disponibles au téléchargement dans MSDN Code Gallery. Ces exemples de code contiennent également tous les composants d'infrastructure requis, tels que la couche d'abstraction acceptant les génériques du service de files d'attente Azure, qui n'ont pas été fournis dans les extraits de code de cet article. Notez que tous les fichiers de code source sont régis par la licence publique de Microsoft, comme expliqué dans les mentions légales correspondantes.

Afficher:
© 2015 Microsoft