Sondes d’intégrité et dégradation contrôlée

Les sondes d’intégrité sont le mécanisme par lequel les équilibreurs de charge et les gestionnaires de trafic détectent si une instance principale peut traiter les requêtes. Sans sondes d’intégrité, un équilibreur de charge pourrait continuer à envoyer du trafic à un serveur défaillant ou qui ne répond plus, ce qui provoquerait des erreurs visibles par les utilisateurs. Des sondes d’intégrité correctement configurées permettent de réacheminer automatiquement le trafic loin des instances défaillantes quelques secondes après une panne.

Azure Load Balancer prend en charge deux types de sondes d’intégrité :

• Sonde TCP — vérifie que le serveur principal peut accepter une connexion TCP sur un port donné. Cette méthode est simple, mais ne vérifie pas la logique de l’application.
• Sonde HTTP/HTTPS — envoie une requête GET vers un chemin donné et attend une réponse 200 OK. Elle est plus précise, car elle teste directement le point de terminaison de l’application.

Un serveur principal est marqué comme défaillant si la sonde échoue pendant un nombre configurable de tentatives consécutives.

Un point de terminaison d’intégrité bien conçu (/health) ne se contente pas de renvoyer 200 OK : il vérifie que les dépendances critiques de l’application sont accessibles. Une vérification d’intégrité complète peut tester la connectivité à la base de données, au cache et à toutes les API en aval. Si une dépendance est indisponible, le point de terminaison renvoie un code d’état 5xx, signalant à l’équilibreur de charge de retirer cette instance de la rotation.

Azure Traffic Manager utilise également des sondes d’intégrité, mais au niveau régional. Il envoie périodiquement des requêtes GET HTTP ou HTTPS à l’URL du point de terminaison configuré dans chaque région. Si un point de terminaison ne répond pas dans le délai d’attente pendant un nombre défini d’intervalles consécutifs, Traffic Manager le marque comme dégradé et cesse d’y acheminer les requêtes DNS, redirigeant les utilisateurs vers une région saine.

Azure Application Gateway offre des fonctionnalités de sonde d’intégrité plus avancées que l’équilibreur de charge standard. Il prend en charge des sondes personnalisées qui définissent l’en-tête d’hôte, la plage de codes d’état attendue (par exemple, 200-399) et une chaîne à rechercher dans le corps de la réponse. Application Gateway prend également en charge le routage par chemin, ce qui permet à différents pools de serveurs principaux d’utiliser des configurations de sondes d’intégrité distinctes pour différents chemins d’URL.

La dégradation progressive est la capacité d’une application à continuer de fournir une partie de ses fonctionnalités lorsqu’une ou plusieurs de ses dépendances échouent. Au lieu de tomber entièrement en panne, l’application détecte l’indisponibilité d’un service non critique et adopte un mode dégradé, mais toujours utile. Par exemple, si un service de recommandations tombe en panne, un site de commerce en ligne peut afficher des suggestions génériques au lieu de faire échouer toute la page du produit.

Le modèle du disjoncteur empêche une application d’appeler de manière répétée un service en aval défaillant. Lorsqu’un service commence à rencontrer des défaillances, le disjoncteur s’ouvre et renvoie immédiatement une erreur ou une réponse de repli sans effectuer l’appel réseau. Après une période de refroidissement, il passe à l’état semi-ouvert et autorise une requête d’essai. Si celle-ci réussit, le disjoncteur se ferme et le fonctionnement normal reprend.

Pour les défaillances transitoires (brèves perturbations réseau, surcharge temporaire d’un service), une stratégie de nouvelle tentative avec temporisation Exponential est appropriée. L’application renouvelle l’appel ayant échoué après un délai, en doublant ce délai à chaque tentative jusqu’à atteindre un maximum. L’ajout d’un jitter (variation aléatoire) au délai empêche toutes les tentatives de se synchroniser et de surcharger un service en cours de rétablissement.

Le modèle de cloisonnement isole différentes parties d’une application dans des pools de ressources afin qu’une défaillance dans une zone ne consomme pas toutes les ressources et ne mette pas l’ensemble du système hors service. Ce modèle tire son nom des cloisons des navires, qui empêchent qu’un compartiment inondé fasse sombrer tout le bâtiment. Dans Azure, cela peut consister à utiliser des pools de threads distincts ou des plans App Service distincts pour différents services afin de contenir les défaillances.

Une technique courante de dégradation maîtrisée consiste à fournir des données mises en cache ou obsolètes lorsqu’une source de données en temps réel n’est pas disponible. Par exemple, une page de catalogue de produits peut fournir les prix d’hier mis en cache depuis Azure Cache for Redis au lieu d’afficher une erreur si la base de données est temporairement inaccessible. Les utilisateurs subissent un désagrément mineur (des prix légèrement obsolètes) plutôt qu’une panne complète.

La dégradation maîtrisée doit être visible et mesurée. Utilisez Application Insights pour suivre, au moyen de métriques personnalisées, le taux d’ouvertures du disjoncteur, de réponses de repli et de tentatives répétées. Configurez des alertes lorsque ces métriques dépassent certains seuils, afin que l’équipe d’astreinte soit informée que l’application fonctionne en mode dégradé, même si l’expérience des utilisateurs semble acceptable.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les sondes d’intégrité permettent aux équilibreurs de charge de détecter les serveurs principaux défaillants et de réacheminer automatiquement le trafic ; que la dégradation maîtrisée permet aux applications de rester partiellement fonctionnelles lorsque leurs dépendances rencontrent des défaillances ; et que des modèles tels que le disjoncteur, la nouvelle tentative avec temporisation et le cloisonnement assurent la résilience au niveau de l’application. Nous allons maintenant étudier les concepts de reprise après sinistre : définition de RTO, RPO et des niveaux de Recovery.