Re:Invent 2022 : les nuances de serverless chez AWS
Lors de Re:Invent 2022, AWS a lancé Lambda SnapStart et OpenSearch Serverless, deux services dits serverless. Le fournisseur explore les capacités du concept, quitte à maintenir une forme de confusion chez les développeurs.
Au premier jour de la conférence annuelle, Peter DeSantis, directeur général EC2 chez AWS, a présenté l’architecture sous-jacente pour exécuter les fonctions Lambda. En l’occurrence, le fournisseur met à disposition un pool d’instances EC2 T2 qui agit comme une « couche de cache de calcul » multitenant. Le tout est piloté depuis Amazon Firecracker, un hyperviseur de microVMs établi sur les capacités de KVM. Une fonction est assignée à une instance EC2 T2 le temps qu’elle s’exécute dans un environnement isolé.
Chaque environnement répond au même cycle de vie. Celui-ci est divisé en trois phases : Init, Invoke et Shutdown. Lors de la phase d’initialisation, Lambda lance toutes les extensions, démarre le runtime, les fonctions de code statique. Dans la phase d’invocation, Lambda répond à une requête API « NEXT », afin d’accomplir une tâche. À ce moment-là, Lambda envoie un événement Invoke au runtime et à chaque extension. Il est possible de paramétrer un délai d’attente pour l’exécution de la fonction. La dernière phase, Shutdown, implique l’arrêt de la microVM en moins de deux secondes.
Lambda : AWS optimise le démarrage à froid des fonctions Java
Pour que les microVMs se lancent à la vitesse requise, AWS doit habituellement faire en sorte d’allouer plus de ressources de calcul que n’en réclame la fonction.
Une fois exécutées, les métadonnées de la fonction demeurent dans le cache du pool d’instances pendant une durée limitée, ce qui permet de l’exécuter plus rapidement par la suite.
Or, cette première exécution peut poser un problème. En temps normal, cette phase se produit en quelques millisecondes, mais sa durée peut varier en fonction du langage de programmation et de la fonction encapsulée.
Ce problème est communément appelé « cold start » ou démarrage à froid. C’est un problème identifié de longue date. Or, la modernisation de l’écosystème Java semble générer un besoin supplémentaire. SpringBoot et Quarkus, portés par VMware et Red Hat, sont de plus en plus populaires.
En l’occurrence, le lancement des fonctions Java qui utilisent SpringBoot, Quarkus ou Micronaut – des frameworks censés simplifier et accélérer le déploiement de microservices Java – peut prendre jusqu’à 10 secondes. « Cela comprend l’injection de dépendances, la compilation du code de la fonction et l’analyse des composants du classpath », précise AWS. « Ensuite, le code statique peut télécharger certains modèles de machine learning, précalculer certaines données de référence ou établir des connexions réseau avec d’autres services AWS », ajoute le fournisseur.
Lambda est facturé à la milliseconde suivant la quantité de mémoire et du volume de stockage éphémère utilisés. Une fois que l’appel de fonctions serverless est généralisé, cela peut créer un problème de performance, et potentiellement de coût.
SnapStart : micro snapshot pour microVM
Pour éviter ces effets contre-productifs, AWS a donc décidé d’ajouter une nouvelle étape dans le cycle d’un environnement Lambda. Intitulée Lambda SnapStart, cette nouvelle étape consiste à créer un snapshot de la mémoire et de l’état du disque pour le mettre en cache plus tard. L’état peut être retrouvé au moment d’invoquer la fonction pendant 14 jours. La phase Init n’est plus nécessaire pour certaines fonctions Java qui utilisent le runtime Corretto de Java 11. L’exécution des fonctions Lambda serait ainsi dix fois plus rapide.
Cet instantané peut être repris par plusieurs microVM. Cependant, cela implique d’adapter le code de la fonction.
Il faut maintenir l’unicité du contenu d’une fonction : le contenu, auparavant généré après l’initialisation, doit maintenant l’être après cette phase. « Il s’agit notamment des identifiants uniques, des secrets uniques et de l’entropie utilisée pour générer un nombre pseudo-aléatoire », renseigne la documentation.
Les développeurs devront aussi s’assurer que les connexions à long terme aux services réseau, pendant la phase Init, qui sont utilisées lors d’une invocation, puissent être rétablies. Il faut vérifier que les informations de référence calculées ou téléchargées lors de la phase d’Init sont encore valables au moment de la mise en cache.
AWS assure toutefois avoir pris des mesures pour éviter les potentiels désagréments. « Lambda fournit une paire de crochets d’exécution pour vous aider à maintenir l’unicité, ainsi qu’un outil d’analyse pour aider à détecter les problèmes éventuels ».
Pour l’instant, SnapStart n’est disponible que pour Java 11.
« Les gains les plus évidents sont liés au code Java et aux frameworks associés », estime Sébastien Stormacq, developer advocate chez AWS auprès du MagIT. « Mais je ne vois pas pourquoi SnapStart ne serait pas adapté à d’autres langages ».
Cependant, le developer advocate observe que les gains de performance seront moins importants pour les fonctions Python ou JavaScript, par exemple.
En outre, Amazon Inspector, un outil de scan de vulnérabilités, est désormais capable d’analyser le code des fonctions écrites en Java, NodeJS et Python. Le service peut être lancé avant de déployer une fonction, à sa mise à jour ou quand un nouveau CVE (Common Vulnerabilities & Exposures) est porté à la connaissance d’AWS. Inspector visite également les couches tierces (c’est-à-dire les librairies utilisées pour déclencher cette fonction) appelées lors d’une invocation.
Voilà pour les Functions as a Service (FaaS). En outre, AWS entend simplifier l’administration des services de gestion de données. « Nous avons maintenant des options serverless pour toutes les offres d’analytique d’Amazon », s’est réjoui Adam Selipsky, PDG d’AWS.
OpenSearch Serverless porterait mal son nom
L’année dernière, AWS avait annoncé la disponibilité de modes « serverless » pour Quicksight, Glue, Amazon EMR, MSK et RedShift. Lors de ReInvent 2022, il a présenté la préversion mode similaire pour Amazon OpenSearch.
Pour rappel, OpenSearch est originellement un fork d’Elasticsearch 7.10 mis en place quand Elastic, le contributeur principal du projet open source éponyme, a décidé de changer de licence en passant d’Apache 2.0 au modèle SSPL. Cette préversion serverless OpenSearch vise à prouver qu’il est possible de simplifier la gestion du moteur de recherche.
« Avec OpenSearch Serverless, vous créez une collection, qui gère un groupe d’index fonctionnant ensemble pour prendre en charge une charge de travail spécifique. »
Channy YunPrincipal developer advocate, AWS
« Auparavant, vous créiez un cluster managé, en spécifiant les types d’instances, leurs nombres et les options de stockage, puis vous gériez le cycle de vie et la stratégie des shards pour les index au sein de ce cluster », indique Channy Yun, Principal developer advocate chez AWS. « Avec OpenSearch Serverless, vous créez une collection, qui gère un groupe d’index fonctionnant ensemble pour prendre en charge une charge de travail spécifique ».
Tout comme Elastic, le fournisseur sait très bien à quel point la gestion de cluster de cette technologie peut s’avérer complexe. Pour autant, si le service impose par défaut la configuration d’une politique de chiffrement et de gestion du VPC, Channy Yun prévient qu’il n’est pour l’instant pas adapté pour les cas d’usage réclamant un contrôle spécifique des shards. La documentation est bien plus précise : cette option « serverless » est pensée pour « les charges de travail peu fréquentes, intermittentes ou imprévisibles ».
Comme OpenSearch Serverless ne prend en charge actuellement que les tiers de stockage chaud et tiède – performants, mais plus coûteux –, il semble peu probable que le service soit utilisé à des fins d’analyses ou d’audits de sécurité pourtant intermittents et peu fréquents. Malgré tout, AWS assure que la solution est économiquement efficace, hautement disponible et scalable. De ce que comprend LeMagIT, OpenSearch Serverless paraît être un moyen de motoriser la recherche sur un site d’e-commerce en période de soldes.
Ici, AWS facture séparément le calcul du stockage. Le calcul est mesuré en OCU (OpenSearch Compute Unit). Ces OCU correspondent aux ressources CPU, RAM, EBS et I/O utilisées pour indexer ou interroger les données. Le fournisseur facture au moins quatre OCU par mois pour exécuter le service 24 heures sur 24 et sept jours sur sept. OpenSearch Serverless coûterait a minima 691 dollars par mois.
Ben Kehoe, chercheur chez le fabricant de robots aspirateurs iRobot, reconnu comme un « serverless heroe » par AWS, réagit à l’ambiguïté de l’appellation, sans douter de l’utilité du service. « Pour OpenSearch, “serverless” signifie principalement “autoscaling” », écrit-il sur twitter. « Vous êtes facturé pour un proxy pour un nombre minimum de quatre OCU. L’autoscaling est utile ! Et il n’est pas très surprenant que ce ne soit pas plus serverless que ça ».
Dans l’idée des utilisateurs, le serverless implique un arrêt total des instances au repos : cela semble impossible à obtenir pour une technologie qui repose en grande partie sur la persistance des données. OpenSearch Serverless semble donc être un service entièrement managé, comme le propose la startup finlandaise Aiven.
