Amazon Prime Video a-t-il basculé du serverless au monolithe ?

Des microservices valent-ils toujours mieux qu'un monolithe ? La question n'a rien de nouveau, mais le cas de Prime Video alimente la réflexion.

L'équipe tech chargée de cette offre chez Amazon a récemment fait le point sur l'évolution d'un de ses outils. En l'occurrence, celui qui lui permet d'analyser la qualité des flux.

Cet outil, nous explique-t-on, n'était initialement pas conçu pour une exploitation à grande échelle (et ce n'en était pas l'objectif). Lorsque le volume de flux à analyser est devenu trop important, il a fallu réarchitecturer.

Trois grandes briques composent l'outil. La première convertit les flux en images et en tampons audio. La deuxième examine ces éléments à renfort d'algorithmes et envoie une notification en cas de problème. Et la troisième orchestre le processus.

La version d'origine suivait une approche « serverless-first » : Step Functions coordonnait des fonctions Lambda. Dans la pratique, le système a vite atteint un goulet d'étranglement - à environ 5 % de la charge attendue. Tout en occasionnant des coûts importants sur deux postes en particulier : l'orchestration et la communication entre microservices.

Tel qu'implémenté, l'outil multipliait les transitions d'état, ce qui faisait exploser la facture Step Functions. C'était sans compter le mécanisme de stockage intermédiaire mis en place à l'appui de S3. Pour réduire les tâches de conversion coûteuses en ressources de calcul, l'équipe Prime Video avait effectivement développé un microservice qui découpait les flux et les entreposait temporairement dans un bucket. Sauf qu'avec la multiplication du nombre de requêtes en provenance de la brique d'analyse, la facture S3 a là aussi... explosé.

Prime Video : les microservices en surcharge

Luca Bianchi, CTO de Neosperience et par ailleurs évangéliste AWS Serverless, note que l'équipe Prime Video n'explique pas ce qui a(urait) pu l'empêcher d'exploiter d'autres solutions de stockage comme EFS, facturée non pas au nombre d'appels, mais à l'usage. Il rappelle surtout les risques de surcharge que peuvent impliquer les architectures de microservices.

Nombre de pairs lui ont fait écho. Illustration avec Lambros Petrou, de Datadog. Son constat, dans les grandes lignes : les architectures distribuées sont peu aux tâches gourmandes en ressources de calcul.

The solution of the post was badly architected from the beginning. It was designed to be inefficient.
They could just bundle up processing in less Lambda functions, with less Step Functions orchestration, and still get a nice boost.

But no, let's scrap it because of servers.

- Lambros Petrou (@LambrosPetrou) May 5, 2023

Le choix initial d'une architecture orientée serverless peut s'expliquer par un manque de visibilité sur l'évolution des fonctionnalités de la solution. Et par là même de ses exigences. L'équipe Prime Video aurait donc privilégier une capacité à itérer rapidement.

Au final, elle se retrouve avec une tâche ECS unique. Finie l'analyse distribuée, toutes les briques sont relocalisées dans un processus. Les transferts se font en mémoire, éliminant la nécessité de stockage S3. L'orchestration est simplifiée en parallèle, au sein d'une même instance. Et il devient possible d'exploiter les plans d'économies (Savings Plans) d'EC2.

Ce basculement a permis d'économiser « 90 % en coûts d'infrastructure », tout en réutilisant beaucoup de code. Mais l'équipe Prime Video a-t-elle vraiment, comme elle le déclare, basculé des microservices au monolithe ? La formulation fait débat.

Adrian Cockroft est un ancien d'AWS, où il occupait le poste de directeur de la stratégie architecture cloud. Pour lui, l'équipe Prime Video n'a en aucun cas créé un monolithe. Elle a simplement optimisé son application serverless en combinant des services au sein d'un conteneur autoévolutif. Une pratique que l'intéressé dit recommander depuis des années (cf. vidéo ci-dessous).

Illustration principale © CDPiC - Adobe Stock