Partager via


Perspective d’Azure Well-Architected Framework sur Azure App Service (Web Apps)

Azure App Service est une plateforme en tant que service (PaaS) qui fournit un environnement d’hébergement entièrement managé pour la création, le déploiement et la mise à l’échelle d’applications web. En tant que solution PaaS, App Service extrait l’infrastructure sous-jacente, ce qui vous permet de vous concentrer sur votre développement d’applications. App Service (Application web) exécute vos applications dans le contexte d’un plan App Service, qui détermine les ressources, le système d’exploitation, la région et le modèle tarifaire (SKU) utilisé pour héberger votre application.

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 correspondant aux principes des piliers du framework Azure Well-Architected.

Important

Comment utiliser ce guide

Chaque section contient une liste de contrôle de conception en mettant en évidence les considérations et stratégies architecturales pour Azure App Service. Recommandations offrent des conseils spécifiques pour implémenter 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 énumèrent les principales recommandations mappées aux perspectives de conception. Utilisez les recommandations pour créer votre preuve de concept ou optimiser vos environnements existants.

Architecture de base qui illustre les recommandations clés : Architecture de référence App Service.

Champ d'application de la technologie

Cette révision se concentre sur les décisions liées aux ressources Azure suivantes :

  • Plans de service App
  • 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 une fonctionnalité continue en construisant suffisamment de résilience et la capacité de récupérer rapidement en cas de défaillance.

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.

Liste de contrôle de conception

Commencez votre stratégie de conception sur la base de la liste de contrôle de la revue de conception 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. Identifiez les chemins critiques de votre application et 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 Atténuation
    Échec des composants App Service sous-jacents ou abstraits Avoir une redondance de composants 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 patrons de conception tels que le patron de réessai et le patron coupe-circuit . 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 analyse du mode de défaillance pour les applications Azure.

  • Construire la redondance: Construire la redondance dans l'application et l'infrastructure de support. 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 Blob. Envisagez de configurer le compte de stockage associé avec un stockage redondant interzone (ZRS) si une application utilise un déploiement redondant interzone.

  • Utiliser plusieurs instances: Exécuter votre application sur une seule instance constitue un point de défaillance unique qui peut survenir immédiatement. Allouez plusieurs instances à votre application pour garantir la haute disponibilité. En cas d’échec d’une instance, d’autres instances peuvent toujours gérer les requêtes entrantes. N’oubliez pas que votre code d’application doit être en mesure de gérer plusieurs instances sans problèmes de synchronisation lors de la lecture ou de l’écriture dans des sources de données.

    Disposer d’une redondance dans les composants réseau. Par exemple, utilisez des adresses IP redondantes interzone et des équilibreurs de charge.

  • Disposer d’une stratégie de mise à l’échelle fiable: une charge inattendue sur une application peut le rendre peu fiable. Considérez l’approche de mise à l’échelle appropriée en fonction des caractéristiques de votre charge de travail. La mise à l’échelle horizontale (scale-out) vous permet d’ajouter d’autres instances pour distribuer la charge, tandis que la mise à l’échelle verticale (scale-up) implique d’augmenter la capacité d’une instance existante (processeur, mémoire). Soyez prudent quant au surapprovisionnement, car l’ajout d’instances inutiles augmente les coûts sans avantages tangibles en matière de performances.

    Vous pouvez parfois augmenter la capacité pour gérer la charge. Toutefois, si la charge continue d’augmenter, effectuez un scale-out vers de nouvelles instances. Préférer la mise à l’échelle automatique ou 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 afin d’empêcher la dégradation des performances[Choisir l’option de mise à l’échelle pour App Service](Mise à l’échelle automatique dans Azure App Service)

    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 appropriée de l'application est effectuée afin que les nouvelles instances soient prêtes rapidement et puissent recevoir des demandes.

    Essayez, dans la mesure du possible, d’utiliser des applications sans état. La mise à l'échelle fiable de l'état 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 une perte d’état de 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 empreintes de déploiement identiques, chaque instance de plan App Service en cours d’exécution ayant son propre point de terminaison. Il est essentiel que vous fassiez précéder toutes les empreintes d’un équilibreur de charge externe afin de répartir le trafic entre elles. 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 Base de référence stratégique avec App Service.

  • Planifiez votre récupérabilité: la redondance est cruciale pour assurer 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 élégante en cas de défaillances temporaires, telles que les problèmes de connectivité réseau, et aussi des événements à grande échelle tels que les pannes régionales. Tenez compte des modèles de conception suivants :

    • Le modèle de cloisonnement segmente votre application en groupes isolés pour empêcher une défaillance d’affecter l’ensemble du système.

    • Le modèle de nivellement de charge basé sur une file d’attente met en file d’attente des éléments de travail qui servent de tampon pour atténuer les pics de trafic.

    • Le modèle Retry gère les échecs temporaires en raison de problèmes réseau, de connexions de base de données perdues ou de services surchargé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 d’erreurs pour introduire intentionnellement des erreurs et valider vos mécanismes d’auto-réparation et d’auto-préservation. 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 limites, quotas et contraintes d’abonnement Azure et de service.

  • Utiliser la fonctionnalité Contrôle d’intégrité pour identifier les travailleurs 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. La plateforme effectue un test ping sur ce chemin pour déterminer si votre application est saine et répond aux demandes. Lorsque votre site est mis à l’échelle vers plusieurs instances, App Service exclut toutes les instances non saines du traitement des requêtes, ce qui améliore votre disponibilité globale. Le chemin d’accès au contrôle d’intégrité de votre application doit interroger les composants critiques de votre application, tels que votre base de données, votre cache ou votre service de messagerie. Cela garantit que l’état renvoyé par le chemin de contrôle d’intégrité représente fidèlement l’état d’intégrité général de votre application. Définir votre chemin de contrôle d’intégrité

  • Utiliser la fonctionnalité de réparation automatique: parfois, votre application peut rencontrer des comportements inattendus qui peuvent être résolus par un redémarrage simple. Les fonctionnalités d'auto-réparation vous permettent de définir une « condition » qui déclenche l'auto-réparation et l'« action » que celle-ci initiera lorsque la condition est remplie. Outils de diagnostic et fonctionnalité d’auto-réparation App Service

  • rapport de score de résilience App Service: pour passer en revue les recommandations de bonnes pratiques personnalisées, consultez le rapport de score de résilience.rapport de score de résilience App Service

Recommandations

Recommandation Avantage
(App Service) Choisissez le niveau Premium v3 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 Présentation du plan App Service.
Un plan App Service Premium V3 offre des fonctionnalités de mise à l’échelle avancées et garantit la redondance en cas d’échecs.
(App Service) Activer 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.
(Application web) 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 n'importe quel nœud unique d'être accablé par le trafic. 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 demeure sans état. Un App Service sans état réduit la complexité et garantit un comportement cohérent entre les nœuds.

Supprimez les sessions persistantes afin qu’App Service puisse ajouter ou supprimer des instances pour effectuer une mise à l’échelle horizontale.
(Application web) Définir des règles de guérison automatique en fonction du nombre de demandes, des demandes lentes, des 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 d’auto-réparation aident votre application à se récupérer automatiquement de 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.
(Application web) Activer la fonctionnalité de contrôle d’intégrité et fournir un chemin d’accès qui répond aux demandes de contrôle d’intégrité. Les bilans de santé peuvent détecter les problèmes précocement. Ensuite, le système peut effectuer automatiquement des actions correctives lorsqu’une demande de contrôle d’intégrité é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 sécurité fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs, en appliquant des approches à la stratégie de conception technique de l'hébergement sur App Service.

Liste de contrôle de conception

Commencez votre stratégie de conception en vous basant sur la liste de contrôle de la révision de la conception 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.

  • Passer 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.

  • Utiliser le dernier runtime et les 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 des runtimes de langage pour mettre à jour les piles existantes et retirer les piles arrivées en fin de support.

  • Créer une segmentation au moyen de limites d’isolation pour contenir une violation : appliquer la segmentation d’identité. 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. Injecter des applications App Service dans un réseau virtuel Azure pour isoler et définir des groupes de sécurité réseau (NSG) pour filtrer le trafic.

    Les plans App Service proposent le niveau App Service Environment 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.

  • Appliquer des contrôles d’accès sur les identités: restreindre l’accès vers l’intérieur à l’application web et l’accès vers l’extérieur 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 webet un contributeur générique, lecteur et propriétaire.

  • Appliquer des contrôles de sécurité réseau: intégrez votre App Service à un réseau virtuel (VNet) pour contrôler le trafic sortant. Utilisez des points de terminaison privés pour contrôler le trafic entrant et limiter l’accès à votre App Service à partir de votre réseau virtuel et désactiver l’accès à Internet public. Sécuriser votre réseau, contrôler le trafic entrant et sortant

    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 NSG sur le sous-réseau de point de terminaison privé pour accepter uniquement le trafic provenant 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 d'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. Vérifiez que toutes les applications web utilisent HTTPS uniquement et appliquent TLS 1.2 ou version ultérieure. La version minimale de TLS par défaut est 1.2. Pour plus d’informations, consultez Vue d’ensemble TLS d’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.

    chiffrement TLS de bout en bout: le chiffrement TLS de bout en bout est disponible dans les plans App Service Premium. Cette fonctionnalité chiffre votre trafic tout au long de la transaction, ce qui réduit le risque d’interception du trafic.

  • Réduire 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 politiques Azure.

    Implémenter 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.

  • Utiliser des identités managées: activez les identités managées pour que votre App Service accède en toute sécurité à d’autres services Azure sans avoir à gérer les informations d’identification. En savoir plus sur les identités managé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.

  • Activer 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é. Consultez les conseils de surveillance des journaux pour des instructions détaillées.

    Envisagez la journalisation dans le cadre de votre processus de modélisation des menaces lorsque vous évaluez les menaces.

Recommandations

Recommandation Avantage
(Application web) Affecter 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 de façon sûre à votre registre de conteneurs si vous en utilisez 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 à changer régulièrement les 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.
(Application web) Configurez 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.
(Application web) détermine si l’authentification intégrée App Service est le mécanisme approprié 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 OpenID Connect. 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.
(Application web) 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’extraction de l’image conteneur via l’intégration du réseau virtuel. Tout le trafic sortant de l’application transite 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.
(Application Web) Pour implémenter le durcissement :
- Désactiver 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.
- Activez les stratégies CORS pour restreindre 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.
(Application web) Toujours utiliser les références Key Vault en tant que 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 des secrets.
(App Service) Activer 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.
(App Service) Activer la journalisation des diagnostics et ajouter de l’instrumentation à votre application. Les journaux d’activité sont envoyés aux comptes stockage Azure, 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 Cost Optimization 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.

Liste de contrôle de conception

Démarrez votre stratégie de conception en fonction de la liste de contrôle de la révision de conception 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 le 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.

  • Évaluer 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 Réduire les coûts avec les instances réservées d'App Service.

  • Comprendre les compteurs d’utilisation: Azure facture un taux horaire, calculé au prorata du deuxième, en fonction du niveau tarifaire de votre plan App Service. Les frais s’appliquent à chaque instance avec extension horizontale dans votre plan, en fonction de la durée pendant laquelle vous allouez l’instance de machine virtuelle. Soyez attentif aux ressources informatiques sous-utilisées qui pourraient augmenter vos coûts en raison d’une surallocation due à une sélection sous-optimale des références SKU, ou d’une configuration 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 des coffres de clés pour protéger les secrets de charges de travail, qui s’intègrent à vos ressources App Service, peuvent également entraîner des coûts supplémentaires. Pour plus d’informations, consultez le modèle de facturation des services d'application .

  • Envisagez les compromis entre la densité et l’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 Tradeoffs.

  • Évaluer 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 ont un faible niveau de performance et un coût bas. Si vous utilisez le niveau De base ou Gratuit, utilisez la gouvernance pour appliquer le niveau, restreindre le nombre d’instances et de processeurs, limiter la mise à l’échelle et réduire 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 le modèle Backends pour Frontends et le modèle d’agrégation de passerelle, ce qui peut diminuer le nombre de requêtes et abaisser les coûts.

  • vérifier régulièrement les coûts liés aux données: les périodes de rétention des données prolongées ou les 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. Le slot fonctionne 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 Excellence Opérationnelle.

Recommandations

Recommandation Avantage
(App Service) Choisir des 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.
(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’économies Azure pour le calcul dédié que vous provisionnez dans le niveau Premium V3 et l’environnement App Service.

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.
(Application web) Surveiller les coûts générés par les ressources App Service. Exécutez l’outil d’analyse des coûts dans le portail Azure.

Créer 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.
(App Service) Effectuer un scale-in lorsque la demande diminue. Pour effectuer un scale-in, 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 concernant les pratiques 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.

Liste de contrôle de conception

Démarrez votre stratégie de conception basée sur la checklist de révision de conception pour l'excellence opérationnelle afin de définir des processus d'observabilité, de test et de déploiement liés aux applications Web.

  • Gérer les versions: utilisez des emplacements de déploiement pour gérer efficacement les versions. 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 sans problème. Ce processus n’entraîne pas de coûts supplémentaires, car le slot s’exécute dans le même environnement de machine virtuelle que l’instance de production.

    Utilisez l'échange avec aperçu (échange multiphase). L’échange avec la préversion vous permet de tester l’application dans vos emplacements de préproduction par rapport à vos paramètres de production et de précharger également l’application. Après avoir effectué vos tests et préchargé tous les chemins nécessaires, vous pouvez ensuite finaliser l’échange et l’application commencera à recevoir du trafic de production sans redémarrer.

  • 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 performance. Explorez les outils automatisés pour d’autres types de tests, tels que Fantôme pour les tests fonctionnels.

  • Automatiser les déploiements: utilisez des pipelines CI/CD avec Azure DevOps ou GitHub Actions pour automatiser les déploiements et réduire les efforts manuels déploiement continu vers Azure App Service.

  • 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 timbre représente une unité autonome que vous pouvez rapidement étendre ou réduire. Les unités basées sur ce cachet sont temporaires et non permanentes. 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 Base de référence stratégique avec App Service.

    Utilisez une technologie IaC (Infrastructure en tant que code), telle que Bicep, pour l’horodatage d’unités de façon répétable et cohérente.

  • 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
(Application web) Surveiller l’intégrité de vos instances et activer les sondes d’intégrité d’instance.

Configurez un chemin spécifique pour gérer les demandes de la 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.
(Application web) Activer 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 :
- Consigner le bon niveau d’information.
- 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.
(Application web) Tirez parti des certificats gérés App Service pour décharger la gestion des certificats vers 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.
(App Service) Valider les modifications apportées à l’application dans l’emplacement de préproduction avant de l’échanger avec l’emplacement de production. Évitez les temps d’arrêt et les erreurs.

Revenez rapidement au dernier état correct connu si vous détectez un problème après une permutation.

Efficacité des performances

L'efficacité des performances consiste à maintenir l'expérience utilisateur même en cas d'augmentation de la charge grâce à la gestion de 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 Performance Efficiency fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs de capacité par rapport à l’utilisation attendue.

Liste de contrôle de conception

Démarrez votre stratégie de conception en fonction de la liste de contrôle de révision de la conception pour l’efficacité des performances afin de définir une base de référence fondée sur les indicateurs clés de performance pour les applications web.

  • Identifier et surveiller les indicateurs de performances: définissez des cibles pour les indicateurs clés de l’application, tels que le volume des requêtes entrantes, le temps que l’application prend pour répondre aux requêtes, 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 de bord pour obtenir des informations sur l'utilisation des ressources et les activités effectuées. Utilisez des outils de surveillance des performances des applications (APM), tels que Application Insights, pour collecter et analyser des données de performances à partir de l’application. Pour plus d’informations, consultez Informations de référence sur les 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 V3 offrent des références SKU plus importantes avec des capacités de mémoire et de CPU accrues, plus d’instances et fonctionnalités, telles que la redondance de zone. Pour plus d’informations, consultez Niveau tarifaire Premium V3.

  • Optimiser votre stratégie de mise à l’échelle: si possible, utilisez mise à l’échelle automatique au lieu d’ajuster manuellement le nombre d’instances à 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 est coûteuse pour accéder affecte les performances. Les requêtes complexes, y compris les jointures et les recherches multiples, contribuent au temps d'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 performance: pour garantir que l’application web performe et évolue 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 gourmandes en ressources peuvent augmenter les temps de réponse pour les demandes des utilisateurs et provoquer une latence élevée.
    Déplacez les processus qui consomment des ressources importantes vers un back-end 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.
    Pas de mise en cache Servez les requêtes à partir d’un cache intermédiaire placé 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
(App Service) Activer 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 expirations de requêtes. L’application n’est jamais déchargée avec Always On activé.
(Web Apps) envisager 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 les listes de contrôle des piliers. 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 optimiser l'utilisation des 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.

    Tenez également compte des inconvénients, tels que la contention des ressources. 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é. Pour les applications critiques nécessitant une haute disponibilité et des performances, des environnements isolés comme App Service Environment V3 (ASE) fournir des ressources dédiées, mais à un coût plus élevé. Envisagez d’utiliser des environnements partagés pour les charges de travail non critiques et les environnements isolés pour les applications stratégiques.

  • 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 de préproduction) pour bénéficier d’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.

Un inconvénient est que les ressources surprovisionnées coûtent plus cher. Vous êtes facturé par seconde pour chaque instance, y compris les instances prédéfinies. Les niveaux supérieurs incluent des instances de préproduction. Déterminez si les fonctionnalités avec des niveaux plus coûteux valent la peine d’investir.

Redondance de bâtiment

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. Si la redondance dépasse les exigences des SLO, cela devient du gaspillage. Évaluez si une redondance excessive améliore les SLOs 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 satisfaire à vos SLO.

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 vérifier 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 un réseau virtuel Azure via l’injection de réseau virtuel pour avoir un meilleur contrôle sur la configuration du 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 Azure Policy et d’autres stratégies susceptibles d’affecter la sécurité de la couche de calcul.

Recommandations d’Azure Advisor

Azure Advisor est un consultant cloud personnalisé qui vous aide à suivre les meilleures 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.