AWS Lambda : l'approche de Babbel pour la montée de version

En parallèle d’un upgrade du runtime Node.js, Babbel a basculé vers une nouvelle version du SDK AWS. Comment s’y est-il pris ?

Comment gérer la montée de version du runtime et du SDK ? Babbel s’est retrouvé face à cette situation dans le cadre de son usage de Lambda.

L’événement déclencheur : la fin de la prise en charge de Node.js 14. L’objectif était de migrer vers la v18. Et, par la même occasion, d’abandonner la v2 du SDK AWS pour passer sur la v3.

La démarche s’est faite en deux temps : d’abord le runtime, puis le SDK.

Node.js 18 étant livré par défaut avec la v3 du SDK, Babbel a dû inclure la v2 dans son build. Cela a garanti une continuité de service, mais le temps moyen d’exécution des fonctions a augmenté, passant de 22 à 38 ms.

Principale cause : la taille du bundle. Un paramètre très influent sur le démarrage à froid des fonctions Lambda. Plus, notamment, que la quantité de mémoire disponible, la région d’exécution ou le jeu d’instructions.

Dans ce contexte, il a été décidé d’augmenter la RAM allouée (passage de 192 à 256 Mo). Cela a relevé le plafond d’usage CPU autorisé de 10,8 % à 14,4 %. Le temps d’exécution moyen est alors redescendu, s’établissant à 28 ms.

Le passage à la v3 du SDK a permis de ne sélectionner que les packages nécessaires – en l’occurrence, client-dynamodb et lib-dynamodb. En utilisant les dépendances dev, Babbel a pu réduire la charge utile à moins de 2 Mo… et le temps d’exécution à 5 ms.

À consulter en complément :

Comment Slack a modernisé le suivi de sa flotte AWS EC2
Le serverless et ses limites : l’expérience d’un éditeur SaaS
Miro a abandonné AWS Lambda pour l’acquisition client
Amazon Prime Video a-t-il basculé du serverless au monolithe ?

Lire aussi : Le serverless et ses limites : l’expérience d’un éditeur SaaS