Partager via

Architecture mutualisée et Azure Cosmos DB

  • Article

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 solution multi-locataires

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.

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.

Modèle de clé de partition par 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.

Remarque

Une unité de requête (RU) est une abstraction logique du coût d’une opération ou d’une requête de base de données. En règle générale, vous approvisionnez un nombre défini d’unités de requête par seconde (RU/s) pour votre charge de travail, appelée débit.

Avantages

  • Rentabilité : vous placez tous les locataires dans un conteneur, qui est partitionné par l’ID de locataire. Cette approche n’a qu’une seule ressource facturable qui provisionne et partage des unités de requête 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 les charges de travail qui ont besoin d’unités de requête garanties sur un seul locataire et 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 l’architecture mutualisée

  • 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 volumineux avec un stockage supérieur à 20 Go si vous avez 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. Un locataire, Contoso, est plus grand et plus lourd en écriture que d’autres, et il 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 prévoyez que la TenantID combinaison produit UserID des partitions logiques qui dépassent la limite de 20 Go, vous pouvez effectuer une partition plus bas vers un autre niveau, par SessionIDexemple . 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 évite la contention ou l’interférence en raison de comptes et de conteneurs Azure Cosmos DB dédiés qui ont approvisionné des unités de requête 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 : d’autres comptes signifient que vous devez provisionner le débit sur chaque ressource, comme les bases de données ou les conteneurs, dans le compte de chaque locataire. Chaque fois qu’une ressource provisionne des unités de requête, vos coûts 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 l’architecture mutualisée

  • Fonctionnalités de sécurité : ce modèle fournit une isolation accrue de la sécurité de l’accès aux données via Azure RBAC. 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

Besoin de charge de travail Clé de partition par locataire (recommandé) Conteneur par locataire (débit partagé) Conteneur par locataire (débit dédié) Base de données par client Compte de base de données par locataire (recommandé)
Requêtes entre locataires Facile (le conteneur sert de limite pour les requêtes) Difficile Difficile Difficile Difficile
Densité de locataire Élevée (coût le plus faible par locataire) Moyenne Faible Faible Faible
Suppression des données de locataire Facile Facile (supprimer le conteneur au départ du locataire) Facile (supprimer le conteneur au départ du locataire) Facile (supprimer la base de données au départ du locataire) Facile (supprimer la base de données au départ du locataire)
Isolation de la sécurité d’accès aux données Besoin d’implémenter dans l’application RBAC (conteneur) RBAC (conteneur) RBAC (base de données) RBAC
Géoréplication Impossible d’effectuer la géoréplication par locataire Regrouper les locataires au sein des comptes de base de données en fonction des exigences Regrouper les locataires au sein des comptes de base de données en fonction des exigences Regrouper les locataires au sein des comptes de base de données en fonction des exigences Regrouper les locataires au sein des comptes de base de données en fonction des exigences
Prévention des voisins bruyants Non Non Oui Oui Oui
Latence de création de locataire Immédiat Rapide Rapide Medium Lente
Avantages de la modélisation des données Aucune Colocation d’entité Colocation d’entité Plusieurs conteneurs pour modéliser des entités de locataire Plusieurs conteneurs et bases de données pour modéliser des locataires
Clé de chiffrement Identique pour tous les locataires Identique pour tous les locataires Identique pour tous les locataires Identique pour tous les locataires Clé gérée par le client par locataire
Débit requis >0 unité de requête par locataire >100 unités de requête par locataire >100 RU par locataire (avec mise à l’échelle automatique uniquement, sinon >400 RU par locataire) >400 unités de requête par locataire >400 unités de requête par locataire
Exemple de cas d’usage Applications B2C Offre standard pour les applications B2B Offre Premium pour les applications B2B Offre Premium pour les applications B2B Offre Premium pour les applications B2B

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 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.

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 limites du nombre minimal d’unités de requête pour votre base de données et du nombre maximal 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 libre de toute surcharge avant. 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 au niveau de l’entité (conteneur) et la colocalisation d’entité.

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

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 inclut une propriété qui interroge fréquemment l’utilisation. 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 ventilateur coûteuses.

Pour plus d’informations, consultez les ressources suivantes :

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 nécessitent une isolation garantie des performances et de la 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 unités de requête entre vos locataires et optimiser le coût 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. Utilisez Azure Cosmos DB pour approvisionner des unités de requête pour une base de données afin que 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 susceptible d’être due au problème de voisin bruyant, car le conteneur d’un seul locataire peut consommer une quantité disproportionnée des unités de requête approvisionnées 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.

Remarque

Lorsque vous planifiez votre configuration Azure Cosmos DB, tenez compte des quotas et limites de service.

Pour surveiller et gérer les coûts associés à chaque locataire, n’oubliez pas 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 unités de requête réelles consommées 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 :

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

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

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

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