Résolution des problèmes liés aux instances gérées Lambda - AWS Lambda
Problèmes de régulation et de mise à l'échelleProblèmes de simultanéitéProblèmes de performanceProblèmes liés aux fournisseurs de capacitéProblèmes de surveillance et d'observabilitéAide supplémentaireÉtapes suivantes

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes liés aux instances gérées Lambda

Problèmes de régulation et de mise à l'échelle

Taux d'erreur élevés lors de la mise à l'échelle

Problème : vous rencontrez des erreurs de régulation (HTTP 429) lorsque le trafic augmente rapidement.

Cause : Les instances gérées Lambda évoluent de manière asynchrone en fonction de l'utilisation des ressources du processeur et de la saturation en multisimultanéité. Si votre trafic double plus que dans les 5 minutes, vous risquez de rencontrer des difficultés à mesure que Lambda augmente le volume des instances et des environnements d'exécution pour répondre à la demande.

Solution :

  • Ajustez l'utilisation des ressources cibles : si votre charge de travail présente des modèles de trafic prévisibles, définissez une utilisation des ressources cible inférieure afin de conserver une marge de manœuvre supplémentaire en cas de pics de trafic.

  • Capacité de préchauffage : pour les augmentations de trafic prévues, augmentez progressivement le trafic sur une plus longue période pour permettre à l'évolution de suivre le rythme.

  • Surveillez les mesures de dimensionnement : suivez les mesures d'erreur d'accélération pour comprendre la raison des problèmes liés aux accélérateurs et à la mise à l'échelle de la capacité.

  • Vérifiez la configuration des fonctions : assurez-vous que la mémoire des fonctions et les paramètres du vCPU prennent en charge les exécutions simultanées multiples. Augmentez la mémoire des fonctions ou l'allocation de vCPU si nécessaire.

Diminution lente

Problème : les instances mettent beaucoup de temps à être réduites lorsque le trafic diminue.

Cause : les instances gérées Lambda diminuent progressivement pour maintenir la disponibilité et éviter les changements rapides de capacité susceptibles d'avoir un impact sur les performances.

Solution :

Ce comportement est normal. Lambda réduit les instances de manière conservatrice pour garantir la stabilité. Surveillez vos CloudWatch indicateurs pour suivre le nombre d'instances en cours d'exécution.

Problèmes de simultanéité

Environnements d'exécution présentant de faibles limites d'expérience en matière de simultanéité

Problème : vos fonctions sont limitées malgré la capacité disponible.

Cause : les environnements d'exécution présentant une simultanéité maximale très faible peuvent avoir des difficultés à évoluer efficacement. Les instances gérées Lambda sont conçues pour les applications multiconcurrentes.

Solution :

  • Augmenter la simultanéité maximale : si vos appels de fonctions utilisent très peu de CPU, augmentez le paramètre de simultanéité maximale à 64 par vCPU.

  • Optimisation du code de fonction : passez en revue votre code de fonction pour réduire la consommation du processeur par appel, permettant ainsi une plus grande simultanéité.

  • Ajustez la mémoire des fonctions et le vCPU : assurez-vous que votre fonction dispose de suffisamment de ressources pour gérer plusieurs appels simultanés.

Problèmes de sécurité des threads (environnement d'exécution Java)

Problème : votre fonction Java produit des résultats incorrects ou est confrontée à des conditions de course sous charge.

Cause : plusieurs threads exécutent la méthode du gestionnaire simultanément, et l'état partagé n'est pas adapté aux threads.

Solution :

  • Utilisez AtomicInteger ou AtomicLong pour des compteurs au lieu de types primitifs

  • Remplacez HashMap par ConcurrentHashMap.

  • Utiliser Collections.synchronizedList() pour emballer ArrayList

  • À utiliser ThreadLocal pour un état spécifique à la demande

  • Trace d'accès IDs à partir de l'objet Lambda Context, et non des variables d'environnement

Pour obtenir des instructions détaillées, consultez la documentation relative à l'environnement d'exécution Java pour les instances gérées Lambda.

Problèmes d'isolation de l'état (environnement d'exécution de Node.js)

Problème : votre fonction Node.js renvoie des données provenant de différentes requêtes ou est corrompue.

Cause : les variables globales sont partagées entre les appels simultanés sur le même thread de travail. Lorsque les opérations asynchrones donnent le contrôle, d'autres invocations peuvent modifier l'état partagé.

Solution :

  • Installation et utilisation @aws/lambda-invoke-store pour tous les états spécifiques à la demande

  • Remplacez les variables globales par InvokeStore.set() et InvokeStore.get()

  • Utiliser des noms de fichiers uniques dans /tmp la demande IDs

  • Accédez au suivi IDs en utilisant InvokeStore.getXRayTraceId() plutôt que des variables d'environnement

Pour obtenir des instructions détaillées, consultez la documentation du runtime Node.js pour les instances gérées Lambda.

Conflits de fichiers (environnement d'exécution Python)

Problème : votre fonction Python lit des données incorrectes dans les fichiers/tmp.

Cause : plusieurs processus partagent le /tmp répertoire. Les écritures simultanées dans le même fichier peuvent entraîner une corruption des données.

Solution :

  • Utilisez des noms de fichiers uniques avec la demande IDs : /tmp/request_{context.request_id}.txt

  • Utiliser le verrouillage de fichiers avec fcntl.flock() pour les fichiers partagés

  • Nettoyez les fichiers temporaires os.remove() après utilisation

Pour obtenir des instructions détaillées, consultez la documentation relative à l'environnement d'exécution Python pour les instances gérées Lambda.

Problèmes de performance

Utilisation élevée de la mémoire

Problème : vos fonctions sont confrontées à une utilisation élevée de la mémoire ou à out-of-memory des erreurs.

Cause : Chaque demande simultanée en Python s'exécute dans un processus distinct avec son propre espace mémoire. L'utilisation totale de la mémoire est égale à la mémoire par processus multipliée par les processus simultanés.

Solution :

  • Surveillez la MemoryUtilization métrique dans CloudWatch

  • Réduisez le MaxConcurrency paramètre si l'utilisation de la mémoire approche de la limite de mémoire de la fonction

  • Augmenter l'allocation de mémoire des fonctions pour permettre une plus grande simultanéité

  • Optimisez l'utilisation de la mémoire en chargeant les données à la demande plutôt que lors de l'initialisation

Performances incohérentes

Problème : les performances des fonctions varient considérablement d'un appel à l'autre.

Cause : Lambda peut sélectionner différents types d'instances en fonction de la disponibilité, ou des fonctions peuvent être exécutées sur des instances dont la disponibilité des ressources varie.

Solution :

  • Spécifiez les types d'instances autorisés : si vous avez des exigences de performances spécifiques, configurez les types d'instances autorisés dans votre fournisseur de capacité afin de limiter les types d'instances que Lambda peut sélectionner.

  • Surveillez les métriques au niveau de l'instance : suivez CPUUtilization et MemoryUtilization au niveau du fournisseur de capacité pour identifier les contraintes en matière de ressources.

  • Passez en revue les indicateurs de capacité : vérifiez vCPUAvailable et MemoryAvailable assurez-vous que des ressources suffisantes sont disponibles sur vos instances.

Problèmes liés aux fournisseurs de capacité

La version de la fonction ne devient pas ACTIVE

Problème : la version de votre fonction reste en attente après la publication.

Cause : Lambda lance des instances gérées et démarre des environnements d'exécution. Ce processus prend du temps, en particulier pour la première version fonctionnelle d'un nouveau fournisseur de capacité.

Solution :

Attendez que Lambda termine le processus d'initialisation. Lambda lance trois instances par défaut pour la résilience AZ et démarre trois environnements d'exécution avant de marquer la version ACTIVE de votre fonction. Cela prend généralement plusieurs minutes.

Impossible de supprimer le fournisseur de capacité

Problème : vous recevez un message d'erreur lorsque vous tentez de supprimer un fournisseur de capacité.

Cause : vous ne pouvez pas supprimer un fournisseur de capacité auquel des versions de fonctions sont associées.

Solution :

  1. Identifiez toutes les versions de fonctions à l'aide du fournisseur de capacité avec l'ListFunctionVersionsByCapacityProviderAPI.

  2. Supprimez ou mettez à jour ces versions de fonction pour supprimer l'association du fournisseur de capacité.

  3. Réessayez de supprimer le fournisseur de capacité.

Messages d'erreur génériques lors de la publication des fonctions

Problème : vous rencontrez des messages d'erreur génériques tels que « Une erreur interne s'est produite lors de la publication » lors de la publication de fonctions.

Solution :

  • Vérifiez les autorisations IAM : assurez-vous d'avoir l'lambda:PassCapacityProviderautorisation du fournisseur de capacité que vous essayez d'utiliser.

  • Vérifiez la configuration du fournisseur de capacité : vérifiez que votre fournisseur de capacité est à l'état ACTIF à l'aide de l'GetCapacityProviderAPI.

  • Vérifiez la configuration du VPC : assurez-vous que les sous-réseaux et les groupes de sécurité spécifiés dans votre fournisseur de capacité sont correctement configurés et accessibles.

  • Vérifier les AWS CloudTrail journaux : consultez CloudTrail les journaux pour obtenir des informations détaillées sur les erreurs relatives à l'échec de l'opération.

Problèmes de surveillance et d'observabilité

CloudWatch Métriques manquantes

Problème : vous ne voyez pas les indicateurs attendus CloudWatch pour votre fournisseur de capacité ou vos fonctions.

Cause : Les métriques sont publiées à intervalles de 5 minutes. Il est possible que les indicateurs ne soient pas disponibles immédiatement pour les nouveaux fournisseurs de capacités ou les nouvelles fonctions.

Solution :

Attendez au moins 5 à 10 minutes après la publication d'une version de fonction avant de vous attendre à ce que les métriques apparaissent dans CloudWatch. Vérifiez que vous recherchez le bon espace de noms (AWS/Lambda) et les bonnes dimensions (CapacityProviderNameFunctionName, ouInstanceType).

Impossible de trouver les CloudWatch journaux

Problème : votre fonction s'exécute correctement, mais vous ne trouvez pas les journaux dans les CloudWatch journaux.

Cause : les instances gérées Lambda s'exécutent dans votre VPC et nécessitent une connectivité réseau pour envoyer les journaux aux journaux. CloudWatch Sans une configuration de connectivité VPC appropriée, vos fonctions ne peuvent pas atteindre le point de terminaison du service CloudWatch Logs.

Solution :

Configurez la connectivité VPC pour permettre à vos fonctions d'envoyer des journaux à CloudWatch Logs. Trois possibilités s’offrent à vous :

Option 1 : point de terminaison VPC pour les CloudWatch journaux (recommandé pour la production)

  1. Ouvrez la console Amazon VPC à l'adresse console.aws.amazon.com/vpc/.

  2. Dans le panneau de navigation, choisissez Points de terminaison.

  3. Choisissez Créer un point de terminaison.

  4. Pour Service category (Catégorie de service), choisissez Services AWS .

  5. Pour le nom du service, sélectionnez com.amazonaws.region.logs (remplacez region par votre AWS région).

  6. Pour le VPC, sélectionnez le VPC utilisé par votre fournisseur de capacité.

  7. Pour les sous-réseaux, sélectionnez les sous-réseaux dans lesquels vous souhaitez créer des interfaces réseau de point de terminaison. Pour une haute disponibilité, sélectionnez des sous-réseaux dans plusieurs zones de disponibilité.

  8. Pour les groupes de sécurité, sélectionnez les groupes de sécurité qui autorisent le trafic HTTPS entrant (port 443) depuis le groupe de sécurité de votre fonction.

  9. Activez le DNS privé pour le point de terminaison.

  10. Choisissez Créer un point de terminaison.

Option 2 : sous-réseau public avec passerelle Internet

Si votre fournisseur de capacité utilise des sous-réseaux publics, assurez-vous que :

  1. Une passerelle Internet est attachée à votre VPC

  2. La table de routage achemine le 0.0.0.0/0 trafic vers la passerelle Internet

  3. Les groupes de sécurité autorisent le trafic HTTPS sortant sur le port 443

Option 3 : sous-réseau privé avec passerelle NAT

Si votre fournisseur de capacité utilise des sous-réseaux privés, assurez-vous que :

  1. Une passerelle NAT existe dans un sous-réseau public

  2. La table de routage du sous-réseau privé achemine le 0.0.0.0/0 trafic vers la passerelle NAT

  3. La table de routage du sous-réseau public achemine 0.0.0.0/0 le trafic vers une passerelle Internet

  4. Les groupes de sécurité autorisent le trafic HTTPS sortant sur le port 443

Pour obtenir des instructions détaillées sur les options de connectivité VPC, consultez la section Connectivité VPC pour les instances gérées Lambda.

Difficulté à corréler les journaux à partir de demandes simultanées

Problème : les journaux des différentes demandes sont entrelacés, ce qui rend difficile le suivi des demandes individuelles.

Cause : L'entrelacement des journaux est un comportement normal et normal dans les systèmes multiconcurrents.

Solution :

  • Utiliser la journalisation structurée au format JSON : inclure l'ID de demande dans toutes les instructions du journal

  • Java : utilisez Log4j avec ThreadContext pour inclure automatiquement l'ID de demande

  • Node.js : à utiliser console.log() avec le formatage JSON et à inclure InvokeStore.getRequestId()

  • Python : utilisez le module de journalisation standard avec le formatage JSON et incluez context.request_id

Pour obtenir des instructions détaillées, consultez les pages de documentation spécifiques à l'environnement d'exécution.

Aide supplémentaire

Si vous continuez à rencontrer des problèmes après avoir essayé ces solutions :

  1. Révision CloudWatch des indicateurs : vérifiez les indicateurs du fournisseur de capacité et de l'environnement d'exécution pour identifier les contraintes de ressources ou les problèmes de dimensionnement.

  2. Vérifier les AWS CloudTrail journaux : consultez CloudTrail les journaux pour obtenir des informations détaillées sur les appels d'API et les erreurs.

  3. Contacter le AWS support : si vous ne parvenez pas à résoudre le problème, contactez le AWS support en fournissant des informations sur la configuration de votre fournisseur de capacité, la configuration des fonctions et les messages d'erreur spécifiques que vous rencontrez.

Étapes suivantes