Approches architecturales en matière de stockage et de données dans les solutions multi-locataires

Les données sont souvent considérées comme la partie la plus précieuse d’une solution, car elles représentent vos informations commerciales précieuses et celles de vos clients. Il est important de gérer soigneusement vos données. Lorsque vous planifiez des composants de stockage ou de données pour un système mutualisé, vous devez décider d’une approche pour partager ou isoler les données de vos locataires.

Cet article fournit des conseils sur les considérations clés et les exigences pour les architectes de solutions lorsqu’ils décident d’une approche pour stocker des données dans un système mutualisé. Cet article décrit également certains modèles courants pour l’application de l’architecture mutualisée aux services de stockage et de données et à certains antimodèles à éviter. Il fournit également des conseils ciblés pour certains scénarios spécifiques.

Considérations et exigences clés

Il est important de prendre en compte les approches que vous utilisez pour les services de stockage et de données de plusieurs points de vue, notamment les piliers d’Azure Well-Architected Framework.

Échelle

Lorsque vous travaillez avec des services qui stockent vos données, vous devez prendre en compte le nombre de locataires dont vous disposez et le volume de données que vous stockez. Si vous avez peu de locataires, tels que cinq ou moins, et que vous stockez de petites quantités de données pour chaque locataire, vous n’avez probablement pas besoin de planifier une approche de stockage de données hautement évolutive ou de créer une approche entièrement automatisée pour gérer vos ressources de données.

Toutefois, à mesure que vous augmentez, vous bénéficiez de plus en plus d’une stratégie claire pour mettre à l’échelle vos données et vos ressources de stockage et automatiser leur gestion. Lorsque vous avez 50 locataires ou plus, ou si vous envisagez d’atteindre ce niveau de mise à l’échelle, il est particulièrement important de concevoir vos données et votre approche de stockage avec une mise à l’échelle en tant que facteur clé.

Déterminez jusqu'où vous souhaitez pousser la mise à l'échelle, et planifiez clairement votre approche architecturale du stockage des données pour atteindre ce niveau de mise à l'échelle.

Prévisibilité des performances

Les services de stockage et de données multilocataire sont sensibles au problème de voisin bruyant. Il est important de déterminer si vos tenants peuvent affecter leurs performances mutuelles. Par exemple, déterminez si vos locataires ont des pics qui se chevauchent dans leurs modèles d’utilisation au fil du temps. Déterminez également si tous vos clients utilisent votre solution en même temps chaque jour et si les demandes sont distribuées uniformément. Ces facteurs affectent le niveau d’isolation dont vous avez besoin pour concevoir, la quantité de ressources que vous devez provisionner et le degré auquel les locataires peuvent partager des ressources.

Il est important de prendre en compte les quotas des ressources Azure et des requêtes dans le cadre de cette décision. Par exemple, supposons que vous déployez un seul compte de stockage pour contenir toutes les données de vos locataires. Si vous dépassez un nombre spécifique d’opérations de stockage par seconde, Stockage Azure rejette les demandes de votre application, ce qui affecte tous vos locataires. Ce fonctionnement est appelé régulation. Les requêtes limitées doivent être surveillées.

Isolation des données

Lorsque vous concevez une solution qui contient des services de données mutualisées, il existe différentes options et niveaux d’isolation des données qui présentent leurs propres avantages et compromis. Prenons les exemples suivants :

• Lorsque vous utilisez Azure Cosmos DB, vous pouvez déployer des conteneurs distincts pour chaque locataire et partager des bases de données et des comptes entre plusieurs locataires. Vous pouvez également envisager de déployer des bases de données différentes ou même des comptes pour chaque locataire, en fonction du niveau d’isolation dont vous avez besoin.

• Lorsque vous utilisez Stockage pour les données d’objets blob, vous pouvez déployer des conteneurs d’objets blob distincts pour chaque locataire, ou déployer des comptes de stockage distincts.

• Lorsque vous utilisez Azure SQL, vous pouvez utiliser des tables distinctes dans des bases de données partagées, ou déployer des bases de données ou des serveurs distincts pour chaque locataire.

• Dans tous les services Azure, vous pouvez envisager de déployer des ressources au sein d’un seul abonnement Azure partagé, ou vous pouvez utiliser plusieurs abonnements Azure ou même un abonnement pour chaque locataire.

Il n’existe aucune solution unique qui fonctionne pour chaque scénario. L’option que vous choisissez dépend de plusieurs facteurs et des exigences de vos locataires. Par exemple, si vous concevez une solution B2C (Business-to-Consumer), il peut être raisonnable d’avoir un magasin de données unique pour toutes vos données. Toutefois, si vos locataires doivent respecter des normes réglementaires ou de conformité spécifiques, vous devrez peut-être appliquer un niveau d’isolation plus élevé.

De même, vous pouvez avoir des exigences commerciales pour isoler physiquement les données de vos clients, ou vous devrez peut-être appliquer l’isolation pour éviter le problème de voisin bruyant. Si l’une des conditions suivantes s’applique, vous devrez peut-être isoler les locataires d’autres locataires ou les regrouper avec des locataires qui ont des stratégies similaires :

• Les locataires doivent utiliser leurs propres clés de chiffrement
• Les locataires ont des stratégies de sauvegarde et de restauration individuelles
• Les locataires doivent disposer de leurs données stockées dans différents emplacements géographiques

Complexité de l'implémentation

Il est important de tenir compte de la complexité de votre implémentation. Il est recommandé de garder votre architecture aussi simple que possible, tout en répondant à vos besoins. Évitez de vous engager dans une architecture qui peut devenir de plus en plus complexe à mesure que vous mettez à l’échelle ou une architecture que vous n’avez pas les ressources ou l’expertise nécessaires pour développer et gérer.

De même, si votre solution n’a pas besoin de s’adapter à un grand nombre de locataires ou si vous n’êtes pas préoccupé par les performances ou l’isolation des données, il est préférable de simplifier votre solution et d’éviter d’ajouter une complexité inutile.

Un point important à prendre en compte avec les solutions de données multilocataires est le niveau de personnalisation possible. Par exemple, vous pouvez autoriser un locataire à étendre votre modèle de données ou à appliquer des règles de données personnalisées. Assurez-vous que vous concevez en tenant compte de cette exigence dès le départ. Évitez la duplication ou fournissez une infrastructure personnalisée pour des locataires individuels. Une infrastructure personnalisée empêche votre capacité à mettre à l’échelle, à tester votre solution et à déployer des mises à jour. Au lieu de cela, envisagez d’utiliser des indicateurs de fonctionnalité et d’autres formes de configuration de client.

Complexité de la gestion et des opérations

Réfléchissez à la façon dont vous envisagez d’exploiter votre solution et comment votre approche multilocataire affecte vos opérations et processus.

• Gestion: Envisagez d’effectuer des opérations de gestion, telles que des activités de maintenance régulières. Si vous utilisez plusieurs serveurs, magasins de fichiers ou bases de données, envisagez de lancer et de surveiller les opérations de maintenance pour les ressources de chaque locataire.

• Surveillance et contrôle : Si vous surveillez ou mesurez vos locataires, réfléchissez à la façon dont votre solution signale les métriques et si elle peut facilement lier des métriques au locataire qui a déclenché la demande.

• Rapports: Déterminez si vous devez signaler des données agrégées provenant de plusieurs locataires isolés. À mesure que votre solution est mise à l’échelle, il devient fastidieux d’exécuter des requêtes sur chaque base de données individuellement et d’agréger les résultats. Une approche différente consiste à faire en ce que les applications de chaque locataire publient des données dans un entrepôt de données centralisé.

• Mises à jour de schéma : Si vous utilisez une base de données qui applique un schéma, planifiez le déploiement des mises à jour de schéma dans votre patrimoine. Réfléchissez à la façon dont votre application saura quelle version de schéma utiliser pour les requêtes de base de données d'un locataire spécifique.

• Exigences: Tenez compte des exigences de haute disponibilité de vos locataires, telles que les contrats de niveau de service de temps d’activité (SLA) et les exigences de récupération d’urgence, telles que les objectifs de délai de récupération (RTO) et les objectifs de point de récupération (RPO). Si les locataires ont des attentes différentes, vérifiez que vous pouvez répondre aux exigences de chaque locataire.

• Migration: Déterminez si vous souhaitez permettre aux locataires de passer à un autre type de service, à un autre déploiement ou à une autre région. Si vous envisagez d’offrir cette fonctionnalité, créez des processus et des outils pour vous assurer qu’il s’agit d’un processus reproductible et sûr.

Coûts

En règle générale, plus la densité de locataires de votre infrastructure de déploiement est élevée, plus le coût d'approvisionnement de cette infrastructure est faible. Toutefois, l’infrastructure partagée augmente la probabilité de problèmes tels que le problème de voisin bruyant, donc considérez soigneusement les compromis.

Approches et modèles à prendre en compte

Plusieurs modèles de conception du Centre d’architecture Azure sont pertinents pour le stockage multilocataire et les services de données. Vous pouvez choisir de suivre un modèle de manière cohérente. Vous pouvez également envisager de combiner et de mettre en correspondance des modèles. Par exemple, vous pouvez utiliser une base de données mutualisée pour la plupart de vos locataires, mais déployer des tampons à locataire unique pour les locataires qui paient plus ou qui ont des exigences inhabituelles.

Modèle d’empreintes de déploiement

Pour plus d’informations sur l’utilisation du modèle des timbres de déploiement pour prendre en charge une solution mutualisée, consultez Vue d’ensemble.

Bases de données multi-locataires et magasins de fichiers partagés

Vous pouvez envisager de déployer une base de données mutualisée partagée, un compte de stockage ou un partage de fichiers et de la partager sur tous vos locataires.

Cette approche offre la densité la plus élevée de locataires à l’infrastructure, de sorte qu’elle tend à atteindre le coût financier le plus bas de toute approche. Cela réduit également souvent la surcharge de gestion, car il existe une base de données ou une ressource unique pour gérer, sauvegarder et sécuriser.

Toutefois, lorsque vous travaillez avec une infrastructure partagée, tenez compte des inconvénients suivants :

• Limites de mise à l’échelle : Lorsque vous vous appuyez sur une seule ressource, tenez compte de la mise à l’échelle et des limites prises en charge de cette ressource. Par exemple, si votre architecture s’appuie sur une base de données partagée unique, la taille maximale d’une base de données ou d’un magasin de fichiers, ou les limites de débit maximales, deviennent finalement un bloqueur dur. Examinez attentivement l’échelle maximale dont vous avez besoin pour atteindre et la comparer à vos limites actuelles et futures avant de sélectionner ce modèle.

• Voisins bruyants : Le problème de voisin bruyant peut devenir un facteur, en particulier si vous avez des locataires qui sont occupés ou génèrent des charges de travail plus élevées que d’autres. Envisagez d’appliquer le modèle de limitation ou le modèle de limitation de débit pour atténuer ces effets.

• Mesurez la consommation des locataires : Déterminez si vous devez mesurer la consommation de chaque locataire. Certains services de données, tels qu’Azure Cosmos DB, fournissent des rapports sur l’utilisation des ressources pour chaque transaction. Vous pouvez suivre ces informations et l’agréger pour mesurer la consommation de chaque locataire. D'autres services ne fournissent pas le même niveau de détail. Par exemple, lorsque vous utilisez Azure Files avec des partages de fichiers Premium, vous pouvez accéder aux métriques pour la capacité de fichier pour chaque dimension de partage de fichiers. Le niveau standard fournit les métriques uniquement au niveau du compte de stockage.

• Configuration requise pour le locataire : Les locataires peuvent avoir des exigences différentes pour la sécurité, la sauvegarde, la disponibilité ou l’emplacement de stockage. Si ces exigences ne correspondent pas à la configuration de votre ressource unique, vous ne pourrez peut-être pas les prendre en charge.

• Personnalisation du schéma : Lorsque vous travaillez avec une base de données relationnelle ou un autre scénario où le schéma des données est important, la personnalisation du schéma au niveau du locataire est difficile.

Modèle de partitionnement

Le modèle de partitionnement implique le déploiement de plusieurs bases de données distinctes, appelées partitions, qui contiennent chacune une ou plusieurs données des locataires. Contrairement aux empreintes de déploiement, les partitions n'impliquent pas que toute l'infrastructure soit dupliquée. Vous pouvez partitionner des bases de données sans dupliquer ou partitionner d'autres infrastructures dans votre solution.

Le sharding est étroitement lié au partitionnement, et les termes sont souvent utilisés de manière interchangeable. Consultez Partitionnement des données horizontales, verticales et fonctionnelles.

Le modèle de partitionnement peut être mis à l’échelle vers un grand nombre de locataires. Selon votre charge de travail, vous pouvez également obtenir une haute densité de locataires sur les partitions, ce qui peut réduire les coûts. Vous pouvez utiliser le modèle de partitionnement pour traiter les quotas, limites et contraintes d’abonnement Azure et de service.

Certains magasins de données, tels qu'Azure Cosmos DB, offrent une prise en charge native du partitionnement. Lorsque vous travaillez avec d’autres solutions, telles qu’Azure SQL, il peut être plus complexe de créer une infrastructure de partitionnement et de router les demandes vers la partition appropriée pour un locataire donné.

Le partitionnement rend également difficile la prise en charge des différences de configuration au niveau du locataire et l'activation de la capacité des clients à fournir leurs propres clés de chiffrement.

Application multi-locataire avec bases de données dédiées pour chaque locataire

Une autre approche courante consiste à déployer une application multilocataire unique qui a des bases de données dédiées pour chaque locataire.

Dans ce modèle, les données de chaque locataire sont isolées des données des autres, et vous pourrez peut-être prendre en charge un certain degré de personnalisation pour chaque locataire.

Le coût de cette approche peut être supérieur à celui des modèles d’hébergement partagé, car vous approvisionnez des ressources de données dédiées pour chaque locataire. Toutefois, Azure fournit plusieurs options que vous pouvez envisager de partager le coût d’hébergement de ressources de données individuelles sur plusieurs locataires. Par exemple, lorsque vous travaillez avec Azure SQL Database, vous pouvez envisager des pools élastiques. Pour Azure Cosmos DB, vous pouvez provisionner le débit pour une base de données et le débit est partagé entre les conteneurs de cette base de données. Toutefois, cette approche n’est pas appropriée lorsque vous avez besoin de performances garanties pour chaque conteneur.

Dans cette approche, étant donné que seuls les composants de données sont déployés individuellement pour chaque locataire, vous pouvez atteindre une densité élevée pour les autres composants de votre solution et réduire le coût de ces composants.

Modèle Geode

Le modèle Geode est conçu spécifiquement pour les solutions distribuées géographiquement, y compris les solutions multilocataires. Il prend en charge une charge élevée et de hauts niveaux de résilience. Si vous implémentez le modèle Geode, votre niveau de données doit être en mesure de répliquer les données dans différentes régions géographiques, et il doit prendre en charge les écritures dans plusieurs zones géographiques.

Azure Cosmos DB fournit des écritures à plusieurs régions pour prendre en charge ce modèle, et Azure Managed Instance pour Apache Cassandra prend en charge les clusters à plusieurs régions. D’autres services de données ne peuvent généralement pas prendre en charge ce modèle sans personnalisation significative.

Antimodèles à éviter

Lorsque vous créez des services de données multilocataires, il est impératif d’éviter les situations qui entravent votre capacité de mise à l’échelle.

Pour les bases de données relationnelles, ces antimodèles sont les suivants :

• Isolation basée sur une table. Lorsque vous travaillez dans une base de données unique, évitez de créer des tables individuelles pour chaque locataire. Une base de données unique ne peut pas prendre en charge un grand nombre de locataires lorsque vous utilisez cette approche, et il devient de plus en plus difficile d’interroger, de gérer et de mettre à jour des données. Envisagez plutôt d'utiliser un ensemble unique de tables multi-locataires avec une colonne d'identification des locataires. Vous pouvez également utiliser un modèle recommandé pour déployer des bases de données distinctes pour chaque locataire.

• Personnalisation des locataires au niveau des colonnes. Évitez les mises à jour de schéma qui ne s'appliquent qu'à un seul locataire. Par exemple, supposons que vous disposez d’une base de données mutualisée unique. Évitez d'ajouter une nouvelle colonne pour répondre aux exigences d'un locataire spécifique. Il peut être acceptable pour quelques personnalisations, mais cette méthode devient rapidement inmanageable lorsque vous avez de nombreuses personnalisations à prendre en compte. Envisagez plutôt de réviser votre modèle de données pour suivre les données personnalisées de chaque locataire dans une table dédiée.

• Modifications manuelles du schéma. Évitez de mettre à jour manuellement le schéma de votre base de données, même si vous ne disposez que d'une seule base de données partagée. Il est facile de perdre le suivi des mises à jour que vous appliquez et, si vous devez effectuer un scale-out vers davantage de bases de données, il est difficile d’identifier le schéma approprié à appliquer. Au lieu de cela, générez des outils ou un pipeline automatisé pour déployer vos modifications de schéma et utilisez-le de manière cohérente. Suivez la version de schéma que vous utilisez pour chaque locataire dans une base de données ou une table de recherche dédiée.

• Dépendances de version. Veillez à ce que votre application ne dépende pas d'une seule version de votre schéma de base de données. Au fil des mises à l’échelle, il peut être nécessaire d’appliquer des mises à jour de schéma à différents moments pour différents tenants. Au lieu de cela, assurez-vous que la version de votre application est rétrocompatible avec au moins une version de schéma précédente, et que les modifications de schéma destructrices sont réparties sur plusieurs versions pour prendre en charge les retours en arrière.

Bases de données

Certaines fonctionnalités peuvent être utiles à l'architecture multi-locataire. Toutefois, ces fonctionnalités ne sont pas disponibles dans tous les services de base de données. Déterminez si vous avez besoin des fonctionnalités suivantes lorsque vous décidez du service à utiliser pour votre scénario :

• La sécurité au niveau des lignes peut fournir une isolation de sécurité pour les données de locataires spécifiques dans une base de données mutualisée partagée. Cette fonctionnalité est disponible dans certaines bases de données, comme SQL Database et Azure Database pour PostgreSQL serveur flexible.

  Lorsque vous utilisez la sécurité au niveau des lignes, vous devez vous assurer que l’identité de l’utilisateur et l’identité de locataire sont propagées via l’application et dans le magasin de données avec chaque requête. Cette approche peut être complexe à concevoir, implémenter, tester et gérer. De nombreuses solutions multilocataires n’utilisent pas de sécurité au niveau des lignes en raison de ces complexités.

• Le chiffrement au niveau du locataire peut être nécessaire pour prendre en charge les locataires qui fournissent leurs propres clés de chiffrement pour leurs données. Cette fonctionnalité est disponible dans SQL Server et Azure SQL dans le cadre d’Always Encrypted. Azure Cosmos DB fournit des clés gérées par le client au niveau du compte et prend également en charge Always Encrypted.

• Le regroupement de ressources vous permet de partager des ressources et leurs coûts entre plusieurs bases de données ou conteneurs. Cette fonctionnalité est disponible dans les pools élastiques de SQL Database, dans Azure SQL Managed Instance et dans le débit de base de données Azure Cosmos DB.

• La shardisation et le partitionnement ont une prise en charge native plus forte dans certains services que dans d’autres. Cette fonctionnalité est disponible dans Azure Cosmos DB à l’aide de son partitionnement logique et physique. Bien que SQL Database ne prend pas en charge le partitionnement en mode natif, il fournit des outils de partitionnement pour prendre en charge ce type d’architecture.

En outre, lorsque vous gérez une flotte de bases de données relationnelles ou d’autres bases de données basées sur des schémas, envisagez l’endroit où le processus de mise à niveau du schéma doit être déclenché. Dans un petit domaine de bases de données, vous pouvez envisager d'utiliser un pipeline de déploiement pour déployer les modifications de schéma. Au fur et à mesure que le nombre de bases de données augmente, il peut être préférable que votre couche Application détecte la version du schéma d'une base de données spécifique et lance le processus de mise à niveau.

Stockage de fichiers et d'objets blob

Considérez l’approche que vous utilisez pour isoler les données au sein d’un compte de stockage. Par exemple, vous pouvez déployer des comptes de stockage distincts pour chaque locataire, ou partager des comptes de stockage et déployer des conteneurs individuels. Vous pouvez également créer des conteneurs d'objets blob partagés, puis utiliser le chemin d'accès aux objets blob pour séparer les données de chaque locataire. Tenez compte des limites et des quotas d’abonnement Azure, et planifiez soigneusement votre croissance pour vous assurer que vos ressources Azure sont mises à l’échelle pour prendre en charge vos besoins futurs.

Si vous utilisez des conteneurs partagés, planifiez soigneusement votre stratégie d’authentification et d’autorisation pour vous assurer que les locataires ne peuvent pas accéder aux données des autres. Prenez en compte le modèle de clé Valet lorsque vous fournissez aux clients un accès aux ressources de stockage.

Affectation des coûts

Réfléchissez à la façon dont vous mesurez la consommation et allouez des coûts aux locataires pour l’utilisation des services de données partagés. Si possible, essayez d'utiliser des métriques intégrées au lieu de calculer vos propres métriques. Toutefois, avec une infrastructure partagée, il devient difficile de fractionner les données de télémétrie pour des tenants individuels, et vous devrez peut-être envisager une mesure personnalisée au niveau de l'application.

En général, les services natifs Cloud, comme Azure Cosmos DB et Stockage Blob Azure, fournissent des métriques plus précises pour suivre et modéliser l'utilisation d'un locataire spécifique. Par exemple, Azure Cosmos DB fournit le débit consommé pour chaque requête et chaque réponse.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques

Autres contributeurs :

• Paul Burpo | Ingénieur client principal, FastTrack for Azure
• Daniel Scott-Raynsford | Stratégiste de la technologie partenaire
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

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

Ressources associées

Pour plus d’informations sur l’architecture mutualisée et les services Azure spécifiques, consultez les ressources suivantes :

• Multi-tenance et stockage
• Architecture mutualisée et base de données SQL
• Architecture mutualisée et Azure Cosmos DB
• Architecture mutualisée et base de données Azure Database pour PostgreSQL