Vous testez la résilience de votre application. Mais testez-vous la résilience de votre base de données ? Voici comment appliquer le chaos engineering aux bases — sans tout casser.
Pourquoi le chaos engineering DB est différent
Le chaos engineering applicatif est relativement sûr : tuez une instance, l'orchestrateur en recrée une. Avec une base de données, c'est différent. Tuer une instance peut corrompre des données. Injecter de la latence peut causer des timeouts en cascade. Le chaos DB est plus risqué — mais aussi plus nécessaire.
Les 5 expériences à mener
Expérience 1 : Perte du primary. Tuez le serveur primary de votre AlwaysOn. L'application doit basculer sur le secondary automatiquement. Mesurez le temps de failover. Si c'est plus de 30 secondes, votre application timeout.
Expérience 2 : Latence réseau. Injectez 200ms de latence entre l'application et la base. L'application doit rester fonctionnelle. Si elle plante, vos timeouts sont mal configurés.
Expérience 3 : Perte de disque. Simulez la perte d'un disque de données. La base doit basculer sur le disque de secours ou le replica. Si elle corrompt, votre stratégie de réplication est défaillante.
Expérience 4 : Saturation CPU. Saturez le CPU du serveur de base. L'application doit dégrader gracieusement, pas planter. Si elle plante, vous n'avez pas de circuit breaker.
Expérience 5 : Corruption de données. Corrompez une table (en environnement de test). L'application doit détecter l'erreur et alerter. Si elle ignore l'erreur, votre gestion d'erreurs est insuffisante.
Comment mener ces expériences en sécurité
1. Environnement de test d'abord. Ne faites jamais de chaos DB en production sans avoir testé en environnement de test. Les conséquences d'une erreur sont trop graves.
2. Pendant les heures creuses. Si vous passez en production, faites-le pendant les heures de faible trafic. Dimanche à 4h du matin, par exemple.
3. Avec un plan de rollback. Préparez un snapshot avant l'expérience. Si quelque chose tourne mal, restaurez le snapshot.
4. Avec un observateur. Une personne surveille les métriques pendant l'expérience. Si quelque chose dérape, elle interrompt.
5. Documentez les résultats. Chaque expérience doit produire un rapport : qu'est-ce qu'on a testé, qu'est-ce qu'on a observé, qu'est-ce qu'on a appris, qu'est-ce qu'on va corriger.
Les outils
Gremlin — Outil commercial de chaos engineering. Supporte l'injection de latence, la perte de disque, la saturation CPU.
Chaos Mesh — Open-source, Kubernetes-native. Idéal si votre base tourne sur Kubernetes.
SQL Server Simulated Failure — Scripts personnalisés pour simuler des pannes SQL Server spécifiques.
Chaos Monkey pour bases — Adapté du chaos monkey de Netflix, spécifiquement pour les bases de données.
Le ROI du chaos DB
Le chaos engineering DB a un ROI difficile à mesurer mais réel. Chaque incident évité grâce à une expérience de chaos est un incident qui n'a pas impacté vos utilisateurs. Les entreprises qui pratiquent le chaos engineering ont 60% moins d'incidents critiques que celles qui ne le pratiquent pas.
Le chaos DB n'est pas un luxe. C'est une assurance. Et comme toute assurance, son coût est bien inférieur au coût de l'incident qu'elle évite.
Et vous ?
Vous voulez tester la résilience de votre base de données ? Aprilium conçoit et exécute vos expériences de chaos engineering DB — en sécurité, avec plan de rollback.
Tester ma résilience DB