Noyau multi-tenant

Le noyau multi-tenants est une couche de base de plate-forme/produit qui sert de nombreux clients indépendants (tenants) sur des ressources partagées avec une isolation garantie, des limites gérables et une personnalisation sûre. Un noyau bien conçu réduit le TCO, accélère l'onbording, simplifie les sorties et assure une qualité prévisible pour chaque locataire.

1) Modèle de locataire et limites d'isolation

Définitions

Tenant (Tenant/Org/Account) : organisation logique avec ses propres utilisateurs, données, politiques et limites.
Isolation : capacité à prévenir l'impact d'un locataire sur les données, la performance et la sécurité d'un autre.

Niveaux d'isolation

1. Données : bases de données/schémas/tables individuelles, cryptage "clé locataire", filtres "tenant _ id'.
2. Calcul : quotas CPU/RAM/IO, pool de workers par tenant ou files d'attente « pondérées ».
3. Réseau : segmentation, endpoints privés/VPN, listes d'autorisations par locataire.
4. Opérations : migrations, backups, DR et incidents aux limites d'exposition « à un locataire ».

Modèles de multitenance

Silo (isolation rigide) : clusters individuels/OBD par tenant. Sécurité maximale, prix élevé.
Pool (ressources partagées) : infrastructure partagée avec isolation logique ; meilleure efficacité, plus risque de « noisy neighbor ».
Bridge/Hybride : hybride - plan de contrôle général + sélectivement « silo » pour les clients VIP/réglables.

2) Identification et routage des demandes de location

Permis de locataire (résolution Tenant)

Par domaine : 'https ://{ tenant} .example. com`

En cours de route : '/t/{ tenant }/... '

Par titre : 'X-Tenant-Id', 'X-Org' (vérification de signature)

Par token : les marques 'tenant _ id', 'org _ id', 'plan', 'scopes'

Routage

La passerelle L7 (API passerelle/Ingress) extrait 'tenant _ id', enrichit le contexte ('plan', limites, région), écrit dans les trajets/logs.
Les services fonctionnels prennent un contexte en lecture seule ; les décisions sur l'itinéraire et les limites sont prises par le gateway/policy moteur.

3) Données et schémas : stratégies

Options de stockage

Shared-schema, row-level : un ensemble de tables, le champ 'tenant _ id', rigoureux RLS (Row-Level Security).
Shared-DB, per-schema : une base de données, un schéma séparé par tenant ; équilibre entre gestion et isolement.
Per-DB/cluster : OBD/cluster séparé par tenant ; plus cher, plus facile pour les revendications souveraines.

Pratiques clés

Partout, passez explicitement "tenant _ id'et incluez-le dans les clés/index composites.
RLS/politiques d'accès au niveau de la base de données + validation de service par « double serrure ».
Chiffrement : hiérarchie des clés (root KMS → key-envelope sur tenant → DEK sur objet).
L'archive/rétention et le « droit à l'oubli » sont gérés par les politiques au niveau du locataire.

4) Paramètres, fiches et versions

Configurations par tenant

Table/store 'tenant _ bou' (plan, quotas, drapeaux ficha, localisation, SLA).
Priorités configues : défaut → plan → tenant → environnement → utilisateur.
Cachets de configues avec TTL court et handicapé par événement.

Drapeaux de ficha et compatibilité

L'activation des fonctions est ponctuelle (per-tenant/per-cohort), canaris.
Versioning API : contrat stable + adaptateurs à la frontière (formats back/forward-compatible).

5) Limites, quotas et facturation

Politiques de consommation

Rate limiting : 'requests/sec'per tenant/route, 'token baquet' avec les priorités des plans.
Quotas : volume de stockage, nombre d'objets, messages/min, jobs/heure.
Fairness : « horaire pondéré » des files d'attente + isolation des workers pour VIP.

Facturation

Compteurs "tenant _ id' → agrégateurs → factures.
Utilisation de snapshots à la frontière (idempotence et protection contre la perte d'événements).
Modèles : plan fixe + recop consommation, post-pei/pré-pei, rabais « tiered ».

6) Sécurité et accès

Authentification/autorisation

OIDC/SAML avec les marques 'tenant _ id', 'roles', 'scopes'.
RBAC/ABAC : rôles au niveau du locataire (Owner/Admin/Reader), attributs de projet/département.
Accès délégué (service-to-service) avec mTLS et tokens limités.

Limites de confiance

Stratégies d'acceptation des demandes : vérification de la signature des titres, nonce/timestamp, ancrage à la source.
Secrets et clés : rotation per-tenant, contextes KMS distincts, audit des opérations clés.
Multi-region & data residency : tenant vers la région, flux croisés contrôlés.

7) Observabilité « par locataire »

Trace et métriques

Balises obligatoires : 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
Dashboards et alertes par segments (VIP/réglables/nouveaux).

Logs et audit

Journaux d'activité (qui/quoi/quand/où) avec stockage immuable et retenti selon la politique du locataire.
Préagrégation des événements pour un stockage bon marché, restauration des détails "par clic'.

8) Performance et « noisy neighbor »

Mesures anti-bruit

Limites par niveau de file d'attente/worker, CPU-shares et proportion IO per tenant.
Division des caches : préfixes des clés 'tenant : {id} :...', TTL par plan, protection contre « cache stampede ».
Index et plans de requête en tenant compte de la sélectivité de 'tenant _ id'.

Démarrage à froid et pools « chauds »

Avant-chauffe pour VIP/fenêtres de pointe.
Pools de worker élastiques par signaux de métrique (backpressure/auto-skyling).

9) Mises à jour et migration sans interruption

Stratégie

Migrations compatibles backward (expand → migrate → contract).
Migrations « par locataire » : batchi avec contrôle de progression, « pause/retour » pour un 'tenant _ id'spécifique.
L'échantillonnage et les migrations « canaries » sur un sous-ensemble de locataires.

DR et incidents

Plan DR avec RTO/RPO per tenant ; mode « read-only » partiel sans downtime global.
Isolement de l'incident : fusion par 'tenant _ id', éteindre le locataire « chaud » n'affecte pas les autres.

10) API et protocoles

REST/gRPC avec le contexte obligatoire du locataire (dans les marques/titres).
Événements (event-driven) : tops avec neuming 'tenant. {id} .event', filtres et ACL sur les abonnements.
Points d'entrée globaux : La passerelle L7 valide le contexte, applique les limites, crypte les PII selon la politique du tenant.

11) Cycle de vie du locataire

1. Provijining : création de l'enregistrement du locataire, génération de clés/configues, ancrage de la région.
2. Activation : libération du client OIDC/SAML, création de rôles/politiques, quotas primaires.
3. Fonctionnement : surveillance, facturation, mise à jour des drapeaux/plans.
4. Suspension/trottinette : gel avec conservation des données/exportation.
5. Suppression/exportation : rétention, backaps conservés, crypto-effacement de clés (crypto-shredding).

12) Mini-référence de l'architecture (schéma verbal)

Edge (API passerelle) : TLS/mTLS, extraction 'tenant _ id', limites, audit.
Control Plane : annuaire des locataires, configis, drapeaux de ficha, facturation, politiques.
Data Plane (services) : services de stateless, files d'attente, workers avec quotas ; Redis/kv avec des préfixes par tenant.
Storage : RLS-OBD/circuits individuels/OBD ; KMS avec clés par locataire ; stockage objet avec encryptage envelope.
Observability : tracing/métriques/logs avec l'étiquette 'tenant _ id', alert per plan.
Admin : opérations isolées (migration/backup) sur un sous-ensemble de locataires.

13) Liste de contrôle avant la vente

Une seule façon de définir 'tenant _ id' à la frontière et dans les services.
Les politiques RLS/ACL sont testées par des tests et des « scénarios négatifs ».
Les quotas/limites/facturation sont validés sur des charges réelles ; il y a une protection contre les « billing drops ».
Observabilité et SLO per tenant ; alertes pour VIP/réglementé.
Les migrations sont compatibles, il y a un retour en arrière partiel et des batchies de location.
Scénarios DR avec RTO/RPO per tenant et exercices réguliers.
Chiffrement de la « clé du locataire », rotation et vérification des clés.
Documentation des contrats API/événements et des politiques de versioning.

14) Erreurs typiques

Les migrations mondiales ne peuvent pas être arrêtées sur un locataire en difficulté.
Dépendance masquée à 'tenant _ id'dans le cache/files d'attente → fuite de données/intersection de files d'attente.
Mélange de contextes (opération admin accidentelle sans "tenant _ id').
Pas de « double cadenas » : seulement un contrôle de service sans RLS dans la base de données.
Limite unique pour l'ensemble du cluster → « noisy neighbor » et violation de SLO.
Facturation opaque sans idempotence et audit-trail.

15) Sélection rapide de la stratégie

Isolation/réglementation stricte : Silo (OBD/clusters séparés), région-lock.
Efficacité équilibrée : Shared-DB per schema + RLS, clés per tenant.
Trafic en temps réel élevé : files d'attente communes avec quotas « pondérés » et workers dédiés pour VIP.
Beaucoup de personnalisations : drapeaux ficha + adaptateurs API, stockage des configues par priorité.

Conclusion

Le noyau multi-tenant est une discipline des limites de l'ingénierie : définition explicite de "tenant _ id', isolation stricte sur toutes les couches, quotas gérables et facturation transparente, plus observabilité et compatibilité des sorties. Suivre les schémas décrits permet de dimensionner le produit sans sacrifier la sécurité, la qualité et la rapidité des changements pour chaque locataire.