L'architecture est vivante

Transcript

1. Votre architecture est Vivante et viable Comment notre stack a évolué de manière con4nue Redis · NATS · etcd · MySQL · ClickHouse · Kubernetes Axe 1 — Messaging & coordinaBon Redis → Redis + NATS + etcd ✓ Terminé Axe 2 — Base de données MySQL → MySQL + ClickHouse ↗ En progression Axe 3 — Infrastructure DO managed → Kubernetes ↗ En progression Julien Maitrehenry — 2025
2. Julien Maitrehenry Dev, Ops, Architect, SRE, ... U4lise des technos avant d'être stable en prod Chief Architect & ac-ng CTO @ Paren Docker Captain Julien Maitrehenry — 2025 linkedin.com/in/jmaitrehenry jmaitrehenry.ca github.com/jmaitrehenry
3. Intro Quelques ques(ons pour commencer… Avez-vous déjà cherché à créer l’architecture parfaite… pour rien ? Depuis combien de temps votre architecture n’a pas bougé ? Avez-vous déjà eu peur de me?re à jour votre infra, de peur de tout casser ? Julien Maitrehenry — 2025
4. Intro Nos produits d’aujourd’hui sont différent d’hier CSV Fichiers généré et envoyé par email à toutes les semaines SaaS limité Plateforme web, consulta;on basique API et webhooks Intégra;on clients, système temps réel Dashboards Analy;cs et dashboard dynamique À chaque étape, l’architecture doit évoluer pour répondre à nos besoins / notre contexte Julien Maitrehenry — 2025
5. Intro Paren en chiffres 27M Data points fetchés par jour 79k+ Chargeurs — 3,77M sessions/semaine ↑ ×5 en 2 ans 4 personnes dans l’équipe tech C’est pour ça que l’architecture doit travailler plus fort que nous. Julien Maitrehenry — 2025 18k Unité de travail (thread)
6. Intro Comment savoir qu’une brique déborde ? On a peur de la redémarrer Quand parler de me,re à jour, redémarrer, modifier créé de la peur. S’il y a un problème cela peut causer un down>me complet. C’est un signe qu’elle porte trop de responsabilités et qu’on a un problème Elle fait trop de choses Quand elle a plus qu’une responsabilité ou rôle. Le managed a7eint ses limites Parfait pour démarrer, mais fonc>onnalités limitées, moins extensible. Quand le service vous freine, il est temps d’évoluer. Julien Maitrehenry — 2025
7. Intro Trois couches, trois évolu(ons Chaque couche a évolué indépendamment, mo<vée par un besoin réel. 01 Messaging & coordina?on Terminé Redis → Redis + NATS + etcd Un seul ouRl portait 3 rôles incompaRbles : cache, messaging, coordinaRon. 02 Base de données En cours MySQL → MySQL + ClickHouse OLTP et OLAP ont des contraintes opposées. MySQL ne peut pas exceller aux deux. 03 Infrastructure En cours DO VMs + App PlaKorm → Kubernetes (hybrid) Limites des managed apps, observabilité et alerRng, GitOps, self-healing et HA, coûts. Julien Maitrehenry — 2025
8. Redis Messaging & coordina.on Redis faisait tout. On a maintenant trois solu4ons séparés.
9. Redis Redis portait trois rôles — dans le même process Queue / stream Traitement asynchrone : jobs, retry, fanout entre services. Pas d'at-least-once na.f, pas de rejeu, pas d'observabilité. C Cache — sans expira?on Données calculées, résultats de requêtes. Sans TTL : comportement voulu, la donnée doit persister. RAM croît indéfiniment avec le volume de données. S State management État partagé entre services : locks distribués, coordinaRon, config live. Pas de consensus fort, double exécu.on possible. Un seul process Redis : quand la RAM sature ou qu'il est surchargé, tous les services sont impactés simultanément.
10. Redis Le vrai problème : la RAM croît, et tout le monde partage Cache sans expira?on = RAM qui croît Le cache sans TTL est un choix délibéré : la donnée doit persister tant qu'elle est valide. Mais le volume de données croît avec la base et dans Redis, le dataset complet est en RAM. Un seul process — effet cascade → RAM saturée → latences sur le cache → Latences cache → queues ralenRssent → Queues bloquées → state management impacté 💥 Tous les services dégradés en même temps La soluBon : Isoler chaque rôle dans son propre process, et en uRlisant la bonne technologie pour le besoin. Redis garde le cache, NATS prend les queues et uRlise des streams, etcd prend la coordinaRon. Julien Maitrehenry — 2025
11. Redis Un rôle par brique — terminé AVANT R Redis Queue · Cache · State APRÈS RRedis Cache uniquement NATS Messaging (JetStream, consumers durables) etcd CoordinaRon (leases, CAS, watches) Etcd : pourquoi pas Redis ? Consensus fort (Rac), leases avec TTL, watches temps réel, CAS atomique. Redis n'a pas ces garanRes, un thread pouvait tourner en double. Julien Maitrehenry — 2025
12. Redis Cas concret : manager/worker — v2 vs v3 v2 — Redis ✗ Workers dumpent leur état dans Redis régulièrement ✗ Manager poll périodiquement tout l'état ✗ DétecRon de panne : agendre le Rmeout heartbeat ✗ Assignment best-effort — double exécuRon possible v3 — etcd ✓ État structuré : /workers/*/alive (lease TTL) /threads/*/{spec,state,phase}, /assignments/* ✓ Manager : watch temps réel, zéro polling ✓ DétecRon de panne : expiraRon de lease, immédiate ✓ CAS + epoch → exclusivité garanRe par construcRon Julien Maitrehenry — 2025
13. MySQL Base de données MySQL faisait tout. OLTP et OLAP ont des contraintes opposées.
14. MySQL Le problème MySQL : pré-agréger pour performer MY MySQL: source de vérité Fonc>onne parfaitement pour les transac>ons. Mais les dashboards sur des millions de lignes forcent à pré-agréger les données à l'avance. Pré-agréga/on = rigidité. Impossible de recalculer autrement après coup. copie CH ClickHouse: analy-cs N'importe quel type de rapport, sur un grand volume de données, sans pré-agréga>on ni impact sur la prod. Engine column based: performant na/vement sur l'analy/que. Ce qu'on copie aujourd'hui : 2 tables MySQL recopiées dans ClickHouse, avec toutes leurs métadonnées agachées à chaque row (JOIN). Le stockage n'est pas un problème (format colonne). Le vrai défi : les mises à jour et la synchronisaRon. Julien Maitrehenry — 2025
15. MySQL Le défi : les updates et les engines colonne ne font pas bon ménage Le problème actuel Les métadonnées changent dans MySQL. Il faut synchroniser ces changements dans ClickHouse. Or les engines colonne sont opRmisés pour l'append, les updates coûtent cher (réécriture de colonnes enRères). F Tables de faits Append only Les 2 tables actuelles deviennent des tables de faits. Chaque événement est immutable, on n'écrit qu'en ajout. ✓ CompaRble avec les engines colonne. ✓ Performance opRmale. Et si la donnée change ? (et elle change) D Tables de dimensions Updates autorisés Les métadonnées (statuts, labels, configs) vivent dans des tables de dimensions. Elles changent, et c'est agendu. ✓ Les dimensions restent peRtes. ✓ L'impact des updates est limité. Réduit la performance à cause des JOINs dans les requêtes Julien Maitrehenry — 2025
16. K8S Infrastructure On se baCait contre la plateforme au lieu de construire le produit. C’était le signal.
17. Kubernetes Le managed nous a permis de démarrer vite Ce que ça nous a donné Pas de serveurs à gérer. Déploiement en un clic. On pouvait se concentrer sur le produit plutôt que sur l’infra. Coût de maintenance faible à pe<te échelle. Ce qu’on a heurté en grandissant Observabilité aveugle — les logs sont derrière un firewall. Réseau sans VPC — impossible à réconcilier avec la SOC2. Lock-in fournisseur — impossible de migrer sans tout recommencer. Le managed reste le bon choix pour démarrer. Ce n’était plus le bon choix pour nous, aujourd’hui. Julien Maitrehenry — 2025
18. Kubernetes Ce qu’on a (enfin) pu faire avec Kubernetes Monitoring, logging et aler-ng normalisés Prometheus + Grafana + OpenSearch. Une seule stack pour tout le monde, automaRque quel que soit le service. Self-healing & haute disponibilité Un service crashe à 3h du mat ? Le cluster le relance. Moi, je dors. Envoy Gateway SSL auto, Google Auth par route, protecRon d’apps internes et sans toucher au code de l’applicaRon. Meilleur contrôle des coûts Fini les VMs sur-provisionnées éparpillées. Bin-packing, vue centralisée, autoscaling à terme. Bonus Opérateurs ClickHouse et Pormetheus déployés naRvement dans le cluster. GitOps via ArgoCD Plus de dric. L’état désiré est dans Git. Julien Maitrehenry — 2025
19. Kubernetes Où en est-on ? Migra(on hybride en cours DigitalOcean VMs / Managed App principale encore ici Applica>on principale (scraper) Base MySQL (source de vérité) en cours Cluster Kubernetes NATS (JetStream) etcd ClickHouse Customer APIs Apps internes ArgoCD Migra.on hybride et lente: on ne fait pas de big bang. On migre une brique à la fois. Julien Maitrehenry — 2025 Redis et Opensearch Consumers apps POC / Demos Monitoring Workflows (n8n) Nouvelles apps et ou.ls déployés ici
20. Les systèmes grossissent. Les responsabilités doivent se séparer. L'architecture est vivante. Et elle ne sera jamais "terminée". Julien Maitrehenry — 2025 Lien de la présenta.on