Prendre en charge le trafic élevé avec Application Gateway

Remarque

Cet article décrit quelques recommandations pour vous aider à configurer votre Application Gateway afin de gérer le trafic supplémentaire résultant d’un volume de trafic élevé qui peut se produire. Les seuils d’alerte sont purement des suggestions et donc génériques par nature. Les utilisateurs peuvent déterminer les seuils d’alerte en fonction de leurs attentes en matière de charge de travail et d’utilisation.

Vous pouvez utiliser Application Gateway avec le pare-feu d’applications Web (WAF) pour disposer d’un moyen évolutif et sécurisé de gérer le trafic vers vos applications web.

Il est important de mettre à l’échelle votre Application Gateway en fonction de votre trafic et de prévoir un peu de mémoire tampon afin d’anticiper les hausses et les pics de trafic, et de réduire l’impact que cela peut avoir dans votre QoS. Les suggestions suivantes vous aident à configurer Application Gateway avec WAF pour gérer le trafic supplémentaire.

Pour obtenir la liste complète des métriques fournies par Application Gateway, consultez la documentation sur les métriques. Pour plus d’informations sur la façon de définir des alertes pour les métriques, consultez Visualiser des métriques dans le portail Azure et la documentation Azure Monitor.

Pour plus d’informations et des recommandations sur l’efficacité des performances pour Application Gateway, consultez l’évaluation de Azure Well-Architected Framework : Azure Application Gateway v2.

Mise à l'échelle pour la référence SKU Application Gateway v1 (SKU Standard/WAF)

Définir le nombre d’instances en fonction de vos pics d’utilisation du processeur

Si vous utilisez une passerelle SKU v1, vous avez la possibilité de définir jusqu’à 32 instances Application Gateway pour la mise à l’échelle. Vérifiez l’utilisation du processeur de votre Application Gateway au cours du mois passé pour détecter les pics supérieurs à 80 %. Cette information est disponible en tant que métrique à surveiller. Il est recommandé de définir le nombre d’instances en fonction de votre utilisation maximale, et avec une mémoire tampon supplémentaire de 10 à 20 % pour tenir compte des pics de trafic.

V1 CPU utilization metrics

Utiliser la référence (SKU) v2 plutôt que la v1 pour ses capacités de mise à l’échelle automatiques et ses avantages en matière de performances

La v2 applique la mise à l’échelle automatique pour s’assurer que votre Application Gateway peut monter en puissance à mesure que le trafic augmente. Elle offre également d’autres avantages significatifs en matière de performances, par exemple des performances 5 fois supérieures de déchargement TLS, des temps de déploiement et de mise à jour plus courts, la redondance de zone, etc., par rapport à la v1. Pour plus d’informations, consultez notre documentation v2 et notre documentation sur la migration de v1 à v2 pour savoir comment migrer vos passerelles SKU v1 existantes vers la référence SKU v2.

Mise à l'échelle automatique pour la référence SKU Application Gateway v2 (SKU Standard_v2/WAF_v2)

Définir le nombre d’instances maximal sur la valeur maximale possible (125)

Pour une SKU Application Gateway v2, la définition du nombre d’instances maximal sur la valeur maximale possible de 125 permet à Application Gateway de monter en charge en fonction des besoins. Cela lui permet de gérer l’augmentation possible du trafic vers vos applications. Seules les unités de capacité (CU) que vous utilisez vous seront facturées.

Veillez à vérifier la taille de votre sous-réseau et le nombre d’adresses IP disponibles dans votre sous-réseau, puis définissez le nombre d’instances maximal selon cette valeur. Si votre sous-réseau n’a pas suffisamment d’espace, vous devrez recréer votre passerelle dans le même sous-réseau ou dans un autre sous-réseau qui dispose d’une capacité suffisante.

V2 autoscaling configuration

Définir le nombre minimal d’instances en fonction de votre utilisation moyenne d’unités de calcul

Pour la référence SKU Application Gateway v2, la mise à l’échelle automatique prend six à sept minutes pour effectuer un scale-out et préparer un ensemble supplémentaire d’instances prêtes à gérer le trafic. En attendant, si le trafic connaît de courts pics, vos instances de passerelle existantes peuvent être fortement sollicitées, entraînant une latence ou une perte inattendue du trafic.

Il est recommandé de définir le nombre minimal d’instances pour un niveau optimal. Par exemple, si vous avez besoin de 50 instances pour gérer le trafic lors des périodes de charge maximale, réduire la valeur minimale de 25 à 30 plutôt qu’à <10 est judicieux, de sorte que même en cas de pics de trafic, Application Gateway est capable de gérer ce trafic, laissant suffisamment de temps pour déclencher et mettre en œuvre la mise à l’échelle automatique.

Vérifiez la métrique de votre unité de calcul pour le mois passé. La métrique d’unité de calcul est une représentation de l’utilisation du processeur de votre passerelle, en fonction de votre utilisation maximale, divisée par 10. Vous pouvez définir le nombre minimal d’instances requises. Notez qu’une instance Application Gateway peut gérer un minimum de 10 unités de calcul

V2 compute unit metrics

Mise à l'échelle manuelle pour la référence SKU Application Gateway v2 (Standard_v2/WAF_v2)

Définir le nombre d’instances en fonction de vos pics d’utilisation d’unités de calcul

Contrairement à la mise à l’échelle automatique, dans le cas d’une mise à l’échelle manuelle, vous devez définir manuellement le nombre d’instances de votre passerelle d’application en fonction des exigences du trafic. Il est recommandé de définir le nombre d’instances en fonction de votre utilisation maximale, et avec une mémoire tampon supplémentaire de 10 à 20 % pour tenir compte des pics de trafic. Par exemple, si votre trafic requiert 50 instances au niveau de charge maximale, provisionnez 55 à 60 instances pour gérer les pics de trafic inattendus qui peuvent se produire.

Vérifiez la métrique de votre unité de calcul pour le mois passé. La métrique d’unité de calcul est une représentation de l’utilisation du processeur de votre passerelle, en fonction de votre utilisation maximale, divisée par 10. Vous pouvez définir le nombre d’instances nécessaires, car une instance Application Gateway peut gérer un minimum de 10 unités de calcul

Surveillance et signalement

Pour être informé des anomalies de trafic ou d’utilisation, vous pouvez configurer des alertes sur certaines métriques. Pour obtenir la liste complète des métriques fournies par Application Gateway, consultez la documentation sur les métriques. Pour plus d’informations sur la façon de définir des alertes pour les métriques, consultez Visualiser des métriques dans le portail Azure et la documentation Azure Monitor.

Pour configurer des alertes à l’aide de modèles ARM, consultez Configurer des alertes Azure Monitor pour Application Gateway.

Alertes pour la référence SKU Application Gateway v1 (Standard/WAF)

Alerter si l’utilisation moyenne du processeur dépasse 80 %

Dans des conditions normales, l’utilisation du processeur ne doit pas dépasser 90 %, car cela peut entraîner une latence dans les sites Web hébergés derrière Application Gateway et perturber l’expérience du client. Vous pouvez indirectement contrôler ou améliorer l'utilisation du processeur en modifiant la configuration d'Application Gateway en augmentant le nombre d'instances ou en passant à une taille SKU plus grande, ou en faisant les deux. Définissez une alerte si la métrique d’utilisation du processeur dépasse 80 % de la valeur moyenne.

Alerter si le nombre d’hôtes non sains dépasse le seuil

Cette métrique indique le nombre de serveurs back-end que la passerelle Application Gateway ne peut pas détecter correctement. Cela permet de détecter les problèmes lorsque les instances d’Application Gateway ne peuvent pas se connecter au serveur principal. Alerter si ce nombre dépasse 20 % de la capacité du back-end. Par exemple, si vous disposez de 30 serveurs principaux dans un pool, définissez une alerte si le nombre d’hôtes non sains est supérieur à 6.

Alerter si l’état de réponse (4xx, 5xx) dépasse le seuil

Créer une alerte lorsque l’état de la réponse Application Gateway est 4xx ou 5xx. Des réponses 4xx ou 5xx peuvent parfois s’afficher en raison de problèmes temporaires. Vous devez observer la passerelle en production pour déterminer le seuil statique, ou utiliser le seuil dynamique pour l’alerte.

Alerter si les échecs de requêtes franchissent le seuil

Créer une alerte lorsque la métrique des échecs de requêtes franchit le seuil. Vous devez observer la passerelle en production pour déterminer le seuil statique, ou utiliser le seuil dynamique pour l’alerte.

Exemple : configuration d’une alerte pour plus de 100 échecs de requêtes au cours des 5 dernières minutes

Cet exemple montre comment utiliser le portail Azure pour configurer une alerte lorsque le nombre d’échecs de requêtes au cours des 5 dernières minutes est supérieur à 100.

  1. Accédez à votre Application Gateway.
  2. Dans le volet de gauche, sélectionnez Mesures sous l’onglet Surveillance.
  3. Ajoutez une métrique pour les échecs de requêtes.
  4. Cliquez sur Nouvelle règle d’alerte et définissez votre condition et vos actions
  5. Cliquez sur Créer une règle d’alerte pour créer et activer l’alerte

V2 create alerts

Alertes pour Application Gateway v2 SKU (Standard_v2/WAF_v2)

Alerter si l’utilisation de l’unité de calcul dépasse 75 % de l’utilisation moyenne

L’unité de calcul mesure l’utilisation du calcul de votre Application Gateway. Vérifiez l’utilisation moyenne des unités de calcul au cours du dernier mois et définissez une alerte si elle dépasse 75 % de cette valeur. Par exemple, si votre utilisation moyenne est de 10 unités de calcul, définissez une alerte sur 7,5 CU. Cela vous avertit si votre utilisation augmente et cela vous donne le temps de réagir en fonction. Vous pouvez augmenter la valeur minimale si vous pensez que ce niveau de trafic sera maintenu, afin de vous avertir que le trafic peut augmenter. Suivez les suggestions de mise à l’échelle ci-dessus pour procéder à un scale-out si nécessaire.

Exemple : configuration d’une alerte à 75 % de l’utilisation moyenne des unités de capacité

Cet exemple montre comment utiliser le portail Azure pour configurer une alerte quand l’utilisation moyenne des unités de capacité atteint 75 %.

  1. Accédez à votre Application Gateway.
  2. Dans le volet de gauche, sélectionnez Mesures sous l’onglet Surveillance.
  3. Ajoutez une mesure pour la moyenne des unités de calcul actuelles.
  4. Si vous avez défini le nombre minimal d’instances comme étant l’utilisation moyenne des unités de capacité, vous pouvez définir une alerte quand 75 % de vos instances minimales sont en cours d’utilisation. Par exemple, si votre utilisation moyenne est de 10 CU, définissez une alerte sur 7,5 CU. Cela vous avertit si votre utilisation augmente et cela vous donne le temps de réagir en fonction. Vous pouvez augmenter la valeur minimale si vous pensez que ce niveau de trafic sera maintenu, afin de vous avertir que le trafic peut augmenter.

V2 compute unit alerts

Remarque

Vous pouvez définir l’alerte pour qu’elle se produise un pourcentage d’utilisation des unités de capacité inférieur ou supérieur, en fonction de la sensibilité que vous souhaitez pour les pics de trafic potentiels.

Alerter si l’utilisation de l’unité de capacité dépasse 75 % de l’utilisation maximale

Les unités de capacité représentent l’utilisation globale de la passerelle en termes de débit, de calcul et de nombre de connexions. Vérifiez l’utilisation de votre unité de capacité maximale au cours du dernier mois et définissez une alerte si elle dépasse 75 % de cette valeur. Par exemple, si votre utilisation maximale est de 100 unités de capacité, définissez une alerte sur 75 CU. Suivez les deux suggestions ci-dessus pour effectuer un scale-out, si nécessaire.

Alerter si le nombre d’hôtes non sains dépasse le seuil

Cette métrique indique le nombre de serveurs back-end que la passerelle Application Gateway ne peut pas détecter correctement. Cela permet de détecter les problèmes lorsque les instances d’Application Gateway ne peuvent pas se connecter au serveur principal. Alerter si ce nombre dépasse 20 % de la capacité du back-end. Par exemple, si vous disposez de 30 serveurs principaux dans un pool, définissez une alerte si le nombre d’hôtes non sains est supérieur à 6.

Alerter si l’état de réponse (4xx, 5xx) dépasse le seuil

Créer une alerte lorsque l’état de la réponse Application Gateway est 4xx ou 5xx. Des réponses 4xx ou 5xx peuvent parfois s’afficher en raison de problèmes temporaires. Vous devez observer la passerelle en production pour déterminer le seuil statique, ou utiliser le seuil dynamique pour l’alerte.

Alerter si les échecs de requêtes franchissent le seuil

Créer une alerte lorsque la métrique des échecs de requêtes franchit le seuil. Vous devez observer la passerelle en production pour déterminer le seuil statique, ou utiliser le seuil dynamique pour l’alerte.

Alerter si le temps de réponse du dernier octet back-end franchit le seuil

Cette métrique indique l’intervalle de temps entre le début de l’établissement d’une connexion au serveur principal et la réception du dernier octet du corps de la réponse. Créez une alerte si la latence de la réponse du back-end est supérieure à celle d’un seuil normal. Par exemple, définissez cette valeur afin d’être averti lorsque la latence de réponse du back-end augmente de plus de 30 % par rapport à la valeur habituelle.

Alerter si le temps total Application Gateway dépasse le seuil

Il s’agit de l’intervalle entre le moment où Application Gateway reçoit le premier octet de la requête HTTP et le moment où le dernier octet de la réponse a été envoyé au client. Doit créer alerte si la latence de la réponse du back-end est supérieure à celle d’un seuil normal. Par exemple, ils peuvent définir cette valeur afin d’être avertis lorsque la latence totale augmente de plus de 30 % par rapport à la valeur habituelle.

Configurer WAF avec le géofiltrage et la protection bot pour bloquer les attaques

Si vous souhaitez ajouter une couche de sécurité devant votre application, utilisez Application Gateway WAF_v2 pour les fonctionnalités WAF. Vous pouvez configurer la référence v2 pour autoriser uniquement l’accès à vos applications à partir d’un ou plusieurs pays/régions. Vous configurez une règle personnalisée WAF pour autoriser ou bloquer explicitement le trafic en fonction de la géolocalisation. Pour plus d’informations, consultez Règles personnalisées de géofiltrage et Comment configurer des règles personnalisées sur Application Gateway WAF_v2 via PowerShell.

Activez la protection bot pour bloquer les mauvais robots connus. Cela devrait réduire le volume de trafic qui arrive jusqu’à votre application. Pour plus d’informations, consultez Protection bot avec instructions de configuration.

Activer les diagnostics sur Application Gateway et WAF

Les journaux de diagnostic vous permettent de consulter les journaux de pare-feu, les journaux de performances et les journaux d’accès. Vous pouvez utiliser ces journaux d’activité dans Azure pour gérer les passerelles Application Gateway et résoudre les problèmes associés. Pour plus d’informations, consultez la documentation des diagnostics.

Configurez une stratégie de protocole TLS pour plus de sécurité

Vérifiez que vous utilisez la dernière version de la stratégie TLS (AppGwSslPolicy20220101) ou une version ultérieure. Ceux-ci prennent en charge la version 1.2 minimale de TLS avec des chiffrements plus forts. Pour plus d’informations, consultez Configuration des versions de stratégie TLS et des suites de chiffrement via PowerShell.