Architecture multi-tenant : guide pratique pour les architectes
Architecture multi-tenant : guide pratique pour les architectes L’architecture multi-tenant est une approche de conception logicielle dans laquelle une seule instance d’application sert plusieurs clients — appelés tenants — tout en maintenant les données et le comportement de chaque tenant isolés de ceux des autres.
Architecture multi-tenant : guide pratique pour les architectes
L’architecture multi-tenant est une approche de conception logicielle dans laquelle une seule instance d’application sert plusieurs clients — appelés tenants — tout en maintenant les données et le comportement de chaque tenant isolés de ceux des autres. Conclusion pratique pour le choix du modèle : considérez la tenancy comme une décision produit à plusieurs niveaux. Commencez par un modèle pool pour les clients sensibles aux coûts et présentant un risque moindre ; utilisez un modèle hybride ou bridge lorsque votre portefeuille de clients est hétérogène ; et provisionnez une infrastructure silo dédiée pour les clients grands comptes ou soumis à une réglementation qui exigent une isolation contractuelle.
Les trois principaux compromis auxquels chaque équipe doit faire face :
-
Isolation contre coût : Une isolation plus forte implique des ressources dédiées, donc des dépenses plus élevées par tenant.
-
Complexité contre flexibilité : Les modèles partagés sont moins coûteux à exploiter, mais exigent une application rigoureuse des contrôles au niveau applicatif pour empêcher les fuites de données.
-
Vitesse contre conformité : Les architectures en pool intègrent les tenants en quelques secondes ; les modèles en silo peuvent prendre de quelques minutes à plusieurs heures, mais répondent aux exigences des auditeurs et des équipes d’achats des grandes entreprises.
Table des matières
-
Liste de contrôle pour l’implémentation de systèmes multi-tenants
-
Sécurité et conformité dans les environnements multi-tenants
-
Comment faire évoluer une plateforme multi-tenant sans nuire aux performances ?
-
À quoi ressemblent les architectures de référence en pratique ?
-
Comment Ridiculous Engineering aborde l’architecture multi-tenant
-
Travailler avec Ridiculous Engineering sur votre plateforme multi-tenant
Que signifie réellement « multi-tenant » ?
Un tenant est une organisation, un compte ou une unité logique distincte représentant un client et partageant la plateforme. Une grande entreprise peut compter des milliers d’utilisateurs, mais ils appartiennent tous à un même tenant. La limite entre tenants est la séparation logique ou physique qui distingue les données, la configuration et le comportement d’un tenant de ceux d’un autre.
À l’inverse, une architecture single-tenant attribue à chaque client une instance d’application et une base de données dédiées. Les déploiements single-tenant sont plus simples à appréhender, mais coûteux à exploiter à grande échelle. Le multi-tenancy permet à une seule instance d’application de servir de nombreux clients ; c’est pourquoi la plupart des plateformes SaaS l’adoptent pour passer de dizaines à des milliers de clients sans réarchitecturer le système central.
Les objectifs commerciaux qui poussent les équipes vers le multi-tenancy sont constants : réduire le coût d’infrastructure par client, disposer d’une surface de déploiement unique pour les mises à jour et les correctifs, et diminuer la charge opérationnelle. Les objectifs techniques sont tout aussi constants : isoler les données entre tenants, router les requêtes en fonction du tenant, assurer une supervision par tenant et pouvoir appliquer des configurations ou des ensembles de fonctionnalités différents selon les comptes.
Quels sont les principaux modèles de tenancy ?
Recommandations d’AWS présentent l’isolation comme un continuum allant du modèle Silo au modèle Pool, avec des modèles Bridge intermédiaires. Cette représentation constitue le modèle mental le plus utile pour prendre des décisions d’architecture.
Silo (pile dédiée par tenant)
Chaque locataire dispose de sa propre pile applicative et de sa propre base de données. L’isolation est maximale : un bug, une faille ou une charge de travail excessive chez un locataire ne peut pas affecter les autres. Les auditeurs de conformité apprécient ce modèle, car la résidence des données et les contrôles d’accès sont faciles à démontrer. Le coût est toutefois réel. Les frais généraux d’infrastructure augmentent linéairement avec le nombre de locataires, et la complexité opérationnelle croît à chaque nouveau déploiement. La restauration par locataire est simple, car chaque base de données est déjà limitée à un seul client.
Schéma par locataire (base de données partagée, schémas séparés)
Tous les locataires partagent un moteur de base de données, mais chacun dispose de son propre schéma. Ce modèle se situe entre le silo et le modèle entièrement mutualisé : il offre une séparation logique significative sans le coût d’instances de bases de données distinctes. Le modèle par schéma convient lorsque le nombre de locataires se compte en centaines plutôt qu’en milliers, car la prolifération des schémas finit par créer des difficultés liées aux migrations et à la mise en pool des connexions. Les migrations de schéma en ligne nécessitent une gestion rigoureuse des versions afin d’éviter de verrouiller plusieurs locataires simultanément.
Schéma partagé (isolation au niveau des lignes)
Une base de données, un schéma, et les lignes de chaque locataire coexistent dans les mêmes tables. Il s’agit du modèle le moins coûteux, mais aussi de celui qui exige le plus de rigueur. La sécurité au niveau des lignes nécessite un filtre tenant_id sur chaque lecture et chaque écriture. Oubliez une seule requête et vous provoquez une fuite de données. Les politiques de sécurité au niveau des lignes (RLS) de PostgreSQL ou un intergiciel au niveau de l’application peuvent appliquer cette règle automatiquement, mais le risque d’un filtre manquant est réel et ses conséquences sont graves.
Modèles passerelle et hybrides
Un modèle passerelle associe un calcul mutualisé à différents degrés d’isolation du stockage. Un schéma courant consiste à partager le niveau applicatif tout en utilisant des bases de données distinctes par locataire pour le stockage. Le modèle Deployment Stamps d’Azure va plus loin en déployant une infrastructure dédiée pour un locataire ou un groupe de locataires, puis en augmentant la capacité par l’ajout de stamps. Les stamps peuvent être mono-locataires ou multilocataires, offrant aux équipes une voie de mise à niveau claire lorsqu’un locataire mutualisé dépasse les ressources partagées.
Comparaison des modèles de multi-location
| Dimension | Silo | Schéma par locataire | Schéma partagé | Passerelle/hybride |
|---|---|---|---|---|
| Niveau d’isolation | Fort (physique) | Modéré (logique) | Faible (appliqué par l’application) | Configurable |
| Coût par locataire | Élevé | Moyen | Faible | Moyen-élevé |
| Complexité de mise en œuvre | Élevée (frais généraux opérationnels) | Moyenne | Faible à moyenne | Élevée |
| Évolutivité | Croissance linéaire des coûts | Des centaines de locataires | Des milliers de locataires | Flexible |
| Adéquation aux exigences de conformité | Excellente | Bonne | Nécessite des preuves | Bon-Excellent |
| Capacité de personnalisation | Complète | Élevée | Limitée | Élevée |
Conseil de pro : Ne considérez pas ce tableau comme une réponse définitive. La plupart des plateformes en production finissent par utiliser au moins deux modèles simultanément : le modèle mutualisé pour les niveaux standard, et le modèle en silo ou par estampillage pour les contrats d’entreprise. Concevez vos abstractions pour prendre en charge les deux dès le premier jour.
Comment choisir le bon modèle de mutualisation ?
La décision n’est pas purement technique. Considérer la mutualisation comme une fonctionnalité produit — quelque chose que vous tarifez et conditionnez — distingue les plateformes qui captent les revenus des entreprises de celles qui les laissent passer.
Évaluez ces critères dans l’ordre suivant :
-
Exigences réglementaires et de conformité. Si certains locataires sont soumis à la loi HIPAA, à la norme PCI DSS ou à des audits SOC 2 Type II, commencez par un silo ou un schéma par locataire pour ces comptes. L’isolation par schéma partagé est difficile à auditer de manière convaincante.
-
Résidence contractuelle des données. Les clients entreprises exigent de plus en plus que les données restent dans des limites géographiques précises. Les modèles en silo ou par estampillage rendent cela simple ; les modèles à schéma partagé nécessitent des contrôles rigoureux au niveau de la base de données.
-
Engagements de niveau de service pour les entreprises. Si vous promettez une disponibilité de 99,9 % ou plus avec des plages de support dédiées, un voisin bruyant dans un modèle mutualisé met en péril le niveau de service.
-
Sensibilité au prix de votre clientèle. Les PME et les clients en libre-service paient rarement suffisamment pour justifier une infrastructure dédiée. Commencez par un modèle mutualisé pour ces segments.
-
Maturité de l’équipe et niveau d’automatisation. Les modèles en silo nécessitent une automatisation mature de l’infrastructure. Si votre équipe ne peut pas provisionner une nouvelle pile pour un locataire en moins de cinq minutes, sans aucune étape manuelle, la surcharge opérationnelle vous pénalisera.
-
Variabilité de la charge de travail. Les charges de travail très variables ou sujettes à des pics bénéficient de ressources mutualisées, car des charges non corrélées réduisent les écarts entre les moyennes et les pics. Les locataires prévisibles et à fort volume sont de meilleurs candidats pour des ressources dédiées.
Le flux de décision pratique est le suivant : commencez par un modèle mutualisé si le profil de vos clients est inconnu ou dominé par les PME. Passez à un modèle hybride dès que vous signez votre premier client entreprise ayant des exigences d’isolation. Réservez le modèle entièrement en silo aux secteurs réglementés ou aux clients ayant des obligations contractuelles de résidence des données.
Conseil de pro : Évitez le piège du tout ou rien. Les plateformes qui s’engagent pour un modèle de mutualisation unique pour tous leurs clients dépensent trop pour isoler les comptes à faible valeur ou perdent des contrats d’entreprise parce qu’elles ne peuvent pas proposer d’infrastructure dédiée. Intégrez votre niveau de mutualisation à votre modèle tarifaire dès le départ, même si vous ne disposez aujourd’hui que d’un seul niveau.
Les équipes qui commencent avec un modèle entièrement mutualisé pour réduire les coûts rencontrent souvent des problèmes de voisin bruyant, coûteux à corriger par la suite. Commencer avec un modèle hybride — mutualisé pour les niveaux inférieurs, isolé pour les entreprises — évite le coût de cette réarchitecture. Aligner les décisions de mutualisation sur les objectifs métier dès le début fait partie des décisions à plus fort effet de levier qu’une équipe d’architecture puisse prendre.
Liste de contrôle de mise en œuvre pour les systèmes mutualisés
Définir correctement le modèle d’architecture représente la moitié du travail. L’autre moitié réside dans la rigueur d’ingénierie nécessaire à sa mise en œuvre correcte. Voici les éléments fondamentaux qui comptent le plus.
Identité et routage des locataires
-
Attribuez à chaque locataire un
tenant_idstable et immuable lors de sa création, et traitez-le comme un élément de première classe à chaque niveau de la pile. -
Propagez le contexte du locataire tout au long du cycle de vie de la requête : les en-têtes HTTP, les intergiciels, les connexions à la base de données et les files d’attente de tâches asynchrones doivent tous le transmettre.
-
Utilisez le routage par sous-domaine (
tenant.app.com), le routage fondé sur le chemin (/api/tenant/{id}/), ou des revendications JWT pour résoudre l’identité du locataire à la périphérie avant que la requête n’atteigne la logique applicative.
Partitionnement des données et regroupement des connexions
-
Pour les modèles à schéma partagé, appliquez automatiquement les filtres
tenant_idau niveau de la couche d’accès aux données, et non au niveau de l’appelant. L’intégration en dur de la logique de gestion des locataires au niveau de l’appelant crée des failles de sécurité subtiles et une dette de maintenance. -
Utilisez PgBouncer ou un outil similaire de regroupement des connexions pour gérer efficacement les connexions à la base de données entre de nombreux locataires ; des limites de connexions par locataire empêchent un locataire d’épuiser le pool.
-
Pour les modèles avec un schéma par locataire, automatisez la création et la suppression des schémas dans le cadre du cycle de provisionnement et de retrait.
Authentification et autorisation
-
Prenez en charge les fournisseurs d’identité propres à chaque locataire : les clients professionnels voudront utiliser leur propre fournisseur SAML ou OIDC.
-
Appliquez des rôles et des autorisations limités au locataire afin qu’un utilisateur authentifié dans le locataire A ne puisse pas accéder aux ressources du locataire B, même avec un jeton valide.
-
Utilisez des outils comme Auth0, Okta ou AWS Cognito avec des revendications tenant-aware pour éviter de créer une infrastructure d’identité à partir de zéro.
Provisionnement et migrations
-
Automatisez entièrement le provisionnement des locataires. Si le provisionnement nécessite des écritures manuelles de schémas ou des interventions humaines, le système est en réalité multi-instance, et non multitenant.
-
Versionnez toutes les migrations de schéma et appliquez-les de manière rétrocompatible afin de pouvoir déployer des modifications auprès de milliers de locataires sans interruption de service.
-
Tenez à jour un registre des locataires (un magasin de métadonnées) qui suit le niveau de service, la configuration, l’état du provisionnement et les ressources attribuées à chaque locataire.
Sauvegardes, reprise après sinistre et mesure de la consommation
-
Définissez des SLA de reprise propres à chaque locataire et testez les procédures de restauration pour chaque locataire, et pas uniquement les restaurations complètes de la base de données.
-
Collectez dès le premier jour les métriques d’utilisation propres à chaque locataire (appels d’API, stockage, calcul) et intégrez-les à votre système de facturation. Des plateformes comme Manaxo montrent concrètement comment les produits SaaS associent les données d’utilisation aux niveaux de facturation.
-
Appliquez des quotas et des limites de débit par locataire afin de protéger les ressources partagées.
CI/CD et stratégie de mise en production
-
Utilisez des indicateurs de fonctionnalité pour déployer les modifications progressivement auprès d’un sous-ensemble de locataires avant le déploiement général. C’est la manière la plus sûre de tester les personnalisations propres à certains locataires sans mettre en danger l’ensemble du parc.
-
Automatisez les pipelines CI/CD pour déployer la configuration propre à chaque locataire avec le code applicatif.
-
Antipatronymes à éviter : logique de gestion des locataires codée en dur dans le code applicatif, étapes de provisionnement manuelles et observabilité insuffisante par locataire.
Conseil de pro : Instrumentez votre système afin qu’il émette des métriques et des journaux étiquetés par locataire dès le premier jour du développement. Ajouter l’observabilité après coup à une plateforme multitenant en production est pénible et coûteux. La journalisation tenant-aware n’est pas facultative — c’est le seul moyen de déboguer les problèmes de production sans exposer les données d’un locataire lors de l’investigation des problèmes d’un autre.
Sécurité et conformité dans les environnements multitenant
La sécurité multitenant ne repose pas sur un contrôle unique. Il s’agit d’un ensemble de décisions en couches qui se cumulent dans toute l’architecture.
-
Chiffrement au repos et en transit : Chiffrez toutes les données des locataires au repos avec AES-256 ou un équivalent, et imposez TLS 1.2 ou une version ultérieure pour toutes les données en transit. Pour les locataires fortement réglementés, envisagez un chiffrement au niveau des champs pour les colonnes sensibles afin que même les administrateurs de bases de données ne puissent pas lire les valeurs brutes.
-
IAM limité au locataire : Appliquez des contrôles d’accès selon le principe du moindre privilège à chaque couche. Les politiques IAM du cloud, les rôles de base de données et les autorisations applicatives doivent tous être limités au locataire. Aucun accès inter-locataires ne doit être possible par les chemins applicatifs normaux.
-
Journalisation des audits : Ajoutez à chaque entrée de journal l’identifiant
tenant_id, stockez les journaux dans un système inviolable (AWS CloudTrail, Azure Monitor Logs) et conservez-les pendant la durée exigée par la réglementation applicable. Les auditeurs SOC 2 vous le demanderont. -
Résidence des données : Pour les exigences américaines de résidence des données, utilisez l’ancrage à une région cloud et confirmez que les services gérés (sauvegardes, réplicas, exportations analytiques) restent également dans la région requise. Les modèles en silo et par estampille facilitent cette démonstration.
-
PCI DSS : Les données des titulaires de carte doivent être isolées. Un modèle à schéma partagé n’est pas une solution viable pour le périmètre PCI sans contrôles compensatoires importants. Le choix pratique consiste à utiliser un silo ou un schéma par locataire.
-
HIPAA : Les informations de santé protégées nécessitent un accord de partenaire commercial avec votre fournisseur cloud ainsi que des contrôles d’accès démontrables. Des clés de chiffrement et des journaux d’audit par locataire constituent les exigences de base.
-
Confinement des violations : Concevez les limites entre locataires de sorte qu’un identifiant d’application compromis ne puisse pas franchir ces limites. Des clés de chiffrement par locataire signifient qu’une compromission de clé affecte un seul locataire, et non l’ensemble d’entre eux.
-
Réponse aux incidents : Maintenez des procédures d’intervention par locataire afin que votre équipe d’astreinte puisse isoler, examiner et restaurer un seul locataire sans affecter les autres. Résilience opérationnelle la planification doit inclure des scénarios d’incident propres à chaque locataire.
Cet article fournit des conseils techniques généraux et ne constitue pas un avis juridique ou de conformité. Confirmez vos obligations réglementaires spécifiques auprès d’un conseiller juridique qualifié et de votre équipe de conformité.
Comment faire évoluer une plateforme mutualisée sans nuire aux performances ?
La mise à l’échelle d’une plateforme mutualisée concerne moins la capacité brute que la protection des locataires les uns vis-à-vis des autres, tout en maintenant des coûts prévisibles.
-
Regroupez les charges de travail non corrélées. Le regroupement de locataires dont les profils d’utilisation sont différents aplanit les ratios de charge maximale sur charge moyenne entre les ressources mutualisées. Un locataire dont le pic survient le lundi matin associé à un autre dont le pic survient le vendredi après-midi constitue un meilleur pool que deux locataires connaissant des pics identiques le lundi matin. Il s’agit de l’une des décisions de planification de capacité offrant le plus fort effet de levier aux équipes de plateforme.
-
Quotas et limitation du débit par locataire. Appliquez des limites de débit d’API, des limites de temps d’exécution des requêtes et des quotas de stockage par locataire. Lorsqu’un locataire atteint une limite, ralentissez ou mettez ses requêtes en file d’attente au lieu de les laisser dégrader le pool. Il s’agit de la principale mesure d’atténuation du problème du voisin bruyant.
-
Escalade de la topologie. Lorsqu’une charge de travail dépasse systématiquement ce que la limitation peut contenir, déplacez le locataire vers un niveau de ressources dédié. Il ne s’agit pas d’un échec de l’architecture, mais du parcours de mise à niveau qui fonctionne comme prévu.
-
Mise à l’échelle automatique et serverless. Le calcul serverless (AWS Lambda, Azure Functions) gère bien les charges variables pour les niveaux mutualisés, car vous payez par invocation plutôt que par instance provisionnée. Pour les déploiements par estampille, les groupes à mise à l’échelle automatique dotés d’une capacité préchauffée gèrent la croissance prévisible. Consultez les modèles de mise à l’échelle de l’infrastructurepour obtenir des conseils pratiques sur la préparation aux charges élevées.
-
Mise à l’échelle de la base de données. Le regroupement des connexions est essentiel à grande échelle. Pour les modèles à schéma partagé, une seule instance PgBouncer peut gérer des milliers de connexions de locataires vers un petit nombre de connexions réelles à la base de données. Pour un schéma par locataire, Aurora Serverless ou des bases de données gérées similaires réduisent le coût des schémas inactifs.
-
Métriques et attribution des coûts par locataire. Instrumentez la plateforme afin d’attribuer les coûts de calcul, de stockage et de réseau à chaque locataire. Ces données orientent les décisions tarifaires et identifient les locataires dont l’utilisation ne couvre pas le coût de leur infrastructure.
Comment gérez-vous l’ensemble du cycle de vie des locataires ?
La gestion des locataires est une fonctionnalité produit, et pas seulement une préoccupation technique. Le cycle de vie, de l’intégration à la désactivation, doit être géré avec autant de soin que toute autre fonctionnalité du produit.
-
Provisionnement sans intervention : Les locataires mutualisés doivent être entièrement provisionnés en quelques secondes au moyen d’un pipeline automatisé : créer l’enregistrement du locataire, attribuer
tenant_id, appliquer la configuration par défaut et envoyer les identifiants de bienvenue. Aucune intervention humaine. Automatiser l’intégration est ce qui distingue une plateforme d’un ensemble d’instances gérées manuellement. -
Artefacts de provisionnement : Chaque événement de provisionnement d’un locataire doit produire un ensemble complet d’artefacts : création du schéma ou de la base de données, blobs de configuration, secrets stockés dans un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault), clés API et entrée dans le registre des métadonnées des locataires.
-
Mises à niveau et migrations de niveau :Définissez un parcours de mise à niveau clair pour faire passer un locataire du modèle mutualisé au modèle un schéma par locataire, puis à la base de données dédiée et enfin au silo complet. Chaque étape doit être automatisée et testée. Les recommandations d’Azure sur les modèles de mutualisation décrivent comment les plateformes performantes utilisent des niveaux mutualisés pour les utilisateurs standard et des unités isolées pour les clients d’entreprise, et ce modèle nécessite un parcours de migration testé entre les niveaux.
-
Gestion des personnalisations :Utilisez des indicateurs de fonctionnalité (LaunchDarkly, Unleash ou un système interne de gestion des indicateurs) pour gérer la disponibilité des fonctionnalités selon les locataires. Stockez la configuration des locataires dans un magasin de configuration dédié, et non dans le code de l’application. Les points d’extension doivent être clairement définis et isolés dans un bac à sable.
-
Facturation et mesure de l’utilisation :Collectez en continu les métriques d’utilisation et associez-les aux niveaux de facturation. Pour les produits SaaS réglementés, des plateformes comme Intelligent Assessmentsmontrent comment une tarification par niveaux s’applique à des segments de clients sensibles aux exigences de conformité. Appliquez des quotas stricts avant la clôture des cycles de facturation afin d’éviter les dépassements inattendus.
-
Sortie de service :Définissez un processus de suppression des locataires qui supprime ou archive toutes les données du locataire, révoque les identifiants, libère les ressources et produit un enregistrement d’audit de la suppression. Le RGPD et le CCPA exigent tous deux une suppression des données démontrable sur demande.
À quoi ressemblent concrètement les architectures de référence ?
Recommandations AWS sur les architectures mutualisées
Les recommandations AWS pour les architectures mutualisées organisent l’espace de conception autour du continuum Silo/Bridge/Pool. Dans une architecture AWS mutualisée, les locataires partagent le calcul ECS ou Lambda, un cluster RDS ou Aurora unique et une API Gateway partagée avec des autorisateurs tenant compte du locataire. Dans une architecture en silo, chaque locataire dispose de son propre VPC, de sa propre instance RDS et de sa propre frontière de rôle IAM. Le modèle Bridge partage généralement le calcul (tâches ECS ou Lambda) tout en isolant le stockage (instances RDS par locataire ou préfixes S3 avec des politiques de compartiment).
AWS recommande d’utiliser Amazon Cognito avec des attributs personnalisés pour gérer l’identité en fonction du locataire, AWS IAM pour l’isolation au niveau des ressources dans les modèles en silo, et Amazon CloudWatch avec des métriques étiquetées par locataire pour l’observabilité dans tous les modèles.
Unités de déploiement Azure
Le Centre d’architecture Azure de Microsoft décrit le modèle des unités de déploiement comme un moyen de faire évoluer les plateformes mutualisées en déployant des unités d’infrastructure autonomes. Une unité peut servir un locataire d’entreprise (unité mono-locataire) ou un groupe de locataires mutualisés (unité multilocataire). L’ajout de capacité consiste à ajouter des unités, et non à faire évoluer un cluster monolithique partagé. Cette approche offre aux équipes de solides garanties d’isolation tout en conservant la possibilité de regrouper les petits locataires au sein d’une même unité.
Salesforce comme exemple de référence
Salesforce est l’exemple le plus souvent cité de mutualisation à grande échelle dans le SaaS d’entreprise. La plateforme sert des centaines de milliers d’organisations sur une infrastructure partagée grâce à une combinaison d’isolation au niveau de l’application, de métadonnées propres à chaque locataire et d’un moteur de requêtes propriétaire qui impose les frontières entre locataires au niveau de l’accès aux données. La principale leçon de l’architecture de Salesforce ne concerne pas une technologie particulière, mais un principe : l’isolation des locataires doit être imposée au niveau des données, et non laissée à la mémoire de chaque développeur au point d’appel.
SAP BTP et les plateformes d’entreprise
L’architecture de référence de SAP pour le SaaS mutualisé sur BTPsuit des principes similaires : isolation des locataires, intégration et retrait automatisés, partage des ressources avec des contrôles de gouvernance et configuration au niveau du locataire pour les extensions d’entreprise. Les plateformes d’entreprise convergent systématiquement vers les mêmes modèles, quelle que soit la pile technologique sous-jacente.
Comment Ridiculous Engineering aborde l’architecture mutualisée
Ridiculous Engineering est un cabinet de conseil en ingénierie logicielle basé au Colorado, qui a conçu et livré des plateformes mutualisées en production pour des clients issus de secteurs réglementés, des startups SaaS et des équipes de logiciels d’entreprise. Notre processus est méthodique et commence par une phase de découverte avant de choisir un modèle.
Notre intervention type suit cette séquence :
-
Découverte et cartographie des contraintes :Nous documentons les objectifs de niveau de service, les exigences de conformité (HIPAA, PCI, SOC 2), l’échelle prévue des locataires à 12 et 36 mois, les exigences de personnalisation et le niveau de maturité de l’équipe en matière d’automatisation. Ces éléments déterminent le modèle de mutualisation initial.
-
Choix du modèle de mutualisation et conception de l’architecture :Nous recommandons un modèle initial et définissons le parcours de mise à niveau. Pour la plupart des clients, cela signifie commencer avec un modèle mutualisé, avec un parcours de migration défini vers un schéma par locataire ou un silo pour les comptes d’entreprise.
-
Automatisation et approvisionnement :Nous construisons des pipelines d’approvisionnement des locataires sans intervention avant d’écrire les fonctionnalités de l’application. L’approvisionnement est un livrable d’ingénierie de premier ordre, et non une tâche secondaire.
-
Mise en œuvre par étapes :Nous mettons en œuvre les contrôles de mutualisation au niveau de l’accès aux données, et non au point d’appel, puis les validons avec des tests automatisés qui simulent des tentatives d’accès inter-locataires.
-
Guide opérationnel et transfert aux équipes d’exploitation :Nous fournissons des guides opérationnels documentés pour l’intégration des locataires, les mises à niveau de niveau, la réponse aux incidents et la sortie de service, afin que votre équipe puisse exploiter la plateforme de manière autonome.
Notre travail sur la plateforme CMS de Consusillustre comment une réflexion au niveau de la plateforme sur l’isolation des locataires et l’architecture cloudse traduit par des systèmes en production qui évoluent sans refonte de l’architecture. Nous évaluons les mêmes contraintes lors de chaque intervention : contrôles de conformité, échelle prévue des locataires, profondeur des personnalisations et capacité de l’équipe à exploiter ce que nous construisons.
Points clés
Considérez la mutualisation comme une décision produit à plusieurs niveaux : commencez par un modèle mutualisé pour maîtriser les coûts, ajoutez des niveaux d’isolation lorsque les exigences de conformité et des entreprises l’imposent, et automatisez chaque étape du cycle de vie des locataires dès le premier jour.
| Point | Détails |
|---|---|
| Commencer avec un modèle mutualisé, prévoir l’isolation | Commencez avec un modèle à schéma partagé ou mutualisé pour les clients PME et définissez le chemin de mise à niveau vers le cloisonnement avant d’en avoir besoin. |
| Appliquer tenant_id au niveau des données | Appliquez automatiquement les filtres de locataire au niveau de l’accès aux données, et non dans chaque point d’appel, afin d’éviter les fuites de données. |
| Automatiser complètement le provisionnement | Des étapes de provisionnement manuelles signifient que vous avez plusieurs instances, et non un environnement multitenant ; l’intégration en un clic est une exigence de base non négociable. |
| Instrumenter tôt les métriques par locataire | Associez tenant_id aux journaux et aux métriques dès le premier jour ; intégrer l’observabilité a posteriori dans une plateforme en production est coûteux et sujet aux erreurs. |
| Ridiculous Engineering conçoit cela | Ridiculous Engineering crée des plateformes multitenant de production avec provisionnement automatisé, isolation par niveaux et architecture prête pour la conformité. |
Sources utiles et lectures complémentaires
Les architectes souhaitant approfondir les détails de mise en œuvre disposent de plusieurs références faisant autorité à ajouter à leurs favoris :
-
Recommandations AWS pour les architectures multitenant : La référence AWS principale sur le continuum Silo/Bridge/Pool, avec des architectures d’exemple, des constructions CDK et des recommandations sur la gestion des identités des locataires à l’aide d’Amazon Cognito.
-
Azure Architecture Center : solutions multitenant : Série complète de Microsoft couvrant les considérations architecturales, les tampons de déploiement, les recommandations propres à chaque service et une liste de contrôle pratique pour la mise en œuvre de plateformes multitenant hébergées sur Azure.
-
Modèles de tenancy Azure : Recommandations ciblées pour choisir entre les modèles de tenancy, avec une analyse des compromis et des recommandations concernant le chemin de mise à niveau.
-
Shopify : bonnes pratiques en matière d’architecture multitenant : Vue d’ensemble destinée aux praticiens sur la façon dont les développeurs d’applications passent de quelques dizaines à plusieurs milliers de marchands, avec des modèles de mise en œuvre concrets.
-
SAP Architecture Center : SaaS multitenant sur BTP : Architecture de référence axée sur les entreprises, couvrant l’isolation des locataires, l’intégration, la gouvernance des ressources et la gestion de la configuration pour les extensions SAP BTP.
-
Ressources Ridiculous Engineering : Pour obtenir de l’aide à la mise en œuvre, consulter des études de cas et bénéficier de missions d’architecture, consultez ridiculousengineering.com.
Collaborer avec Ridiculous Engineering sur votre plateforme multitenant
Construire correctement une plateforme multitenant dès le départ coûte moins cher que de corriger une plateforme mal conçue. La décision architecturale la plus coûteuse que prennent la plupart des équipes consiste à s’engager dans un modèle de tenancy unique sans chemin de migration, puis à découvrir deux ans plus tard que leur pipeline d’entreprises exige une isolation dédiée qu’elles sont incapables de fournir.
Ridiculous Engineering’s développement de logiciels sur mesureLa pratique est précisément axée sur ce type de travail d’architecture : d’abord la découverte, guidée par les contraintes, et livrée avec l’automatisation et la documentation dont votre équipe a besoin pour l’exploiter durablement. Nous travaillons avec des startups SaaS, des plateformes en pleine croissance et des entreprises établies dans le Colorado et au-delà. Si vous concevez un nouveau système multitenant ou modernisez un système existant, le bon moment pour définir correctement l’architecture est avant que le premier client entreprise ne demande une isolation dédiée. Contactez-nous pour entamer une discussion sur les exigences de tenancy de votre plateforme.
FAQ
Quel est un exemple d’application multitenant ?
Salesforce est l’exemple le plus souvent cité : des centaines de milliers d’organisations partagent la même infrastructure applicative, l’isolation des locataires étant appliquée au niveau de l’accès aux données. Shopify suit le même modèle pour les marchands de commerce électronique.
Quels sont les principaux inconvénients d’une architecture multitenant ?
Les principaux inconvénients sont le risque de « voisin bruyant » (la charge de travail d’un locataire dégrade les performances des autres), la complexité accrue de l’application due au filtrage et au routage tenant-aware, ainsi que la difficulté à démontrer l’isolation aux auditeurs de conformité dans les modèles à schéma partagé.
Quelle est la différence entre une architecture single-tenant et multitenant ?
Dans une architecture single-tenant, chaque client dispose d’une instance d’application et d’une base de données dédiées. Dans une architecture multitenant, une seule instance d’application sert plusieurs clients, l’isolation étant assurée par la logique applicative, la séparation des schémas ou les frontières physiques des ressources, selon le modèle choisi.
Que signifie l’architecture multitenant dans Salesforce ?
Salesforce utilise un modèle d’infrastructure partagée dans lequel toutes les organisations clientes s’exécutent sur la même plateforme applicative. L’isolation des locataires est assurée par un moteur de requêtes propriétaire piloté par les métadonnées, qui restreint automatiquement chaque opération sur les données à l’organisation à l’origine de la demande, rendant tout accès aux données d’un autre locataire impossible via les chemins applicatifs normaux.
Quand faut-il utiliser un modèle en silo plutôt qu’un modèle mutualisé ?
Utilisez un modèle en silo lorsqu’un locataire est soumis à des exigences réglementaires (HIPAA, PCI DSS), à des obligations contractuelles de résidence des données ou à des engagements de niveau de service d’entreprise que l’infrastructure partagée ne peut pas garantir de manière fiable. Pour la plupart des clients PME ou en libre-service, un modèle mutualisé constitue le choix par défaut le plus économique.