Comment puis-je résoudre les problèmes de démarrage à froid de la fonction Lambda ?

Résolution

La configuration initiale d'une demande de fonction Lambda pour l'environnement et le code est appelée temps de démarrage à froid ou latence de démarrage. Pour minimiser le temps de démarrage à froid et la latence de votre fonction Lambda, suivez ces instructions correspondant à votre cas d'utilisation.

Code de fonction Lambda et bonnes pratiques de configuration

• Augmentez la mémoire allouée à la fonction Lambda. La plage de démarrage à froid dépend de la taille de votre fonction, de la quantité de mémoire allouée et de la complexité de votre code. L'ajout de mémoire augmente proportionnellement la quantité de processeur, ce qui accroît la puissance de calcul globale disponible. Pour plus d'informations, consultez la section Mémoire et puissance de calcul.
• Réduisez la taille de votre package de déploiement. Plus votre package de déploiement est petit, plus votre fonction démarre rapidement. Réduisez le nombre de dépendances et de bibliothèques externes que votre fonction importe, et limitez la taille de votre package de déploiement à moins de 50 Mo. Pour plus d'informations, consultez la section Packages de déploiement Lambda.
• Optimisez le code de votre fonction Lambda afin de minimiser le temps nécessaire à l'initialisation. Réduisez le nombre de dépendances et de bibliothèques externes que votre fonction importe. Réduisez la quantité de code exécutée lors de l'initialisation.
• Évitez les calculs complexes au démarrage. Si votre fonction nécessite des calculs complexes au démarrage, tels que le chargement de grands ensembles de données, vous pouvez effectuer ces calculs en arrière-plan. Exécutez le calcul dans un thread d'arrière-plan pendant la phase d'initialisation. Ensuite, mettez les résultats en cache pour les appels suivants. La mise en cache des résultats permet de réduire le temps nécessaire aux calculs complexes au démarrage.
• Réutilisez les connexions à la base de données Amazon Relational Database Service (Amazon RDS). Si votre fonction se connecte à une base de données Amazon RDS, vous pouvez créer un proxy de base de données proxy Amazon RDS pour votre fonction. Un proxy de base de données gère un pool de connexions de base de données. La réutilisation des connexions à la base de données Amazon RDS réduit le temps nécessaire à l'établissement d'une connexion à chaque fois que votre fonction est appelée.
• Configurez la simultanéité provisionnée. Les fonctions utilisant la simultanéité provisionnée ne présentent pas de comportement de démarrage à froid car l'environnement d'exécution est préparé avant l'invocation. Vous pouvez spécifier le nombre d'instances de fonction pour rester au chaud et gérer le trafic.
• Réduisez la complexité de vos dépendances. Utilisez des cadres simples qui se chargent rapidement au démarrage de l'environnement d'exécution.
• Pour réduire le temps nécessaire à Lambda pour décompresser les packages de déploiement créés en Java, placez vos fichiers .jar de dépendance dans un répertoire /lib. Séparer les fichiers .jar est plus rapide que de placer tout le code de votre fonction dans un seul fichier jar contenant un grand nombre de fichiers .class. Pour plus d'informations, voir Déployer des fonctions Java Lambda avec des archives de fichiers .zip ou JAR.
• Utilisez la surveillance pour découvrir les problèmes et l'observabilité pour en découvrir les causes. Surveillez les performances de démarrage à froid de vos fonctions et utilisez Lambda Insights dans Amazon CloudWatch pour résoudre les problèmes de performances.

Pour plus d'informations, consultez la section Meilleures pratiques d'utilisation des fonctions Lambda.

Longue durée d'INIT en cas de simultanéité provisionnée

Dans les fonctions Lambda à la demande, l'initialiseur statique est exécuté après la réception d'une demande, mais avant que le gestionnaire ne soit appelé. Cela entraîne une latence pour le demandeur et contribue à la durée globale du démarrage à froid.

• Déterminez si la simultanéité de vos fonctions dépasse le niveau configuré de simultanéité provisionnée. Vous pouvez vérifier le nombre de fois où votre fonction est appelée à l'aide de la métrique CloudWatch de ProvisionedConcurrencySpilloverInvocations. Une valeur différente de zéro indique que toute la simultanéité provisionnée est utilisée et que certains appels ont eu lieu lors d'un démarrage à froid.
• Vérifiez votre fréquence d'invocation (demandes par seconde). Les fonctions avec simultanéité provisionnée ont un taux maximum de 10 demandes par seconde et par simultanéité provisionnée (demandes d'API Lambda). Par exemple, une fonction configurée avec 100 simultanéité provisionnées peut traiter 1 000 demandes par seconde. Si le taux d'appel dépasse 1 000 demandes par seconde, des démarrages à froid peuvent se produire. Pour plus d'informations, consultez Lambda : Cold commence par une simultanéité provisionnée.

Pour plus d'informations, consultez l'article Comment résoudre les problèmes de simultanéité provisionnée des fonctions Lambda ?

Requêtes Amazon API Gateway intégrées à Lambda

Si vous utilisez Lambda avec API Gateway et que vous constatez une métrique d'intégration/latence élevée, consultez les journaux CloudWatch de votre fonction Lambda. La latence élevée doit être corrigée lorsqu'un point de terminaison d'API intégré à une fonction Lambda met trop de temps à envoyer des réponses à un client. Les démarrages à froid dans les fonctions Lambda ne sont pas enregistrés dans la métrique de durée de la fonction. La latence d'intégration de votre API peut donc être supérieure à la durée de la fonction. Pour connaître la durée de votre fonction en cas de démarrage à froid, utilisez AWS X-Ray.

Pour plus d'informations, consultez l'article Comment résoudre les problèmes de latence élevée dans mes requêtes de passerelle API intégrées à Lambda ?

Informations connexes

Comment réduire la latence d'initialisation et d'invocation pour ma fonction Java Lambda ?

Amélioration des performances de démarrage avec Lambda SnapStart pour Java 11 exécution

Fonctionnement de Lambda : Optimisation des performances — Partie 1