La migration de L’Equipe.fr vers le Cloud GCP

Cette migration a été effectuée en 4 mois entre septembre et décembre 2018. Six mois après il m’a semblé intéressant de faire un bilan et d’en tirer quelques enseignements.
Cet article s’inspire largement de la présentation faite le 18 juin 2019 au Google Summit de Paris avec Céline Aurégan, team leader à L’Equipe.fr et Jean Pierre Chamarande CEO de Skale-5.

Présentation de lequipe.fr

L’Equipe est un media de sports complet avec un quotidien sportif, des sites et des applis et une chaîne télé gratuite sur la TNT.

L’Equipe.fr est un des tous premiers sites media Français.
Les sites et les applis sont réalisés par 35 développeurs. Ils sont alimentés par plus de 100 journalistes.
C’est 1,5 milliard de pages vues par mois, 3 millions de visiteurs uniques chaque jour et 15 millions chaque mois.

Les matches phares de football provoquent des montées de trafic très brusques, par exemple pendant le match PSG- Manchester United nous avons connu des pointes à 300 000 pages vues par minute !
Il est donc très important que la plateforme puisse encaisser ces pics et cela chaque semaine.

Nous notifions simultanément 3,5 millions d’utilisateurs via nos applis. Avec un taux d’ouverture qui peut culminer à 10 % pour certaines news, on prend donc une charge très violente en 2 ou 3 minutes.
D’ailleurs, pour tenir la charge, nous utilisons Google Shield pour les images de ces alertes.

Contexte et objectifs de cette migration

En 2018, nous avons décidé de lancer un appel d’offres pour l’hébergement. Nous étions depuis l’origine chez un hébergeur traditionnel dont l’organisation commençait à nous peser, face à une structure lourde et segmentée (une équipe système, une équipe réseau, une équipe sécurité…) qui ne correspondait plus aux besoins d’un site media dont les mises à jour et les évolutions sont par nature très fréquentes pour suivre le rythme de l’actualité.
Nous voulions sortir de l’infogérance 1.0, pouvoir monter un POC avec un nouveau type de serveur en quelques heures et surtout que notre équipe devienne acteur de la vie de sa plate-forme technique et puisse demain étendre son domaine d’action, en visant l’autonomie un jour.

Dans notre appel d’offre, adressé à 6 sociétés, nous avons souhaité avoir des réponses orientées Cloud public mais pas seulement. Au départ, vus nos délais, nous n’étions pas certains de migrer vers le Cloud en une seule étape.
Cependant au fil des discussions, il s’est avéré que c’était la meilleur solution et que celle ci serait plus motivante pour nos équipes.

Le choix s’est porté sur GCP car l’offre Google nous a semblé aussi mature que celle d’AWS pour nos besoins et nous avons rencontré en Skale-5 une société qui parlait le même langage que nos développeurs, de petite taille certes mais maîtrisant parfaitement GCP et donc en mesure de nous accompagner lors de la migration et au delà quand on voudra prendre plus de responsabilités sur notre plate-forme.

Ce choix de GCP et d’une petite structure n’était pas forcément évident à faire passer mais un comité élargi pour l’appel d’offres (métier, technique, DSI) a permis de convaincre.

Organisation et planning

Nous disposions de 4 mois pour migrer ce qui était relativement court. L’Equipe est un site ancien avec évidemment du code Php legacy que nous n’avions pas le temps de réécrire.

Comme contraintes nous avions aussi un SGBDR Sybase, très exotique dans le monde Web et sur lequel les répondants à l’appel d’offre n’avaient pas ou très peu d’expérience.

Et surtout un Filer NetApp avec plusieurs centaines de milliers de fichiers représentant 1,3 To avec des modifications permanentes.

Enfin nous devions migrer avant le 31 décembre fin de notre contrat mais avec une actualité sportive très dense jusqu’au 22 et des matchs NBA suivis en live chaque nuit. La rédaction de l’Equipe travaille de 6h à 1h du matin laissant donc une plage très courte pour les opérations de maintenance.

Nous avons choisi l’option Lift and Shift en faisant quelques changements qui étaient de toutes manières prévus et qui ne mettaient pas en péril le planning.

• remplacement de solR par Elastic Search
• remplacement de couchDB par MongoDB
• remplacement de Redis par le service managé Cloud Memorystore
• passage de notre mySQL sur le service managé Cloud SQL

L’objectif était de limiter les inconnus et de rester dans une zone de maîtrise.

Toutefois les premiers piliers du DevOps devaient être implémentés :

1) Infra As A Code : l’infra doit se piloter par du code, c’est une condition sine qua non d’une démarche résolument DevOps

Ce code doit être partagé entre tous les intervenants, chacun a le droit d’une bonne idée et de proposer une évolution. Le principe de PR garantissant la qualité du code produit …

2) Automatisation : Une CI/CD parfaitement opérationnelle pour ce qui concerne le code Infra, et une démarche volontaire pour en faire de même avec le code applicatif.

C’est sur ce terrain qu’il faut passer du temps lors de la phase de set-up, et ce n’est pas toujours simple …

L’Architecture cible de la migration

La plate forme cible comprend une dizaine de composants principaux: un groupe de serveurs fronts et un groupe de serveurs middle (outils, traitements…), 2 Varnish croisés, des clusters ES, Memcached, Rabbit MQ, MongoDB, un gros NFS, un cluster Sybase.

Soit au total une quarantaine de VM et 2 services managés : mySQL sur cloudSQL, Memory Store (Redis)

Cette architecture est raisonnablement complexe par la richesse et la variété des composants utilisés, mais avec un nombre de serveurs limités par notre mécanisme de caching.

Ce système de caching éprouvé, situé en amont de la plate forme, est resté inchangé. Il a été décrit dans cet article.

Les bonnes et les mauvaises surprises

On a essayé de transférer notre filer via une solution Cloud NetApp mais sans succès. Il n’était pas possible non plus d’ouvrir notre netApp car mutualisé. Un SSH depuis les serveurs Google n’a pas été accepté pour des questions de sécurité.

Heureusement nous avions anticipé un système de recopies régulières incrémentales via un tunneling SSH genre “Man in the middle” qui a tourné une première fois pour initialiser puis chaque nuit, en faisant des diff sur 24 heures et écriture de ces fichiers en blocs de 200. Une crontab faisait chaque nuit les mises à jour avec un système de verrou pendant la phase de copie.

On craignait le débit limité de notre ligne spécialisée à 10 Mbps mais finalement ce système a très bien marché.
Le soir de la bascule, le rattrapage du delta a été fait en moins de 2h !

Le SGBD Sybase est notre base de données sportives. Sybase est pour le moins exotique dans le monde du web, on partait donc dans l’inconnu avec peu de références sur du virtualisé. Au final le fonctionnement sur des VM est très bien passé.

Quelques chiffres clé

Les économies budgétaires sont de l’ordre de 20 %.

Nous avons réduit de 40 % le nombre de serveurs front.

Le budget se décompose comme ceci :

• 10% de bande passante
• 25% d’infogérance
• le reste est essentiellement du compute engine lié à notre legacy qui n’exploite pas encore suffisamment de services managés. Une manière d’optimiser la facture est bien d’aller vers plus de services managés.

Un point très positif est qu’on a beaucoup plus d’informations sur les postes de coûts que précédemment où le coût de plate-forme était un chiffre global sans détail. Maintenant on peut avoir le détail de chaque composant par projet, produit ou SKU et même isoler la bande passante !

Pour réduire le nombre de serveurs nous avons commencé de manière prudente en reprenant le dimensionnement de la plate forme d’origine, puis observé ce qui était utilisé concrètement (cpu, RAM) puis on a diminué par étapes.

Outre la réduction des serveurs, on a ajusté sur certains services la ram et ou la cpu, comme par exemple sur nos Varnish qui avaient besoin d‘un peu plus de ram mais avaient beaucoup trop de cpu.
GCP permet de gérer des Custom VM avec ram et cpu optimales.

Une démarche de Committed Use Discounts sur 3 ans a été lancée afin de poursuivre cette optimisation.

Depuis janvier une vingtaine de modifications ont été réalisées (changement machines, downsize, ajout de services) ce qui revient à 1 changement toutes les 2 semaines.

On a aussi beaucoup plus de détails sur les serveurs, les infos sont plus accessibles.
Nous avons partagé beaucoup de dashboards (créés par Skale-5 et nous), on a des outils de monitoring très fins de notre infra GCP à base de Prometheus, Grafana et ELK. Le Prometheus alimente Opsgenie chez Skale-5.

Applicativement, les releases/livraisons front sont libérées mais il nous reste des améliorations à faire sur la partie back (héritage du legacy)

Les échanges avec notre infogérant sont plus fluides qu’avant et se font , comme on l’espérait, en réelle confiance.
Nos DevOps sont beaucoup plus heureux car acteurs de la plate forme, les contributions du code de l’infra (Terraform) sont partagés.

Enfin la mise à disposition de nouveaux services (Node, Postgre) se fait bien en quelques heures.

La suite ?

L’autoscaling sera bientôt à l’ordre du jour.

Nous réfléchissons à mettre du Docker en production, d’abord avec nos images actuelles (celles des développeurs) puis sur GKE (Kubernetes) pour nos micro services et api.

Il existe de nombreux composants GCP qu’il nous appartient maintenant d’appréhender pour améliorer les fonctionnalités vers nos utilisateurs et optimiser les coûts.

Quelques conseils

Si vous avez beaucoup de code legacy, laissez vous plus de temps : 4 mois c’est court. Mais prenez en compte le fait que lorsque vous annoncerez à votre hébergeur que vous partez, les relations peuvent devenir compliquées.

Si vous envisagez comme nous de passer d’un hébergement classique au Cloud, faites vous accompagner. Et prévoyez d’avoir des compétences Cloud dans votre équipe.

Anticipez la connaissance exhaustive de vos applications. Vous ne pourrez pas déménager sereinement si vous savez pas ce qu’il y a au grenier et à la cave.
La très bonne connaissance que nous avions de nos applications a été un facteur important de réussite.

Etudiez en amont le modèle de facturation GCP qui est public mais comporte des subtilités et surtout prévoyez que vous aller devoir vous en occuper ! Peut être pas créer un poste FinOps à temps plein mais un suivi quotidien est nécessaire.

A ce propos l’export des données de facturation vers Big Query est intéressant pour monter vos dahboards dans Data Studio afin de les partager avec votre direction.