Perspective d’Azure Well-Architected Framework sur Azure App Service (Web Apps)
Azure App Service est une solution de calcul PaaS (Platform as a Service) que vous pouvez utiliser pour héberger votre charge de travail sur la plateforme Azure. Il s’agit d’un service entièrement managé qui extrait le calcul sous-jacent et décharge la responsabilité de la création, du déploiement et de la mise à l’échelle sur la plateforme. Un App Service s’exécute toujours dans un plan App Service. Le plan de service que vous choisissez détermine la région dans laquelle la charge de travail s’exécute, les configurations de calcul et le système d’exploitation. Plusieurs modèles de facturation sont disponibles pour App Service.
Cet article suppose qu’en tant qu’architecte, vous avez examiné l’arbre de décision de calcul et choisi App Service comme calcul pour votre charge de travail. Les conseils de cet article fournissent des recommandations architecturales mappées aux principes des piliers azure Well-Architected Framework.
Important
Guide pratique pour utiliser ce guide
Chaque section possède une liste de case activée de conception qui présente des domaines d’intérêt architecturaux, ainsi que des stratégies de conception localisées dans l’étendue technologique.
Il y a également des recommandations sur les fonctionnalités technologiques qui peuvent aider à matérialiser ces stratégies. Les recommandations ne représentent pas une liste exhaustive de toutes les configurations disponibles pour la fonctionnalité Web Apps d’Azure App Service et leurs dépendances. Au lieu de cela, ils répertorient les recommandations clés mappées aux perspectives de conception. Utilisez les recommandations pour créer votre preuve de concept ou optimiser vos environnements existants.
Architecture fondamentale qui illustre les recommandations clés : architecture de base App Service.
Étendue de la technologie
Cette révision se concentre sur les décisions liées aux ressources Azure suivantes :
- Plans App Service
- Web Apps
D’autres offres Azure sont associées à App Service, telles qu’Azure Functions, Azure Logic Apps et App Service Environment. Ces offres sont hors de portée pour cet article. App Service Environment est référencé occasionnellement pour aider à clarifier les fonctionnalités ou options des offres App Service principales.
Fiabilité
L’objectif du pilier fiabilité est de fournir des fonctionnalités continues en générant suffisamment de résilience et en permettant de récupérer rapidement des défaillances.
Les principes de conception de fiabilité fournissent une stratégie de conception de haut niveau appliquée aux composants individuels, aux flux système et au système dans son ensemble.
Check-list pour la conception
Démarrez votre stratégie de conception en fonction de la révision de conception case activée liste pour la fiabilité. Déterminez sa pertinence pour vos besoins métier tout en gardant à l’esprit les niveaux et fonctionnalités d’App Service et de ses dépendances. Étendez la stratégie pour inclure davantage d’approches en fonction des besoins.
Hiérarchiser les flux utilisateur : tous les flux ne sont pas tout aussi critiques. Attribuez des priorités à chaque flux pour guider vos décisions de conception. La conception de flux utilisateur peut influencer les niveaux de service et le nombre d’instances que vous choisissez pour un plan et une configuration App Service.
Par exemple, votre application peut inclure des niveaux frontaux et back-end qui communiquent via un répartiteur de messages. Vous pouvez choisir de segmenter les niveaux dans plusieurs applications web pour permettre une mise à l’échelle, une gestion du cycle de vie et une maintenance indépendantes. Placer une grande application dans un seul plan peut entraîner des problèmes de mémoire ou d’UC et affecter la fiabilité.
Vous devrez peut-être plus d’instances sur le front-end pour optimiser les performances côté interface utilisateur. Toutefois, le serveur principal peut ne pas nécessiter le même nombre d’instances.
Anticiper les défaillances potentielles : planifier des stratégies d’atténuation pour les défaillances potentielles. Le tableau suivant présente des exemples d’analyse du mode d’échec.
Échec Limitation des risques Échec des composants App Service sous-jacents ou abstraits Disposer d’une redondance de composant dans les instances et les dépendances. Surveillez l’intégrité des instances, des performances réseau et des performances de stockage. Échec des dépendances externes Utilisez des modèles de conception tels que le modèle Nouvelle tentative et le modèle Disjoncteur. Surveillez les dépendances externes et définissez les délais d’expiration appropriés. Échec en raison du trafic acheminé vers des instances non saines Surveiller l’intégrité de l’instance. Tenez compte de la réactivité et évitez d’envoyer des requêtes à des instances non saines. Pour plus d’informations, consultez l’analyse du mode échec pour les applications Azure.
Redondance de build : générer la redondance dans l’application et l’infrastructure de prise en charge. Répartir les instances entre les zones de disponibilité pour améliorer la tolérance de panne. Le trafic est acheminé vers d’autres zones si une zone échoue. Déployez votre application dans plusieurs régions pour vous assurer que votre application reste disponible, même si une région entière subit une panne.
Créez des niveaux similaires de redondance dans les services dépendants. Par exemple, les instances d’application se lient au stockage d’objets blob. Envisagez de configurer le compte de stockage associé avec un stockage redondant interzone (ZRS) si une application utilise un déploiement redondant interzone.
Disposer d’une redondance dans les composants réseau. Par exemple, utilisez des adresses IP redondantes interzone et des équilibreurs de charge.
Avoir une stratégie de mise à l’échelle fiable : une charge inattendue sur une application peut la rendre peu fiable. Considérez l’approche de mise à l’échelle appropriée en fonction des caractéristiques de votre charge de travail. Vous pouvez parfois effectuer un scale-up pour gérer la charge. Toutefois, si la charge continue d’augmenter, effectuez un scale-out vers de nouvelles instances. Préférez la mise à l’échelle automatique par rapport aux approches manuelles. Conservez toujours une mémoire tampon de capacité supplémentaire pendant les opérations de mise à l’échelle pour éviter la dégradation des performances.
Le niveau de plan App Service que vous choisissez affecte la mise à l’échelle en termes de nombre d’instances et d’unités de calcul.
Assurez-vous que l’initialisation d’application appropriée afin que les nouvelles instances se réchauffent rapidement et puissent recevoir des demandes.
S’efforcez d’utiliser des applications sans état dans la mesure du possible. L’état de mise à l’échelle fiable avec de nouvelles instances peut augmenter la complexité. Considérez un magasin de données externe que vous pouvez mettre à l’échelle indépendamment si vous devez stocker l’état de l’application. Le stockage de l’état de session en mémoire peut entraîner la perte de l’état de la session en cas de problème avec l’application ou App Service. Elle limite également la possibilité de répartir la charge entre d’autres instances.
Testez régulièrement vos règles de mise à l’échelle automatique. Simuler des scénarios de charge pour vérifier que votre application est mise à l’échelle comme prévu. Vous devez journaliser les événements de mise à l’échelle afin de pouvoir résoudre les problèmes qui peuvent survenir et optimiser votre stratégie de mise à l’échelle au fil du temps.
App Service a une limitation sur le nombre d’instances au sein d’un plan, ce qui peut affecter la fiabilité de la mise à l’échelle. Une stratégie consiste à utiliser des tampons de déploiement identiques, chaque instance de plan App Service en cours d’exécution avec son propre point de terminaison. Il est essentiel que vous frontiez tous les tampons avec un équilibreur de charge externe pour distribuer le trafic entre eux. Utilisez Azure Application Gateway pour les déploiements à zone unique et Azure Front Door pour les déploiements multirégions. Cette approche est idéale pour les applications stratégiques où la fiabilité est cruciale. Pour plus d’informations, consultez la base de référence stratégique avec App Service.
Un plan App Service distribue le trafic entre les instances et surveille leur intégrité. Notez que l’équilibreur de charge externe peut ne pas détecter immédiatement si une instance échoue.
Planifiez votre récupération : la redondance est essentielle pour la continuité de l’activité. Basculez vers une autre instance si une instance est inaccessible. Explorez les fonctionnalités de guérison automatique dans App Service, telles que la réparation automatique des instances.
Implémentez des modèles de conception pour gérer la dégradation normale des deux défaillances temporaires, telles que les problèmes de connectivité réseau et les événements à grande échelle tels que les pannes régionales. Tenez compte des modèles de conception suivants :
Le modèle bulkhead segmente votre application en groupes isolés pour empêcher une défaillance d’affecter l’ensemble du système.
Les files d’attente du modèle de nivellement de charge basé sur la file d’attente fonctionnent en tant qu’éléments de travail qui servent de mémoire tampon pour faciliter les pics de trafic.
Le modèle Nouvelle tentative gère les échecs temporaires en raison de problèmes réseau, de connexions de base de données supprimées ou de services occupés.
Le modèle Disjoncteur empêche une application d’essayer à plusieurs reprises d’effectuer une opération susceptible d’échouer.
Vous pouvez utiliser webJobs pour exécuter des tâches en arrière-plan dans votre application web. Pour exécuter ces tâches de manière fiable, assurez-vous que l’application qui héberge votre travail s’exécute en continu selon une planification ou en fonction des déclencheurs pilotés par les événements.
Pour plus d’informations, consultez Modèles de fiabilité.
Effectuer des tests de fiabilité : effectuez des tests de charge pour évaluer la fiabilité et les performances de votre application sous charge. Les plans de test doivent inclure des scénarios qui valident vos opérations de récupération automatisées.
Utilisez l’injection de pannes pour introduire intentionnellement des défaillances et valider vos mécanismes d’auto-guérison et de conservation. Explorez la bibliothèque d’erreurs fournie par Azure Chaos Studio.
App Service impose des limites de ressources sur les applications hébergées. Le plan App Service détermine ces limites. Assurez-vous que vos tests vérifient que l’application s’exécute dans ces limites de ressources. Pour plus d’informations, consultez Abonnement Azure et limites, quotas et contraintes de service.
Utilisez des sondes d’intégrité pour identifier les workers non réactifs : App Service dispose de fonctionnalités intégrées qui effectuent régulièrement un test ping sur un chemin spécifique de votre application web. Les instances sans réponse sont supprimées de l’équilibreur de charge et remplacées par une nouvelle instance.
Recommandations
| Recommandation | Avantage |
|---|---|
| (Plan App Service) Choisissez le niveau Premium d’un plan App Service pour les charges de travail de production. Définissez le nombre maximal et minimal de travailleurs en fonction de votre planification de capacité. Pour plus d’informations, consultez la vue d’ensemble du plan App Service. |
Un plan App Service Premium offre des fonctionnalités de mise à l’échelle avancées et garantit la redondance si des défaillances se produisent. |
| (Plan App Service) Activez la redondance de zone. Envisagez de provisionner plus de trois instances pour améliorer la tolérance de panne. Vérifiez la prise en charge régionale de la redondance de zone, car toutes les régions n’offrent pas cette fonctionnalité. |
Votre application peut résister aux défaillances dans une seule zone lorsque plusieurs instances sont réparties entre les zones. Le trafic passe automatiquement à des instances saines dans d’autres zones et maintient la fiabilité de l’application si une zone n’est pas disponible. |
| (App Service) Envisagez de désactiver la fonctionnalité d’affinité de routage des demandes d’application (ARR). L’affinité ARR crée des sessions sticky qui redirigent les utilisateurs vers le nœud qui a géré leurs demandes précédentes. | Les requêtes entrantes sont réparties uniformément entre tous les nœuds disponibles lorsque vous désactivez l’affinité ARR. Les requêtes distribuées uniformément empêchent le trafic d’accablant n’importe quel nœud unique. Les requêtes peuvent être redirigées en toute transparence vers d’autres nœuds sains si un nœud n’est pas disponible. Évitez l’affinité de session pour vous assurer que votre instance App Service reste sans état. Un App Service sans état réduit la complexité et garantit un comportement cohérent entre les nœuds. Supprimez les sessions sticky afin que App Service puisse ajouter ou supprimer des instances à mettre à l’échelle horizontalement. |
| (App Service) Définissez des règles de guérison automatique basées sur le nombre de demandes, les requêtes lentes, les limites de mémoire et d’autres indicateurs qui font partie de votre base de référence de performances. Considérez cette configuration dans le cadre de votre stratégie de mise à l’échelle. | Les règles de guérison automatique aident votre application à récupérer automatiquement des problèmes inattendus. Les règles configurées déclenchent des actions de guérison lorsque des seuils sont enfreints. La réparation automatique permet une maintenance proactive automatique. |
| (App Service) Activez la fonctionnalité de case activée d’intégrité et fournissez un chemin d’accès qui répond aux demandes d’intégrité case activée. | Les case activée d’intégrité peuvent détecter les problèmes précoces. Ensuite, le système peut effectuer automatiquement des actions correctives lorsqu’une demande d’intégrité case activée échoue. L’équilibreur de charge achemine le trafic loin des instances non saines, ce qui dirige les utilisateurs vers des nœuds sains. |
Sécurité
L’objectif du pilier sécurité est de fournir des garanties de confidentialité, d’intégrité et de disponibilité à la charge de travail.
Les principes de conception de la sécurité fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs en appliquant des approches à la conception technique autour de l’hébergement sur App Service.
Check-list pour la conception
Démarrez votre stratégie de conception en fonction de la révision de conception case activée list pour la sécurité et identifiez les vulnérabilités et les contrôles pour améliorer la posture de sécurité. Étendez la stratégie pour inclure davantage d’approches en fonction des besoins.
Passez en revue les bases de référence de sécurité : pour améliorer la posture de sécurité de votre application hébergée sur un plan App Service, passez en revue la base de référence de sécurité pour App Service.
Utilisez les derniers runtimes et bibliothèques : testez soigneusement les builds de votre application avant d’effectuer des mises à jour pour détecter les problèmes au début et garantir une transition fluide vers la nouvelle version. App Service prend en charge la stratégie de prise en charge du runtime de langage pour la mise à jour des piles existantes et la mise hors service des piles de fin de prise en charge.
Créez une segmentation par le biais de limites d’isolation pour contenir une violation : appliquez la segmentation des identités. Par exemple, implémentez le contrôle d’accès en fonction du rôle (RBAC) pour attribuer des autorisations spécifiques en fonction des rôles. Suivez le principe du privilège minimum pour limiter les droits d’accès aux seuls éléments nécessaires. Créez également une segmentation au niveau du réseau. Injectez des applications App Service dans un réseau virtuel Azure pour l’isolation et définissez des groupes de sécurité réseau (NSG) pour filtrer le trafic.
Les plans App Service offrent le niveau Environnement App Service qui fournit un degré élevé d’isolation. Avec App Service Environment, vous bénéficiez d’un calcul et d’une mise en réseau dédiés.
Appliquez des contrôles d’accès sur les identités : limitez l’accès vers l’intérieur de l’application web et l’accès sortant de l’application web à d’autres ressources. Cette configuration applique des contrôles d’accès sur les identités et permet de maintenir la posture de sécurité globale de la charge de travail.
Utilisez l’ID Microsoft Entra pour tous les besoins d’authentification et d’autorisation. Utilisez des rôles intégrés, tels qu’un contributeur de plan web, un contributeur de site web et un contributeur générique, un lecteur et un propriétaire.
Contrôler le trafic réseau vers et depuis l’application : n’exposez pas les points de terminaison d’application à l’Internet public. Au lieu de cela, ajoutez un point de terminaison privé sur l’application web placée dans un sous-réseau dédié. Frontez votre application avec un proxy inverse qui communique avec ce point de terminaison privé. Envisagez d’utiliser Application Gateway ou Azure Front Door à cet effet.
Déployez un pare-feu d’applications web (WAF) pour vous protéger contre les vulnérabilités courantes. Application Gateway et Azure Front Door ont des fonctionnalités WAF intégrées.
Configurez les règles de proxy inverse et les paramètres réseau de manière appropriée pour atteindre le niveau de sécurité et de contrôle souhaité. Par exemple, ajoutez des règles de groupe de sécurité réseau sur le sous-réseau de point de terminaison privé pour accepter uniquement le trafic à partir du proxy inverse.
Le trafic de sortie de l’application vers d’autres services PaaS doit se trouver sur des points de terminaison privés. Envisagez de placer un composant de pare-feu pour restreindre le trafic de sortie vers l’Internet public. Les deux approches empêchent l’exfiltration des données.
Pour une vue complète, consultez les fonctionnalités de mise en réseau App Service.
Chiffrer les données : protégez les données en transit avec TLS (Transport Layer Security) de bout en bout. Utilisez vos clés gérées par le client pour le chiffrement complet des données au repos. Pour plus d’informations, consultez Chiffrement au repos à l’aide de clés gérées par le client.
N’utilisez pas de protocoles hérités tels que TLS 1.0 et 1.1. App Service active la version 1.2 par défaut. Pour plus d’informations, consultez la vue d’ensemble du protocole TLS App Service.
Toutes les instances de votre App Service ont un nom de domaine par défaut. Utilisez un domaine personnalisé et sécurisez ce domaine avec des certificats.
Réduisez la surface d’attaque : supprimez les configurations par défaut dont vous n’avez pas besoin. Par exemple, désactivez le débogage à distance, l’authentification locale pour les sites SCM (Source Control Manager) et l’authentification de base. Désactivez les protocoles non sécurisés tels que HTTP et FTP (File Transfer Protocol). Appliquer des configurations via des stratégies Azure. Pour plus d’informations, consultez stratégies Azure.
Implémentez des stratégies de partage de ressources cross-origin restrictives (CORS) : utilisez des stratégies CORS restrictives dans votre application web pour accepter uniquement les demandes des domaines, en-têtes et autres critères autorisés. Appliquez des stratégies CORS avec des définitions de stratégie Azure intégrées.
Protéger les secrets d’application : vous devez gérer des informations sensibles, telles que des clés API ou des jetons d’authentification. Au lieu de coder en dur ces secrets directement dans votre code d’application ou vos fichiers de configuration, vous pouvez utiliser des références Azure Key Vault dans les paramètres de l’application. Au démarrage de l’application, App Service récupère automatiquement les valeurs secrètes à partir de Key Vault à l’aide de l’identité managée de l’application.
Activez les journaux de ressources pour votre application : activez les journaux de ressources de votre application pour créer des pistes d’activité complètes qui fournissent des données précieuses pendant les enquêtes qui suivent les incidents de sécurité.
Envisagez la journalisation dans le cadre de votre processus de modélisation des menaces lorsque vous évaluez les menaces.
Recommandations
| Recommandation | Avantage |
|---|---|
| (App Service) Affectez des identités managées à l’application web. Pour maintenir les limites d’isolation, ne partagez pas ni ne réutilisez les identités entre les applications. Veillez à vous connecter en toute sécurité à votre registre de conteneurs si vous utilisez des conteneurs pour votre déploiement. |
L’application récupère les secrets de Key Vault pour authentifier la communication vers l’extérieur de l’application. Azure gère l’identité et ne vous oblige pas à provisionner ou à faire pivoter des secrets. Vous avez des identités distinctes pour la granularité du contrôle. Les identités distinctes facilitent la révocation si une identité est compromise. |
| (App Service) Configurez des domaines personnalisés pour les applications. Désactivez HTTP et acceptez uniquement les requêtes HTTPS. |
Les domaines personnalisés permettent une communication sécurisée via HTTPS à l’aide du protocole TLS (Transport Layer Security), ce qui garantit la protection des données sensibles et génère la confiance des utilisateurs. |
| (App Service) évalue si l’authentification intégrée App Service est le bon mécanisme pour authentifier les utilisateurs qui accèdent à votre application. L’authentification intégrée App Service s’intègre à l’ID Microsoft Entra. Cette fonctionnalité gère la validation des jetons et la gestion des identités utilisateur sur plusieurs fournisseurs de connexion et prend en charge les Connecter OpenID. Avec cette fonctionnalité, vous n’avez pas d’autorisation à un niveau granulaire et vous n’avez pas de mécanisme pour tester l’authentification. | Lorsque vous utilisez cette fonctionnalité, vous n’avez pas besoin d’utiliser des bibliothèques d’authentification dans le code d’application, ce qui réduit la complexité. L’utilisateur est déjà authentifié lorsqu’une demande atteint l’application. |
| (App Service) Configurez l’application pour l’intégration de réseau virtuel. Utilisez des points de terminaison privés pour les applications App Service. Bloquer tout le trafic public. Routez l’image conteneur par extraction via l’intégration du réseau virtuel. Tout le trafic sortant de l’application passe par le réseau virtuel. |
Bénéficiez des avantages de sécurité de l’utilisation d’un réseau virtuel Azure. Par exemple, l’application peut accéder en toute sécurité aux ressources au sein du réseau. Ajoutez un point de terminaison privé pour protéger votre application. Les points de terminaison privés limitent l’exposition directe au réseau public et autorisent l’accès contrôlé via le proxy inverse. |
| (App Service) Pour implémenter le renforcement : - Désactivez l’authentification de base qui utilise un nom d’utilisateur et un mot de passe en faveur de l’authentification basée sur l’ID Microsoft Entra. - Désactivez le débogage distant afin que les ports entrants ne soient pas ouverts. - Activer les stratégies CORS pour renforcer les demandes entrantes. - Désactivez les protocoles, tels que FTP. |
Nous vous déconseillons d’utiliser l’authentification de base comme méthode de déploiement sécurisée. Microsoft Entra ID utilise l’authentification basée sur des jetons OAuth 2.0, qui offre de nombreux avantages et améliorations qui répondent aux limitations associées à l’authentification de base. Les stratégies limitent l’accès aux ressources d’application, autorisent uniquement les requêtes provenant de domaines spécifiques et sécurisent les requêtes interrégions. |
| (App Service) Utilisez toujours les références Key Vault comme paramètres d’application. |
Les secrets sont conservés séparément de la configuration de votre application. Les paramètres de l’application sont chiffrés au repos. App Service gère également les rotations de secrets. |
| (Plan App Service) Activez Microsoft Defender pour le cloud pour App Service. | Bénéficiez d’une protection en temps réel pour les ressources qui s’exécutent dans un plan App Service. Protégez-vous contre les menaces et améliorez votre posture de sécurité globale. |
| (Plan App Service) Activez la journalisation des diagnostics et ajoutez l’instrumentation à votre application. Les journaux d’activité sont envoyés à Stockage Azure comptes, Azure Event Hubs et Log Analytics. Pour plus d’informations sur les types de journaux d’audit, consultez Types de journaux pris en charge. | La journalisation capture les modèles d’accès. Il enregistre les événements pertinents qui fournissent des insights précieux sur la façon dont les utilisateurs interagissent avec une application ou une plateforme. Ces informations sont cruciales à des fins de responsabilité, de conformité et de sécurité. |
Optimisation des coûts
L’optimisation des coûts se concentre sur la détection des modèles de dépense, la hiérarchisation des investissements dans les domaines critiques et l’optimisation dans d’autres pour répondre au budget de l’organisation tout en répondant aux besoins de l’entreprise.
Les principes de conception d’optimisation des coûts fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs et faire des compromis si nécessaire dans la conception technique liée à vos applications web et à l’environnement dans lequel ils s’exécutent.
Check-list pour la conception
Démarrez votre stratégie de conception en fonction de la révision de conception case activée list pour l’optimisation des coûts pour les investissements et ajustez la conception afin que la charge de travail soit alignée sur le budget alloué pour la charge de travail. Votre conception doit utiliser les fonctionnalités Azure appropriées, surveiller les investissements et trouver des opportunités d’optimisation au fil du temps.
Estimer le coût initial : dans le cadre de votre exercice de modélisation des coûts, utilisez la calculatrice de prix Azure pour évaluer les coûts approximatifs associés à différents niveaux en fonction du nombre d’instances que vous envisagez d’exécuter. Chaque niveau App Service offre différentes options de calcul.
Surveillez en permanence le modèle de coût pour suivre les dépenses.
Évaluez les options remises : les niveaux supérieurs incluent des instances de calcul dédiées. Vous pouvez appliquer une remise de réservation si votre charge de travail a un modèle d’utilisation prévisible et cohérent. Veillez à analyser les données d’utilisation pour déterminer le type de réservation qui convient à votre charge de travail. Pour plus d’informations, consultez Enregistrer les coûts avec les instances réservées App Service.
Comprendre les compteurs d’utilisation : Azure facture un taux horaire, au prorata de la seconde, en fonction du niveau tarifaire de votre plan App Service. Les frais s’appliquent à chaque instance avec montée en puissance parallèle dans votre plan, en fonction de l’heure à laquelle vous allouez l’instance de machine virtuelle. Faites attention aux ressources de calcul sous-utilisées susceptibles d’augmenter vos coûts en raison d’une surallocation en raison d’une sélection de référenceS SKU non optimale ou d’une configuration de scale-in mal configurée.
Des fonctionnalités App Service supplémentaires, telles que l’inscription de domaine personnalisée et les certificats personnalisés, peuvent ajouter des coûts. D’autres ressources, telles que des réseaux virtuels, pour isoler votre solution ou vos coffres de clés pour protéger les secrets de charge de travail, qui s’intègrent à vos ressources App Service peuvent également ajouter des coûts. Pour plus d’informations, consultez le modèle de facturation App Services.
Tenez compte des compromis entre densité et isolation : vous pouvez utiliser des plans App Service pour héberger plusieurs applications sur le même calcul, ce qui permet d’économiser des coûts avec des environnements partagés. Pour plus d’informations, consultez Compromis.
Évaluez l’effet de votre stratégie de mise à l’échelle sur les coûts : vous devez concevoir, tester et configurer correctement pour effectuer un scale-out et une mise à l’échelle lorsque vous implémentez la mise à l’échelle automatique. Établissez des limites maximales et minimales précises sur la mise à l’échelle automatique.
Initialisez de manière proactive l’application pour une mise à l’échelle fiable. Par exemple, n’attendez pas que le processeur atteigne 95 % d’utilisation. Au lieu de cela, déclenchez la mise à l’échelle à environ 65 % pour permettre à de nouvelles instances d’être allouées et initialisées pendant le processus de mise à l’échelle. Toutefois, cette stratégie peut entraîner une capacité inutilisée.
Nous vous recommandons de combiner et d’équilibrer les mécanismes de montée en puissance et de scale-out. Par exemple, une application peut effectuer un scale-up pendant un certain temps, puis effectuer un scale-out si nécessaire. Explorez les niveaux élevés qui offrent une grande capacité et une utilisation efficace des ressources. En fonction des modèles d’utilisation, les niveaux Premium supérieurs sont souvent plus rentables, car ils sont plus capables.
Optimiser les coûts d’environnement : envisagez le niveau De base ou Gratuit pour exécuter des environnements de préproduction. Ces niveaux sont des performances faibles et des coûts faibles. Si vous utilisez le niveau De base ou Gratuit, utilisez la gouvernance pour appliquer le niveau, limitez le nombre d’instances et de processeurs, limitez la mise à l’échelle et limitez la rétention des journaux.
Implémenter des modèles de conception : cette stratégie réduit le volume de requêtes générées par votre charge de travail. Envisagez d’utiliser des modèles tels que les back-ends pour les modèles frontaux et le modèle d’agrégation de passerelle, ce qui peut réduire le nombre de requêtes et réduire les coûts.
Régulièrement case activée coûts liés aux données : des périodes de rétention des données prolongées ou des niveaux de stockage coûteux peuvent entraîner des coûts de stockage élevés. D’autres dépenses peuvent s’accumuler en raison de l’utilisation de la bande passante et de la conservation prolongée des données de journalisation.
Envisagez d’implémenter la mise en cache pour réduire les coûts de transfert de données. Commencez par la mise en cache en mémoire locale, puis explorez les options de mise en cache distribuée pour réduire le nombre de requêtes adressées à la base de données principale. Tenez compte des coûts de trafic de bande passante associés à la communication entre régions si votre base de données se trouve dans une autre région.
Optimiser les coûts de déploiement : tirez parti des emplacements de déploiement pour optimiser les coûts. L’emplacement s’exécute dans le même environnement de calcul que l’instance de production. Utilisez-les de manière stratégique pour les scénarios tels que les déploiements bleu-vert qui basculent entre les emplacements. Cette approche réduit les temps d’arrêt et garantit des transitions fluides.
Utilisez des emplacements de déploiement avec précaution. Vous pouvez introduire des problèmes, tels que des exceptions ou des fuites de mémoire, susceptibles d’affecter les instances existantes et les nouvelles instances. Vérifiez que vous testez soigneusement les modifications. Pour obtenir des conseils opérationnels, consultez l’excellence opérationnelle.
Recommandations
| Recommandation | Avantage |
|---|---|
| (Plan App Service) Choisissez les niveaux Gratuit ou De base pour les environnements inférieurs. Nous recommandons ces niveaux pour une utilisation expérimentale. Supprimez les niveaux quand vous n’en avez plus besoin. | Les niveaux Gratuit et De base sont abordables par rapport aux niveaux supérieurs. Ils fournissent une solution économique pour les environnements hors production qui n’ont pas besoin des fonctionnalités complètes et des performances des plans Premium. |
| (Plan App Service) Tirez parti des remises et explorez les tarifs préférés pour : - Environnements inférieurs avec des plans de développement/test. - Réservations Azure et plans d’épargne Azure pour le calcul dédié que vous approvisionnez dans le niveau Premium V3 et App Service Environment. Utilisez des instances réservées pour les charges de travail stables qui ont des modèles d’utilisation prévisibles. |
Les plans de développement/test fournissent des tarifs réduits pour les services Azure, ce qui les rend rentables pour les environnements hors production. Utilisez des instances réservées pour prépayer les ressources de calcul et obtenir des remises significatives. |
| (App Service) Surveillez les coûts que les ressources App Service entraînent. Exécutez l’outil d’analyse des coûts dans le Portail Azure. Créez des budgets et des alertes pour informer les parties prenantes. |
Vous pouvez identifier les pics de coûts, les inefficacités ou les dépenses inattendues au début. Cette approche proactive vous aide à fournir des contrôles budgétaires pour éviter les dépassements de dépenses. |
| (Plan App Service) Mettre à l’échelle lorsque la demande diminue. Pour effectuer une mise à l’échelle, définissez des règles de mise à l’échelle pour réduire le nombre d’instances dans Azure Monitor. | Empêchez les gaspillages et réduisez les dépenses inutiles. |
Excellence opérationnelle
L’excellence opérationnelle se concentre principalement sur les procédures de développement, l’observabilité et la gestion des mises en production.
Les principes de conception d’excellence opérationnelle fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs vers les exigences opérationnelles de la charge de travail.
Check-list pour la conception
Démarrez votre stratégie de conception en fonction de la révision de conception case activée liste pour l’excellence opérationnelle pour définir des processus d’observabilité, de test et de déploiement liés à Web Apps.
Gérer les versions : utilisez des emplacements de déploiement pour gérer efficacement les mises en production. Vous pouvez déployer votre application sur un emplacement, effectuer des tests et valider ses fonctionnalités. Après vérification, vous pouvez déplacer l’application en production en toute transparence. Ce processus n’entraîne pas de coûts supplémentaires, car l’emplacement s’exécute dans le même environnement de machine virtuelle que l’instance de production.
Exécuter des tests automatisés : avant de promouvoir une version de votre application web, testez soigneusement ses performances, ses fonctionnalités et son intégration à d’autres composants. Utilisez Azure Load Testing, qui s’intègre à Apache JMeter, un outil populaire pour les tests de performances. Explorez les outils automatisés pour d’autres types de tests, tels que Fantôme pour les tests fonctionnels.
Déployer des unités immuables : implémentez le modèle Tampons de déploiement pour compartimenter App Service dans un tampon immuable. App Service prend en charge l’utilisation de conteneurs, qui sont intrinsèquement immuables. Envisagez des conteneurs personnalisés pour votre application web App Service.
Chaque tampon représente une unité autonome dans laquelle vous pouvez rapidement effectuer un scale-out ou un scale-in. Les unités basées sur ce tampon sont temporaires et sans état. La conception sans état simplifie les opérations et la maintenance. Cette approche est idéale pour les applications stratégiques. Pour obtenir un exemple, consultez la base de référence critique pour la mission avec App Service.
Utilisez une technologie IaC (Infrastructure as code), telle que Bicep, pour horodatage d’unités avec répétabilité et cohérence.
Sécuriser les environnements de production : créez des plans App Service distincts pour exécuter des environnements de production et de préproduction. N’apportez pas de modifications directement dans l’environnement de production pour garantir la stabilité et la fiabilité. Les instances distinctes permettent une flexibilité dans le développement et les tests avant de promouvoir les modifications apportées à la production.
Utilisez des environnements faibles pour explorer de nouvelles fonctionnalités et configurations de manière isolée. Conservez les environnements de développement et de test éphémères.
Gérer les certificats : pour les domaines personnalisés, vous devez gérer les certificats TLS.
Disposer de processus en place pour obtenir, renouveler et valider des certificats. Déchargez ces processus sur App Service si possible. Si vous utilisez votre propre certificat, vous devez gérer son renouvellement. Choisissez une approche qui s’aligne le mieux sur vos exigences de sécurité.
| Recommandation | Avantage |
|---|---|
| (App Service) Surveillez l’intégrité de vos instances et activez les sondes d’intégrité d’instance. Configurez un chemin spécifique pour gérer les demandes de sonde d’intégrité. |
Vous pouvez détecter rapidement les problèmes et prendre les mesures nécessaires pour maintenir la disponibilité et les performances. |
| (App Service) Activez les journaux de diagnostic pour l’application et l’instance. La journalisation fréquente peut ralentir les performances du système, ajouter aux coûts de stockage et introduire des risques si vous avez un accès non sécurisé aux journaux. Suivez ces bonnes pratiques : - Journaliser le niveau d’informations approprié. - Définir des stratégies de rétention. - Conservez une piste d’audit de l’accès autorisé et des tentatives non autorisées. - Traitez les journaux en tant que données et appliquez des contrôles de protection des données. |
Les journaux de diagnostic fournissent des insights précieux sur le comportement de votre application. Surveillez les modèles de trafic et identifiez les anomalies. |
| (App Service) Tirez parti des certificats managés App Service pour décharger la gestion des certificats sur Azure. | App Service gère automatiquement les processus tels que l’approvisionnement de certificats, la vérification des certificats, le renouvellement de certificat et l’importation de certificats à partir de Key Vault. Vous pouvez également charger votre certificat dans Key Vault et autoriser le fournisseur de ressources App Service à y accéder. |
| (Plan App Service) Validez les modifications apportées à l’application dans l’emplacement intermédiaire avant de l’échanger avec l’emplacement de production. | Évitez les temps d’arrêt et les erreurs. Revenez rapidement à l’état correct connu si vous détectez un problème après un échange. |
Efficacité des performances
L’efficacité des performances consiste à maintenir l’expérience utilisateur même en cas d’augmentation de la charge en gérant la capacité. La stratégie inclut la mise à l’échelle des ressources, l’identification et l’optimisation des goulots d’étranglement potentiels et l’optimisation des performances maximales.
Les principes de conception d’efficacité des performances fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs de capacité par rapport à l’utilisation attendue.
Check-list pour la conception
Démarrez votre stratégie de conception en fonction de la révision de conception case activée list pour l’efficacité des performances pour définir une base de référence basée sur les indicateurs de performances clés pour Web Apps.
Identifiez et surveillez les indicateurs de performances : définissez des cibles pour les indicateurs clés de l’application, tels que le volume de requêtes entrantes, le temps nécessaire à l’application pour répondre aux demandes, aux requêtes en attente et aux erreurs dans les réponses HTTP. Considérez les indicateurs clés dans le cadre de la base de référence des performances de la charge de travail.
Capturez les métriques App Service qui constituent la base des indicateurs de performances. Collectez les journaux pour obtenir des insights sur l’utilisation des ressources et les activités. Utilisez des outils de surveillance des performances des applications (APM), tels que l’application Recommandations, pour collecter et analyser les données de performances à partir de l’application. Pour plus d’informations, consultez la référence des données de surveillance App Service.
Incluez l’instrumentation au niveau du code, le suivi des transactions et le profilage des performances.
Évaluer la capacité : simuler différents scénarios utilisateur pour déterminer la capacité optimale dont vous avez besoin pour gérer le trafic attendu. Utilisez le test de charge pour comprendre comment votre application se comporte sous différents niveaux de charge.
Sélectionnez le niveau approprié : utilisez le calcul dédié pour les charges de travail de production. Les niveaux Premium offrent des références SKU plus volumineuses avec une capacité de mémoire et d’UC accrue, plus d’instances et plus de fonctionnalités, telles que la redondance de zone. Pour plus d’informations, consultez le niveau tarifaire Premium V3.
Optimisez votre stratégie de mise à l’échelle : dans la mesure du possible, utilisez la mise à l’échelle automatique au lieu d’ajuster manuellement le nombre d’instances au fur et à mesure que la charge de l’application change. Avec la mise à l’échelle automatique, App Service ajuste la capacité du serveur en fonction de règles ou de déclencheurs prédéfinis. Veillez à effectuer des tests de performances adéquats et à définir les règles appropriées pour les déclencheurs appropriés.
Si vous hiérarchisez la simplicité pendant la configuration initiale, utilisez une option de mise à l’échelle automatique qui ne vous oblige pas à définir des règles et que vous devez uniquement définir des limites.
Disposer de ressources suffisantes pour garantir des performances optimales. Allouez les ressources de manière appropriée pour maintenir des cibles de performances, telles que le temps de réponse ou le débit. Envisagez la surallocation des ressources si nécessaire.
Lorsque vous définissez des règles de mise à l’échelle automatique, comptez le temps nécessaire à l’initialisation de votre application. Tenez compte de cette surcharge lorsque vous prenez toutes les décisions de mise à l’échelle.
Utiliser la mise en cache : la récupération d’informations à partir d’une ressource qui ne change pas fréquemment et qui est coûteuse pour accéder affecte les performances. Les requêtes complexes, y compris les jointures et plusieurs recherches, contribuent à l’exécution. Effectuez la mise en cache pour réduire le temps de traitement et la latence. Cachez les résultats des requêtes pour éviter les allers-retours répétés vers la base de données ou le serveur principal et réduire le temps de traitement des requêtes suivantes.
Pour plus d’informations sur l’utilisation du cache local et distribué dans la charge de travail, consultez Mise en cache.
Passez en revue les antimodèles de performances : pour vous assurer que l’application web effectue et met à l’échelle conformément aux exigences de votre entreprise, évitez les antimodèles classiques. Voici quelques antimodèles corrects par App Service.
Anti-modèle Description Front-end occupé Les tâches nécessitant de nombreuses ressources peuvent augmenter les temps de réponse pour les requêtes utilisateur et entraîner une latence élevée.
Déplacez les processus qui consomment de nombreuses ressources sur un serveur principal distinct. Utilisez un répartiteur de messages pour mettre en file d’attente des tâches gourmandes en ressources que le serveur principal récupère de manière asynchrone.Aucune mise en cache Traitez les demandes d’un cache intermédiaire devant la base de données back-end pour réduire la latence. Voisin bruyant Les systèmes multilocataires partagent des ressources entre locataires. L’activité d’un locataire peut avoir un effet négatif sur l’utilisation du système par un autre locataire. App Service Environment fournit un environnement entièrement isolé et dédié pour exécuter des applications App Service.
Recommandations
| Recommandation | Avantage |
|---|---|
| Activez le paramètre Always On lorsque les applications partagent un seul plan App Service. Les applications App Service se déchargent automatiquement lorsqu’elles sont inactives pour enregistrer des ressources. La requête suivante déclenche un démarrage à froid, ce qui peut entraîner des délais d’expiration de requête. | L’application n’est jamais déchargée avec Always On activé. |
| Envisagez d’utiliser HTTP/2 pour les applications afin d’améliorer l’efficacité du protocole. | Choisissez HTTP/2 sur HTTP/1.1, car HTTP/2 multiplexe entièrement les connexions, réutilise les connexions pour réduire la surcharge et compresse les en-têtes pour réduire le transfert de données. |
Compromis
Vous devrez peut-être faire des compromis de conception si vous utilisez les approches dans le pilier case activée lists. Voici quelques exemples d’avantages et d’inconvénients.
Densité et isolation
Densité plus élevée : colocalisez plusieurs applications dans le même plan App Service pour réduire les ressources. Toutes les applications partagent des ressources telles que l’UC et la mémoire, ce qui permet d’économiser de l’argent et de réduire la complexité opérationnelle. Cette approche optimise également l’utilisation des ressources. Les applications peuvent utiliser des ressources inactives d’une autre application si les modèles de chargement changent au fil du temps.
Considérez également les inconvénients. Par exemple, les pics d’utilisation ou d’instabilité d’une application peuvent affecter les performances d’autres applications. Les incidents d’une application peuvent également perméer à d’autres applications au sein de l’environnement partagé, ce qui peut affecter la sécurité.
Isolation plus élevée : l’isolation permet d’éviter les interférences. Cette stratégie s’applique à la sécurité, aux performances et même à la séparation des environnements de développement, de test et de production.
App Service Environment offre un meilleur contrôle sur la sécurité et la protection des données, car chaque application peut avoir ses propres paramètres de sécurité. Votre environnement peut contenir des violations, car l’isolation limite le rayon d’explosion. La contention des ressources est réduite du point de vue des performances. L’isolation permet une mise à l’échelle indépendante en fonction de la demande spécifique et de la planification de la capacité individuelle.
En tant qu’inconvénient, cette approche est plus coûteuse et nécessite une rigueur opérationnelle.
Stratégie de mise à l’échelle fiable
Une stratégie de mise à l’échelle bien définie garantit que votre application peut gérer différentes charges sans compromettre les performances. Toutefois, il y a des compromis sur les coûts. Les opérations de mise à l’échelle prennent du temps. Lorsque de nouvelles ressources sont allouées, l’application doit être correctement initialisée avant de pouvoir traiter efficacement les demandes. Vous pouvez surprovisionner des ressources (instances préliminaires) pour fournir un filet de sécurité. Sans cette capacité supplémentaire, pendant la phase d’initialisation, il peut y avoir un retard dans le traitement des demandes, ce qui affecte l’expérience utilisateur. Les opérations de mise à l’échelle automatique peuvent se déclencher suffisamment tôt pour activer l’initialisation des ressources appropriée au moment où les clients utilisent les ressources.
En guise d’inconvénient, les ressources surprovisionnés coûtent plus cher. Vous êtes facturé par seconde pour chaque instance, y compris les instances préchauffées. Les niveaux supérieurs incluent des instances prédéfinies. Déterminez si les fonctionnalités avec des niveaux plus coûteux valent la peine d’investir.
Redondance de la construction
La redondance offre une résilience, mais entraîne également des coûts. Les objectifs de niveau de service (SLA) de votre charge de travail déterminent les seuils de performances acceptables. Elle devient gaspille si la redondance dépasse les exigences de SLO. Déterminez si l’excès de redondance améliore les slaos ou ajoute une complexité inutile.
Considérez également les inconvénients. Par exemple, la redondance multirégion offre une haute disponibilité, mais ajoute de la complexité et du coût en raison de la synchronisation des données, des mécanismes de basculement et de la communication entre régions. Déterminez si la redondance de zone peut répondre à vos contrats SLA.
Stratégies Azure
Azure fournit un ensemble complet de stratégies intégrées liées à App Service et à ses dépendances. Un ensemble de stratégies Azure peut auditer certaines des recommandations précédentes. Par exemple, vous pouvez case activée si :
Les contrôles réseau appropriés sont en place. Par exemple, vous pouvez incorporer la segmentation du réseau en plaçant App Service dans Azure Réseau virtuel via l’injection de réseau virtuel pour avoir un meilleur contrôle sur la configuration réseau. L’application n’a pas de points de terminaison publics et se connecte aux services Azure via des points de terminaison privés.
Les contrôles d’identité sont en place. Par exemple, l’application utilise des identités managées pour s’authentifier auprès d’autres ressources. L’authentification intégrée App Service (authentification simple) vérifie les demandes entrantes.
Les fonctionnalités telles que le débogage à distance et l’authentification de base sont désactivées pour réduire la surface d’attaque.
Pour une gouvernance complète, passez en revue les définitions intégrées d’Azure Policy et d’autres stratégies susceptibles d’affecter la sécurité de la couche de calcul.
Recommandations Azure Advisor
Azure Advisor est un conseiller cloud personnalisé qui vous aide à suivre les bonnes pratiques pour optimiser vos déploiements Azure. Voici quelques recommandations qui peuvent vous aider à améliorer la fiabilité, la sécurité, l’efficacité des coûts, les performances et l’excellence opérationnelle de vos instances d’application web.
Étapes suivantes
Considérez les articles suivants comme des ressources qui illustrent les recommandations mises en évidence dans cet article.
Utilisez ces architectures de référence comme exemples d’application de ces recommandations à une charge de travail.
Si vous n’avez jamais déployé d’application web, consultez l’application web de base.
Pour une architecture de base comme point de départ d’un déploiement de niveau production, consultez l’application web redondante interzone hautement disponible de référence.
Utilisez la documentation de produit suivante pour créer votre expertise en implémentation :