Comment Michelin a migré sa plateforme Kafka vers le cloud

Kafka, au cœur des applications critiques chez Michelin

Au sein du groupe, l’adoption de Kafka ne date pas d’hier : les premiers projets ont émergé en 2018. Il s’avère que la notion d’architecture orientée événements a créé un fort engouement dans pratiquement toutes les lignes métiers.

Le fabricant de pneus utilise l’ensemble de la pile technologique Kafka au sein de ses systèmes critiques. Plus précisément, il a fait le choix d’adopter la distribution commerciale de Confluent, le principal contributeur au projet open source.

« Concernant la prise de commandes de nos usines jusqu’à nos entrepôts, nous avons un gros projet fondé sur Kafka Streams avec des notions de transactions et « d’exactly once ». Il concerne environ un millier de microservices », explique le Squad Leader Integration.

Dans le monde réel, il s’agit de transporter des pneus depuis 67 usines dans des entrepôts installés dans 171 pays.

La gestion des événements logistiques - qui retracent les livraisons des pneus aux clients finaux - est également effectuée à travers Kafka.

« De même, d’un point de vue finance, nous gérons le processus order-to-cash, de la prise de commande jusqu’à la facture finale à l’aide de Kafka », précise Damien Fayet.

Kafka Connect, elle, est la brique utilisée pour exposer les données issues des référentiels de manière centrale.

Une infrastructure sur site qui n’allait plus tenir la route

Ces déploiements Kafka ont débuté sur une infrastructure on-premise. « Nous avons débuté par un petit cluster, puis les clusters se sont additionnés au fur et à mesure que les projets se sont accumulés », se rappelle Damien Fayet. Rapidement, plus de 35 projets ont vu le jour sur une seule plateforme Kafka sur site. Certains de ceux-là desservaient des applications critiques.

« Est-ce que Michelin a vocation à gérer de l’infrastructure Kafka ? La réponse était clairement non, d’autant plus que la popularité de Kafka grandissait en interne ».

Et au rythme d’adoption prédit par l’équipe en charge des plateformes d’intégration, qui impliquait d’ajouter trois nouveaux courtiers de messagerie Kafka (brokers) par trimestre, le maintien de la plateforme sur site n’était clairement pas rentable.

« Avions-nous la capacité d’accueillir de plus en plus de projets Kafka au niveau de nos data centers ? Au moment de se poser la question, nous étions à court de place », ajoute Guillaume Dury, Product Owner chez Michelin.

Au-delà des problématiques d’infrastructures, les équipes de Michelin commençaient à ressentir la rançon de la gloire.

Une seule équipe était responsable de la gestion des clusters et l’équipe centrale avait peur qu’elle devienne « un goulet d’étranglement » pour l’arrivée des nouvelles équipes et projets.

Par ailleurs, les échanges de données entre applications auguraient de fortes interdépendances entre les services. De plus, « il n’y avait pas de normalisation des initiatives au sein de chaque cas d’usage », indique Guillaume Dury.

Sans parler des coûts supplémentaires à prévoir en ressources humaines, en infrastructure et en licence.

Michelin a donc fait le choix de migrer de Confluent Platform sur site vers Confluent Cloud.

« L’objectif, c’était d’avoir une plateforme partagée qui facilite l’accès à la donnée à l’intérieur du groupe Michelin, que ce soit en interne, avec les filiales, ou à l’externe », explicite Guillaume Dury.

Seul le « backbone Kafka » devait migrer vers le cloud, tandis que les applications « conservaient leur business intelligence ». Tout cela pour que les équipes puissent se concentrer sur les logiques métiers, « là où il y a une réelle plus-value ».

Etablir les itinéraires de migration les plus courts…

Une fois cette décision prise, les experts de la technologie ont ainsi mis en place un chemin de migration prenant en compte l’ensemble des particularités des déploiements existants.

« Il nous fallait observer chaque projet au cas par cas », informe Guillaume Dury.

Dès le mois d’octobre 2020, les experts chez Michelin se sont posé un bon nombre de questions pour déterminer les protocoles de migration.

« Est-ce que l’application a besoin d’un historique ? Quel type de données est traité ? Transactionnel ? Référentiel ? Quel est le contexte applicatif, comment interagissent les producteurs et les consommateurs de données ? », liste le product owner.

Ensuite, les experts ont bâti un chemin de migration théorique. Par exemple, pour les référentiels de données, il a été décidé de répliquer les producteurs de ces données dans le cloud. « Cela devait permettre aux consommateurs hébergés dans le cloud de tirer plus facilement des flux de données », avance Guillaume Dury.

Une fois que les producteurs ne poussaient plus de données depuis l’infrastructure on-prem, ceux hébergés dans le cloud devaient prendre le relais. « Il n’y avait plus qu’à décommissionner les producteurs sur site et à ne conserver que les données référentielles dans le cloud. C’est le chemin de migration facile », présente le product owner.

De manière générale, les équipes de Michelin ont tenté d’emprunter le chemin de migration le plus court pour chaque cas d’usage. Durant cette période, l’architecture Kafka était donc hybride. Les services Kafka devaient être répartis entre l’infrastructure sur site et celle dans le cloud, et se retrouveraient parfois déployés sur les deux. « Cela amenait une certaine complexité en matière de gestion du réseau et du support applicatif », constate Guillaume Dury. Il y avait également un facteur financier à surveiller : « nous avions prévu notre migration sans renouvellement de nos licences [Confluent] sur site ».

…Et conserver les outils en place

Ce planning serré a demandé une coordination entre l’équipe IT centrale en charge de la plateforme d’intégration, l’équipe support de l’éditeur, les lignes métiers et les équipes opérationnelles (infrastructure, réseau, sécurité).

Il y avait un impératif supplémentaire : s’assurer que les outils développés en interne – rassemblés dans une librairie nommée Kafka Features Extensions (KFE) et utilisés pour la supervision des services Kafka - puissent être compatibles avec la solution « SaaS ».

Par ailleurs, Michelin avait besoin d’effectuer de la ségrégation des données en provenance des différentes lignes métier. « Vous imaginez bien que les données de la R&D ne peuvent pas se retrouver dans les mains de la supply chain et vice-versa », illustre Damien Fayet.

En sus de la migration technique, il fallait s’assurer du respect des bonnes pratiques de développement et des conventions de nommage.

« Les outils présents dans KFE doivent permettre à nos équipes de gagner en autonomie. Il s’agit presque d’offrir Kafka en libre-service ».

« Les outils présents dans KFE doivent permettre à nos équipes de gagner en autonomie. Il s’agit presque d’offrir Kafka en libre-service », avance Damien Fayet.

L’équipe centrale a notamment développé NS4KAFKA, une suite d’outils rattachée à KFE qui permet de piloter le modèle de déploiement des ressources Kafka (topics, Kafka Connect). Celle-ci vise à assurer l’isolation des espaces de nommage, une problématique bien connue des utilisateurs de Kubernetes. NS4KAFKA doit également vérifier le contrôle des états des clusters Kafka. Par ailleurs, l’outil apporte un moteur de règles pour piloter les politiques de rétention ou encore les partitions. Enfin, la librairie fournit un CLI conçu pour s’intégrer avec les chaînes CI/CD.

Un an pour migrer vers le cloud

 L’on ne change pas de pneu comme de chemise. Et l’on change pas de plateforme Kafka comme de pneu. Après une validation technique en février 2021, le contrat avec Confluent a été signé en avril de la même année. Les premiers environnements Confluent Cloud ont été mis en route en juin 2021 pour les équipes métier. En juillet, le premier cas d’usage entrait en production.

En octobre 2021, Michelin a migré ses données référentielles dans le cloud. En novembre, l’équipe a terminé sa première migration. « Du mois de novembre 2021 jusqu’en avril 2022, nous avons enchaîné tous les go-lives de migration de toutes nos applications », évoque Guillaume Dury.

Au mois d’avril, Michelin terminait les décommissions des clusters sur site.

Michelin s’est ainsi dégagé de la maintenance de la plateforme, qui est désormais aux mains de Confluent. L’architecture élastique de Confluent Cloud doit permettre d’adapter automatiquement la quantité de ressources cloud en fonction des charges de travail.

De son côté, l’équipe en charge de la plateforme d’intégration a rendu les équipes autonomes, permis la ségrégation des données, a assuré la normalisation des ressources Kafka au cours de la migration grâce à sa suite d’outils KFE.

En septembre 2022, plus de 2 200 topics Kafka étaient mis à disposition en production sur Confluent Cloud. Plus d’une centaine d’applications s’exécutent sur la plateforme EDA.

Il lui reste à piloter les coûts d’une telle architecture déportée dans le cloud. Selon les dires des deux experts, le bilan financier serait « positif ». « Cela correspond à nos prévisions », avance Damien Fayet, sans trop s’étendre sur le sujet.

Cela ne veut pas pour autant dire que Michelin en a fini avec ses déploiements de Kafka. « Tous les jours, l’on nous soumet tous les jours de nouveaux projets à déployer », affirme Guillaume Dury.

Dans un même temps, l’équipe centrale doit gérer l’adoption de la plateforme et la fourniture de bonnes pratiques. « Notre nouveau cheval de bataille sera la gouvernance des données au vu du nombre de projets », anticipe le product owner.

Propos recueillis lors du Confluent Data in Motion 2022 à Paris.