Amélioration des démarrages à froid à l’aide de Lambda SnapStart | de Haiko van der Schaaf | décembre 2022

AWS Lambda SnapStart a-t-il un sens ?

L’adoption de Java pour AWS Lambda a pris du retard par rapport à Node.js et Python. Et pour de bon raison. Java, en tant que langage compilé, a un terrible démarrage à froid. Est-ce que le récemment annoncé SnapStart d’AWS Lambda pour Java à l’année AWS re:Invent atténuer cette caractéristique indésirable ?

Dans cet article, je prends la construction récente API REST sans serveur avec Java et Spring pour un essai routier avec AWS SnapStart pour regarder derrière la couverture de l’annonce.

L’affirmation est que l’activation des fonctions Lambda SnapStart pour Java peut les faire démarrer 10 fois plus rapidement sans frais supplémentaires. Mais comment cela fonctionne-t-il ?

Pour cela, nous devons examiner le cycle de vie de l’environnement d’exécution Lambda.

Sur un déclencheur, la fonction Lambda passe par différentes phases. La première est la phase INIT. Lorsque vous activez Lambda SnapStart, Lambda enregistre un instantané de l’état de la mémoire et du disque de l’environnement d’exécution initialisé résultant de la phase INIT et l’utilise pour les fonctions SnapStart.

Noter: Vous ne pouvez utiliser SnapStart que sur les versions publiées et les alias qui pointent vers des versions. Vous ne pouvez pas utiliser SnapStart sur une fonction version non publiée ($LATEST).

Lorsque vous invoquez pour la première fois un SnapStart fonction, et à mesure que la fonction évolue, Lambda reprend de nouveaux environnements d’exécution à partir de l’instantané persistant au lieu d’initialiser la fonction à partir de zéro. Cela devrait économiser un temps de démarrage considérable avec l’environnement Java Runtime.

Avant de creuser dans les gains de performances, je veux d’abord vous montrer comment vous pouvez activer SnapStart pour votre fonction Java AWS Lambda. La condition préalable est que la fonction Java Lambda utilise l’environnement d’exécution Java 11 (Corretto).

Comme les images peuvent dire plus que mille mots, j’ai fait le screencast suivant sur la façon dont vous pouvez activer SnapStart via la console AWS.

Une autre façon d’activer SnapStart consiste à l’ajouter au modèle SAM et à déployer la fonction AWS Lambda.

Assurez-vous de préciser PublishedVersions pour le ApplyOn propriété et publier une version.

Les performances gagnent

Maintenant que nous savons ce qu’est Lambda SnapStart et comment nous pouvons l’activer, examinons ce que propose Lambda SnapStart. J’ai fait deux demandes de démarrage à froid sur le bibliothèque en ligne fonction Java Lambdaun pré-SnapStart et un sur une version publiée avec Lambda SnapStart activé.

Les journaux cloudwatch pour la demande de démarrage à froid pré-SnapStart indiquent une durée d’initialisation de plus de 3 secondes, 3111,32 ms.

Si nous comparons cela aux journaux cloudwatch de la version SnapStart, nous constatons quelques différences. Il n’y a pas de « durée d’initialisation ». Au lieu de cela, il y a la «durée de restauration» de 469,23 ms. Il s’agit du temps nécessaire pour restaurer l’instantané créé en publiant la fonction Lambda.

En comparant la durée d’initialisation à la durée de restauration, nous constatons une augmentation de 6,6 fois des performances de démarrage. Pas mal!

Comme d’habitude, avec chaque solution, il y a aussi des inconvénients et des limitations. Pour l’instant, seul le runtime Java 11 est pris en charge.

Dans les journaux cloudwatch ci-dessus, vous pouvez voir que l’ID de trace XRay n’est pas présent pour la version SnapStart. Cela est dû au manque de prise en charge d’AWS XRay. De plus, Lambda SnapStart ne prend pas en charge simultanéité provisionnéela architecture arm64la API des extensions Lambda, Amazon Elastic File System (Amazon EFS)ou stockage éphémère supérieur à 512 Mo.

De plus, les démarrages à froid avec Lambda SnapStart sont un peu plus chers. Dans cet exemple, la durée facturée pour la version SnapStart est plus élevée, 803 ms contre 494 ms, soit une augmentation considérable de 63 %.

AWS Lambda SnapStart tient sa promesse d’accélérer les performances de démarrage des fonctions Java Lambda et doit être considéré comme une amélioration bienvenue pour quiconque crée des fonctions AWS Lambda avec Java. Il y a quelques mises en garde à garder à l’esprit lors de l’utilisation de Lambda SnapStart.

Donc, cela conclut. J’espère que cela vous aidera dans vos voyages sans serveur.