Devriez-vous utiliser la simultanéité provisionnée pour les fonctions AWS Lambda ?

Les fonctions Lambda sont un élément crucial de tout déploiement sans serveur sur Amazon Web Services. Cependant, ils ne sont pas magiques et peuvent présenter quelques inconvénients, comme les démarrages à froid, en raison des limitations physiques du matériel. La simultanéité provisionnée peut aider à atténuer le problème.

Que sont les « démarrages à froid » ?

Les « démarrages à froid » sont un gros problème pour Lambda, en particulier lorsqu’ils sont envisagés pour une application sensible à la latence. Le terme fait référence au temps de démarrage nécessaire pour que l’environnement d’exécution d’une fonction Lambda soit opérationnel à partir de zéro.

Les fonctions Lambda seront maintenues « au chaud » pendant un certain temps après leur appel. Les fonctions non-VPC seront chaudes pendant 5 minutes et les fonctions VPC seront chaudes pendant 15 minutes. Pendant cette période, si la fonction est appelée à nouveau, elle répondra immédiatement. C’est idéal pour les services qui connaissent un trafic constant et régulier.

Cependant, si votre code ne s’est pas exécuté depuis un certain temps, ou s’il doit être mis à l’échelle et exécuter plusieurs fonctions simultanées, il sera démarré à partir de zéro. Selon l’analyse d’AWS, les démarrages à froid se produisent dans moins de 1 % des demandes dans les charges de travail de production, ce qui est acceptable pour de nombreux scénarios.

Cependant, selon l’environnement d’exécution que vous utilisez (Java et .NET prennent tous deux un certain temps pour compiler JIT), un démarrage à froid peut retarder l’invocation de la fonction de plusieurs secondes. Cela peut être inacceptable pour les applications sensibles à la latence.

Fini les démarrages à froid

Le mode de simultanéité provisionnée de Lambda peut aider à résoudre ce problème. Vous pouvez le considérer comme des instances réservées pour les fonctions Lambda : vous réservez essentiellement une certaine quantité de capacité et une fonction Lambda sera maintenue au chaud pendant toute la période.

Cela présente des avantages majeurs, notamment la suppression presque complète des coûts de démarrage. En fait, vous n’aurez pas du tout à vous soucier de l’optimisation du code d’initialisation, car il s’exécutera une fois et continuera à s’exécuter. Il s’agit d’un avantage majeur pour les langages compilés JIT comme Java et C#/.NET, qui peuvent avoir des fichiers binaires volumineux et des temps de démarrage pour les charger.

Par rapport à l’exemple précédent, où les fonctions sont démarrées à froid, la simultanéité provisionnée les démarre toutes à l’avance et les maintient au chaud. Lorsqu’un appel est nécessaire, Lambda utilise les fonctions warm pour l’exécuter.

Cependant, il vient avec ses propres inconvénients. En raison de la manière dont Lambda sélectionne les versions des fonctions, la simultanéité provisionnée ne fonctionne pas avec la balise $LATEST. Vous devrez créer un nouvel alias, provisionner la simultanéité pour cet alias, puis le mettre à jour lorsque la version changera.

Il est également important de comprendre que malgré l’exécution de la fonction pendant de longues périodes, la simultanéité provisionnée ne rend pas votre application avec état. Les fonctions Lambda peuvent et seront détruites, et vous ne devez pas les traiter comme un serveur EC2.

Combien coûte la simultanéité provisionnée ?

La réponse dépend de la fréquence d’exécution de votre fonction et de la fréquence à laquelle vous voyez plusieurs environnements d’exécution créés pour répondre à une demande parallèle.

Le nombre principal à prendre en compte pour la simultanéité provisionnée est le nombre d’exécutions de fonctions exécutées en même temps. Par exemple, si vous avez une fonction appelée dix fois par seconde et que chaque appel dure 500 ms, cette fonction aura en moyenne 5 exécutions simultanées par seconde.

Dans l’ensemble, la simultanéité provisionnée ne coûte pas beaucoup plus cher que les fonctions Lambda classiques. Vous pouvez utiliser le calculateur de tarification d’AWS pour déterminer combien cela vous coûtera personnellement. Par exemple, un Lambda appelé 10 fois par seconde, avec un temps d’invocation de 500 ms et 256 Mo de mémoire coûtera 60 $ par mois pour fonctionner.

Cependant, cette même fonction, mais avec 10 exécutions provisionnées, revient un peu plus à 64,50 $ par mois. Dans l’ensemble, il s’agit probablement d’une petite augmentation de 5 à 10 % du coût, selon l’utilisation.

Cependant, la simultanéité provisionnée est en fait moins chère par Go-seconde d’utilisation. Cela signifie que si vous utilisez constamment une utilisation très proche de 100 %, il peut être moins coûteux de réserver la simultanéité que d’utiliser la tarification Lambda standard. Cela se résume en grande partie au fait qu’il est globalement moins coûteux de réduire le temps que les Lambda passent dans le code d’initialisation.