Optimisation des performances lambda

Si vous réussissez à obtenir les performances les plus efficaces d'Amazon Web Services (AWS) Lambda, vous verrez une grande différence dans le budget cloud de votre entreprise. AWS Lambda élimine la complexité de la gestion de votre propre serveur et d'autres ressources cloud, ce qui peut être bénéfique quand vous devez faire évoluer rapidement vos systèmes et réaliser des prototypes de nouveaux produits et capacités. 

Si vous avez dépassé le stade du lancement de votre start-up depuis votre garage et en fonction du niveau de complexité de votre infrastructure, il serait probablement bon pour votre emploi du temps et votre budget d'automatiser ces tâches. 

Qu'est-ce qu'AWS Lambda?

AWS Lambda est un service serverless basé sur les événements (event‑driven) qui exécute automatiquement le code pour fournir les ressources AWS adéquates à votre infrastructure sans devoir les gérer. En d'autres termes, vous n'avez pas à vous inquiéter du provisionnement ni de la gestion des tâches comme la maintenance du système d'exploitation, la scalabilité, etc. 

Pour ce service, vous payez des droits à AWS pour le temps de calcul que vous utilisez. Une fonction exécutée via un déclencheur de notification d'événement ou un appel Invoke direct, engendre des frais. Cela signifie que vous voudrez paramétrer le monitoring pour savoir où vous pouvez éviter de trop payer pour l'utilisation future de Lambda. 

AWS vous fournit une solution de monitoring de base, mais ne vous donne pas les informations sur les comportements les plus détaillés de vos fonctions Lambda, tels que les informations sur la source d'un événement avec tout son contexte, le tracing distribué et les données détaillées sur les performances sur la durée, les démarrages à froid, les exceptions et les tracebacks (ou retraçages). Pour obtenir ces renseignements, vous aurez besoin d'une solution de monitoring en continu. 

La mémoire impacte les performances Lambda

Un élément clé à rechercher dans les fonctions Lambda pendant le runtime est l'usage de la mémoire. AWS vous permet de configurer l'allocation de la mémoire pour chacune des fonctions, entre 128 Mo et 10,24 Go. Pour les petites fonctions Lambda, 128 Mo peuvent suffire. En outre, les performances Lambda évoluent relativement proportionnellement à la quantité de mémoire allouée. 

Le problème vient du fait que la quantité de mémoire allouée détermine également approximativement la puissance virtuelle du CPU ainsi que les performances du réseau et du disque. Ceci peut entraîner l'imprédictibilité des performances des fonctions. Par exemple, si vous utilisez trop de CPU, vous pouvez observer un ralentissement dû aux limites de concurrence. 

L'analyse comparative des performances est également complexe étant donné que votre objectif global est de réduire le temps d'exécution réel de la fonction Lambda. Bien qu'il soit vrai jusqu'à une certaine limite que plus de CPU accélère l'exécution d'une fonction, il est aussi vrai qu'il arrive un moment où les retours obtenus diminuent. Étant donné que vous êtes facturé par tranche de 100 ms, il n'y a aucune différence entre la facturation pour 120 ms et celle pour 150 ms — elles sont toutes deux facturées pour 200 ms. 

Dépannage et amélioration des performances Lambda

Afin de faire des économies, configurez le monitoring continu d'AWS Lambda de telle sorte à pouvoir monitorer toutes les anomalies au sein de vos fonctions Lambda, les déboguer, et globalement, faire le suivi de ces exécutions de code. À mesure que votre infrastructure devient de plus en plus complexe, ces fonctions serverless peuvent devenir moins performantes si elles dépendent les unes des autres au cours de plusieurs événements. Il peut ainsi s'avérer difficile de savoir où se trouve un problème en raison de la nature distribuée de votre système. 

Voici quelques-uns des problèmes courants qui peuvent se produire : 

Fonctions longues

L'exécution d'une grande partie ou de toute votre logique commerciale dans une seule fonction n'est généralement pas une bonne idée, mais cela résulterait aussi en une facture importante en raison du temps nécessaire pour invoquer la fonction. Si vous le pouvez, découpez le code en fonctions plus courtes et évitez celles dites « lambdalithiques » ou longues. 

Démarrages à froid

Pour que vos fonctions continuent de répondre de manière prévisible, vous devrez aussi les invoquer régulièrement pour éviter la latence des « démarrages à froid » due à leur réinitialisation.

Limites du temps d'exécution

Le délai des fonctions Lamda expire après 15 minutes. Dans l'idéal, vos fonctions seront courtes, elles seront exécutées rapidement et elles n'incluront pas de workloads à exécution longue. L'exécution dans de grandes bases de données, ou toute tâche chronophage semblable, n'est pas recommandé pour les fonctions AWS Lambda.

Limites concurrentes

Une instance est créée à chaque fois qu'un service invoque une fonction pour la première fois. Si cette requête est toujours en cours de traitement, mais que le service invoque la fonction une deuxième fois, AWS créera une autre instance pour traiter cette nouvelle requête. Cela continue jusqu'à ce que vous arriviez à la limite maximale. Vous pouvez exécuter en même temps 1 000 instances servant des requêtes pour chaque région AWS.

Pour éviter tout ralentissement, vous pouvez demander à AWS d'augmenter la limite, mais vous devez le faire au moins deux semaines à l'avance. Cela peut s'avérer utile si vous savez qu'un événement, comme le Black Friday ou la saison des fêtes, va augmenter l'accès à votre application. 

AWS fournit un Power Tuner AWS Lambda qui vous aide à comprendre les performances de votre fonction et les frais encourus si vous ajustez l'allocation de mémoire. Toutefois, cela ne vous donne pas la vue complète dont vous avez besoin pour repérer l'origine de l'augmentation des coûts parce que cette information n'est tout simplement pas assez détaillée. 

Pour réellement améliorer vos fonctions et éviter les problèmes courants mentionnés ci-dessus, il vous faut une solution de monitoring en continu tierce. Elle doit accomplir plusieurs choses que vous n'obtiendrez pas du tuner, notamment :

• Vous permettre d'observer toutes les instances des invocations AWS Lambda
• Définir des alertes personnalisées en fonction de n'importe quels critères d'invocation
• Fournir une analyse des erreurs
• Fournir une vue unique où vous pouvez voir toutes vos fonctions Lambda dans chacune des régions AWS en un coup d'œil.

Après tout, vous ne pouvez pas trouver de solution à un problème si vous ne le comprenez pas. Et vous ne pouvez pas comprendre un problème si vous n'avez pas suffisamment de contexte. 

L'observabilité New Relic peut booster votre réussite avec AWS. Voici comment.

Avec le monitoring Lambda de New Relic, vous obtiendrez une expérience rationalisée abordable. Nous offrons le monitoring Lambda complet et une intégration à AWS Lambda qui vous permet de démarrer en quelques minutes. 

 Notre monitoring lambda vous montre :

• Chaque invocation de vos fonctions Lambda : ceci comprend les informations détaillées sur la durée, les tracebacks, les démarrages à froid et plus encore.
• Informations sur les événements : ces informations fournissent le contexte et les attributs dont vous aurez besoin pour savoir ce qui a déclenché une invocation AWS Lambda, y compris API Gateway, ALB SNS, SQS, DynamoDB, etc. 
• Tracing distribué : ces traces illustrent le chemin des requêtes qui ont amené votre Lambda. 
• Logs en contexte : ils fournissent l'invocation complète et les logs au niveau de la fonction ainsi que vos métriques, attributs et données de trace.
• Tags et métadonnées inventoriés : les informations à partir de vos entités AWS que vous utilisez pour descendre jusqu'à des attributs de métadonnées spécifiques sur la configuration d'une fonction ou l’invocation elle-même.