Lambda concurrency coût explosif malgré les envies de cheap du FinOps
Commentaires
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 ?
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
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 ?
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
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
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
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
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
ç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
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 ?
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
et pense à provisioned concurrency pour tes fonctions ultra critiques ça réduit les cold starts mais ça coûte plus cher à la base
provisioned concurrency c'est si je veux 0 cold starts même en dehors des pics c'est ça ?
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
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
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
on a identifié que le 5s c'est un appel externe vers une API qui est lente. du coup la lambda attend pour rien
aha classique ! tente d'utiliser Step Functions pour orchestrer tes appels asynchrones ou des SQS pour découpler les systèmes
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%
magnifique ! découpler et contrôler la concurrence c'est la clé du succès pour le finops serverless
Laisser une réponse
Vous devez être connecté pour poster un message !
Rejoindre la communauté
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
xalbert
Membre depuis le 13/05/2024
actif
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 ?