Les principales critiques autour des Functions as a Service (FaaS) se concentrent sur le cold start. À la différence d’une application traditionnelle où le code est présent en mémoire sur le serveur et attend des requêtes, dans le monde serverless, le code est dormant et n’est pour la plupart du temps pas provisionné.

Qu’est ce que le cold start ?

Le cold start ou en français « démarrage à froid » se produit quand l’exécution d’une fonction inactive (cold) survient pour la première fois. Dans ce cas, le fournisseur de cloud doit télécharger le package sur les serveurs, charger le code en mémoire et enfin l’exécuter. Il va de soi que ces étapes augmentent drastiquement le temps de réponse.

Une fois la fonction instanciée (hot), elle peut recevoir plusieurs requêtes sans subir toutes les étapes précédentes. Toutefois, après une certaine période d’inactivité, le provider de cloud se réserve le droit de supprimer le conteneur associé à la fonction, qui devient par la même occasion cold.

 

Anatomie d’une lambda en Node.js

Le handler (en vert) est appelé à chaque requête : il reçoit les paramètres d’appel dans l’objet event et le contexte d’exécution dans l’objet context.

Le code (en orange) hors du handler n’est exécuté que lors de l’instanciation d’une fonction « cold ». Une bonne pratique consiste à initialiser le maximum de code hors de ce handler, tels que les pool de connexion HTTP ou SQL. Cela ne réduira pas le temps de démarrage, mais accéléra le temps des prochaine requêtes d’une fonction « hot ».

Comment mesurer le cold start ?

Au re-invent 2016, le catalogue Amazon s’est étoffé en proposant le service AWS X-Ray, un outil qui « aide les développeurs à analyser et à déboguer la production et les applications distribuées ».

Lambda est intégré avec X-Ray et envoie automatiquement ses traces d’exécution une fois la case « Enable active tracing » cochée. Le rôle IAM associé à la Lambda doit également avoir les droits suivants :

• « xray:PutTelemetryRecords« 
• « xray:PutTraceSegments« 

Le cold start est-il facturé ?

Pour répondre à cette question je vous propose le code de test suivant :

• Simulation d’une fonction lente à s’exécuter lors de l’initialisation à l’aide d’un « sleep » de 9 secondes
• Le handler attend 2,5 secondes avant de renvoyer la réponse

La trace X-Ray représente bien les 9 secondes d’attente dans l’initialisation et les 2,5 secondes de traitement du handler.

CloudWatch nous indique quant à lui que le temps facturé est de 2600 ms soit le temps d’exécution du handler.

L’initialisation de la fonction ne compte donc pas dans le temps de facturation.

Le cold start est-il décompté du timeout ?

Comme vous le savez sûrement, le temps maximal d’exécution d’une Lambda est de 5 minutes. Une question légitime que l’on peut se poser, est de savoir si ce temps comprend également l’initialisation. Ce qui laisserait dans ce cas moins de 5 minutes au code métier pour renvoyer un résultat.

Pour vérifier, dans l’exemple précédent, il suffit de configurer le timeout à 3 secondes pour laisser le temps au handler de retourner une réponse mais pas à l’initialisation de se terminer.

Aucune erreur n’est présente lors de l’exécution, ce qui signifie que le timeout n’opère que sur le handler.

Mais alors je peux exécuter du code gratuitement hors du handler ?

Si l’initialisation de la fonction est gratuite et ne compte pas dans le timeout alors pourquoi ne pas en profiter pour faire des traitements lourds aux frais d’AWS ?

Pour simuler ce cas, le temps d’attente de l’initialisation à la ligne 7 passe de 9 secondes à 11 secondes.

Après exécution de la Lambda, nous obtenons les résultats suivants. Au lieu d’avoir un temps de total de 13,5 secondes (11 secondes + 2,5 secondes) X-Ray indique 24 secondes.

CloudWatch Logs révèle une facturation de 13600 ms soit la somme du temps d’initialisation (11 secondes) et du handler (2,5 secondes). De plus la Lambda a été chargée deux fois car le log « Loading function » est répété.

Explications :

Ces chiffres semblent de prime abord incompréhensibles mais l’explication est simple.

Si l’initialisation de la fonction Lambda dure plus de 10 secondes, AWS stoppe le traitement et le relance. La deuxième fois, le temps d’initialisation est décompté dans le temps d’exécution et de facturation.

Cela empêche donc d’exécuter du code lourd hors du handler.

Pour espérer tirer efficacement parti d’une architecture serverless, il est indispensable de connaître les subtilités de fonctionnement des services utilisés, et le cold start en est une. 

Vous êtes à présent incollables sur ce sujet, alors bon code ;)