REL 4: Comment concevez-vous des interactions dans un système distribué pour éviter les défaillances ?

Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants comme des serveurs ou des services. Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence dans 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 empêchent les défaillances et améliorent le temps moyen entre les défaillances (MTBF).

Ressources

AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems

Bonnes pratiques:

• Identifier le type de système distribué requis: Les systèmes distribués en temps réel durs exigent la fourniture des réponses de manière synchrone et rapide, alors que les systèmes en temps réel souples disposent d'une fenêtre de temps plus importante (en minutes ou plus). Les systèmes hors connexion gèrent les réponses via un traitement par lots ou asynchrone. Les systèmes distribués en temps réel ont les exigences de fiabilité les plus strictes.

• Implémenter des dépendances couplées faiblement: Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage souple permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.

• Rendre toutes les réponses idempotentes: Un service idempotent promet que chaque demande est traitée une seule fois et exactement de la même façon, de sorte que l'exécution de plusieurs demandes identiques ait le même effet qu'une seule demande. Un service idempotent permet à un client d'implémenter plus facilement les nouvelles tentatives sans craindre qu'une demande soit traitée plusieurs fois par erreur. Pour ce faire, les clients peuvent émettre des demandes d'API avec un jeton d'idempotence. Le même jeton est utilisé chaque fois que la demande est répétée. Une API de service idempotente utilise le jeton pour renvoyer une réponse identique à la réponse qui a été renvoyée la première fois que la demande a été traitée.

• Effectuer un travail constant: Les systèmes peuvent échouer en cas de modifications importantes et rapides de charge. Par exemple, un système de vérification de l'état qui surveille l'état de milliers de serveurs doit envoyer chaque fois la même charge utile de taille (un instantané complet de l'état actuel). Le système de vérification de l'état fait un travail constant sans changements importants et rapides, qu'aucun serveur ne soit défaillant ou qu'ils le soient tous.

Plan d'amélioration

Identifier le type de système distribué requis

Identifier le type de système distribué requis: Les défis posés par les systèmes distribués sont la latence, la mise à l'échelle, la compréhension des API de réseau, le regroupement et le dégroupement des données et la complexité des algorithmes tels que Paxos. Des cas jadis marginaux et théoriques deviennent monnaie courante au fur et à mesure que les systèmes devenaient de plus en plus grands et distribués.
The Amazon Builders' Library: Challenges with distributed systems

• Des réponses données de manière synchrone et rapide sont nécessaires pour les systèmes distribués en temps réel durs.
• Les systèmes en temps réel souples ont un créneau de temps plus généreux de plusieurs minutes ou plus pour la réponse.
• Les systèmes hors connexion gèrent les réponses via un traitement par lots ou asynchrone.
• Les systèmes distribués en temps réel ont les exigences de fiabilité les plus strictes.

Implémenter des dépendances couplées faiblement

Implémenter des dépendances couplées faiblement: Des dépendances telles que des systèmes de file d'attente, des systèmes de streaming, des flux de travail et des équilibreurs de charge sont couplées faiblement. Le couplage souple permet d'isoler le comportement d'un composant des autres composants qui en dépendent, ce qui augmente la résilience et l'agilité.
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?

• Amazon EventBridge vous permet de créer des architectures pilotées par les événements, qui sont faiblement couplées et distribuées.
  AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205)
• Si les changements apportés à un composant obligent les autres composants qui en dépendent à changer également, c'est qu'ils sont étroitement liés. Le couplage souple rompt cette dépendance de sorte que les composants de dépendance n'ont besoin que de connaître l'interface publiée et déclinée en version.
• Rendez les interactions des composants aussi asynchrones que possible. Ce modèle convient à toute interaction qui n'a pas besoin d'une réponse immédiate et pour laquelle un accusé de réception indiquant qu'une demande a été enregistrée suffira.
  AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)

Rendre toutes les réponses idempotentes

Rendre toutes les réponses idempotentes: Un service idempotent promet que chaque demande est traitée une seule fois et exactement de la même façon, de sorte que l'exécution de plusieurs demandes identiques ait le même effet qu'une seule demande.

• Les clients peuvent émettre des demandes d'API avec un jeton d'idempotence. Le même jeton est utilisé chaque fois que la demande est répétée. Une API de service idempotente utilise le jeton pour renvoyer une réponse identique à la réponse qui a été renvoyée la première fois que la demande a été traitée.
  Amazon EC2: Ensuring Idempotency

Effectuer un travail constant

Effectuer un travail constant: Les systèmes peuvent échouer en cas de modifications importantes et rapides de charge.
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)

• Charges de travail d'ingénieurs afin que les tailles de charge utile restent constantes, quel que soit le nombre de succès ou d'échecs.
  • Par exemple, si le système de vérification de l'état surveille 100 000 serveurs, la charge sur celui-ci est nominale sous le taux de défaillance normalement faible du serveur. Toutefois, si un événement majeur rend la moitié de ces serveurs non sains, le système de vérification de l'état sera submergé lors de la mise à jour des systèmes de notification et de la communication de l'état à ses clients. Cet incident peut être évité si le système de vérification de l'état envoie l'instantané complet de l'état actuel à chaque fois. 100 000 états d'intégrité du serveur, chacun représenté par un bit, ne seraient qu'une charge utile de 12,5 Ko. Le système de vérification de l'état fonctionne constamment, qu'aucun serveur ne soit en panne ou qu'ils le soient tous. En outre, les changements importants et rapides ne constituent pas une menace pour la stabilité du système. C'est ainsi que le plan de contrôle est conçu pour les vérifications de l'état Amazon Route 53.