Architecture mutualisée et Azure Cosmos DB

Dans cette page, nous décrivons certaines fonctionnalités d’Azure Cosmos DB utiles quand vous travaillez avec des systèmes multitenants. Nous proposons également des liens vers des conseils et des exemples relatifs à l’utilisation d’Azure Cosmos DB dans une solution multilocataire.

Exigences de solution multi-locataires

Lorsque vous planifiez une solution multi-locataires, deux besoins clés peuvent nécessiter une conception spécifique :

• Assurer une forte isolation entre les locataires et répondre à des exigences de sécurité strictes pour ceux qui en ont besoin.
• Maintenir un coût bas par locataire. En tant que fournisseur, vous voulez vous assurer que le coût d’exécution de l’application reste durable à mesure qu’elle évolue.

Ces deux besoins peuvent souvent être en conflit, nécessitant des compromis et la priorisation de l’un par rapport à l’autre. Il existe quelques lignes directrices que vous pouvez suivre pour mieux comprendre les compromis impliqués dans la gestion des deux besoins décrits ci-dessus. Ce document vous aide à naviguer dans ces considérations afin que vous puissiez prendre des décisions éclairées lors de la conception de votre solution multi-locataires.

Modèles d’isolation

Vous devez décider du niveau d’isolation entre vos locataires. Azure Cosmos DB prend en charge une gamme de modèles d’isolation, mais pour la plupart des solutions, nous vous recommandons d’utiliser l’une des stratégies suivantes :

• Clé de partition par locataire, souvent utilisée pour des solutions entièrement multi-locataires comme celles utilisées dans les logiciels en tant que service business-to-consumer (B2C SaaS).
• Compte de base de données par locataire, souvent utilisé dans le SaaS business-to-business (B2B).

Pour sélectionner le modèle d’isolation le plus approprié, tenez compte de votre modèle économique et des exigences des locataires. Par exemple, une isolation de performance forte peut ne pas être prioritaire pour certains modèles B2C où les entreprises vendent directement à un client individuel utilisant le produit ou le service. Cependant, les modèles B2B peuvent prioriser une isolation forte de sécurité et de performance, et pourraient nécessiter que les locataires aient leur propre compte de base de données approvisionné.

Vous pouvez également combiner plusieurs modèles pour répondre à différents besoins clients. Par exemple, supposons que vous construisiez une solution SaaS B2B que vous vendez à des clients d’entreprise, tout en fournissant une version d’essai gratuite pour les nouveaux clients potentiels. Vous pourriez déployer un compte de base de données séparé pour les locataires d’entreprise payants, qui ont besoin de fortes garanties de sécurité et d’isolation, tout en partageant un compte de base de données et en utilisant des clés de partition pour isoler les clients d’essai.

Modèles d’isolation recommandés

Clé de partition par locataire

En isolant nos locataires par clé de partition, le débit sera partagé entre les locataires et regroupé dans le même conteneur.

Avantages :

• Efficacité des coûts : Tous les locataires sont placés dans un conteneur, partitionné par ID de locataire. Comme il n’y a qu’une seule ressource facturable où les RU/s sont approvisionnés et partagés entre plusieurs locataires, cette approche est généralement plus rentable et plus facile à gérer que d’avoir des comptes séparés par locataire.
• Gestion simplifiée : Moins de comptes Azure Cosmos DB à gérer.

Compromis :

• Concurrence des ressources : Le partage du débit (RU/s) entre les locataires dans le même conteneur peut entraîner une concurrence lors des pics d’utilisation, provoquant le problème du voisin bruyant qui peut poser des défis de performance si vos locataires ont des charges de travail élevées ou qui se chevauchent. Ce modèle d’isolation convient aux charges de travail nécessitant une garantie de RU/s sur un seul locataire et pouvant être partagées.
• Isolation limitée : Cette approche fournit une isolation logique, pas physique. Elle pourrait ne pas satisfaire aux exigences strictes d’isolation, qu’il s’agisse de performance ou de sécurité.
• Moins de flexibilité : La personnalisation des fonctionnalités au niveau du compte telles que la géo-réplication, la restauration à un point dans le temps (PITR) et les clés gérées par le client (CMK) par locataire n’est pas disponible en isolant par clé de partition (ou par base de données/conteneur).

Fonctionnalités Azure Cosmos DB pertinentes :

• Contrôlez votre débit : Explorez des fonctionnalités qui peuvent aider à gérer le problème du voisin bruyant lors de la modélisation des locataires par partition, comme ré-allocation de débit, capacité de rafale et contrôle du débit dans le Java SDK.

• Clés de partition hiérarchiques : Azure Cosmos DB permet à chaque partition logique de croître jusqu’à 20 Go. Si vous avez un seul locataire qui doit stocker plus de 20 Go de données, envisagez de répartir les données sur plusieurs partitions logiques. Par exemple, au lieu d’avoir une clé de partition unique de Contoso, vous pouvez saler les clés de partition en créant plusieurs clés de partition pour un locataire, par exemple Contoso1, Contoso2 et ainsi de suite.

  Lorsque vous interrogez les données d’un locataire, vous pouvez utiliser la clause WHERE IN pour faire correspondre toutes les clés de partition. Clés de partition hiérarchiques peuvent également être utilisées pour prendre en charge des locataires de grande taille (à condition que vous ayez une haute cardinalité de locataires), avec un stockage supérieur à 20 Go, sans avoir à utiliser des clés de partition synthétiques ou plusieurs valeurs de clé de partition par locataire.

  Supposons que vous ayez une charge de travail qui isole les locataires par clé de partition. Un locataire, Contoso, est beaucoup plus grand et génère plus d’écritures que les autres, et continue de croître en taille. Pour éviter le risque de ne pas pouvoir ingérer plus de données pour ce locataire, vous pouvez utiliser des clés de partition hiérarchiques. Spécifiez TenantID comme clé de premier niveau, puis ajoutez un deuxième niveau comme UserId. Si vous anticipez que la combinaison TenantID et UserID produise des partitions logiques dépassant la limite de 20 Go, vous pouvez partitionner davantage jusqu’à un autre niveau tel que SessionID. Les requêtes qui spécifient soit TenantID, soit à la fois TenantID et UserID, sont effectivement dirigées vers uniquement le sous-ensemble de partitions physiques contenant les données pertinentes, évitant ainsi une requête de fan-out complète. Si le conteneur avait 1 000 partitions physiques, mais qu’une valeur TenantId spécifique était présente uniquement dans 5 partitions physiques, la requête serait dirigée vers le nombre réduit de partitions physiques pertinentes.

  Si votre premier niveau n’a pas une cardinalité suffisamment élevée et que vous atteignez la limite de 20 Go de partition logique sur votre clé de partition, envisagez d’utiliser une clé de partition synthétique au lieu d’une clé de partition hiérarchique.

Compte de base de données par locataire

En isolant nos locataires par compte de base de données, chaque locataire aura son propre débit provisionné au niveau de la base de données ou du conteneur.

Avantages :

• Haute isolation : Cette approche évite la concurrence ou l’interférence en raison de comptes et de conteneurs Azure Cosmos DB dédiés avec des RU/s provisionnés pour chaque locataire unique.
• SLA personnalisés : Grâce à chaque locataire disposant de son propre compte, vous pouvez fournir des ressources spécifiques, des SLA orientés client et des garanties car le compte de base de données de chaque locataire peut être configuré indépendamment pour le débit.
• Sécurité renforcée : L’isolation physique des données garantit une sécurité robuste car les clients peuvent activer des clés gérées par le client au niveau du compte pour chaque locataire. Les données de chaque locataire sont isolées par compte, plutôt que d’être dans le même conteneur.
• Flexibilité : les locataires peuvent activer des fonctionnalités au niveau du compte, telles que la géoréplication, la restauration à un instant dans le passé (PITR) et les clés gérées par le client (CMK) en fonction des besoins.

Compromis :

• Gestion accrue : Cette approche entraîne une plus grande complexité car vous gérez plusieurs comptes Azure Cosmos DB.
• Coûts plus élevés : Plus de comptes signifient provisionner le débit (RU/s) sur chaque ressource (bases de données et/ou conteneurs) au sein du compte, pour chaque locataire. Chaque fois qu’une ressource provisionne des RU/s, vos coûts Azure Cosmos DB augmentent.
• Limitations de requête : Comme tous les locataires sont dans des comptes différents, plusieurs appels dans la logique de l’application à chaque locataire sont nécessaires lors de la requête pour plusieurs locataires.

Fonctionnalités Azure Cosmos DB pertinentes :

• Fonctionnalités de sécurité : Ce modèle offre une isolation accrue de la sécurité d’accès aux données en utilisant Azure RBAC. De plus, ce modèle offre une isolation de la sécurité de chiffrement des bases de données au niveau du locataire grâce à clés gérées par le client.
• Configuration personnalisée : Vous pouvez configurer l’emplacement du compte de base de données en fonction des exigences du locataire. Vous pouvez également ajuster la configuration des fonctionnalités Azure Cosmos DB, telles que la géoréplication et les clés de chiffrement gérées par le client, pour répondre aux besoins de chaque locataire.

Lors de l’utilisation d’un compte Azure Cosmos DB dédié par locataire, prenez en compte le nombre maximal de comptes Azure Cosmos DB par abonnement Azure.

Liste complète des modèles d’isolation

Conteneur par locataire

Vous pouvez provisionner des conteneurs dédiés pour chaque locataire. Les conteneurs dédiés fonctionnent bien quand les données que vous stockez pour votre locataire peuvent être regroupées dans un seul conteneur. Ce modèle offre une meilleure isolation des performances que le modèle de clé de partition par locataire ci-dessus. Il fournit également une meilleure isolation de la sécurité d’accès aux données grâce à Azure RBAC.

Lorsque vous utilisez un conteneur pour chaque locataire, vous pouvez envisager de partager le débit avec d’autres locataires en provisionnant le débit au niveau de la base de données. Prenez en compte les restrictions et les limites concernant le nombre minimal d’unités de requête pour votre base de données et le nombre maximal de conteneurs dans la base de données. Déterminez également si vos locataires requièrent un niveau de performance garanti et s’ils sont susceptibles d’être confrontés au problème de voisin bruyant. Quand vous partagez le débit au niveau de la base de données, la charge de travail ou le stockage sur tous les conteneurs doit être relativement uniforme. Sinon, vous risquez d’avoir un problème de voisin bruyant si vous avez un ou plusieurs grands locataires. Si nécessaire, envisagez de regrouper ces locataires dans différentes bases de données basées sur des modèles de charge de travail.

Vous pouvez également provisionner un débit dédié pour chaque conteneur. Cette approche fonctionne bien pour les locataires plus grands et ceux qui risquent d’être confrontés au problème de voisin bruyant. Toutefois, comme le débit de base de chaque locataire est plus élevé, tenez compte des exigences minimales et des implications financières de ce modèle.

Si votre modèle de données de locataire nécessite plusieurs entités, celles-ci peuvent être colocalisées dans le même conteneur à condition qu’elles puissent partager la même clé de partition. Toutefois, si le modèle de données de locataire est plus complexe et nécessite des entités ne pouvant pas partager la même clé de partition, envisagez les modèles de base de données par locataire ou de compte de base de données par locataire ci-dessous. Pour plus d’informations, consultez notre article sur la modélisation et le partitionnement des données sur Azure Cosmos DB à l’aide d’un exemple concret.

La gestion du cycle de vie est généralement plus simple lorsque les conteneurs sont dédiés aux locataires. Vous pouvez facilement déplacer des locataires entre les modèles de débit partagés et dédiés, et lors de l’annulation du provisionnement d’un locataire, vous pouvez rapidement supprimer le conteneur.

Base de données par client

Vous pouvez provisionner des bases de données pour chaque locataire dans le même compte de base de données. Au même titre que le modèle de conteneur par locataire ci-dessus, ce modèle offre une meilleure isolation des performances que le modèle de clé de partition par locataire. Il fournit également une meilleure isolation de la sécurité d’accès aux données grâce à Azure RBAC.

Similaire au modèle de compte-par-locataire, cette approche offre le niveau le plus élevé d’isolation des performances, mais fournit la plus faible densité de locataires. Toutefois, cette option est idéale quand chaque locataire a besoin d’un modèle de données plus complexe que le modèle de conteneur par locataire. Vous pouvez également suivre cette approche quand vous devez créer des locataires rapidement et/ou des comptes de locataire à l’avance sans frais. Il est aussi possible, selon le framework de développement logiciel utilisé, que la base de données par locataire soit le seul niveau d’isolation des performances reconnu dans ce framework. L’isolation au niveau de l’entité (conteneur) et la colocalisation d’entités ne sont généralement pas prises en charge en mode natif dans de tels frameworks.

Fonctionnalités d’Azure Cosmos DB qui prennent en charge l’architecture multilocataires

Partitionnement

En utilisant des partitions avec vos conteneurs Azure Cosmos DB, vous pouvez créer des conteneurs qui sont partagés entre plusieurs locataires. En général, vous utilisez l’identificateur de locataire comme clé de partition. Vous pouvez également envisager d’utiliser plusieurs clés de partition pour un seul locataire. Une stratégie de partitionnement bien planifiée implémente efficacement le modèle de partitionnement. Avec les grands conteneurs, Azure Cosmos DB répartit vos locataires sur plusieurs nœuds physiques pour atteindre un niveau élevé d’échelle.

Nous vous recommandons d’explorer l’utilisation de clés de partition hiérarchiques pour améliorer les performances de votre solution multitenant. Les clés de partitions hiérarchiques vous permettent de créer une clé de partition qui comprend plusieurs valeurs. Par exemple, vous pouvez utiliser une clé de partition hiérarchique qui inclut l’identifiant du locataire, comme un GUID à haute cardinalité, pour permettre une échelle presque illimitée. Ou, vous pouvez spécifier une clé de partition hiérarchique qui inclut une propriété souvent utilisée dans les requêtes. Cette approche vous aide à éviter les requêtes inter-partitions. En utilisant des clés de partition hiérarchiques, vous pouvez évoluer au-delà de la limite de partition logique de 20 Go par valeur de clé de partition, et vous limitez les requêtes de fan-out coûteuses.

Plus d’informations :

• Partitionnement et mise à l’échelle horizontale dans Azure Cosmos DB
• Clés de partition hiérarchiques

Gestion des unités de requête

Le modèle de tarification d’Azure Cosmos DB est basé sur le nombre d’unités de requête par seconde que vous provisionnez ou consommez. Une unité de requête est une abstraction logique du coût d’une requête ou d’une opération de base de données. En règle générale, vous provisionnez un nombre défini d’unités de requête par seconde pour votre charge de travail. Cela constitue le débit. Azure Cosmos DB offre plusieurs options de provisionnement du débit. Dans un environnement multilocataires, la sélection que vous effectuez affecte les performances et le prix de vos ressources Azure Cosmos DB.

Pour les locataires nécessitant une isolation garantie de performance et de sécurité, nous recommandons d’isoler les locataires par compte de base de données et d’allouer des unités de requête au locataire. Pour les locataires avec des exigences moins strictes, nous recommandons d’isoler les locataires par clé de partition, ce qui permet de partager des unités de requête entre vos locataires et vous aide à optimiser un coût bas par locataire.

Un modèle de multi-location alternatif pour Azure Cosmos DB consiste à déployer des conteneurs séparés pour chaque locataire dans une base de données partagée. Azure Cosmos DB vous permet de provisionner des unités de requête pour une base de données, et tous les conteneurs partagent les unités de requête. Si les charges de travail de vos locataires ne se chevauchent généralement pas, cette approche peut vous aider à réduire vos coûts d’exploitation. Toutefois, cette approche est vulnérable au problème de voisin bruyant dans la mesure où le conteneur d’un locataire donné peut consommer une quantité disproportionnée des unités de requête provisionnées partagées. Pour atténuer ce problème, commencez par identifier les locataires bruyants. Ensuite, définissez éventuellement un débit provisionné sur un conteneur spécifique. Les autres conteneurs de la base de données continuent de partager leur débit alors que le locataire bruyant utilise son propre débit dédié.

Azure Cosmos DB fournit également un niveau serverless, qui est adapté aux charges de travail avec un trafic intermittent ou imprévisible. Sinon, la mise à l’échelle automatique vous permet de configurer des stratégies pour spécifier la mise à l’échelle du débit provisionné. En outre, vous pouvez tirer parti de la capacité de rafale d’Azure Cosmos DB, ce qui optimise l’utilisation de votre capacité de débit approvisionnée, qui aurait eu un débit limité dans le cas contraire. Dans une solution multilocataires, vous pouvez combiner toutes ces approches pour prendre en charge différents types de locataires.

Pour surveiller et gérer les coûts associés à chaque locataire, chaque opération utilisant l’API Azure Cosmos DB inclut les unités de requête consommées. Vous pouvez utiliser ces informations pour agréger et comparer les unités de requête réelles consommées par chaque locataire. Vous pouvez ensuite identifier les locataires avec des caractéristiques de performances différentes.

Plus d’informations :

• Débit approvisionné
• Autoscale
• Sans serveur
• Mesure de la facturation d’unité de requête d’une demande
• Quotas du service Azure Cosmos DB
• Capacité de rafale

Clés gérées par le client

Certains locataires peuvent nécessiter l’utilisation de leurs propres clés de chiffrement. Azure Cosmos DB fournit une fonctionnalité de clé gérée par le client. Cette fonctionnalité étant appliquée au niveau d’un compte Azure Cosmos DB, les locataires qui nécessitent leurs propres clés de chiffrement doivent être déployés à l’aide de comptes Azure Cosmos DB dédiés.

Plus d’informations :

• Configurer des clés gérées par le client pour votre compte Azure Cosmos DB avec Azure Key Vault

Contributeurs

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

Principaux auteurs :

• Tara Bhatia | Responsable de programme, Azure Cosmos DB
• Paul Burpo | Ingénieur client principal, FastTrack for Azure
• John Downs | Ingénieur logiciel principal

Autres contributeurs :

• Mark Brown | Principal PM Manager, Azure Cosmos DB
• Deborah Chen | Responsable de programme principale
• Theo van Kraay | Responsable de programme senior, Azure Cosmos DB
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
• Thomas Weiss | Responsable du programme principal
• Vic Perdana | Architecte de solutions cloud, Azure ISV

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.

Découvrez-en plus sur la multilocation et Azure Cosmos DB :

• Concevez et construisez des applications SaaS multi-locataires à grande échelle avec Azure Cosmos DB : une session lors de Build 2024 qui vous guide dans la conception pour la multi-location sur Azure Cosmos DB et vous fait découvrir les bonnes pratiques d’un éditeur de logiciels indépendant du monde réel.
• Azure Cosmos DB and multitenant systems : billet de blog expliquant comment créer un système multilocataires qui utilise Azure Cosmos DB.
• Applications multilocataires avec Azure Cosmos DB (vidéo)
• Création d’une application SaaS multilocataire avec Azure Cosmos DB et Azure (vidéo) : Étude de cas réaliste portant sur la manière dont Whally, une start-up SaaS multilocataire, a créé une plateforme moderne à partir de zéro sur Azure Cosmos DB et Azure. Whally aborde les décisions de conception et d’implémentation qu’il a pris concernant le partitionnement, la modélisation des données, la sécurisation de la multilocation, les performances, le streaming en temps réel du flux de modification vers SignalR, etc. Toutes ces solutions utilisent ASP.NET Core sur Azure App Services.

Ressources associées

Reportez-vous à certains de nos autres scénarios architecturaux Cosmos DB :

• Applications serverless avec Azure Cosmos DB
• Azure Cosmos DB dans des charges de travail IoT
• Modèle de boîte d’envoi transactionnelle avec Azure Cosmos DB
• Recherche visuelle dans le commerce de détail avec Azure Cosmos DB
• Le gaming avec Azure Cosmos DB