Lambda concurrency coût explosif malgré les envies de cheap du FinOps

Question

On a un cas bizarre sur nos fonctions lambda. on pensait faire des économies en passant des services batch sur du serverless mais la facture explose littéralement. C'est surtout les invocations et la durée qui sont énormes. On a des pics de charge où la concourrence monte très haut. Y'a un truc que je loupe sur le scaling de lambda ?# exemple de handler lambdaimport jsonimport timedef lambda_handler(event, context):    start_time = time.time()    # simulation d'un traitement long et consommateur    time.sleep(5)     result = {"message": "processing complete", "duration": time.time() - start_time}    print(json.dumps(result))    return {        'statuscode': 200,        'body': json.dumps(result)    }

cblanc · Answer

salut ! t'as des cold starts de ouf ou c'est juste la durée d'exécution qui est élevée ? et c'est quel runtime ?

xalbert · Answer

python 3.9 et oui on a des cold starts mais surtout la durée totale quand la concurrence monte. genre la fonction prend 5s et quand y'a 1000 invocations simultanées ça fait 5000s de compute facturé en 5s réelles

cblanc · Answer

ok le problème c'est pas le coût d'une invocation mais l'accumulation. t'as configuré de la concurrency réservée sur tes lambdas critiques ?

xalbert · Answer

non j'ai laissé l'auto-scaling géré par aws sans limites j'ai cru que c'était le plus optimal pour la facture

cblanc · Answer

non c'est le piège le plus classique du finops sur lambda si t'as pas de réservé et que ton env monte en charge trop vite aws provisionne à mort et ça coûte un bras

cblanc · Answer

le "burst concurrency" c limité à 500-3000 par région mais c pas instantané au-delà ça prend du temps et ça crée de la latence et des nouvelles invocations

xalbert · Answer

donc en gros si j'ai un pic de 5000 requêtes d'un coup lambda va essayer de scaler à 5000 instances même si c'est cher

cblanc · Answer

exactement et si chaque instance prend 5s bah tu multiplies le coût. il faut mettre de la concurrency réservée pour tes fonctions critiques pour éviter ça

cblanc · Answer

ça coûte pas plus cher d'avoir de la concurrency réservée ça empêche juste les autres fonctions de prendre tes ressources si y'a une limite régionale

xalbert · Answer

mais si je mets 1000 de réservée ça veut dire que je peux pas dépasser 1000 concurrents c'est pas contre-productif ?

cblanc · Answer

non ça te force à mieux gérer ta demande. si tu as besoin de plus tu augmentes mais tu as un contrôle direct sur le coût

cblanc · Answer

et pense à provisioned concurrency pour tes fonctions ultra critiques ça réduit les cold starts mais ça coûte plus cher à la base

xalbert · Answer

provisioned concurrency c'est si je veux 0 cold starts même en dehors des pics c'est ça ?

cblanc · Answer

oui c'est une quantité de lambdas toujours chaudes même s'il y a pas d'invocations mais ça a un coût fixe par GB/s

xalbert · Answer

ok je vais mettre de la concurrency réservée sur la fonction qui coûte cher à genre 500 pour voir. et on va investiguer pourquoi les traitements prennent 5s

cblanc · Answer

c'est une bonne première étape. souvent le problème est ailleurs après c'est juste la visibilité des coûts qui change

xalbert · Answer

on a identifié que le 5s c'est un appel externe vers une API qui est lente. du coup la lambda attend pour rien

cblanc · Answer

aha classique ! tente d'utiliser Step Functions pour orchestrer tes appels asynchrones ou des SQS pour découpler les systèmes

xalbert · Answer

on a mis en place SQS avant la lambda et la fonction est devenue plus courte. et avec la concurrency réservée de 500 on est bien maintenant la facture a baissé de 60%

cblanc · Answer

magnifique ! découpler et contrôler la concurrence c'est la clé du succès pour le finops serverless

Lambda concurrency coût explosif malgré les envies de cheap du FinOps

20 commentaires

Laisser une réponse

Les boucles dans le langage de programmation Go

Introduction du cours pour apprendre l'orchestrateur Kubernetes (k8s)

Comprendre et manipuler le scheduler Kubernetes

Augmenter les performances de votre Playbook

Configurer les GitLab Runners comme moteurs de votre CI/CD

Rejoindre la communauté