Construire un produit SaaS réussi sur Azure signifie concevoir pour plusieurs clients dès le premier jour. Multi-ténacy n'est pas seulement une caractéristique – c'est la base architecturale qui détermine comment vous échellez, sécurisez et monétiser votre application. Azure fournit un riche écosystème de services pour vous aider à mettre en œuvre l'isolement, l'élasticité et les contrôles de coûts, mais la bonne architecture dépend de vos besoins de locataires, de votre sensibilité aux données et de votre capacité opérationnelle.

Comprendre la multi-ténacité dans SaaS

Le multi-tenance est une architecture logicielle où une seule instance de l'application dessert plusieurs locataires (clients, organisations, groupes d'utilisateurs).Chaque locataire expérimente l'application comme si elle leur était dédiée, mais l'infrastructure, le calcul et le stockage sous-jacents sont partagés. Cette approche réduit le coût par client, simplifie la maintenance (une base de code, une unité de déploiement) et permet le déploiement rapide des fonctionnalités.

Les fournisseurs Azure SaaS sont généralement confrontés à trois décisions : le degré d'isolement, le modèle de calcul (PaaS vs. IaaS vs. conteneurs) et l'architecture de stockage.

Principes de conception de base pour les applications multi-tenantes sur Azure

Un design efficace et multi-locataires sur Azure repose sur quatre piliers : isolement, évolutivité, sécurité et gestion des coûts. Chaque principe influence votre choix de services et de modèles de déploiement Azure.

Isolation

L'isolement peut être logique (ID de niveau de ligne dans une base de données partagée) ou physique (bases de données séparées, comptes de stockage, voire abonnements séparés). Azure SQL Database et Azure Cosmos DB supportent les deux approches avec les politiques de sécurité de ligne de niveau de locataire et les clés de niveau conteneur. Du côté informatique, les plans de service App Azure peuvent être partagés, mais vous devez appliquer la portée du locataire dans votre code d'application. Pour une isolement plus stricte, considérez Azure Kubernetes Service (AKS) avec des espaces de noms spécifiques au locataire ou même des piscines de nœuds dédiés.

Échelle

Les charges de travail multi-tenues connaissent des pics imprévisibles à mesure que certains locataires augmentent rapidement tandis que d'autres restent stables. Azure , les capacités d'échelle automatique – comme les règles de décrochage App Service , AKS cluster autoscaler et Azure SQL Database pools élastiques – vous permettent d'absorber la croissance sans intervention manuelle. Concevoir votre application absoluement et décharger l'état de session à Azure Cache pour Redis ou Cosmos DB. Utilisez Azure Load Balancer ou Azure Front Door pour distribuer le trafic à travers les instances à échelle réduite.

Sécurité

Pour la communication service-service, s'appuyer sur des identités gérées et Azure Key Vault pour éviter les secrets de codage dur. Implémenter l'autorisation locataire-connaissance à la passerelle API – Azure API Management peut imposer la validation de jeton et limiter le taux par locataire. L'exploitation et l'audit devraient saisir le contexte locataire sans exposer les données sensibles au-delà des frontières.

Gestion des coûts

L'infrastructure partagée réduit le coût par locataire, mais une utilisation non optimale peut gaspiller de l'argent. Utilisez Azure Cost Management pour marquer les ressources par locataire et suivre les dépenses. Combinez les instances réservées avec l'auto-échelle pour gérer la charge de base à bas prix et les instances premium d'échelle pour les pics. Les piscines élastiques de base vous permettent de mettre en commun les ressources entre locataires, en ne payant que pour l'utilisation globale de DTU/vCore plutôt que de fournir des pics individuellement.

Stratégies d'isolement des données

Choisir comment stocker les données des locataires est la décision architecturale la plus conséquente. Azure prend en charge plusieurs modèles, chacun avec des compromis distincts dans l'isolement, la gérable, et les coûts.

Base de données unique, schéma partagé

Dans ce modèle, tous les locataires sont stockés dans une base de données avec une colonne d'identificateur de locataire sur chaque table. C'est la plus simple à gérer (une sauvegarde, une chaîne de connexion) et la plus rentable pour les petits locataires. Cependant, l'isolement est purement logique : un bug dans votre code de filtrage de locataire pourrait exposer des données d'un autre locataire. L'indexation et la performance de la requête peuvent diminuer au fur et à mesure que le nombre de locataires augmente, et les changements de schéma affectent chaque locataire simultanément.

Bases de données séparées (base de données par locataire)

Chaque locataire obtient sa propre base de données (et éventuellement son propre serveur ou pool élastique), ce qui lui permet d'être isolé de façon plus efficace (séparation des données physiques) et de faciliter la conformité (par exemple, résidence des données du RGPD). Les sauvegardes, la restauration et l'accord de performance peuvent être effectués par locataire. Les compromis sont complexes (des centaines ou des milliers de bases de données à gérer) et les frais généraux de ressources plus élevés.

Approches hybrides

De nombreux fournisseurs SaaS adoptent une stratégie à plusieurs niveaux : les locataires libres ou d'essai partagent une base de données commune, tandis que les locataires premium reçoivent des bases de données dédiées. Sinon, certaines données (par exemple, catalogues publics, données de référence) peuvent être partagées, tandis que les données privées sont isolées. Azure SQL Database , les capacités de sharding et de fédération supportent des modèles hybrides. Par exemple, vous pouvez utiliser une seule base de données partagée pour l'authentification et les métadonnées des locataires, puis diriger chaque locataire vers sa propre base de données ou sa propre base de données. Azure Cosmos DB prend également en charge l'isolement hybride avec des clés de partition qui peuvent être mappées aux locataires logiques, combinés avec des conteneurs séparés pour les locataires qui ont besoin de limites plus strictes.

Leveraging Azure Services pour multi-tendance

Au-delà du stockage des données, Azure offre une plateforme complète pour rendre opérationnel SaaS multi-tenu. Les services suivants sont particulièrement pertinents.

Calcul et hébergement

Azure App Service est le point d'entrée de nombreux fournisseurs SaaS. Il prend en charge l'échelle automatique, les déploiements basés sur les fentes et l'authentification intégrée. Pour plus de contrôle sur l'environnement d'exécution, Azure Kubernetes Service (AKS) vous permet d'isoler les locataires via des espaces de noms, des politiques de réseau et des quotas de ressources. AKS intègre également Azure AD pour le contrôle d'accès basé sur le rôle.

Stockage et base de données

Nous avons déjà discuté de Azure SQL Database et Cosmos DB. Pour le stockage blob ou de fichiers, Azure Blob Storage supporte l'isolement du locataire au niveau des conteneurs. Vous pouvez générer des jetons SAS spécifiques au locataire et appliquer des politiques d'accès avec Azure RBAC. Azure Storage compte par locataire est également une option pour l'isolement élevé, mais il augmente les frais généraux de gestion. Azure Cache pour Redis peut être partitionné par locataire en utilisant des bases de données séparées ou des préfixes de clés.

Gestion de l'identité et de l'accès

Azure AD B2C (business-to-consumer) est conçu pour SaaS avec des locataires externes. Il supporte les politiques personnalisées, les fournisseurs d'identité sociale et l'authentification multi-facteurs par locataire. Pour l'entreprise SaaS où les locataires sont des organisations, Azure AD B2B (business-to-business) permet aux utilisateurs de se connecter avec leurs propres identifiants d'organisation.

Sécurité et secrets

Azure Key Vault stocke des secrets spécifiques au locataire, des chaînes de connexion et des certificats. Vous pouvez accorder l'accès à certains services ou développeurs en utilisant des politiques d'accès à la voûte et RBAC. Pour le chiffrement au repos, Azure SQL Database prend en charge le chiffrement transparent des données (TDE) avec les clés gérées par le client stockées dans Key Vault – les clés peuvent être par titulaire si nécessaire.

Surveillance et observation

Étiquetez toute télémétrie avec un identifiant de locataire – soit dans des propriétés personnalisées, soit par l'intermédiaire d'un processeur d'enrichissement. Créez des règles d'alerte qui font feu par locataire lorsque les seuils sont dépassés (p. ex., CPU de base de données > 80% pour un locataire spécifique). Utilisez Azure Log Analytics et KQL pour étudier les performances spécifiques du locataire sans fuite de données croisées.

Mise en oeuvre de modèles multi-tendances

Vous avez plusieurs modèles architecturaux à choisir, allant de entièrement partagés à entièrement dédiés. Le bon modèle dépend de votre taille de locataires, des besoins de conformité, et de votre maturité DevOps.

Tout partagé (instance d'application unique, base de données partagée)

Tous les locataires partagent le même code d'application, calculent les ressources et la base de données. L'isolement est purement logique ou RLS. Ce modèle maximise l'utilisation des ressources et simplifie le déploiement. Il est idéal pour les locataires SaaS en début de phase ou les locataires à faible complexité. Le risque principal est qu'un locataire voisin bruyant puisse dégrader les performances pour d'autres.

Base de données partagée, schémas séparés

Les locataires partagent une seule base de données mais ont des schémas séparés (par exemple, lean 123.orders au lieu d'une colonne lean id). Cela fournit une meilleure isolation logique et permet des sauvegardes par schéma (bien que Azure SQL Database ne supporte pas nativement la sauvegarde au niveau du schéma – vous avez sauvegardé la base entière).

Bases de données séparées (base de données par locataire)

Chaque locataire possède sa propre base de données, et peut-être son propre bassin ou serveur élastique. Ce modèle offre la plus forte isolation, la plus grande flexibilité pour la configuration spécifique du locataire, et la plus facile de conformité (il suffit de supprimer un locataire en supprimant sa base de données). L'inconvénient est les frais généraux de gestion – vous devez scripter les actions de provisionnement, de sauvegarde et de migration pour de nombreuses bases de données.

Modèles hybrides et mis en commun

De nombreux fournisseurs SaaS matures combinent des modèles. Par exemple, utilisez une base de données partagée pour les métadonnées des locataires, la configuration et les journaux d'audit, et dédier des bases de données pour les locataires au-dessus d'un certain seuil de revenus. Ou bien mettez les petits locataires ensemble dans des piscines élastiques et placez de grands locataires dans des piscines dédiées.

Meilleures pratiques pour les applications multi-tendants Azure SaaS

Au-delà de la conception initiale, les opérations en cours font ou rompent une offre SaaS multi-locataires. Suivez ces pratiques pour assurer la fiabilité, la sécurité et l'efficacité économique.

  • Design for scalability from the start Utilisez Azure , l'auto-scalage intégré pour le service App, AKS et les bases de données. Testez avec la croissance simulée du locataire pour assurer le fonctionnement de votre logique de scalling.
  • prioriser l'isolement des locataires dans chaque couche. Votre authentification, votre autorisation, votre accès aux données et votre enregistrement doivent tous inclure un contexte de locataire explicite. Ne jamais se fier uniquement aux vérifications de niveau de code – renforcer l'isolement par la sécurité de niveau de ligne de base de données, les politiques Azure RBAC ou API.
  • Surveiller et optimiser en continu Utilisez Azure Monitor pour suivre les performances, les coûts et les taux d'erreur du locataire. Configurez l'alerte pour un comportement anormal qui pourrait indiquer un voisin bruyant ou un problème de sécurité.
  • Gestion du cycle de vie des locataires automatiques Fournir aux nouveaux locataires des modèles de MRA, Bicep ou Terraform. Automatiser la création de bases de données, la configuration de l'identité et le semis initial des données.
  • Plan de sauvegarde et de récupération de données. Pour les modèles de base de données partagés, sauvegardez l'ensemble de la base de données et assurez-vous que la restauration ponctuelle fonctionne dans tous les locataires.Pour les bases de données par locataire, implémentez des politiques de sauvegarde automatisées (la base de données SQL d'Azure le fait automatiquement avec des politiques de conservation).
  • Suivi des coûts d'exécution par locataire Étiquette toutes les ressources Azure avec un ID de locataire. Utilisez Azure Cost Management pour générer des rapports de coûts par locataire. Envisagez de facturer les locataires en fonction de la consommation réelle (CPU, stockage, transfert de données) pour aligner les coûts sur les revenus.
  • Sécurisez le pipeline CI/CD. Utilisez des emplacements de déploiement séparés ou des espaces de noms AKS pour la mise en scène. Exécutez des tests d'intégration qui simulent plusieurs locataires. N'exposez jamais les données des locataires dans les journaux ou les sorties de test. Utilisez Azure DevOps ou GitHub Actions avec une identité gérée pour un déploiement sécurisé.

Conclusion

La conception d'applications multi-tenues sur Azure n'est pas un exercice unique. L'architecture adéquate équilibre l'isolement, l'évolutivité, la sécurité et le coût en fonction de votre profil de locataire et de votre modèle d'affaires. Azure , un vaste portefeuille de services – de App Service et Azure SQL Database à Azure AD B2C et Key Vault – fournit les éléments de construction pour mettre en œuvre n'importe quel modèle, de entièrement partagé à entièrement dédié. En suivant les principes et les meilleures pratiques exposés dans cet article, les fournisseurs SaaS peuvent fournir des solutions multi-tenues fiables, sécurisées et rentables qui grandissent avec leurs clients. Pour plus de détails, explorez les conseils officiels d'Azure sur architecture multi-tenue, piscines élastiques[ et plate-forme d'identité Microsoft-tenue.