REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux - AWS Well-Architected Framework

REL11-BP05 Utiliser la stabilité statique pour éviter les comportements bimodaux

Un comportement bimodal survient lorsque votre charge de travail adopte un comportement différent en mode normal et en mode de défaillance, par exemple, en s'appuyant sur le lancement de nouvelles instances en cas de défaillance d'une zone de disponibilité. Pour éviter ce type de comportement, vous devez créer des charges de travail stables statiquement et qui fonctionnent dans un seul mode.  : dans ce cas, mettez en service suffisamment d'instances dans chaque zone de disponibilité pour gérer la charge de travail si une zone de disponibilité venait à être supprimée, puis utilisez les vérifications de l'état d'Elastic Load Balancing ou d'Amazon Route 53 pour déplacer la charge à distance des instances compromises.

La stabilité statique du déploiement de calcul (par exemple, des conteneurs ou des instances EC2) garantit une fiabilité optimale. Celle-ci doit être pondérée par rapport aux problèmes de coût. Il est moins coûteux d'allouer une capacité de calcul inférieure et de compter sur le lancement de nouvelles instances en cas de défaillance. Toutefois, pour les défaillances à grande échelle (par exemple, une défaillance de zone de disponibilité), cette approche est moins efficace, car elle repose sur la réaction aux défaillances à mesure qu'elles se produisent, plutôt que sur la préparation à contrer ces défaillances avant leur occurrence. Votre solution doit évaluer la fiabilité par rapport aux besoins en termes de coûts de votre charge de travail. En augmentant le nombre de zones de disponibilité utilisées, vous réduisez la quantité de calcul supplémentaire dont vous avez besoin pour la stabilité statique.

Diagramme illustrant la stabilité statique des instances EC2 dans les zones de disponibilité

Figure 14 : stabilité statique des instances EC2 dans les zones de disponibilité

Une fois le trafic déplacé, utilisez AWS Auto Scaling pour remplacer de manière asynchrone les instances de la zone défaillante et les lancer dans les zones saines.

Autre exemple de comportement bimodal : un délai d'expiration du réseau peut amener un système à tenter d'actualiser l'état de configuration de l'ensemble du système. Cette tentative ajoute une charge inattendue à un autre composant, ce qui peut entraîner un échec et déclencher d'autres conséquences imprévues. Cette boucle de rétroaction négative a un impact sur la disponibilité de votre charge de travail. Vous devriez donc créer des systèmes stables statiquement et fonctionnant dans un seul mode. Une conception statiquement stable consisterait à effectuer un travail constant et à toujours actualiser l'état de la configuration selon une cadence fixe. Lorsqu'un appel échoue, la charge de travail utilise la valeur précédemment mise en cache et déclenche une alarme.

Un autre exemple de comportement bimodal consiste à autoriser les clients à contourner votre cache de charge de travail lorsque des défaillances se produisent. Cette solution peut répondre aux besoins des clients, mais ne doit pas être autorisée, car elle modifie considérablement les demandes sur votre charge de travail et risque d'entraîner des défaillances.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : Moyenne entreprise

Directives d'implémentation

  • Utilisez la stabilité statique pour éviter les comportements bimodaux. Un comportement bimodal survient lorsque votre charge de travail adopte un comportement différent en mode normal et en mode de défaillance, par exemple, en s'appuyant sur le lancement de nouvelles instances en cas de défaillance d'une zone de disponibilité.

Ressources

Documents connexes :

Vidéos connexes :