Partager via

Recommandations en matière d’auto-guérison et de préservation de soi

  • Article

S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :

RE :07 Renforcez la résilience et la récupération de votre charge de travail en implémentant des mesures d’auto-préservation et d’auto-réparation. Générez des fonctionnalités dans la solution à l’aide de modèles de fiabilité basés sur l’infrastructure et de modèles de conception basés sur le logiciel pour gérer les défaillances des composants et les erreurs temporaires. Générez des fonctionnalités dans le système pour détecter les défaillances des composants de solution et lancer automatiquement une action corrective pendant que la charge de travail continue à fonctionner à pleine ou réduite.

Guides connexes : erreurs temporaires des travaux | en arrière-plan

Ce guide décrit les recommandations relatives à la création de fonctionnalités d’auto-réparation et de conservation automatique dans votre architecture d’application pour optimiser la fiabilité.

Les fonctionnalités d’autopréservation ajoutent une résilience à votre charge de travail. Elles réduisent la probabilité d’une panne complète et permettent à votre charge de travail de fonctionner dans un état dégradé pendant que les composants ayant échoué sont récupérés. Les fonctionnalités d’autoréparation vous permettent d’éviter les temps d’arrêt en créant des actions correctives automatiques et de détection des défaillances pour répondre à différents types d’échecs.

Ce guide décrit les modèles de conception qui se concentrent sur la préservation de soi et l’auto-guérison. Incorporez-les dans votre charge de travail pour renforcer sa résilience et sa récupération. Si vous n’implémentez pas de modèles, vos applications risquent d’échouer lorsque des problèmes inévitables surviennent.

Définitions

Terme Définition
Autoréparation Capacité de votre charge de travail à résoudre automatiquement les problèmes en récupérant les composants affectés et, le cas échéant, en basculant vers une infrastructure redondante.
Auto-protection Capacité de votre charge de travail à résister aux problèmes potentiels.

Stratégies de conception

Conception pour la préservation de soi

Pour concevoir votre charge de travail pour la conservation automatique, suivez les modèles de conception d’architecture d’infrastructure et d’application pour optimiser la résilience de votre charge de travail. Pour réduire le risque de panne d’une application complète, augmentez la résilience de votre solution en éliminant les points de défaillance uniques et en réduisant le rayon d’explosion des défaillances. Les approches de conception de cet article fournissent plusieurs options pour renforcer la résilience de votre charge de travail et répondre aux objectifs de fiabilité définis par votre charge de travail.

Conseils et modèles de conception d’infrastructure

Au niveau de l’infrastructure, une conception d’architecture redondante doit prendre en charge vos flux critiques, avec des ressources déployées dans des zones de disponibilité ou des régions. Implémentez la mise à l’échelle automatique si possible. La mise à l’échelle automatique permet de protéger votre charge de travail contre les rafales inattendues d’activité, en renforçant davantage votre infrastructure.

Utilisez le modèle Tampons de déploiement ou le modèle bulkhead pour réduire le rayon d’explosion lorsque des problèmes se produisent. Ces modèles permettent de maintenir votre charge de travail disponible si un composant individuel n’est pas disponible. Utilisez les modèles de conception d’application suivants en combinaison avec votre stratégie de mise à l’échelle automatique.

  • Modèle Tampons de déploiement : provisionnez, gérez et surveillez un groupe varié de ressources pour héberger et exploiter plusieurs charges de travail ou locataires. Chaque copie individuelle est appelée empreinte voire unité de service, unité d’échelle ou cellule.

  • Modèle de cloisonnement : partitionner des instances de service en différents groupes, appelés pools, en fonction des exigences de charge et de disponibilité du consommateur. Cette conception permet d’isoler les défaillances et vous permet de maintenir les fonctionnalités de service pour certains consommateurs, même lors d’une défaillance.

Conseils et modèles de conception d’application

Évitez de créer des applications monolithiques dans votre conception d’application. Utilisez des services ou des microservices faiblement couplés qui communiquent les uns avec les autres via des normes bien définies pour réduire le risque de problèmes étendus lorsque des dysfonctionnements se produisent à un seul composant. Par exemple, vous pouvez normaliser l’utilisation d’un service bus pour gérer toutes les communications asynchrones. La normalisation des protocoles de communication garantit que la conception des applications est cohérente et simplifiée, ce qui rend la charge de travail plus fiable et plus facile à résoudre quand des dysfonctionnements se produisent. Si c’est pratique, préférez la communication asynchrone entre les composants par rapport à la communication synchrone pour réduire les problèmes de délai d’expiration, tels que la lettre morte. Les modèles de conception suivants vous aident à organiser votre charge de travail et à définir les communications entre les composants d’une manière qui répond le mieux à vos besoins métier.

  • Modèle Ambassadeur : séparez votre logique métier de votre code réseau et de votre logique de résilience. Créez des services d’assistance qui envoient des requêtes réseau pour le compte d’applications ou d’un service consommateur. Vous pouvez utiliser ce modèle pour implémenter des mécanismes de nouvelle tentative ou des ruptures de circuit.

  • Modèle de demande-réponse asynchrone : dissocier le traitement back-end d’un hôte frontal si le traitement back-end doit être asynchrone, mais que le serveur frontal a besoin d’une réponse claire.

  • Modèle Cache-Aside : chargez des données à la demande à partir d’un magasin de données dans un cache. Ce modèle peut améliorer les performances et aider à maintenir la cohérence entre les données conservées dans le cache et les données qui se trouvent dans le magasin de données sous-jacent.

  • Modèle disjoncteur : utilisez des disjoncteurs pour déterminer de manière proactive s’il faut autoriser une opération à continuer ou à retourner une exception en fonction du nombre de défaillances récentes.

  • Modèle de vérification des revendications : fractionnez un message volumineux en une vérification de revendication et une charge utile. Envoyez la vérification des revendications à la plateforme de messagerie et stockez la charge utile dans un service externe. Ce modèle permet aux messages volumineux d’être traités tout en protégeant le bus de messages et en empêchant le client d’être submergé ou ralenti.

  • Modèle consommateurs concurrents : permettre à plusieurs consommateurs simultanés de traiter les messages reçus sur le même canal de messagerie. Un système peut traiter plusieurs messages simultanément, ce qui optimise le débit, améliore la scalabilité et la disponibilité, et équilibre la charge de travail.

  • Configurer les délais d’expiration des demandes : configurez les délais d’expiration des demandes pour les appels aux services ou aux bases de données. Les délais d’expiration de connexion de base de données sont généralement définis sur 30 secondes.

  • Modèle Gatekeeper : Protégez les applications et les services à l’aide d’une instance hôte dédiée pour répartir les demandes entre les clients et l’application ou le service. Le répartiteur valide et nettoie les demandes et peut fournir une couche supplémentaire de sécurité pour limiter la surface d’attaque du système.

  • Modèle de niveau de charge basé sur la file d’attente : dissociez les tâches du service dans votre solution à l’aide d’une file d’attente entre elles afin qu’elles puissent chacune s’exécuter de manière asynchrone. Utilisez une file d’attente comme mémoire tampon entre une tâche et un service qu’il appelle pour aider les charges lourdes intermittentes lisses qui peuvent entraîner l’échec du service ou l’expiration de la tâche. Ce modèle peut aider à réduire l’effet des pics de demande sur la disponibilité et la réactivité de la tâche et du service.

  • Modèle de limitation : contrôlez la consommation de ressources utilisées par une instance d’une application, d’un locataire individuel ou d’un service entier. Ce modèle permet au système de continuer à fonctionner et à respecter les contrats de niveau de service (SLA), même lorsqu’une augmentation de la demande place une charge extrême sur les ressources.

  • Modèle de gestion des erreurs temporaires et modèle nouvelle tentative : implémentez une stratégie pour gérer les défaillances temporaires afin de fournir une résilience dans votre charge de travail. Les défaillances temporaires sont normales et attendues dans les environnements cloud. Les causes courantes des erreurs temporaires incluent la perte momentanée de la connectivité réseau, une connexion de base de données supprimée ou un délai d’expiration lorsqu’un service est occupé. Pour plus d’informations sur le développement d’une stratégie de nouvelle tentative, consultez le guide de gestion des erreurs temporaires de cette série.

Travaux en arrière-plan

Les travaux en arrière-plan constituent un moyen efficace d’améliorer la fiabilité d’un système en découplant les tâches de l’interface utilisateur. Implémentez une tâche en tant que travail en arrière-plan s’il ne nécessite pas d’entrée ou de commentaires utilisateur et s’il n’affecte pas la réactivité de l’interface utilisateur.

Voici quelques exemples courants de travaux en arrière-plan :

  • Travaux nécessitant beaucoup d’UC, tels que l’exécution de calculs complexes ou l’analyse de modèles structurels.
  • Travaux gourmands en E/S, tels que l’exécution de plusieurs opérations de stockage ou l’indexation de fichiers volumineux.
  • Travaux Batch, tels que la mise à jour des données régulièrement ou le traitement des tâches à un moment spécifique.
  • Flux de travail longs, tels que l’exécution d’une commande ou l’approvisionnement de services et de systèmes.

Pour plus d’informations, consultez Recommandations pour les travaux en arrière-plan.

Conception de la réparation spontanée

Pour concevoir votre charge de travail pour la réparation automatique, implémentez la détection des défaillances afin que les réponses automatiques soient déclenchées et que les flux critiques récupèrent correctement. Activez la journalisation pour fournir des insights opérationnels sur la nature de l’échec et la réussite de la récupération. Les approches que vous prenez pour obtenir la réparation automatique d’un flux critique dépendent des cibles de fiabilité définies pour ce flux et les composants et dépendances du flux.

Conseils en matière de conception d’infrastructure

Au niveau de l’infrastructure, vos flux critiques doivent être pris en charge par une conception d’architecture redondante avec basculement automatisé activé pour les composants qui le prennent en charge. Vous pouvez activer le basculement automatisé pour les types de services suivants :

  • Ressources de calcul : Les groupes de machines virtuelles identiques Azure et la plupart des services de calcul PaaS (Platform as a Service) peuvent être configurés pour le basculement automatique.

  • Bases de données : les bases de données relationnelles peuvent être configurées pour le basculement automatique avec des solutions telles que des clusters de basculement Azure SQL, des groupes de disponibilité Always On ou des fonctionnalités intégrées avec les services PaaS. Les bases de données NoSQL ont des fonctionnalités de clustering similaires et des fonctionnalités intégrées pour les services PaaS.

  • Stockage : utilisez des options de stockage redondantes avec basculement automatique.

Conseils et modèles de conception d’application

  • Bloquer les acteurs incorrects : si vous limitez un client, cela ne signifie pas que le client agissait de manière malveillante. Cela peut signifier que le client a dépassé son quota de service. Toutefois, si un client dépasse constamment son quota ou qu’il se comporte mal, vous pouvez les bloquer. Définissez un processus hors bande pour qu’un client demande la déblocage.

  • Modèle disjoncteur : si une défaillance persiste après le lancement de votre mécanisme de nouvelle tentative, vous risquez des défaillances en cascade résultant d’un backlog croissant d’appels. Un disjoncteur conçu pour fonctionner avec le mécanisme de nouvelle tentative limite le risque de défaillances en cascade en empêchant l’application de tenter à plusieurs reprises d’exécuter une opération susceptible d’échouer.

  • Modèle de transaction de compensation : si vous utilisez une opération cohérente qui se compose d’une série d’étapes, implémentez le modèle de transaction de compensation. Si une ou plusieurs des étapes échouent, vous pouvez utiliser ce modèle pour annuler le travail effectué par les étapes.

  • Dégrader correctement : parfois, vous ne pouvez pas contourner un problème, mais vous pouvez fournir des fonctionnalités réduites. Imaginez une application qui propose un catalogue de livres. Si l’application ne peut pas récupérer l’image miniature de la couverture, elle affichera une image de substitution. Des sous-systèmes entiers peuvent s’avérer non critiques pour l’application. Par exemple, pour un site web de commerce électronique, l’affichage des recommandations de produit est probablement moins critique que le traitement des commandes. La dégradation appropriée peut également inclure des opérations de basculement automatique. Lorsqu’une base de données bascule automatiquement vers un réplica en raison d’un problème avec l’instance principale, les performances sont dégradées pendant une courte période.

  • Modèle d’élection du responsable : lorsque vous devez coordonner une tâche, utilisez l’élection du chef pour sélectionner un coordinateur afin qu’un coordinateur ne soit pas un point d’échec unique. Si le coordinateur échoue, un autre est sélectionné. Au lieu d’implémenter un algorithme d’élection de leader à partir de zéro, envisagez une solution prête à l’emploi, telle que ZooKeeper.

  • Modèles de test : incluez les tests des modèles que vous implémentez dans le cadre de vos procédures de test standard.

  • Utilisez des points de contrôle pour les transactions de longue durée : les points de contrôle peuvent fournir une résilience en cas d’échec d’une opération de longue durée. Lorsque l’opération redémarre, par exemple si elle est récupérée par une autre machine virtuelle, elle peut reprendre à partir du dernier point de contrôle. Envisagez d’implémenter un mécanisme qui enregistre les informations d’état sur la tâche à intervalles réguliers. Enregistrez cet état dans un stockage durable accessible par n’importe quelle instance du processus exécutant la tâche. Si le processus est arrêté, le travail qu’il effectue peut être repris à partir du dernier point de contrôle à l’aide d’une autre instance. Il existe des bibliothèques qui fournissent cette fonctionnalité, telles que NServiceBus et MassTransit. Elles conservent en toute transparence l’état où les intervalles sont alignés sur le traitement des messages à partir de files d’attente dans Azure Service Bus.

Actions automatisées d’auto-guérison

Une autre approche de l’auto-guérison est l’utilisation d’actions automatisées déclenchées par votre solution de supervision lorsque des modifications d’état d’intégrité prédéfinies sont détectées. Par exemple, si votre supervision détecte qu’une application web ne répond pas aux demandes, vous pouvez générer une automatisation via un script PowerShell pour redémarrer le service d’application. Selon l’ensemble de compétences de votre équipe et les technologies de développement préférées, utilisez un webhook ou une fonction pour créer des actions d’automatisation plus complexes. Consultez l’architecture de référence de l’automatisation cloud basée sur les événements pour obtenir un exemple d’utilisation d’une fonction pour répondre à la limitation de la base de données. L’utilisation d’actions automatisées peut vous aider à récupérer rapidement et à réduire la nécessité d’une intervention humaine.

Facilitation Azure

La plupart des services Azure et des kits de développement logiciel (SDK) client incluent un mécanisme de nouvelle tentative. Mais ils diffèrent, car chaque service a des caractéristiques et des exigences différentes, de sorte que chaque mécanisme de nouvelle tentative est paramétré sur un service spécifique. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Utilisez des groupes d’actions Azure Monitor pour les notifications, telles que l’e-mail, la voix ou les SMS, et pour déclencher des actions automatisées. Lorsque vous êtes averti d’une défaillance, déclenchez un runbook Azure Automation, Azure Event Hubs, une fonction Azure, une application logique ou un webhook pour effectuer une action de guérison automatisée.

À propos de l’installation

Familiarisez-vous avec les considérations relatives à chaque modèle. Assurez-vous que le modèle convient à vos exigences de charge de travail et d’entreprise avant l’implémentation.

Exemple

Par exemple, les cas d’utilisation de certains modèles, consultez le modèle d’application web fiable pour .NET. Suivez ces étapes pour déployer une implémentation de référence.

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de fiabilité