Conception favorisant la résilience
 La charge de travail doit continuer à fonctionner avec des fonctionnalités complètes ou réduites. |
|---|
Vous devez vous attendre à ce que des défaillances de composants, des pannes de plateforme, une détérioration de performances et d’autres erreurs se produisent. Construisez la résilience dans le système pour qu’il soit tolérant aux pannes et puisse se dégrader normalement.
Exemple de scénario
Contoso Air est une compagnie aérienne commerciale avec un service de développement interne. L’application métier principale est une solution de réservation qui permet aux clients de réserver des vols directement auprès de Contoso Air. L’application est intégrée à Azure et utilise Azure App Service, Cosmos DB, Azure Functions, Azure Logic Apps et Azure Service Bus.
Déterminez les risques de défaillance.
Identifiez les points de défaillance potentiels dans le système, en particulier pour les composants critiques, et déterminez l’effet sur les flux utilisateur et système.
Analysez le cas de défaillance, le rayon d’impact et l’intensité de l’erreur pour chaque point de défaillance potentiel. Les cas de défaillance et leur intensité peuvent aller de scénarios avec un impact relativement faible comme la perte temporaire d’un processus de back-end à des pannes à grande échelle résultant de sinistres. L’exécution de cette analyse vous aide à déterminer la conception des fonctionnalités de gestion des erreurs au niveau du composant.
Défi de Contoso
- L’application métier fournit de nombreuses fonctions clés allant du marketing au commerce. Le flux utilisateur d’achat de billets a été identifié comme le flux le plus critique. L’équipe de charge de travail a déterminé qu’elle doit implémenter plus de mesures de fiabilité pour garantir l’optimisation du flux pour la résilience.
- L’équipe a du temps alloué pour faire des améliorations comme le découplage des composants et la refonte des flux, mais veut utiliser ce temps pour se concentrer sur les améliorations qui ont le plus de valeur.
Application de l’approche et résultats
- L’équipe identifie la passerelle de paiement externe comme un point de défaillance potentiel. La passerelle est hautement disponible, mais il y a un risque que les utilisateurs rencontrent des erreurs temporaires occasionnelles à la suite de problèmes réseau ou de rafales d’un très grand nombre de demandes. La passerelle peut rejeter certaines demandes si elle est surchargée par l’envoi de plusieurs demandes simultanées.
- L’équipe détermine que les utilisateurs doivent renvoyer leur demande quand la demande initiale est rejetée par la passerelle, ce qui provoque une expérience utilisateur négative.
Implémenter des mécanismes d’auto-protection
Créez des fonctionnalités d’auto-protection en utilisant correctement des modèles de conception et en modularisant la conception pour isoler les défaillances.
En créant des fonctionnalités d’auto-protection dans le système, vous pouvez empêcher un problème d’affecter les composants en aval. Le système peut atténuer les défaillances temporaires et permanentes, les goulots d’étranglement des performances et d’autres problèmes susceptibles d’affecter la fiabilité. Vous pouvez également réduire le rayon d’impact.
Défi de Contoso
- L’équipe souhaite réduire le risque de défaillances temporaires entraînant le rejet des demandes des utilisateurs par la passerelle de paiement. En raison de la nature temporaire de certaines conditions d’erreur, il y a de fortes chances que la même demande réussisse si elle est renvoyée.
Application de l’approche et résultats
- L’équipe développe une logique personnalisée dans le flux pour réessayer la transaction après un court délai quand une défaillance permettant un nouvel essai est détectée.
- La conception de la solution est modifiée pour incorporer le modèle de nouvelle tentative, ce qui augmente légèrement le temps d’attente entre les nouvelles tentatives jusqu’à ce que la demande soit correctement traitée ou que le nombre maximal de défaillances soit atteint.
- L’équipe décide également de dissocier l’interaction utilisateur et la fonctionnalité de traitement de paiement de back-end de ce flux en utilisant une approche pilotée par les événements avec Azure Service Bus. Quand des défaillances irrécupérables se produisent pendant le traitement du message (après le nombre maximal de nouvelles tentatives), le processeur de back-end abandonne le traitement de cette demande, en laissant le message dans la file d’attente pour qu’il puisse être retraité plus tard.
Créer une redondance et une résilience complètes
Construisez la redondance en couches et une résilience sur différentes couches Application.
Visez la redondance dans les fournisseurs physiques de services publics et la réplication immédiate des données. Visez également la redondance dans la couche fonctionnelle qui couvre les services, les opérations et le personnel. La redondance permet de réduire les points de défaillance uniques. Par exemple, si une panne affecte un ou plusieurs composants, une zone de disponibilité ou un déploiement régional redondant (actif-actif ou actif-passif) entier vous permet de répondre aux objectifs de temps d’activité.
L’ajout d’intermédiaires empêche une dépendance directe entre les composants et améliore la mise en mémoire tampon. Ces deux avantages renforcent la résilience du système.
Défi de Contoso
- L’implémentation de nouvelles tentatives et le découplage des appels de la passerelle de paiement à partir de l’interface utilisateur en utilisant Service Bus a considérablement augmenté la fiabilité de ce flux, mais les parties prenantes de l’entreprise s’inquiètent toujours de la perte de données pouvant se produire à la suite d’une défaillance catastrophique dans la région primaire.
Application de l’approche et résultats
- L’équipe décide de passer au niveau Premium de Service Bus. En procédant ainsi, elle peut tirer parti des fonctionnalités de prise en charge des zones de disponibilité de ce niveau. Avec cette fonctionnalité, plusieurs copies des données sont stockées dans trois installations physiquement séparées (zones de disponibilité) et le service a des réserves de capacité suffisantes pour faire face instantanément à la perte complète et catastrophique d’un centre de données.
- Par ailleurs, l’équipe configure la géo-reprise d’activité après sinistre Azure Service Bus pour répliquer en continu les données vers une région secondaire qui sera utilisée dans le cas peu probable d’une défaillance complète de la région primaire.