Partager via

Fiabilité dans Azure App Service

Azure App Service est un service HTTP pour l’hébergement d’applications web, d’API REST et de back-ends mobiles. App Service s’intègre à Microsoft Azure pour assurer la sécurité, l’équilibrage de charge, la mise à l’échelle automatique et la gestion automatisée pour les applications. En tant que service Azure, App Service fournit une gamme de fonctionnalités pour prendre en charge vos exigences de fiabilité.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre App Service résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance du service. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service App Service (SLA).

Note

Si vous recherchez des informations sur la prise en charge de la fiabilité dans App Service Environment, consultez Fiabilité dans App Service Environment.

Recommandations concernant le déploiement de production

Azure Well-Architected Framework fournit des recommandations sur la fiabilité, les performances, la sécurité, le coût et les opérations. Pour comprendre comment ces domaines influencent les uns les autres et contribuent à une solution App Service fiable, consultez les meilleures pratiques d’architecture pour App Service (Web Apps) dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous créez une application web App Service, vous spécifiez le plan App Service qui exécute l’application.

Un plan App Service définit un ensemble de ressources de calcul qui exécutent vos applications web. Toutes les applications web doivent s’exécuter à l’intérieur d’un plan. Vous pouvez mettre à l’échelle un plan pour s’exécuter sur plusieurs instances de machine virtuelle, également appelées workers. Ces instances fournissent les ressources de calcul qui exécutent le code de votre application. Un seul plan App Service peut héberger plusieurs applications. Toutes les applications s’exécutent sur le même ensemble partagé d’instances de machine virtuelle.

App Service fournit les fonctionnalités de redondance suivantes :

  • Distribution entre domaines d’erreur : Au niveau de la plateforme, Azure distribue automatiquement les instances de machine virtuelle de votre plan App Service entre les domaines d’erreur au sein de la région Azure. Cette distribution réduit le risque de défaillances matérielles localisées en regroupant les machines virtuelles qui partagent une source d’alimentation commune et un commutateur réseau.

  • Distribution entre les zones de disponibilité : Si vous activez la redondance de zone sur un plan App Service pris en charge, Azure distribue vos instances entre les zones de disponibilité au sein de la région. Cette configuration offre une résilience plus élevée si une panne de zone se produit. Pour plus d’informations sur la redondance de zone, consultez la prise en charge des zones de disponibilité.

  • Mise à l’échelle des applications : Lorsque vous configurez votre plan App Service pour exécuter plusieurs instances de machine virtuelle, toutes les applications du plan s’exécutent sur toutes les instances par défaut. Si vous configurez votre plan pour l'extensibilité automatique, toutes les applications s'étendent ensemble en fonction des paramètres d'extensibilité automatique. Toutefois, vous pouvez personnaliser le nombre d’instances de plan qui exécutent une application spécifique à l’aide de la mise à l’échelle par application.

  • Unités d’échelle : En interne, App Service s’exécute sur une infrastructure de plateforme appelée unités d’échelle, également appelées tampons ou espaces web. Une unité d’échelle inclut tous les composants nécessaires pour héberger et exécuter App Service, notamment le calcul, le stockage, la mise en réseau et l’équilibrage de charge. Azure gère les unités de mise à l’échelle pour garantir la distribution équilibrée des charges de travail, effectuer une maintenance de routine et maintenir la fiabilité globale de la plateforme.

    Certaines fonctionnalités peuvent uniquement être appliquées à des unités d’échelle spécifiques. Par exemple, certaines unités d’échelle App Service peuvent prendre en charge la redondance de zone, tandis que d’autres unités d’échelle dans la même région ne le font pas.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Les Kits de développement logiciel (SDK) fournis par Microsoft gèrent généralement les fautes temporaires. Étant donné que vous hébergez vos propres applications sur App Service, prenez des mesures pour réduire le risque d’erreurs temporaires :

  • Déployez plusieurs instances dans votre plan. App Service effectue des mises à jour automatisées et d’autres formes de maintenance sur les instances de votre plan. Si une instance devient non saine, le service peut remplacer automatiquement cette instance par une nouvelle instance saine. Pendant le processus de remplacement, il peut y avoir une courte période lorsque l’instance précédente n’est pas disponible et qu’une nouvelle instance n’est pas prête à servir le trafic. Pour atténuer ces effets, déployez plusieurs instances de votre plan App Service.

  • Utilisez des emplacements de déploiement. Les emplacements de déploiement App Service permettent de déployer des déploiements sans temps d’arrêt de vos applications. Utilisez des emplacements de déploiement pour réduire l’effet des déploiements et des modifications de configuration pour vos utilisateurs. Les emplacements de déploiement réduisent également la probabilité que votre application redémarre. Le redémarrage de l’application provoque une erreur temporaire.

  • Évitez d'effectuer une mise à l'échelle vers le haut ou vers le bas. Ces opérations modifient l’UC, la mémoire et d’autres ressources affectées à chaque instance, et peuvent déclencher un redémarrage d’une application. Au lieu de cela, sélectionnez un niveau et une taille d’instance qui répondent à vos besoins en matière de performances en fonction de la charge standard. Pour effectuer un scale-out et un scale-in, ajoutez et supprimez dynamiquement des instances pour gérer les modifications apportées au volume de trafic.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Pour les niveaux Premium v2 à v4, vous pouvez configurer App Service comme redondant interzone, ce qui signifie que vos ressources sont distribuées entre plusieurs zones de disponibilité. La distribution entre plusieurs zones permet à vos charges de travail de production d’atteindre la résilience et la fiabilité. Lorsque vous configurez la redondance de zone sur les plans App Service, toutes les applications qui utilisent le plan deviennent redondantes par zone.

Spécifications

Pour activer la redondance de zone, vous devez répondre aux exigences suivantes :

Distribution d’instances entre zones

Lorsque vous créez un plan App Service redondant interzone, Azure distribue les instances du plan entre les zones de disponibilité de la région. Cette distribution garantit que vos applications restent disponibles même si une zone subit une panne.

La distribution d’instances dans un déploiement redondant interzone suit des règles spécifiques. Ces règles s’appliquent également au fur et à mesure que l’application est mise à l’échelle :

  • Instances minimales : Votre plan App Service doit avoir au moins deux instances pour la redondance de zone.

  • Zones de disponibilité maximale prises en charge par votre plan : Azure détermine le nombre de zones de disponibilité que votre plan peut utiliser, ce qui est appelé maximumNumberOfZones. Pour afficher le nombre de zones de disponibilité que votre plan spécifique peut utiliser, consultez Vérifier la prise en charge de la redondance de zone pour un plan App Service.

  • Distribution d’instances : Lorsque la redondance de zone est activée, Azure distribue automatiquement les instances de plan entre plusieurs zones de disponibilité. La distribution est basée sur les règles suivantes :

    • Si le nombre d’instances dépasse maximumNumberOfZones et divise uniformément, Azure distribue les instances uniformément entre les zones.

    • Si le nombre d’instances ne se divise pas uniformément, Azure distribue les instances restantes entre les zones restantes.

    • Lorsque la plateforme App Service alloue des instances à un plan App Service redondant interzone, elle utilise le meilleur équilibrage de zone possible qu’offre les groupes de machines virtuelles identiques Azure. Un plan est équilibré si chaque zone a le même nombre de machines virtuelles ou diffère d’une instance de toutes les autres zones. Pour découvrir plus d’informations, consultez Équilibrage de zone.

  • Positionnement de zone physique : Vous pouvez afficher la zone de disponibilité physique utilisée pour chacune de vos instances de plan App Service. Pour plus d’informations, consultez Afficher les zones physiques d’un plan App Service.

Considérations

Pour les plans Premium v2 à v4 , une panne de zone de disponibilité peut affecter certains aspects d’Azure App Service, même si l’application continue de traiter le trafic. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

Lorsque vous activez la redondance de zone sur votre plan App Service Premium v2 vers v4 , vous améliorez également la résilience pendant les mises à jour de la plateforme. Pour plus d’informations, consultez Résilience à la maintenance du service.

Pour les plans App Service qui ne sont pas configurés avec une redondance interzone, les instances de machine virtuelle sous-jacentes ne sont pas résilientes aux échecs des zones de disponibilité. Elles peuvent rencontrer des temps d’arrêt pendant une panne dans n’importe quelle zone de cette région.

Coût

Lorsque vous utilisez des plans App Service Premium v2 vers v4, l’activation des zones de disponibilité n’ajoute pas de coût si vous avez deux instances ou plus. Les frais sont basés sur la référence SKU de votre plan App Service, la capacité que vous spécifiez et les instances auxquelles vous effectuez une mise à l’échelle en fonction de vos critères de mise à l’échelle automatique.

Si vous activez les zones de disponibilité, mais spécifiez une capacité inférieure à deux, la plateforme applique un nombre minimal d’instances de deux. La plateforme vous facture pour ces deux instances.

Configurer la prise en charge des zones de disponibilité

Planification de capacité et gestion

Pour vous préparer à une défaillance de zone de disponibilité, envisagez de surprovisionner la capacité de votre plan App Service. Cette approche permet à la solution de tolérer une perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité à l’aide du surapprovisionnement.

Comportement lorsque toutes les zones sont saines

La liste suivante décrit ce qui doit être attendu lorsque les plans App Service sont configurés pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles :

  • Routage du trafic entre les zones : Pendant les opérations normales, le trafic est acheminé entre toutes les instances de plan App Service disponibles dans toutes les zones de disponibilité.

  • Réplication des données entre les zones : Pendant les opérations normales, tout état stocké dans le système de fichiers de votre application est stocké dans un stockage redondant interzone et répliqué de manière synchrone entre les zones de disponibilité.

Comportement lors d’une défaillance de zone

Une panne de zone de disponibilité peut affecter certains aspects d’App Service, même si l’application continue de traiter le trafic. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

La liste suivante décrit ce qui doit être attendu lorsque les plans App Service sont configurés pour la redondance de zone et qu’une ou plusieurs zones de disponibilité ne sont pas disponibles :

  • Détection et réponse : La plateforme App Service détecte automatiquement les défaillances dans une zone de disponibilité et lance une réponse. Aucune intervention manuelle n’est nécessaire pour lancer un basculement de zone.
  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : Toutes les demandes en cours qui se connectent à une instance de plan App Service dans la zone de disponibilité défectueuse sont arrêtées. Réessayez ces requêtes.

  • Réacheminement du trafic : App Service détecte les instances perdues de cette zone et tente de trouver de nouvelles instances de remplacement. Une fois qu’App Service a trouvé des remplacements, il distribue le trafic entre les nouvelles instances en fonction des besoins.

    Si la mise à l’échelle automatique est configurée et détermine que d’autres instances sont nécessaires, elle demande des instances à partir d’App Service. Le comportement de mise à l’échelle automatique fonctionne indépendamment du comportement de la plateforme App Service. Par conséquent, la spécification du nombre d’instances n’a pas besoin d’être un multiple de deux. Pour plus d’informations, consultez Mise à l’échelle d’une application dans App Service et vue d’ensemble de la mise à l’échelle automatique.

    Important

    Azure ne garantit pas que les demandes de plus d’instances réussissent dans un scénario de zone descendante. La plateforme tente de restaurer les instances perdues dans la mesure du possible. Si vous avez besoin d’une capacité garantie lors d’une défaillance de zone de disponibilité, créez et configurez vos plans App Service pour tenir compte de la perte de zone en surprovisionnant la capacité.

  • Comportements non-runtime : Les applications d’un plan App Service redondant interzone continuent à s’exécuter et à traiter le trafic même si une zone de disponibilité subit une panne. Toutefois, il est possible que les comportements hors runtime soient toujours affectés pendant une panne de zone de disponibilité. Ces comportements incluent la mise à l’échelle de plans App Service, la création d’applications, la configuration d’applications et la publication d’applications.

Récupération de la zone

Lorsque la zone de disponibilité récupère, App Service crée automatiquement des instances dans la zone de disponibilité récupérée, supprime toutes les instances temporaires créées dans les autres zones de disponibilité et route le trafic entre vos instances comme d’habitude.

Tester les pannes de zone

La plateforme Azure App Service gère le routage du trafic, le basculement et la restauration automatique pour les plans App Service redondants interzone. Cette fonctionnalité est entièrement gérée. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

App Service est un service à région unique. Si la région devient indisponible, votre application n’est pas disponible.

Solutions multirégions personnalisées pour la résilience

Pour réduire le risque d’une défaillance à une seule région affectant votre application, vous pouvez déployer des plans dans plusieurs régions. Les étapes suivantes aident à renforcer la résilience :

  • Déployez votre application sur les plans de chaque région.
  • Configurez les stratégies d’équilibrage de charge et de basculement.
  • Répliquez vos données entre les régions afin de pouvoir récupérer votre dernier état d’application.

Tenez compte des ressources associées suivantes :

Sauvegarde et restauration

Lorsque vous utilisez le niveau De base ou une version ultérieure, vous pouvez sauvegarder vos applications App Service dans un fichier à l’aide des fonctionnalités de sauvegarde et de restauration App Service.

Ces fonctionnalités vous aident quand il est difficile de redéployer du code ou lorsque vous stockez l’état sur le disque. La plupart des solutions ne doivent pas s’appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités de ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas.

Important

À compter du 31 mars 2028, les sauvegardes personnalisées Azure App Service ne prennent plus en charge la sauvegarde des bases de données liées. Pour plus d’informations, consultez Dépréciation des sauvegardes de base de données liées .

Utilisez plutôt les outils de sauvegarde et de restauration natifs de votre base de données liée. Pour plus d’informations, consultez Sauvegarder et restaurer votre application dans App Service.

Résilience à la maintenance du service

App Service effectue des mises à niveau de service régulières et d’autres tâches de maintenance. Pour maintenir votre capacité attendue pendant une mise à niveau, la plateforme ajoute automatiquement des instances supplémentaires du plan App Service pendant le processus de mise à niveau.

Activer la redondance de zone. Lorsque vous activez la redondance de zone sur votre plan App Service, vous améliorez également la résilience pendant les mises à jour de la plateforme. Les domaines de mise à jour sont constitués de collections de machines virtuelles qui sont hors connexion pendant une mise à jour et qui sont mappées aux zones de disponibilité. Le déploiement de plusieurs instances dans votre plan App Service et l’activation de la redondance de zone pour votre plan ajoute une couche supplémentaire de résilience si une instance ou une zone devient défectueuse pendant une mise à niveau.

Pour plus d’informations, consultez Maintenance planifiée de routine pour App Service et Maintenance de routine pour App Service, redémarrages et temps d’arrêt.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Lorsque vous déployez un plan App Service redondant entre zones, le pourcentage de temps d’activité défini dans le SLA augmente.

Contenu connexe

  • Last updated on