Partager via

Multilocataire et Azure Cache pour Redis

  • Article

Azure Cache pour Redis est couramment utilisé pour augmenter les performances de votre solution, pour réduire la charge sur votre base de données ou d’autres composants de la couche Données, et pour réduire la quantité d’états stockés sur les nœuds de calcul. Dans cet article, nous décrivons quelques-unes des fonctionnalités d’Azure Cache pour Redis qui sont utiles pour les solutions multilocataires, puis nous fournissons des liens vers des conseils qui peuvent vous aider quand vous planifiez la façon dont vous allez utiliser Azure Cache pour Redis.

Modèles d’isolation

Quand vous travaillez avec un système multilocataires qui utilise Azure Cache pour Redis, vous devez décider du niveau d’isolation que vous voulez utiliser. Azure Cache pour Redis prend en charge plusieurs modèles d’isolation.

Le tableau suivant récapitule les différences entre les principaux modèles d’isolation de location pour Azure Cache pour Redis :

Considération Cache partagé, base de données partagée Cache et base de données partagés, liste de contrôle d'accès Cache partagé, base de données par locataire Cache par locataire
Isolation des données Faible. Utiliser des structures de données Redis ou des préfixes clés pour identifier les données de chaque locataire Élevé. Les données sont isolées en fonction des préfixes des clés Faible. Les données sont séparées, mais aucune isolation de sécurité n’est fournie Élevé
Isolation des performances Faible. Tous les locataires partagent les mêmes ressources de calcul Faible. Tous les locataires partagent les mêmes ressources de calcul Faible. Tous les locataires partagent les mêmes ressources de calcul Élevé
Complexité du déploiement Faible Faible-Moyenne. Moyenne Moyenne-élevée
Complexité opérationnelle Faible Faible-Moyenne. Faible Moyenne-élevée
Coût des ressources Faible Faible Faible Élevé
Exemple de scénario Solution multilocataire volumineuse avec une couche Application partagée Solution multilocataire importante avec des identités d'application distinctes qui accèdent au cache Migration d’une application monolocataire pour être multilocataire Instances d’applications individuelles par locataire

Instance de cache partagé et base de données partagée

Vous pouvez envisager de déployer un seul cache, avec une seule base de données Redis, et de l’utiliser pour stocker des données mises en cache pour tous vos locataires. Cette approche est couramment utilisée lorsque vous avez une instance d'application unique que tous vos locataires partagent.

Lorsque vous suivez cette approche, votre application est seule responsable de la séparation des données des locataires. Vous pouvez utiliser des préfixes de clé pour distinguer les données des différents locataires, mais votre application doit veiller à n'accéder qu'aux données du locataire avec lequel elle travaille. Vous pouvez aussi envisager d’utiliser des structures de données Redis, comme des jeux ou des hachages, pour les données de chaque locataire. Chacune de ces approches prend en charge un grand nombre de clés, de sorte qu'elles peuvent s'adapter à de nombreux locataires. Cependant, vous devez gérer les autorisations dans votre application et non dans le cache.

Lorsque vous partagez une instance de cache et une base de données entre locataires, tenez compte du fait que tous vos locataires partagent les mêmes ressources informatiques sous-jacentes pour le cache. Cette approche peut donc être vulnérable au problème du voisin bruyant. Veillez à suivre les meilleures pratiques pour Azure Cache for Redis afin d'utiliser au mieux les ressources de votre cache et d'atténuer tout effet de voisinage bruyant. Voici les meilleures pratiques :

En outre, envisagez de superviser les ressources de votre cache, comme le processeur et la mémoire. Si vous observez la pression sur les ressources, envisagez les atténuations suivantes :

  • Effectuez un scale-up vers une référence SKU ou un niveau de cache avec des ressources plus importantes.
  • Effectuez un scale-out vers plusieurs caches en partitionnant vos données mises en cache. Une option consiste à répartir les données par locataire, certains locataires utilisant le cache A et d'autres le cache B. Vous pouvez également répartir les données par sous-système, une partie de votre solution mettant en cache les données de tous les locataires dans le cache A et une autre partie de votre solution les mettant en cache dans le cache B.

Cache et base de données partagés avec listes de contrôle d'accès

Si votre niveau d'application utilise des identités distinctes pour accéder au cache de chaque locataire, utilisez les listes de contrôle d'accès Redis. Les listes de contrôle d'accès vous permettent de limiter l'accès aux informations des locataires à des identités spécifiques. Vous identifiez les données auxquelles l'identité est autorisée à accéder sur la base de noms de clés ou de préfixes. Cette approche peut s'avérer judicieuse lorsque vous avez des instances d'application distinctes pour chaque locataire, ou si vous avez une application partagée qui utilise plusieurs identités pour accéder à des services en aval en fonction du contexte du locataire.

Comme pour le modèle d'isolation précédent, le partage du cache et de la base de données implique que vous preniez des précautions pour éviter le problème des voisins bruyants.

Instance de cache partagé avec une base de données par locataire

Une autre approche que vous pouvez envisager consiste à déployer une seule instance de cache et à déployer des bases de données Redis spécifiques au locataire au sein de l’instance. Cette approche fournit un certain degré d’isolation logique des données de chaque locataire, mais elle ne fournit pas d’isolation des performances ou de protection contre les voisins bruyants.

Cette approche peut être utile pour les scénarios de migration. Par exemple, supposons que vous modernisez une application monolocataire qui n’est pas conçue pour fonctionner avec plusieurs locataires et que vous la convertissez progressivement en prenant en charge le multilocataire en incluant le contexte du locataire dans toutes les requêtes. Vous pouvez réaliser des économies en utilisant un seul cache partagé, et vous n'avez pas besoin de mettre à jour la logique de l'application pour utiliser des préfixes de clé de locataire ou des structures de données spécifiques au locataire.

Azure Cache pour Redis impose des limites au nombre de bases de données qui peuvent être créées sur un même cache. Avant de mettre en œuvre cette approche, réfléchissez au nombre de locataires que vous prévoyez d'atteindre.

En outre, cette approche ne fournit aucun avantage pour l’isolation de la sécurité des données. Dans Azure Cache pour Redis, l’authentification et l’autorisation sont effectuées au niveau de l’instance du cache.

Notes

Azure Cache pour Redis prend en charge plusieurs bases de données sur des niveaux spécifiques, et il ne prend pas en charge plusieurs bases de données quand vous utilisez des instances en cluster.

Instance de cache par locataire

Vous pouvez envisager de déployer une instance distincte d’Azure Cache pour Redis pour chaque locataire. Il n’existe pas de limite du nombre de caches que vous pouvez déployer dans un même abonnement Azure. Cette approche fournit le niveau de données et d’isolation des performances le plus fort.

Cependant, chaque cache est facturé comme ressource Azure distincte, de sorte que si vous passez à un grand nombre de locataires, vos coûts vont augmentez. En outre, cette approche ne permet pas souvent d’utiliser efficacement les ressources de chaque cache, car chaque instance d’Azure Cache pour Redis prend généralement en charge de grands volumes de requêtes. Il est préférable d’envisager cette approche de l’isolation seulement si vous avez des exigences strictes en matière d’isolation des données ou des performances.

Fonctionnalités d’Azure Cache pour Redis prenant en charge le multilocataire

Listes de contrôle d’accès

Azure Cache for Redis fournit un puissant système de contrôle d'accès basé sur les rôles, qui vous permet de créer des stratégies complètes d'accès aux données pour appliquer vos règles d'authentification et d'autorisation. Ces règles peuvent être spécifiées à différents niveaux de granularité, y compris pour permettre à un utilisateur d'accéder aux clés de cache qui suivent un modèle spécifique. En utilisant des modèles de clés, vous pouvez partager une seule instance de cache et une seule base de données entre plusieurs locataires, chacun avec ses propres comptes d'utilisateur. Azure Cache for Redis applique l'isolation des locataires pour garantir qu'un utilisateur ne peut accéder qu'à son propre ensemble de clés qui suivent le modèle.

Par exemple, supposons que vous ayez un locataire nommé Fabrikam. Votre niveau d'application ne doit pouvoir accéder qu'aux données de cache relatives à Fabrikam, et non à celles d'autres locataires. Vous pouvez définir une stratégie d'accès personnalisée qui autorise la lecture et la définition de toutes les clés de cache commençant par Fabrikam :

+@read +set ~Fabrikam*

Vous pouvez alors affecter la stratégie à l'identité Microsoft Entra que votre instance d'application Fabrikam utilise. Après avoir configuré votre cache, l'utilisateur Fabrikam peut accéder aux clés nommées FabrikamData1 et FabrikamUserDetails, mais pas à ContosoData1.

La géoréplication active

De nombreuses solutions multilocataires doivent être géodistribuées. Vous pouvez partager un niveau d’application distribué mondialement avec vos instances d’application lisant et écrivant dans un cache proche pour conserver des performances acceptables. Le niveau Entreprise d’Azure Cache pour Redis prend en charge la liaison de plusieurs caches entre des régions dans une configuration active-active.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Principaux auteurs :

Autres contributeurs :

  • Carl Dacosta | Gestionnaire principal de l’ingénierie logicielle, Azure Cache pour Redis
  • Kyle Teegarden | Responsable de programme principal, Azure Cache pour Redis
  • Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

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

Étapes suivantes

Passez en revue les approches de stockage et de données pour l’architecture multilocataire.