Multilocataire et Azure App Configuration

Azure App Configuration vous aide à stocker les paramètres de configuration de votre application. En utilisant App Configuration, vous pouvez implémenter plus facilement le modèle du Magasin de configuration externe. Cet article décrit certaines des fonctionnalités d’App Configuration qui sont utiles lorsque vous travaillez avec des systèmes multilocataire. Les liens fournis vous guident vers des conseils et des exemples sur l’utilisation d’App Configuration dans une solution multilocataire.

Modèles d’isolation

Un magasin fait référence à une instance unique du service App Configuration.

Dans une solution multilocataire, il est courant d’avoir deux types de paramètres :

• Paramètres partagés : Appliqués à plusieurs clients, tels que les paramètres globaux ou les paramètres qui s’appliquent à tous les clients au sein d’une estampille de déploiement. Il est souvent préférable de stocker des paramètres globaux 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 sortent de la synchronisation.

• Paramètres spécifiques au locataire : spécifiez le nom de la base de données ou les identificateurs internes de chaque locataire. Vous pouvez utiliser ces paramètres pour spécifier différents niveaux de journal pour chaque locataire. Par exemple, vous pouvez diagnostiquer un problème signalé par un locataire spécifique et vous devez collecter uniquement les journaux de diagnostic de ce locataire. Vous pouvez choisir de combiner les paramètres spécifiques au locataire pour plusieurs locataires dans un magasin unique ou de déployer un magasin pour chaque locataire. Basez votre décision sur vos besoins. 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ésume les différences entre les principaux modèles d’isolation de location pour App Configuration.

Considération	Magasin partagé	Magasin par locataire
Isolation des données	Faible. Utilisez 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	Moyennement élevé
Complexité opérationnelle	Faible	Moyennement élevé
Coût des ressources	Faible	Moyennement élevé
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 App Configuration partagé pour toute votre solution, ou un pour chaque tampon. Vous pouvez ensuite utiliser le même magasin pour tous les paramètres de vos locataires. Utilisez des préfixes de clé ou des étiquettes pour les distinguer.

Si vous devez stocker une grande quantité de données par locataire ou effectuer une mise à l’échelle vers un grand nombre de locataires, vous risquez peut-être de dépasser les limites de ressources pour un seul magasin. Dans ce scénario, déterminez si vous pouvez partager 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, n’oubliez pas la limite de stockage totale pour le niveau de service que vous utilisez et veillez à ne pas dépasser les demandes maximales par heure.

Magasin par locataire

Vous pouvez plutôt choisir de déployer un magasin App Configuration pour chaque locataire. Le niveau App Configuration Standard vous permet de déployer un nombre illimité de magasins dans votre abonnement. Toutefois, cette approche est souvent plus complexe à gérer, car vous devez ensuite déployer et configurer davantage de ressources.

Envisagez d’utiliser des magasins spécifiques aux locataires si vous avez une des situations suivantes :

• Vous devez utiliser des clés gérées par le client (CMK), où les clés sont distinctes pour chaque locataire.
• Vos locataires nécessitent que leurs données de configuration soient isolées des données d’autres locataires. L’autorisation d’accès pour App Configuration est contrôlée au niveau du magasin. Par conséquent, en déployant des magasins distincts, vous pouvez configurer des autorisations d’accès distinctes.

Fonctionnalités d’App Configuration qui prennent en charge l’architecture mutualisée

Lorsque vous utilisez App Configuration dans une application mutualisée, il existe plusieurs fonctionnalités que vous pouvez utiliser pour stocker et récupérer des paramètres spécifiques au locataire.

Préfixes de clés

Dans App Configuration, vous travaillez avec 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 mutualisée, vous pouvez choisir d’utiliser un nom de clé hiérarchique, par tenant1/LogLevel exemple pour le locataire 1 et tenant2/LogLevel pour le locataire 2.

Vous pouvez spécifier des noms de clés longs et plusieurs niveaux dans une hiérarchie. Si vous choisissez d’utiliser des noms de clés longs, vérifiez que vous comprenez 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 également configurer la bibliothèque de fournisseurs pour App Configuration afin de découper 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

App Configuration prend également en charge les étiquettes. Avec les étiquettes, vous pouvez définir des valeurs distinctes qui utilisent la même clé.

Les étiquettes aident à gérer le contrôle de version, à utiliser plusieurs environnements de déploiement ou à d’autres fins dans votre solution. Même si vous pouvez utiliser des identificateurs de locataire comme étiquettes, vous ne pouvez pas utiliser d’étiquettes pour tout autre élément. Par conséquent, pour les solutions multilocataires, il est généralement recommandé d’utiliser des préfixes de clé pour la gestion des paramètres spécifiques au locataire et d’utiliser des étiquettes à d’autres fins.

Si vous décidez d’utiliser des étiquettes pour chaque locataire, votre application peut charger uniquement les paramètres d’un locataire spécifique à l’aide d’un filtre d’étiquette. Cette approche est utile si vous avez des déploiements d’applications distincts pour chaque locataire.

Mise en cache côté application

Lorsque vous travaillez avec 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 fournisseurs de App Configuration mettent en cache les paramètres et les actualisent automatiquement.

Vous devez également décider si votre application charge les paramètres d’un seul locataire ou de 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 des autres. Dans les applications .NET, vous pouvez utiliser un cache en mémoire pour mettre en cache l’objet du IConfiguration locataire, puis utiliser l’identificateur du locataire comme clé de cache. En utilisant un cache en mémoire, vous n’avez pas besoin de recharger une configuration pour chaque requête, mais le cache peut supprimer les instances inutilisées si votre application est sous pression mémoire. Vous pouvez aussi configurer des délais d’expiration pour les paramètres de configuration de chaque locataire.

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 :

• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
• Jenlan Wang | Principal Software Engineering Manager, App Configuration

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

Étape suivante

• Approches de déploiement et de configuration pour l’architecture mutualisée.