Partage via

Fiabilité dans Azure App Service

  • Article

Cet article décrit la prise en charge de la fiabilité dans Azure App Service, et couvre à la fois la résilience intrarégionale avec les zones de disponibilité et les informations sur les déploiements multirégions.

La résilience est une responsabilité partagée entre Microsoft et vous-même. Cet article couvre donc également les moyens à votre disposition pour créer une solution résiliente qui répond à vos besoins.

Azure App Service est un service HTTP pour l’hébergement d’applications web, d’API REST et de backends mobiles. Azure App Service ajoute la puissance de Microsoft Azure à votre application, avec des fonctionnalités de sécurité, d’équilibrage de charge, de mise à l’échelle automatique et de gestion automatisée. Pour découvrir comment Azure App Service peut renforcer la fiabilité et la résilience de votre charge de travail d’application, consultez Pourquoi utiliser App Service ?

Lorsque vous déployez Azure App Service, vous pouvez créer plusieurs instances d’un plan App Service, qui représente les workers de calcul qui exécutent votre code d’application. Bien que la plateforme s’efforce de déployer les instances entre différents domaines d’erreur, elle ne répartit pas automatiquement les instances entre les zones de disponibilité.

Recommandations concernant le déploiement de production

Pour les déploiements de production, vous devez :

  • Utilisez des plans App Service Premium v3.
  • Activez la redondance de zone, ce qui nécessite que votre plan App Service utilise au moins trois instances.

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. Elles se corrigent d’elles-même après un court laps de temps. Il est important que vos applications gèrent 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 d’Azure lors de la communication avec les API, bases de données et autres composants hébergés dans le cloud. Pour en savoir plus sur la gestion des erreurs temporaires, consultez Recommandations pour la gestion des erreurs temporaires.

Bien que les SDK fournis par Microsoft gèrent généralement les erreurs temporaires, étant donné que vous hébergez vos propres applications sur Azure App Service, vous devez penser aux manières d’éviter d’entraîner des erreurs temporaires en vous assurant de :

  • Déployez plusieurs instances de votre plan. Azure 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 où l’instance précédente n’est pas disponible et qu’une nouvelle instance n’est pas encore prête à servir le trafic. Vous pouvez atténuer l’impact de ce comportement en déployant plusieurs instances de votre plan App Service.

  • Utilisez des emplacements de déploiement. Les emplacements de déploiement Azure App Service permettent des déploiements sans temps d’arrêt de vos applications. Utilisez des emplacements de déploiement pour réduire l’impact des déploiements et des modifications de configuration sur vos utilisateurs. L’utilisation d’emplacements de déploiement réduit également la probabilité que votre application redémarre, ce qui provoque une erreur temporaire.

  • Évitez de monter ou de descendre en puissance. 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. Effectuez un scale-out des instances uniquement pour gérer les modifications du volume de trafic. Gardez à l’esprit qu’un scale-up ou scale-down peut déclencher un redémarrage de l’application.

Prise en charge des zones de disponibilité

Azure App Service peut être configuré comme redondant interzone, ce qui signifie que vos ressources sont réparties entre plusieurs zones de disponibilité. La répartition entre plusieurs zones permet à vos charges de travail de production d’atteindre la résilience et la fiabilité. La prise en charge des zones de disponibilité est une propriété du plan App Service.

La répartition d’instances avec un déploiement redondant interzone est déterminée à l’intérieur des règles suivantes, même lorsque l’application est mise à l’échelle et sortante :

  • Le nombre minimal d’instances du plan App Service est de trois.
  • Si vous spécifiez une capacité supérieure à trois et que le nombre d’instances est divisible par trois, les instances sont réparties de manière égale.
  • Toutes les instances au-delà de 3*N sont réparties sur les zones restantes d’une ou deux zones.

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 App Service est « équilibré » si chaque zone compte le même nombre de machines virtuelles, à une machine virtuelle près, dans toutes les autres zones que le plan App Service utilise.

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

Spécifications

  • Les zones de disponibilité ne sont prises en charge que sur l’empreinte App Service la plus récente. Même si vous utilisez l’une des régions prises en charge, vous recevrez une erreur si les zones de disponibilité ne sont pas prises en charge pour votre groupe de ressources. Pour vous assurer que vos charges de travail atterrissent sur un tampon qui prend en charge les zones de disponibilité, vous devrez peut-être créer un groupe de ressources, un plan App Service et App Service.
  • Vous devez déployer au minimum trois instances de votre plan.

Régions prises en charge

Les plans App Service redondants interzone peuvent être déployés dans n’importe quelle région qui prend en charge les zones de disponibilité.

Pour savoir quelles régions prennent en charge les zones de disponibilité pour App Service Environment v3, consultez Régions.

À propos de l’installation

Les applications déployées dans un plan App Service redondant interzone continuent à s’exécuter et à servir le trafic même si plusieurs zones de la région souffrent d’une panne. Cependant, il se peut que des comportements hors runtime, dont la mise à l’échelle de plan App Service, la création d’application, la configuration d’application et la publication d’application soient encore affectés par une panne d’une zone de disponibilité. La redondance de zone pour les plans App Service garantit uniquement un temps d’activité continu des applications déployées.

Cost

Quand vous utilisez des plans App Service Premium v2 ou Premium v3, il n’existe aucun coût supplémentaire associé à l’activation des zones de disponibilité dès lors que vous avez trois instances ou plus dans votre plan App Service. Vous serez facturé en fonction de la référence SKU de votre plan App Service, de la capacité que vous spécifiez et des instances que vous mettez à l’échelle en fonction de vos critères de mise à l’échelle automatique. Si vous activez les zones de disponibilité mais que vous spécifiez une capacité inférieure à trois, la plateforme applique un nombre d’instances minimal de trois et vous facture l’utilisation de ces trois instances.

App Service Environment v3 a un modèle de tarification spécifique pour la redondance de zone. Pour obtenir des informations de tarification pour App Service Environment v3, consultez Tarification.

Configurer la prise en charge des zones de disponibilité

Pour utiliser la redondance de zone, basculez vers un type de plan App Service pris en charge.

Pour déployer un nouveau plan Azure App Service redondant interzone, sélectionnez l’option Redondant interzone lorsque vous déployez le plan.

Pour déployer une nouvelle instance d’Azure App Service Environment redondante interzone, consultez Créer une instance App Service Environment.

La redondance de zone ne peut être configurée que lors de la création d’un plan App service. Si vous disposez d’un plan App Service existant qui n’est pas redondant interzone, vous devez le remplacer par un nouveau plan redondant interzone. Vous ne pouvez pas convertir un plan App Service existant pour utiliser des zones de disponibilité. De même, vous ne pouvez pas désactiver la redondance de zone sur un plan App Service existant.

Planification de capacité et gestion

Pour vous préparer à une défaillance de la zone de disponibilité, vous devez surdimensionner la capacité de service pour veiller à ce que la solution puisse tolérer une perte de capacité d’un tiers et continue à fonctionner sans dégradation des performances pendant les pannes à l’échelle de la zone. Étant donné que la plateforme répartit les machines virtuelles dans trois zones et que vous devez prendre en compte au moins la défaillance d’une zone, multipliez le nombre d’instances nécessaires pour un pic de charge de travail par un facteur de zones/(zones-1), soit 3/2. Par exemple, si votre pic de charge de travail typique nécessite quatre instances, vous devez en approvisionner six : (2/3 * 6 instances) = 4 instances.

Routage du trafic entre les zones

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

Expérience en cas de panne de zone

Détection et réponse : la plateforme App Service est responsable de la détection d’une panne dans une zone de disponibilité et de sa résolution. Vous n’avez rien à faire pour lancer un basculement de zone.

Requêtes actives : lorsqu’une zone de disponibilité n’est pas disponible, toutes les requêtes en cours connectées à une instance de plan App Service dans la zone de disponibilité en panne sont arrêtées et doivent être retentées.

Réacheminement du trafic : lorsqu’une zone n’est pas disponible, Azure App Service détecte les instances perdues de cette zone. Il tente automatiquement de trouver de nouvelles instances de remplacement. Ensuite, il répartit le trafic entre les nouvelles instances en fonction des besoins.

Si vous avez configuré la mise à l’échelle automatique et qu’elle décide que davantage d’instances sont nécessaires, la mise à l’échelle automatique envoie également une requête à App Service pour ajouter des instances supplémentaires.

Remarque

Le comportement de la mise à l’échelle automatique est indépendant de celui de la plateforme App Service. La spécification du nombre d’instances de mise à l’échelle automatique n’a pas besoin d’être un multiple de trois.

Important

Il n’est pas garanti que les requêtes d’instances supplémentaires dans un scénario de zone en panne réussissent. Le remplissage arrière des instances perdues survient sur une base du meilleur effort. Si vous avez besoin d’une capacité garantie lorsqu’une zone de disponibilité est perdue, vous devez créer et configurer vos plans App Service pour prendre en compte la perte d’une zone. Vous pouvez le faire en surapprovisionnant la capacité de votre plan App Service.

Restauration automatique

Lorsque la zone de disponibilité récupère, Azure 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 achemine le trafic entre vos instances normalement.

Test des défaillances 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é étant complètement managée, vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité.

Prise en charge de plusieurs régions

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

Solutions multirégions alternatives

Pour vous assurer que votre application soit moins vulnérable à une défaillance d’une seule région, vous devez déployer votre application dans plusieurs régions. Pour ce faire, vous devrez suivre les étapes suivantes :

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

Pour obtenir des exemples d’architectures qui illustrent cette approche, consultez :

Pour suivre un tutoriel qui vous montre comment créer une application multirégion, consultez Tutoriel : Créer une application multirégion hautement disponible dans Azure App Service.

Pour obtenir un exemple d’approche illustrant cette architecture, consultez Déploiement d’entreprise à haute disponibilité à l’aide d’App Service Environment.

Sauvegardes

Lorsque vous utilisez le niveau Essentiel ou un niveau supérieur, vous pouvez sauvegarder votre application App Service dans un fichier à l’aide des fonctionnalités de sauvegarde et restauration App Service. Cette fonctionnalité est utile s’il est difficile de redéployer votre code ou si vous stockez l’état sur le disque. Toutefois, pour la plupart des solutions, vous ne devez pas vous appuyer sur les sauvegardes App Service. Utilisez plutôt les autres méthodes décrites dans cet article pour prendre en charge vos exigences de résilience.

Contrat de niveau de service (SLA)

Le contrat de niveau de service (SLA) pour Azure App Service décrit la disponibilité attendue du service. Il décrit également les conditions qui doivent être remplies pour atteindre cette attente de disponibilité. Pour comprendre ces conditions, il est important de passer en revue les contrats de niveau de service (SLA) pour les services en ligne.

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

Contenu connexe