Maintenance de routine pour Azure App Service, redémarrages et temps d’arrêt

Azure App Service est un service Platform as a Service (PaaS) pour l’hébergement d’applications web, d’API REST et de backends mobiles. L’un des avantages de l’offre est que la maintenance planifiée est effectuée en arrière-plan. Nos clients peuvent se concentrer sur le déploiement, l’exécution et la maintenance de leur code d’application au lieu de se préoccuper des activités de maintenance de l’infrastructure sous-jacente. La maintenance d’Azure App Service est un processus robuste conçu pour éviter ou réduire les temps d’arrêt des applications hébergées. Ce processus reste largement invisible pour les utilisateurs d’applications hébergées. Cependant, nos clients sont souvent curieux de savoir si les temps d’arrêt qu’ils subissent sont le résultat de notre maintenance planifiée, surtout s’ils semblent coïncider dans le temps.

Background

Notre mécanisme de maintenance planifiée s’articule autour de l’architecture des unités d’échelle qui hébergent les serveurs sur lesquels les applications déployées s’exécutent. Toute unité d’échelle donnée contient plusieurs types de rôles différents qui fonctionnent tous ensemble. Les deux rôles les plus pertinents pour notre mécanisme de mise à jour de maintenance planifiée sont les rôles de travail et de serveur de fichiers. Pour obtenir une description plus détaillée des différents rôles et d’autres détails sur l’architecture App Service, consultez Coup d’œil sur l’architecture Azure App Service.

Une stratégie de mise à jour peut être conçue de différentes manières et ces différentes conceptions ont chacune leurs avantages et leurs inconvénients. L’une des stratégies que nous utilisons pour les mises à jour majeures est que ces mises à jour ne s’exécutent pas sur des serveurs ou des rôles actuellement utilisés par nos clients. Au lieu de cela, notre processus de mise à jour met à jour les instances par vagues et les instances en train d’être mises à jour ne sont pas utilisées par les applications. Les instances utilisées par les applications sont progressivement remplacées par des instances mises à jour. L’effet résultant sur une application est qu’elle subit un démarrage ou un redémarrage. D’un point de vue statistique et d’après des observations empiriques, le redémarrage des applications est beaucoup moins perturbant que la maintenance des serveurs activement utilisés par les applications.

Détails de la mise à jour d’une instance

Il existe deux scénarios légèrement différents qui s’exécutent pendant chaque cycle de maintenance planifiée. Ces deux scénarios sont liés aux mises à jour effectuées sur les rôles de travail et de serveur de fichiers. À un niveau élevé, ces deux scénarios paraissent similaires du point de vue de l’utilisateur final, mais certaines différences importantes peuvent parfois entraîner un comportement inattendu.

Lorsqu’un rôle de serveur de fichiers doit être mis à jour, le volume de stockage utilisé par l’application doit être migré d’une instance de serveur de fichiers vers une autre. Pendant cette modification, un rôle de serveur de fichiers mis à jour est ajouté à l’application. Cela entraîne un redémarrage simultané d’un processus de travail sur toutes les instances de travail de ce plan App Service. Le redémarrage du processus de travail se chevauche : le mécanisme de mise à jour démarre d’abord le nouveau processus de travail, lui permet de terminer son démarrage et d’envoyer de nouvelles requêtes au nouveau processus de travail. Une fois que le nouveau processus de travail répond, les requêtes existantes ont 30 secondes par défaut pour se terminer dans l’ancien processus de travail, puis l’ancien processus de travail est arrêté.

Lorsqu’un rôle de travail est mis à jour, le mécanisme de mise à jour permute de la même façon un nouveau rôle de travail mis à jour. Le rôle de travail est échangé comme suit : un rôle de travail mis à jour est ajouté à l’ASP, l’application est démarrée sur le nouveau rôle de travail, notre infrastructure attend que l’application démarre, les nouvelles requêtes sont envoyées à la nouvelle instance de travail, les requêtes sont autorisées à se terminer sur l’ancienne instance, puis l’ancienne instance de travail est supprimée de l’ASP. Cette séquence se produit généralement une fois pour chaque instance de travail dans l’ASP et est répartie sur plusieurs minutes ou plusieurs heures en fonction de la taille du plan et de l’unité d’échelle.

Les principales différences entre ces deux scénarios sont les suivantes :

• Un changement du rôle de serveur de fichiers entraîne un redémarrage simultané d’un processus de travail qui se chevauche sur toutes les instances, tandis qu’un changement du rôle de travail entraîne le démarrage d’une application sur une seule instance.
• Un changement du rôle de serveur de fichiers signifie que l’application redémarre sur la même instance sur laquelle elle s’exécutait avant, tandis qu’un changement du rôle de travail entraîne l’exécution de l’application sur une autre instance après le démarrage.

Le mécanisme de redémarrage superposé entraîne un temps d’arrêt nul pour la plupart des applications et la maintenance planifiée n’est même pas remarqué. Si l’application prend un certain temps à démarrer, l’application peut rencontrer un temps d’arrêt minimal associé à la lenteur ou aux défaillances de l’application pendant ou peu après le démarrage du processus. Notre plateforme tente de démarrer l’application jusqu’à ce qu’elle réussisse, mais si l’application ne parvient pas à démarrer complètement, un temps d’arrêt plus long peut se produire. Le temps d’arrêt persiste jusqu’à ce que certaines mesures correctives soient prises, telles que le redémarrage manuel de l’application sur cette instance.

Gestion des défaillances inattendues

Bien que cet article se concentre principalement sur les activités de maintenance planifiées, il est important de mentionner qu’un comportement similaire peut se produire lorsque la plateforme se remet de défaillances inattendues. Si une défaillance matérielle inattendue qui affecte un rôle de travail se produit, la plateforme la remplace de la même façon par un nouveau rôle de travail. L’application démarre sur ce nouveau rôle de travail. Lorsqu’une défaillance ou une latence affecte un rôle de serveur de fichiers associé à l’application, un nouveau rôle de serveur de fichiers le remplace. Un redémarrage du processus de travail se produit sur tous les rôles de travail. Il est important de tenir compte de ce fait lors de l’évaluation des stratégies visant à améliorer le temps de fonctionnement de vos applications.

Stratégies pour augmenter le temps de fonctionnement

La plupart de nos applications hébergées ne subissent qu’un temps d’arrêt limité, voire aucun temps d’arrêt, lors de la maintenance planifiée. Cependant, ce fait n’est pas utile si vos applications spécifiques ont un comportement de démarrage plus compliqué et sont donc susceptibles de subir des temps d’arrêt lorsqu'elles sont redémarrées. Si les applications subissent des temps d’arrêt à chaque redémarrage, il est encore plus urgent d’y remédier. Il existe plusieurs fonctionnalités disponibles dans notre offre de produit App Service conçues pour réduire davantage le temps d’arrêt dans ces scénarios. En général, il existe deux catégories de stratégies qui peuvent être employées :

• Améliorer la cohérence du démarrage des applications
• Réduire les redémarrages d’applications

L’amélioration de la vitesse de démarrage des applications et la garantie d’un succès constant ont un taux de réussite statistiquement plus élevé. Nous vous recommandons d’examiner d’abord les options disponibles dans ce domaine. Certaines d’entre elles sont assez faciles à mettre en œuvre et peuvent apporter d’importantes améliorations. Les stratégies de cohérence du démarrage utilisent à la fois les fonctionnalités d’App Service et les techniques liées au code ou à la configuration de l’application. Réduire au minimum les redémarrages est un groupe d’options qui peut être utilisé si nous ne pouvons pas améliorer le démarrage de l’application pour qu’il soit suffisamment cohérent. Ces options sont généralement plus coûteuses et moins fiables, car elles protègent généralement contre un sous-ensemble de redémarrages. Il n’est pas possible d’éviter tous les redémarrages. L’utilisation des deux types de stratégies est très efficace.

Stratégies de cohérence de démarrage

Initialisation d'application (AppInit)

Lorsqu’une application démarre sur un Worker Windows, l’infrastructure Azure App Service tente de déterminer quand l’application est prête à traiter les requêtes avant que les requêtes externes soient acheminées vers ce Worker. Par défaut, une requête réussie à la racine (/) de l’application est un signal indiquant que l’application est prête à traiter les requêtes. Pour certaines applications, ce comportement par défaut n’est pas suffisant pour s’assurer que l’application est entièrement initialisée. En règle générale, cela se produit si la racine de l’application a des dépendances limitées, mais que d’autres chemins s’appuient sur davantage de bibliothèques ou de dépendances externes pour fonctionner. Le module d’initialisation d’application IIS fonctionne bien pour affiner le comportement d’initialisation. À un niveau élevé, il permet au propriétaire de l’application de définir le ou les chemins d’accès qui servent à indiquer que l’application est effectivement prête à répondre aux demandes. Pour une discussion détaillée sur la façon d’implémenter ce mécanisme, consultez l’article suivant : Démystifier l’initialisation d’App Service. Lorsqu’elle est correctement mise en œuvre, cette fonctionnalité peut se traduire par un temps d’arrêt nul, même si le démarrage de l’application est plus complexe.

Les applications Linux peuvent utiliser un mécanisme similaire à l’aide du paramètre d’application WEBSITE_WARMUP_PATH.

Contrôle d’intégrité

Le contrôle d’intégrité est une fonctionnalité conçue pour gérer les défaillances inattendues du code et de la plateforme pendant l’exécution normale de l’application, mais peut également être utile pour augmenter la résilience du démarrage. Le contrôle d’intégrité effectue deux fonctions de réparation différentes : la suppression d’une instance défaillante de l’équilibreur de charge et le remplacement d’une instance entière. Nous pouvons utiliser la suppression d’une instance de l’équilibreur de charge pour gérer les échecs de démarrage intermittents. Si une instance retourne des échecs après le démarrage malgré l’utilisation de toutes les autres stratégies, le contrôle d’intégrité peut supprimer cette instance de l’équilibreur de charge jusqu’à ce que cette instance retourne à nouveau le code d’état 200 aux requêtes du contrôle d’intégrité. Cette fonctionnalité agit donc comme une prévention de défaillance pour réduire les temps d’arrêt après le démarrage. Cette fonctionnalité peut être utile si les échecs après le démarrage sont temporaires et ne nécessitent pas de redémarrage du processus.

Réparation automatique

La réparation automatique pour Windows et Linux est une autre fonctionnalité conçue pour l’exécution normale de l’application, mais qui peut également être utilisée pour améliorer le comportement du démarrage. Si nous savons que l’application entre parfois dans un état irrécupérable après le démarrage, le contrôle d’intégrité est inutile. Toutefois, la réparation automatique peut redémarrer automatiquement le processus de travail qui peut être utile dans ce scénario. Nous pouvons configurer une règle de réparation automatique qui surveille les requêtes ayant échoué et déclenche un redémarrage du processus sur une seule instance.

Test de démarrage d’application

Le test du démarrage d’une application peut être ignoré. Les tests de démarrage combinés à d’autres facteurs tels que les défaillances de dépendance, les défaillances de charge des bibliothèques, les problèmes de réseau, etc. posent un plus grand défi. Un taux d’échec relativement faible au démarrage peut passer inaperçu, mais peut entraîner un taux d’échec élevé lorsque plusieurs instances sont redémarrées à chaque cycle de mise à jour. Un plan comportant 20 instances et une application dont le taux d’échec au démarrage est de 5 % se traduit par trois instances qui ne démarrent pas en moyenne à chaque cycle de mise à jour. Il existe généralement trois redémarrages d’application par instance (20 déplacements d’instance et 2 redémarrages liés au serveur de fichiers par instance).

Nous vous recommandons de tester plusieurs scénarios

• Test de démarrage général (une instance à la fois) pour établir un taux de réussite de démarrage d’une instance individuelle. Ce scénario le plus simple doit approcher les 100 % avant de passer à d’autres scénarios plus complexes.
• Simuler un échec de dépendance de démarrage. Si l’application a une dépendance sur d’autres services Azure ou non Azure, simulez un temps d’arrêt dans ces dépendances pour révéler le comportement de l’application dans ces conditions.
• Démarrage simultané de nombreuses instances, de préférence plus d’instances qu’en production. Les tests effectués avec de nombreuses instances révèlent souvent des défaillances au niveau des dépendances qui ne sont souvent utilisées qu’au démarrage, telles que les références KeyVault, App Configuration, les bases de données, etc. Ces dépendances doivent être testées pour le volume de requêtes en rafale qu’un redémarrage simultané de l’instance génère.
• Ajout d’une instance en charge complète : assurez-vous qu’AppInit est configuré correctement et que l’application peut être initialisée entièrement avant que les requêtes ne soient envoyées à la nouvelle instance. La montée en charge manuelle est un moyen simple de répliquer un déplacement d’instance pendant la maintenance.
• Redémarrage du processus de travail qui se chevauche : vérifiez à nouveau si AppInit est configuré correctement et si les requêtes peuvent se terminer correctement lorsque l’ancien processus de travail se termine et que le nouveau processus de travailleur démarre. La modification d’une variable d’environnement sous charge peut simuler les effets d’une modification du serveur de fichiers.
• Plusieurs applications dans un plan : s’il existe plusieurs applications dans le même plan, effectuez tous ces tests simultanément sur toutes les applications.

Journalisation du démarrage

La capacité de résoudre rétroactivement les défaillances de démarrage en production est une considération distincte de l’utilisation des tests pour améliorer la cohérence des démarrages. Cependant, elle est tout aussi importante, voire plus, car malgré tous nos efforts, il se peut que nous ne soyons pas en mesure de simuler tous les types de défaillances réelles dans un environnement de test ou d’assurance qualité. C’est aussi souvent le point faible de la journalisation, car l’initialisation de l’infrastructure de journalisation est une autre activité de démarrage qui doit être effectuée. L’ordre des opérations d’initialisation de l’application est une considération importante pour cette raison et peut devenir un problème de type « l’œuf ou la poule ». Par exemple, si nous devons configurer la journalisation en fonction d’une référence KeyVault et que nous ne parvenons pas à obtenir la valeur KeyVault, comment journaliser cette défaillance ? Nous pourrions envisager de dupliquer la journalisation de démarrage à l’aide d’un mécanisme de journalisation distinct qui ne dépend pas d’autres facteurs externes. Par exemple, journaliser ces types d’échecs de démarrage sur le disque local. L’activation d’une fonctionnalité de journalisation générale, telle que la journalisation stdout .NET Core, peut être contre-productive, car cette journalisation continue de générer des données de journal, même après le démarrage, ce qui peut encombrer le disque au fil du temps. Cette fonctionnalité peut être utilisée de manière stratégique pour résoudre les échecs de démarrage reproductibles.

Stratégies de réduction des redémarrages

Les stratégies suivantes peuvent réduire considérablement le nombre de redémarrages qu’une application rencontre pendant la maintenance planifiée. Certaines des stratégies présentées dans cette section permettent également de mieux contrôler le moment où ces redémarrages ont lieu. En général, ces stratégies, bien qu’efficaces, ne permettent pas d’éviter complètement les redémarrages. La principale raison en est que certains redémarrages sont dus à des défaillances inattendues plutôt qu’à une maintenance planifiée.

Important

Il n’est pas possible d’éviter complètement les redémarrages. Les stratégies suivantes peuvent aider à réduire le nombre de redémarrages.

cache local

Le cache local est une fonctionnalité conçue pour améliorer la résilience en raison d’échecs de stockage externe. À un niveau élevé, il crée une copie du contenu de l’application sur le disque local de l’instance sur laquelle il s’exécute. Cela isole l’application contre les échecs de stockage inattendus, mais empêche également les redémarrages en raison des modifications apportées au serveur de fichiers. L’utilisation de cette fonctionnalité peut réduire considérablement le nombre de redémarrages pendant la maintenance publique. En règle générale, elle peut supprimer environ deux tiers de ces redémarrages. Étant donné qu’elle évite principalement les redémarrages simultanés du processus de travail, l’amélioration observée de la cohérence de démarrage de l’application peut être encore plus grande. Le cache local a des implications en termes de conception et de modification du comportement de l’application. Il est donc important de tester complètement l’application pour s’assurer qu’elle est compatible avec cette fonctionnalité.

Notifications de maintenance planifiée et régions jumelées

Si nous voulons réduire le risque de redémarrage lié aux mises à jour en production, nous pouvons utiliser des notifications de maintenance planifiée pour savoir quand une application donnée sera mise à jour. Nous pouvons ensuite configurer une copie de l’application dans une région jumelée et acheminer le trafic vers notre copie d’application secondaire pendant la maintenance de la copie principale. Cette option peut être coûteuse, car la fenêtre de cette maintenance est assez large, de sorte que la copie d’application secondaire doit s’exécuter sur des instances suffisantes pendant au moins plusieurs jours. Cette option peut être moins coûteuse si nous avons déjà configuré une application secondaire pour une résilience générale. Cette option peut réduire le nombre de redémarrages mais, comme les autres options de cette catégorie, elle ne peut pas éliminer tous les redémarrages.

Contrôle de la fenêtre de maintenance planifiée dans ASE v3

Le contrôle de la fenêtre de maintenance n’est disponible que dans nos environnements ASE v3 isolés. Si nous utilisons déjà un ASE ou si nous pouvons utiliser un ASE, cela permet à nos clients de contrôler le comportement de maintenance planifiée à un degré élevé. Il n’est pas possible de contrôler le temps de la maintenance planifiée dans un environnement multilocataire.