La BBC étoffe sa VOD grâce aux microservices

Chaque semaine, iPlayer, le service de télévision et de radio par internet de la BBC accueille 10 000 heures de médias vidéo et audio supplémentaires. Et depuis le passage à une plateforme de type microservices, la chaîne britannique publique n'a plus besoin de décider de ce qu’il faut ou non ajouter en regard des contraintes techniques. Lors d'une intervention très technique organisée pendant la conférence AWS Re:invent qui se tient cette semaine à Las Vegas, Stephen Goodwin, architecte en chef à la BBC, a expliqué comment, en 2012, iPlayer avait été porté sur l'infrastructure de cloud public d’AWS et comment la plateforme s’était développée.

Avant d’opter pour le cloud et de diviser son application iPlayer monolithique en microservices, la BBC faisait tourner le service iPlayer sur des systèmes physiques dans ses propres datacenters. À l'époque, c’était suffisant. Mais quand la BBC a ajouté à iPlayer des options d'affichage sur mobile, tablette et HD pour ses contenus à la demande et en direct, plus un service iPlayer Radio et des téléchargements, la solution a atteint ses limites. « Les systèmes n'avaient pas les ressources nécessaires pour prendre en charge toutes ces fonctions », a expliqué Stephen Goodwin. « Ils manquaient de puissance processeur, et le débit et le stockage étaient insuffisants ». Au final, l’ensemble était à la fois très rigide et peu stable.

Migration vers AWS SQS et SNS

Par exemple, à l’heure des informations locales de 18h30, BBC1 se divise en 19 chaînes régionales fonctionnant simultanément. « Avec l'ancienne configuration matérielle, il fallait de 16 à 17 heures pour traiter ces 19 canaux vidéos », a déclaré Stephen Goodwin. Aujourd’hui, il suffit de créer des instances EC2 supplémentaires pour traiter ces contenus au moment voulu et les ajouter au service iPlayer. Pire encore, à l’époque, la BBC n'avait pas la capacité de traitement pour mettre en ligne tout ce qu'elle diffusait. La chaîne employait même des assistants pour décider chaque semaine du contenu qu’il fallait charger en priorité sur le service.

L'ancien système était géré par une base de données centrale qui listait toutes les tâches à exécuter, essentiellement les contenus à télécharger sur le service. « Ça fonctionnait correctement et c’était stable », a encore déclaré l’architecte en chef. « Mais en cas de surcharge de travail, d’erreurs, ou s’il fallait lancer des sauvegardes, la base était saturée ». Si bien qu’au fur et à mesure que la base de données se remplissait, elle devenait de plus en plus difficile à interroger, et tout le service d’appel en aval était ralenti. La BBC n’arrivait pas à traiter les tâches assez rapidement, et la base de données continuait à grossir.

La BBC propose beaucoup plus de programmes en rattrapage depuis l'adoption des microservices. (Crédit BBC)

Pour contourner ce problème, les développeurs vidaient le contenu de la base dans un fichier texte et le réinjectaient lentement pour permettre au système de le digérer. « Ce n'était pas la panacée d'utiliser une base de données comme file d'attente », a reconnu Stephen Goodwin. Aujourd’hui, la BBC a remplacé tout cela par des microservices, tous soutenus par un puissant framework de mise en file d'attente et de messagerie. Sans surprise, l’ensemble est basé sur les outils d’AWS, d’où la présence de Stephen Goodwin à la conférence AWS Re:invent de cette semaine.

30 microservices distincts

Désormais, les workflows de messagerie et de mise en file d'attente sont pris en charge par les services de file d'attente simple SQS et de notification simple SNS d’AWS. En bref, les tâches précédemment chargées dans la base de données manuelle sont déplacées dans une file d'attente SQS avant d’être transmises sous forme de messages de microservices à microservices jusqu'à leur mise à disposition éventuelle sur iPlayer. « En réalité, le système est constitué de 30 microservices distincts, et les messages traversent une série de services successifs pour constituer le workflow », a expliqué l’architecte en chef.

En cas d’afflux de contenus à télécharger sur iPlayer, la file d'attente de messagerie et le système utilisent la mise à l'échelle automatique pour accroître le nombre d'instances. Les messages sont masqués pour éviter une duplication des tâches. « Nous pouvons ainsi mobiliser jusqu'à 30 instances en ayant la garantie qu'elles travailleront indépendamment les unes des autres », a encore expliqué l’architecte en chef de la BBC. Cela permet également à la chaine britannique d'être sûre qu'un message ne sera pas perdu. Comme l’a précisé Stephen Goodwin : « Nous utilisons cette méthode, car les messages représentent les tâches à réaliser et les systèmes de files d'attente sont bien adaptés pour garantir l'intégrité de ces messages. C’est important, car chaque message équivaut par exemple à ajouter un épisode de la série Sherlock à iPlayer et les téléspectateurs seraient mécontents s’ils ne pouvaient pas accéder aux épisodes de leur série favorite ».

Surveillance avec les outils de Splunk

Il y a cependant quelques restrictions : chaque message est prédéfini avec une période d'expiration de 30 secondes pour éviter de provoquer un goulot d'étranglement. Le système limite également à 5 le nombre de tentatives de traitement d’un message. Si un message pose problème, il peut être retiré de la file d'attente et récupéré par l'équipe des opérations, à charge pour elle de résoudre le problème avant de remettre le message dans la file d’attente au lieu de solliciter le système à l’infini. Cette modalité est particulièrement importante, car la BBC applique la méthodologie Chaos Monkey développée par les ingénieurs de Netflix pour tester la résilience et les capacités de récupération de leurs services AWS. De sorte que, si une infrastructure est supprimée par Chaos Monkey, le traitement sera exécuté à coup sûr malgré tout.

Le nouveau système intègre également de puissantes fonctions de surveillance et de débogage fournies par Splunk tournant au-dessus d'AWS, qui permettent de suivre les messages sur le système et repérer les problèmes dans chaque microservice sans avoir à éplucher les 300 logs individuels. « C’est beaucoup plus facile de voir ce qui se passe et de savoir combien de programmes nous pouvons traiter à l’heure, par exemple », a déclaré Stephen Goodwin.

Les avantages des microservices

Dans l'ensemble, le passage aux microservices a été un succès incontestable pour la BBC, l'extensibilité et la résilience représentant les avantages les plus évidents. Cela signifie également que le système est plus facilement extensible. En guise d’illustration, l’architecte en chef a évoqué l’intégration des services de radio, auparavant séparés, dans iPlayer. « Il est facile d’ajouter des fonctions supplémentaires », a-t-il déclaré. Les microservices permettent également de réduire les temps de déploiement. L'équipe d’iPlayer procède désormais à la mise en ligne continue de programmes avec l'architecture de microservices.

« Nous disposons aujourd’hui de l'outil nécessaire pour appliquer un changement en 15 minutes, et chaque semaine l’équipe de développement, 30 personnes au total, effectue 32 déploiements en direct », a déclaré Stephen Goodwin. À la grande satisfaction des téléspectateurs et auditeurs de la BBC. « Si nous possédons les droits d’un programme, nous le mettons en ligne », a déclaré l’architecte en chef. Dès le passage à l’architecture de microservices, la chaîne britannique a pu augmenter de 100 % la quantité de ses contenus sur iPlayer.