- Après avoir exploité une architecture composée de centaines de microservices, Twilio Segment a basculé vers un service unique (monolithique) en raison de la complexité et de la charge de maintenance
- Au départ, l’entreprise avait séparé chaque API de destination afin d’assurer l’isolation des pannes et la scalabilité, mais le nombre de services a dépassé 140, ce qui a fait exploser l’overhead opérationnel
- La gestion de multiples repositories et bibliothèques partagées est devenue difficile, et les phases de test et de déploiement finissaient par affecter l’ensemble des services
- Pour résoudre ces problèmes, l’entreprise a introduit le système Centrifuge et une structure en monorepo, tout en créant Traffic Recorder pour automatiser les tests
- Résultat : la vitesse de développement et la stabilité se sont nettement améliorées, et Twilio Segment conserve aujourd’hui une architecture monolithique pour maximiser la productivité et l’efficacité opérationnelle
Adoption des microservices et limites
- Twilio Segment a adopté une architecture microservices pour son infrastructure de données client, en concevant des services indépendants capables de traiter les événements selon leur finalité
- Les données étaient envoyées vers des centaines de destinations côté serveur (par ex. Google Analytics, Optimizely, etc.)
- Au début, un unique queue était utilisé, mais une panne sur une destination spécifique provoquait des ralentissements globaux via un problème de head-of-line blocking
- Pour corriger cela, l’entreprise a mis en place un service et une queue distincts pour chaque destination, obtenant ainsi une meilleure isolation des pannes et une scalabilité indépendante
- Mais à mesure que le nombre de services augmentait, la complexité opérationnelle et le coût de maintenance ont fortement progressé, entraînant un ralentissement du développement et une hausse du taux de défauts
Les problèmes des repositories séparés et des bibliothèques partagées
- Chaque destination utilisait un format d’API différent, ce qui nécessitait du code de transformation personnalisé
- Initialement, tout était géré dans un repository unique, mais comme un échec de test affectait l’ensemble, l’équipe a choisi de séparer les repositories
- Avec l’ajout ultérieur de plus de 50 nouvelles destinations, cela a conduit à la création de plus de 50 repositories
- Des bibliothèques partagées ont été introduites pour les fonctions communes, mais les divergences de version et la charge liée aux déploiements se sont accrues
- Les profils de charge variant selon les services, il était difficile de régler l’autoscaling, ce qui obligeait parfois les opérateurs à intervenir manuellement
Passage au monolithique et adoption de Centrifuge
- L’entreprise a décidé de fusionner plus de 140 services en un seul
- Pour remplacer les queues individuelles, elle a développé le système Centrifuge, qui achemine tous les événements vers un service unique
- Centrifuge a ensuite évolué pour devenir l’infrastructure backend de Connections chez Twilio Segment
- Le passage à une architecture en service unique a permis de réduire la charge opérationnelle et de simplifier la gestion des incidents
Monorepo et automatisation des tests
- Tout le code des destinations a été fusionné dans un seul repository, et plus de 120 dépendances ont été unifiées sur une version unique
- La gestion des versions a été simplifiée et l’efficacité de maintenance améliorée
- Pour automatiser les tests, l’entreprise a introduit Traffic Recorder
- L’outil enregistre puis rejoue de vraies requêtes/réponses HTTP, supprimant la dépendance au réseau externe
- La durée des tests est passée de plusieurs minutes à quelques millisecondes, avec un net gain de stabilité
- Le taux d’échec des tests a diminué et la productivité des développeurs s’est fortement améliorée
Effets et compromis de l’architecture monolithique
- Après la fusion dans un service unique, la vitesse de déploiement et l’efficacité de développement se sont nettement améliorées
- En un an, le nombre d’améliorations apportées aux bibliothèques partagées est passé de 32 à 46
- Un seul ingénieur peut désormais déployer en quelques minutes
- L’efficacité opérationnelle s’est également améliorée : même en cas de forte hausse de charge, celle-ci peut être absorbée par un grand pool de workers
- Il reste toutefois des inconvénients, comme la difficulté d’isoler les défauts, la baisse de l’efficacité du cache et le risque lié aux mises à jour de dépendances
- Une partie de ces pertes est compensée par la simplicité opérationnelle et le gain de productivité
Conclusion
- Les microservices ont permis de résoudre les problèmes de performance initiaux, mais ils sont moins adaptés à la montée en charge à grande échelle et aux mises à jour groupées
- Le retour au monolithique a permis d’améliorer à la fois la stabilité opérationnelle et la vitesse de développement
- Pour réussir une telle transition, il est indispensable de disposer d’un système de test robuste et d’accepter les compromis associés
- Twilio Segment continue d’utiliser des microservices pour une partie de son infrastructure, mais considère que pour les destinations côté serveur, l’architecture monolithique est plus adaptée
Aucun commentaire pour le moment.