Spotify mise sur Google Kubernetes Engine pour ses audiences records
Depuis son lancement en 2006, Spotify a profondément fait évoluer son infrastructure IT. Historiquement construit en interne, son tout premier système atteint une capacité de huit data centers en 2015. Il compte alors 2 000 services applicatifs et 20 000 pipelines de données exécutées quotidiennement pour 100 Po de stockage. Son métier n'étant pas de gérer des usines informatiques, la plateforme de streaming décide alors d'évoluer vers le cloud. Le choix se porte sur Google Cloud Platform (GCP). La stratégie de migration est double. Pour le front end utilisateur, le copier-coller d'applications (ou lift and shift) est retenu en vue d'éviter toute interruption de service. En parallèle, la réécriture de code (ou refactoring) est privilégiée pour le data processing, l'idée étant de tirer parti au maximum des environnements de données de Google, que sont notamment Bigtable, BigQuery et Cloud SQL. Mais pour Spotify, le cloud de Mountain View présente un autre intérêt. Il dispose d'un orchestrateur de containers managé à l'état de l'art : Google Kubernetes Engine (GKE).
Certes, Spotify n'a pas attendu Google pour se tourner vers les containers logiciels. Dès 2013, l'entreprise de Stockholm développe son propre orchestrateur Docker, dénommé Helios. Mais à la différence de GKE, il ne permet pas d'automatiser le provisionning des serveurs virtuels nécessaires à l'exécution des architectures containérisées. Il implique par conséquent une infrastructure en permanence surprovisionnée en ressources en vue de faire face à tout impondérable, du pic de trafic aux nouveaux projets. GKE, lui, bénéficie de l'autoscaling industriel de Google. Résultat : les unités de calcul sont activées à la volée au regard de l'évolution de l'audience, qu'elle soit à la hausse ou à la baisse. N'est payé que ce qui est consommé.
Une brique stratégique
La décision de basculer vers Kubernetes Engine est prise fin 2017 alors que la migration d'Helios vers Google Cloud est tout juste achevée. "Il était devenu assez clair qu'Helios et sa petite équipe de développeurs ne feraient pas le poids face à la communauté Kubernetes", argue Jai Chakrabarti, directeur de l'ingénierie, de l'infrastructure et des opérations de Spotify. "En se tournant vers Kubernetes, l'objectif était de bénéficier de sa vélocité tout en réduisant nos coûts, mais aussi évidemment de nous aligner sur le secteur en termes de bonnes pratiques et d'outils."
"Sur 150 composants applicatifs migrés sous GKE, le principal d'entre eux encaisse 10 millions de requêtes par seconde"
Presque trois ans après, l'orchestrateur de Google représente un élément clés de la stratégie de Spotify pour encaisser la croissance de son audience. De 140 millions d'utilisateurs actifs mensuels fin 2017, la plateforme est officiellement passée à presque 300 millions en juin, soit une hausse de 29% d'une année sur l'autre.
"Les premiers résultats sont là. Sur 150 composants applicatifs migrés sous GKE, le principal d'entre eux encaisse 10 millions de requêtes par seconde et bénéficie grandement de l'autoscaling", reconnait James Wen, senior site reliability engineer chez Spotify, avant de préciser : "Auparavant, une heure était nécessaire pour créer un nouveau service applicatif et l'exécuter de manière opérationnelle en production. Kubernetes réalise ces taches en quelques secondes voire quelques minutes. De plus, avec les capacités de Kubernetes en multi-tenant et bin-packing, l'utilisation de la CPU a été améliorée par deux ou trois."
200 équipes d'ingénierie dans la boucle
Le chantier de migration n'en est qu'à ses débuts, reste donc à savoir comment Spotify gère la cohabitation de Kubernetes avec Helios. "Ces deux environnements sont très différents, que ce soit en termes de gestion des métriques, des identifications, etc.", souligne Matt Brown, ingénieur chez Spotify. "Notre plateforme compte des milliers de microservices qui inter-opèrent les uns avec les autres. Si nous avions voulu les migrer un par un vers Kubernetes, cela aurait demandé des années."
Pour relever ce défi, les développeurs du groupe ont réutilisé la couche d'API (nom de code : Tugboat) qui avait été conçue initialement pour piloter des déploiements sur l'architecture Helios. Ils y ont greffé une option pour prendre en charge les API Kubernetes.
"Du coup, nos 200 collaborateurs des équipes d'ingénierie peuvent désormais gérer leurs mises en production quel que soit l'orchestrateur. Nous avons pu utiliser un grand nombre des interfaces et extensions Kubernetes pour prendre en charge et connecter ainsi notre infrastructure existante", ajoute James Wen. Une démarche intelligente qui évite de forcer la main aux équipes de gestion de projet et permet de passer ainsi d'un environnement à l'autre en douceur.