Multi-tenancy dans Azure Cosmos DB : modèles, coûts et choix pour les PME

Pourquoi le multi-tenancy ? Le cas Cosmos DB

Le multi-tenancy permet à une seule instance de base de données de servir plusieurs clients (ou locataires) simultanément, réduisant les coûts opérationnels et simplifiant la gestion (F3). Microsoft cite des applications à grande échelle comme exemple d’utilisation de Cosmos DB pour des services nécessitant fiabilité et faible maintenance (F1). Une PME doit arbitrer entre :

• Économie : Partager une infrastructure entre plusieurs locataires divise les coûts.
• Isolation : Garantir que les données et les performances d’un locataire n’impactent pas les autres.

Ces objectifs sont souvent en conflit (F11). Voici comment arbitrer entre ces contraintes en fonction de vos besoins.

Les deux modèles de multi-tenancy dans Cosmos DB

1. Partition key-per-tenant : l’équilibre coût/isolation

Principe : Chaque locataire se voit attribuer une clé de partition unique au sein d’un même conteneur Cosmos DB. Les données sont logiquement séparées, mais l’infrastructure est partagée (F4).

Avantages :

• Économique : Un seul compte Cosmos DB à gérer, réduisant les coûts d’infrastructure (F6).
• Scalable : Peut gérer des centaines de milliers de locataires avec une gestion simplifiée.
• Flexible : Idéal pour les charges de travail homogènes (ex : tous les locataires ont des volumes de données similaires).

Inconvénients :

• Contention de ressources : Un locataire avec une charge élevée peut impacter les performances des autres (F6).
• Limite de 20 Go par partition logique : Au-delà, il faut utiliser des hierarchical partition keys (HPK) pour étendre la capacité (F5, F12). Une partition logique peut également consommer jusqu’à 10 000 RU/s (F12).
• Isolation limitée : Pas d’isolation physique (ex : un locataire malveillant pourrait, en cas de faille, accéder aux données d’un autre).

Cas d’usage pour une PME :

• Applications internes avec des équipes ou services distincts (ex : CRM, gestion de projets).
• SaaS B2B avec des clients de taille similaire (ex : 100–1 000 utilisateurs par locataire).
• Prototypes ou MVP où le coût est prioritaire sur l’isolation.

2. Account-per-tenant : l’isolation maximale

Principe : Chaque locataire dispose de son propre compte Cosmos DB, avec une isolation physique complète (F7).

Avantages :

• Isolation totale : Aucun risque de contention ou d’interférence entre locataires.
• SLAs personnalisables : Chaque locataire peut avoir des garanties de performance distinctes.
• Sécurité renforcée : Chiffrement avec des clés gérées par le client via Azure Key Vault (F9).
• Flexibilité : Activation de fonctionnalités au niveau du compte (ex : géo-réplication, restauration à un point dans le temps).

Inconvénients :

• Coûts plus élevés : Multiplier les comptes Cosmos DB augmente les frais d’infrastructure (F8).
• Complexité de gestion : Plus de comptes à surveiller, configurer et maintenir.

Cas d’usage pour une PME :

• Secteurs réglementés (ex : santé, finance) où l’isolation des données est obligatoire.
• Clients exigeant des SLAs stricts (ex : temps de réponse garanti).
• Applications critiques où la sécurité prime sur le coût (ex : gestion de données sensibles).

Autres modèles d’isolation dans Cosmos DB

Cosmos DB propose deux autres approches pour des besoins spécifiques :

Container isolation

Principe : Chaque locataire a son propre conteneur au sein d’un même compte Cosmos DB (F10).

• Avantages : Meilleure isolation que partition key-per-tenant, gestion simplifiée vs account-per-tenant.
• Inconvénients : Pas d’isolation physique, risque de contention si un conteneur monopolise les ressources.

Database isolation

Principe : Chaque locataire a sa propre base de données au sein d’un compte Cosmos DB (F10).

• Avantages : Isolation renforcée, allocation de ressources au niveau de la base.
• Inconvénients : Coût et complexité intermédiaires, pas d’isolation physique.

Quand les utiliser ?

• Container isolation : Pour des locataires avec des schémas de données très différents (ex : un locataire stocke des images, un autre des logs).
• Database isolation : Pour des locataires nécessitant des configurations distinctes (ex : index personnalisés).

Checklist pour une PME : migrer vers le multi-tenancy

Voici une approche progressive pour adopter le multi-tenancy dans Cosmos DB, inspirée des recommandations officielles de Microsoft (F4) :

1. Évaluer les besoins en isolation :
   • Les données des locataires sont-elles sensibles (ex : données médicales) ? → Privilégier account-per-tenant.
   • Les locataires ont-ils des charges de travail similaires ? → Partition key-per-tenant est suffisant.
2. Estimer les coûts :
   • Utiliser le calculateur de prix Azure pour comparer partition key-per-tenant (1 compte) vs account-per-tenant (N comptes).
3. Tester la contention :
   • Simuler des charges de travail avec l’émulateur Cosmos DB ou Azure Monitor.
   • Vérifier les partitions chaudes (partitions surchargées) avec des requêtes comme :

     SELECT TOP 100 * FROM c WHERE c._partitionKey = "tenant1"

4. Démarrer par un pilote :
   • Choisir 10–20 locataires représentatifs (ex : clients internes ou bêta-testeurs).
   • Implémenter le modèle choisi et surveiller les performances pendant 1–2 mois.
5. Planifier la migration :
   • Pour partition key-per-tenant :
     • Ajouter un champ tenantId à chaque document et l’utiliser comme clé de partition.
     • Configurer des hierarchical partition keys si un locataire dépasse 20 Go (F5).
   • Pour account-per-tenant :
     • Automatiser la création de comptes avec Azure Bicep ou Terraform.
     • Configurer des clés gérées par le client pour le chiffrement (F9).

Arbre de décision pour choisir un modèle

• Isolation physique obligatoire ? → Account-per-tenant.
• Budget serré et locataires similaires ? → Partition key-per-tenant.
• Schémas de données très différents ? → Container isolation.
• Configurations distinctes par locataire ? → Database isolation.

Limites et alternatives pour les PME

Les pièges à éviter

• Sous-estimer la contention : Un seul locataire peut dégrader les performances pour tous les autres dans un modèle partagé. Surveiller les métriques de Cosmos DB (ex : Request Units consommées).
• Ignorer la limite des 20 Go par partition logique : Au-delà, les requêtes deviennent lentes. Utiliser des HPK ou migrer vers account-per-tenant.
• Négliger la sécurité : Même en isolation logique, des failles peuvent exposer les données. Activer le chiffrement au repos et en transit.

Alternatives à Cosmos DB

Si le budget est serré ou que les compétences en NoSQL manquent, d’autres solutions existent :

• PostgreSQL avec extensions multi-tenants :
  • Utiliser des schémas séparés (tenant1.table, tenant2.table) ou un champ tenant_id.
  • Avantages : Coût réduit, écosystème mature, support des requêtes complexes.
  • Inconvénients : Moins scalable que Cosmos DB pour des millions de locataires.
• Firebase/Firestore :
  • Solution serverless de Google, idéale pour les petites applications ou les MVP.
  • Avantages : Intégration facile avec les apps mobiles, pas de gestion d’infrastructure.
  • Inconvénients : Coûts imprévisibles à grande échelle, moins adapté aux données structurées.
• MongoDB Atlas :
  • Alternative NoSQL à Cosmos DB, avec un modèle de tarification similaire.
  • Avantages : Flexibilité des schémas, support des requêtes géospatiales.
  • Inconvénients : Moins intégré à l’écosystème Azure pour les PME utilisant déjà Microsoft 365.

Pour aller plus loin sur l’implémentation d’une architecture scalable en PME, consultez notre guide sur l’implémentation de l’IA en entreprise.