L’auteur raconte comment son équipe a migré plus d’un milliard d’enregistrements d’une base de données critique (contenant des données financières) vers une nouvelle, sans aucune interruption de service. Voici les étapes clés et les leçons apprises :
-
Migration par lots des données historiques : Les données ont été divisées en chunks par plages d’ID, chargées en parallèle avec les index et contraintes désactivés pour accélérer le processus, puis vérifiées par des checksums pour garantir l’intégrité.
-
Écritures doubles (dual writes) : Pendant la migration, chaque nouvelle écriture était dupliquée vers l’ancienne et la nouvelle base. Les échecs étaient gérés via une file Kafka de réessai, avec des écritures idempotentes pour éviter les doublons.
-
Lectures fantômes (shadow reads) : Les requêtes étaient exécutées en silence sur la nouvelle base et comparées à l’ancienne pour détecter des incohérences (fuseaux horaires, collations, valeurs NULL), permettant de corriger les problèmes avant de basculer les utilisateurs.
-
Bascule progressive (cutover) : La nouvelle base a été préchauffée (cache et index), et le basculement a eu lieu à 4h30, heure de faible trafic, avec un mécanisme de retour arrière (rollback) prêt. Les métriques business et techniques ont été surveillées en temps réel.
-
Observabilité totale : Des tableaux de bord ont suivi la latence, le lag de réplication, les deadlocks, et les KPI métiers pour détecter instantanément tout problème.
Leçons clés :
- Les migrations à grande échelle se font par lots parallèles, avec des mécanismes de reprise et de vérification.
- Les dual writes et les shadow reads sont essentiels pour capturer les données en temps réel et valider la nouvelle base.
- La bascule doit être préparée comme une opération critique : cache préchauffé, monitoring obsessionnel, et plan de rollback.
- Une migration réussie repose sur la conception distribuée (idempotence, files de réessai) et une observabilité fine (WAL, cache, deadlocks).
En traitant la migration comme un problème de system design plutôt que technique, l’équipe a pu garantir une transition sans temps d’arrêt, malgré la pression et les risques financiers.
L’observabilité full-stack passe aussi par le frontend – Longtemps considéré comme une boîte noire, le suivi des performances côté client (latence des interactions, complexité asynchrone, contexte utilisateur) est désormais possible grâce au tracing (OpenTelemetry, Sentry, Datadog). En instrumentant les clics, requêtes et rendus, on relie les actions utilisateurs aux traces backend, offrant une visibilité complète : identification précise des goulots d’étranglement, corrélation entre latence perçue et temps système, et débogage simplifié. Avec une implémentation simple (ex : @opentelemetry/sdk-trace-web), le frontend s’intègre enfin dans la chaîne d’observabilité, transformant l’expérience utilisateur en données exploitables.
L'article explique l'intérêt de mettre en place l'observabilité, et il montre comment le faire pour une application Symfony en utilisant Sentry.
SigNoz est une plateforme d'observabilité open-source qui unifie la gestion des logs, des métriques et des traces pour surveiller les applications, détecter les problèmes et résoudre rapidement les temps d'arrêt. Elle offre des fonctionnalités telles que la surveillance des performances des applications, la gestion centralisée des logs, le traçage distribué, des métriques personnalisables et des alertes. Basée sur OpenTelemetry, elle évite le verrouillage propriétaire et utilise ClickHouse pour un stockage optimisé. SigNoz propose une solution tout-en-un pour l'observabilité, avec des options de déploiement cloud ou auto-hébergé, et une communauté active pour le support et les contributions.
Tout est dans le titre
Les résumés des conférences de BDX I/O :
- Keynote d'ouverture : LLMs, entre fantasme et réalité - le point de vue d'une dév passée de l'autre côté
- Découvrons ensemble la relève de l'observabilité avec les logs et traces : Quickwit
- HTMX, où le retour de l'AJAX dans le développement Web
- IA-404 : Explication not found
- Rex scale-up : les impacts du passage à l'échelle
- Really Inaccessible - Stanley Servical & Louis Fredice Njako Molom
- Causalité et statistiques : un amour pas si impossible que ça
- Shaders : Comment créer des effets hallucinants sur son site web
- L'envers du décor d'un passage douloureux à Vue 3
- Secrets faciles dans Kubernetes : parce que je le Vault bien
- Les histoires d’A. finissent pas si mal : Offboarding ou la fin de la relation entre un client et une marque
- L'IA Éco-Responsable : Utopie Marketing ou Réalité ?
- Le coût du Mob Programming
- Simplifiez la conteneurisation de vos idées !
Tout est dans le titre
Il s'agit d'un outil développé par l'auteur pour configurer des healtcheck à partir d'un autre outil de l'auteur : Cabourotte. Très intéressant
Tout est dans le titre
Tout est dans le titre
Je cite l'auteur :
Voilà donc une série d’articles détaillants comment mettre en place l’observabilité sur une application Spring Boot 3.
Dans cet article, il parle de la stack de télémétrie qu'il a choisi : Grafana, Prometheus, Loki, et Tempo. Il explique la mise en oeuvre de l'observabilité dans une application Sping Boot.