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 des 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” ?
“ Démarrages à froid” sont un gros problème pour Lambda, en particulier lorsqu'on l'envisage 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 les avoir invoqués. 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 n'a pas été 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 le temps 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.
Plus de 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 tous à l'avance et les garde au chaud. Lorsqu'un appel est nécessaire, Lambda utilisera 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 de temps, 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 à cette question 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 principal nombre à prendre en compte pour la simultanéité provisionnée est le nombre d'exécutions de fonctions s'exécutant en même temps. Par exemple, si vous avez une fonction qui est 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 USD par mois pour s'exécuter.
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 légère augmentation des coûts de 5 à 10 %, 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 passé par Lambda dans le code d'initialisation.
LIRE LA SUITE
- › IPv4 et IPv6 : quelles sont les différences ?
- › Dans le verset Android : l'histoire du robot Android
- &rsaquo ; Les meilleures applications de podcast pour iPhone et iPad
- › Comment formater une clé USB en FAT32 sous Windows 11 ou Windows 10
- › Piles jetables ou rechargeables : laquelle est la meilleure ?
- &rsaquo ; Threads est la nouvelle application de médias sociaux des créateurs de Facebook & Instagram