REL 5: Comment concevez-vous des interactions dans un système distribué pour atténuer ou résister aux défaillances ?

Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants (tels que des serveurs ou des services). Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence sur ces réseaux. Les composants du système distribué doivent fonctionner d'une manière qui n'a pas d'impact négatif sur les autres composants ou la charge de travail. Ces bonnes pratiques permettent aux charges de travail de résister aux contraintes ou aux défaillances, de s'en remettre plus rapidement et d'atténuer l'impact de ces déficiences. Il en résulte une amélioration du temps moyen de récupération (MTTR).

Ressources

Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
Error Retries and Exponential Backoff in AWS
Amazon API Gateway: Throttle API Requests for Better Throughput
The Amazon Builders' Library: Timeouts, retries, and backoff with jitter
The Amazon Builders' Library: Avoiding fallback in distributed systems
The Amazon Builders' Library: Avoiding insurmountable queue backlogs
The Amazon Builders' Library: Caching challenges and strategies
Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability
CircuitBreaker (summarizes Circuit Breaker from “Release It!” book)
Michael Nygard “Release It! Design and Deploy Production-Ready Software”

Bonnes pratiques:

Plan d'amélioration

Implémenter une dégradation appropriée pour transformer les dépendances dures applicables en dépendances souples

  • Implémenter une dégradation appropriée pour transformer les dépendances dures applicables en dépendances souples: Lorsque les dépendances d'un composant ne sont pas saines, le composant lui-même peut continuer de fonctionner, même si de manière dégradée. Par exemple, lorsqu'un appel de dépendance échoue, basculez vers une réponse statique prédéterminée.
  • Demandes de limitation

  • Demandes de limitation: Il s'agit d'un modèle d'atténuation conçu répondre à une augmentation inattendue de la demande. Certaines demandes sont honorées, mais celles qui dépassent une limite définie sont rejetées et renvoient un message indiquant qu'elles ont été limitées. On attend des clients qu'ils renoncent à leur demande ou qu'ils essaient à nouveau à un taux plus lent.
  • Contrôler et limiter les appels de nouvelle tentative

  • Contrôler et limiter les appels de nouvelle tentative: Utilisez le backoff exponentiel pour réessayer après des intervalles progressivement plus longs. Introduisez l'instabilité pour randomiser ces intervalles de nouvelle tentative et limitez le nombre maximal de nouvelles tentatives.
    Error Retries and Exponential Backoff in AWS
  • Échec rapide et limite des files d'attente

  • Échec rapide et limite des files d'attente: Si la charge de travail n'est pas en mesure de répondre avec succès à une demande, procédez à son interruption immédiate. Cela permet la libération des ressources associées à une demande et permet au service de récupérer s'il manque de ressources. Si la charge de travail est en mesure de répondre avec succès, mais que le taux de requêtes est trop élevé, utilisez plutôt une file d'attente pour mettre les requêtes en mémoire tampon. N'autorisez toutefois pas les files d'attente longues qui peuvent entraîner le traitement de requêtes obsolètes que le client a déjà abandonnées.
  • Définir les délais d'attente du client

  • Définir un délai de connexion et un délai de demande pour tout appel à distance et, plus généralement, pour tout appel entre processus: De nombreux cadres offrent des fonctionnalités de délai d'expiration intégrées. Toutefois, restez prudent, car beaucoup d'entre elles ont des valeurs par défaut infinies ou trop élevées. Une valeur trop élevée réduit l'utilité du délai d'attente, car les ressources continuent d'être consommées pendant que le client attend l'expiration du délai. Une valeur trop faible peut générer un trafic accru sur le backend et une latence accrue en raison du trop grand nombre de demandes relancées. Dans certains cas, cela peut entraîner des interruptions complètes, car toutes les demandes font l'objet d'une nouvelle tentative.
    AWS SDK: Retries and Timeouts
  • Rendre les services sans état dans la mesure du possible

  • Faites de vos applications des applications apatrides: Les applications apatrides permettent une mise à l'échelle horizontale et tolèrent la défaillance d'un nœud individuel.
  • Mettre en place des leviers d'urgence

  • Mettre en place des leviers d'urgence: Il s'agit de processus rapides qui peuvent atténuer l'impact sur la disponibilité de votre charge de travail. Ils peuvent être exploités en l'absence d'une cause racine. Un levier d'urgence idéal réduit à zéro la charge cognitive sur les résolveurs en fournissant des critères d'activation et de désactivation entièrement déterministes. Les exemples de leviers incluent le blocage de tout le trafic robotique ou le traitement d'une réponse statique. Les leviers sont souvent manuels, mais ils peuvent également être automatisés.