ARCHITECTURE MULTI-LOCATAIRE

(TENANT)

PARTIE I : THEORIE
Modèles de multi-locataire pour la base de données SaaS (Software as a Service)

Lors de la conception d'une application SaaS multi-locataire, il est essentiel de choisir avec soin le
modèle de locataire qui correspond le mieux aux besoins de votre application. Un modèle de locataire
détermine comment les données de chaque locataire sont associées au stockage (base de données).
Votre choix de modèle de locataire influence la conception et la gestion de l'application. Changer
ultérieurement pour un modèle différent peut parfois être coûteux.

I- Concepts et terminologie SaaS

Dans le modèle de Software as a Service (SaaS), votre entreprise ne vend pas de licences
pour votre logiciel. Au lieu de cela, chaque client effectue des paiements de location à
votre entreprise, faisant de chaque client un locataire de votre entreprise.

En échange du paiement de la location, chaque locataire a accès aux composants de votre

application SaaS et ses données sont stockées dans le système SaaS.

Le terme modèle de locataire se réfère à la manière dont les données des locataires sont
organisées :

- Locataire unique : Chaque base de données stocke les données d'un seul locataire.

- Multi-locataire : Chaque base de données stocke les données de plusieurs locataires

distincts (avec des mécanismes pour protéger la confidentialité des données).

- Des modèles de locataire hybrides sont également disponibles.

II- Comment choisir le modèle de locataire approprié

Scalabilité :

- Nombre de locataires.
- Stockage par locataire.
- Stockage global.
 - Charge de travail (Workload).

Isolation des locataires : Isolation des données et performance (si la charge de travail d'un
locataire impacte les autres).

Coût par locataire : Coûts de la base de données.

Complexité de développement :

- Modifications du schéma.
- Modifications des requêtes (requises par le modèle).

Complexité opérationnelle :

- Surveillance et gestion des performances.

- Gestion du schéma.
- Restauration d'un locataire.
- Plan de reprise après sinistre.

Personnalisation : Facilité de prise en charge des personnalisations de schéma spécifiques

à un locataire ou à une classe de locataires.

La discussion sur la locataire est axée sur la couche de données. Mais considérez un instant
la couche d'application. La couche d'application est traitée comme une entité
monolithique. Si vous divisez l'application en de nombreux petits composants, votre choix
de modèle de locataire pourrait changer. Vous pourriez traiter certains composants
différemment des autres en ce qui concerne à la fois la locataire et la technologie ou la
plateforme de stockage utilisée.

III- Application autonome avec une base de données dédiée à un seul

locataire

1- Isolation au niveau de l'application

Dans ce modèle, l'ensemble de l'application est installé de manière répétée, une fois
pour chaque locataire. Chaque instance de l'application est une instance autonome,
elle n'interagit donc jamais avec une autre instance autonome. Chaque instance de
l'application n'a qu'un seul locataire et n'a donc besoin que d'une seule base de
données. Le locataire a la base de données entièrement pour lui-même.
 Chaque instance de l'application est installée dans un groupe de ressources distinct.
Le groupe de ressources peut appartenir à un abonnement détenu soit par le
fournisseur de logiciels, soit par le locataire. Dans les deux cas, le fournisseur peut
gérer le logiciel pour le locataire. Chaque instance de l'application est configurée pour
se connecter à sa base de données correspondante.

Chaque base de données locataire est déployée en tant que base de données unique.
Ce modèle offre la plus grande isolation de base de données. Cependant, cette
isolation nécessite l'allocation de ressources suffisantes à chaque base de données
pour gérer ses charges maximales. Il est important de noter que les pools élastiques
ne peuvent pas être utilisés pour les bases de données déployées dans des groupes
de ressources différents ou dans des abonnements différents. Cette limitation rend
ce modèle d'application autonome à locataire unique la solution la plus coûteuse du
point de vue global des coûts de base de données.

2- Gestion du fournisseur

Le fournisseur peut accéder à toutes les bases de données de toutes les instances
autonomes de l'application, même si les instances de l'application sont installées dans
différents abonnements locataires. L'accès est réalisé via des connexions SQL. Cet
accès inter-instances peut permettre au fournisseur de centraliser la gestion du
schéma et les requêtes interbases de données à des fins de reporting ou d'analyse. Si
ce type de gestion centralisée est souhaité, un catalogue doit être déployé pour faire
correspondre les identifiants de locataire aux URI de base de données.

IV- Application multi-locataire avec une base de données par locataire

Ce modèle suivant utilise une application multi-locataire avec de nombreuses bases de

données, toutes étant des bases de données dédiées à un seul locataire. Une nouvelle
base de données est provisionnée pour chaque nouveau locataire. La couche d'application
est mise à l'échelle verticalement en ajoutant plus de ressources par nœud. Ou
l'application est mise à l'échelle horizontalement en ajoutant plus de nœuds. 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.
1- Personnaliser pour un locataire

Comme dans le modèle d'application autonome, l'utilisation de bases de données

dédiées à un seul locataire offre une forte isolation des locataires. Dans toute
application dont le modèle spécifie uniquement des bases de données dédiées à un
seul locataire, le schéma de n'importe quelle base de données peut être personnalisé
et optimisé pour son locataire. Cette personnalisation n'affecte pas les autres
locataires de l'application. Il se peut qu'un locataire ait besoin de données au-delà des
champs de données de base nécessaires à tous les locataires. De plus, le champ de
données supplémentaire pourrait nécessiter un index.

Avec une base de données par locataire, la personnalisation du schéma pour un ou

plusieurs locataires individuels est facile à réaliser. Le fournisseur de l'application doit
concevoir des procédures pour gérer soigneusement les personnalisations de schéma
à grande échelle.

2- Pools élastiques

Lorsque les 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 une
manière rentable de partager des ressources entre de nombreuses bases de données.
Cette option de pool est moins coûteuse que d'exiger que chaque base de données
soit suffisamment grande pour accueillir les pics d'utilisation qu'elle connaît. Même si
les bases de données regroupées partagent l'accès aux ressources, elles peuvent
toujours atteindre un haut degré d'isolation des performances.
V- Application multi-locataire avec des bases de données multi-
locataires

Un autre modèle disponible consiste à stocker de nombreux locataires dans une base de
données multi-locataire. L'instance de l'application peut avoir un nombre quelconque de
bases de données multi-locataires. Le schéma d'une base de données multi-locataire doit
avoir une ou plusieurs colonnes d'identifiant de locataire afin que les données de
n'importe quel locataire donné puissent être récupérées sélectivement. De plus, le
schéma peut nécessiter quelques tables ou colonnes utilisées uniquement par un sous-
ensemble de locataires. Cependant, 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.

1- L'isolation des locataires est sacrifiée

Données : Une base de données multi-locataire sacrifie nécessairement l'isolation des

locataires. Les données de plusieurs locataires sont stockées ensemble dans une seule
base de données. Pendant le développement, assurez-vous que les requêtes
n'exposent jamais les données de plus d'un locataire. SQL Database prend en charge
la sécurité au niveau des lignes, qui peut garantir que les données renvoyées par une
requête sont limitées à un seul locataire.

Traitement : Une base de données multi-locataire partage les ressources de calcul et

de stockage entre tous ses locataires. La base de données dans son ensemble peut
être surveillée pour garantir qu'elle fonctionne de manière acceptable. La base de
données multi-locataire présente un risque accru de rencontrer des voisins bruyants,
où la charge de travail d'un locataire trop actif impacte l'expérience de performance
des autres locataires dans la même base de données. Une surveillance
supplémentaire au niveau de l'application pourrait surveiller les performances au
niveau du locataire.

2- Coût inférieur

En général, les bases de données multi-locataires ont le coût par locataire le plus bas.
Les coûts des ressources pour une seule base de données sont inférieurs à ceux d'un
 pool élastique de taille équivalente. De plus, pour les scénarios où les locataires n'ont
besoin que d'un espace de stockage limité, potentiellement des millions de locataires
pourraient être stockés dans une seule base de données. Aucun pool élastique ne
peut contenir des millions de bases de données. Cependant, une solution contenant
1000 bases de données par pool, avec 1000 pools, pourrait atteindre l'échelle des
millions au risque de devenir difficile à gérer.

Deux variations d'un modèle de base de données multi-locataires sont discutées ci-
dessous, le modèle multi-locataire fragmenté étant le plus flexible et évolutif.

VI- Application multi-locataire avec une seule base de données multi-

locataire

Le modèle de base de données multi-locataire le plus simple utilise une seule base de
données pour héberger les données de tous les locataires. À mesure que davantage de
locataires sont ajoutés, la base de données est mise à l'échelle avec plus de ressources de
stockage et de calcul. Cette mise à l'échelle pourrait être tout ce qui est nécessaire, bien
qu'il y ait toujours une limite ultime d'échelle. Cependant, bien avant d'atteindre cette
limite, la base de données devient difficile à gérer.

Les opérations de gestion axées sur des locataires individuels sont plus complexes à
mettre en œuvre dans une base de données multi-locataire. Et à grande échelle, ces
opérations pourraient devenir inacceptablement lentes. Un exemple est une restauration
à un moment donné des données pour un seul locataire.

VII- Application multi-locataire avec des bases de données multi-

locataires fragmentées

La plupart des applications SaaS accèdent aux données d'un seul locataire à la fois. Ce
modèle d'accès permet de distribuer les données des locataires sur plusieurs bases de
données ou fragments, où toutes les données d'un locataire donné sont contenues dans
un fragment. Associé à un modèle de base de données multi-locataire, un modèle
fragmenté permet une échelle presque illimitée.

1- Gérer les fragments

 Fragmenté ajoute de la complexité tant à la conception qu'à la gestion opérationnelle.
Un catalogue est nécessaire pour maintenir la correspondance entre les locataires et
les bases de données. De plus, des procédures de gestion sont nécessaires pour gérer
les fragments et la population de locataires. Par exemple, des procédures doivent être
conçues pour ajouter et supprimer des fragments, ainsi que pour déplacer les
données des locataires entre les fragments. Une manière de mettre à l'échelle est
d'ajouter un nouveau fragment et de le peupler avec de nouveaux locataires. À
d'autres moments, vous pourriez diviser un fragment densément peuplé en deux
fragments moins densément peuplés. Après le déplacement ou l'arrêt de plusieurs
locataires, vous pourriez fusionner des fragments peu peuplés ensemble. La fusion
permettrait une utilisation plus rentable des ressources. Les locataires peuvent
également être déplacés entre les fragments pour équilibrer les charges de travail.

SQL Database fournit un outil de division/fusion qui fonctionne en conjonction avec

la bibliothèque de sharding et la base de données de catalogue. L'application fournie
peut diviser et fusionner des fragments, et elle peut déplacer les données des
locataires entre les fragments. L'application maintient également le catalogue
pendant ces opérations, marquant les locataires concernés comme hors ligne avant
de les déplacer. Après le déplacement, l'application met à jour le catalogue avec la
nouvelle correspondance et marque le locataire comme de retour en ligne.

2- Les bases de données plus petites sont plus faciles à gérer

En répartissant les locataires sur plusieurs bases de données, la solution multi-

locataire fragmentée donne lieu à des bases de données plus petites qui sont plus
faciles à gérer. Par exemple, restaurer un locataire spécifique à un moment antérieur
implique maintenant de restaurer une seule base de données plus petite à partir
d'une sauvegarde, plutôt qu'une plus grande base de données qui contient tous les
locataires. La taille de la base de données et le nombre de locataires par base de
données peuvent être choisis pour équilibrer la charge de travail et les efforts de
gestion.

3- Identifiant de locataire dans le schéma

Selon l'approche de sharding(fragmentation) utilisée, des contraintes

supplémentaires peuvent être imposées au schéma de la base de données.
L'application de division/fusion de SQL Database exige que le schéma inclue la clé de
sharding, qui est généralement l'identifiant du locataire. L'identifiant du locataire est
l'élément principal dans la clé primaire de toutes les tables fragmentées. L'identifiant
du locataire permet à l'application de division/fusion de localiser rapidement et
déplacer les données associées à un locataire spécifique.

4- Pool élastique pour les fragments

Les bases de données multi-locataires fragmentées peuvent être placées dans des
pools élastiques. En général, avoir de nombreuses bases de données dédiées à un seul
locataire dans un pool est aussi rentable que d'avoir de nombreux locataires dans
 quelques bases de données multi-locataires. Les bases de données multi-locataires
sont avantageuses lorsqu'il y a un grand nombre de locataires relativement inactifs.

VIII- Modèle hybride de base de données multi-locataire fragmentée

Dans le modèle hybride, toutes les bases de données ont l'identifiant du locataire dans
leur schéma. Les bases de données sont toutes capables de stocker plus d'un locataire, et
les bases de données peuvent être fragmentées. Ainsi, dans le sens du schéma, ce sont
toutes des bases de données multi-locataires. Cependant, en pratique, certaines de ces
bases de données ne contiennent qu'un seul locataire. Quoi qu'il en soit, la quantité de
locataires stockés dans une base de données donnée n'a aucun effet sur le schéma de la
base de données.

1- Déplacer des locataires

À tout moment, vous pouvez déplacer un locataire particulier vers sa propre base de
données multi-locataire. Et à tout moment, vous pouvez changer d'avis et déplacer le
locataire vers une base de données qui contient plusieurs locataires. Vous pouvez
également attribuer un locataire à une nouvelle base de données dédiée à un seul
locataire lors de la provision de la nouvelle base de données.

Le modèle hybride se distingue lorsque des différences importantes existent entre les
besoins en ressources de groupes de locataires identifiables. Par exemple, supposons
que les locataires participant à un essai gratuit ne bénéficient pas du même niveau
élevé de performances que les locataires abonnés. La politique pourrait être que les
locataires en phase d'essai gratuit soient stockés dans une base de données multi-
locataire partagée entre tous les locataires en essai gratuit. Lorsqu'un locataire en
essai gratuit s'abonne au niveau de service de base, le locataire peut être déplacé vers
une autre base de données multi-locataire qui pourrait avoir moins de locataires. Un
abonné payant pour le niveau de service Premium pourrait être déplacé vers sa
propre nouvelle base de données dédiée à un seul locataire.

2- Pools élastiques de bases de données

Dans ce modèle hybride, les bases de données dédiées à un seul locataire pour les
locataires abonnés peuvent être placées dans des pools de ressources pour réduire
les coûts de base de données par locataire. Cela est également fait dans le modèle de
base de données par locataire.
 PARTIE II : PRATIQUE
https://django-tenants.readthedocs.io/en/latest/index.html

Django tenant : Cette application permet aux sites web alimentés par Django d'avoir plusieurs
locataires via les schémas PostgreSQL. Une fonctionnalité essentielle pour chaque application web
en tant que service logiciel.

Django ne propose actuellement aucune manière simple de prendre en charge plusieurs locataires
en utilisant la même instance de projet, même lorsque seules les données diffèrent. Comme nous ne
voulons pas que vous exécutiez de nombreuses copies de votre projet, vous pourrez avoir :

- Plusieurs clients fonctionnant sur la même instance.

- Des données partagées et spécifiques à chaque locataire.

- Un routage de vue spécifique à chaque locataire.

1- Qu'est-ce que les schémas ?

Un schéma peut être envisagé comme un répertoire dans un système d'exploitation, chaque
répertoire (schéma) ayant son propre ensemble de fichiers (tables et objets). Cela permet
d'utiliser le même nom de table et les mêmes objets dans différents schémas sans conflit.

2- Pourquoi les schémas ?

Il existe généralement trois solutions pour résoudre le problème de la multi-locataire.

o Approche isolée : Bases de données séparées. Chaque locataire a sa propre

base de données.

o Approche semi-isolée : Base de données partagée, schémas séparés. Une

base de données pour tous les locataires, mais un schéma par locataire.

o Approche partagée : Base de données partagée, schéma partagé. Tous les

locataires partagent la même base de données et le même schéma. Il existe
une table principale des locataires, à laquelle toutes les autres tables font
référence via une clé étrangère.

Cette bibliothèque met en œuvre la deuxième approche, qui, selon nous, représente le
compromis idéal entre simplicité et performance.

Simplicité : apporte à peine des modifications à votre code actuel pour prendre en charge la
multi-locataire. De plus, vous ne gérez qu'une seule base de données.

Performance : utilise des connexions, des tampons et une mémoire partagée.

 Chaque solution a ses avantages et inconvénients.

3- Fonctionnement

Les locataires sont identifiés via leur nom d'hôte (c'est-à-dire locataire.domaine.com). Cette
information est stockée dans une table sur le schéma public. Chaque fois qu'une requête est
effectuée, le nom d'hôte est utilisé pour trouver un locataire dans la base de données. S'il y a
correspondance, le chemin de recherche est mis à jour pour utiliser le schéma de ce locataire.
Ainsi, à partir de maintenant, toutes les requêtes auront lieu dans le schéma du locataire. Par
exemple, supposez que vous ayez un locataire "client1" à http://client1.example.com. Toute
requête entrante à client1.example.com utilisera automatiquement le schéma du client et
rendra le locataire disponible pour la requête. Si aucun locataire n'est trouvé, une erreur 404
est générée. Cela signifie également que vous devriez avoir un locataire pour votre domaine
principal, utilisant généralement le schéma public.

Important

Le nom de domaine du locataire et le nom du schéma sont généralement les mêmes ou

similaires, mais cela n'est pas obligatoire ! Par exemple, le locataire à
http://acme.example.com pourrait être associé au schéma acme, tandis que http://looney-
tunes.tld pourrait être associé au schéma tenant2 ! Notez que les noms de domaine ne sont
en aucun cas liés aux noms de schéma ! Il n'y a également aucune restriction quant à
l'utilisation de sous-domaines ou de domaines de premier niveau.

Attention

Les règles de validation des noms de schéma et des noms de domaine sont différentes. Les
traits de soulignement (_) et les lettres majuscules sont autorisés dans les noms de schéma,
mais ils sont interdits pour les noms de domaine ! En revanche, les noms de domaine peuvent
contenir un tiret (-), ce qui est interdit pour les noms de schéma !

Vous devez être prudent si vous utilisez indifféremment les noms de schéma et les noms de
domaine dans vos applications multi-locataires ! Les classes de modèle pour les locataires et
les domaines, la création et la validation des données d'entrée sont des aspects que vous
devez gérer vous-même, imposant éventuellement des contraintes supplémentaires aux
valeurs acceptables !

4- Applications partagées et spécifiques à chaque locataire

1- Applications spécifiques à chaque locataire

La plupart de vos applications sont probablement spécifiques à chaque locataire, c'est-à-dire

que leurs données ne doivent pas être partagées avec d'autres locataires.

2- Applications partagées
 Une application est considérée comme partagée lorsque ses tables se trouvent dans le schéma
public.

Certaines applications ont du sens à être partagées. Supposons que vous ayez un ensemble
de données publiques, par exemple, une table contenant des données de recensement. Vous
voulez que chaque locataire puisse la consulter. Cette application contenant cette table sera
dans le schéma public au chemin de recherche, rendant ainsi ces applications toujours
disponibles pour tous locataires.

5- Installation et configuration

pip install django-tenants

Dans le fichier settings.py changer la configuration de la db

DATABASES = {
'default': {
'ENGINE': 'django_tenants.postgresql_backend',
'NAME': config('DB_NAME'),
'USER': config('DB_USER'),
'PASSWORD': config('DB_PASSWORD'),
'HOST': config('DB_HOST'),
'PORT': config('DB_PORT'),
}
}

Revoir le INSTALL APP

SHARED_APPS = (
'django_tenants', # mandatory
'clients', # you must list the app where your tenant model resides in

'django.contrib.contenttypes',

# everything below here is optional

'django.contrib.admin',
'django.contrib.auth',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
)

TENANT_APPS = (
# your tenant-specific apps
'courses',
)

INSTALLED_APPS = list(SHARED_APPS) + [app for app in TENANT_APPS if app not in

SHARED_APPS]
 Creer une app customers: django-admin startapp clients

Dans le fichier model de clients :

from django.db import models

from django_tenants.models import TenantMixin, DomainMixin

class Client(TenantMixin):
name = models.CharField(max_length=100)
on_trial = models.BooleanField()
created_on = models.DateField(auto_now_add=True)

class Domain(DomainMixin):
pass

Dans le fichier settings.py il faut referencer la table client et domain

TENANT_MODEL = "clients.Client" # app.Model

TENANT_DOMAIN_MODEL = "clients.Domain" # app.Model

Dans le setting toujours ajouter ceci dans le MIDDLEWARE

MIDDLEWARE = [
'django_tenants.middleware.main.TenantMainMiddleware',

Preciser le fichier des urls public

PUBLIC_SCHEMA_URLCONF = 'chemin_ici'

Configurer le routage des urls

DATABASE_ROUTERS = (
'django_tenants.routers.TenantSyncRouter'
)

Migrations
python manage.py makemigrations $$ python manage.py migrate_schemas --shared

Dans le fichier admin.py

from django.contrib import admin

from django_tenants.admin import TenantAdminMixin

from myapp.models import Client

@admin.register(Client)
class ClientAdmin(TenantAdminMixin, admin.ModelAdmin):
list_display = ('name', 'on_trial’)