Il existe de nombreuses façons de réfléchir au mode d’utilisation des locataires dans votre solution. Votre choix d’approche dépendra en grande partie de la façon dont vous partagez les ressources entre vos locataires. Intuitivement, vous souhaiterez peut-être éviter de partager des ressources, mais cette approche devient rapidement onéreux à mesure que votre entreprise évolue et que vous intégrez davantage de locataires.
Lorsque vous considérez les différents modèles de multilocation, il est utile de commencer par prendre en compte la façon dont vous définissez les locataires pour votre organisation, quels sont vos axes stratégiques, et la façon dont vous prévoyez 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
Tout d’abord, vous devez définir ce qu’est un locataire pour votre organisation. Pensez à qui sont vos clients. En d’autres termes, à qui fournissez-vous vos services ? Il existe deux modèles principaux :
- B2B (interentreprises). Si vos clients sont d’autres entreprises, vous mapperez probablement vos locataires à ces clients. Déterminez cependant si vos clients ont différentes divisions (équipes ou services) et s’ils sont présents dans plusieurs pays/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 vouloir disposer de deux instances de votre service, de sorte que les environnements de développement et de production puissent rester séparés. En règle générale, un locataire a plusieurs utilisateurs. Par exemple, tous les employés de votre client seront des utilisateurs au sein d’un locataire unique.
- B2C (entreprise-client). Si vos clients sont des consommateurs, il est souvent plus compliqué d’associer les notions de client, de locataire et d’utilisateur. 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 aura un effet sur certaines des informations que vous devez prendre en compte ou mettre en avant au moment de la conception de votre solution. Prenez par exemple les types de locataires suivants :
- Si vos locataires sont des personnes ou des familles, vous devrez peut-être vous soucier de la gestion des données personnelles, ainsi que des lois sur la souveraineté des données au sein des différentes juridictions dans lesquelles vous travaillez.
- Si vos locataires sont des entreprises, vous devrez peut-être vous soucier des exigences de vos clients en matière de conformité réglementaire, d’isolation des données, et vous assurer que vous vous conformez bien à un objectif de niveau de service précis, par exemple en matière de durée de bon fonctionnement ou de disponibilité du service.
Comment 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 tenir compte de questions telles que celles-ci :
- Quels sont vos objectifs stratégiques ?
- Vos clients vont-ils accepter toutes les formes d’architecture mutualisée ? Quel est l’impact de chaque modèle de multilocation sur vos exigences de conformité ou sur les exigences de conformité de votre client ?
- Une solution à un seul locataire peut-elle évoluer pour répondre à vos aspirations de croissance ?
- Quelle est la taille de votre équipe d’exploitation, et quelle est la part de la gestion de l’infrastructure que vous pouvez automatiser ?
- Vos clients attendent-ils de vous que vous respectiez des contrats de niveau de service, ou visez-vous vous-même des objectifs bien définis ?
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 croissante d’instances de grande taille. Le déploiement de ressources Azure individuelles pour chaque client peut ne pas être viable, sauf si vous provisionnez et utilisez un abonnement dédié pour chaque locataire. Lorsque vous partagez le même abonnement Azure entre plusieurs locataires, les quotas et limites de ressources Azure peuvent commencer à s’appliquer, et les coûts opérationnels de déploiement et de reconfiguration de ces ressources augmentent à 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 infrastructure à locataire unique peut être appropriée.
Locataires et déploiements
Ensuite, vous devez déterminer ce que vous entendez par locataire dans votre solution, et 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 capable de gérer facilement des milliers (voire des dizaines de milliers) d’utilisateurs. Cependant, à mesure que le service continue de croître, vous pouvez être amené à dupliquer votre solution ou certains de ses composants afin de répondre aux besoins de nouveaux clients. Vous devez donc déterminer comment assigner des clients spécifiques à des instances spécifiques de votre solution. Vous pouvez assigner les clients de façon aléatoire ou géographique, ou bien en remplissant une instance puis en en démarrant une autre. Toutefois, vous devez probablement conserver des informations sur vos clients et sur l’infrastructure sur laquelle leurs données et leurs applications sont disponibles, et ce afin de pouvoir router le trafic vers la bonne infrastructure. Dans cet exemple, vous pouvez représenter chaque client en tant que locataire distinct, puis mapper les utilisateurs au déploiement qui contient leurs données. Vous avez un mappage un-à-plusieurs entre les locataires et les déploiements, et vous pouvez déplacer les locataires parmi les déploiements à votre propre 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 respecter les normes de conformité. 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 vous avez des locataires avec leurs propres déploiements dédiés, ils disposent de leur propre infrastructure, et il peut donc être moins important que votre code sache qu’il opère dans un environnement multilocataire.
Les déploiements sont parfois désignés sous le terme de superlocatairesou d’empreintes.
Lorsque vous recevez une demande pour un locataire spécifique, vous devez le mapper au déploiement qui contient les données de ce locataire, comme illustré ici :
Isolation des locataires
L’une des principales considérations en matière de conception d’architecture multilocataire est le niveau d’isolation dont chaque locataire a besoin. L’isolation peut se rapporter à différentes choses :
- Le fait de n’avoir qu’une seule infrastructure partagée, avec 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. Cela peut même signifier le déploiement d’une infrastructure physique distincte à l’aide d’hôtes dédiés.
Plutôt que de considérer l’isolation comme une propriété discrète, vous devez la considérer comme un continuum. Vous pouvez déployer des composants de votre architecture qui sont plus ou moins isolés que les 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 a un effet sur de nombreux aspects de votre architecture, notamment :
- Sécurité. Si vous partagez l’infrastructure parmi plusieurs locataires, vous devez veiller à ne pas accéder aux données d’un locataire lorsque vous renvoyez des réponses à un 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. L’infrastructure partagée peut être utilisée par plusieurs locataires ; elle est donc moins coûteuse.
- Les performances. Si vous partagez l’infrastructure, les performances de votre système peuvent être affectées lorsque davantage de clients l’utilisent, car les ressources peuvent être consommées plus rapidement.
- Fiabilité. Si vous utilisez une seule infrastructure partagée, tout problème dans les composants d’un locataire peut entraîner une panne pour tout le monde.
- Réactivité aux besoins individuels des locataires. Lorsque vous déployez une infrastructure dédiée pour un locataire unique, vous pouvez adapter la configuration des ressources aux besoins de ce locataire. Vous pouvez même prendre en compte cette capacité dans votre modèle tarifaire, afin d’offrir aux clients la possibilité de payer davantage pour des 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 multilocataire partagée, dans le cadre de laquelle tous vos locataires accèdent à un seul nom d’hôte.
- Votre couche intermédiaire peut être une couche d’application partagée, avec des files d’attente de messages partagés.
- Votre couche de données peut consister en des bases de données isolées, des tables ou des conteneurs d’objets blob.
Vous pouvez utiliser différents niveaux d’isolation à chaque niveau. Vous devez baser votre décision concernant ce qui est partagé et ce qui est isolé sur différents éléments, notamment le coût, la complexité, les besoins de vos clients et le nombre de ressources que vous pouvez déployer avant d’atteindre les limites et les quotas 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 le cadre d’un modèle de déploiement automatisé à locataire unique, vous déployez une infrastructure dédiée pour chaque locataire, comme indiqué dans cet exemple :
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 créées à l’aide de ce modèle utilisent l’infrastructure en tant que code (IaC) ou les API Azure Resource Manager de manière intensive. Vous pouvez utiliser cette approche lorsque vous devez approvisionner des infrastructures entièrement distinctes pour chacun de vos clients. Tenez compte du modèle d’empreintes de déploiement lorsque vous planifiez 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. Ce dispositif de protection peut être important pour certains clients dont les exigences de conformité réglementaire sont élevées. En outre, il est peu probable qu’un locataire affecte les performances système d’un autre, ce qu’on appelle parfois le 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 adoptez cette approche, la rentabilité est faible, car vous ne partagez pas l’infrastructure parmi vos locataires. Si un locataire unique nécessite un certain coût d’infrastructure, 100 locataires nécessitent probablement 100 fois ce coût. En outre, la maintenance continue (comme l’application d’une nouvelle configuration ou de nouvelles mises à jour logicielles) prendra sans doute du temps. Envisagez d’automatiser vos processus opérationnels et d’appliquer les modifications progressivement dans vos environnements. Vous devez également tenir compte des autres opérations concernant tous les déploiements, par exemple la création de rapports et l’analyse sur l’ensemble de vos ressources. De même, veillez à bien planifier la manière dont vous pouvez interroger et manipuler les données dans plusieurs déploiements.
Déploiements mutualisés complets
À l’extrême opposé, vous pouvez envisager un déploiement entièrement mutualisé, où 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. Même si vous devez déployer des niveaux ou des références SKU de ressources supérieurs, le coût global du déploiement est souvent tout de même inférieur à celui 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 les 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. En outre, vous devrez peut-être vous préoccuper des effets que chaque locataire peut avoir sur l’ensemble du système. 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 ceci est important à vos yeux.
La maintenance peut être plus simple avec un seul déploiement, car vous devez mettre à jour un seul ensemble de ressources. Toutefois, c’est aussi souvent plus risqué, car les modifications peuvent affecter l’ensemble de votre clientèle.
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 envisager de déployer plusieurs instances de vos ressources (par exemple 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 est probable qu’il y ait une limite à la possibilité de faire évoluer un déploiement unique, et que les coûts de cette opération puissent augmenter de façon non linéaire. Par exemple, si vous avez une seule base de données partagée, lorsque vous l’exécutez à très grande échelle, il est possible que vous épuisiez son débit et que vous deviez payer de plus en plus pour augmenter le débit afin de répondre à la demande.
Déploiements partitionnés verticalement
Le choix ne se limite pas à ces deux solutions extrêmes. Au lieu de cela, vous pouvez envisager de partitionner verticalement vos locataires en adoptant cette approche :
- Utilisez une combinaison de déploiements à locataire unique et de déploiements mutualisés. Par exemple, vous pouvez avoir la plupart des couches données et application de vos clients sur des infrastructures multilocataires, mais déployer des infrastructures à locataire unique pour les clients qui requièrent des performances plus élevées ou une plus grande isolation des données.
- Déployez plusieurs instances de votre solution de manière géographique, et mappez chaque locataire à un déploiement en particulier. Cette approche est particulièrement efficace lorsque vos locataires se trouvent 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 l’infrastructure, vous pouvez bénéficier de certains des avantages en termes de coûts des déploiements multilocataires partagés. Vous pouvez déployer des ressources partagées moins chères pour certains clients, comme ceux qui évaluent votre service avec un essai gratuit. Vous pouvez même facturer aux clients un tarif plus élevé pour qu’ils utilisent un déploiement à locataire unique, ce qui permet de réduire les coûts.
Risques : Votre base de code devra probablement ê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 infrastructures, 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 quels locataires se trouvent sur chaque déploiement, afin de pouvoir communiquer des informations sur les problèmes système ou les mises à niveau aux clients concernés.
Déploiements partitionnés horizontalement
Vous pouvez également envisager de 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 dans le diagramme suivant :
Avantages : Les déploiements partitionnés horizontalement peuvent vous aider à limiter les problèmes de voisin bruyant si vous observez 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, 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 tenir compte du déploiement et de 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 fuitent pas accidentellement vers un autre locataire, et que les effets éventuels de voisin bruyant 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
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- John Downs | Ingénieur client principal, FastTrack for Azure
Autres contributeurs :
- Chad Kittel | Ingénieur logiciel principal
- 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.
Étapes suivantes
Tenez compte du cycle de vie de vos locataires.