Recommandations pour l’auto-guérison et l’auto-conservation

  • Article

S’applique à cette recommandation de liste de vérification de fiabilité 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-conservation et d’auto-réparation. Créez 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 des logiciels pour gérer les défaillances de composants et les erreurs temporaires. Créez des fonctionnalités dans le système pour détecter les défaillances des composants de la solution et lancer automatiquement une action corrective pendant que la charge de travail continue de fonctionner à l’intégralité ou à la réduction des fonctionnalités.

Guides associés :Travaux | en arrière-planErreurs temporaires

Ce guide décrit les recommandations pour créer des fonctionnalités d’auto-réparation et d’auto-conservation dans votre architecture d’application afin d’optimiser la fiabilité.

Les fonctionnalités d’auto-conservation ajoutent de la résilience à votre charge de travail. Ils réduisent la probabilité d’une panne complète et permettent à votre charge de travail de fonctionner dans un état dégradé pendant la récupération des composants défaillants. Les fonctionnalités d’auto-réparation vous aident à éviter les temps d’arrêt en créant dans la détection des défaillances et des actions correctives automatiques pour répondre à différents types de défaillances.

Ce guide décrit les modèles de conception qui se concentrent sur l’auto-conservation et l’auto-guérison. Intégrez-les à 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 en cas de problèmes inévitables.

Définitions

Terme Définition
Autoréparation La capacité de votre charge de travail à résoudre automatiquement les problèmes en récupérant les composants affectés et, si nécessaire, en basculant vers une infrastructure redondante.
Auto-conservation Capacité de votre charge de travail à être résiliente face aux problèmes potentiels.

Stratégies de conception

Conseils pour la préservation de soi

Pour concevoir votre charge de travail pour l’auto-conservation, suivez les modèles de conception de l’infrastructure et de l’architecture d’application afin d’optimiser la résilience de votre charge de travail. Pour réduire les risques de panne complète de l’application, 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 décrites dans cet article offrent plusieurs options pour renforcer la résilience de votre charge de travail et atteindre les objectifs de fiabilité définis de 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 lorsque cela est possible. La mise à l’échelle automatique permet de protéger votre charge de travail contre les pics d’activité imprévus, ce qui renforce davantage votre infrastructure.

Utilisez le modèle Empreintes de déploiement ou le modèle De cloisonnement pour réduire le rayon d’explosion en cas de problème. 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 d’empreintes de déploiement : approvisionnez, gérez et supervisez 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 : partitionnez les 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 en cas de défaillance.

Conseils et modèles de conception d’application

Évitez de créer des applications monolithiques dans la conception de votre application. Utilisez des services ou des microservices faiblement couplés qui communiquent entre eux via des normes bien définies pour réduire le risque de problèmes importants lorsque des dysfonctionnements se produisent sur un seul composant. Par exemple, vous pouvez standardiser 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 en cas de dysfonctionnements. Lorsque cela est pratique, préférez la communication asynchrone entre les composants à la communication synchrone pour réduire les problèmes de délai d’attente, comme les lettres mortes. Les modèles de conception suivants vous aident à organiser votre charge de travail et à définir les communications entre les composants de la manière qui répond le mieux aux besoins de votre entreprise.

  • Modèle d’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 une rupture de circuit.

  • Modèle de Request-Reply asynchrone : dissocier le traitement back-end d’un hôte frontal si le traitement back-end doit être asynchrone, mais si 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 qui sont 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 se poursuivre ou retourner une exception en fonction du nombre d’échecs récents.

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

  • Modèle de consommateurs concurrents : permet à 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 des connexions 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’un hôte dédié instance pour traiter les demandes entre les clients et l’application ou le service. Le répartiteur valide et assainit les requêtes et peut fournir une couche de sécurité supplémentaire pour limiter la surface d’attaque du système.

  • Modèle de nivellement 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’elle appelle pour faciliter les charges lourdes intermittentes 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 des ressources utilisées par un instance d’une application, d’un locataire individuel ou d’un service entier. Ce modèle permet au système de continuer à fonctionner et de respecter les contrats de niveau de service (SLA), même lorsqu’une augmentation de la demande entraîne une charge extrême sur les ressources.

  • Modèle de gestion des erreurs temporaires et modèle de nouvelle tentative : implémentez une stratégie pour gérer les échecs temporaires afin de fournir une résilience dans votre charge de travail. Les échecs temporaires sont des occurrences normales et attendues dans les environnements cloud. Les causes typiques d’erreurs temporaires incluent une perte momentanée de connectivité réseau, une connexion de base de données supprimée ou un délai d’attente 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 arrière-plan si elle ne nécessite pas d’entrée ou de commentaires de l’utilisateur et si elle n’affecte pas la réactivité de l’interface utilisateur.

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

  • Travaux gourmands en ressources processeur, 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 par lots, tels que la mise à jour régulière des données ou le traitement des tâches à un moment spécifique.
  • Flux de travail de longue durée, 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.

Guide auto-guérissant

Pour concevoir votre charge de travail en vue d’une réparation automatique, implémentez la détection des défaillances afin que des réponses automatiques soient déclenchées et que les flux critiques soient récupérés 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 utilisez pour obtenir la réparation automatique d’un flux critique dépendent des cibles de fiabilité définies pour ce flux, ainsi que des composants et dépendances du flux.

Conseils de conception d’infrastructure

Au niveau de l’infrastructure, vos flux critiques doivent être pris en charge par une conception d’architecture redondante avec un 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 : Azure Virtual Machine Scale Sets 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 malveillants : si vous limitez un client, cela ne signifie pas que le client a agi de manière malveillante. Cela peut signifier que le client a dépassé son quota de service. Mais si un client dépasse constamment son quota ou se comporte mal, vous pouvez le bloquer. Définissez un processus hors bande pour qu’un client demande le déblocage.

  • Modèle de 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 d’essayer à 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 de recommandations de produits est probablement moins critique que le traitement des commandes. La dégradation normale 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 le instance principal, les performances sont dégradées pendant une courte période.

  • Modèle d’élection de leader : lorsque vous devez coordonner une tâche, utilisez l’élection du leader pour sélectionner un coordinateur afin qu’un coordinateur ne soit pas un seul point d’échec. Si le coordinateur échoue, un autre est sélectionné. Plutôt que 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 le test 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 des informations d’état sur la tâche à intervalles réguliers. Enregistrez cet état dans un stockage durable accessible à n’importe quel instance du processus exécutant la tâche. Si le processus est arrêté, le travail qu’il effectuait peut être repris à partir du dernier point de contrôle à l’aide d’un 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 d’auto-réparation automatisées

Une autre approche de la réparation automatique consiste à utiliser des actions automatisées qui sont déclenchées par votre solution de surveillance lorsque des modifications d’intégrité status déterminées 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 l’automatisation via un script PowerShell pour redémarrer le service d’application. En fonction de l’ensemble des compétences de votre équipe et des 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 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 parce que chaque service a des caractéristiques et des exigences différentes, de sorte que chaque mécanisme de nouvelle tentative est réglé 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, comme 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, un Azure Event Hubs, une fonction Azure, une application logique ou un webhook pour effectuer une action de réparation automatisée.

Considérations

Familiarisez-vous avec les considérations relatives à chaque modèle. Assurez-vous que le modèle est adapté à votre charge de travail et aux exigences métier avant l’implémentation.

Exemple

Par exemple, des 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é