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 !

FAITES DES BACKUPS !

icon Tags de l'article :

Octembre 13, 2022
Je suis de retour.



Il s'est passé beaucoup de choses ces dernières années. Genre pandémie, guerre Russie Ukraine, je suis devenu papa d'une petite fille il y a 2 semaines... de petits changements quoi.

Mais en ce qui nous/vous concerne ici : j'ai perdu mon blog.

Enfin pas tout, juste 5 ans d'historique...



J'ai perdu mon blog suite à un enchainement de coups de malchance (téléphone cassé, bloqué en réparation, expiration de l'hébergement, impossibilité de payer car pas de téléphone pour valider le paiement, carte de ma femme bloquée au même timing, ...)

Quand j'ai voulu voir avec mon hébergeur pour enfin le réactiver, quelques heures après l'expiration, ils m'ont dit que les données avaient été intégralement et irrémédiablement détruites (questions de sécurité).

Heureusement j'avais un backup, mais un backup de 2015. Sans aucun des articles 2016-2020...



Il m'a fallu 2 ans pour trouver le courage, l'énergie, la motivation et le temps de réactiver mon blog, et reprendre 1 à 1 tous les articles, en recheckant toutes les URLS. C'était plus fastidieux que compliqué, mais tellement démotivant.

Et on s'en veut d'avoir zappé les backups.

Et du coup, la morale de l'histoire... FAITES DES BACKUPS !

IMMEDIATEMENT.

MAINTENANT !

AUTOMATISEZ LES !

There are two kinds of people: those who backup, and those who have never lost all their data.