Multilocataire et Azure App Configuration
Azure App Configuration vous permet de stocker les paramètres de configuration de votre application. En utilisant Azure App Configuration, vous pouvez facilement implémenter le modèle Magasin de configuration externe. Dans cet article, nous décrivons certaines des fonctionnalités d’Azure App Configuration qui sont utiles lors de l’utilisation de systèmes multilocataires, et nous donnons des liens vers des conseils et des exemples d’utilisation d’Azure App Configuration dans une solution multilocataire.
Modèles d’isolation
Un magasin fait référence à une instance unique du service Azure App Configuration.
Dans une solution multilocataire, il est courant d’avoir deux types de paramètres :
Les paramètres partagés sont ceux qui s’appliquent à plusieurs locataires, tels que des paramètres globaux ou des paramètres qui s’appliquent à tous les locataires au sein d’un modèle de déploiement. Les paramètres globaux sont souvent stockés au mieux dans un magasin App Configuration partagé. En suivant cette approche, vous réduisez le nombre d’endroits que vous devez mettre à jour quand la valeur d’un paramètre change. Cette approche réduit également le risque que les paramètres soient hors synchronisation.
Paramètres spécifiques au locataire, tels que le nom de la base de données de chaque locataire ou des identifiants internes. Vous pouvez aussi spécifier différents niveaux de journalisation pour chaque locataire, par exemple quand vous diagnostiquez un problème signalé par un locataire spécifique et que vous devez collecter les journaux de diagnostic auprès de ce seul locataire. Vous pouvez choisir de combiner les paramètres spécifiques aux locataires pour plusieurs locataires dans un même magasin ou de déployer un magasin pour chaque locataire. Cette décision doit être basée sur vos spécifications. Si votre solution utilise un seul niveau d’application partagé pour plusieurs locataires, il est probable qu’il n’y ait qu’un avantage minimal à utiliser des magasins spécifiques aux locataires. Cependant, si vous déployez des instances d’application spécifiques aux locataires, vous pouvez choisir de mettre en œuvre la même approche en déployant des magasins de configuration spécifiques aux locataires.
Le tableau suivant récapitule les différences entre les principaux modèles d’isolation de location pour Azure App Configuration :
| Considération | Magasin partagé | Magasin par locataire |
|---|---|---|
| Isolation des données | Faible. Utiliser des préfixes de clé ou des étiquettes pour identifier les données de chaque locataire | Élevé |
| Isolation des performances | Faible | Élevé |
| Complexité du déploiement | Faible | Moyenne-élevée |
| Complexité opérationnelle | Faible | Moyenne-élevée |
| Coût des ressources | Faible | Moyenne-élevée |
| Exemple de scénario | Solution multilocataire volumineuse avec une couche Application partagée | Locataires de niveau Premium avec déploiements entièrement isolés |
Magasins partagés
Vous pouvez déployer un magasin Azure App Configuration partagé pour l’ensemble de votre solution, ou un pour chaque modèle. Vous pouvez ensuite utiliser le même magasin pour tous les paramètres de vos locataires, et vous pouvez utiliser des préfixes de clé ou des étiquettes pour les distinguer.
Si vous devez stocker une grande quantité de données par locataire ou si vous devez effectuer une mise à l’échelle vers un grand nombre de locataires, vous risquez de dépasser les limites de ressources pour un même magasin. Dans ce scénario, déterminez si vous pouvez partitionner vos locataires sur un ensemble de magasins partagés, afin de réduire les coûts de déploiement et de gestion.
Si vous suivez cette approche, veillez à bien comprendre les quotas et les limites de ressources qui s’appliquent. En particulier, pensez bien à la limite de stockage totale du niveau de service que vous utilisez et veillez à ne pas dépasser le nombre maximal de demandes par heure.
Magasins par locataire
Vous pouvez choisir au lieu de cela de déployer un magasin Azure App Configuration pour chaque locataire. Le niveau standard d’Azure App Configuration vous permet de déployer un nombre illimité de magasins dans votre abonnement. Cependant, cette approche est souvent plus complexe à gérer, car vous devez déployer et configurer plus de ressources. Il y a aussi des frais pour chaque ressource de magasin que vous déployez.
Envisagez d’utiliser des magasins spécifiques aux locataires si vous avez une des situations suivantes :
- Vous devez utiliser des clés de chiffrement gérées par le client, où les clés sont distinctes pour chaque locataire.
- Vos locataires ont besoin que leurs données de configuration soient complètement isolées des données des autres locataires. L’autorisation d’accès pour Azure App Configuration est contrôlée au niveau du magasin : en déployant des magasins distincts, vous pouvez donc configurer des autorisations d’accès distinctes.
Fonctionnalités d’Azure App Configuration prenant en charge le multilocataire
Quand vous utilisez Azure App Configuration dans une application multilocataire, vous pouvez utiliser plusieurs fonctionnalités pour stocker et récupérer des paramètres spécifiques à un locataire.
Préfixes de clés
Dans Azure App Configuration, vous utilisez des paires clé-valeur qui représentent les paramètres d’application. La clé représente le nom du paramètre de configuration. Vous pouvez utiliser une structure de nommage hiérarchique pour vos clés. Dans une solution multilocataire, envisagez d’utiliser un identificateur de locataire comme préfixe pour vos clés.
Par exemple, supposons que vous devez stocker un paramètre pour indiquer le niveau de journalisation de votre application. Dans une solution monolocataire, vous pouvez nommer ce paramètre LogLevel. Dans une solution multilocataire, vous pouvez choisir d’utiliser un nom de clé hiérarchique, comme tenant1/LogLevel pour le locataire 1, tenant2/LogLevel pour le locataire 2, etc.
Azure App Configuration vous permet de spécifier des noms de clés longs pour prendre en charge plusieurs niveaux dans une hiérarchie. Si vous choisissez d’utiliser des noms de clés longs, veillez à bien comprendre les limites de taille des clés et des valeurs.
Quand vous chargez la configuration d’un seul locataire dans votre application, vous pouvez spécifier un filtre de préfixe de clé pour charger seulement les clés de ce locataire. Vous pouvez aussi configurer la bibliothèque de fournisseurs pour Azure App Configuration de façon à éliminer le préfixe de clé des clés avant de les rendre disponibles pour votre application. Quand vous éliminez le préfixe de clé, votre application voit un nom de clé cohérent, avec les valeurs de ce locataire chargées dans l’application.
Étiquettes
Azure App Configuration prend également en charge les étiquettes, qui vous permettent d’avoir des valeurs distinctes avec la même clé.
Les étiquettes sont souvent utilisées pour le versioning, pour l’utilisation de plusieurs environnements de déploiement ou à d’autres fins dans votre solution. Bien que vous puissiez utiliser des identifiants de locataires comme étiquettes, vous ne pourrez alors pas utiliser les étiquettes pour autre chose. Ainsi, pour les solutions multilocataires, il est généralement conseillé d’utiliser des préfixes de clés pour gérer les paramètres spécifiques aux locataires et d’utiliser les étiquettes à d’autres fins.
Si vous décidez d’utiliser des étiquettes pour chaque locataire, votre application peut charger seulement les paramètres d’un locataire spécifique en utilisant un filtre d’étiquettes. Cette approche peut être utile si vous avez des déploiements d’applications distincts pour chaque locataire.
Mise en cache côté application
Quand vous utilisez Azure App Configuration, il est important de mettre en cache les paramètres au sein de votre application au lieu de les charger chaque fois que vous les utilisez. Les bibliothèques de fournisseur Azure App Configuration mettent en cache les paramètres et les actualisent automatiquement.
Vous devez aussi décider si votre application charge les paramètres pour un seul locataire ou pour tous les locataires.
À mesure que votre base de locataires s’accroît, la quantité de temps et la mémoire nécessaires pour charger les paramètres de tous les locataires ensemble sont susceptibles d’augmenter. Ainsi, dans la plupart des cas, c’est une bonne pratique que de charger les paramètres pour chaque locataire séparément, quand votre application en a besoin.
Si vous chargez séparément les paramètres de configuration de chaque locataire, votre application doit mettre en cache chaque ensemble de paramètres séparément de tous les autres. Dans les applications .NET, envisagez d’utiliser un cache en mémoire pour mettre en cache l’objet IConfiguration du locataire, puis utilisez l’identificateur du locataire comme clé de cache. En utilisant un cache en mémoire, vous n’avez pas besoin de recharger une configuration à chaque demande, mais le cache peut supprimer des instances inutilisées si votre application a besoin de plus de mémoire. Vous pouvez aussi configurer des délais d’expiration pour les paramètres de configuration de chaque locataire.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- John Downs | Ingénieur logiciel principal
Autres contributeurs :
- Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
- Jenlan Wang | Responsable principal de l’ingénierie logicielle, Azure App Configuration
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
Examinez les approches du déploiement et de la configuration pour une architecture mutualisée.