Architecture multi-tenant en SaaS : trois approches et critères de choix

Dans les produits SaaS, une seule application sert un grand nombre de clients. Chaque client est appelé « locataire » (tenant) et doit être le seul à voir ses propres données. La manière de séparer les données des tenants est une décision d'architecture qui influe pendant des années sur le coût, la sécurité et la charge d'exploitation du produit.

Trois approches fondamentales

1. Base de données partagée, schéma partagé

Les données de tous les tenants résident dans les mêmes tables ; chaque ligne porte un champ indiquant à quel tenant elle appartient. Chaque requête est filtrée sur ce champ. C'est l'approche la plus simple à mettre en place et à exploiter, et la plus efficace en matière d'utilisation des ressources.

Le risque est qu'une seule requête où le filtrage a été oublié puisse afficher les données d'un autre tenant. Ce risque se réduit en rendant le filtrage obligatoire au niveau de la base de données plutôt qu'en le laissant au code applicatif ; la fonctionnalité de sécurité au niveau des lignes de PostgreSQL, par exemple, est utilisée à cette fin.

2. Base de données partagée, schéma distinct par tenant

Les tenants partagent le même serveur de base de données, mais les tables de chacun résident dans un schéma distinct. L'isolation est plus forte et il devient plus facile de restaurer les données d'un seul tenant à partir d'une sauvegarde. En contrepartie, à mesure que le nombre de tenants augmente, il devient plus difficile d'appliquer les modifications de schéma à tous les schémas.

3. Base de données distincte par tenant

Chaque tenant dispose de sa propre base de données. L'isolation est maximale ; l'utilisation intensive d'un tenant n'affecte pas les autres et des demandes telles que la conservation des données dans une région donnée peuvent être satisfaites. Le prix à payer est un coût d'infrastructure plus élevé et la charge d'exploitation qu'entraîne la gestion d'un grand nombre de bases de données.

Comparaison

Critère	Schéma partagé	Schéma distinct	Base de données distincte
Isolation des données	Logique	Plus forte	La plus forte
Coût par tenant	Le plus faible	Moyen	Le plus élevé
Modification de schéma	En une seule fois	Pour chaque schéma	Pour chaque base de données
Sauvegarde et restauration propres à un tenant	Difficile	Facile	Le plus facile
Grand nombre de petits tenants	Très adapté	Limité	Inadapté
Petit nombre de grands tenants (grands comptes)	Peut suffire	Adapté	Très adapté

Qu'est-ce qui détermine le choix ?

• Profil des clients : servirez-vous des milliers de petites entreprises ou un petit nombre de grandes organisations ?
• Exigences contractuelles et réglementaires : les clients exigent-ils que leurs données soient conservées de manière physiquement séparée ?
• Niveau de personnalisation : les tenants se contenteront-ils de modifier des paramètres, ou demanderont-ils des champs et des flux de travail qui leur sont propres ?
• Capacité de l'équipe : disposez-vous de la capacité d'exploitation nécessaire pour superviser et mettre à jour un grand nombre de bases de données ?

Le modèle hybride

Les approches peuvent aussi être utilisées ensemble. Une organisation courante consiste à conserver les clients des formules standard dans le schéma partagé et à proposer une base de données distincte aux clients grands comptes. Pour que cela soit possible, l'information de tenant doit être véhiculée dès le départ dans chaque couche de l'application.

Ce à quoi il faut penser au-delà de la base de données

• Identité et droits d'accès : on doit savoir avec certitude à quel tenant appartient chaque session ; si les utilisateurs peuvent être membres de plusieurs tenants, le passage de l'un à l'autre doit être conçu de manière sécurisée.
• Partage des ressources : l'utilisation intensive d'un seul tenant ne doit pas ralentir les autres. Les limites de requêtes et les quotas par tenant pour les tâches en arrière-plan sont utilisés à cette fin.
• Fichiers et cache : l'isolation doit être assurée non seulement dans la base de données, mais aussi dans le stockage de fichiers, le cache et l'index de recherche.
• Supervision : les journaux d'erreurs et de performance doivent contenir l'information de tenant ; à défaut, la question « quel client a été touché ? » reste sans réponse.

Pour la plupart des produits SaaS, le schéma partagé est le bon point de départ ; l'important est de le concevoir de façon à ne pas empêcher un passage ultérieur à une base de données distincte.

Pour planifier ensemble l'architecture de votre produit, vous pouvez consulter notre service de développement de produits SaaS.