Approches architecturales pour le déploiement et la configuration de solutions multilocataires

Quels que soient votre architecture et les composants que vous utilisez pour l’implémenter, vous devez déployer et configurer les composants de votre solution. Dans un environnement multilocataire, il est important de tenir compte de la manière dont vous déployez vos ressources Azure, notamment lorsque vous déployez des ressources dédiées pour chaque locataire, ou lorsque vous reconfigurez les ressources selon le nombre de locataires dans votre système. Sur cette page, nous fournissons aux architectes de solutions des conseils sur le déploiement de solutions multilocataires, et présentons certaines approches à prendre en compte lorsque vous planifiez votre stratégie de déploiement.

Principaux éléments et exigences à prendre en compte

Il est important d’identifier précisément vos besoins avant de planifier votre stratégie de déploiement. Voici les points spécifiques à prendre en compte :

• Échelle attendue : Prévoyez-vous de prendre en charge un petit nombre de locataires (cinq ou moins, par exemple), ou de vous développer pour servir un grand nombre de locataires ?
• Intégration automatisée ou prise en charge : Lorsqu’un locataire est prêt à être intégré, pourra-t-il accomplir le processus lui-même en suivant une procédure automatisée ? Ou bien, les nouveaux locataires font-ils une demande, et vous les intégrez manuellement après avoir reçu cette demande ? Des étapes d’approbation manuelle sont-elles requises de la part de votre équipe, par exemple pour empêcher toute utilisation abusive de votre service ?
• Durée du provisionnement : Lorsqu’un locataire est prêt à être intégré, en combien de temps le processus d’intégration doit-il être achevé ? Si vous n’avez pas de réponse définitive, demandez-vous si cette valeur sera mesurée en secondes, minutes, heures ou jours.
• Place de marché Azure : Prévoyez-vous d’utiliser la Place de marché Azure pour lancer le déploiement ? Si c’est le cas, il existe des conditions à remplir pour ajouter de nouveaux locataires.

Vous devez également prendre en compte les étapes d’intégration et de configurer, l’automatisation et la responsabilité de la gestion des ressources.

Étapes d’intégration et de configuration

Pensez à tout ce que vous devez faire lors de l’intégration d’un locataire, et documentez cette liste et ce flux de travail, même s’il est effectué manuellement. Le processus d’intégration inclut généralement les éléments suivants :

• Acceptation des accords commerciaux.
• Collecte des informations dont vous avez besoin afin de configurer votre système pour le nouveau locataire.
• Des étapes d’approbation manuelle, par exemple pour prévenir la fraude ou l’abus de votre service.
• Le provisionnement des ressources dans Azure.
• Créer ou configurer des noms de domaine.
• Effectuez les tâches de configuration post-déploiement, notamment la création du premier compte d’utilisateur pour le tenant et la transmission sécurisée de ses informations d’identification au tenant.
• Modifications manuelles de la configuration, par exemple des changements d’enregistrement DNS.

Documentez clairement le flux de travail nécessaire à l’intégration d’un nouveau locataire.

Considérez également les ressources Azure spécifiques que vous devez provisionner pour un locataire. Même si vous ne prévoyez pas de ressources dédiées pour chaque locataire, demandez-vous si vous devez parfois déployer des ressources lors de l’intégration d’un nouveau locataire. Cela peut se produire lorsqu’un locataire exige que ses données soient stockées dans une région spécifique, ou lorsque vous approchez des limites d’une empreinte ou d’un composant de votre solution et que vous devez créer une autre instance pour le prochain lot de locataires.

Demandez-vous si le processus d’intégration est susceptible de perturber les autres locataires, en particulier ceux qui partagent la même infrastructure. Par exemple, si vous devez modifier des bases de données partagées, ce processus pourrait-il avoir un impact sur les performances que les autres locataires pourraient remarquer ? Demandez-vous si vous pouvez éviter ces effets ou les atténuer en effectuant le processus d’intégration en dehors des heures de travail habituelles.

Automatisation

Les déploiements automatisés sont toujours conseillés pour les solutions hébergées dans le cloud. Si vous utilisez des solutions multilocataires, l’automatisation du déploiement devient encore plus importante pour les raisons suivantes :

• Échelle : les processus de déploiement manuels deviennent de plus en plus complexes et chronophages à mesure que votre nombre de tenants augmente. Une approche de déploiement automatisé est plus facile à mettre à l'échelle à mesure que le nombre de tenants augmente.
• Répétable : Dans un environnement multilocataire, utilisez un processus cohérent pour les déploiements dans l’ensemble des locataires. Les processus manuels introduisent un risque d’erreur ou la réalisation d’étapes pour certains locataires et pas pour d’autres. Ces processus manuels laissent votre environnement dans un état incohérent, ce qui complique la gestion de la solution par votre équipe.
• Impact des interruptions : Les déploiements manuels sont beaucoup plus risqués et sujets à des interruptions que les déploiements automatisés. Dans un environnement multilocataire, l’impact d’une interruption à l’échelle du système (due à une erreur de déploiement) peut être élevé car chaque locataire peut être affecté.

Lorsque vous effectuez un déploiement dans un environnement multilocataire, vous devez utiliser des pipelines de déploiement et des technologies d’infrastructure en tant que code (IaC), par exemple Bicep, les modèles JSON ARM, Terraform ou les SDK Azure.

Si vous envisagez de proposer votre solution via la Place de marché Azure, vous devez prévoir un processus d’intégration entièrement automatisé pour les nouveaux locataires. Ce processus est décrit dans la documentation sur les API de traitement SaaS.

Capacité maximale des ressources

Lorsque vous déployez par programmation des ressources de locataires sur des ressources partagées, tenez compte de la limite de capacité de chaque ressource. Lorsque vous vous approchez de cette limite, vous devrez peut-être créer une autre instance de la ressource pour permettre une plus grande mise à l’échelle. Tenez compte des limites de chaque ressource que vous déployez, et des conditions qui vous inciteront à déployer une autre instance.

Par exemple, si votre solution inclut un serveur logique Azure SQL et que votre solution prévoit une base de données dédiée sur ce serveur pour chaque locataire. Un serveur logique unique comporte des limites, qui incluent un nombre maximum de bases de données qu’un serveur logique prend en charge. À mesure que vous approchez de ces limites, vous devrez peut-être provisionner de nouveaux serveurs afin de pouvoir continuer à intégrer des locataires. Réfléchissez à la possibilité d’automatiser ce processus ou de surveiller manuellement l’augmentation de vos locataires.

Responsabilité de la gestion des ressources

Dans certaines solutions multilocataires, vous déployez des ressources Azure dédiées à chaque locataire, par exemple une base de données pour chacun d’eux. Vous pouvez également décider d’un nombre déterminé de locataires à héberger sur une instance unique d’une ressource, de sorte que le nombre de locataires détermine l’ensemble des ressources que vous déployez sur Azure. Dans d’autres solutions, vous déployez un ensemble unique de ressources partagées, puis vous reconfigurez ces ressources lorsque vous intégrez de nouveaux locataires.

Chacun de ces modèles vous oblige à déployer et à gérer les ressources de différentes manières, et vous devez considérer comment vous allez déployer et gérer le cycle de vie des ressources que vous provisionnez. Les deux approches les plus courantes sont les suivantes :

• Traiter les locataires comme une configuration des ressources que vous déployez, et utiliser vos pipelines de déploiement pour déployer et configurer ces ressources.
• Traiter les tenants comme des données, puis faire en sorte qu’un plan de contrôle approvisionne, puis configure l’infrastructure pour vos locataires.

Une discussion plus approfondie de ces approches est présentée ci-dessous.

Test

Prévoyez de tester minutieusement votre solution pendant et après chaque déploiement. Vous pouvez utiliser les tests automatisés pour vérifier le comportement fonctionnel et non fonctionnel de votre solution. Veillez à tester votre modèle d’isolement des locataires et à utiliser des outils comme Azure Chaos Studio pour introduire délibérément des failles qui simulent des interruptions réelles, puis vérifiez que votre solution fonctionne même lorsqu’un composant est indisponible ou défaillant.

Approches et modèles à prendre en compte

Plusieurs modèles de conception issus du Centre des architectures Azure et de la communauté au sens large sont adaptés au déploiement et à la configuration de solutions multilocataires.

Modèle d’empreintes de déploiement

Le modèle Empreintes de déploiement implique le déploiement d'une infrastructure dédiée pour un locataire ou un groupe de locataires. Une même empreinte peut contenir plusieurs locataires ou être dédiée à un seul locataire. Vous pouvez choisir de déployer une seule empreinte, ou de coordonner un déploiement sur plusieurs empreintes. Si vous déployez des empreintes dédiées pour chaque locataire, vous pouvez également déployer des empreintes complètes par programmation.

Anneaux de déploiement

Les anneaux de déploiement vous permettent de déployer des mises à jour sur différents groupes d’infrastructure à divers moments. Cette approche est couramment utilisée avec le modèle Empreintes de déploiement, et des groupes d’empreintes peuvent être attribués dans des anneaux distincts selon les préférences des tenants, les types de charge de travail et d’autres considérations. Pour plus d’informations, voir Anneaux de déploiement.

Indicateurs de fonctionnalités

Les indicateurs de fonctionnalités vous permettent d’exposer progressivement de nouvelles fonctionnalités ou versions de votre solution à différents tenants, tout en conservant une base de code unique. Pensez à utiliser Azure App Configuration pour gérer vos indicateurs de fonctionnalités. Pour plus d’informations, voir Indicateurs de fonctionnalités.

Parfois, vous devez activer de manière sélective des fonctionnalités spécifiques pour certains clients. Par exemple, vous pouvez avoir différents niveaux tarifaires qui donnent accès à certaines fonctionnalités. Les indicateurs de fonctionnalités sont généralement déconseillés pour ces scénarios. Envisagez plutôt de mettre en place un processus permettant de suivre et d’appliquer les droits de licence de chaque client.

Antimodèles à éviter

Lorsque vous déployez et configurez des solutions multilocataires, il est important d’éviter les situations qui vous empêchent votre entreprise de se développer. Leurs thèmes sont les suivants :

• Déploiement et tests manuels. Comme décrit ci-dessus, les processus de déploiement manuels ajoutent des risques et ralentissent votre capacité de déploiement. Nous vous recommandons d’utiliser des pipelines pour les déploiements automatisés à l’aide de pipelines et/ou de créer des ressources de manière programmatique depuis le code de votre solution.
• Personnalisations spécialisées pour les tenants. Évitez de déployer des fonctionnalités ou une configuration qui ne s’appliquent qu’à un seul locataire. Cette approche augmente la complexité de vos déploiements et vos processus de test. Utilisez plutôt les mêmes types de ressources et la même base de code pour chaque locataire, et utilisez des stratégies comme les indicateurs de fonctionnalités pour les changements temporaires ou pour les fonctionnalités déployées progressivement, ou utilisez différents niveaux tarifaires avec des droits de licence pour activer de façon sélective les fonctionnalités pour les locataires qui en ont besoin. Utilisez un processus de déploiement cohérent et automatisé, même pour les locataires qui disposent de ressources isolées ou dédiées.

Listes de locataires comme configuration ou données

Vous pouvez envisager les deux approches suivantes lorsque vous déployez des ressources dans une solution multilocataire :

• Utilisez un pipeline de déploiement automatisé pour déployer chaque ressource. À mesure que de nouveaux locataires sont ajoutés, reconfigurez votre pipeline afin de fournir les ressources pour chaque locataire.
• Utilisez un pipeline de déploiement automatisé pour déployer des ressources partagées qui ne dépendent pas du nombre de locataires. Pour les ressources déployées pour chaque locataire, créez-les dans votre application.

En considérant les deux approches, vous devez faire la distinction entre traiter votre liste de locataires comme une configuration ou comme des données. Cette distinction est également importante quand vous réfléchissez à la façon de créer un plan de contrôle pour votre système.

Liste des locataires en tant que configuration

Quand vous traitez votre liste de tenants en tant que configuration, vous déployez toutes vos ressources depuis un pipeline de déploiement centralisé. Lorsque de nouveaux locataires sont intégrés, vous reconfigurez le pipeline ou ses paramètres. En général, la reconfiguration est effectuée à l’aide de changements manuels, comme l’illustre le schéma suivant.

Le processus d’intégration d’un nouveau locataire peut ressembler à ce qui suit :

1. Mettez à jour la liste des locataires. Cela se fait généralement manuellement en configurant le pipeline lui-même, ou en modifiant un fichier de paramètres inclus dans la configuration du pipeline.
2. Déclenchez l’exécution du pipeline.
3. Le pipeline redéploie l’ensemble de vos ressources Azure, y compris les nouvelles ressources spécifiques au locataire.

Cette approche fonctionne généralement bien pour un petit nombre de locataires et pour les architectures où toutes les ressources sont partagées. Il s’agit d’une approche simple, car toutes vos ressources Azure peuvent être déployées et configurées à l’aide d’un seul processus.

Toutefois, lorsque vous vous approchez d’un grand nombre de locataires, disons 5 à 10 voire plus, il devient fastidieux de reconfigurer le pipeline à mesure que vous ajoutez des locataires. Le temps nécessaire à l’exécution du pipeline de déploiement augmente également souvent de manière significative. Cette approche ne permet pas non plus de créer facilement des locataires en libre-service, et le délai avant l’intégration d’un locataire peut être plus long car vous devez déclencher l’exécution de votre pipeline.

Liste de locataires comme données

Lorsque vous traitez votre liste de locataires comme des données, vous déployez toujours vos composants partagés en utilisant un pipeline. Cependant, pour les ressources et les paramètres de configuration qui doivent être déployés pour chaque locataire, vous devez impérativement déployer ou configurer vos ressources. Par exemple, votre plan de contrôle peut utiliser les Kits de développement logiciels (SDK) Azure pour créer une ressource spécifique ou pour lancer le déploiement d’un modèle paramétrisé.

Le processus d’intégration d’un nouveau locataire peut ressembler à ce qui suit, et se dérouler de manière asynchrone :

1. Demandez l’intégration d’un tenant, par exemple en lançant une requête d’API dans le plan de contrôle de votre système.
2. Un composant de flux de travail reçoit la demande de création et orchestre les étapes restantes.
3. Le flux de travail initie le déploiement des ressources spécifiques au locataire sur Azure. Cette étape peut être réalisée en utilisant un modèle de programmation impératif, par exemple en utilisant les SDK Azure, ou en déclenchant impérativement le déploiement d’un modèle Bicep ou Terraform.
4. Lorsque le déploiement est terminé, le workflow enregistre les détails du nouveau tenant dans le catalogue central des tenants. Les données stockées pour chaque locataire peuvent inclure l’ID du locataire et les ID des ressources pour toutes les ressources spécifiques au locataire créées par le flux de travail.

Vous pouvez ainsi fournir des ressources à de nouveaux locataires sans redéployer l’ensemble de votre solution. Le temps nécessaire au provisionnement de nouvelles ressources pour chaque locataire sera probablement plus court, car seules ces ressources doivent être déployées.

Mais cette approche est souvent beaucoup plus longue à mettre en place, et les efforts que vous déployez doivent être justifiés par le nombre de locataires ou les délais de provisionnement que vous devez respecter.

Si vous souhaitez en savoir plus sur cette approche, veuillez consulter la rubrique Considérations relatives aux plans de contrôle multi-tenants.

Exemple

Contoso exploite une solution multilocataire pour ses clients. Actuellement, elle compte six locataires, et prévoit de passer à 300 locataires dans les 18 prochains mois. Contoso suit l’approche d’une application multilocataire avec des bases de données dédiées pour chaque locataire. Elle a déployé un ensemble unique de ressources App Service et un serveur logique Azure SQL, partagés entre tous leurs locataires, et elle déploie une base de données Azure SQL dédiée pour chaque locataire, comme le montre le schéma suivant.

Contoso utilise Bicep pour déployer ses ressources Azure.

Option 1 - Utiliser des pipelines de déploiement pour tout

Contoso pourrait envisager de déployer toutes ses ressources à l’aide d’un pipeline de déploiement. Son pipeline déploie un fichier Bicep incluant toutes ses ressources Azure, y compris les bases de données Azure SQL pour chaque locataire. Un fichier de paramètres définit la liste des locataires, et le fichier Bicep utilise une boucle de ressources afin de déployer une base de données pour chacun des locataires répertoriés, comme le montre le schéma suivant.

Si Contoso suit ce modèle, elle doit mettre à jour son fichier de paramètres dans le cadre de l’intégration d’un nouveau locataire. Elle doit alors relancer son pipeline. Elle doit également vérifier manuellement si elle s’approche des limites, par exemple si elle se développe à un rythme élevé inattendu et s’approche du nombre maximal de bases de données prises en charge par un seul serveur Azure SQL logique.

Option 2 - Utiliser une combinaison de pipelines de déploiement et de création impérative de ressources

Par ailleurs, Contoso pourrait envisager de séparer la responsabilité des déploiements Azure.

Contoso utilise un fichier Bicep qui définit les ressources partagées qui doivent être déployées. Les ressources partagées prennent en charge tous leurs locataires et incluent une base de données de plans de locataires, comme le montre le schéma suivant.

L’équipe Contoso génère ensuite un plan de contrôle qui inclut une API d’intégration de tenant. Lorsque l’équipe commerciale a conclu la vente avec un nouveau client, Microsoft Dynamics déclenche l’API pour lancer le processus d’intégration. Contoso propose également une interface web en libre-service que les clients peuvent utiliser et qui déclenche également l’API.

L’API lance de manière asynchrone un flux de travail permettant d’intégrer les nouveaux locataires. Le flux de travail lance le déploiement d’une nouvelle base de données Azure SQL, qui peut être effectué avec l’une des approches suivantes :

• Utilisez le kit de développement logiciel (SDK) Azure pour lancer le déploiement d’un deuxième fichier Bicep définissant la base de données Azure SQL.
• Utilisez le SDK Azure pour créer impérativement une base de données Azure SQL, en utilisant la bibliothèque de gestion.

Après le déploiement de la base de données, le flux de travail ajoute le locataire à la base de données de la liste des locataires, comme le montre le schéma suivant.

Les mises à jour continues du schéma de la base de données sont lancées par la couche Application.

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 :

• Bohdan Cherchyk | Ingénieur client senior, FastTrack for Azure
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

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

Étapes suivantes

• Examinez les considérations relatives à la mise à jour d’une solution multilocataire.
• Envisagez des approches architecturales pour le stockage et les données.
• Examinez comment utiliser Azure Resource Manager dans une solution multilocataire.