Share via

Architecture mutualisée et Azure Cosmos DB

  • Article

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.

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’identificateur de tenant et le type de données que vous stockez. Cette approche vous permet d’effectuer une mise à l’échelle au-delà de la limite de partition logique de 20 Go par valeur de clé de partition.

Plus d’informations :

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.

Un modèle de location pour Azure Cosmos DB implique le déploiement de conteneurs distincts pour chaque locataire au sein d’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.

Notes

Lorsque vous planifiez votre configuration Azure Cosmos DB, veillez à prendre en compte les quotas et limites de service.

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 :

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 :

Modèles d’isolation

Lorsque vous travaillez avec un système multilocataires qui utilise Azure Cosmos DB, vous devez prendre une décision concernant le niveau d’isolation que vous souhaitez utiliser. B2B (Business-to-Business) fait référence à la vente à une entreprise. B2C (Business-to-Consumer) fait référence à la vente directe à un client individuel qui utilise le produit ou le service. Azure Cosmos DB prend en charge plusieurs modèles d’isolation :

Besoin de charge de travail Clé de partition par locataire 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
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 Difficile 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 Doit être implémentée 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 Aucune Aucune Oui Oui Oui
Latence de création de locataire Immédiat Rapide Rapide Medium Lente
Avantages de la modélisation des données Aucune Colocalisation d’entités Colocalisation d’entités 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(s) 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

Clé de partition par locataire

Lorsque vous utilisez un seul conteneur pour plusieurs locataires, vous pouvez utiliser la prise en charge du partitionnement d’Azure Cosmos DB. En utilisant des clés de partition distinctes pour chaque locataire, vous pouvez facilement interroger les données d’un seul locataire. Vous pouvez également interroger plusieurs locataires, même s’ils se trouvent dans des partitions distinctes. Toutefois, les requêtes dans plusieurs partitions ont un coût d’unité de requête supérieur à celui des requêtes à partition unique.

Cette approche a tendance à fonctionner correctement lorsque la quantité de données stockées pour chaque locataire est faible. Il peut s’agir d’un bon choix pour la création d’un modèle de tarification qui inclut un niveau gratuit et pour les solutions B2C (Business-to-Consumer). En général, en utilisant des conteneurs partagés, vous obtenez la densité la plus élevée des locataires et, par conséquent, le prix le plus bas par locataire.

Il est important de prendre en compte le débit de votre conteneur. Tous les locataires partagent le débit du conteneur, de sorte que le problème du voisin bruyant peut entraîner des problèmes de performances si vos locataires ont des charges de travail élevées ou qui se chevauchent. Ce problème peut parfois être atténué en regroupant des sous-ensembles de locataires dans des conteneurs différents et en s’assurant que chaque groupe de locataires a des modèles d’utilisation compatibles. Vous pouvez également envisager un modèle multilocataire et monolocataire hybride. Regroupez les petits locataires dans des conteneurs partitionnés partagés et donnez aux clients importants des conteneurs dédiés. De plus, certaines fonctionnalités comme la réallocation du débit, la capacité de rafale et le contrôle du débit dans le SDK Java peuvent vous aider à contrôler le problème de voisin bruyant lors de la modélisation d’un locataire par partition.

Il est également important de prendre en compte la quantité de données que vous stockez dans chaque partition logique. 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. Vous pouvez également faire appel à des clés de partition hiérarchiques pour prendre en charge les grands locataires (avec un stockage supérieur à 20 Go), sans avoir à utiliser de clés de partition synthétiques ou plusieurs valeurs de clé de partition par locataire.

Prenez en compte les aspects opérationnels de votre solution, ainsi que les différentes phases du cycle de vie du locataire. Par exemple, quand un locataire passe à un niveau tarifaire dédié, vous devrez probablement déplacer les données vers un autre conteneur. Lorsqu’un locataire est mis hors service, vous devez exécuter une requête de suppression sur le conteneur pour supprimer les données, et pour les locataires de grande taille, cette requête peut consommer une quantité significative de débit pendant son exécution.

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.

Comme le modèle de compte par locataire ci-dessous, cette approche offre le niveau d’isolation des performances le plus élevé, mais aussi la densité de locataire la plus faible. 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.

Compte de base de données par locataire

Azure Cosmos DB vous permet de configurer des comptes de base de données distincts pour chaque locataire, ce qui fournit le niveau d’isolation le plus élevé, mais la densité la plus faible. Au même titre que les modèles de conteneur par locataire et de base de données 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. Par ailleurs, ce modèle fournit une isolation de la sécurité de chiffrement de base de données au niveau du locataire grâce à des clés gérées par le client.

Un compte de base de données unique est dédié à un locataire, ce qui signifie qu’il n’est pas soumis au problème de voisin bruyant. 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.

Si vous utilisez ce modèle, vous devez prendre en compte la vitesse à laquelle votre application doit pouvoir générer de nouveaux locataires. La création de compte dans Azure Cosmos DB pouvant prendre quelques minutes, vous devrez peut-être créer des comptes à l’avance. Si cette approche n’est pas possible, envisagez le modèle de base de données par locataire.

Si vous autorisez les locataires à migrer à partir d’un compte partagé vers un compte Azure Cosmos DB dédié, réfléchissez à l’approche de migration que vous allez utiliser pour déplacer les données d’un locataire entre les anciens et les nouveaux comptes.

Approches hybrides

Vous pouvez envisager une combinaison des approches ci-dessus pour répondre aux exigences des différents locataires et à votre modèle de tarification. Par exemple :

  • Provisionnez tous les clients de la version d’essai gratuite au sein d’un conteneur partagé et utilisez l’ID de locataire ou une clé de partition de clé synthétique.
  • Offrez un niveau Bronze payant qui déploie un conteneur dédié par locataire, mais avec un débit partagé sur une base de données.
  • Offrez un niveau Silver supérieur qui provisionne un débit dédié pour le conteneur du locataire.
  • Offrez le niveau Gold le plus élevé et fournissez un compte de base de données dédié pour le locataire, ce qui permet également aux locataires de sélectionner la zone géographique de leur déploiement.

Contributeurs

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

Auteurs principaux :

  • Paul Burpo | Ingénieur client principal, FastTrack for Azure
  • John Downs | Ingénieur client principal, FastTrack for Azure

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 :

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