Modèles de location pour une solution multilocataire

Il existe de nombreuses façons de réfléchir au mode d’utilisation des locataires dans votre solution. Votre approche dépend de la façon dont vous partagez des ressources entre vos locataires. Intuitivement, vous souhaiterez peut-être éviter de partager des ressources, mais cette approche devient rapidement coûteuse à mesure que votre entreprise est mise à l’échelle et que vous intégrez davantage de locataires.

Lorsque vous tenez compte des différents modèles de l’architecture mutualisée, il est utile de commencer par prendre en compte la façon dont vous définissez des locataires pour votre organisation, ce que sont vos pilotes métier et la façon dont vous envisagez de mettre à l’échelle votre solution. Cet article fournit des conseils pour aider les décideurs techniques à évaluer les modèles de location et leurs compromis.

Définir les locataires

Vous devez d’abord définir un client pour votre organisation. Considérez qui est votre client ou qui reçoit vos services. Il existe deux modèles principaux :

• Business to business (B2B) : Si vos clients sont d’autres organisations, vous mappez probablement vos locataires à ces clients. Toutefois, déterminez si vos clients ont des divisions, comme des équipes ou des services, et s’ils ont une présence dans plusieurs pays ou régions. Vous devrez peut-être mapper un client unique à plusieurs locataires si les besoins de ces sous-groupes sont différents. De même, un client peut souhaiter conserver deux instances de votre service afin qu’il puisse conserver ses environnements de développement et de production séparés les uns des autres. Un seul locataire a généralement plusieurs utilisateurs. Par exemple, tous les employés de votre client sont des utilisateurs au sein d’un locataire unique.

• Entreprise à consommateur (B2C) : Si vos clients sont des consommateurs, il est souvent plus compliqué de lier des clients, des locataires et des utilisateurs. Dans certains scénarios, chaque consommateur peut être un locataire distinct. Toutefois, déterminez si votre solution peut être utilisée par des familles, des groupes d’amis, des clubs, des associations ou d’autres groupes qui peuvent avoir besoin d’accéder à leurs données et de les gérer ensemble. Par exemple, un service de streaming de musique peut avoir des utilisateurs individuels et des familles, et il peut traiter chacun de ces types de comptes de façon différente lorsqu’il les sépare en locataires.

Votre définition de ce qu’est un locataire a un effet sur certaines des informations que vous devez prendre en compte ou mettre en avant au moment de la conception de votre solution. Par exemple, tenez compte des types de locataires suivants :

• Si vos locataires sont des personnes ou des familles individuelles, vous devrez peut-être tenir compte de la façon dont vous gérez des données personnelles et des lois sur la souveraineté des données dans chaque juridiction que vous servez.

• Si vos locataires sont des entreprises, vous devrez peut-être tenir compte des exigences de vos clients en matière de conformité réglementaire et d’isolation de leurs données. Assurez-vous que vous respectez un objectif de niveau de service (SLO) spécifié, comme le temps d’activité ou la disponibilité du service.

Choisir le modèle à utiliser

La sélection d’un modèle de location n’est pas seulement une décision technique. C’est aussi une décision commerciale. Vous devez prendre en compte les questions suivantes :

• Objectifs métier : Déterminez si la réduction du coût pour chaque locataire ou l’optimisation de l’expérience client s’aligne plus étroitement sur les objectifs stratégiques.

• Conformité : déterminez si vos clients acceptent toutes les formes de modèles multilocataires. Comment chaque modèle multilocataire affecte-t-il vos exigences de conformité ou les exigences de conformité de vos clients ?

• Échelle: Déterminez si une solution monolocataire peut être mise à l’échelle selon vos aspirations de croissance futures.

• Automatisation: Tenez compte de la taille de votre équipe d’exploitation et de la quantité de votre gestion de l’infrastructure que vous pouvez automatiser.

• Contrats de niveau de service (SLA) : Déterminez si vos clients s’attendent à ce que vous rencontriez des contrats SLA ou si vous avez des contrats SLA que vous ciblez.

Si vous vous attendez à ce que votre entreprise soit amenée à s’adapter à un grand nombre de clients, il est important de déployer une infrastructure partagée. Dans le cas contraire, vous devrez maintenir une flotte importante et croissante d’instances de ressources. Le déploiement de ressources Azure individuelles pour chaque client est probablement non durable, sauf si vous approvisionnez et utilisez un abonnement dédié pour chaque locataire. Lorsque vous partagez le même abonnement Azure sur plusieurs locataires, les quotas et limites des ressources Azure peuvent s’appliquer, et les coûts opérationnels pour déployer et reconfigurer ces ressources augmentent avec chaque nouveau client.

À l’inverse, si vous vous attendez à ce que votre entreprise n’ait que quelques clients, il peut être intéressant d’avoir des ressources à locataire unique dédiées à chaque client. Par ailleurs, si les exigences d’isolation de vos clients sont élevées, une approche d’infrastructure à locataire unique pourrait être appropriée, même si elle est plus coûteuse.

Locataires et déploiements

Ensuite, vous devez déterminer si vous devez faire la distinction entre les locataires logiques et les déploiements.

Prenons l’exemple d’un service de streaming de musique. Au départ, vous pouvez créer une solution qui peut facilement gérer des milliers ou même des dizaines de milliers d’utilisateurs. Toutefois, au fur et à mesure que votre organisation continue de croître, vous pourriez constater que vous devez dupliquer votre solution ou certains de ses composants pour répondre à la demande accrue de la clientèle. Pour accomplir cette tâche, vous devez déterminer comment affecter des clients spécifiques à des instances spécifiques de votre solution. Vous pouvez affecter des clients de manière aléatoire, géographique ou en remplissant une seule instance, puis en démarrant une autre instance, également appelée empaquetage de compartiments. Toutefois, vous devez probablement conserver un enregistrement de vos clients et de l’infrastructure où résident leurs données et applications afin de pouvoir acheminer leur trafic vers l’emplacement approprié. Dans cet exemple, vous pouvez représenter chaque client en tant que locataire distinct et mapper les utilisateurs au déploiement qui contient leurs données. Cette approche crée une relation un-à-plusieurs entre les locataires et les déploiements, et vous pouvez déplacer des locataires entre des déploiements à votre discrétion.

À l’inverse, imaginons une société qui crée des logiciels cloud pour les cabinets juridiques. Vos clients peuvent insister sur le fait qu’ils doivent disposer de leur propre infrastructure dédiée pour rester conformes aux exigences réglementaires. Par conséquent, vous devez être prêt à déployer et à gérer de nombreuses instances de votre solution, et ce dès le départ. Dans cet exemple, un déploiement contient toujours un locataire unique, et un locataire est mappé à son propre déploiement dédié.

Une différence clé entre les locataires et les déploiements est la façon dont l'isolation est appliquée. Lorsque plusieurs locataires partagent un même déploiement (ensemble d’infrastructure), vous vous appuyez généralement sur le code de votre application et sur un identificateur de locataire qui est dans une base de données pour séparer les données de chaque locataire. Lorsque les locataires ont leurs propres déploiements dédiés, ils disposent de leur propre infrastructure. Il peut donc être moins important pour votre code de tenir compte d’un environnement mutualisé.

Les déploiements sont parfois désignés sous le terme de superlocataires ou d’empreintes.

Lorsque vous recevez une demande pour un locataire spécifique, vous devez la mapper au déploiement qui contient les données de ce locataire, comme illustré dans le diagramme suivant :

Pour plus d’informations, consultez Mapper les demandes aux locataires.

Isolation des locataires

L’un des principaux points à prendre en compte dans la conception d’architecture mutualisée est le niveau d’isolation dont chaque locataire a besoin. L’isolation peut faire référence aux configurations suivantes :

• Avoir une infrastructure partagée unique qui inclut des instances distinctes de votre application et des bases de données distinctes pour chaque locataire.

• Le partage de certaines ressources communes tout en maintenant les autres ressources séparées pour chaque locataire.

• La conservation des données sur une infrastructure physique distincte. Dans le cloud, cette configuration peut nécessiter des ressources Azure distinctes pour chaque locataire. Dans des scénarios extrêmes, il peut même vous obliger à déployer une infrastructure physique distincte à l’aide d’hôtes dédiés.

Au lieu de considérer l’isolation comme une propriété discrète, voyez-la comme un spectre. Vous pouvez déployer des composants de votre architecture qui sont plus isolés ou moins isolés que d’autres composants de la même architecture, en fonction de vos besoins. Le diagramme suivant présente un continuum d’isolation :

Le niveau d’isolation affecte de nombreux aspects de votre architecture :

• Sécurité: Si vous partagez l’infrastructure entre plusieurs locataires, veillez à ne pas accéder aux données d’un locataire lorsque vous retournez des réponses à une autre. Vous avez besoin d’une base solide pour votre stratégie d’identité, et vous devez prendre en compte l’identité des locataires et des utilisateurs dans votre processus d’autorisation.

• Coût: Plusieurs locataires peuvent utiliser l’infrastructure partagée, de sorte qu’il est moins coûteux.

• Performance: Si vous partagez l’infrastructure, les performances de votre système peuvent se dégrader car davantage de clients l’utilisent, car les ressources peuvent être consommées plus rapidement. Les locataires qui ont des modèles d’utilisation inhabituels peuvent aggraver les problèmes de performances.

• Fiabilité: Si vous utilisez un seul ensemble d’infrastructures partagées, un problème avec un composant peut entraîner une panne pour tous vos locataires.

• Réactivité aux besoins individuels des locataires : Lorsque vous déployez une infrastructure dédiée à un locataire, vous pouvez peut-être adapter la configuration des ressources à ces besoins spécifiques du locataire. Vous pouvez même envisager cette fonctionnalité dans votre modèle de tarification pour permettre aux clients de payer davantage pour les déploiements isolés.

L’architecture de votre solution peut influencer les options d’isolation disponibles. Prenez par exemple une architecture de solution à trois niveaux :

• Votre niveau d’interface utilisateur peut être une application web mutualisée partagée. Tous vos locataires accèdent à un nom d’hôte unique.

• Votre niveau intermédiaire peut être une couche d’application partagée qui a des files d’attente de messages partagées.

• Votre niveau de données peut être composé de bases de données isolées, de tables isolées ou de conteneurs de blobs.

Vous pouvez utiliser différents niveaux d’isolation pour chaque niveau. Vous devez baser votre décision sur le partage et l’isolation de plusieurs facteurs, notamment le coût, la complexité, les exigences de vos clients et le nombre de ressources que vous pouvez déployer avant d’atteindre les quotas et limites Azure.

Modèles courants

Après avoir établi vos besoins, évaluez-les par rapport aux modèles de location courants et aux modèles de déploiement correspondants.

Déploiements automatisés à locataire unique

Dans un modèle de déploiement à locataire unique automatisé, vous déployez un ensemble dédié d’infrastructure pour chaque locataire, comme illustré dans l’exemple suivant :

Votre application est chargée d’initialiser et de coordonner le déploiement des ressources de chaque locataire. En règle générale, les solutions qui utilisent ce modèle utilisent l’infrastructure en tant que code ou les API Azure Resource Manager largement. Vous pouvez utiliser cette approche lorsque vous devez approvisionner des infrastructures entièrement distinctes pour chacun de vos clients. Envisagez d’utiliser le modèle d’empreintes de déploiement lors de la planification de votre déploiement.

Avantages : un des principaux avantages de cette approche est que les données de chaque locataire sont isolées, ce qui réduit le risque de fuite accidentelle. Cette protection peut être importante pour les clients qui ont une charge de conformité réglementaire élevée. En outre, les locataires sont peu susceptibles d’affecter les performances du système les uns des autres, également appelé problème de voisin bruyant . Les mises à jour et les modifications peuvent être déployées progressivement pour les locataires, ce qui réduit la probabilité d’une panne à l’échelle du système.

Risques: Si vous utilisez cette approche, l’efficacité des coûts est faible, car vous ne partagez pas l’infrastructure entre vos locataires. Si un seul locataire nécessite un coût d’infrastructure spécifique, 100 locataires nécessitent probablement 100 fois ce coût. En outre, la maintenance continue, comme l’application de nouvelles mises à jour logicielles ou de configuration, peut prendre du temps. Envisagez d’automatiser vos processus opérationnels et d’appliquer les modifications progressivement dans vos environnements. Vous devriez également considérer d’autres opérations inter-déploiements, comme les rapports et les analyses sur l’ensemble de votre flotte. Planifiez la façon dont vous pouvez interroger et manipuler des données sur plusieurs déploiements.

Déploiements mutualisés complets

À l’extrême opposé, vous pouvez envisager un déploiement entièrement mutualisé dans lequel tous les composants sont partagés. Vous n’avez qu’une seule infrastructure à déployer et à gérer, et tous les locataires l’utilisent, comme indiqué dans le diagramme suivant :

Avantages: Ce modèle est attrayant, car l’exploitation d’une solution qui a des composants partagés est moins coûteuse que l’utilisation de ressources individuelles pour chaque locataire. Même si vous devez déployer des niveaux ou des SKU de ressources plus élevés pour tenir compte de la charge accrue, le coût global du déploiement est souvent encore inférieur au coût d’un ensemble de ressources à locataire unique. En outre, si un utilisateur ou un locataire doit déplacer ses données vers un autre locataire, vous pouvez peut-être mettre à jour les identificateurs et clés du locataire, et vous n’avez peut-être pas besoin de migrer des données entre deux déploiements distincts.

Risques :

• Veillez à séparer les données pour chaque locataire et à ne pas divulguer de données entre les locataires. Vous devrez peut-être gérer le partitionnement des données. Vous devrez peut-être également tenir compte des effets que les locataires individuels peuvent avoir sur le système global. Par exemple, si un locataire de grande taille essaie d’exécuter une requête ou une opération lourde, cela peut affecter d’autres locataires.

• Déterminez comment suivre et associer vos coûts Azure aux locataires, si ces informations sont importantes pour vous.

• Vous pouvez simplifier la maintenance à l’aide d’un seul déploiement, car vous n’avez qu’à mettre à jour un ensemble de ressources. Toutefois, il est souvent plus risqué, car les modifications peuvent affecter l’ensemble de votre base de clients.

• Vous devrez peut-être également prendre en compte la mise à l’échelle. Il est plus probable que vous atteigniez les limites d’échelle des ressources Azure lorsque vous mettez en place une infrastructure partagée. Par exemple, si vous utilisez un compte de stockage dans le cadre de votre solution, lorsque la taille augmente, le nombre de requêtes envoyées à ce compte de stockage peut atteindre la limite de ce qu’il peut gérer. Pour éviter d’atteindre une limite de quota de ressources, vous pouvez déployer un pool de plusieurs instances de vos ressources, telles que plusieurs clusters AKS ou comptes de stockage. Vous pourriez même distribuer vos locataires parmi des ressources que vous déployez dans plusieurs abonnements Azure.

• Il existe probablement une limite à la quantité de mise à l’échelle d’un déploiement unique, et les coûts de mise à l’échelle peuvent augmenter non linéairement. Par exemple, si vous disposez d’une base de données partagée unique que vous exécutez à grande échelle, vous risquez d’épuiser son débit et de devoir payer de plus en plus pour augmenter le débit pour maintenir votre demande.

Déploiements partitionnés verticalement

Le choix ne se limite pas à ces deux solutions extrêmes. Au lieu de cela, vous pouvez partitionner verticalement vos locataires en suivant l’approche suivante :

• Utilisez une combinaison de déploiements à locataire unique et de déploiements mutualisés. Par exemple, vous pouvez avoir la plupart des niveaux de données et d’application de vos clients sur des infrastructures mutualisées, mais vous déployez des infrastructures monolocataires pour les clients qui nécessitent des performances ou une isolation des données supérieures.

• Déployez plusieurs instances de votre solution de manière géographique, et mappez chaque locataire à un déploiement en particulier. Cette approche est efficace lorsque vous avez des locataires dans différentes zones géographiques.

Voici un exemple qui illustre un déploiement partagé pour certains locataires et un déploiement à locataire unique pour un autre :

Avantages: Étant donné que vous partagez toujours une partie de votre infrastructure, vous pouvez bénéficier de certains des avantages liés à l’utilisation de déploiements multilocataire partagés. Vous pouvez déployer des ressources partagées moins coûteuses pour des clients spécifiques, tels que les clients qui évaluent votre service à l’aide d’une version d’évaluation. Vous pouvez même facturer aux clients un taux plus élevé pour utiliser un déploiement à locataire unique, ce qui vous permet de récupérer certains de vos coûts.

Risques : votre base de code doit être conçue de façon à prendre en charge à la fois les déploiements multilocataires et les déploiements à locataire unique. Si vous prévoyez d’autoriser la migration entre les déploiements, vous devez réfléchir à la façon de migrer les clients d’un déploiement multilocataire vers leur propre déploiement à locataire unique. Vous devez également savoir lequel de vos locataires se trouvent sur chaque déploiement afin de pouvoir communiquer des informations sur les problèmes système ou les mises à niveau vers les clients concernés.

Déploiements partitionnés horizontalement

Vous pouvez également partitionner horizontalement vos déploiements. Dans un déploiement horizontal, vous avez certains composants partagés, mais vous en gérez d’autres avec des déploiements à locataire unique. Par exemple, vous pouvez créer une couche Application unique, puis déployer des bases de données individuelles pour chaque locataire, comme illustré dans ce diagramme :

Avantages: Les déploiements partitionnés horizontalement peuvent vous aider à atténuer un problème de voisin bruyant. Si vous identifiez que des composants spécifiques entraînent la plupart de la charge sur votre système, vous pouvez déployer des composants distincts pour chaque locataire. Par exemple, vos bases de données peuvent absorber la majeure partie de la charge de votre système, car la charge des requêtes est élevée. Si un seul locataire envoie un grand nombre de requêtes à votre solution, les performances d’une base de données peuvent être affectées, mais les bases de données des autres locataires (et les composants partagés comme la couche application) ne sont pas affectées.

Risques: Avec un déploiement partitionné horizontalement, vous devez toujours prendre en compte le déploiement et la gestion automatisés de vos composants, en particulier les composants utilisés par un seul locataire.

Tester votre modèle d’isolation

Quel que soit le modèle d’isolation que vous choisissez, veillez à tester votre solution pour vérifier que les données d’un locataire ne sont pas accidentellement divulguées vers une autre et que les résultats des voisins bruyants sont acceptables. Envisagez d’utiliser Azure Chaos Studio pour introduire délibérément des erreurs qui simulent des pannes réelles, et vérifier la résilience de votre solution même lorsque des composants ne fonctionnent pas correctement.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques

Autres contributeurs :

• Chad Kittel | Ingénieur logiciel principal, modèles Azure & Pratiques
• Paul Salvatori | Ingénieur client principal, FastTrack for Azure
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étape suivante

Tenez compte du cycle de vie de vos locataires.