Projets

Des mises en production progressives pour les sites de e-commerce de Decathlon

Dans un magasin Decathlon. À l’occasion d’une modification de son identité de marque, le distributeur a repensé l’architecture de ses sites de e-commerce et la sécurisation des mises en production sur ceux-ci. (Photo : Decathlon)

Pour limiter les incidents, la marque de sport table sur la mise en production progressive de ses changements, via un canary intégré à sa chaîne de continuous delivery. Le principe : tester en production en dérivant une partie du trafic vers la nouvelle version.

PublicitéÉviter de voir un incident affecter toute la production. C'est à cette demande que les équipes techniques de Decathlon ont été confrontées à l'occasion d'un rebranding de la marque de sport en 2024, donc à une refonte des sites de e-commerce associés. « Auparavant, les pays avaient la liberté de customiser leurs sites. Conserver cette logique avec le rebranding aurait abouti à un ensemble peu homogène, détaille Maxime Véroone, un ingénieur ops dans le domaine e-commerce de Decathlon. Nous avons donc pris la décision de réviser les frontaux. » Le groupe bascule alors sur une logique multi-tenant [sur un environnement Kubernetes, NDLR], chaque pays bénéficiant de son instance. Le corollaire : une augmentation des risques lors des changements.

« Auparavant, nous pouvions tester nos déploiements sur un pays cobaye avant de l'étendre à toute la production. Là, ce n'était plus possible », reprend Maxime Véroone, qui s'exprimait lors du salon Cloud Native Days, à Paris, le 3 février. Avec des impacts potentiellement majeurs sur l'activité. « Un incident sérieux, c'est l'équivalent de 40 magasins fermés, souligne Johan Lore, lead tech ops chez Decathlon. Sans oublier les impacts indirects sur le click and collect et les effets en cascade sur les entrepôts. » Bien sûr, les tests permettent en théorie d'écarter les changements entraînant des incidents de production. « Mais effectuer des tests de charge reste difficile. Il n'y a qu'en production qu'on prend conscience des impacts réels », estime Johan Lore.

Tester sur 5% du trafic, puis 10%...

D'où le choix d'un outil assurant des mises en production progressives dans Kubernetes, en l'occurrence Flagger, un logiciel sous licence open source Apache 2.0 intégré nativement à la solution de déploiement GitOps Flux CD qu'exploite Decathlon. Techniquement, il s'agit d'un opérateur, un service permettant d'étendre Kubernetes, chargé de mettre en oeuvre des stratégies de déploiement dites canary, où de nouvelles versions d'une application côtoient des versions stables en production. La dérivation d'une partie du trafic vers cet environnement de test permet d'analyser les impacts en temps réel, la solution décidant d'elle-même de promouvoir la nouvelle version en production ou au contraire de l'écarter. « Mais l'autonomie n'empêche pas le contrôle », souligne Johan Lore. L'outil envoie ainsi aux équipes techniques des notifications pour suivre les étapes du processus et peut également demander des confirmations avant de passer à l'étape suivante.

Maxime Véroone, ingénieur ops dans le domaine e-commerce de Decathlon, et Johan Lore, lead tech ops au sein de la même société, lors du Cloud Native Days de Paris. (Photo : R.F.)

PublicitéPlusieurs approches de tests sont possibles : duplication du trafic (sans renvoi à l'utilisateur), A/B testing ou encore déploiement progressif par paliers. « Par exemple, on peut initier les processus en redirigeant 5% du trafic vers le canary, puis augmenter de 5% cette part toutes les 5 minutes », illustre Maxime Véroone. Quand un certain seuil est atteint, les pods Kubernetes basculent vers la nouvelle version et l'environnement de tests est alors éteint. « Par exemple, sur une API à 3 000 requêtes par seconde, quand on atteint 20% du trafic sans incident, on considère que la version est saine », reprend l'ingénieur.

L'enjeu n°1 : l'adoption par les développeurs

En pratique, l'usage d'un canary suppose tout de même quelques précautions, soulignent les deux experts de Decathlon. D'abord l'outil de monitoring utilisé par le distributeur (Datadog) peut entraîner une forme de pollution de Flagger, aboutissant à des décisions de retours arrière injustifiées. Les équipes techniques de Decathlon ont d'ailleurs proposé une contribution à la communauté Open Source pour régler ce problème. Ensuite, la précision des mesures de l'outil, donc la fiabilité des décisions qu'il prend dépend de la base statistique. Toute mesure devant être associée à son intervalle de confiance. « Par exemple, sur notre catalogue, qui enregistre un trafic massif, on peut se baser sur des intervalles courts de mesure, illustre Maxime Véroone. À l'inverse, sur le tunnel de commandes, par nature moins fréquenté, nous avons besoin d'intervalles plus longs. »

Par ailleurs, Decathlon a préféré brider certains automatismes de l'outil, pour garder la main sur les retours arrière et conserver un « bouton d'urgence », y compris après le processus Flagger. « Car les métriques ne sont jamais exhaustives à 100% et l'impact des incidents se manifeste parfois avec un effet retard », souligne Johan Lore. Pour son collègue Maxime Véroone, le principal enjeu de ce type de projet réside toutefois plutôt dans son acceptation par la communauté des développeurs. « Nous avons répondu à un besoin par une étude technique, puis par une solution présentée aux développeurs. Il aurait mieux valu coconstruire la solution avec eux », indique-t-il.