Accueil Cloud Comment Radio France a migré ses sites Web vers Kubernetes

Comment Radio France a migré ses sites Web vers Kubernetes

Avec des chaînes telles que France Inter, France Info, France Culture et France bleue qui caracolent en tête des audiences Web, Radio France a réussi son virage vers le digital. Côté infrastructure informatique, cette mutation s’est faite dans la douleur.

Pierre-Gilles Mialon, Cloud Architect chez Radio France, attaché à la direction du numérique, était fier de présenter au public du Google Cloud Summit, le dernier événement en date de Google à Paris, les courbes d’audience des radios publiques sur le Web françaises ainsi que celles des téléchargements de podcasts. L’essor exponentiel de l’audience, notamment à partir de 2014 prouve le succès des sites des 7 chaînes de radio du groupe ainsi que celui de leurs applications mobiles. Aujourd’hui 12 % de l’écoute radio est réalisée en numérique et la moitié de ces 12 % se fait sur smartphone. Si Radio France a réussi sa transformation digitale, il a fallu faire face à cette hausse rapide des audiences Web, avec une DSI sur la brèche depuis plus de 4 ans maintenant. En effet, l’infrastructure Web du groupe n’a cessé de connaître de profondes mutations technologiques à un rythme très rapide. « Nous sommes arrivés à la situation actuelle par migrations successives. La première a été menée en 2014, ce qui nous a permis de passer de serveurs dédiés à un Cloud privé. C’est en 2015 que nous avons décidé de nous tourner vers le Cloud public, et en 2017, nous avons fait passer notre architecture full VM à une architecture pilotée par Kubernetes. » Retour sur cette épopée informatique.

Du Bare Metal au Cloud public en passant par le Cloud privé

En 2014, alors que l’audience Web commence à grimper, Radio France exploite des serveurs Bare Metal afin de faire tourner les plateformes LAMP (Linux/Apache/MySQL/PHP) de ses 7 sites Web. Mais alors que certains serveurs étaient inactifs, d’autres étaient surchargés.

Pierre-Gilles Mialon
Pierre-Gilles Mialon, Radio France, témoignant au Google Cloud Summit

« Nous devions rationaliser ses ressources de traitement et c’est pourquoi nous avons migré ces serveurs Bare Metal vers un Cloud privé avec lequel il était plus simple d’accorder à chacune de nos chaînes les ressources dont elles avaient besoin. » A cette époque, Radio France ne dispose pas d’une équipe Ops et cette migration vers un hébergeur est réalisée aux forceps, avec plus de 5 rollbacks (retours en arrière) pour le site de France Inter pour un résultat jugé décevant. Les sites répondaient mal et s’avéraient très lents. Très vite, un jeu de ping-pong s’instaure entre les développeurs et l’hébergeur, chacun renvoyant à l’autre la responsabilité des piètres performances des sites. « Nous avons alors envisagé la refonte de notre applicatif, passer de l’approche monolithique LAMP pas très performante à une architecture basée sur les microservices. » Pour ne pas renouveler la situation rencontrée avec l’hébergeur, l’équipe de Pierre-Gilles Mialon fait le choix d’être « Cloud agnostique » au travers de choix technologiques qui lui permettront de passer d’un opérateur Cloud à un autre sans difficulté. « Le choix de Terraform devait nous permettre de piloter notre infrastructure sur GCP et sur AWS et effectivement, depuis juin 2015, nous sommes capables de redéployer quotidiennement une infrastructure de test complète avec le backup de la production de la veille de manière totalement automatisée. »

Une migration vers les microservices… en catimini

Premier site à bénéficier d’une migration vers la nouvelle architecture baptisée Wanda, le site de France bleu dont la migration était programmée pour septembre 2015. L’histoire des migrations chez Radio France étant qualifiée de « pathologique » par l’architecte, la direction de la chaîne n’a pas souhaité communiquer sur la sortie de la nouvelle version du site, de peur de générer un pic de fréquentation qui écroule le site le jour de sa mise en ligne. « Le site a été basculé en production à 5 h du matin, le pic d’audience de la matinale se passe plutôt mieux qu’avec le site précédent, ce qui est somme toute assez normal puisque nous avions tout refait. Comme la chaîne n’annonçait toujours pas le nouveau site, c’est au bout de quelques jours que les auditeurs ont commencé à appeler car ils n’étaient plus très sûrs d’être sur le site France Bleu… Ce n’est qu’à partir de ce moment-là que la chaîne à pris la décision de communiquer sur son nouveau site. » Wanda a réussi son examen de passage et va démontrer son efficacité sur la durée puisque le site France Bleu a vu sa disponibilité moyenne passer de 99,99 % à 99,999 %.

Pour décrire son architecture Wanda, Pierre-Gilles Mialon explique comment est générée chaque matin la plateforme de préproduction : « Un cron [table de planification] Terraform est lancé tous les matins afin de générer la préprod. Terraform instancie les machines virtuelles et effectue le nommage. Dans un second temps, Puppet vient s’appuyer sur les noms définis par Terraform afin de configurer le serveur, selon qu’il s’agisse d’un serveur de bases de données, des serveurs de cropping d’images, ou un serveur HTTP. Consul nous sert de registry dynamique, configurée par Puppet. Cela permet de savoir où est qui. HAproxy sert d’ambassadeur pattern, il est configuré par Consul via Consul Template pour générer les configurations et permettre à l’ensemble des microservices de communiquer les uns avec les autres. Il y a une VM pour chaque service et est représenté au moins trois fois dans l’architecture pour que nous puissions perdre jusqu’à 2/3 de notre infrastructure et que le service puisse continuer à fonctionner. »

Basculer vers Kubernetes pour optimiser l’exploitation des ressources

Si Wanda a su démontrer sa fiabilité, la plateforme s’appuyait sur 25 000 lignes de code Puppet, ce qui nécessitait plusieurs mois à un Ops pour en acquérir une bonne maitrise. En outre, la solution ne parvenait pas à tirer la quintessence de la plateforme d’exécution : « Nous avons constaté que des ressources CPU et Ram restaient non consommées sur nos serveurs, or il s’est avéré que nous ne pouvions pas choisir des instances moins puissantes et donc moins coûteuses. En effet, les microservices sollicitent énormément le réseau or les capacités réseau des instances Cloud sont fortement liées à la puissance CPU allouée à la machine. Sachant que l’affichage d’une page d’un de nos sites génère jusqu’à 2 500 appels réseaux lors de son affichage, on imagine l’impact réseau sur la performance. » Kubernetes apporte une solution à ce problème car la plateforme de gestion des conteneurs créée par Google permet une collocation des microservices au sein d’une même machine virtuelle, ce qui permet d’opter pour une grosse machine virtuelle qui dispose d’une bonne capacité réseau et d’utiliser de manière optimale la puissance CPU et la Ram à disposition. De même, il est plus rapide d’orchestrer des conteneurs que des VM. Le temps de déploiement de la plateforme Radio France complète est passé de 2 heures à 10 minutes seulement avec Kubernetes.

Pour améliorer encore l’efficience de la plateforme digitale de Radio France, Pierre-Gilles Mialon s’est intéressé à Istrio. « Ce qui nous intéresse particulièrement dans Istrio, c’est l’affinité de zones. Nos factures Cloud se répartissent entre 1/3 de compute, 1/3 de trafic interzone, le reste étant représenté par le trafic externe et le stockage. Notre cluster Kubernetes est réparti sur 3 zones avec 3 masters pour des raisons de résilience. Or lorsqu’on déploie un microservice dans Kubernetes, celui-ci ne va pas nécessairement communiquer avec les microservices de la même zone.  Cela génère du trafic qui coûte cher et cela ajoute de la latence inutile. Istio nous permettra de faire en sorte que les microservices déployés sur la zone A parlent à ceux de la zone A, ceux de la zone B ne communiquent qu’à ceux de la même zone. »

Si Radio France dispose enfin d’une plateforme performante et pérenne, Pierre-Gilles Mialon songe déjà à la prochaine étape, c’est-à-dire passer au déploiement continu. Cette nouvelle étape constituera sans nul doute l’aboutissement d’une démarche d’automatisation initiée il y a 4 ans.

 

Auteur : Alain Clapaud