Pour ce dernier article sur les problématiques à étudier avant la mise en œuvre de microservices nous traiterons de la gestion des erreurs dans nos services.
Gestion des logs et monitoring
Comment gérer la collecte de log et le monitoring dans un système éclaté, distribué et auto scalable ?
Le besoin de logs et de monitoring est un enjeu majeur, dans cet environnement encore plus qu’ailleurs. Nous avons besoins d’outils permettant de :
- Récolter les logs applicatifs
- Récolter les logs systèmes et réseaux
- Les présenter de façon lisible et structurée
- Récolter les métriques de performances systèmes et réseaux
- Les présenter sous forme de graphique
- Surveiller les métriques en temps réel.
Gestion des pannes et résilience
Comment garantir à nos clients une SLA optimale compte tenu du caractère fortement distribué de notre SI ?
Il ne faut pas perdre de vue que résistant à la panne ne veut pas dire infaillible. Quand un service tombe, il faut un mécanisme pour identifier cette panne et relancer le service en question.
Cette résilience des architectures microservices passe donc par :
- Un mécanisme de surveillance.
- Un démarrage et une configuration des serveurs automatisés.
- Un déploiement des services automatisé.
Notre architecture mettant en œuvre un grand nombre de composants communiquant par HTTP le nombre d’erreurs est forcément plus important que dans un cadre d’exécution plus classique et une communication inter processus.
Les besoins de notre système sont :
-
- Détecter quand un service est off pour ne pas que le client tente de le joindre inutilement.
- Auto guérison des services : le cloud favorise la gestion de ce besoin par la mise en œuvre de :
- Scalabilité horizontale : duplication automatique des composants logiciels.
- Scalabilité verticale : augmentation de la puissance de la plateforme hôte (CPU / RAM / espace disque).
Au niveau logiciel, on peut également agir en mettant en œuvre un pattern appelé circuit breaker. Il permet de contrôler la collaboration entre différents services afin d’offrir une grande tolérance à la latence et à l’échec. Pour cela, en fonction d’un certain nombre de critères (timeout, nombre d’erreurs, élément dans la réponse), ce pattern permet de désactiver l’envoi de requêtes au service appelé et de renvoyer plus rapidement une réponse alternative de repli (fallback), aussi appelé graceful degradation.
La gestion des erreurs dans ce type de système est tellement importante que Netflix à prévu un composant chargé de débrancher des services aléatoirement pour s’assurer de la résilience de son système : c’est le célèbre Chaos Monkey.
« Le but de cet outil est de simuler des pannes en environnement réel et de vérifier que le système informatique continue à fonctionner. »
On s’assure ainsi d’avoir anticipé correctement la survenue de ce type d’incidents en mettant en place une architecture suffisamment redondante pour qu’une panne de serveurs n’affecte d’aucune façon les millions d’utilisateurs de Netflix.
C’est la fin de cette série d’articles sur les problématiques à étudier avant de se lancer dans l’implémentation de microservices ! Nous avons parlé de :
- Communication clients / services
- Communication entre services
- Gestion des données et des transactions
- Gestion des erreurs et tolérance aux pannes
Après cette introduction très théorique nous verrons comment nous pouvons répondre à toutes ces problématiques grâce aux différentes briques Azure 🙂
A très vite !