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

Quelle que soit 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, envisagez de déployer vos ressources Azure, en particulier lorsque vous déployez des ressources dédiées pour chaque locataire ou reconfigurez dynamiquement les ressources en fonction du nombre de locataires dans votre système. Cet article fournit aux architectes de solutions des conseils sur le déploiement de solutions mutualisées. Il montre des approches à prendre en compte lorsque vous planifiez votre stratégie de déploiement.

Considérations et exigences clés

Définissez clairement vos exigences avant de planifier votre stratégie de déploiement. Tenez compte des facteurs suivants :

• Mise à l’échelle attendue : Déterminez si vous prévoyez de gérer seulement quelques locataires, tels que cinq ou moins, ou évoluer vers un grand nombre de locataires. À mesure que le nombre de locataires augmente, l’automatisation devient de plus en plus importante.

• Intégration automatisée ou prise en charge : Spécifiez si les locataires doivent effectuer l’intégration par le biais d’une procédure automatisée ou lancer une demande nécessitant une intégration manuelle. Définissez toutes les étapes d’approbation manuelle de votre équipe, telles que pour empêcher l’utilisation incorrecte de votre service.

• Temps d’approvisionnement : Établissez la rapidité avec laquelle le processus d’intégration doit être effectué. Si vous n’avez pas de réponse claire, définissez si cette étape doit être mesurée en secondes, minutes, heures ou jours.

• Microsoft Marketplace : Vérifiez si vous envisagez d’utiliser la Place de marché Microsoft pour lancer le déploiement de votre solution de Azure. Si vous le faites, répondez aux exigences nécessaires pour ajouter de nouveaux locataires.

Prenez également en compte les étapes d’intégration et d’approvisionnement, l’automatisation et la responsabilité de gestion des ressources.

Étapes d’intégration et d’approvisionnement

Définissez et documentez chaque tâche requise pour intégrer un locataire, même si le processus est manuel. Le flux de travail d’intégration inclut généralement les étapes suivantes :

1. Accepter des contrats commerciaux.
2. Effectuez des étapes d’approbation manuelles, par exemple pour éviter toute fraude ou mauvaise utilisation de votre service.
3. Provisionnez des ressources dans Azure.
4. Créez ou configurez des noms de domaine.
5. Effectuez des tâches de configuration post-déploiement, telles que la création du premier compte d’utilisateur pour le locataire et la transmission sécurisée de ses informations d’identification au locataire.
6. Appliquez des modifications de configuration manuelles, telles que les modifications d’enregistrement DNS (Domain Name System).

Documentez clairement le flux de travail requis pour intégrer un nouveau locataire.

Considérez les ressources Azure spécifiques que vous devez provisionner pour un locataire. Même si vous ne provisionnez pas de ressources dédiées pour chaque locataire, déterminez si vous devez parfois déployer des ressources lorsqu’un nouveau locataire est intégré. Ce scénario peut se produire lorsqu’un locataire nécessite un stockage de données dans une région spécifique. Il peut également se produire lorsque vous utilisez une approche d’emballage de bac. Dans le "bin packing", lorsque vous approchez des limites d’un seuil ou d’un composant dans votre solution, vous créez une autre instance pour le groupe suivant d’utilisateurs.

Déterminez si le processus d’intégration peut perturber d’autres locataires, en particulier les locataires qui partagent la même infrastructure. Par exemple, si vous devez modifier des bases de données partagées, déterminez si ce processus peut entraîner un impact sur les performances que d’autres locataires peuvent remarquer. Déterminez si vous pouvez éviter ces effets ou les atténuer en effectuant le processus d’intégration en dehors des heures de fonctionnement normales.

Automatisation

Vous devez utiliser des déploiements automatisés pour les solutions hébergées dans le cloud. Dans les solutions mutualisées, l’automatisation devient encore plus importante pour les raisons suivantes :

• Échelle: À mesure que le nombre de vos locataires augmente, les processus de déploiement manuels deviennent de plus en plus complexes et fastidieux. Une approche de déploiement automatisé est plus facile à mettre à l’échelle à mesure que le nombre de locataires augmente.

• Répétable: Dans un environnement mutualisé, utilisez un processus cohérent pour les déploiements sur tous les locataires. Les processus manuels introduisent la probabilité d’erreurs ou d’étapes incohérentes entre les locataires. Votre environnement peut ensuite être laissé dans un état incohérent, ce qui rend plus difficile pour votre équipe de gérer la solution.

• Impact des pannes : Les déploiements manuels sont plus risqués et sujets aux pannes que les déploiements automatisés. Dans un environnement multilocataire, une erreur de déploiement peut entraîner une panne à l’échelle du système qui affecte chaque locataire, ce qui augmente l’impact global.

Lorsque vous effectuez un déploiement dans un environnement multilocataire, procédez comme suit :

• Utilisez des pipelines de déploiement pour déployer des ressources courantes.

• Utilisez des technologies d’infrastructure en tant que code (IaC), telles que Bicep, des modèles de Azure Resource Manager JSON (modèles ARM) ou Terraform.

• Utilisez le code pour appeler Azure SDKs le cas échéant.

Si vous envisagez d’offrir votre solution de Azure via le Microsoft Marketplace, vous devez fournir un processus d’intégration automatiquement automatisé pour les nouveaux locataires.

Capacité maximale des ressources

Lorsque vous déployez par programmation des ressources de locataire sur des ressources partagées, tenez compte de la limite de capacité pour chaque ressource. Lorsque vous approchez de cette limite, vous devrez peut-être créer une autre instance de la ressource pour prendre en charge une mise à l’échelle supplémentaire. Tenez compte des limites de chaque ressource que vous déployez et des conditions qui vous déclenchent pour déployer une autre instance.

Par exemple, supposons que votre solution inclut un serveur logique Azure SQL et approvisionne une base de données dédiée sur ce serveur pour chaque locataire. Un seul serveur logique a des limites, qui incluent un nombre maximal de bases de données qu’il prend en charge. Lorsque vous approchez de ces limites, vous devrez peut-être provisionner de nouveaux serveurs afin de pouvoir continuer à intégrer des locataires. Déterminez s’il faut automatiser ce processus ou surveiller manuellement la croissance.

Responsabilité de gestion des ressources

Dans certaines solutions mutualisées, déployez des ressources à l’aide de l’un de plusieurs modèles. Déployez des ressources Azure dédiées pour chaque locataire, comme une base de données pour chaque locataire. Vous pouvez également définir un nombre défini de locataires à héberger sur une seule instance d’une ressource, de sorte que le nombre de locataires que vous avez détermine l’ensemble des ressources que vous déployez sur Azure. Dans d’autres solutions, déployez un seul ensemble de ressources partagées et reconfigurez-les lorsque vous intégrez de nouveaux locataires.

Chacun de ces modèles vous oblige à déployer et à gérer des ressources de différentes manières, et vous devez prendre en compte comment déployer et gérer le cycle de vie des ressources que vous approvisionnez. Considérez deux approches courantes :

• Traitez les locataires comme configuration des ressources déployées et utilisez vos pipelines de déploiement pour déployer et configurer ces ressources.

• Considérez les locataires comme des données et utilisez un plan de contrôle pour provisionner et configurer l’infrastructure pour vos locataires.

Les sections suivantes décrivent plus en détail ces approches.

Essai

Testez soigneusement votre solution pendant et après chaque déploiement. Vous pouvez utiliser des tests automatisés pour vérifier le comportement fonctionnel et non fonctionnel de votre solution. Assurez-vous de tester votre modèle d’isolation de locataires. Envisagez d’utiliser des outils tels que Azure Chaos Studio pour introduire délibérément des erreurs qui simulent des pannes réelles et vérifient que votre solution fonctionne même lorsqu’un composant devient indisponible ou qu’il ne fonctionne pas correctement.

Approches et modèles à prendre en compte

Plusieurs modèles de conception du Centre d’architecture Azure et de la communauté plus large prennent en charge le déploiement et la configuration de solutions mutualisées.

Modèle d’empreintes de déploiement

Utilisez le modèle Tampons de déploiement pour déployer une infrastructure dédiée pour un locataire ou un groupe de locataires. Un tampon unique peut contenir plusieurs locataires, ou il peut être dédié à un seul locataire. Vous pouvez déployer un tampon unique ou coordonner un déploiement sur plusieurs tampons. Si vous déployez des tampons dédiés pour chaque locataire, envisagez de déployer des tampons entiers par programmation.

Anneaux de déploiement

Utilisez des anneaux de déploiement pour déployer des mises à jour sur différents groupes d’infrastructure à différents moments. Cette approche complète souvent le modèle Tampons de déploiement. Affectez des groupes d’empreintes à des anneaux distincts en fonction des préférences du locataire, des types de charge de travail et d’autres considérations. Pour plus d’informations, consultez Anneaux de déploiement.

Indicateurs de fonctionnalités

Utilisez des indicateurs de fonctionnalité pour exposer progressivement de nouvelles fonctionnalités ou versions de votre solution à différents locataires ou utilisateurs sans redéployer du code. Envisagez d’utiliser Azure App Configuration pour gérer vos indicateurs de fonctionnalité. Pour plus d’informations, consultez indicateurs de fonctionnalité.

Parfois, vous devez activer sélectivement des fonctionnalités spécifiques pour des clients spécifiques. Par exemple, vous pouvez avoir différents niveaux tarifaires qui autorisent l’accès à certaines fonctionnalités. Les indicateurs de fonctionnalité ne sont généralement pas le bon choix pour ces scénarios. Au lieu de cela, envisagez de créer un processus pour suivre et appliquer les droits de licence dont dispose chaque client.

Antimodèles à éviter

Lorsque vous déployez et configurez des solutions mutualisées, évitez les situations qui empêchent votre capacité à effectuer une mise à l’échelle. Les exemples suivants mettent en évidence les antimodèles courants :

• Déploiement et test manuels : Les processus de déploiement manuel ajoutent des risques et ralentissent votre capacité à déployer. Envisagez d’utiliser des pipelines pour les déploiements automatisés, créer par programmation des ressources à partir du code de votre solution ou combiner les deux.

• Personnalisations spécialisées pour les locataires : Évitez de déployer des fonctionnalités ou une configuration qui s’applique uniquement à un seul locataire. Cette approche ajoute de la complexité à vos déploiements et processus de test. Utilisez plutôt les mêmes types de ressources et codebase pour chaque locataire. Utilisez des stratégies telles que des indicateurs de fonctionnalité pour les modifications temporaires ou pour les fonctionnalités déployées progressivement. Vous pouvez également utiliser différents niveaux tarifaires avec des droits de licence pour activer de manière sélective les fonctionnalités des locataires qui en ont besoin. Utilisez un processus de déploiement cohérent et automatisé, même pour les locataires qui ont des ressources isolées ou dédiées.

Listes de locataires en tant que configuration ou données

Tenez compte des approches suivantes lorsque vous déployez des ressources dans une solution mutualisée :

• Utilisez un pipeline de déploiement automatisé pour déployer chaque ressource. À mesure que de nouveaux locataires sont ajoutés, reconfigurez votre pipeline pour approvisionner les ressources de 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. Créez des ressources spécifiques au locataire au sein de votre application.

Lorsque vous envisagez les deux approches, faites la distinction entre le traitement de votre liste de locataires comme une configuration ou comme des données. Cette distinction influence également la façon dont vous créez un plan de contrôle pour votre système.

Liste de locataires utilisée comme configuration

Lorsque vous traitez votre liste de locataires comme configuration, vous déployez toutes vos ressources à partir d’un pipeline de déploiement centralisé. Lorsque de nouveaux locataires sont intégrés, vous reconfigurez le pipeline ou ses paramètres. En règle générale, la reconfiguration se produit par le biais de modifications manuelles, comme illustré dans le diagramme suivant.

Le processus d’intégration d’un nouveau locataire inclut généralement les étapes suivantes :

1. Mettez à jour la liste des locataires manuellement en configurant le pipeline 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 votre ensemble complet de ressources Azure, y compris les nouvelles ressources spécifiques au locataire.

Cette approche fonctionne bien pour un petit nombre de locataires et d’architectures où toutes les ressources sont partagées. Un processus unique déploie et configure toutes vos ressources Azure, ce qui simplifie l’approche globale.

Toutefois, à mesure que le nombre de locataires augmente, souvent environ 10 ou plus, il devient fastidieux de reconfigurer le pipeline lorsque vous ajoutez des locataires. Le temps nécessaire à l’exécution du pipeline de déploiement augmente souvent également. Cette approche ne prend pas facilement en charge la création de locataires en libre-service et le délai avant l'intégration d'un locataire peut être plus long, car vous devez déclencher votre pipeline.

Liste de locataires sous forme de données

Lorsque vous traitez votre liste de locataires en tant que données, vous déployez toujours vos composants partagés à l’aide d’un pipeline. Toutefois, pour les ressources et les paramètres de configuration qui doivent être déployés pour chaque locataire, vous déployez ou configurez impérativement vos ressources. Par exemple, votre plan de contrôle peut utiliser Azure SDKs pour créer une ressource spécifique ou lancer le déploiement d’un modèle paramétrable.

Le processus d’intégration inclut généralement les étapes asynchrones suivantes :

1. Demande d’intégration d’un locataire, par exemple l’initialisation d’une demande d’API sur 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 lance le déploiement de ressources spécifiques au locataire pour Azure. Vous pouvez utiliser un modèle de programmation impératif, tel que Azure SDKs, ou déclencher impérativement le déploiement d’un fichier Bicep ou d’un modèle Terraform.

4. Une fois le déploiement terminé, le flux de travail enregistre les détails du nouveau locataire dans le catalogue de locataires central. Les données stockées pour chaque locataire peuvent inclure l’ID de locataire et les ID de ressource pour toutes les ressources spécifiques au locataire créées par le flux de travail.

Cette approche permet l’approvisionnement de ressources pour les nouveaux locataires sans redéployer l’ensemble de votre solution. Le temps d’approvisionnement est généralement plus court, car seules les ressources spécifiques au locataire sont déployées.

Toutefois, cette approche exige souvent beaucoup plus de temps à mettre en œuvre. Votre effort doit être justifié par le nombre de locataires ou les délais d’approvisionnement que vous devez respecter.

Pour plus d’informations, consultez Considérations relatives aux plans de contrôle multilocataire.

Exemple :

Contoso exécute une solution mutualisée pour ses clients. Ils ont six locataires et s’attendent à atteindre 300 locataires au cours des 18 prochains mois. Contoso suit l'approche de l'application mutualisée avec des bases de données dédiées pour chaque locataire. Ils déploient un ensemble unique de ressources Azure App Service et un serveur logique Azure SQL que tous les locataires partagent. Ils déploient également une base de données Azure SQL dédiée pour chaque locataire, comme illustré dans le diagramme suivant. Contoso utilise Bicep pour déployer ses ressources de Azure.

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

Contoso peut déployer toutes ses ressources à l’aide d’un pipeline de déploiement. Leur pipeline déploie un fichier Bicep qui inclut toutes leurs 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. Le fichier Bicep utilise une boucle resource pour déployer une base de données pour chacun des locataires répertoriés, comme illustré dans le diagramme suivant.

Si Contoso suit ce modèle, il doit effectuer les étapes suivantes :

1. Mettez à jour leur fichier de paramètres dans le cadre de l’intégration d’un nouveau locataire.

2. Réexécutez leur pipeline.

3. Suivez manuellement les limites des ressources, par exemple si elles augmentent à un taux inattendu élevé et approchent le nombre maximal de bases de données prises en charge sur un seul serveur logique Azure SQL.

Option 2 : Utiliser une combinaison de pipelines de déploiement et de création de ressources impératives

Contoso peut également séparer la responsabilité des déploiements Azure.

Contoso utilise un fichier Bicep qui définit les ressources partagées à déployer. Les ressources partagées prennent en charge tous les locataires et incluent une base de données de catalogue de locataires, également appelée base de données de liste de locataires, comme illustré dans le diagramme suivant.

L'équipe Contoso développe un plan de gestion qui inclut une API d’intégration de locataire. Lorsque leur équipe commerciale termine la vente à un nouveau client, Microsoft Dynamics déclenche l’API pour commencer le processus d’intégration. Contoso fournit également une interface web libre-service que les clients utilisent pour déclencher la même API.

L’API démarre de façon asynchrone un flux de travail qui intègre ses nouveaux locataires. Le flux de travail lance le déploiement d’une nouvelle base de données Azure SQL, qui peut utiliser l’une des approches suivantes :

• Utilisez le Azure SDK pour lancer le déploiement d’un deuxième fichier Bicep qui définit la base de données Azure SQL.

• Utilisez la Azure SDK pour créer impérativement une base de données Azure SQL à l’aide de la bibliothèque management.

Une fois la base de données déployée, le flux de travail ajoute le locataire à la base de données de liste de locataires, comme illustré dans le diagramme suivant. La couche Application lance les mises à jour de schéma de base de données en cours.

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 :

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

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

Ressources associées

• Considérations relatives à la mise à jour d’une solution mutualisée.
• Approches architecturales pour le stockage et les données.
• Utilisez Azure Resource Manager dans une solution multilocataire.