Partager via

Approches architecturales pour la messagerie dans les solutions multilocataires

  • Article

La messagerie asynchrone et la communication basée sur les événements sont des ressources critiques quand vous créez une application distribuée qui est composée de plusieurs services internes et externes. Lorsque vous concevez une solution multilocataire, il est indispensable de conduire une analyse préliminaire pour déterminer comment partager ou partitionner des messages qui se rapportent à des locataires différents.

D’un côté, le partage du même système de messagerie ou du même service de streaming d’événements peut réduire considérablement le coût opérationnel et la complexité de la gestion. D’un autre côté, l’utilisation d’un système de messagerie dédié pour chaque locataire offre un meilleur isolement des données, réduit le risque de fuite de données, élimine le problème de voisin bruyant, et permet de refacturer facilement vos coûts Azure à vos locataires.

Cet article explique la différence entre messages et événements. Il donne également des conseils qui aideront les architectes de solution à choisir l’approche qu’ils utiliseront pour une infrastructure de gestion des messages ou des événements dans une solution multilocataire.

Messages, points de données et événements discrets

Tous les systèmes de messagerie présentent des fonctionnalités, des protocoles de transport et des scénarios d’usage similaires. Par exemple, la plupart des systèmes de messagerie modernes prennent en charge les communications asynchrones qui utilisent les files d’attente volatiles ou persistantes, les protocoles de transport AMQP et HTTPS, la remise au moins une fois, etc. Toutefois, en examinant de plus près le type des informations publiées et la façon dont les données sont consommées et traitées par les applications clientes, nous pouvons distinguer différentes sortes de messages et d’événements. Il y a une différence essentielle entre les services qui remettent des événements et les systèmes qui envoient des messages. Pour plus d’informations, consultez les ressources suivantes :

Événements

Un événement est une notification légère d’une condition ou d’un changement d’état. Les événements peuvent être des unités discrètes ou appartenir à une série. Les événements sont des messages qui ne transmettent généralement comme intention de l’éditeur que celle d’informer. Un événement capture un fait et le communique à d’autres services ou composants. Un consommateur de l’événement peut traiter l’événement comme il le souhaite et il ne répond pas aux attentes spécifiques de l’éditeur. Nous pouvons classifier les événements en deux catégories principales :

  • Les événements discrets contiennent des informations sur les actions spécifiques effectuées par l’application de publication. Dans le cas d’une communication asynchrone basée sur les événements, l’application publie un événement de notification quand un événement se produit dans son domaine. Une ou plusieurs applications consommatrices doivent être averties de ce changement d’état, comme un changement de prix dans une application de catalogue de produits. Les consommateurs s’abonnent aux événements pour les recevoir de manière asynchrone. Quand un événement se produit, les applications consommatrices doivent parfois mettre à jour leurs entités de domaine, ce qui peut entraîner la publication d’un plus grand nombre d’événements d’intégration.
  • Les événements de série transmettent des points de données d’information, tels que des lectures de température reçues d’appareils à des fins d’analyse ou d’actions utilisateur dans une solution d’analyse des clics, sous forme d’éléments dans un flux continu. Un flux d’événements est lié à un contexte particulier, comme la température ou l’humidité rapportée par un appareil de terrain. Tous les événements d’un même contexte sont organisés selon un ordre temporel strict qui est suivi au moment du traitement de ces événements avec un moteur de traitement de flux d’événements. L’analyse des flux d’événements qui transmettent les points de données nécessite que ces événements soient tous stockés dans une mémoire tampon qui s’étend sur une fenêtre de temps souhaitée. Cela peut aussi se faire en sélectionnant un nombre d’éléments, puis en traitant ces événements avec une solution en quasi-temps réel ou un algorithme entraîné par la machine. L’analyse d’une série d’événements peut générer des signaux, comme la moyenne d’une valeur mesurée sur une fenêtre de temps qui dépasse un seuil. Ces signaux peuvent ensuite être déclenchés sous forme d’événements discrets et actionnables.

Les événements discrets signalent les changements d’état et sont actionnables. La charge utile d’événement contient des informations sur ce qui s’est produit, mais, en général, elle ne fournit pas les données complètes qui ont déclenché l’événement. Par exemple, un événement notifie les consommateurs qu’une application de génération de rapports a créé un fichier dans un compte de stockage. La charge utile d'événement peut contenir les informations générales relatives au fichier, mais pas le fichier lui-même. Les événements discrets conviennent parfaitement aux solutions sans serveur qui ont besoin d’être mises à l’échelle.

Les événements en série signalent une condition et sont analysables. Les événements discrets sont chronologiques et liés entre eux. Dans certains contextes, le consommateur a besoin de recevoir la séquence complète des événements pour analyser ce qui s’est produit et prendre l’action requise.

Messages

Les messages contiennent des données brutes qui sont générées par un service en vue d’être consommées ou stockées ailleurs. Ils fournissent souvent les informations dont un service de réception a besoin pour exécuter des étapes dans un workflow ou une chaîne de traitement. Le modèle Commande est un exemple de ce type de communication. L’éditeur peut également attendre du ou des destinataires d’un message qu’ils exécutent une série d’actions et qu’ils renvoient le résultat de leur traitement dans un message asynchrone. Un contrat existe entre l’éditeur du message et chaque destinataire du message. Par exemple, l’éditeur envoie un message contenant certaines données brutes et s’attend à ce que le consommateur crée un fichier à partir de ces données et lui renvoie un message de réponse quand il a terminé. Dans d’autres situations, un processus d’expédition peut envoyer un message unidirectionnel asynchrone pour demander à un autre service d’effectuer une opération donnée, mais sans attendre de lui en retour un accusé de réception ou un message de réponse.

Ce type de traitement des messages contractuels est très différent d’un éditeur qui publie des événements discrets vers une audience d’agents consommateurs, sans leur imposer d’attentes particulières sur la façon de gérer ces notifications.

Exemples de scénarios

Voici une liste d’exemples de scénarios multilocataires pour les messages, les points de données et les événements discrets :

  • Événements discrets :
    • Une plateforme de partage de musique suit le fait qu’un utilisateur spécifique dans un locataire spécifique a écouté un morceau de musique particulier.
    • Dans une application web de magasin en ligne, l’application de catalogue envoie un événement, en utilisant le modèle Éditeur-abonné, à d’autres applications pour les informer qu’un prix d’article a changé.
    • Une entreprise de fabrication envoie (push) des informations en temps réel aux clients et aux tiers à propos de la maintenance des équipements, de l’intégrité des systèmes et des mises à jour des contrats.
  • Points de données :
    • Un système de contrôle de construction reçoit des événements de télémétrie, tels que des lectures de température ou d’humidité reçues des capteurs appartenant à plusieurs clients.
    • Un système de monitoring basé sur les événements reçoit et traite en quasi-temps réel les journaux de diagnostic reçus de plusieurs services, tels que des serveurs web.
    • Un script côté client sur une page web collecte les actions utilisateur et les envoie à une solution d’analyse des clics.
  • Messages :
    • Une application financière B2B reçoit un message lui demander de commencer à traiter les transactions bancaires d’un locataire.
    • Un workflow de longue durée reçoit un message qui déclenche l’exécution de l’étape suivante.
    • L’application de panier d’une application de magasin en ligne envoie une commande CreateOrder (Créer la commande) à l’application de commande, par le biais d’un message asynchrone et persistant.

Principaux éléments et exigences à prendre en compte

Le modèle de déploiement et de location que vous choisissez pour votre solution a un impact important sur la sécurité, les performances, l’isolement des données, la gestion et la possibilité de refacturer les coûts des ressources aux locataires. Cette analyse utilise le modèle choisi pour votre infrastructure de gestion des messages et des événements. Dans cette section, nous allons examiner certaines des décisions clés à prendre lorsque vous planifiez un système de messagerie dans votre solution multilocataire.

Scale

Le nombre de locataires, la complexité des flux de messages et des flux d’événements, le volume de messages, le profil de trafic attendu et le niveau d’isolement sont autant de facteurs qui doivent conduire votre prise de décision lors de la planification d’une infrastructure de gestion des messages et des événements.

La première étape consiste à effectuer une planification précise de la capacité et à définir la capacité maximale dont un système de messagerie a besoin pour garantir un débit qui lui permette de traiter correctement le volume attendu de messages dans les conditions d’un trafic normal ou en hausse.

Certaines offres de services, comme le niveau Premium d’Azure Service Bus, fournissent l’isolement des ressources au niveau du processeur et de la mémoire afin que chaque charge de travail de client s’exécute de manière isolée. Ce conteneur de ressources est appelé unité de messagerie. Au moins une unité de messagerie est allouée à chaque espace de noms premium. Vous pouvez acheter 1, 2, 4, 8 ou 16 unités de messagerie pour chaque espace de noms Service Bus Premium. Une seule entité ou charge de travail peut couvrir plusieurs unités de messagerie, et le nombre d’unités de messagerie peut être changé au besoin. Au final, les performances de votre solution Service Bus sont prévisibles et reproductibles. Pour plus d’informations, consultez Couches messagerie Service Bus Premium et Standard. De même, les niveaux tarifaires d’Azure Event Hubs vous permettent de dimensionner l’espace de noms, en fonction du volume attendu d’événements entrants et sortants. Par exemple, l’offre Premium est facturée en fonction du nombre d’unités de traitement (ou « PU », pour « Processing Units ») qui correspondent à une part de ressources isolées (processeur, mémoire et stockage) dans l’infrastructure sous-jacente. Le débit d’ingestion et de streaming effectif pour chaque unité de traitement dépend des facteurs suivants :

  • Nombre de producteurs et consommateurs
  • Taille de charge utile
  • Nombre de partitions
  • Taux de requêtes de sortie
  • Utilisation de la fonctionnalité Capture de Event Hubs, du registre de schéma et d’autres fonctionnalités avancées

Pour plus d’informations, consultez Vue d’ensemble d’Event Hubs Premium.

Si votre solution gère un nombre considérable de locataires et que vous décidez d’adopter un système de messagerie distinct pour chaque locataire, vous devez avoir une stratégie cohérente pour automatiser le déploiement, le monitoring, les alertes et la mise à l’échelle des infrastructures, séparément les unes des autres.

Par exemple, vous pouvez déployer un système de messagerie pour un locataire donné pendant le processus de provisionnement en utilisant un outil d’infrastructure en tant que code (IaC), comme Terraform, Bicep ou des modèles JSON Azure Resource Manager (ARM), et un système DevOps comme Azure DevOps ou GitHub Actions. Pour plus d’informations, consultez Approches architecturales pour le déploiement et la configuration de solutions multilocataires.

Le système de messagerie peut être dimensionné avec un débit maximal de messages par unité de temps. Si le système prend en charge la mise à l’échelle automatique dynamique, sa capacité peut être augmentée ou réduite automatiquement, en fonction des conditions de trafic et des métriques pour respecter le contrat de niveau de service attendu.

Prévisibilité et fiabilité des performances

Si vous devez concevoir et créer un système de messagerie pour un nombre limité de locataires, l’utilisation d’un système de messagerie unique peut être une excellente solution pour remplir les exigences fonctionnelles (sur le plan du débit) et réduire le coût total de possession. Une application multilocataire peut partager les mêmes entités de messagerie, telles que les files d’attente et les rubriques, entre plusieurs clients. Il est possible aussi d’utiliser un ensemble de composants dédiés pour chacun d’eux afin de mieux isoler les locataires. En revanche, le partage de la même infrastructure de messagerie entre plusieurs locataires risque d’exposer toute la solution au problème de voisin bruyant. L’activité d’un locataire peut avoir un impact sur les performances et l’opérabilité d’autres locataires.

Dans ce cas, le système de messagerie doit être correctement dimensionné pour supporter la charge de trafic attendue au moment du pic. Dans l’idéal, il doit prendre en charge la mise à l’échelle automatique. Le système de messagerie doit dynamiquement être mis à l’échelle par un scale-out lorsque le trafic augmente, et par un scale-in quand le trafic diminue. Un système de messagerie dédié pour chaque locataire peut également atténuer le risque de voisin bruyant, mais cela implique de gérer beaucoup de systèmes de messagerie et peut rendre la solution plus complexe.

Une application multilocataire peut finalement adopter une approche hybride, où les services principaux utilisent le même ensemble de files d’attente et de rubriques dans un système de messagerie unique et partagé, afin d’implémenter des communications asynchrones internes. A contrario, d’autres services peuvent utiliser un groupe dédié d’entités de messagerie, voire un système de messagerie dédié, pour chaque locataire dans le but d’atténuer le problème de voisin bruyant et de garantir l’isolement des données.

Quand vous déployez un système de messagerie sur des machines virtuelles, vous devez mettre ces machines au même endroit que les ressources de calcul pour réduire la latence du réseau. Ces machines virtuelles ne doivent pas être partagées avec d’autres services ou applications afin que l’infrastructure de messagerie n’entre pas en concurrence avec des ressources système, telles que le processeur, la mémoire et la bande passante réseau. Les machines virtuelles peuvent également être réparties entre les zones de disponibilité, ce qui contribue à améliorer la résilience entre les régions ainsi que la fiabilité des charges de travail critiques, dont les systèmes de messagerie. Supposons que vous décidiez d’héberger un système de messagerie comme RabbitMQ ou Apache ActiveMQ sur des machines virtuelles. Dans ce cas, nous vous recommandons de le déployer sur un groupe de machines virtuelles identiques et de le configurer pour la mise à l’échelle automatique sur la base de certaines métriques (processeur ou mémoire, par exemple). De cette façon, le nombre de nœuds d’agent hébergeant le système de messagerie sera adapté de manière approprié selon les conditions de trafic. Pour plus d’informations, consultez Vue d’ensemble de la mise à l’échelle automatique avec les groupes de machines virtuelles identiques Azure.

De même, si vous hébergez votre système de messagerie sur un cluster Kubernetes, envisagez d’utiliser des sélecteurs de nœuds et des aversions pour planifier l’exécution de ses pods dans un pool de nœuds dédié, et non partagé avec d’autres charges de travail. Cela évite le problème de voisin bruyant. Si vous déployez un système de messagerie dans un cluster AKS redondant interzone, utilisez des contraintes de propagation de topologie pour les pods afin de contrôler comment les pods sont propagés à travers votre cluster AKS parmi les domaines de défaillance comme les régions, les zones de disponibilité et les nœuds. Si vous hébergez un système de messagerie tiers sur AKS, utilisez la mise à l’échelle automatique Kubernetes pour augmenter dynamiquement le nombre de nœuds worker lorsque le trafic augmente. Avec la mise à l’échelle automatique horizontale des pods et la mise à l’échelle automatique du cluster AKS, les volumes de nœuds et de pods sont ajustés de façon dynamique en temps réel pour répondre aux besoins de trafic du moment et éviter les temps d’arrêt causés par des problèmes de capacité. Pour plus d’informations, consultez Mise à l’échelle automatique d’un cluster pour répondre aux demandes applicatives d’Azure Kubernetes Service (AKS). Envisagez la mise à l’échelle avec KEDA (Kubernetes Even-Driven Autoscaling) si vous souhaitez effectuer un scale-out du nombre de pods d’un système de messagerie hébergé par Kubernetes (comme RabbitMQ ou Apache ActiveMQ) en fonction de la longueur d’une file d’attente donnée. Avec KEDA, vous pouvez contrôler la mise à l’échelle des conteneurs dans Kubernetes sur la base du nombre d’événements à traiter. Par exemple, utilisez KEDA pour mettre à l’échelle des applications en fonction de la longueur d’une file d’attente Azure Service Bus, d’une file d’attente RabbitMQ ou d’une file d’attente ActiveMQ. Pour plus d’informations sur KEDA, consultez Kubernetes Event-driven Autoscaling.

Isolation

Lorsque vous concevez le système de messagerie pour une solution multilocataire, sachez que selon leur type, les applications nécessitent un type d’isolement différent, qui dépend des exigences des locataires en matière de performances, de confidentialité et d’audit.

  • Plusieurs locataires peuvent partager les mêmes entités de messagerie, telles que les files d’attente, les rubriques et les abonnements, dans le même système de messagerie. Par exemple, une application multilocataire peut recevoir des messages qui transmettent des données pour plusieurs locataires, à partir d’une file d’attente Azure Service Bus unique. Cette solution peut donner lieu à des problèmes de performances et de scalabilité. Si certains des locataires génèrent un plus grand volume de commandes que d’autres, cela peut provoquer un backlog des messages. Ce problème, également connu sous le nom de problème de voisin bruyant, peut dégrader le contrat de niveau de service de certains locataires sur le plan de la latence. Le problème est plus visible si l’application consommatrice lit et traite les messages de la file d’attente les uns après les autres, dans un ordre chronologique strict, et si la durée de traitement d’un message dépend du nombre d’éléments dans la charge utile. Quand une ou plusieurs ressources de file d’attente sont partagées entre différents locataires, l’infrastructure de messagerie et les systèmes de traitement doivent être capables de prendre en charge le trafic attendu en fonction des exigences de débit et de mise à l’échelle. Cette approche architecturale convient bien dans les scénarios où une solution multilocataire utilise un pool unique de processus worker afin de recevoir, traiter et envoyer les messages pour tous les locataires.
  • Plusieurs locataires partagent le même système de messagerie, mais utilisent des ressources de rubrique ou de file d’attente différentes. Cette approche offre un meilleur isolement et une plus grande protection des données, mais elle présente un coût plus élevé, une complexité opérationnelle accrue et une agilité moindre, car les administrateurs système doivent provisionner, superviser et gérer beaucoup plus de ressources de file d’attente. Cette solution garantit une expérience cohérente et prévisible pour tous les locataires, en ce qui concerne les performances et les contrats de niveau de service, car elle empêche les locataires de créer un goulot d’étranglement susceptible d’impacter les autres locataires.
  • Un système de messagerie distinct et dédié est utilisé pour chaque locataire. Par exemple, une solution multilocataire peut utiliser un espace de noms Azure Service Bus distinct pour chaque locataire. Cette solution offre le plus haut niveau d'isolement, au détriment d’une complexité et d’un coût opérationnel plus élevés. Cette approche garantit des performances cohérentes et permet d’adapter le système de messagerie en fonction des besoins spécifiques des locataires. Lorsqu’un nouveau locataire est intégré, en plus d’un système de messagerie entièrement dédié, l’application de provisionnement peut également avoir besoin de créer une identité managée distincte ou un principal de service ayant les autorisations RBAC appropriées pour accéder au nouvel espace de noms. Par exemple, quand un cluster Kubernetes est partagé par plusieurs instances de la même application SaaS, à raison d’une instance par locataire s’exécutant dans un espace de noms séparé, chaque instance de l’application peut utiliser un principal de service ou une identité managée différents pour accéder à un système de messagerie dédié. Dans ce contexte, le système de messagerie peut être un service PaaS entièrement managé, par exemple un espace de noms Azure Service Bus, ou un système de messagerie hébergé par Kubernetes, tel que RabbitMQ. Quand un locataire est supprimé du système, l’application doit supprimer le système de messagerie et toutes les ressources dédiées qui ont été créées précédemment pour ce locataire. Le principal inconvénient de cette approche est qu’elle accroît la complexité opérationnelle et réduit l’agilité, en particulier quand le nombre de locataires augmente au fil du temps.

Prenez connaissance des remarques et observations supplémentaires suivantes :

  • Si les locataires doivent utiliser leur propre clé pour chiffrer et déchiffrer les messages, une solution multilocataire doit offrir la possibilité d’employer un espace de noms Azure Service Bus Premium distinct pour chaque locataire. Pour plus d’informations, consultez Configurer les clés gérées par le client pour le chiffrement des données Azure Service Bus au repos.
  • Si les locataires nécessitent un haut niveau de résilience et de continuité de l’activité, une solution multilocataire doit permettre de provisionner un espace de noms Service Bus Premium où la géo-reprise d’activité après sinistre et les zones de disponibilité sont activées. Pour plus d’informations, consultez Géorécupération d’urgence Azure Service Bus.
  • Lorsque vous utilisez des ressources de file d’attente distinctes ou un système de messagerie dédié pour chaque locataire, il est conseillé d’utiliser un pool séparé de processus worker pour chacun des locataires. Ainsi, l’isolement des données sera meilleur et la gestion des différentes entités de messagerie sera plus facile. Chaque instance du système de traitement peut utiliser des informations d’identification différentes, comme une chaîne de connexion, un principal de service ou une identité managée, pour accéder au système de messagerie dédié. Cette approche offre un plus haut niveau de sécurité et d’isolement entre les locataires, mais elle complexifie la gestion des identités.

De la même façon, une application basée sur les événements offre différents niveaux d’isolement :

  • Une application basée sur les événements reçoit des événements de plusieurs locataires, via une instance Azure Event Hubs partagée unique. Cette solution offre une grande agilité, car l’intégration d’un nouveau locataire n’impose pas la création d’une ressource d’ingestion d’événements dédiée. L’inconvénient est qu’elle fournit un faible niveau de protection des données, du fait qu’elle regroupe les messages des différents locataires dans la même structure de données.
  • Les locataires peuvent s’abonner à une rubrique Kafka ou un hub d’événements dédié pour éviter le problème de voisin bruyant et remplir leurs exigences en matière d’isolement des données, lorsque les événements ne doivent pas être regroupés avec ceux d’autres locataires. Cela permet de garantir la sécurité et la protection des données.
  • Si les locataires nécessitent un haut niveau de résilience et de continuité de l’activité, une solution multilocataire doit permettre de provisionner un espace de noms Event Hubs Premium où la géo-reprise d’activité après sinistre et les zones de disponibilité sont activées. Pour en savoir plus, consultez Azure Event Hubs – Géo-reprise d’activité après sinistre.
  • Des instances Event Hubs dédiées, avec la fonctionnalité Event Hubs Capture activée, doivent être créées pour les clients qui veulent archiver les événements dans un compte de stockage Azure, pour se conformer aux obligations de conformité réglementaire. Pour plus d’informations, consultez Capturer des événements avec Azure Event Hubs dans Stockage Blob Azure ou Azure Data Lake Storage.
  • Une application multilocataire unique peut envoyer des notifications à plusieurs systèmes internes et externes, en utilisant Azure Event Grid. Dans ce cas, un abonnement Event Grid distinct doit être créé pour chaque application consommatrice. Si votre application utilise plusieurs instances Event Grid pour envoyer des notifications à un grand nombre d’organisations externes, envisagez d’utiliser des domaines d’événements. Ces domaines permettent à une application de publier des événements dans des milliers de rubriques (une par locataire). Pour plus d’informations, consultez Comprendre les domaines d’événements pour gérer les rubriques Event Grid.

Complexité de l'implémentation

Quand vous concevez une solution multilocataire, il est essentiel de prendre en compte la façon dont le système évoluera à moyen terme et à long terme. Vous éviterez ainsi qu’elle devienne de plus en plus complexe au fil du temps, jusqu’au moment où il sera nécessaire de reconcevoir votre solution, en partie ou en totalité. Cette reconception vous aidera à assurer la prise en charge d’un nombre croissant de locataires. Quand vous concevez un système de messagerie, vous devez tenir compte de la croissance attendue des volumes de messages et du nombre de locataires au cours des prochaines années. Sur cette base, vous créez un système capable de monter en charge au rythme du trafic prédit, tout en réduisant la complexité des opérations telles que le provisionnement, le monitoring et la maintenance.

La solution doit automatiquement créer ou supprimer les entités de messagerie nécessaires chaque fois qu’une application cliente est provisionnée ou déprovisionnée, sans que cela demande des opérations manuelles.

Un point important à prendre en compte avec les solutions de données multilocataires est le niveau de personnalisation possible. Toute personnalisation doit être automatiquement configurée et appliquée par le système de provisionnement des applications (par exemple, un système DevOps), qui est basé sur un ensemble de paramètres initiaux, dès qu’une application monolocataire ou multilocataire est déployée.

Complexité de la gestion et des opérations

Dès le début de la conception, prévoyez comment vous souhaitez utiliser, superviser et administrer votre infrastructure de gestion des messages et des événements, et de quelle manière votre approche d’architecture multilocataire impacte vos opérations et processus. Par exemple, étudiez les possibilités suivantes :

  • Vous pouvez choisir d’héberger le système de messagerie utilisé par votre application dans un ensemble dédié de machines virtuelles, une pour chaque locataire. Dans ce scénario, comment prévoyez-vous de déployer, mettre à niveau, superviser et monter en charge ces systèmes ?
  • De même, si vous conteneurisez et hébergez votre système de messagerie dans un cluster Kubernetes partagé, comment prévoyez-vous de déployer, mettre à niveau, superviser et monter en charge chaque système de messagerie ?
  • Supposons que vous partagiez un système de messagerie entre plusieurs locataires. Comment votre solution peut-elle collecter et envoyer les métriques d’usage par locataire, ou limiter le nombre de messages que chaque locataire peut envoyer ou recevoir ?
  • Si votre système de messagerie utilise un service PaaS, tel qu’Azure Service Bus, vous devez vous poser les questions suivantes :
    • Comment pouvez-vous personnaliser le niveau tarifaire pour chaque locataire en fonction des fonctionnalités et du niveau d’isolement (partagé ou dédié) demandés par le locataire ?
    • Comment pouvez-vous créer une identité managée par locataire et une attribution de rôles Azure pour attribuer les autorisations appropriées uniquement aux entités de messagerie (files d’attente, rubriques et abonnements) auxquelles le locataire peut accéder ? Pour plus d’informations, consultez Authentifier une identité managée avec Microsoft Entra ID pour accéder aux ressources Azure Service Bus.
  • Comment allez-vous effectuer la migration des locataires qui doivent passer à un autre type de service de messagerie, à un autre déploiement ou à une autre région ?

Coût

En règle générale, plus la densité de locataires de votre infrastructure de déploiement est élevée, plus le coût d'approvisionnement de cette infrastructure est faible. Cela dit, l'infrastructure partagée augmente la probabilité de rencontrer des problèmes, tels que le problème de voisin bruyant, d'où la nécessité de bien réfléchir aux compromis à faire.

Approches et modèles à prendre en compte

Plusieurs modèles de conception cloud du Centre des architectures Azure peuvent être appliqués à un système de messagerie multilocataire. Vous pouvez choisir de suivre un ou plusieurs modèles de manière cohérente, ou de trouver et combiner des modèles répondant à vos besoins. Par exemple, vous pouvez utiliser un espace de noms Service Bus multilocataire pour la plupart de vos locataires, et ensuite déployer un espace de noms Service Bus monolocataire dédié pour les locataires qui paient davantage ou qui ont des exigences plus élevées en matière d’isolement et de performances. De même, il est souvent judicieux d’effectuer des mises à l’échelle à l’aide d’empreintes de déploiement, même lorsque vous utilisez un espace de noms Service Bus multilocataire ou des espaces de noms dédiés au sein d’une empreinte.

Modèle d’empreintes de déploiement

Pour plus d’informations sur le modèle Empreintes de déploiement et la multilocation, consultez la section relative au modèle Empreintes de déploiement dans les approches architecturales pour la multilocation. Pour plus d’informations sur les modèles de location, consultez Modèles de location possibles pour une solution multilocataire.

Système de messagerie partagé

Vous pouvez envisager de déployer un système de messagerie partagé, comme Azure Service Bus, et de le partager entre tous vos locataires.

Diagramme illustrant un système de messagerie mutualisé partagé unique pour tous les locataires.

Cette approche offre la plus forte densité de locataires par rapport à l'infrastructure, ce qui permet de réduire le coût total de possession. En outre, elle réduit souvent la surcharge de gestion, car il n’y a qu’un seul système de messagerie ou une seule ressource à gérer et à sécuriser.

Toutefois, lorsque vous partagez une ressource ou une infrastructure entière entre plusieurs locataires, il y a certains points à ne pas oublier :

  • Tenez toujours compte des contraintes, des capacités de mise à l’échelle, des quotas et des limites de la ressource en question. Par exemple, le nombre maximal d’espaces de noms Service Bus dans un abonnement Azure, le nombre maximal d’instances Event Hubs dans un même espace de noms ou les limites de débit maximales peuvent au final constituer des blocages matériels quand votre architecture grossit pour prendre en charge plus de locataires. Réfléchissez soigneusement à la taille maximale que vous devez atteindre en nombre d’espaces de noms par abonnement Azure ou en nombre de files d’attente par espace de noms. Comparez ensuite vos estimations actuelles et futures aux quotas et limites connus pour le système de messagerie de votre choix avant de choisir le modèle.
  • Comme mentionné dans les sections ci-dessus, le problème de voisin bruyant peut devenir gênant lorsque vous partagez une ressource sur plusieurs locataires, surtout si certains de ces locataires ont une charge particulièrement élevée ou s’ils génèrent plus de trafic que d’autres. Dans ce cas, pour atténuer ces effets, essayez d’appliquer le modèle Limitation ou le modèle Limitation du débit. Par exemple, vous pouvez limiter le nombre maximal de messages qu’un seul locataire peut envoyer ou recevoir dans l’unité de temps.
  • Vous rencontrerez peut-être des difficultés pour superviser l’activité et mesurer la consommation de ressource d’un seul locataire. Certains services, comme Azure Service Bus, facturent les opérations de messagerie. Par conséquent, lorsque vous partagez un espace de noms entre plusieurs locataires, votre application doit être en mesure de suivre le nombre d’opérations de messagerie effectuées au nom de chaque locataire ainsi que les coûts refacturés à chacun. D'autres services ne fournissent pas le même niveau de détail.

Les locataires peuvent avoir des exigences différentes en matière de sécurité, de résilience entre les régions, de reprise d’activité après sinistre ou d’emplacement. Si ces exigences ne correspondent pas à la configuration de votre système de messagerie, vous risquez de ne pas pouvoir les remplir avec une seule ressource.

Modèle de partitionnement

Le modèle Partitionnement implique le déploiement de plusieurs systèmes de messagerie, appelés partitions, qui contiennent les entités de messagerie, telles que des files d’attente et des rubriques, d’un ou de plusieurs locataires. Contrairement aux empreintes de déploiement, les partitions n'impliquent pas que toute l'infrastructure soit dupliquée. Vous pouvez partitionner des systèmes de messagerie sans dupliquer ou partitionner d’autres infrastructures dans votre solution.

Schéma montrant un système de messagerie partagé. Un système de messagerie contient les files d'attente des locataires A et B, et l'autre contient les files d'attente du locataire C.

Chaque système de messagerie ou partition peut avoir des caractéristiques différentes en termes de fiabilité, référence SKU et emplacement. Par exemple, vous pouvez partitionner vos locataires sur plusieurs systèmes de messagerie avec des caractéristiques différentes, en fonction de leur emplacement ou bien de leurs exigences de performances, de fiabilité, de protection des données ou de continuité de l’activité.

Lorsque vous utilisez le modèle Partitionnement, vous devez utiliser une stratégie de partitionnement afin de mapper un locataire donné au système de messagerie qui contient ses files d’attente. La stratégie de recherche utilise un mappage pour différencier le système de messagerie cible, en fonction du nom ou de l’ID du locataire. Plusieurs locataires peuvent partager la même partition, mais les entités de messagerie utilisées par un locataire spécifique ne sont pas réparties sur plusieurs partitions. Le mappage peut être implémenté avec un dictionnaire unique qui mappe le nom du locataire au nom ou à la référence du système de messagerie cible. Le mappage peut être stocké dans un cache distribué accessible par toutes les instances d’une application multilocataire, ou dans un magasin persistant, tel qu’une table dans une base de données relationnelle ou une table dans un compte de stockage.

Le modèle Partitionnement peut s'adapter à un très grand nombre de locataires. En outre, en fonction de votre charge de travail, vous pouvez atteindre une densité élevée de locataires par rapport aux partitions, ce qui rend le coût intéressant. Le modèle Partitionnement peut également être utilisé pour satisfaire aux quotas, limites et contraintes des abonnements et services Azure.

Application multilocataire avec système de messagerie dédié pour chaque locataire

Une autre approche courante consiste à déployer une seule application multilocataire, avec des systèmes de messagerie dédiés pour chaque locataire. Dans ce modèle de location, vous avez des composants partagés, par exemple des ressources de calcul, tandis que d’autres services sont provisionnés et gérés selon une approche de déploiement dédié monolocataire. Par exemple, vous pouvez créer une couche application unique, puis déployer des systèmes de messagerie individuels pour chaque locataire, comme dans l’illustration suivante.

Diagramme montrant différents systèmes de messagerie pour chaque locataire.

Les déploiements partitionnés horizontalement peuvent vous aider à limiter les problèmes de voisin bruyant si vous avez repéré que la majeure partie de la charge système est due à des composants spécifiques que vous pouvez déployer séparément pour chaque locataire. Par exemple, vous devrez peut-être utiliser un système de messagerie ou de streaming d’événements distinct pour chaque locataire, si le trafic généré par les différents locataires ne peut pas être traité par une seule instance. Si vous utilisez un système de messagerie dédié pour chaque locataire et qu’un locataire génère à lui seul un volume important de messages ou d’événements, cela peut impacter les composants partagés mais pas les systèmes de messagerie des autres locataires.

Dans la mesure où vous provisionnez des ressources dédiées pour chaque locataire, le coût de cette approche peut être supérieur à celui d’un modèle d’hébergement partagé. En revanche, avec ce modèle de location, il est plus facile de refacturer les coûts des ressources d’un système dédié au seul locataire qui les utilise. Cette approche vous permet d’obtenir une haute densité pour d’autres services, tels que des ressources informatiques, et réduit les coûts de ces composants.

Avec un déploiement partitionné horizontalement, vous devez adopter un processus automatisé pour déployer et gérer les services d’une application multilocataire, en particulier ceux utilisés par un seul locataire.

Modèle Géode

Le modèle Geode implique le déploiement d’une collection de services back-end dans un ensemble de nœuds géographiques. Chacun peut traiter une requête d’un client dans n’importe quelle région. Avec ce modèle, vous traitez les requêtes dans un style actif-actif, ce qui vous permet de répartir le traitement des requêtes à travers le monde et ainsi de réduire la latence et d’améliorer la disponibilité.

Diagramme montrant le modèle Geode, avec des systèmes de messagerie déployés dans plusieurs régions qui se synchronisent ensemble.

Azure Service Bus et Azure Event Hubs prennent en charge la récupération des métadonnées après sinistre, dans les espaces de noms de reprise d’activité principaux et secondaires, et dans les régions et les zones de disponibilité séparées, afin d’assurer une résilience optimale entre les régions. De plus, Azure Service Bus et Azure Event Hubs implémentent un ensemble de modèles de fédération qui répliquent activement la même rubrique logique, la même file d’attente ou le même hub d’événements pour les mettre à disposition dans plusieurs espaces de noms, situés au final dans des régions différentes. Pour plus d’informations, consultez les ressources suivantes :

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autres contributeurs :

Étapes suivantes

Pour plus d’informations sur les modèles de conception de la messagerie, consultez les ressources suivantes :