Architecture multi-tenant partie 1 : présentation

icon Tags de l'article : , ,

Octembre 22, 2022
En anglais, tenant signifie locataire. Donc architecture multitenant = architecture multi-locataires.

La plupart du temps, lorsqu'on développe une application destinée à plusieurs clients, on va avoir tendance à concevoir une (et une seule) appli web, qu'on déploiera ensuite pour chaque client, chaque client/appli ayant sa propre BDD.



Cette approche simplifie le développement, mais elle va complexifier :
  • le déploiement
  • les mises à jour
  • la maintenance
  • le débogage
  • les backups

Ce qui fait qu'on a vite beaucoup à faire niveau infra/ops :



Ces opérations, quand on a 1 ou 2 clients, sont faciles à gérer manuellement. Mais quand on commence à arriver à 10, 20, 50, ... clients, ben vous voyez vite où ça nous mène :


Du coup on doit automatiser ces opérations. Ce qui demande des compétences ops/devops assez poussées. Et même en automatisant un maximum (procédures, provisionning, scripts, monitoring, ...), ben vous aurez très souvent à intervenir manuellement, ne serait-ce que pour lancer les opérations à chaque nouveau client.

En résumé, plus vous aurez de clients, plus vous aurez besoin d'une équipe ops conséquente et compétente. Ce qui va créer de gros problèmes de scaling humain dans votre structure. Ca plus les problématiques de synchronisation/management.

Et bien sachez qu'il existe une solution applicative à ça : l'architecture multi-tenant.

En quoi ça consiste ? C'est assez simple à expliquer : vous avez une seule application web déployée, et une seule base de données, pour tous vos clients.



Là vous vous dites : euh ouais mais ça peut pas être si simple. En effet, techniquement il va y avoir pas mal de choses à implémenter.

Déjà, il y a trois façons de faire :
  • colonne personnalisée : sur chaque table on va créer une colonne "tenant" ou "tenantId" qui servira à filtrer par tenant dans toutes les requêtes
  • BDD séparées : une seule application web, mais chaque client a sa propre BDD
  • schémas séparés : on crée différents schémas en BDD, et chaque client a son propre schéma et ses propres tables

Chaque solution a ses avantages et inconvénients.
La solution colonne personnalisée permet d'avoir un multitenant complet mais demande beaucoup de rigueur niveau code et architecture applicative.
La solution de BDD séparées oblige à créer/mettre à jour/backuper X BDD, 1 par client.
La solution de schémas séparés oblige à créer des tables pour chaque client, ce qui va rendre compliqué la partie investigation/débug.

Dans cette série d'articles, je vais me concentrer sur l'approche colonne personnalisée, afin d'avoir à m'occuper le moins possible des systèmes.

Si on devait imaginer un postulat de départ : vendre une suite applicative à plein de clients, sans augmenter ma charge de travail même si je passe de 10 clients à 100.

Pour ça, le fonctionnement implémenté est simple :
  • quand une requête arrive, en fonction du nom de domaine/de l'url/d'un autre paramètre dans les headers, on va filtrer les données de la BDD, afin de ne renvoyer que les données concernant ce client.
  • Et quand le client crée un objet, on ajoute une information sur l'objet pour indiquer à quel client appartient cette donnée.

Ainsi, les clients ne peuvent pas accéder aux données des autres clients. Quoi qu'il arrive, chaque client a sa propre portion de données et n'a pas accès aux données des autres.


Comme on le voit ici, chaque client verra une application différente et des données différentes, alors qu'ils utilisent la même infrastructure.

Evidemment, cette approche a ses avantages, et des défauts.

Avantages :
  • 0 problèmes de scaling humain
  • 1 seule application web et 1 seule BDD à déployer/mettre à jour/backuper/monitorer
  • débogage simplifié

Inconvénients :
  • limitations charge (si vous avez trop de clients votre BDD risque de ne pas suivre)
  • potentiellement bloquant pour certains marchés qui imposent un hébergement des données indépendant

Neutre :
  • sécurité : beaucoup de gens diraient "oui mais si ta BDD fuite ils récupèrent les données de tous tes utilisateurs", mais soyons honnêtes, même avec des BDD séparées, quand t'as une fuite d'infos, toutes les infos de tous les clients fuitent la plupart du temps car la sécurité ne diffère pas entre les clients
  • technique : le code va est plus compliqué au départ, mais une fois la base posée, on ne voit "presque" plus la différence avec une application classique

Malgré ses défauts, je pense qu'une architecture multi-tenant vaut vraiment la peine d'être mise en place lorsqu'on sort un produit SAAS et qu'on veut se simplifier la vie sur le long terme.

On va arrêter là pour l'instant, dans le prochain article je pense me concentrer sur l'implémentation.

D'ici là... bon dev à vous !

Commentaires fermés

icon Flux RSS des commentaires de cet article

Les commentaires sont fermés pour cet article