Considérations relatives à Azure App Service et à Azure Functions pour l’architecture mutualisée

Azure App Service est une plateforme d’hébergement d’applications web puissante. Azure Functions, reposant sur l’infrastructure App Service, vous permet de créer facilement des charges de travail de calcul serverless et pilotées par les événements. Les deux services sont fréquemment utilisés dans les solutions mutualisées.

Fonctionnalités d’Azure App Service et d’Azure Functions qui prennent en charge l’architecture mutualisée

Azure App Service et Azure Functions incluent de nombreuses fonctionnalités qui prennent en charge l’architecture mutualisée.

Noms de domaine personnalisés

Azure App Service vous permet d’utiliser des caractères génériques DNS et d’ajouter vos propres certificats TLS génériques. Lorsque vous utilisez des sous-domaines spécifiques au locataire, les certificats DNS et TLS vous permettent d’adapter facilement votre solution à un grand nombre de locataires, sans nécessiter de reconfiguration manuelle pour chaque nouveau locataire.

Lorsque vous utilisez des noms de domaine personnalisés spécifiques au client, vous pouvez avoir un grand nombre de noms de domaine personnalisés qui doivent être ajoutés à votre application. Cela peut devenir fastidieux de gérer un grand nombre de noms de domaine personnalisés, en particulier lorsqu’ils requièrent des certificats TLS individuels. App Service fournit des certificats TLS gérés, ce qui réduit le travail nécessaire lorsque vous utilisez des domaines personnalisés. Toutefois, il existe des limites à prendre en compte, telles que le nombre de domaines personnalisés qui peuvent être appliqués à une seule application.

Intégration avec Azure Front Door

App Service et Azure Functions peuvent s’intégrer à Azure Front Door pour agir en tant que composant Internet de votre solution. Azure Front Door vous permet d’ajouter un pare-feu d’applications web (WAF) et une mise en cache de périphérie, et fournit d’autres optimisations de performances. Vous pouvez facilement reconfigurer vos flux de trafic pour diriger le trafic vers différents backends, en fonction de la modification des exigences métiers ou techniques.

Quand vous utilisez Azure Front Door avec une application mutualisée, vous pouvez l’utiliser pour gérer vos noms de domaine personnalisés et mettre fin à vos connexions TLS. Votre application App Service est ensuite configurée avec un seul nom d’hôte, et tout le trafic transite par cette application, ce qui vous permet d’éviter de gérer les noms de domaine personnalisés à plusieurs endroits.

Comme dans l’exemple ci-dessus, Azure Front Door peut être configuré pour modifier l’en-tête Host de la demande. L’en-tête d’origine Host envoyé par le client est propagé via l’en-tête X-Forwarded-Host, et votre code d’application peut utiliser cet en-tête pour mapper la demande au bon locataire.

Vous pouvez utiliser des points de terminaison privés ou des restrictions d’accès App Service pour vous assurer que le trafic a transité Front Door avant d’atteindre votre application.

Pour plus d’informations sur l’utilisation d’Azure Front Door dans une solution multi-locataire, consultez Utiliser Azure Front Door dans une solution multi-locataire

Authentification et autorisation

Azure App Service peut valider des jetons d’authentification pour le compte de votre application. Lorsque App Service reçoit une requête, il vérifie si chacune des conditions suivantes est remplie :

• La requête contient un jeton.
• Le jeton est valide.
• La requête n’est pas autorisée.

Si l’une des conditions n’est pas respectée, App Service peut bloquer la requête ou rediriger l’utilisateur vers votre fournisseur d’identité pour pouvoir se connecter.

Si vos locataires utilisent Microsoft Entra ID comme système d’identité, vous pouvez configurer Azure App Service pour utiliser le point de terminaison /common afin de valider des jetons utilisateur. Ainsi, quel que soit le locataire Microsoft Entra de l’utilisateur, les jetons utilisateur sont validés et acceptés.

Vous pouvez également intégrer Azure App Service avec Azure AD B2C pour l’authentification des consommateurs.

Plus d’informations :

• Autorisation App Service
• Configuration de l’authentification dans un exemple d’application web à l’aide d’Azure AD B2C
• Utilisation des identités multilocataires Microsoft Entra

Restrictions d'accès

Vous pouvez limiter le trafic à votre application à l’aide de restrictions d’accès. Celles-ci peuvent être utilisées pour spécifier les plages d’adresses IP ou les réseaux virtuels qui sont autorisés à se connecter à l’application.

Lorsque vous travaillez avec une solution mutualisée, tenez compte du nombre maximal de règles de restriction d’accès. Par exemple, si vous devez créer une règle de restriction d’accès pour chaque locataire, vous risquez de dépasser le nombre maximal de règles autorisées. Si vous avez besoin d’un plus grand nombre de règles, envisagez de déployer un proxy inverse comme Azure Front Door.

Modèles d’isolation

Lorsque vous travaillez avec un système multilocataires qui utilise Azure App Service ou Azure Functions, vous devez prendre une décision concernant le niveau d’isolation que vous souhaitez utiliser. Reportez-vous aux modèles de location à prendre en compte pour une solution mutualisée et aux conseils fournis dans les approches architecturales pour le calcul dans les solutions mutualisées, afin de vous aider à sélectionner le modèle d’isolation le mieux adapté à votre scénario.

Lorsque vous travaillez avec Azure App Service et Azure Functions, vous devez connaître les concepts clés suivants :

• Dans Azure App Service, un plan représente votre infrastructure d’hébergement. Une application représente une application unique s’exécutant sur cette infrastructure. Vous pouvez déployer plusieurs applications dans un seul plan.
• Dans Azure Functions, votre hébergement et votre application sont également séparés, mais des options d’hébergement supplémentaires sont disponibles pour l’hébergement élastique, où Azure Functions gère la mise à l’échelle pour vous. Pour plus de simplicité, nous faisons référence à l’infrastructure d’hébergement sous l’appellation plan dans cet article, car les principes décrits ici s’appliquent à la fois à App service et à Azure Functions, quel que soit le modèle d’hébergement que vous utilisez.

Le tableau suivant récapitule les différences entre les principaux modèles d’isolation de location pour Azure App Service et Azure Functions :

Applications partagées

Vous pouvez déployer une application partagée sur un seul plan et utiliser l’application partagée pour tous vos locataires.

Cela a tendance à être l’option la plus rentable, et elle nécessite le moins de ressources opérationnelles, car il y a moins de ressources à gérer. Vous pouvez mettre à l’échelle le plan global en fonction de la charge ou de la demande, et tous les locataires qui partagent le plan tireront parti de la capacité accrue.

Il est important de connaître les quotas et les limites d’App Service, tels que le nombre maximal de domaines personnalisés qui peuvent être ajoutés à une seule application et le nombre maximal d’instances d’un plan qui peuvent être provisionnées.

Pour pouvoir utiliser ce modèle, votre code d’application doit prendre en charge l’architecture mutualisée.

Applications par locataire avec des plans partagés

Vous pouvez également choisir de partager votre plan entre plusieurs locataires, mais de déployer des applications distinctes pour chaque locataire. Cela vous permet d’isoler logiquement entre chaque locataire, et cette approche offre les avantages suivants :

• Rentabilité : en partageant votre infrastructure d’hébergement, vous pouvez généralement réduire vos coûts globaux par locataire.
• Séparation de la configuration : l’application de chaque locataire peut avoir ses propres nom de domaine, certificat TLS, restrictions d’accès et stratégies d’autorisation de jeton.
• Séparation des mises à niveau : les binaires d’application de chaque locataire peuvent être mis à niveau indépendamment des autres applications sur le même plan.

Toutefois, étant donné que les ressources de calcul du plan sont partagées, les applications peuvent être sujettes au problème de voisinage bruyant. En outre, il existe des limites concernant le nombre d’applications qui peuvent être déployées sur un seul plan.

Plans par locataire

Le niveau d’isolation le plus élevé consiste à déployer un plan dédié pour un locataire. Ce plan dédié garantit que le locataire utilise toutes les ressources du serveur qui sont allouées à ce plan.

Cette approche vous permet de mettre à l’échelle votre solution afin d’assurer l’isolation des performances pour chaque locataire et d’éviter le problème de voisinage bruyant. Toutefois, cela a également un coût plus élevé, car les ressources ne sont pas partagées avec plusieurs locataires. En outre, vous devez prendre en compte le nombre maximal de plans qui peuvent être déployés dans un seul groupe de ressources Azure.

API d’hôte

Vous pouvez héberger des API sur Azure App Service et Azure Functions. Votre choix de plateforme dépend de l’ensemble de fonctionnalités et des options de mise à l’échelle dont vous avez besoin.

Quelle que soit la plateforme utilisée pour héberger votre API, envisagez d’utiliser la Gestion des API Azure devant votre application API. La Gestion des API fournit de nombreuses fonctionnalités qui peuvent être utiles pour les solutions multi-locataires, notamment :

• Point centralisé pour toutes les authentifications. Cela peut inclure la détermination de l’identificateur de locataire à partir d’une revendication de jeton ou d’autres métadonnées de demande.
• Routage des requêtes vers différents backends d’API, qui peuvent être basés sur l’identificateur de locataire de la demande. Cela peut être utile lorsque vous hébergez plusieurs tampons de déploiement, avec leurs propres applications API indépendantes, mais que vous avez besoin d’une URL d’API unique pour toutes les demandes.

Mise en réseau et architecture mutualisée

Adresses IP

De nombreuses applications mutualisées doivent se connecter aux réseaux locaux des locataires pour envoyer des données.

Si vous devez envoyer le trafic sortant à partir d’une adresse IP statique connue ou d’un ensemble d’adresses IP statiques connues, envisagez d’utiliser une passerelle NAT. Pour plus d’informations sur l’utilisation de la NAT Gateway dans des solutions multi-locataires, consultez l’article Considérations relatives à la passerelle NAT Azure pour l’architecture mutualisée. App Service fournit des conseils sur l’intégration à une passerelle NAT.

Si vous n’avez pas besoin d’une adresse IP sortante statique, mais que vous avez besoin de vérifier occasionnellement l’adresse IP utilisée par votre application pour le trafic sortant, vous pouvez interroger les adresses IP actuelles du déploiement App Service.

Quotas

Étant donné qu’App Service est lui-même un service multi-locataire, vous devez vous soucier de la façon dont vous utilisez les ressources partagées. La mise en réseau est un domaine auquel vous devez porter attention, car il existe des limites qui affectent la manière dont votre application peut fonctionner avec les connexions réseau entrantes et sortantes, notamment la traduction d’adresses réseau source (SNAT) et les limites de ports TCP.

Si votre application se connecte à un grand nombre de bases de données ou de services externes, votre application risque d’être menacée par l’épuisement des ports SNAT. En général, l’épuisement des ports SNAT indique que votre code ne réutilise pas correctement les connexions TCP, et même dans une solution mutualisée, vous devez vous assurer que vous suivez les pratiques recommandées pour réutiliser les connexions.

Toutefois, dans certaines solutions mutualisées, le nombre de connexions sortantes vers des adresses IP distinctes peut entraîner l’épuisement des ports SNAT, même lorsque vous suivez les bonnes pratiques de codage. Dans ces scénarios, envisagez l’une des options suivantes :

• Déployez la NAT Gateway pour augmenter le nombre de ports SNAT disponibles pour votre application. Pour plus d’informations sur l’utilisation de la NAT Gateway dans des solutions multi-locataires, consultez l’article Considérations relatives à la passerelle NAT Azure pour l’architecture mutualisée.
• Utilisez des points de terminaison de service lorsque vous vous connectez aux services Azure pour contourner les limites de l’équilibreur de charge.

Même si ces contrôles sont en place, vous pouvez approcher des limites avec un grand nombre de locataires. Vous devez donc envisager de mettre à l’échelle des plans App Service ou des tampons de déploiement supplémentaires.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• John Downs | Ingénieur logiciel principal

Autres contributeurs :

• Thiago Almeida | Responsable du programme principal, Azure Functions
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Consultez Ressources pour architectes et développeurs de solutions multilocataires.