100 crons par seconde, le Scheduler se venge

On est partis d’un cron solitaire, tournant discrètement dans l’ombre d’un serveur.

Aujourd’hui, on orchestre un Scheduler Symfony distribué, déployé sur Kubernetes, capable de piloter des centaines de tâches en parallèle avec fiabilité.

Ce talk raconte cette migration pleine d’enseignements — entre verrous, scalabilité horizontale, observabilité, et une bonne dose de magie Symfony.

Vous y découvrirez comment un simple cron s’est transformé en un système robuste, mais aussi les nombreux pièges rencontrés en chemin :

- des problèmes d’observabilité difficiles à diagnostiquer,
- des locks Symfony qui bloquent tout le scheduler,
- et quelques surprises liées au scaling horizontal.

Bref, une aventure concrète, pleine de sueur, de logs, de metric, et de solutions ingénieuses.

Transcript

1. 100 crons par seconde, le Scheduler se venge Jérémie AUGUSTIN - Click&Boat
2. 100 crons par seconde, le Scheduler se venge 2 Github: @jaugustin X : @pixeljer 2 Jérémie AUGUSTIN Software Architect Click&Boat
3. 3 3
4. 4 Voyage vers Symfony Scheduler • Lʼhistoire de nos tâches planifiés ◦ Naviguer avec l'ancien système • Migration vers le Symfony Scheduler ◦ La scalabilité ◦ Lʼobservabilité ◦ Lʼimpacte business 4
5. Les tâches planifiés 5 100 Taches planifiés 5
6. 6 Risque business 6
7. 7 Lʼhistoire de nos tâches planifiés 7
8. 8 Notre infra en 2020 8
9. 1 crontab dans un EC2 # /etc/crontab: * * * * * docker compose run php gate.php 9 9
10. Comment ça marche 10 10
11. Timeline 11 11 • Durée variable de 10 sec à 24h • Nombre variable de 0 à X tâches
12. Consommations de ressource 12 12
13. 13 Limitations • Lock des tâches 24h si crash • Log dans le container • Les devs n'ont pas accès • Déploiement à la main 13
14. 14 2021 Symfony 14
15. 15 Juillet 2021 15
16. 16 1 semaine pour changer lʼinfra 16
17. 17 Infra plus resiliante 17
18. 18 2023 Kubernetes 18
19. 19 Et nos crons ? 🙁 19
20. 20 k8s cronjob 😀 20
21. 21 k8s cronjob & compromis 21 • Tâches longues ? • Trop de tache en 24h ?
22. 22 k8s cronjob & compromis 22 • 3 tasks max • 1vCPu / 8Go • log opensearch • Réduit la fréquence
23. 23 Limitations ✅ Log dans le container ⇒ Opensearch ✅ Les devs n'ont pas accès ⇒plus besoin ✅ Déploiement à la main ⇒ helm 23
24. 24 k8s cronjob - succès 24
25. 25 Limitations ✅ Log dans le container ⇒ Opensearch ✅ Les devs n'ont pas accès ⇒plus besoin ✅ Déploiement à la main ⇒ helm ❌ Lock des tâches 24h si crash 25
26. 26 On a mis le legacy dans des conteneurs. C'est toujours du legacy. 26
27. 27 Symfony 🚀 27
28. 28 Migration vers Symfony Scheduler 28
29. 29 Expérimental ? 🤔 29 • Une première tâche en production #[AsSchedule('default')] class DefaultScheduleProvider implements ScheduleProviderInterface { public function getSchedule(): Schedule { return (new Schedule())->add( RecurringMessage::every('2 hours', new DISynchronizeMessage('n')) ); } }
30. 30 Symfony Scheduler 30 • Puis 2, 3, 4 … • Toujours aussi simple • 1 worker Pas de lock / Pas de cache
31. 31 Concurrence: théorie 31
32. 32 Concurrence: réalité 32
33. Pourquoi ? 33 33
34. 34 Le scheduler Monothread 34
35. 35 Solutions • On suit la doc cache+lock 35
36. 36 Pas mieux 36
37. 37 Lock par Scheduler = pas de parallélisation 37 • Scheduler_A ◦ RecuringMessageA ◦ RecuringMessageB ◦ RecuringMessageC ◦ RecuringMessageB
38. 38 1 scheduler + 1 message + 1 worker = 🔥💵💵💵 38 • Scheduler_A ◦ RecuringMessageA • Scheduler_B ◦ RecuringMessageB • Scheduler_C ◦ RecuringMessageC • Scheduler_D ◦ RecuringMessageD
39. On a lu la doc ça scale pas 39 39
40. 40 40
41. 41 Un lock maison par message 41 <?php #[AsEventListener (event: PreRunEvent::class)] public function onSchedulerPreRun (PreRunEvent $event): void { $messageId = $event->getMessageContext ()->id; // Lock par message empeche l'execution parallele $messageLock = $this->lockFactory->createLock("scheduler_msg_ {$messageId}", 300); if (!$messageLock->acquire()) { $event->shouldCancel(true); return; } // Lock par run - idempotence $triggerTime = $event->getMessageContext ()->triggeredAt->getTimestamp(); $runLock = $this->lockFactory->createLock("scheduler_run_ {$messageId}_{$triggerTime}", 86400); if (!$runLock->acquire()) { $messageLock->release(); $event->shouldCancel(true); } }
42. 42 Un lock par message 42 1 scheduler + X messages + Y workers = 💚 • Scheduler_A ◦ RecuringMessageA ◦ RecuringMessageB ◦ RecuringMessageC ◦ RecuringMessageB
43. 43 1 scheduler + X messages + Y workers = 💚 43
44. 44 Le Scheduler scale 44 Combien de worker on a besoin ? 🤔
45. Combien de worker on a besoin ? 🤔 45 45 • Des metrics • Un dashboard • Des alertes
46. Les metrics avec Prometheus ? 46 46 • Scheduler = daemon php • Pas de server HTTP • Pas de metrics
47. Scheduler & Observabilité 47 47
48. Scheduler & Observabilité 48 48 $registry = new CollectorRegistry (new Prometheus\Storage\Redis($redisConfig), false); $http = new HttpServer(static function (ServerRequestInterface $request) use ($registry) { return Response::plaintext( (new RenderTextFormat ())->render($registry->getMetricFamilySamples ()) ); }); $http->listen(new SocketServer("0.0.0.0:9100") );
49. Scheduler & Observabilité 49 49
50. Scheduler & Observabilité 50 50 • Metrics ◦ Execution / failure ◦ Durée ◦ Business • Alertes ◦ Si pas exécuté depuis 24h ◦ Spécifique
51. Lʼimpact Business 51 51
52. 52 Les tâches migrés • Des commandes Symfony simple • Du code testable • Observable Log / Metrics / Alerte) 52
53. 53 Migrer une tâche: • On priorise par le business Impact / Risk) • On évalue le besoin (sinon 🗑) • On évalue lʼarchitecture One shot, batch, queue) 53
54. 54 Touch it, migrate it 54 • Migration progressive • 50 tâches migrés • 10 tâches supprimés
55. Le scheduler cʼest top, utilisez le! 55 55 1. Le scheduler scale 2. Observabilité dès le début 3. Migrer progressivement
56. La suite ? 56 56
57. Memories made on water 57 Thank you! Jérémie AUGUSTIN Github: @jaugustin X : @pixeljer On recrute! www.clickandboat.com/jobs