Si les microservices sont à la mode, ils ne sont pas forcément la réponse à tout. Dans un article de blog détaillé, une équipe de Prime Video, qui développe un service pour suivre la qualité des flux vidéo visionnés en live par les clients relate son parcours à contre-courant. En effet, l'équipe est passée d'une architecture initiale fortement distribuée, basée sur des microservices et du serverless, à une approche plus monolithique.

Le service d'analyse de la qualité comporte trois composants principaux : des convertisseurs média, qui transforment les flux vidéo en images et en buffers audio ; des détecteurs qui analysent ces éléments en temps réel afin d'identifier des défauts et enfin une couche d'orchestration. L'outil initial avait été développé avec des composants distribués, exécutés dans la plateforme serverless d'AWS, Lambda, et orchestrés avec les Step Functions. « Un bon choix pour aller vite », selon Marcin Kolny, ingénieur développement logiciel senior chez Prime Video et auteur de l'article. Mais cette architecture s'est révélée mal adaptée lorsqu'il a fallu passer à l'échelle et surveiller la qualité de milliers de flux en parallèle. « En théorie, ce modèle permet de faire évoluer chaque composant du service de manière indépendante. Cependant, la manière dont nous avons utilisé certains composants nous a fait atteindre un plafond à environ 5 % de la charge prévue », confie l'auteur. L'architecture posait en particulier deux problèmes : d'une part, la montée en charge s'avérait très coûteuse ; d'autre part, le service rencontrait des goulets d'étranglement.

Le principal blocage se situait dans la couche d'orchestration : le service exécute de très nombreuses transitions d'état par seconde, ce qui conduit rapidement à atteindre la limite prévue pour le compte utilisateur. En outre, ce service est facturé en fonction du nombre de changements d'état. Un autre problème concernait la façon de passer les images issues des vidéos d'un composant à l'autre du service. Pour éviter des tâches de conversion vidéo coûteuses en termes de performance au sein du service principal, celles-ci étaient déléguées à un microservice à part, qui stockait les images résultantes dans un bucket S3 de façon temporaire. Mais cela entraînait un grand nombre d'appels vers S3 depuis le service principal, ce qui était financièrement coûteux.

D'une scalabilité horizontale à verticale

Constatant que dans ce cas précis, une approche distribuée n'apportait pas vraiment les bénéfices attendus, l'équipe a pris le parti de revoir l'architecture, en regroupant tous les composants dans un seul processus, mais en gardant le même découpage fonctionnel (ce qui a permis de reprendre une grande partie du code). De cette façon, le recours à un bucket S3 pour le stockage intermédiaire des images n'est plus nécessaire. Par ailleurs, la façon dont est gérée la montée en charge a changé. Précédemment, elle se faisait de façon horizontale, l'ajout de détecteurs nécessitant de créer de nouveaux microservices branchés sur la couche d'orchestration. Désormais, elle s'effectue de façon verticale : l'équipe a créé plusieurs clones de son service, hébergés dans des conteneurs ECS sur des instances EC2. Lorsque la capacité maximale d'une instance est atteinte, les requêtes des clients sont dirigées vers un autre clone, grâce à une couche d'orchestration légère. Autre avantage, elle peut ainsi bénéficier des plans d'économies proposés avec AWS EC2.

En repensant son architecture, l'équipe a réduit ses coûts d'infrastructure de 90%. Les changements effectués lui permettent aussi de surveiller la qualité sur tous les flux vidéo, là où précédemment elle se concentrait sur ceux avec le plus de spectateurs, en raison des plafonds. De cette expérience, Marcin Kolny conclut, pragmatique : « Les microservices et les composants serverless sont des outils qui fonctionnent à grande échelle, mais le choix de les utiliser plutôt qu'un monolithe doit être étudié au cas par cas. »