Dans le cadre d'une série d'annonces, présentant les nouveautés apportées à son infrastructure cloud AWS, depuis la semaine dernière, Amazon a annoncé mardi que AWS Lambda fait désormais passer la granularité de facturation pour la durée de la fonction Lambda de 100 ms à 1 ms. Le leader mondial des services de cloud computing estime que ce changement devrait permettre de réduire le prix de la plupart des fonctions Lambda, surtout pour les fonctions de courte durée. Leur durée de calcul sera facturée par incréments de 1 ms au lieu d'être arrondie à l'incrément de 100 ms le plus proche par appel.AWS Lambda est une plateforme d'informatique sans serveur, pilotée par des événements, fournie par Amazon dans le cadre de son offre cloud Amazon Web Services. Il s'agit d'un service informatique qui exécute un code en réponse à des événements et gère automatiquement les ressources informatiques requises par ce code. Il a été introduit en novembre 2014. L'objectif de AWS Lambda, par rapport à AWS EC2 (Elastic Compute Cloud), est de simplifier la construction d'applications à la demande plus petites, qui répondent aux événements et aux nouvelles informations.
AWS vise à lancer une instance Lambda dans les millisecondes suivant un événement. Node.js, Python, Java, Go, Ruby, et C# (via le noyau .NET) sont officiellement pris en charge depuis 2018. Un support d'exécution personnalisé a ensuite été ajouté à AWS Lambda, donnant aux développeurs la possibilité d'exécuter un Lambda dans le langage de leur choix. AWS Lambda supporte l'exécution sécurisée d'exécutables Linux natifs en faisant appel à un runtime pris en charge, tel que Node.js. Par exemple, le code Haskell peut être exécuté en Lambda. Mardi, AWS Lambda a annoncé l'arrivée de la tarification à la milliseconde, dont en voici quelques détails.
Fonction Lambda : qu'est-ce que c'est ?
Une fonction Lambda est un logiciel d'application qui s'exécute dans un conteneur de courte durée pour répondre à une demande ou un événement unique. Bien que l'utilisation du terme "fonction" puisse suggérer que le code doit être constitué d'une seule fonction, les fonctions Lambda sont des processus réguliers qui peuvent aussi, par exemple, engendrer des processus enfants. Elles doivent être conformes à une interface spécifique, mais peuvent aussi contenir un code arbitraire. Chaque fonction Lambda peut être "dimensionnée" en définissant le paramètre de taille mémoire maximale (Go) dans la console Lambda ou en utilisant l'API.
Cette valeur affecte également les parts de CPU allouées à la fonction lorsqu'elle est exécutée, mais d'une manière qui n'est pas actuellement divulguée par AWS. En outre, Lambda permet également de limiter la durée maximale d'exécution d'une fonction (en secondes), afin d'éviter que les fonctions en fugue ou en suspens n'entraînent une augmentation des coûts. Étant donné que les fonctions Lambda ne s'exécutent que lorsqu'une demande doit être traitée, elles n'entraînent des frais que lorsqu'elles sont utilisées.
Le modèle général de tarification adopté par les fournisseurs FaaS (Function as a Service) sans serveur est basé sur deux critères par appel de fonction :
- la taille maximale de la mémoire (Go) : il ne s'agit pas de la mémoire réellement utilisée par la fonction, mais plutôt du paramètre de taille maximale de la mémoire dans la configuration de la fonction Lambda. Si vous réduisez l'utilisation de la mémoire de votre fonction, mais que vous n'ajustez pas ce paramètre de configuration en conséquence, vous ne constaterez pas de réduction de coût par rapport à l'utilisation réduite de la mémoire ;
- le temps d'exécution de la fonction (secondes) : le temps réel d'horloge (murale) que l'appel de la fonction a pris pour s'exécuter. Si une fonction Lambda effectue un appel réseau sortant et reste inactive en attendant le résultat, le temps passé à être inactive est quand même compté dans le temps d'exécution de la fonction, c'est-à-dire que ce n'est pas une mesure de l'utilisation du CPU.
Pour chaque invocation de fonction, ces deux valeurs sont multipliées ensemble pour produire un nombre avec l'unité Go-sec (Go-secondes). Après avoir tenu compte d'une allocation mensuelle de Go-sec gratuite du niveau gratuit, le coût de calcul facturable est le total de Go-sec pour toutes les invocations de fonction, multiplié par un taux de Go-sec fixe. Ce taux fixe est actuellement de 0.00001667 dollar pour AWS Lambda.
AWS Lambda : comment fonctionne la tarification des fonctions ?
Pour beaucoup, l'introduction de la tarification à la milliseconde dans AWS Lambda est un changement majeur dans l'industrie qui modifie fondamentalement le coût de fonctionnement de nombreuses applications sans serveur. Comme mentionné ci-dessus, la tarification Lambda comporte deux dimensions : les demandes et la durée. Une demande est faite chaque fois qu'une fonction est appelée et elle est facturée 0,20 dollar par million de demandes, quelle que soit la taille de la fonction. La durée est calculée comme un facteur de temps et d'utilisation de la mémoire à 0,0000166667 dollar par Go-sec.
Il existe également une allocation gratuite "Free Tier" d'un million de requêtes et jusqu'à 400 000 Go/s de calcul chaque mois. C'est-à-dire que vous n'êtes pas facturé pour toute utilisation de Lambda inférieure à ce niveau. Toutefois, notez que, comme le Go-sec est une unité composite, il peut être difficile de raisonner à son sujet. Par exemple, chaque invocation peut devoir démarrer un runtime de langage et charger des bibliothèques tierces avant d'arriver au code utilisateur, ce qui augmente le runtime facturable de la fonction pour chaque invocation.
Avant l'annonce des changements mardi, la durée minimale de facturation était de 100 ms (millisecondes) et la durée facturable était toujours arrondie à la centaine de ms supérieure (ou le multiple de 100 immédiatement supérieur à la durée d'exécution de la fonction). Prenons un petit exemple pour illustrer la chose. Avant la nouvelle facturation, une fonction avec une durée de 5 ms était arrondie à 100 ms et une fonction avec une durée de 385 ms était arrondie à 400 ms. Mais avec le passage à la facturation à 1 ms, la plus petite valeur de durée est désormais de 1 ms et toute autre utilisation est arrondie à la milliseconde supérieure.
Dans un autre exemple, une fonction avec une durée d'exécution de 30 ms était facturée comme une fonction qui prenait 100 millisecondes. Désormais, elle sera facturée pendant 30 ms, ce qui entraînera une baisse de 70 % de la durée de sa dépense. Selon AWS, ce changement rendra des fonctions telles que l'appel Web interactif et la diffusion de données en continu, qui ont tendance à avoir des durées courtes, encore plus rentables à exécuter sur Lambda. La granularité de la tarification ou de la facturation pour les demandes ou la simultanéité provisionnée ne changera pas.
En outre, ce changement n'aura pas d'impact sur la façon dont les demandes Lambda et "Provisioned Concurrency" sont facturées aujourd'hui. Il n'a pas non plus d'impact sur l'expérience client via la console de gestion AWS, le CLI AWS ou les SDK. Selon AWS, ce changement sera effectif à partir du cycle de facturation de décembre 2020. La granularité de facturation de 1 ms est disponible pour les fonctions Lambda dans toutes les régions où le Lambda AWS est disponible, sauf dans les régions de Chine, à partir du cycle de facturation de décembre 2020.
De 100 ms à 1 ms : quelle est la différence de coût pour le code existant ?
AWS Lambda est conçu pour des volumes de trafic très élevés et de nombreuses applications basées sur la production donnent lieu à des millions d'invocations. Ainsi, cette modification de la granularité de la durée devrait permettre de réaliser des économies pour presque toutes les fonctions Lambda, une chose qui devrait se manifester automatiquement sur votre relevé de facturation AWS. Pour illustrer l'impact de ce changement dans la tarification pour différentes durées de fonctions, James Beswick de "A Cloud Guru" compare trois types de fonctions Lambda à savoir :
- les fonctions de courte durée de vie (~100 ms) : ces fonctions fonctionnent généralement comme de la "colle", en traitant un minimum de données entre les services AWS ;
- les fonctions sous-seconde (moins d'une seconde) : pour une logique commerciale plus compliquée traitant plus de données ;
- les fonctions à plus longue durée de vie (moins d'une minute) : pour les logiques complexes sur le plan informatique, ou les fonctions appelant de manière synchrone des services tiers.
Sa comparaison montre que le passage à la durée facturable a le plus d'impact sur le coût de fonctionnement des fonctions de courte durée, avec jusqu'à 67 % de durées facturables plus courtes. Pour les fonctions secondaires, la comparaison montre une baisse de 10 % de la durée moyenne, alors qu'elle a moins d'impact pour les fonctions à longue durée de vie. Cependant, en pratique, dans la plupart des charges de travail de production, les fonctions Lambda sont de courte durée, ce qui offre de bonnes possibilités d'optimisation.
Optimisation : relation et équilibre entre mémoire, coût et durée
Selon Beswick, l'un des principaux leviers de configuration dont vous disposez en tant que développeur Lambda est la mémoire. Vous pouvez régler la mémoire allouée de 128 Mo à 10 Go par incréments de 64 Mo. Cependant, la mémoire contrôle aussi la quantité de CPU virtuels disponible pour votre fonction, allant d'un pourcentage d'un seul cœur à 128 Mo à 6 CPU virtuels complets à la mémoire maximale. Pour de nombreuses fonctions de calcul intensif, l'augmentation de la mémoire réduit la durée totale. Cela signifie que vous pouvez obtenir une fonction plus rapide avec un impact négligeable sur le coût dans de nombreux cas.
En outre, il estime qu'il existe plusieurs options pour trouver l'équilibre optimal de vos fonctions. Vous pouvez tester manuellement une fonction avec différentes allocations de mémoire pour mesurer l'effet sur la durée, ou vous pouvez utiliser l'outil AWS Lambda Power Tuning. Cet outil permet d'automatiser la recherche de l'équilibre entre la mémoire, la durée et le coût, et de visualiser les résultats. Lorsque la durée minimale de facturation était de 100 ms, il n'y avait aucun gain financier à optimiser les fonctions qui fonctionnaient pendant moins de 100 ms.
Bien que l'augmentation de la mémoire ait pu réduire les millisecondes dans ces cas, le coût global a augmenté en raison de l'utilisation de mémoire supplémentaire et de l'absence de changement de la durée minimale. Cependant, avec la facturation à 1 ms, tout cela change, il vaut maintenant la peine d'optimiser l'efficacité de ces fonctions. Il existe de nombreuses mesures que vous pouvez prendre pour optimiser ces fonctions de courte durée.
Autres optimisations des fonctions de durées inférieures à 100 millisecondes
Beswick estime qu'il y a plusieurs autres facteurs à prendre en compte qui peuvent aider à réduire la durée globale d'une fonction. Votre cas d'utilisation déterminera ceux que vous pouvez appliquer. Tout d'abord, votre choix de durée d'exécution fait une différence. Bien que le service Lambda soit agnostique au temps d'exécution, certains temps d'exécution sont plus rapides à initialiser que d'autres. Pour les fonctions courtes, vous pouvez par exemple envisager d'utiliser des runtimes comme Node.js, Go et Python, qui peuvent généralement s'exécuter plus rapidement.
Ensuite, maintenez la taille de vos paquets de déploiement aussi petite que possible, car les paquets plus volumineux prennent souvent plus de temps à s'initialiser. Vous devez supprimer toute exigence ou importation de bibliothèques qui n'est pas utilisée directement par la fonction. Évitez également les fonctions "monolithiques" qui contiennent plusieurs chemins de code et réduisez votre code autant que possible afin de réduire au maximum la taille du paquet de déploiement. En outre, assurez-vous que tous les objets globaux qui nécessitent une initialisation, comme les connexions aux bases de données, sont définis dans le champ d'application global.
Il s'agit du code en dehors de la fonction de traitement Lambda, également connu sous le nom de code "INIT". Le coût de tout code d'initialisation long est ensuite amorti sur plusieurs invocations si le même environnement d'exécution est invoqué plusieurs fois.
Que retenir des changements introduits dans la tarification Lambda ?
« Avec la nouvelle facturation de 1 ms pour les fonctions Lambda, l'optimisation de la durée du code a un impact direct sur le coût d'exécution des fonctions Lambda. Les fonctions de courte durée peuvent souvent fonctionner beaucoup plus vite avec seulement quelques petites modifications, ce qui se traduit par une baisse des coûts », a déclaré Beswick. L'allocation de mémoire dans Lambda détermine la puissance du processeur de votre fonction. Pour déterminer le compromis optimal entre durée, coût et mémoire, il recommande d'utiliser l'outil de réglage de la puissance AWS.
Le drapeau "Réutiliser la connexion HTTP" peut par exemple vous aider à réduire la latence des fonctions Node.js et vous pouvez l'activer avec une variable d'environnement. Le choix sélectif des parties du SDK AWS à importer peut aussi réduire la durée sans affecter la fonctionnalité de votre logique commerciale.
Sources : AWS Lambda, Analyse de James Beswick
Et vous ?
Que pensez-vous de la nouvelle tarification de AWS Lambda ? Utilisez-vous AWS Lambda ? Si oui, quel est l'impact de ce changement sur vous ou sur votre organisation ?Voir aussi
AWS annonce la prise en charge des images de conteneur, du jeu d'instruction AVX2 et une tarification à la milliseconde Utilisez les instances Mac d'Amazon EC2 pour créer et tester des applications macOS, iOS, ipadOS, tvOS et watchOS. Le service est disponible sur de véritables Macs mini au prix de 25,99 $ par jour Amazon Web Services veut séduire les développeurs avec Lambda pour l'exécution d'applications dans le Cloud et Aurora, un MySQL puissant AWS présente Proton, le service de gestion des conteneurs pour automatiser le développement et le déploiement des conteneurs et d'applications "serverless" 
