Modèles de client de base de données SaaS multilocataires

S’applique à : Azure SQL Database

Cet article décrit les différents modèles de location disponibles pour une application SaaS en architecture mutualisée.

Quand vous concevez une application SaaS en architecture mutualisée, vous devez choisir avec soin le modèle de client qui répond le mieux aux besoins de votre application. Un modèle de location détermine la façon dont les données de chaque locataire sont mappées au stockage. Le modèle de location que vous choisissez a un impact sur la conception et la gestion des applications. Le fait de passer à un autre modèle par la suite peut parfois s’avérer coûteux.

R. Concepts et terminologie SaaS

Dans le modèle SaaS (Software as a Service), votre entreprise ne vend pas de licences de vos logiciels. À la place, chaque client paie un loyer à votre entreprise, qui fait de chaque client un locataire de votre entreprise.

En échange du loyer, chaque client reçoit l’accès aux composants de votre application SaaS et voit ses données stockées dans le système SaaS.

Le terme modèle de location fait référence à la façon dont sont organisées les données stockées des locataires :

• Monolocation : Chaque base de données stocke les données d’un seul locataire.
• Multilocation : Chaque base de données stocke les données de plusieurs locataires distincts (avec des mécanismes de protection de la confidentialité des données).
• Des modèles de location hybrides sont également disponibles.

B. Comment choisir le modèle de location approprié

En général, le modèle de client n’affecte pas les fonctionnalités d’une application, mais il peut avoir un impact sur d’autres aspects de la solution dans son ensemble. Les critères suivants sont utilisés pour évaluer chacun des modèles :

• Scalabilité :

  • Nombre de locataires.
  • Stockage par locataire.
  • Stockage dans l’agrégat.
  • Charge de travail.

• Isolation des locataires : Niveau de performance et isolation des données (impact de la charge de travail d’un locataire sur les autres).

• Coût par locataire : Coûts des bases de données.

• Complexité du développement :

  • Changements apportés au schéma.
  • Changements apportés aux requêtes (exigés par le modèle).

• Complexité opérationnelle :

  • Surveillance et gestion des performances.
  • Gestion des schémas.
  • Restauration d’un locataire.
  • Récupération d’urgence.

• Possibilités de personnalisation : Facilité de prise en charge des personnalisations de schéma propres au locataire ou à la classe du locataire.

La discussion sur la location est axée sur la couche Données. Mais réfléchissons un instant à la couche Application. La couche Application est traitée comme une entité monolithique. Si vous divisez l’application en plusieurs composants, le modèle de location que vous avez choisi peut être amené à changer. Vous pouvez traiter certains composants différemment des autres sur le plan de la location et de la plateforme/technologie de stockage utilisées.

C. Application à locataire unique autonome avec une base de données à locataire unique

Isolation au niveau de l’application

Dans ce modèle, l’application est installée en intégralité à plusieurs reprises, une fois par locataire. Chaque instance de l’application étant autonome, une instance n’interagit jamais avec une autre instance autonome. Chaque instance de l’application n’a qu’un seul locataire et ne nécessite donc qu’une base de données. Le locataire dispose de la base de données pour lui tout seul.

Chaque instance de l’application est installée dans un groupe de ressources Azure distinct. Le fournisseur du logiciel ou le client peut être propriétaire de l'abonnement qui possède le groupe de ressources. Dans les deux cas, l’éditeur peut gérer le logiciel pour le locataire. Chaque instance de l’application est configurée pour se connecter à la base de données correspondante.

Chaque base de données de locataire est déployée en tant que base de données unique. Ce modèle offre le niveau d’isolation de base de données le plus élevé. Mais l’isolation nécessite que des ressources suffisantes soient allouées à chaque base de données pour gérer les pics de charge. L’important ici, c’est que les pools élastiques ne peuvent pas être utilisés pour les bases de données déployées sur des groupes de ressources ou des abonnements différents. En raison de cette limitation, le modèle d’application autonome à locataire unique constitue la solution la plus onéreuse du point de vue du coût global des bases de données.

Gestion des fournisseurs

Le fournisseur peut accéder à toutes les bases de données dans toutes les instances d’application autonomes, même si les instances d’application sont installées dans des abonnements appartenant à des locataires différents. L’accès s’effectue par le biais de connexions SQL. Cet accès entre instances peut permettre au fournisseur de centraliser la gestion des schémas et les requêtes entre bases de données dans le but de créer des rapports ou à des fins analytiques. Si ce type de gestion centralisée est souhaité, vous devez déployer un catalogue qui mappe les identificateurs de client aux URI de base de données. Azure SQL Database propose une bibliothèque de partitionnement qui fonctionne pour fournir un catalogue. La bibliothèque de partitionnement a pour nom officiel Bibliothèque cliente de bases de données élastiques.

D. Application en architecture mutualisée avec une base de données par client

Le modèle suivant utilise une application en architecture mutualisée avec plusieurs bases de données qui sont toutes à client unique. Une nouvelle base de données est provisionnée pour chaque nouveau locataire. Vous pouvez mettre à l’échelle la couche Application verticalement en ajoutant davantage de ressources par nœud. Vous pouvez aussi mettre à l’échelle l’application horizontalement en ajoutant des nœuds supplémentaires. La mise à l’échelle est basée sur la charge de travail et est indépendante du nombre ou de l’échelle des bases de données individuelles.

Personnaliser en fonction d’un locataire

Comme le modèle d’application autonome, l’utilisation de bases de données à locataire unique offre un niveau élevé d’isolation des locataires. Dans toute application dont le modèle spécifie uniquement des bases de données à locataire unique, vous pouvez personnaliser et optimiser le schéma d’une base de données quelconque en fonction de son locataire. Cette personnalisation n’affecte pas les autres clients dans l’application. Par exemple, un locataire peut nécessiter des données qui ne figurent pas dans les champs de données de base communs à tous les locataires. Par ailleurs, le champ de données supplémentaire peut nécessiter un index.

Grâce au modèle de base de données par locataire, vous pouvez facilement personnaliser le schéma pour un ou plusieurs locataires individuels. Le fournisseur de l’application doit concevoir des procédures pour gérer avec soin les personnalisations du schéma à l’échelle.

Pools élastiques

Quand des bases de données sont déployées dans le même groupe de ressources, elles peuvent être regroupées dans des pools élastiques. Les pools offrent un moyen économique de partager des ressources entre plusieurs bases de données. Le fait de recourir à des pools revient moins cher que d’exiger une base de données suffisamment volumineuse pour faire face aux pics d’utilisation. Même si les bases de données mises en pool partagent l’accès aux ressources, vous pouvez toujours obtenir un niveau élevé d’isolation des performances.

Azure SQL Database fournit les outils nécessaires pour configurer, surveiller et gérer le partage. Les métriques de performances au niveau du pool et de la base de données sont disponibles dans le portail Azure et par le biais des journaux Azure Monitor. Les métriques peuvent donner d’excellents insights sur les performances agrégées et celles spécifiques au locataire. Vous pouvez déplacer les bases de données individuelles entre pools pour fournir des ressources réservées à un locataire spécifique. Ces outils vous permettent de garantir un bon niveau de performance de façon rentable.

Mise à l’échelle des opérations pour le modèle de base de données par locataire

Azure SQL Database propose de nombreuses fonctionnalités de gestion conçues pour gérer plus de 100 000 bases de données à grande échelle. Ces fonctionnalités font du modèle de base de données par locataire un modèle plausible.

Prenons l’exemple d’un système constitué d’une seule base de données à 1 000 locataires. La base de données peut avoir 20 index. Si le système passe à 1000 bases de données à client unique, le nombre d’index s’élève à 20 000. Dans le cadre du paramétrage automatique Azure SQL Database, les fonctionnalités d’indexation automatiques sont activées par défaut. L’indexation automatique gère pour vous les 20 000 index et l’optimisation des opérations continues de création et de suppression. Effectuées dans une base de données individuelle, ces actions automatisées ne sont ni coordonnées ni restreintes par des actions similaires dans d’autres bases de données. L’indexation automatique traite différemment les index selon qu’ils se trouvent dans une base de données occupée ou non. Cette tâche colossale de personnalisation de la gestion des index serait difficile à réaliser manuellement à l’échelle du modèle de base de données par locataire.

Parmi les autres fonctionnalités de gestion pouvant facilement être mises à l’échelle, citons les suivantes :

• Sauvegardes intégrées.
• Haute disponibilité :
• Chiffrement sur le disque.
• Télémétrie des performances.

Automatisation

Les opérations de gestion peuvent être scriptées et proposées par le biais d’un modèle devops. Vous pouvez même automatiser et exposer les opérations dans l’application.

Par exemple, vous pouvez automatiser la récupération d’un locataire unique à un point antérieur dans le temps. La récupération doit seulement restaurer la base de données à locataire unique qui stocke le locataire. Cette restauration n’a aucun impact sur les autres locataires, ce qui confirme que les opérations de gestion sont effectuées très précisément au niveau de chaque locataire.

E. Application mutualisée avec des bases de données mutualisées

Un autre modèle disponible consiste à stocker plusieurs clients dans une base de données multi-locataire. L’instance d’application peut avoir autant de bases de données en architecture mutualisée que vous le souhaitez. Le schéma d’une base de données en architecture mutualisée doit avoir une ou plusieurs colonnes d’identification des clients pour permettre la récupération sélective des données de n’importe quel client. En outre, le schéma peut nécessiter quelques tables ou colonnes qui sont uniquement utilisées par un sous-ensemble de locataires. Toutefois, le code statique et les données de référence ne sont stockés qu’une seule fois et sont partagés par tous les locataires.

L’isolation des locataires est pénalisée

Données : Une base de données à architecture mutualisée nuit nécessairement à l’isolation des clients. Les données de plusieurs locataires sont stockées ensemble dans une base de données. Pendant le développement, vérifiez que les requêtes n’exposent jamais les données de plusieurs locataires. SQL Database prend en charge la sécurité au niveau des lignes, ce qui permet de limiter l’étendue des données retournées par une requête à un seul locataire.

Traitement : Une base de données en architecture mutualisée partage les ressources de calcul et de stockage entre tous ses clients. Vous pouvez surveiller la base de données dans son ensemble pour vérifier que ses performances sont acceptables. Toutefois, le système Azure n’intègre aucun outil permettant de surveiller ou de gérer l’utilisation de ces ressources par un locataire individuel. La base de données en architecture mutualisée accroît donc le risque de rencontre de voisins bruyants, où la charge de travail d’un client hyperactif a un impact sur les performances des autres clients dans la même base de données. Un contrôle plus poussé au niveau de l'application permettrait de surveiller les performances au niveau du client.

Coûts réduits

En général, les bases de données en architecture mutualisée offrent le coût le plus bas par client. Les coûts des ressources pour une base de données unique sont inférieurs à ceux d’un pool élastique de taille équivalente. De plus, pour les scénarios où les locataires ont seulement besoin d’un stockage limité, vous pouvez potentiellement stocker des millions de locataires dans une même base de données. Un pool élastique ne peut pas contenir des millions de bases de données. Toutefois, si vous avez une solution contenant 1 000 bases de données par pool et 1 000 pools, vous risquez de vous retrouver avec une solution lourde à gérer composée de millions d’éléments.

Deux variantes du modèle de base de données en architecture mutualisée sont abordées ci-après, le modèle en architecture mutualisée partitionné étant le plus souple et le plus scalable.

F. Application mutualisée avec une base de données en architecture mutualisée unique

Le modèle de base de données en architecture mutualisée le plus simple emploie une base de données unique pour héberger des données pour tous les clients. Au fur et à mesure que des locataires sont ajoutés, la base de données est mise à l’échelle verticalement avec davantage de ressources de stockage et de calcul. Cette mise à l’échelle verticale peut suffire, bien qu’elle soit toujours soumise à une limite. Cependant, la base de données devient lourde à gérer bien avant que cette limite ne soit atteinte.

Les opérations de gestion qui portent sur des clients individuels sont plus complexes à implémenter dans une base de données en architecture mutualisée. Et à grande échelle, ces opérations peuvent devenir beaucoup trop lentes. C’est le cas par exemple d’une restauration dans le temps des données pour un seul locataire.

G. Application en architecture mutualisée avec des bases de données en architecture mutualisée partitionnées

La plupart des applications SaaS accèdent aux données d’un seul locataire à la fois. Ce modèle d’accès permet aux données du locataire d’être distribuées entre plusieurs bases de données ou partitions, où toutes les données d’un locataire sont contenues dans une seule partition. Associé à un modèle de base de données d’architecture mutualisée, un modèle partitionné autorise une mise à l’échelle pratiquement illimitée.

Gérer les partitions

Le partitionnement rend la conception et la gestion des opérations plus complexes. Vous devez disposer d’un catalogue dans lequel le mappage entre les locataires et les bases de données est tenu à jour. Des procédures de gestion sont également nécessaires pour gérer les partitions et la population des locataires. Par exemple, vous devez concevoir des procédures pour ajouter et supprimer des partitions et pour déplacer les données des locataires entre partitions. L’un des moyens d’effectuer la mise à l’échelle consiste à ajouter une nouvelle partition et à la peupler de nouveaux locataires. En d’autres occasions, vous pouvez fractionner une partition très peuplée en deux partitions moins peuplées. Si plusieurs locataires sont déplacés ou mis hors service, vous pouvez fusionner des partitions peu peuplées ensemble. La fusion aboutit à une utilisation plus rentable des ressources. Vous pouvez également déplacer les locataires entre partitions pour équilibrer les charges de travail.

SQL Database propose un outil de fractionnement/fusion qui fonctionne conjointement avec la bibliothèque de partitionnement et la base de données de catalogues. L’application fournie peut non seulement fractionner et fusionner les partitions, mais elle peut aussi déplacer les données des locataires entre partitions. L’application gère également le catalogue pendant ces opérations ; pour cela, elle marque les client affectés comme étant hors connexion avant de les déplacer. Au terme du déplacement, l’application remet à jour le catalogue avec le nouveau mappage et marque le locataire comme étant à nouveau en ligne.

Gestion plus facile des bases de données plus petites

La solution d’architecture mutualisée partitionnée répartit les clients sur plusieurs bases de données, ce qui conduit à des bases de données plus petites et plus faciles à gérer. Par exemple, pour restaurer un locataire spécifique à un point antérieur dans le temps, il suffit désormais de restaurer une seule base de données de petite taille à partir d’une sauvegarde (et non une base de données volumineuse contenant tous les locataires). Vous pouvez choisir la taille de la base de données et le nombre de locataires par base de données pour équilibrer la charge de travail et les efforts de gestion.

Identificateur de locataire dans le schéma

Selon l’approche de partitionnement utilisée, des contraintes supplémentaires peuvent être imposées au schéma de base de données. L’application de fractionnement/fusion SQL Database exige que le schéma inclue la clé de partitionnement, qui est généralement l’identificateur de locataire. L’identificateur de locataire est l’élément situé au début de la clé primaire de toutes les tables partitionnées. L’identificateur de locataire permet à l’application de fractionnement/fusion de localiser et de déplacer rapidement les données associées à un locataire spécifique.

Pool élastique pour les partitions

Vous pouvez placer les bases de données en architecture mutualisée partitionnées dans des pools élastiques. En général, le fait d’avoir plusieurs bases de données à client unique dans un pool est aussi rentable que d’avoir plusieurs clients dans quelques bases de données en architecture mutualisée. Les bases de données en architecture mutualisée sont avantageuses quand vous avez un grand nombre de clients relativement inactifs.

H. Modèle de base de données en architecture mutualisée partitionnée hybride

Dans le modèle hybride, l’identificateur de locataire est inclus dans le schéma de toutes les bases de données. Les bases de données sont toutes capables de stocker plusieurs locataires, et elles peuvent être partitionnées. Du point de vue du schéma, ces bases de données sont donc toutes en architecture mutualisée. Pourtant, dans la pratique, certaines de ces bases de données contiennent un seul locataire. Quoi qu’il en soit, la quantité de locataires stockés dans une base de données n’a aucun effet sur le schéma de la base de données.

Déplacer les locataires

Vous pouvez à tout moment déplacer un client spécifique dans sa propre base de données à architecture mutualisée. Vous pouvez aussi à tout moment replacer le locataire dans une base de données contenant plusieurs locataires. Vous pouvez également affecter un locataire à une nouvelle base de données à locataire unique quand vous provisionnez la nouvelle base de données.

Le modèle hybride est particulièrement adapté quand des groupes identifiables de locataires ont des besoins en ressources très différents. Par exemple, supposons que les clients qui participent à un essai gratuit ne bénéficient pas systématiquement du même niveau de performance que les clients abonnés. La stratégie peut stipuler de stocker les clients dans la phase d’essai gratuit dans une base de données en architecture mutualisée qui est partagée entre tous les clients de l’essai gratuit. Quand un client dans la phase d’essai gratuit s’abonne au niveau de service de base, le client peut être déplacé dans une autre base de données en architecture mutualisée qui peut contenir moins de clients. Un abonné qui paie pour un niveau de service Premium peut être déplacé dans sa nouvelle base de données monolocataire.

Pools

Dans ce modèle hybride, les bases de données à locataire unique pour les locataires abonnés peuvent être placées dans des pools de ressources pour réduire les coûts de la base de données par locataire. Il en va de même dans le modèle de base de données par locataire.

I. Comparaison des modèles de location

Le tableau suivant récapitule les différences entre les principaux modèles de location.

Contenu connexe

• Déployer et explorer une application Wingtip d’architecture mutualisée qui utilise le modèle SaaS de base de données par client - Azure SQL Database

• Bienvenue dans l’exemple d’application de location Azure SQL Database Wingtip Tickets SaaS