Comment maintenir au chaud la quantité souhaitée de conteneurs de fonction AWS Lambda
Sur mon projet, il existe une API REST implémentée sur AWS API Gateway et AWS Lambda. Comme les fonctions AWS Lambda sont sans serveur et sans état pendant que nous l'appelons, AWS démarre un conteneur avec le code de la fonction Lambda qui traite notre appel. Selon la documentation AWS une fois l'exécution de la fonction lambda terminée, AWS n'arrête pas le conteneur et nous sommes en mesure de traiter l'appel suivant dans ce conteneur. Une telle approche améliore les performances du service - uniquement au moment du premier appel AWS prend le temps de démarrer le conteneur (démarrage à froid de la fonction Lambda) et tous les appels suivants sont exécutés plus rapidement car ils utilisent le même conteneur (démarrages à chaud).
Comme prochaine étape pour améliorer les performances, nous avons créé le travail cron qui appelle périodiquement notre fonction Lambda (nous utilisons les règles Cloudwatch pour cela). Une telle approche permet de garder la fonction Lambda "au chaud", ce qui évite l’arrêt et le redémarrage des conteneurs. C'est à dire. Lorsque l'utilisateur réel appellera notre API REST, Lambda n'aura pas passé de temps à démarrer un nouveau conteneur.
Mais nous avons dû faire face au problème - une telle approche permet de garder au chaud un seul conteneur de fonction Lambda alors que le nombre réel d’appels parallèles de différents utilisateurs peut être beaucoup plus important (dans notre cas, c’est des centaines et parfois même des milliers d’utilisateurs). Existe-t-il un moyen d'implémenter une fonctionnalité de préchauffage pour la fonction Lambda qui pourrait réchauffer non seulement un conteneur, mais le nombre souhaité d'entre eux?
Je comprends que cette approche peut affecter le coût d’utilisation de la fonction Lambda et qu’il sera peut-être préférable d’utiliser un bon vieux serveur d’applications, mais la comparaison de ces approches et de leurs coûts sera la prochaine étape, je pense, souhaite simplement trouver le moyen de réchauffer le nombre souhaité de conteneurs de fonctions Lambda.
Nous utilisons des lambdas Java (bottes à ressort) et avons abouti à une solution à peu près identique à la réponse de Kush Vyas ci-dessus, qui fonctionne très bien.
Lors des tests de charge, nous avons toutefois constaté qu'une demande d'utilisateur légitime se produisait souvent pendant la période d'exécution de la "fonction contrôleur", ce qui entraînait à nouveau l'inévitable démarrage à froid ...
Donc, maintenant dans notre "fonction de contrôleur", nous avons notre nombre régulier de demandes de préchauffage simultanées X, cependant, chaque 5ème exécution de la fonction, nous appelons notre lambda cible deux fois de plus. La théorie étant que nous allons nous retrouver avec X + 2 lambdas restant au chaud, mais pour 4 appels sur 5 d'échauffement, il y aura toujours 2 lambdas redondants pouvant répondre aux demandes des utilisateurs.
Cela a réduit notre nombre de démarrages à froid encore plus loin (mais évidemment pas encore complètement) et nous continuons de jouer avec des combinaisons simultanéité/fréquence d’échauffement/sommeil pour trouver la solution optimale pour nous - ces valeurs dépendront probablement toujours de les exigences de charge pour une situation spécifique.
Si vous utilisez le framework serverless avec AWS Lambda, vous pouvez utiliser ce plugin pour maintenir tous vos lambda au chaud avec un certain niveau de simultanéité.
J'aimerais partager un petit conseil utile que nous utilisons pour réduire le délai «observé par l'utilisateur» lié aux démarrages à froid. Dans notre cas, la fonction Lambda traite les requêtes HTTP du serveur frontal via AWS API Gateway, en particulier exécute la fonctionnalité de recherche lorsque l'utilisateur saisit quelque chose dans le champ d'entrée. Habituellement, les utilisateurs commencent à taper avec un certain retard après le rendu de l'interface utilisateur. Nous avons donc un peu de temps pour exécuter un appel ping à notre fonction Lambda afin de le réchauffer. Et lorsque l'utilisateur fera des demandes au serveur principal, le Lambda sera probablement prêt à fonctionner.
En réalité, une telle approche ne fait rien pour résoudre le problème avec les démarrages à froid du côté serveur et vous devrez rechercher d'autres options pour le résoudre, mais il peut s'agir d'une amélioration de l'expérience utilisateur sans trop d'effort (quelque chose comme un correctif).
Une chose à retenir: si votre service est public et que vous vous souciez du score Google Insights, vous devez être prudent dans la mise en œuvre de cette approche.