Quand vous identifiez une portion de la solution logicielle de votre entreprise que vous pouvez commercialiser sans marque auprès d’autres entreprises, celle-ci ajoute un flux de revenus entier. Toutefois, configurer la solution pour prendre en compte la charge qu’entraîne une pléthore de locataires est souvent un obstacle difficile à franchir. Cette solution fait appel à une suite de technologies Azure qui sécurisent et équilibrent le trafic.
Architecture
Téléchargez un fichier Visio de cette architecture.
Workflow
Une suite de technologies Azure sécurise et équilibre la charge du trafic.
Microsoft Azure Front Door gère quelques tâches initiales :
Traitement de la requête initiale
Équilibrage de la charge entre les régions
Arrêt et déchargement SSL (HTTPS)
Basculement en cas de panne régionale
Azure DNS gère les enregistrements DNS et assure leur routage vers le point de terminaison Azure Front Door approprié.
L’architecture utilise Microsoft Entra ID comme fournisseur d’identité pour l’authentification.
Une fois le routage effectué vers la région appropriée, Application Gateway route et équilibre la charge, dirigeant les demandes vers l’Azure App Service approprié.
Pour cette architecture, App Service est le service préféré pour :
toute application basée sur HTTP ;
le service de contenu web ;
l’exposition d’API RESTful ;
l’implémentation de la logique métier derrière l’application frontale.
Vous pouvez configurer App Service pour une mise à l’échelle automatique. Cela fait d’App Service une solution adaptée pour la mise à l’échelle d’un hôte de requêtes HTTP de locataire à la demande.
Les services de la couche d’accès aux données sont également mis à l’échelle de manière indépendante en fonction de la charge. Les services de données gèrent les modèles de données, les clients de connexion et les pilotes. Les services fournissent également une interface de données cohérente pour tous les services de niveau supérieur souhaitant consommer des données dans l’application. Vous pouvez déployer et mettre à l’échelle ces services de données à l’aide du service Azure Kubernetes (AKS). Chaque cluster AKS est responsable d’un ensemble de fonctionnalités associées dans la couche. AKS peut implémenter une architecture de microservices, qui se caractérise par une série de conteneurs qui encapsulent chacun une fonctionnalité spécifique au sein du cluster. Cela permet un degré élevé d’abstraction et de découplage dans le code. Cela permet également aux clusters d’effectuer un scale-out individuellement pour prendre en compte la charge accrue de plusieurs locataires. Chaque cluster peut augmenter l’échelle (scale-up) de ses ressources si sa charge augmente. Le scale-up n’affecte pas les autres clusters du groupe de ressources tant qu’ils ne connaissent pas la même augmentation.
Stockez et gérez les données relationnelles en dehors de l’infrastructure d’application. Cela fournit un point unique d’entrée de données pour chaque région. Vous pouvez réaliser la réplication, la disponibilité, la scalabilité et la sécurité en tirant profit de la puissance des pools élastiques Azure SQL. Approvisionnez pour chaque locataire une base de données dans un pool. Allouez les ressources disponibles dans le pool à des bases de données à la demande à mesure que la charge et les demandes arrivent. Cela optimise les ressources de base de données disponibles pour les locataires par rapport à votre budget.
Components
Les composants principaux sont les composants suggérés pour l’architecture de cette solution. Si l’un des composants principaux ne correspond pas à votre architecture, consultez la liste des autres composants.
Composants principaux
Azure Front Door : équilibreur de charge régional qui achemine le trafic client vers la région correcte. Il peut basculer vers la deuxième région si une défaillance régionale se produit, et sécuriser le point d’entrée accessible sur Internet via Azure Web Application Firewall.
Microsoft Entra ID : agit en tant que fournisseur d’identité pour l’application entière, en appliquant l’authentification et l’autorisation de bout en bout de la requête dans l’application.
Azure DNS : service d’hébergement dans Azure pour la résolution de nom de domaine. Dans une solution mutualisée, plusieurs clients accèdent à la solution via leurs propres domaines individuels. Utilisez Azure DNS pour configurer et résoudre les demandes des clients en leur pile d’applications correcte.
Application Gateway : achemine le trafic, et en équilibre la charge en interne dans l’application, vers les différents services qui répondent aux besoins métier du client. Tandis qu’Azure Front Door équilibre la charge entre régions de haut niveau, Application Gateway a connaissance de la charge sur les services individuels au sein d’un groupe. Azure Front Door et Application Gateway se combinent pour fournir un équilibrage de charge complexe à tous les niveaux d’une solution mutualisée. Pour plus d’informations sur les options d’équilibrage de charge dans Azure, consultez cette vue d’ensemble de l’équilibrage de charge Azure.
Service d’application : service Premier d’Azure pour les applications web et les API basées sur le web. La sécurité s’intègre à des services tels que Microsoft Entra ID et Azure Key Vault. Vous pouvez configurer la mise à l’échelle automatique. De plus, la quantité de ressources disponibles pour la mise à l’échelle est flexible entre les différents plans App Service sur lesquels l’application peut s’exécuter. App Service peut également tirer parti des fonctionnalités de DevOps intégrées pour l’intégration et le déploiement continus dans plusieurs environnements. Ces fonctionnalités, ainsi que d’autres fonctionnalités de prise en charge, de la plateforme Azure permettent aux développeurs de se concentrer sur le développement de leurs applications.
Azure Kubernetes Service (AKS) : orchestre les instances d’images de conteneur déployées sur un cluster. La gestion des données de plusieurs clients implique souvent l’implémentation d’une suite de composants pour gérer les aspects suivants :
modélisation de données ;
connectivité de la source de données ;
extraction, transformation et chargement (ETL) ;
activités d’importation/exportation.
Le développement de ces nombreux composants plus petits en tant que microservices basés sur des conteneurs crée un scénario idéal pour le déploiement sur un cluster AKS. Des outils pour la mise à l’échelle automatique, l’équilibrage de charge et l’évolutivité sont intégrés dans l’infrastructure. AKS s’intègre bien avec une stratégie d’intégration/livraison continues (CI/CD) en utilisant les fonctionnalités de DevOps disponibles et Azure Container Registry.
Pools élastiques SQL Azure : fournit une solution pour gérer un ensemble de bases de données de manière flexible avec un pool de ressources. Le service alloue des ressources à la demande aux bases de données. Il offre au développeur d’architecture SaaS mutualisée la puissance nécessaire pour fournir des ressources de base de données aux clients en fonction de leurs besoins. Le service réduit également le budget et la surcharge liés à la gestion de plusieurs serveurs SQL avec de grands segments de ressources de calcul inutilisées.
Recherche cognitive Azure (anciennement Recherche Azure) : service qui ajoute un puissant moteur d’indexation et de requête à votre application. Il permet aux clients d’accéder à une puissante fonctionnalité de requête. Les clients peuvent également utiliser les fonctionnalités d’IA d’Azure pour enrichir et améliorer la fonctionnalité de requête. Le service Recherche cognitive Azure peut prendre en compte la mutualisation à l’aide d’une stratégie d’index par locataire ou de service par locataire.
Azure Cache pour Redis : applique une couche de mise en cache en tant que service à la solution, en fournissant un cache géré en mémoire pour réduire la latence et accroître les performances pour les clients. Un débit élevé permet qu’un volume important de demandes gère plusieurs locataires accédant au système. Vous pouvez augmenter l’échelle du service de manière flexible en fonction de l’augmentation des charges de l’application. Azure Cache pour Redis prend également en charge le chiffrement au repos pour protéger et isoler les données de locataire mises en cache.
Composants alternatifs
Azure Virtual Machine Scale Sets : groupe de machines virtuelles identiques permettant le déploiement de services dans un environnement de machines virtuelles qui se met à l’échelle et croît automatiquement en fonction des besoins. Virtual Machine Scale Sets s’intègre bien avec un équilibreur de charge ou Application Gateway pour rééquilibrer automatiquement la charge à mesure que croît le groupe identique. Il fournit la scalabilité que cette solution demande. Cependant, dans de nombreux cas, il est inutile de gérer l’environnement de machine virtuelle entier, et nous pouvons reporter ce niveau de la pile sur App Service ou AKS.
Azure SQL Database : services implémentés en tant qu’instances dédiées individuelles à la place de pools élastiques. L’utilisation des services Azure SQL Database ajoute des frais à la gestion directe de l’instance et augmente le coût des ressources allouées. Cela dit, il s’agit d’une alternative acceptable quand le locataire requiert un serveur dédié. En particulier, le client pourrait avoir besoin de davantage de contrôle sur l’instance et des ressources disponibles dédiées. Des locataires qui ont besoin d’un SQL Server dédié peuvent exister à côté de locataires sur une configuration de pool élastique. Vous pouvez faire d’un niveau de bases de données SQL une option de tarification disponible pour les locataires lors de l’achat de licences pour la fonctionnalité SaaS.
SQL Server sur les machines virtuelles : autre option pour le déploiement de bases de données SQL. Le locataire pourrait avoir une infrastructure informatique préexistante ainsi que des serveurs SQL Server locaux. Dans ce cas, le locataire pourrait vouloir utiliser ses licences actuelles, que ce soit en tant que migration complète ou dans un scénario hybride. La nature découplée de la solution SaaS permet à la couche de données de l’application de cibler n’importe quel service SQL Database via la configuration.
Détails du scénario
Quand vous identifiez une portion de la solution logicielle de votre entreprise que vous pouvez commercialiser sans marque auprès d’autres entreprises, celle-ci ajoute un flux de revenus entier. Toutefois, configurer la solution pour prendre en compte la charge qu’entraîne une pléthore de locataires est souvent un obstacle difficile à franchir.
Azure propose une gamme de services pour la gestion d’une solution logicielle qui :
gère de façon flexible les bases de données pour tous les clients ;
met à l’échelle les niveaux métier et logique de la solution afin d’éviter les goulots d’étranglement dans la couche de calcul ;
intègre la disponibilité et le basculement régional ;
fournit une sécurité de bout en bout à tous les niveaux de la solution.
Cas d’usage potentiels
Les cas d’usage suivant ont des modèles de conception qui peuvent tirer parti d’une solution SaaS mutualisée hébergée sur Azure :
développer une solution de gestion de la relation client (CRM) que les clients peuvent commercialiser et vendre à des clients ;
implémenter un système de gestion de contenu (CMS) et le fournir à plusieurs utilisateurs à l’aide de cette architecture.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Mutualisation
La mutualisation est au cœur de cette solution. Celle-ci gère plusieurs clients simultanément. Elle alloue également suffisamment de ressources pour traiter efficacement toutes les demandes des clients. Lors du traitement des demandes, la solution sécurise le trafic en provenance de points de terminaison globaux, et isole les données du client pour prévenir les violations et toute contamination croisée. Déployez des clients sur une paire de groupes de ressources régionaux en fonction de leur emplacement principal. Cela optimise la disponibilité régionale.
Vous pouvez déployer un grand nombre de clients sur un seul groupe de calcul, puisque le système isole les requêtes en fonction de l’authentification et des clés des clients, qui différencient les demandes en fonction de ces identificateurs uniques. Le système peut chiffrer toutes les requêtes des clients séparément en fonction de leurs clés, afin qu’aucun client ne puisse déchiffrer les données d’autres clients. La gestion de plusieurs clients sur une pile de calcul unique vous permet d’optimiser l’allocation des ressources pour fournir aux clients la réactivité dont ils ont besoin.
Vous gérez les bases de données clientes de la même façon en dehors de la pile de calcul, car une requête de client peut provenir d’une des piles régionales. De nombreuses bases de données clientes peuvent exister sur le même pool élastique. Elles sont isolées et sécurisées par la technologie Transparent Data Encryption (TDE). Vous pouvez configurer chaque base de données pour chiffrer les données à l’aide d’une clé gérée par le client, et déchiffrer les données juste-à-temps (JIT). Le déchiffrement JIT protège les données du client vis-à-vis du développeur et d’autres clients. Le système tire profit du pool élastique pour fournir des ressources à la demande aux clients qui lui sont attribués, tout en maintenant des coûts peu élevés pour vous. Vous pouvez affecter des stratégies de réplication à chaque pool élastique à des fins de sauvegarde et de basculement des données du client. Mettez en ligne davantage de pools élastiques à mesure que vous intégrez plus de clients dans le système.
Pour plus d’informations sur les solutions multi-locataire, consultez Solutions multi-locataire sur Azure.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
Scalabilité et disponibilité
Cette solution est conçue pour prendre en compte un grand nombre de locataires utilisant la fonctionnalité SaaS. Elle tire parti du grand nombre de composants et services évolutifs pour croître en fonction de la charge. Cette architecture n’est pas conçue pour des solutions servant une poignée de locataires, ou une petite charge de demandes et de données. Elle pourrait mettre l’accent sur le budget d’une solution ciblant un seul client ou une moindre charge. Il n’est pas non plus nécessaire de disposer de la surcharge multirégion où une haute disponibilité globale n’est pas une exigence, car cela ajoute une complexité et des coûts superflus.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Le système assure la sécurité de bout en bout à chaque niveau de l’application :
Azure Front Door intègre une prise en charge de HTTPS pour ses domaines. Cela signifie que le système peut chiffrer tout le trafic en direction de l’application SaaS. Azure Front Door implémente également un pare-feu d’applications web Azure protégeant la pile SaaS contre les attaques à la périphérie, avant que le système route les demandes vers l’application.
Chaque pile d’applications dans chaque région réside dans un réseau virtuel Azure. Le système restreint le trafic entrant dans le réseau virtuel, en acceptant les demandes provenant d’Azure Front Door, et en protégeant tous les services d’application du trafic externe. Après franchissement du pare-feu sécurisé, Application Gateway peut mettre fin à l’utilisation du protocole SSL et assurer un équilibrage de charge et un routage performants au sein de l’application.
Vous pouvez gérer en toute sécurité l’ensemble des informations d’identification, secrets et autres chaînes de connexion à l’aide de Azure Key Vault. En gérant ces données sensibles comme des secrets, les développeurs peuvent injecter des informations d’identification dans l’application au moment du déploiement. Cela garantit que le code n’est pas pollué avec des informations sensibles. L’utilisation de secrets protège les données du client en veillant à ce qu’une violation de code ou de l’attaque d’intercepteur ne puisse pas donner accès aux bases de données clientes.
Dans ce scénario, les données de plusieurs locataires peuvent coexister sur un même serveur de base de données, s’il ne s’agit pas de la même base de données. L’utilisation de la technologie TDE et du déchiffrement JIT protège les données de la base de données. Le système chiffre toutes les données de la base de données au repos, et ne les déchiffre qu’à la demande du locataire. Les clients peuvent fournir leurs propres clés, et vous pouvez stocker toutes leurs clés dans la solution Azure Key Vault afin de gérer le chiffrement pour plusieurs locataires. Le système protège les données des clients de bout en bout, empêche les développeurs d’y avoir accès, isole les données entre les locataires, et aide à répondre aux exigences de conformité en matière de sécurité et de données.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Azure App Service propose de nombreux niveaux tarifaires en fonction des ressources de calcul requises. Pour une SaaS mutualisée, les fonctionnalités de haute disponibilité et de montée en charge parallèle sont des aspects clés du choix du plan de service. Si vous envisagez d’héberger de nombreux locataires, le choix d’un niveau Premium ou Isolé pourrait être nécessaire pour fournir les ressources de calcul nécessaires pour prendre en charge un trafic élevé. Les niveaux Standard, Premium et Isolé correspondent tous à des instances de machine virtuelle dédiées. Vous pouvez calculer le coût par unité de temps en fonction du nombre de machines virtuelles de ce niveau que vous avez spécifié. Pour plus d’informations, consultez la vue d’ensemble des plans tarifaires d’App Service.
L’environnement Azure Kubernetes Service fournit un service de conteneur économique. Les frais liés aux nœuds AKS sont comptabilisés à l’utilisation. Vous n’êtes donc facturé que pour les postes suivants :
machines virtuelles ;
ressources de stockage et de réseau consommées ;
mise à l’échelle directement liée à l’utilisation.
L’environnement AKS en tant que service de couche Données est idéal si vous cherchez à réduire les coûts. Pour obtenir une estimation de la tarification d’une couche d’instances AKS, consultez la calculatrice du service Kubernetes.
Par conception, la tarification du pool élastique SQL Azure est très économique dans un scénario mutualisé. Les bases de données de locataires dans un pool élastique partagent les ressources disponibles. À mesure que la répartition de la demande évolue entre les locataires, la répartition des ressources évolue également. Un pool élastique SQL Azure fournit les ressources disponibles maximales aux bases de données demandées sans occasionner de frais généraux pour les ressources sur toutes les bases de données. Le service maintient un coût faible pour le développeur de la fonctionnalité SaaS et les locataires. Vous pouvez utiliser la calculatrice de prix d’Azure SQL Database pour estimer le prix et déterminer le niveau et la quantité de ressources nécessaires pour servir vos locataires et leurs données.
L’utilisation d’un modèle de tarification de mémoire à tores magnétiques virtuelle (vCore) offre davantage de flexibilité en matière de mise à l’échelle pour répondre aux besoins en ressources. En outre, vous pouvez tirer parti d’Azure Hybrid Benefit. Les licences SQL Server existantes permettent d’obtenir une remise sur les ressources SQL vCore dans le cloud. Dès lors, dans une instance où des serveurs locaux font déjà partie de l’infrastructure du développeur, ces remises vous permettent d’encore mieux maîtriser les coûts. Vous pouvez estimer vos économies potentielles à l’aide de la calculatrice des économies réalisées avec Azure Hybrid Benefit.
Vous pouvez également économiser sur les ressources SQL Server en achetant de la capacité de réserve Azure SQL Database. L’achat de capacité réservée marque un engagement à utiliser SQL Database sur le long terme. Le terme est généralement compris entre un et trois ans. En retour, vous bénéficiez de remises sur les coûts de calcul des ressources réservées. Par exemple, vous pouvez réserver 32 vCores à usage général pour une année afin de réduire leur coût pour cette période. Le fait d’avoir plusieurs locataires achetant des licences pour une fonctionnalité SaaS est un indicateur fort que l’utilisation de capacité réservée convient pour la solution et constitue un économiseur de coût idéal dans cette charge de travail.
Vous pouvez trouver la structure de tarification d’Azure Cache pour Redis sur la page Tarification d’Azure Cache pour Redis. Vous pouvez ajuster le niveau de cache à tout moment en optant pour le niveau De base, Standard ou Premium en fonction des besoins. Vous constaterez une tarification supérieure des limites de cache plus élevées et des fonctionnalités supplémentaires telles que la réplication et la récupération d’urgence. Azure Cache pour Redis propose également une tarification de capacité de réserve pour les engagements d’utilisation à long terme.
Le prix d’Azure Front Door dépend du volume du transfert de données échangées avec le service. Pour les données sortantes, la tarification varie selon les zones. Les différentes régions entraînent des coûts différents. Si vous voyez un écart de prix, estimez le coût séparément. Le prix inclut une certaine capacité de routage et de domaine, mais l’utilisation du système au-delà des limites initiales entraîne des coûts. Azure Web Application Firewall entraîne un faible coût supplémentaire par stratégie ou règle appliquée. Vous trouverez les détails de la tarification d’Azure Front Door sur la page Tarification d’Azure Front Door.
La tarification de Recherche cognitive Azure est un système à plusieurs niveaux. Un niveau gratuit est disponible pour le développement et le test. Après cela, chaque niveau entraîne un coût horaire pour chaque instance de Recherche cognitive allouée. À chaque passage à un niveau supérieur, le stockage total, le nombre d’index et les limites de montée en charge parallèle augmentent. Le service Recherche cognitive Azure propose une extraction d’image en tant que service au même tarif pour tous les niveaux payants.
Étapes suivantes
Les applications et les objets principaux de service dans Microsoft Entra ID permettent de tirer parti de Microsoft Entra ID pour mettre en œuvre des applications multilocataire.
L’article Modèles de location de base de données SaaS mutualisés couvre l’implémentation de modèles mutualisés dans SQL.
La location dans Microsoft Entra ID consiste également à tirer parti de Microsoft Entra ID pour mettre en œuvre des applications multilocataires.
Ressources associées
L’article Exécuter une application web dans plusieurs régions Azure à des fins de haute disponibilité est une référence pour l’exigence multirégion de la solution.
L’article Application web multiniveau développée pour la haute disponibilité et la reprise d’activité sur Azure est un exemple similaire de scénario de charge de travail. Il énonce de nombreuses de considérations relatives à une application à grande échelle sur Azure.