Aujourd’hui, se tenait chez Criteo, la conférence NABD. Oui c’est une conférence très orientée big data mais ce n’est pas une autre conférence sur le sujet comme le dit le nom de l’événement. L’agenda est particulièrement riche, surtout l’après-midi et les sujets très variés : graphe, données historiques, time-series, Hadoop Yarn, deck.gl, etc. 

Nous avons retenu une des présentations de la matinée : moving to the cloud : a story from the tranches. C’est le récit terrain de Spotify, célèbre service de streaming de musique. Avouons que l’expérience vécue est intéressante car le service gère aujourd’hui 30 millions de chansons, 100 millions d’utilisateurs actifs. On image très bien le volume de données à traiter, notamment pour générer les playlists, les top selon les critères définis, etc. 

Spotify raconte que l’infrastructure a plusieurs fois changé : datacenter interne puis du cloud Amazon, puis retour au bare metal interne puis nouveau retour sur le cloud, mais cette fois-ci sur Google Cloud Platform, tout en gardant des serveurs Hadoop. Notez que le bare metal était monté à 700 machines… Et en 2014-2015, la décision fut prise de retourner sur le cloud… 

Spotify a considéré que le cloud était désormais mature, avec un coût moindre et la capacité de suivre la montée en charge du service. Un argument nous a beaucoup interpellé : la machine physique n’est pas pour nous un avantage compétitif. Cela veut dire qu’avoir de gros datacenters internes et maintenir une infrastructure importante n’apporte pas un avantage. Et si on va plus loin, on va parler de budget et de maintenance. Pourquoi le choix de Google, qui n’est parfois pas décrit comme un leader, à tord : « on pense que Google sera un leader sur les services de big data, et pour nous, c’est important ». Spotify a choisi Google pour les services big data et notamment Big Query. 

Mais on ne change pas une infrastructure Hadoop interne comme cela et il ne fallait pas casser le fonctionnement du service. La migration a démarré il y a 2 ans. Et plusieurs challenges ont été relevés, l’éditeur ne s’en cache pas. 

Le 1er challenge a été de construire les briques nécessaires pour migrer et fonctionner sur le cloud. Big Query peut être vu comme un Hive mais sans les noeuds Hadoop et les serveurs à gérer. Pour comparer l’avantage de l’offre Google, un petit benchmark a été fait sur la génération du top 10 des artistes français pour mai 2017 :

En Hive : 4055s et 21 To de données traités

En Big Query : 66s et 2,2 To de données traités

Une partie du travail a été de migrer les données vers le cloud et les process qui allaient avec, le lien Hadoop - Big Query a été essentiel à mettre en place. Et le copy jobs a tendance à stresser le réseau ou atteindre les limites de chargement de données sur Big Query. 

Ce changement de services d’infrastructure a permis à Spotify de supprimer plusieurs outils / solutions. Ainsi, Kafta a été remplacé par un cloud pub/sub. Il s’agit faire du message queue avec une volumétrie importante, plus de 800 000 événements par secondes et une latence très faible. Google DataFlow a été mis en place pour remplacer Spark et Flink. Spotify a développé une API Scala, Scio, pour assurer le lien entre Apache Beam et Dataflow. 

L’usage de Dataflow a permis de lancer un autre chantier : remplacer Storm et Map/Reduce. 

L’orateur met aussi en garde : le cloud n’est pas une ressource infinie et il n’y a pas de garantie de capacité pour les jobs hautement critiques. 

Le 2e challenge a été le chemin, bref : comment migrer les pipelines de flux sur le cloud ? Un des chemins pris a été d’utiliser des conteneurs, avec un cron distribué. Avec cela, l’opération était assurée par les serveurs internes. Et pour ordonnancer tout cela, un scheduler de jobs a été mis en place, avec Kubernetes. Pour faciliter l’exécution des « data processing jobs » sur la plateforme Google, les équipes ont développé une API dédiée : Spydra. L’outil est un des éléments de la migration de l’infrastructure de données interne vers Google. Spydra repose sur l’expérience des équipes et du cluster Hadoop déployée (2500 noeuds et 100 Po de capacités). 

L’autre chemin est la réécriture mais attention cela peut coûter très cher en temps et en budget. Donc méfiance… Le commentaire de la session est clair : « et pourquoi pas réarchitecturer ? »

Le 3e challenge a considérer et à relever concerne les dépendances et donc l’arbre de dépendances. Chez Spotify, cet arbre est énorme, avec de multiples sections et des dépendances plus ou moins importantes. La question a été de savoir comment faire 2000 jobs et 20 000 endpoints générés chaque fois sur le cloud de Google ? Méfiance donc. 

Mais clairement, le cloud est l’avenir même si le chantier est toujours en cours. Il faut avoir en tête le coût global, les risques de verrouillage technologique lié à un fournisseur ou encore se retrouver avec une boîte noire. 

Les points à retenir selon Spotify :

- ça en vaut la peine et nous sommes voués à réussir
- avoir conscience des ressources limitées du cloud
- avoir un chemin de migration et de fonctionnement clair et précis
- visualiser les progrès : c’est important pour avoir un suivi régulier du chantier

François Tonic