Comment optimiser les fonctions AWS Lambda avec la simultanéité provisionnée et la mise à l’échelle automatique

Les fonctions AWS Lambda sont une solution sans serveur pour exécuter du code dans le cloud sans configurer vos propres serveurs. Le principal inconvénient est que les temps d’initialisation peuvent être élevés, ce qui entraîne une latence accrue. Avec Provisioned Concurrency, vous pouvez résoudre ce problème.

Qu’est-ce que la simultanéité provisionnée ?

Les fonctions Lambda s’exécutent dans leurs propres « environnements d’exécution », qui sont généralement démarrés automatiquement lorsqu’une demande est faite. Après une invocation de fonction, l’environnement sera maintenu « chaud » pendant environ 5 à 15 minutes, et le code d’initialisation n’aura pas à s’exécuter à nouveau.

Cependant, après cette période, ou si plusieurs requêtes doivent être servies simultanément, un nouvel environnement d’exécution doit être lancé, ce qui entraîne une augmentation des temps de démarrage appelé « démarrage à froid ». Cela peut être particulièrement prononcé avec les langages qui doivent effectuer de grandes quantités de compilation JIT au démarrage, tels que Java et .NET.

Pour résoudre ce problème, AWS dispose d’une fonctionnalité appelée Provisioned Concurrency, où vous pouvez essentiellement réserver un certain nombre d’environnements d’exécution pour qu’ils soient en permanence chauds tout au long de la journée. Cela signifie que tout le code d’initialisation est exécuté à l’avance et que vous n’avez pas à faire l’expérience de démarrages à froid.

Si vous comptez sur Lambda pour traiter les requêtes destinées aux utilisateurs, vous voudrez peut-être envisager la simultanéité provisionnée même si cela finit par coûter un peu plus cher. Même si les démarrages à froid ne représentent généralement que 1 % des requêtes, ces 1 % peuvent représenter des secondes supplémentaires passées à attendre le chargement d’une application, bien que cela dépende de la durée d’exécution et de la taille de votre code.

Combien coûte la simultanéité provisionnée ?

Contrairement aux instances EC2 réservées, la simultanéité provisionnée est toujours principalement une tarification « payez pour ce que vous utilisez », comme le reste de Lambda. Vous payez une somme modique pour chaque heure d’approvisionnement de chaque environnement, puis payez les requêtes Lambda comme d’habitude.

Cependant, étant donné que le trafic est plus prévisible du côté d’AWS et qu’il est moins coûteux de ne pas avoir à exécuter le code d’initialisation en permanence, le coût de calcul par fonction pour les requêtes effectuées avec la simultanéité provisionnée est en réalité plus faible. Il n’y a pas non plus d’inconvénient à dépasser la limite – vous ne serez facturé qu’au prix standard de la simultanéité.

Dans l’ensemble, la simultanéité provisionnée peut être légèrement moins chère (environ 5 à 10 %) si vous avez un trafic très prévisible et réservez exactement autant de capacité. Cependant, cela peut aussi être un peu plus cher dans certains cas. Vous voudrez vérifier vos analyses et branchez-les dans le calculateur de tarification Lambda d’AWS pour apprendre plus.

Activation de la simultanéité provisionnée

L’activation de la simultanéité provisionnée est assez simple, mais elle présente un inconvénient : elle ne peut pas pointer vers la version $LATEST par défaut. Cette balise est un alias qui peut changer et ne pointe pas vers une version spécifique, et la simultanéité provisionnée doit réserver une version spécifique. Vous devrez donc publier une nouvelle version de Lambda, si vous n’en avez pas déjà une :

Ensuite, configurez un alias pour pointer vers cette version. Cet alias peut être mis à jour, ce qui déclenchera une mise à jour pour les environnements provisionnés.

Une fois votre alias configuré, vous pouvez ajouter une nouvelle configuration de simultanéité à partir des paramètres de Lambda, sous Configuration > Concurrency. Vous pouvez également le configurer directement à partir des paramètres d’alias.

Les paramètres de simultanéité provisionnée sont simples : sélectionnez un alias et saisissez un montant à provisionner.

Vous pouvez également définir et mettre à jour cette valeur à l’aide de l’API ou de la CLI AWS, qui peut être utilisée pour l’automatiser tout au long de la journée :

aws lambda put-provisioned-concurrency-config --function-name MyFunction \
--qualifier LatestProvisioned --provisioned-concurrent-executions 10

Mise à l’échelle automatique avec simultanéité provisionnée

Étant donné que la simultanéité provisionnée peut être ajustée tout au long de la journée, elle peut également être connectée à Application Auto Scaling d’AWS pour l’ajuster en fonction de l’utilisation. La connexion est simple et ne prend que quelques commandes de l’AWS CLI ou de l’API, car il n’y a pas encore de console de gestion pour cela.

Tout d’abord, vous devez enregistrer la fonction Lambda en tant que cible de mise à l’échelle. Ici, vous devrez modifier le nom de la fonction (MyFunction) et l’alias (LatestProvisioned), et également ajuster les plages de capacité min et max.

aws application-autoscaling register-scalable-target --service-namespace lambda \
--resource-id function:MyFunction:LatestProvisioned --min-capacity 2 --max-capacity 10 \
--scalable-dimension lambda:function:ProvisionedConcurrency

Ensuite, vous pouvez activer une stratégie de mise à l’échelle automatique, en utilisant le nom et l’alias de la fonction comme ID de ressource, et en la configurant avec une stratégie de mise à l’échelle JSON. Cet exemple le met à l’échelle vers le haut et vers le bas lorsque LambdaProvisionedConcurrencyUtilization passe au-dessus ou en dessous de 70 %.

aws application-autoscaling put-scaling-policy --service-namespace lambda \
--scalable-dimension lambda:function:ProvisionedConcurrency --resource-id function:MyFunction:LatestProvisioned \
--policy-name my-policy --policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration ' "TargetValue": 0.7, "PredefinedMetricSpecification":  "PredefinedMetricType": "LambdaProvisionedConcurrencyUtilization" '

Cela ne couvre pas tous les cas, tels que les rafales rapides d’utilisation qui ne durent pas longtemps, mais cela fonctionne bien pour un trafic constant et vous fera économiser de l’argent le soir lorsque le trafic est faible.