Partager via

Application web redondante interzone de base hautement disponible

Azure App Service
Application Gateway Azure
Stockage Azure
Azure SQL Database
Azure Private Link
Réseau virtuel Azure
Azure Monitor

Cette architecture de base repose sur l’architecture de base de l’application web et fournit des instructions détaillées pour concevoir une application web sécurisée, redondante interzone et hautement disponible sur Azure. Dans cette architecture, Azure Application Gateway avec le pare-feu d’applications web Azure expose un point de terminaison public et route les demandes vers Azure App Service via Azure Private Link. L’application App Service utilise l’intégration de réseau virtuel et Private Link pour communiquer en toute sécurité avec des solutions PaaS (platform as a service) Azure comme Azure Key Vault et Azure SQL Database.

Important

Un exemple d’implémentation illustre cette implémentation App Service de référence sur Azure. Utilisez-la comme base pour votre solution de production.

Architecture

Diagramme montrant une architecture de base d'App Service avec redondance zonale et haute disponibilité.

Téléchargez un fichier Visio de cette architecture.

Composants

Cette architecture partage de nombreux composants avec l’architecture de base de l’application web. La liste suivante décrit uniquement les composants qui diffèrent ou étendent l’architecture de base :

  • Application Gateway est un équilibreur de charge HTTP et HTTPS de couche 7 et un gestionnaire de trafic web. Dans cette architecture, Application Gateway agit comme un point d’entrée public unique. Application Gateway met fin au protocole TLS (Transport Layer Security) et évalue les règles de pare-feu d’applications web Azure. Il transfère ensuite les demandes approuvées en privé aux instances App Service entre les zones de disponibilité.

  • Le pare-feu d’applications web Azure est un service natif cloud qui protège les applications web contre les attaques courantes, telles que l’injection SQL et le script intersites (XSS). Dans cette architecture, le pare-feu d’applications web Azure s’exécute sur Application Gateway et bloque les requêtes malveillantes avant d’atteindre App Service. Cette configuration améliore la sécurité et permet de maintenir la disponibilité.

  • Key Vault est un service qui stocke et gère en toute sécurité les secrets, les clés de chiffrement et les certificats. Dans cette architecture, elle stocke le certificat TLS (X.509) que Application Gateway utilise et contient les secrets d’application auxquels App Service accède en privé.

  • Le réseau virtuel Azure est un service qui fournit des réseaux virtuels privés isolés et sécurisés dans Azure. Dans cette architecture, le réseau virtuel fournit des points de terminaison privés, l’intégration d’App Service et des sous-réseaux dédiés pour Application Gateway. Cette configuration isole le trafic et permet à App Service de communiquer en toute sécurité avec les services Azure dépendants via des points de terminaison privés.

  • Private Link est un service de mise en réseau qui fournit un accès privé aux services Azure via le réseau principal Microsoft afin d’éliminer l’exposition à l’Internet public. Dans cette architecture, Private Link permet des connexions entrantes privées vers App Service et des connexions sortantes privées d’App Service vers des services tels que Key Vault, SQL Database et Stockage Azure.

  • Azure DNS est un service d’hébergement pour les domaines DNS (Domain Name System). Il fournit la résolution de noms à l’aide de l’infrastructure Microsoft Azure. Les zones DNS privées mappent le nom de domaine complet (FQDN) d’un service à l’adresse IP d’un point de terminaison privé. Dans cette architecture, les zones DNS privées mappent le domaine par défaut App Service et d’autres domaines de service PaaS à leurs adresses de point de terminaison privé afin que tout le trafic reste sur le réseau privé.

Mise en réseau

La sécurité réseau est essentielle à l’architecture de référence App Service. À un niveau élevé, l’architecture réseau fournit les fonctionnalités suivantes :

  • Point d’entrée sécurisé unique pour le trafic client

  • Filtrage du trafic via le pare-feu d’applications web Azure

  • Chiffrement TLS de bout en bout pour les données en transit

  • Exfiltration de données réduite via Private Link, qui conserve le trafic dans Azure

  • Regroupement logique et isolation des ressources réseau par le biais de la segmentation du réseau

Flux réseau

Diagramme montrant les flux réseau dans une architecture réseau App Service de base.

Flux entrant

Les étapes suivantes décrivent le flux entrant depuis Internet vers l’instance App Service :

  1. L’utilisateur émet une demande à l’adresse IP publique d’Application Gateway.

  2. Application Gateway évalue les règles de pare-feu d’applications web, qui protègent contre les attaques telles que l’injection XSS et SQL. Si une règle détecte une violation, Application Gateway renvoie une erreur au demandeur et arrête le traitement. Sinon, Application Gateway achemine la requête vers le pool principal, ce qui, dans ce cas, est le domaine par défaut App Service.

  3. La zone privatelink.azurewebsites.net DNS privée est liée au réseau virtuel. La zone DNS contient un enregistrement A qui mappe le domaine par défaut App Service à l’adresse IP privée du point de terminaison privé App Service. Azure DNS utilise cet enregistrement pour résoudre le domaine par défaut à l'adresse IP du point de terminaison privé.

  4. Application Gateway achemine la requête vers une instance App Service via le point de terminaison privé.

Flux sortant

Les étapes suivantes décrivent le flux sortant d’App Service vers les services PaaS Azure :

  1. App Service envoie une requête au nom DNS du service Azure requis, comme Key Vault, Storage, SQL Database ou tout autre service Azure prenant en charge Private Link. La fonctionnalité d’intégration de réseau virtuel App Service route la requête via le réseau virtuel.

  2. Comme à l’étape 3 dans le flux entrant, la zone DNS privée liée contient un enregistrement A qui mappe le domaine du service Azure à son adresse IP de point de terminaison privé. Azure DNS utilise cet enregistrement pour attribuer le domaine à l'adresse IP du point de terminaison privé du service.

  3. Le réseau virtuel achemine la requête vers le service via le point de terminaison privé.

Le trafic sortant qui ne passe pas aux services PaaS Azure quitte une adresse IP publique que plusieurs clients partagent. Par exemple, une application web peut appeler une API publique pendant une requête HTTP. Pour contrôler ce type de trafic de sortie, routez-le via un appareil réseau comme le Pare-feu Azure. Pour plus d’informations, consultez Contrôler le trafic sortant à l’aide du Pare-feu Azure.

Implémentation d’Application Gateway

Application Gateway est un équilibreur de charge de couche 7 scalable et régional qui prend en charge le pare-feu d’applications web Azure et le déchargement TLS. Lorsque vous implémentez Application Gateway pour le trafic entrant vers App Service, tenez compte des points suivants :

Passer d’App Service aux services Azure

Cette architecture utilise l’intégration de réseau virtuel pour router le trafic App Service vers des points de terminaison privés via le réseau virtuel. L'architecture de base ne permet pas l'acheminement de tout le trafic, ce qui forcerait tout le trafic sortant à passer par le réseau virtuel. Au lieu de cela, il route uniquement le trafic interne lié aux points de terminaison privés.

Pour les services Azure qui ne nécessitent pas d’accès à Internet public, autorisez les points de terminaison privés et bloquez les points de terminaison publics. Les points de terminaison privés améliorent la sécurité en permettant à App Service de se connecter aux services Private Link directement à partir du réseau virtuel privé sans adressage IP public.

Dans cette architecture, SQL Database, Storage et Key Vault ont tous des points de terminaison publics bloqués. Leurs pare-feu de service autorisent le trafic uniquement à partir d’autres services Azure autorisés. Configurez d’autres services Azure, comme Azure Cosmos DB et Azure Managed Redis, avec des points de terminaison privés. Dans cette architecture, Azure Monitor n’utilise pas de point de terminaison privé, mais vous pouvez en implémenter un à l’aide d’une étendue AMPLS (Azure Monitor Private Link Scope).

L’architecture de base implémente une zone DNS privée pour chaque service. Chaque zone DNS privée contient un enregistrement A qui mappe le nom de domaine complet du service à l’adresse IP du point de terminaison privé. Les zones sont liées au réseau virtuel. Les groupes de zones DNS privés créent et mettent automatiquement à jour les enregistrements DNS pour les points de terminaison privés.

Tenez compte des points suivants lorsque vous implémentez l’intégration de réseau virtuel et les points de terminaison privés :

Segmentation et sécurité du réseau virtuel

Le réseau de cette architecture comporte des sous-réseaux distincts pour Application Gateway, des composants d’intégration App Service et des points de terminaison privés. Un groupe de sécurité réseau (NSG) sur chaque sous-réseau autorise uniquement le trafic entrant et sortant requis. Le tableau suivant décrit une sélection de règles de groupe de sécurité réseau que vous pouvez ajouter à chaque sous-réseau.

Sous-réseau Trafic entrant Règle de trafic sortant
GatewaySubnet AppGw.In.Allow.ControlPlane: autoriser l’accès au plan de contrôle entrant.

AppGw.In.Allow443.Internet : Autoriser l'accès HTTPS entrant à Internet.		 AppGw.Out.Allow.PrivateEndpoints: Autoriser l’accès sortant à PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: Autoriser l’accès sortant à Azure Monitor.
PrivateEndpointsSubnet Règles par défaut : autoriser l’accès entrant à partir du réseau virtuel. Règles par défaut : autoriser l’accès sortant au réseau virtuel.
AppServiceSubnet Règles par défaut : autoriser l’accès entrant à partir du réseau virtuel. AppPlan.Out.Allow.PrivateEndpoints: Autoriser l’accès sortant à PrivateEndpointsSubnet.

AppPlan.Out.Allow.AzureMonitor: Autoriser l’accès sortant à Azure Monitor.

Tenez compte des points suivants lorsque vous implémentez la segmentation et la sécurité du réseau virtuel :

  • Activez la protection DDoS pour le réseau virtuel qui contient un sous-réseau de passerelle d’application avec une adresse IP publique.

  • Ajoutez un groupe de sécurité réseau à chaque sous-réseau le cas échéant. Utilisez les règles les plus strictes qui autorisent la fonctionnalité complète de la solution.

  • Utilisez des groupes de sécurité d’application pour regrouper les ressources logiquement, ce qui simplifie la création de règles de groupe de sécurité réseau dans des environnements complexes.

Le tableau suivant présente un exemple de schéma réseau.

Catégorie Nom Plage d’adresses
Réseau virtuel Préfixe de l’adresse 10.0.0.0/16
Sous-réseau GatewaySubnet 10.0.1.0/24
Sous-réseau AppServiceSubnet 10.0.0.0/24
Sous-réseau PrivateEndpointsSubnet 10.0.2.0/27
Sous-réseau AgentsSubnet 10.0.2.32/27

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de garantir que votre application peut respecter les engagements que vous avez pris envers vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

L’architecture App Service de base se concentre sur la redondance zonale pour les services régionaux clés. Les zones de disponibilité sont des emplacements physiquement distincts au sein d’une région qui fournissent une haute disponibilité et une tolérance de panne. Lorsque vous déployez deux instances sur plusieurs zones de disponibilité dans des régions prises en charge, l’échec d’une zone n’affecte pas les autres. Cette approche permet de maintenir la disponibilité du service.

L’architecture garantit également des instances suffisantes des services Azure pour répondre à la demande. Les sections suivantes fournissent des conseils de fiabilité pour chaque service clé dans l’architecture.

Application Gateway

Déployez Application Gateway dans une configuration redondante interzone avec un nombre minimal d’instances d’échelle de trois ou plus. Plusieurs instances garantissent que le service reste disponible pendant les défaillances sans attendre la durée de démarrage de six minutes à sept minutes nécessaire pour configurer une nouvelle instance.

Service d'application

  • Déployez au moins deux instances App Service qui prennent en charge les zones de disponibilité. Pour une résilience plus élevée, déployez au moins une instance pour chaque zone de disponibilité de votre région, ainsi que des instances supplémentaires dans chaque zone pour la redondance.

  • Implémentez des points de terminaison de contrôle d’intégrité dans vos applications et configurez la fonctionnalité de contrôle d’intégrité App Service pour rediriger les demandes à partir d’instances non saines. Pour plus d’informations, consultez Surveiller les instances App Service à l’aide des contrôles d’intégrité et vérifications d’intégrité dans ASP.NET Core.

  • Capacité de surprovisionnement pour gérer les défaillances de zone.

Stockage Blob

  • Utilisez le stockage redondant interzone (ZRS), qui réplique les données de manière synchrone sur trois zones de disponibilité de la région. Créez des comptes de stockage standard ZRS ou de stockage géoredondant interzone standard (GZRS) pour garantir la réplication des données entre les zones de disponibilité.

  • Créez des comptes de stockage distincts pour les déploiements, les ressources web et d’autres données pour gérer et configurer chaque compte indépendamment.

SQL Database

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

L’architecture App Service de base se concentre sur les recommandations de sécurité essentielles pour votre application web. Vous devez comprendre comment le chiffrement et l’identité fonctionnent à chaque couche pour sécuriser votre charge de travail.

Service d'application

  • Désactivez les méthodes d’authentification locales pour les déploiements de sites FTP (File Transfer Protocol) et SCM (Source Control Management).

  • Désactivez le débogage à distance.

  • Utilisez la dernière version tls prise en charge par tous vos clients.

  • Activez le plan Microsoft Defender pour App Service.

  • Utilisez les dernières versions des plateformes, langages de programmation, protocoles et infrastructures pris en charge.

  • Envisagez App Service Environment si vous avez besoin d’une isolation plus élevée ou d’un accès réseau sécurisé.

Chiffrement

Les applications web de production doivent chiffrer les données en transit à l’aide du protocole HTTPS. HTTPS s’appuie sur TLS et utilise des clés publiques et privées pour le chiffrement. Stockez le certificat TLS (X.509) dans Key Vault et accordez l’autorisation Application Gateway pour récupérer la clé privée. Pour les données au repos, certains services chiffrent automatiquement les données, et d’autres vous permettent de personnaliser les paramètres.

Données en transit

L’architecture de base chiffre les données en transit de l’utilisateur vers l’application web dans App Service.

Diagramme montrant un flux de chiffrement App Service de base.

Le flux de travail suivant décrit le fonctionnement du chiffrement à un niveau élevé :

  1. L’utilisateur envoie une requête HTTPS à l’application web.

  2. La requête HTTPS atteint la passerelle d’application.

  3. La passerelle d’application utilise un certificat (X.509) dans Key Vault pour créer une connexion TLS sécurisée avec le navigateur web de l’utilisateur. La passerelle d’application déchiffre la requête HTTPS afin que le pare-feu d’applications web puisse l’inspecter.

  4. La passerelle d’application crée une connexion TLS à App Service pour chiffrer à nouveau la demande de l’utilisateur. App Service fournit une prise en charge native du protocole HTTPS. Vous n’avez donc pas besoin d’ajouter un certificat à App Service. La passerelle d’application envoie le trafic chiffré à App Service. App Service déchiffre le trafic et l’application web traite la requête.

Tenez compte des recommandations suivantes lorsque vous configurez le chiffrement de données en transit :

  • Pour charger votre certificat dans Key Vault. Le chiffrement HTTPS nécessite un certificat (X.509). Vous avez besoin d’un certificat d’une autorité de certification approuvée pour votre domaine personnalisé.

  • Stockez la clé privée du certificat dans Key Vault.

  • Fournissez l’accès Application Gateway à la clé privée de certificat. Pour plus d’informations, consultez Accorder une autorisation à l’aide du contrôle d’accès en fonction du rôle Azure (Azure RBAC) et des identités managées pour les ressources Azure. N’utilisez pas de stratégies d’accès Key Vault pour fournir l’accès. Les stratégies d’accès vous permettent d’accorder uniquement des autorisations étendues, et non des valeurs spécifiques.

  • Activez le chiffrement de bout en bout. App Service est le pool principal pour la passerelle d’application. Lorsque vous configurez le paramètre back-end pour le pool principal, utilisez le protocole HTTPS sur le port principal 443.

Données au repos

  • Utilisez le chiffrement transparent des données pour chiffrer les données sensibles dans SQL Database. Le chiffrement transparent des données chiffre l’intégralité de la base de données, des sauvegardes et des fichiers journaux des transactions et ne nécessite pas de modifications apportées à votre application web.

  • Placez des données sensibles dans sa propre base de données et activez le chiffrement uniquement pour cette base de données. Cette approche réduit la latence de chiffrement de base de données.

  • Comprendre la prise en charge du chiffrement intégré. Stockage Azure chiffre automatiquement les données au repos par le biais du chiffrement côté serveur (AES (Advanced Encryption Standard) 256 bits). Azure Monitor chiffre automatiquement les données au repos via des clés gérées par Microsoft.

Gouvernance

Azure Policy permet d’appliquer des décisions architecturales et de sécurité pour les applications web. Il peut empêcher le déploiement de ressources non conformes (mode refus) ou les marquer pour révision (mode audit). Cette approche permet de détecter la dérive de configuration de votre architecture prévue, que la dérive se produise via des déploiements d’infrastructure en tant que déploiements de code (IaC) ou des modifications manuelles dans le portail Azure.

Placez toutes les ressources dans votre architecture sous gouvernance Azure Policy. Utilisez des stratégies intégrées ou des initiatives de stratégie lorsque c'est possible pour imposer la topologie réseau essentielle, les fonctionnalités de service, la sécurité et les mesures de surveillance. Tenez compte des stratégies intégrées suivantes :

  • App Service doit désactiver l’accès réseau public.
  • App Service doit utiliser l’intégration de réseau virtuel.
  • App Service doit utiliser Private Link pour se connecter aux services PaaS.
  • App Service doit avoir des méthodes d’authentification locales désactivées pour les déploiements de site FTP et SCM.
  • App Service doit avoir désactivé le débogage à distance.
  • Les applications App Service doivent utiliser la dernière version tls.
  • Defender pour App Service doit être activé.
  • Le pare-feu d’applications web Azure doit être activé pour Application Gateway.

Consultez des stratégies intégrées pour les services clés tels que les composants Application Gateway et réseau, App Service, Key Vault et les composants de supervision. Vous pouvez créer des stratégies personnalisées ou utiliser des stratégies de communauté, telles que des stratégies à partir de zones d’atterrissage Azure, si les stratégies intégrées ne répondent pas à vos besoins. Préférez les stratégies intégrées lorsque cela est possible.

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

L’architecture de référence App Service configure l’authentification et l’autorisation pour les identités utilisateur (utilisateurs) et les identités de charge de travail (ressources Azure). Il implémente le principe du privilège minimum.

Identités utilisateur

  • Utilisez le mécanisme d’authentification intégré pour App Service, également appelé EasyAuth. EasyAuth simplifie l’intégration du fournisseur d’identité à votre application web. Il gère l’authentification en dehors de votre application web, de sorte que vous n’avez pas à apporter de modifications significatives au code.

  • Configurez l’URL de réponse pour le domaine personnalisé. Définissez l’URL de redirection sur https://<application-gateway-endpoint>/.auth/login/<provider>/callback.

    Remplacez <application-gateway-endpoint> par l’adresse IP publique ou le nom de domaine personnalisé de votre passerelle d’application. Remplacez <provider> par votre fournisseur d’authentification, par exemple aad pour Microsoft Entra ID.

    Pour obtenir des instructions de configuration, consultez les considérations relatives à Azure Front Door ou configurer Application Gateway.

Identités de charge de travail

  • Utilisez des identités managées pour les identités de charge de travail. Les identités managées éliminent la nécessité pour les développeurs de gérer les informations d’identification d’authentification.

  • Utilisez des identités managées affectées par l’utilisateur. Les identités attribuées par le système peuvent entraîner l’échec des déploiements IaC en raison des situations de compétition et de l’ordre des opérations. Les identités managées affectées par l’utilisateur évitent certains de ces scénarios d’erreur de déploiement. Pour plus d’informations, voir Identités managées.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

Le déploiement de l’application App Service de base suit les instructions d’architecture Azure Pipelines. Étant donné que l’architecture de base refuse l’accès public à App Service et sécurise le compte de stockage de déploiement au sein du réseau virtuel, vous ne pouvez pas déployer à partir de l’extérieur du réseau virtuel. Pour résoudre cette contrainte, l’architecture utilise des agents de déploiement auto-hébergés qui s’exécutent dans le réseau virtuel. Les conseils de déploiement suivants se concentrent sur le déploiement de code d’application, et non sur les modifications apportées à l’infrastructure ou à la base de données.

Diagramme montrant une architecture de base d’un déploiement App Service.

Flux de déploiement

  1. Le pipeline de déploiement publie une requête de travail dans la file d’attente des agents auto-hébergés. Le travail indique à l’agent de télécharger l'artefact de build du fichier zip de publication sur un compte de stockage.

  2. Un agent de déploiement auto-hébergé interroge la file d’attente, récupère la demande de travail et télécharge le travail et l’artefact de génération.

  3. L'agent de déploiement auto-hébergé charge le fichier zip sur le compte de stockage via le point de terminaison privé du compte de stockage.

  4. Le pipeline continue et un agent managé récupère un travail suivant. L'agent managé effectue un appel d'interface de ligne de commande (CLI) pour mettre à jour le paramètre d'application WEBSITE_RUN_FROM_PACKAGE afin de référencer le nouveau fichier zip de publication correspondant à l'emplacement de préproduction.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip

  5. App Service récupère le nouveau fichier zip de publication à partir du stockage via le point de terminaison privé du compte de stockage. Elle redémarre l'instance intermédiaire avec le nouveau package, car WEBSITE_RUN_FROM_PACKAGE a été configurée avec un autre nom de fichier.

  6. Le pipeline reprend et exécute des tests de fumée ou attend une approbation manuelle. Une fois les tests ou l’approbation réussis, le pipeline échange les slots de préproduction et de production.

Conseils pour le déploiement

Appliquez les instructions de déploiement suivantes pour l’architecture de base :

  • Exécutez votre déploiement directement à partir d’un package dans App Service pour éviter les conflits de déploiement. Cette approche monte le package ZIP directement en tant que répertoire wwwroot en lecture seule au lieu de copier des fichiers. Il élimine les conflits de verrouillage de fichiers entre le déploiement et l’exécution et garantit que seules les applications entièrement déployées s’exécutent.

  • Incluez les numéros de version dans les noms de fichiers zip du package déployé. Lorsque vous mettez à jour le WEBSITE_RUN_FROM_PACKAGE paramètre d’application pour référencer le package de déploiement dont le nom de fichier est différent, App Service extrait automatiquement le nouveau package et redémarre.

  • Utilisez des emplacements de déploiement pour des implémentations de code résilientes.

  • Envisagez d’utiliser des agents gérés et auto-hébergés.

  • Utilisez IaC pour automatiser les déploiements d’infrastructure.

  • Validez les performances et la résilience de la charge de travail en continu à l’aide de services tels qu’Azure Load Testing et Azure Chaos Studio.

Paramétrage

Les applications nécessitent à la fois des valeurs de configuration et des secrets. Utilisez les instructions suivantes pour la gestion des secrets et de la configuration :

  • Ne stockez jamais de secrets tels que les mots de passe ou les clés d’accès dans le contrôle de code source. Stockez les secrets dans Key Vault.

  • Stocker la configuration de l’application dans la configuration d’App Service. Si vous avez besoin de la prise en charge de la configuration externe ou de l’indicateur de fonctionnalité, utilisez Azure App Configuration.

  • Utilisez des références Key Vault dans la configuration App Service pour exposer en toute sécurité des secrets dans votre application.

  • Configurez les paramètres d'application spécifiques au slot si vos slots de production et de préproduction nécessitent des valeurs différentes. Par défaut, lors du déploiement, les paramètres de l'application sont échangés avec ceux du slot.

  • Utilisez des variables d’environnement locales ou des fonctionnalités spécifiques à la plateforme pour le développement local. La configuration d’App Service expose les paramètres d’application en tant que variables d’environnement. Les outils de développement tels que Visual Studio vous permettent de définir des variables d’environnement dans les profils de lancement et de fournir un stockage sécurisé pour les paramètres locaux via les secrets utilisateur.

Surveillance

La surveillance collecte et analyse les données des systèmes informatiques pour fournir une observabilité. Dans cette architecture, la surveillance effectue le suivi de l’intégrité et de la sécurité des applications web sur plusieurs couches, ce qui permet de maintenir des opérations fiables.

Surveillez trois couches clés :

  • Code d’application : Suivez les données de télémétrie spécifiques à l’application et les métriques personnalisées.

  • Infrastructure (runtime) : Surveillez l’environnement d’exécution App Service.

  • Plateforme (ressources Azure) : Collectez des métriques et des journaux provenant de services Azure comme Application Gateway, SQL Database et Key Vault.

Pour plus d’informations, consultez le journal d’activité Azure, les journaux des ressources Azure et la journalisation des applications App Service.

Surveiller la plateforme

La supervision de la plateforme recueille des données des services Azure présents dans votre architecture.

Application Gateway

Application Gateway surveille l’intégrité du pool principal par le biais de sondes d’intégrité par défaut. Utilisez les journaux d’accès Application Gateway pour collecter des informations telles que les horodatages, les codes de réponse HTTP et les chemins d’URL. Pour plus d’informations, consultez les journaux d’intégrité et de diagnostic principaux.

Service d'application

App Service fournit des fonctionnalités de supervision intégrées et unifiées pour améliorer l’observabilité. Si votre application web dispose déjà de fonctionnalités de télémétrie et de surveillance, telles que l’instrumentation in-process, ces fonctionnalités continuent de fonctionner sur App Service.

  • Activez l’instrumentation automatique pour étendre l’instrumentation sans modification du code. Cette fonctionnalité fournit une visibilité de l’analyse des performances des applications (APM). Pour plus d’informations, consultez Surveiller les performances d’App Service.

  • Activez le suivi distribué pour suivre les demandes entre plusieurs services et dépendances. Vous pouvez surveiller les systèmes cloud distribués via le suivi distribué et un profileur de performances.

  • Utilisez l’instrumentation basée sur le code pour la télémétrie personnalisée. Application Insights prend également en charge l’instrumentation basée sur le code pour la télémétrie d’application personnalisée. Ajoutez le Kit de développement logiciel (SDK) Application Insights à votre code et utilisez l’API Application Insights.

  • Activez les journaux de service d'application pour les diagnostics au niveau de la plateforme. App Service fournit quatre types de journaux pour la résolution des problèmes : les journaux des applications, les journaux du serveur web, les messages d’erreur détaillés et le suivi des demandes ayant échoué.

  • Utilisez une journalisation structurée. Ajoutez une bibliothèque de journalisation structurée au code de votre application. Mettez à jour votre code pour utiliser des paires clé-valeur et activez les journaux d’application dans App Service pour les stocker dans votre espace de travail Log Analytics.

  • Activez la fonctionnalité de contrôle d’intégrité App Service pour maintenir la disponibilité. Les contrôles d’intégrité détectent les instances non saines, redirigent le trafic pour les éviter et les remplacent automatiquement. Cette fonctionnalité nécessite deux instances App Service ou plus.

Base de données

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’efficacité des performances.

Application Gateway

Service d'application

SQL Database

La mise à l’échelle de la base de données implique de nombreuses considérations au-delà de l’étendue de cette architecture. Pour plus d’informations sur la mise à l’échelle de SQL Database, consultez les ressources suivantes :

Autre guide de scalabilité

  • Passez en revue les limites et quotas d’abonnement pour vous assurer que les services sont mis à l’échelle à la demande.

  • Envisagez de mettre en cache les types de données suivants pour augmenter les performances et l’extensibilité :

    • Données de transaction semi-statiques
    • État de session
    • Sortie HTML complexe

Étapes suivantes