Chaos Engineering : venez, on va s'empoisonner !

La Chaos Engineering introduit des perturbations sur ta production afin de tester la résilience et renforcer la confiance dans ton système.

Cette méthode est fantastique, vraiment. Mais il se passe quoi si les perturbations de la production sont déjà présentes ?

C'est ici qu'entre en jeu le RCE (Reversed Chaos Engineering). C'est tout nouveau, tout frais et je suis certain que cela pourra t'aider !

Transcript

1. AFUP DAY POITIERS MAI 2025 Chaos Engineering Venez, nous allons nous empoisonner! CTO PHP Nicolas Perussel nicolas.perussel@ekino.com @mamoot
2. BORDEAUX BEST JUIN 2025 Chaos Engineering Venez, nous allons nous empoisonner! CTO PHP Nicolas Perussel nicolas.perussel@ekino.com @mamoot
3. Plus de 20 années d’XP avec PHP Polyglotte : Ruby, Typescript, Python, C Nicolas PERUSSEL aka @mamoot 3 Mes domaines de prédilection : • Architecture technique • Facilitateur • Team & Tech Lead PHP CTO at
4. Laissez moi vous conter une histoire 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
5. Notre équipe a migré un réseau social professionnel de Neo4J/Java/Angular vers Drupal/PostgreSQL avec le profil de distribution OpenSocial. En local sur nos Mac M1, tout fonctionnait parfaitement. Les débuts Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 5
6. Après la migration des données, les performances se sont effondrées sur les environnements de recette et de production : - 6 à 30 secondes pour charger une page (avec le cache interne de Drupal) Début des problèmes 6 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
7. Pendant des mois, nous avons tout essayé : • Profiling avec Blackfire, • Analyse mémoire avec Kcachegrind, • Ajout de Varnish (cache public/privée), • Optimisation TCP vers Redis & PostgreSQL • Nettoyage de code, Big O • Déploiement sur des instances Graviton - … Rien n'y faisait. Les galères… Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 7
8. La révélation est venue lorsque nous avons réalisé que les appels vers Redis et PostgreSQL étaient vraiment en jeu. La latence cumulée était la seule responsable. Sur nos M1, la latence réseau était quasi inexistante, alors qu'en production, chaque requête subissait des délais importants. L’éveil 8 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
9. Des vues matérialisées PostgreSQL et le contournement des render arrays de Drupal. Performance finale : moins de 400ms (sans cache). On sacrifie le Drupal Way et nous prenons de « gros » raccourcis, mais clairement, le design de l’application en l’état n’est pas adapté. Notre solution Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 9
10. 10 Nous avons développé une nouvelle approche pour nous aider : Le Reversed Chaos Engineering (RCE) Car simuler les conditions de production en local est crucial pour éviter les surprises… Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
11. Le Chaos Engineering 11 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
12. Definition 12 CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Pour faire simple, l’ingénierie du chaos est une méthode de test de logiciel distribué. Elle consiste à introduire des perturbations ou des erreurs pour vérifier la résistance face aux imprévus. L’objectif du Chaos Engineering est renforcer la confiance dans la capacité du système à résister à des conditions de production turbulentes. Le Chaos Engineering est une démarche scientifique mesurant la faiblesse systèmique des apps. Cette démarche repose sur l’expérience. Ali Basiri 2010 2011 2012 2013 2014 Bruce Wong 2015 2016 …
13. Chaos en pratique 13 CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Définir un « état stable » comme une sortie mesurable d’un système qui indique un comportement normal. 1 Tenter de réfuter l’hypothèse en recherchant une différence d’état d’équilibre entre le groupe témoin et le groupe expérimental. 4 Faire l’hypothèse que cet état d’équilibre se poursuivra dans le groupe témoin et dans le groupe expérimental. 2 Introduire des variations qui reflètent des événements réels, tels que les serveurs en panne, les disques durs défectueux, les connexions réseau coupées, etc. 3
14. Chaos en pratique 14 CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Définir un « état stable » comme une sortie mesurable d’un système qui indique un comportement normal. 1 Tenter de réfuter l’hypothèse en recherchant une différence d’état d’équilibre entre le groupe témoin et le groupe expérimental. 4 Faire l’hypothèse que cet état d’équilibre se poursuivra dans le groupe témoin et dans le groupe expérimental. 2 Introduire des variations qui reflètent des événements réels, tels que les serveurs en panne, les disques durs défectueux, les connexions réseau coupées, etc. 3 Temps de chargement : moins de 1 seconde "Si la base de données devient lente, la page d'accueil continuera à se charger en moins de 2 secondes grâce au système de cache." Ajout de perturbation TCP (latence par exemple) vers la DB. Groupe A : connexion normale à la DB Groupe B : connexion avec latence simulée Le temps de chargement pour le groupe B est pssé à 3,5 secondes L'hypothèse est réfutée : le site n'est pas aussi résilient qu'on le pensait face à la latence de la base de données.
15. Chaos en pratique 15 CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Définir un « état stable » comme une sortie mesurable d’un système qui indique un comportement normal. 1 Tenter de réfuter l’hypothèse en recherchant une différence d’état d’équilibre entre le groupe témoin et le groupe expérimental. 4 Faire l’hypothèse que cet état d’équilibre se poursuivra dans le groupe témoin et dans le groupe expérimental. 2 Introduire des variations qui reflètent des événements réels, tels que les serveurs en panne, les disques durs défectueux, les connexions réseau coupées, etc. 3 Temps de chargement : moins de 1 seconde "Si la base de données devient lente, la page d'accueil continuera à se charger en moins de 2 secondes grâce au système de cache." Ajout de perturbation TCP (latence par exemple) vers la DB. Groupe A : connexion normale à la DB Groupe B : connexion avec latence simulée Le temps de chargement pour le groupe B est pssé à 3,5 secondes L'hypothèse est réfutée : le site n'est pas aussi résilient qu'on le pensait face à la latence de la base de données.
16. Chaos en pratique 16 CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Définir un « état stable » comme une sortie mesurable d’un système qui indique un comportement normal. 1 Tenter de réfuter l’hypothèse en recherchant une différence d’état d’équilibre entre le groupe témoin et le groupe expérimental. 4 Faire l’hypothèse que cet état d’équilibre se poursuivra dans le groupe témoin et dans le groupe expérimental. 2 Introduire des variations qui reflètent des événements réels, tels que les serveurs en panne, les disques durs défectueux, les connexions réseau coupées, etc. 3 Temps de chargement : moins de 1 seconde "Si la base de données devient lente, la page d'accueil continuera à se charger en moins de 2 secondes grâce au système de cache." Ajout de perturbation TCP (latence par exemple) vers la DB. Groupe A : connexion normale à la DB Groupe B : connexion avec latence simulée Le temps de chargement pour le groupe B est pssé à 3,5 secondes L'hypothèse est réfutée : le site n'est pas aussi résilient qu'on le pensait face à la latence de la base de données.
17. Chaos en pratique 17 CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Définir un « état stable » comme une sortie mesurable d’un système qui indique un comportement normal. 1 Tenter de réfuter l’hypothèse en recherchant une différence d’état d’équilibre entre le groupe témoin et le groupe expérimental. 4 Faire l’hypothèse que cet état d’équilibre se poursuivra dans le groupe témoin et dans le groupe expérimental. 2 Introduire des variations qui reflètent des événements réels, tels que les serveurs en panne, les disques durs défectueux, les connexions réseau coupées, etc. 3 Temps de chargement : moins de 1 seconde "Si la base de données devient lente, la page d'accueil continuera à se charger en moins de 2 secondes grâce au système de cache." Ajout de perturbation TCP (latence par exemple) vers la DB. Groupe A : connexion normale à la DB Groupe B : connexion avec latence simulée Le temps de chargement pour le groupe B est passé à 3,5 secondes L'hypothèse est réfutée : le site n'est pas aussi résilient qu'on le pensait face à la latence de la base de données.
18. 18 Encountering failure doesn't mean we failed; it is how we learn! Build. Fail. Learn. Repeat. Jason Yee - Staff Technical Evangelist at Datadog Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
19. Le Chaos Engineering inversé Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 19
20. 20 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
21. Chaos en pratique 21 REVERSED CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Définir un « état stable » comme une sortie mesurable d’un système qui indique un comportement normal. 1 Tenter de réfuter l’hypothèse en recherchant une différence d’état d’équilibre entre le groupe témoin et le groupe expérimental. 4 Faire l’hypothèse que cet état d’équilibre se poursuivra dans le groupe témoin et dans le groupe expérimental. 2 Introduire des variations qui reflètent des événements réels, tels que les serveurs en panne, les disques durs défectueux, les connexions réseau coupées, etc. 3
22. Definition du RCE 22 REVERSED CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Le Reversed Chaos Engineering (RCE) est une méthodologie systématique qui part de l'observation d'instabilités existantes en production pour remonter aux causes fondamentales, les comprendre, et les résoudre durablement. Contrairement au Chaos Engineering traditionnel qui introduit des perturbations dans un système stable, le RCE analyse des perturbations déjà présentes pour renforcer la fiabilité du système. Comprendre leurs causes fondamentales Développer une connaissance approfondie des comportements du système Mettre en œuvre des corrections ciblées et efficaces Enrichir la pratique globale du Chaos Engineering
23. Pourquoi avoir modélisé le RCE ? REVERSED CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 REVERSED CHAOS ENGINEERING Instabilité observée en production Comprendre et résoudre les causes fondamentales Analyse systématique + reproduction contrôlée Méthodologie complète couvrant tout le cycle d'observation, hypothèse, validation et résolution 23 FAULT REPRODUCTION Adrian Colyer dans son billet de blog « The Morning Paper » Bug ou défaut signalé Recréer précisément le problème Reproduction déterministe PERFORMANCE ENGINEERING Brendan Gregg dans son livre "Systems Performance: Enterprise and the Cloud » Préoccupation de performance Optimiser les performances du système Analyse empirique DIGITAL TWINS Concept, popularisé dans l'industrie IoT et manufacturière Système existant Tester des scénarios sans risque Simulation complète PRODUCTION PARITY Martin Fowler et d'autres auteurs de ThoughtWorks Écart dev/prod Réduire les différences entre environnements Alignement environnemental
24. Reversed Chaos en pratique Workflow 24 REVERSED CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Caractérisation de l'instabilité Établir une compréhension précise et mesurable de l'anomalie du système en production. 1 Reproduction et résolution Recréer l'instabilité dans un environnement contrôlé et développer une solution durable. 4 Formulation d'hypothèses causales Développer un ensemble d'explications plausibles et testables des causes de l'instabilité. 2 Validation par instrumentation Recueillir des données empiriques pour confirmer ou infirmer les hypothèses formulées. 3
25. Vue d’ensemble du RCE 25 REVERSED CHAOS ENGINEERING Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 CHAOS ENGINEERING REVERSED CHAOS ENGINEERING PERFORMANCE ENGINEERING PRODUCTION PARITY DIGITAL TWINS FAULT REPRODUCTION EXISTING METHODS TECHNIQUE PHASE 4 METRIQUE PHASE 1 FONDATION PHASE 3 ENVIRONNMENT PHASE 4 SYSTEMATIC APPROACH
26. 26 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Exemple pratique
27. RCE Phase 1 - Caractérisation RCE – PHASE 1 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Contexte applicatif • Application : Drupal 10 avec PHP 8 • Infrastructure : • Connexions TCP à la base de données • Connexions TCP à Redis (système de cache) • Problème observé : Temps de chargement de page > 20 secondes ELASTICACHE - REDIS RDS - POSTGRESQL MANAGED SERVICES SECRET MANAGER FRONTEND CLI SEARCH-PROXY INGRESS Node 1 PARAMETER STORE EXTERNAL SERVICES ELASTIC SEARCH KAFKA helm repo flux CD Controller Charts Releases
28. RCE Phase 1 - Caractérisation 28 RCE – PHASE 1 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 TLS Latence moyenne : 0,0685 microsecondes (68,50 nanosecondes) Latence maximale : 64956 microsecondes (~65 millisecondes) Nombre total d'exécutions : 2 919 698 346 Ratio pire cas/moyenne : 948 260 fois plus lent que la moyenne Interprétation • Latence moyenne excellente • Pics de latence significatifs : Bien que la moyenne soit excellente, on observe un saut important de la latence maximale (de 274 μs à plus de 64 ms). • Pire cas problématique : Une latence maximale de ~65 ms pourrait être préoccupante pour des applications nécessitant des temps de réponse constants et prévisibles Causes possibles des pics de latence • Activité du garbage collector • Planification du système d'exploitation • Interruptions matérielles • Swapping mémoire • Autres processus consommant des ressources sur le même système
29. RCE Phase 1 - Caractérisation 29 RCE – PHASE 1 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 TCP Interprétation • Latence moyenne légèrement plus élevée : ~98 ns contre ~68 ns pour le premier test, le serveur de production sans TLS est environ 43% plus lent en moyenne. • Latence maximale nettement meilleure : ~11,1 ms contre ~65 ms, soit environ 6 fois moins élevée que dans le premier test. Cela indique une meilleure stabilité et moins d'interruptions système majeures. • Progression plus graduelle des pics : On observe une montée progressive des valeurs maximales (3137μs, 3320μs, 7124μs, 11128μs), contrairement au premier test qui montrait un saut brutal (de 274μs à 64951μs). • Ratio pire cas/moyenne plus faible : Environ 8 fois meilleur que le premier test avec TLS, ce qui indique une meilleure prévisibilité des performances. Latence moyenne : 0,0979 microsecondes (97,93 nanosecondes) Latence maximale : 11 128 microsecondes (~11,1 millisecondes) Nombre total d'exécutions : 2 042 249 535 Ratio pire cas/moyenne : 113 631 fois plus lent que la moyenne
30. • Problème fondamental : Effet cumulatif des latences TCP individuelles • Volume estimé d'appels par page : • Nombre élevé de requêtes base de données (> 250) • Nombre élevé d'appels Redis (> 1000) • Impact des pics de latence sur le temps total : • Même avec une latence moyenne basse, un seul pic de 65ms ou 11ms peut significativement retarder le rendu de page • Le temps cumulé monte rapidement avec des centaines d'appels Analyse du cumul de latence TCP RCE Phase 1 - Caractérisation Latence TCP et cumul 30 • Effet cascade : Chaque requête bloquante retarde toutes les suivantes • Blocage séquentiel : PHP exécute généralement les opérations de manière séquentielle, amplifiant l'impact de chaque latence • Multiplication des connexions : Chaque opération TCP ajoute un overhead supplémentaire Analyse de l'amplification de la latence • Temps total de chargement : > 20 s • Points d'étranglement potentiels : • Temps d'exécution PHP pour générer la page • Temps d'attente cumulé pour les requêtes DB • Temps d'attente cumulé pour les opérations Redis • Overhead de sérialisation/désérialisation PHP Comportement de Drupal/PHP observé Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
31. RCE Phase 1 – Caractérisation Rapport de caractérisation 31 RCE – PHASE 1 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 1. Le problème principal semble être le volume cumulatif des appels TCP qui multiplie l'impact de chaque latence individuelle. 2. Même avec des latences moyennes Redis excellentes (68ns-98ns), les pics occasionnels (11ms-65ms) ont un impact disproportionné sur le temps total lorsqu'ils sont multipliés par de nombreux appels. 3. Le modèle d'exécution synchrone/bloquant de PHP aggrave probablement le problème en rendant le temps de chargement égal à la somme de toutes les latences individuelles. 4. TLS semble poser problème car il ajoute overhead conséquent ajoutant de la latence.
32. RCE Phase 2 - Hypothèses 32 RCE – PHASE 2 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Hypothèses relatives à la latence TCP cumulée dans Drupal Description Justification Probabilité Impact Priorité H1: Volume excessif de requêtes Redis et BDD par page L'application Drupal exécute un nombre excessif d'appels TCP individuels (Redis et BDD) pour générer une seule page. Les temps de chargement > 20s suggèrent un effet cumulatif de centaines d'opérations TCP individuelles. Très élevée (90%) Critique 1 H2: Modèle d'exécution séquentiel et bloquant PHP exécute les requêtes Redis et BDD de manière séquentielle et bloquante, additionnant chaque latence individuelle. Le modèle d'exécution par défaut de PHP est synchrone, et une architecture non-optimisée attendrait chaque résultat avant de continuer. Très élevée (90%) Critique 1 H3: Absence de mise en cache des requêtes répétitives L'application Drupal exécute un nombre excessif d'appels TCP individuels (Redis et BDD) pour générer une seule page. Les temps de chargement > 20s suggèrent un effet cumulatif de centaines d'opérations TCP individuelles. Élevée (80%) Élevé 2 H4: Connexions TCP non persistantes/poolées Les connexions TCP sont établies et fermées pour chaque requête individuelle, ajoutant l'overhead d'établissement de connexion. Une mauvaise configuration du pooling de connexions peut entraîner un overhead d'établissement de connexion de 1-3ms par requête. Élevée (75%) Élevé 2
33. RCE Phase 2 - Hypothèses 33 RCE – PHASE 2 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Hypothèses relatives à la latence TCP cumulée dans Drupal Description Justification Probabilité Impact Priorité H6: Configuration TCP sous-optimale Les paramètres TCP du système (keepalive, taille de fenêtre, etc.) ne sont pas optimisés pour de nombreuses connexions courtes. Les paramètres TCP par défaut peuvent être inadaptés aux modèles d'accès intensifs de Drupal. Moyenne (60%) Moyen 3 H8: Contention réseau et saturation de connexions Le nombre élevé de connexions simultanées crée une contention au niveau du réseau ou des limites du système. Les limites de descripteurs de fichiers ou les files d'attente réseau peuvent être saturées lors de pics de charge. Moyenne (50%) Moyen 4
34. RCE Phase 2 - Hypothèses 34 RCE – PHASE 2 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Hypothèses spécifiques aux pics de latence Redis Description Justification Probabilité Impact Priorité HR1: Garbage collection PHP Les pics de latence Redis coïncident avec des opérations de GC du PHP-FPM qui héberge l'application Drupal. PHP effectue périodiquement des opérations de nettoyage mémoire qui peuvent bloquer le thread d'exécution. Élevée (75%) Élevé 2 HR2: Interruptions du système d'exploitation Les pics de latence extrêmes (65ms) sont causés par des interruptions du système d'exploitation. Le saut brutal de 274μs à 64951μs suggère un événement système majeur. Élevée (75%) Élevé 2
35. RCE Phase 3 – Validation Mise en place de Blackfire 35 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Profiling web et CLI Des choses intéressantes : • Beaucoup de connexions réseau • Le cycle de Garbage Collection est appelé 5 fois par requête • Aucun « hotspot » ne pop et signe que le problème est là • La performance liée à PHP semble très correcte Blackfire confirme que le souci est lié au réseau
36. RCE Phase 3 – Validation APM Datadog « Full Tracing » 36 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Quelques constats • Sur une page « simple », constat de la multiplicité des appels TCP vers Redis / PostgreSQL • Les « vues » utilisant des « paragraph » semblent être fortement impliquées • Rien de particulier dans les logs
37. RCE Phase 3 – Validation strace devient ton meilleur ami 37 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Temps d'exécution : 56,6 secondes Appels réseau totaux : 601 528 • Une latence réseau élevée • Des problèmes de connectivité réseau fréquents • Une possible saturation des ressources serveur
38. RCE Phase 3 - Validation 38 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Problèmes probables 1. Problème de connexion persistante :Un nombre excessif de nouvelles connexions plutôt que la réutilisation de connexions existantes 2. Problèmes de cache : • Taux d'échec du cache élevé (cache miss) • Trop de clés différentes, fragmentant le cache 1. Problèmes de base de données : • Requêtes non optimisées nécessitant beaucoup de temps • Verrouillage de table ou contention sur certaines ressources • Index manquants pour certaines requêtes 4. Problèmes réseau : • Latence réseau élevée vers certains services • Possible congestion réseau pendant les pics d'activité
39. RCE Phase 3 - Validation 39 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Nous sommes passés sur TCP Fast Open pour grapiller des ms… Nous avons voulu vérifier la congestion réseau et avons changé CUBIC par BBR (Bottleneck Bandwidth and Round-trip propagation time) Interventions sur la couche Transport du réseau
40. RCE Phase 3 – Validation Dump memory & time et analyse avec QCacheGrind 40 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
41. RCE Phase 3 – Validation Vérification des settings Drupal pour Redis 41 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Cette config était manquante par exemple
42. RCE Phase 3 - Validation 42 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Nous avons également : • Étudier les trames TCP avec tcpdump et Wireshark/tshark • Caler des sondes (probes) avec SystemTap (https://www.php.net/manual/fr/features.dtrace.systemtap.php) • Revue toutes les configurations de PostgreSQL et Redis • Analyser tous les logs via DataDog • Bruler la planète avec un End To End Tracing de folie • Lancer des stress tests avec K6 (Sparta) • Triturer le php.ini, deep dive PHP-FPM • …
43. RCE Phase 3 - Validation 43 RCE – PHASE 3 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Il est important de TOUT consigner afin d’avoir les métriques accessibles lors des tests de reproduction (phase 4) Il faut supprimer le hasard et tenter d’être le plus exhaustif possible.
44. RCE Phase 4 - Reproduction 44 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Reproduction des observations en local (pour mémoire, aucun souci de latence sur les Mac M1/M2)
45. Toxiproxy 45 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Toxiproxy est un framework de simulation des conditions réseau. Conçu spécifiquement pour les environnements de test, d'intégration continue et de développement, il prend en charge la falsification déterministe des connexions, mais aussi le chaos aléatoire et la personnalisation. Toxiproxy est l'outil idéal pour prouver, par des tests, que l’application ne présente aucun point de défaillance unique. (SPOF) LATENCY DOWN BANDWIDTH SLOW_CLOSE TIMEOUT RESET LIMIT_DATA SLICER Toxiproxy repose sur la notion de TOXICS, tous agissant sur la couche TCP. https://github.com/Shopify/toxiproxy
46. Empoisonner la connexion à Redis 46 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
47. Empoisonner la connexion à Redis 47 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
48. Empoisonner la connexion à Redis 48 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
49. Analyse et conclusion 49 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 SANS TOXIC LATENCY TOXIC 35ms LATENCY TOXIC 65ms X 2,8 X 3,2 « Même nombre d’appels TCP mais la latence augmente (obvious mais significatif) »
50. Analyse et conclusion 50 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 drush cr sans latence => 7 à 9s drush cr avec latence => 150 à 200s curlt -k https://slow-app.localdev/fr/test-page (sans cache, sans latence) => 7,3s curlt -k https://slow-app.localdev/fr/test-page (sans cache, avec latence) => 60s ON MATCH LA PRODUCTION !
51. Analyse et conclusion 51 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 ON MATCH LA PRODUCTION, MAIS C’EST ENCORE PLUS L’ANGOISSE drush cr sans latence => 7 à 9s drush cr avec latence => 150 à 200s curlt -k https://slow-app.localdev/fr/test-page (sans cache, sans latence) => 7,3s curlt -k https://slow-app.localdev/fr/test-page (sans cache, avec latence) => 60s
52. Analyse et conclusion 52 RCE – PHASE 4 Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 Description Justification Probabilité Impact Priorité H1: Volume excessif de requêtes Redis et BDD par page L'application Drupal exécute un nombre excessif d'appels TCP individuels (Redis et BDD) pour générer une seule page. Les temps de chargement > 20s suggèrent un effet cumulatif de centaines d'opérations TCP individuelles. Très élevée (90%) Critique 1 • Nous utilisons Drupal et son modèle de données • Les différents Cache-Bins sont correctement configurés • Créer un « Custom Kernel » n’est pas envisageable • Impossible de rapatrier le cluster Redis au sein du cluster K8S • Le Drupal Way est respecté • Nous avons beaucoup de layer de cache rendant l’invalidation complexe • Impossible de réécrire l’application dans son intégralité Nous validons l’hypothèse 1 Mais comment agir sur la latence et/ou le nombre d’appels TCP ?
53. Notre solution Inlining de données dans des Materialized View 53 SOLUTION Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
54. Notre solution Inlining de données dans des Materialized View 54 SOLUTION Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
55. Notre solution Bypass du Drupal Way 55 SOLUTION Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
56. En synthèse 56 CONCLUSION Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 La méthodologie systématique du RCE transforme la résolution des problèmes d'une forme d'art basée sur l'intuition et l'expérience individuelle en un processus scientifique, structuré et reproductible. Elle permet non seulement de résoudre plus efficacement les instabilités actuelles, mais aussi de construire une base de connaissances organisationnelle qui renforce progressivement la résilience globale du système. Cette rigueur méthodologique est ce qui distingue fondamentalement le RCE d'autres approches plus informelles de troubleshooting, et explique pourquoi cette approche peut s'intégrer si naturellement avec des pratiques établies comme le Chaos Engineering traditionnel. https://github.com/reversed-chaos-engineering/foundation
57. • Chaos Engineering - https://arxiv.org/pdf/1702.05843 • Chaos Monkey - https://netflix.github.io/chaosmonkey/ • Simian Army - https://github.com/Netflix/SimianArmy • Chaos Engineering, principes et mise en application (B. Gakic) https://www.youtube.com/watch?v=WTT2GJquAWY • What is Chaos Engineering (J. Yee) https://www.youtube.com/watch?v=CXhd30tDqBc • Brendan Gregg - https://www.brendangregg.com/blog/2020-07-15/systems-performance-2nd-edition.html • Blog d’Adrian Colyer - https://web.archive.org/web/20250102080315/https://blog.acolyer.org/ • Github Awesome Chaos - https://github.com/adriannovegil/awesome-chaos-engineering • Principles of Chaos - https://principlesofchaos.org/ • La goutte d’eau qui fait déborder le Cloud - Julien JOYE - https://www.youtube.com/watch?v=OCClZfNUMI8 • Soyons fou ! Et si Drupal faisait moins de chose au runtime ? - https://www.youtube.com/watch?v=wRziVwPxVjE Références 57 CONCLUSION Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025
58. Thank you. Merci. 謝謝. dhanya Nicolas Perussel • Chaos Engineering | AFUP DAY POITIERS 2025 58