Architecture mutualisée et Azure Cosmos DB

Cet article décrit les fonctionnalités d’Azure Cosmos DB que vous pouvez utiliser pour les systèmes multilocataire. Il fournit des conseils et des exemples sur l’utilisation d’Azure Cosmos DB dans une solution mutualisée.

Exigences de l’architecture mutualisée

Lorsque vous planifiez une solution mutualisée, vous avez deux exigences clés :

• Assurez-vous une forte isolation entre les locataires et répondez à des exigences de sécurité strictes pour ceux qui en ont besoin.
• Maintenez un coût faible par locataire. En tant que fournisseur, assurez-vous que le coût d’exécution de l’application reste durable à mesure qu’elle est mise à l’échelle.

Ces deux besoins peuvent souvent entrer en conflit et introduire un compromis où vous devez hiérarchiser l’un par rapport à l’autre. Les conseils de cet article peuvent vous aider à mieux comprendre les compromis que vous devez faire pour répondre à ces besoins. Cet article vous aide à parcourir ces considérations afin de prendre des décisions éclairées lorsque vous concevez votre solution mutualisée.

Modèles d’isolation

Déterminez le niveau d’isolation dont vous avez besoin 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 :

• Une clé de partition par locataire est souvent utilisée pour les solutions multilocataires, comme les solutions saaS B2C (Business-to-Consumer Software as a Service).
• Un compte de base de données par locataire est souvent utilisé pour les solutions SaaS business-to-business (B2B).

Pour choisir le modèle d’isolation le plus approprié, tenez compte des besoins de votre modèle métier et des locataires. Par exemple, une isolation forte des performances peut ne pas être une priorité pour certains modèles B2C où une entreprise vend un produit ou un service directement à un client individuel. Toutefois, les modèles B2B peuvent hiérarchiser une sécurité forte et une isolation des performances et nécessiter que les locataires disposent de leur propre compte de base de données provisionné.

Vous pouvez également combiner plusieurs modèles pour répondre à différents besoins des clients. Par exemple, supposons que vous créez une solution SaaS B2B que vous vendez aux clients d’entreprise et que vous fournissez un essai gratuit pour les nouveaux clients potentiels. Vous pouvez déployer un compte de base de données distinct pour les locataires d’entreprise payants qui ont besoin de garanties de sécurité et d’isolation fortes. Vous pouvez également partager un compte de base de données et utiliser des clés de partition pour isoler les clients d’évaluation.

Modèles d’isolation recommandés

Le modèle partition-clé par locataire et le modèle de base de données-compte par locataire sont les modèles d’isolation les plus courants pour les solutions mutualisées. Ces modèles fournissent le meilleur équilibre entre l’isolation des locataires et l’efficacité des coûts.

Clé de partition par modèle de locataire

Si vous isolez vos locataires par clé de partition, le débit est partagé entre les locataires et géré dans le même conteneur.

Avantages

• Rentabilité : vous placez tous les locataires dans un seul conteneur, partitionné en fonction de l'ID du locataire. Cette approche n’a qu’une seule ressource facturable qui provisionne et partage des unités de ressources (RUs) entre plusieurs locataires. Ce modèle est généralement plus rentable et plus facile à gérer que d’avoir des comptes distincts pour chaque locataire.

• Gestion simplifiée : vous avez moins de comptes Azure Cosmos DB à gérer.

Compromis

• Contention des ressources : le débit partagé (RU/s) entre les locataires qui se trouvent dans le même conteneur peut entraîner une contention pendant les pics d’utilisation. Cette contention peut créer des problèmes de voisin bruyants et des problèmes de performances si vos locataires ont des charges de travail élevées ou qui se chevauchent. Utilisez ce modèle d’isolation pour des charges de travail qui ont besoin d’unités de requête garanties sur un seul locataire et qui peuvent partager le débit.

• Isolation limitée : Cette approche fournit une isolation logique, pas physique. Il peut ne pas répondre à des exigences d’isolation strictes du point de vue des performances ou de la sécurité.

• Moins de flexibilité : vous ne pouvez pas personnaliser les fonctionnalités au niveau du compte, telles que la géoréplication, la restauration dans le temps et les clés gérées par le client, pour chaque locataire si vous isolez par clé de partition ou par base de données ou conteneur.

Fonctionnalités Azure Cosmos DB pour la multilocation

• Contrôler votre débit : explorez les fonctionnalités qui peuvent aider à contrôler le problème de voisin bruyant lorsque vous utilisez une clé de partition pour isoler les locataires. Utilisez des fonctionnalités telles que la réaffectation du débit, la capacité de rafale et le contrôle de débit dans le Kit de développement logiciel (SDK) Java.

• Clés de partition hiérarchiques : utilisez Azure Cosmos DB pour que chaque partition logique puisse augmenter de taille 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 seule clé de partition, Contosovous pouvez distribuer les clés de partition en créant plusieurs clés de partition pour un locataire, telles que Contoso1 et Contoso2.

  Lorsque vous interrogez des données pour un locataire, vous pouvez utiliser la WHERE IN clause pour faire correspondre toutes les clés de partition. Vous pouvez également utiliser des clés de partition hiérarchiques pour fournir à des locataires importants un stockage supérieur à 20 Go à condition que vous ayez une cardinalité élevée des locataires. Vous n’avez pas besoin d’utiliser des clés de partition synthétiques ou plusieurs valeurs de clé de partition par locataire pour cette méthode.

  Supposons que vous ayez une charge de travail qui isole les locataires par clé de partition. L’un des locataires, Contoso, est plus grand et plus gourmand en écriture que les autres, et sa taille ne cesse de croître. 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 prévoyez que la combinaison de TenantID et UserID produise des partitions logiques dépassant la limite de 20 Go, vous pouvez subdiviser à un autre niveau, par exemple SessionID. Les requêtes qui spécifient l’une ou l’autre TenantID ou les deux TenantID et UserID sont routées efficacement vers le sous-ensemble de partitions physiques contenant les données pertinentes, ce qui évite une requête de fan-out complète. Si le conteneur a 1 000 partitions physiques, mais qu’une valeur spécifique TenantId se trouve uniquement sur cinq partitions physiques, la requête est acheminée vers le plus petit nombre de partitions physiques pertinentes.

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

Modèle de compte de base de données par locataire

Si vous isolez vos locataires par compte de base de données, chaque locataire dispose de son propre débit approvisionné au niveau de la base de données ou du conteneur.

Avantages

• Isolation élevée : cette approche permet d’éviter les conflits ou les interférences grâce aux comptes et aux conteneurs Azure Cosmos DB dédiés qui disposent d’unités de requête approvisionnées par locataire unique.

• Contrats de niveau de service personnalisés (SLA) : chaque locataire possède son propre compte, ce qui vous permet de fournir des ressources personnalisées spécifiques, des contrats SLA orientés client et des garanties, car vous pouvez paramétrer le compte de base de données de chaque locataire indépendamment pour le débit.

• Sécurité renforcée : l’isolation des données physiques permet de garantir une sécurité robuste, car les clients peuvent activer les clés gérées par le client au niveau du compte par 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 les fonctionnalités au niveau du compte, telles que la géoréplication, la restauration à un point dans le temps et les clés gérées par le client en fonction des besoins.

Compromis

• Gestion accrue : cette approche est plus complexe, car vous gérez plusieurs comptes Azure Cosmos DB.

• Coûts plus élevés : un plus grand nombre de comptes signifie que vous devez approvisionner un débit sur chaque ressource, telle que les bases de données ou les conteneurs, au sein du compte pour chaque locataire. Chaque fois qu'une ressource provisionne des RUs, vos coûts liés à Azure Cosmos DB augmentent.

• Limitations de requête : tous les locataires se trouvent dans différents comptes, de sorte que les applications qui interrogent plusieurs locataires nécessitent plusieurs appels dans la logique de l’application.

Fonctionnalités Azure Cosmos DB pour la multilocation

• Fonctionnalités de sécurité : Ce modèle fournit une isolation accrue de la sécurité de l’accès aux données via le contrôle d’accès en fonction du rôle (RBAC) Azure. Ce modèle fournit également une isolation de sécurité de chiffrement de base de données au niveau du locataire par le biais de 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.

Lorsque vous utilisez un compte Azure Cosmos DB dédié par locataire, tenez compte du nombre maximal de comptes Azure Cosmos DB par abonnement Azure.

Liste complète des modèles d’isolation

Modèle conteneur par locataire

Vous pouvez provisionner des conteneurs dédiés pour chaque locataire. Les conteneurs dédiés fonctionnent bien lorsque vous pouvez combiner les données que vous stockez pour votre locataire dans un seul conteneur. Ce modèle permet une meilleure isolation des performances que le modèle partition-clé-par-locataire. 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, envisagez de partager le débit avec d’autres locataires en approvisionnant le débit au niveau de la base de données. Tenez compte des restrictions et des limites concernant le nombre minimum d'unités de gestion pour votre base de données et le nombre maximum de conteneurs dans la base de données. Déterminez également si vos locataires nécessitent un niveau de performance garanti et s’ils sont sensibles 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 pouvez avoir un problème de voisin bruyant si vous avez un ou plusieurs locataires volumineux. 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 volumineux et pour les locataires qui sont à risque du problème de voisin bruyant. Toutefois, le débit de référence pour chaque locataire est plus élevé. Tenez donc compte des exigences minimales et des implications sur les coûts de ce modèle.

Si votre modèle de données de locataire nécessite plusieurs entités et si toutes les entités peuvent partager la même clé de partition, vous pouvez les colocaliser dans le même conteneur. Toutefois, si le modèle de données client est plus complexe et nécessite des entités qui ne peuvent 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. Pour plus d’informations, consultez Modèles et données de partition sur Azure Cosmos DB.

La gestion du cycle de vie est généralement plus simple lorsque vous dédiez des conteneurs à des locataires. Vous pouvez facilement déplacer des locataires entre des modèles de débit partagés et dédiés. Et quand vous déprovisionnez un locataire, vous pouvez rapidement supprimer le conteneur.

Modèle de base de données par locataire

Vous pouvez provisionner des bases de données pour chaque locataire dans le même compte de base de données. Comme le modèle conteneur par locataire, ce modèle offre une isolation des performances supérieure au 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.

Comme pour le modèle de compte par locataire, cette approche fournit le niveau d’isolation des performances le plus élevé, mais elle fournit la densité de locataire la plus faible. Utilisez cette option si chaque locataire nécessite un modèle de données plus complexe que possible dans le modèle conteneur par locataire. Ou suivez cette approche si la création d’un nouveau locataire doit être rapide ou sans aucune surcharge initiale. Pour certains frameworks de développement logiciel, le modèle de base de données par locataire peut être le seul niveau d’isolation des performances pris en charge par l’infrastructure. Ces frameworks ne prennent généralement pas en charge l’isolation des entités (conteneurs) et la colocalisation des entités.

Fonctionnalités Azure Cosmos DB qui prennent en charge l’architecture mutualisée

Partitionnement

Utilisez des partitions avec vos conteneurs Azure Cosmos DB pour créer des conteneurs partagés par 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. Lorsque vous avez des conteneurs volumineux, Azure Cosmos DB répartit vos locataires sur plusieurs nœuds physiques pour obtenir un degré élevé de mise à l’échelle.

Envisagez les clés de partition hiérarchiques pour améliorer les performances de votre solution multilocataire. Utilisez des clés de partition hiérarchiques pour créer une clé de partition qui inclut 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. Vous pouvez également spécifier une clé de partition hiérarchique qui contient une propriété souvent utilisée par les requêtes. Cette approche vous aide à éviter les requêtes entre partitions. Utilisez des clés de partition hiérarchiques pour effectuer une mise à l’échelle au-delà de la limite de partition logique de 20 Go par valeur de clé de partition et limiter les requêtes de dispersion coûteuses.

Pour plus d’informations, consultez les ressources suivantes :

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

Gérer les unités de requête

Le modèle de tarification Azure Cosmos DB est basé sur le nombre de RU/s que vous approvisionnez ou consommez. Azure Cosmos DB fournit plusieurs options pour approvisionner le débit. Dans un environnement multilocataire, votre sélection affecte les performances et le prix de vos ressources Azure Cosmos DB.

Pour les locataires qui ont besoin d’un niveau de performance garanti et d’une isolation de sécurité, nous vous 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 qui ont des exigences moins strictes, nous vous recommandons d’isoler les locataires par clé de partition. Utilisez ce modèle pour partager des UR entre vos clients et optimiser le coût par client.

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. Utilisez Azure Cosmos DB pour approvisionner des RUs (unités de requête) pour une base de données, permettant ainsi à tous les conteneurs de partager ces RUs. 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 sujette au problème du voisin bruyant, car le conteneur d’un seul locataire peut consommer une quantité disproportionnée des RUs partagées. Pour atténuer ce problème, identifiez d’abord 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 convient aux charges de travail qui ont un trafic intermittent ou imprévisible. Vous pouvez également utiliser la mise à l’échelle automatique pour configurer des stratégies qui spécifient la mise à l’échelle du débit provisionné. Vous pouvez également tirer parti de la capacité de rafale Azure Cosmos DB pour optimiser l’utilisation de votre capacité de débit provisionnée, qui est autrement limitée par les limites de débit. Dans une solution mutualisée, 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, rappelez-vous que chaque opération qui utilise 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 RUs réels consommés par chaque locataire. Vous pouvez ensuite identifier les locataires qui ont des caractéristiques de performances différentes.

Pour plus d’informations, consultez les ressources suivantes :

• Capacité de traitement provisionnée
• Mise à l'échelle automatique
• Sans serveur
• Mesurer la charge RU 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. Vous appliquez cette fonctionnalité au niveau d’un compte Azure Cosmos DB. Par conséquent, si les locataires nécessitent leurs propres clés de chiffrement, vous devez utiliser des comptes Azure Cosmos DB dédiés pour déployer les locataires.

Pour plus d’informations, consultez 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, modèles Azure & Pratiques

Autres contributeurs :

• Marquer 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

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

• Concevoir et créer des applications SaaS multilocataires à grande échelle avec Azure Cosmos DB : une session de Build 2024 qui vous guide tout au long de la conception pour la multilocation sur Azure Cosmos DB et apprendre les meilleures pratiques d’un fournisseur de logiciels indépendant.
• Azure Cosmos DB and multitenant systems : billet de blog expliquant comment créer un système multilocataires qui utilise Azure Cosmos DB.
• Vidéo : Applications mutualisées avec Azure Cosmos DB
• Vidéo : Créer un SaaS multilocataire avec Azure Cosmos DB et Azure : une étude de cas réelle sur la façon dont Whally, un démarrage SaaS multilocataire, crée une plateforme moderne à partir de zéro sur Azure Cosmos DB et Azure. Whally montre les décisions de conception et d’implémentation qu’ils prennent en ce qui concerne le partitionnement, la modélisation des données, le multilocataire sécurisé, les performances et la diffusion en temps réel des flux de modification vers SignalR. Toutes ces solutions utilisent ASP.NET Core sur Azure App Service.

Ressources associées

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

• Approches de stockage et de données pour l’architecture mutualisée
• Modèle de boîte d’envoi transactionnelle avec Azure Cosmos DB