Cet article fait partie de notre guide: Micro-services : l'heure de la gouvernance a sonné

Le Chaos Monkey ou comment améliorer la résilience des micro-services

Les tests de résilience ne sont pas uniquement faits pour les infrastructures. Les architectes peuvent aussi l'adopter pour développer des micro-service plus fiables.

Chaos Monkey est un outil Open Source développé par Netflix dont la vocation est de revoir en profondeur la façon dont sont réalisés les tests de fiabilité. Cette démarche consiste à rendre inopérants des nœuds de façon aléatoire et à intervalles réguliers pour évaluer si le système peut survivre malgré ces défaillances. Le principe du Chaos Monkey peut ainsi contribuer à évaluer la fiabilité des applications basées sur les micro-services. Mais plutôt que d’agir intentionnellement les nœuds, il s’agit de se concentrer davantage sur l'interruption des services. 

En cas de défaillance d'un service, d'autres services alors dépendants du premier risquent, par effet boule de neige, tout simplement de ne pas aboutir. Cela crée une mauvaise expérience utilisateur. Il existe de nombreuses façons d'aborder ce problème. Si combinées, la résilience des systèmes se retrouve améliorée.

L'importance des services de secours

Les réplicas et les Fallbacks ne concernent pas seulement les composants d'infrastructure, mais aussi les services critiques. La création d'un service alternatif, capable de prendre en charge la workload en cas de défaillance du service par défaut, est alors à envisager. Ceci est particulièrement utile pour les services tels que la facturation et le traitement des transactions dans le eCommerce.

La mise en place d'un service de Fallback peut être aussi simple que de router le trafic hors du service défaillant. Avant d’amorcer la bascule, il est toutefois nécessaire de s’assurer que les services de sauvegarde des processus critiques sont prêts à prendre le relais.

Bâtir une infrastructure résilience

Avec les solutions de gestion de containers, il est désormais possible - et même facile - de redémarrer automatiquement les containers défectueux et de mettre automatiquement en place des groupes. Cette automatisation permet d'assurer la résilience de la couche infrastructure.

Au niveau du réseau, réduire les seuils des temps de réponse permettra un réacheminement plus rapide vers un service de secours après une panne. Cela permet de mieux optimiser le système et ses performances.

Il est également essentiel de mettre un place un mode de stockage persistant des données des containers. Lorsqu'un container tombe en panne, ses données stockées sont perdues à moins que ne soient configurés des volumes de stockage persistants. Cela garantit que, même en cas de défaillance d'un service, il peut être facilement repris à partir d’anciennes données.

Si malgré cela, les pertes de données sont encore possibles, un outil de reprise après sinistre (DR) permet d'avoir toujours accès aux données en cas de panne. Pour une vraie résilience des données, l’achat d’outils et services de DR vaut la peine.

 

Pour approfondir sur Architectures logicielles et SOA

Close