View a markdown version of this page

Résolution des problèmes liés aux instances gérées Lambda - AWS Lambda
Problèmes de limitation et de dimensionnementProblèmes de simultanéitéProblèmes de performanceProblèmes liés aux fournisseurs de capacitésProblè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 limitation et de dimensionnement

étranglement occasionnel

Problème : vous rencontrez des erreurs d'étranglement (HTTP 429) pendant les opérations normales.

Cause : Les instances gérées Lambda peuvent rejeter les nouvelles invocations afin de protéger les appels déjà en cours. Si le taux d'utilisation de vos environnements d'exécution est constamment élevé, les nouvelles invocations peuvent être limitées.

Solution :

  • Surveillez les indicateurs de dimensionnement : examinez le graphique des raisons de l'étranglement pour comprendre la raison des problèmes d'étranglement et de mise à l'échelle des capacités. Dans l'exemple suivant, un processeur trop élevé provoque des ralentissements.

  • Vérifiez la configuration des fonctions : assurez-vous que la mémoire de vos fonctions et les paramètres du processeur virtuel prennent en charge les exécutions multisimultanées. Augmentez la mémoire des fonctions ou l'allocation du processeur virtuel si nécessaire. S'il ExecutionEnvironmentVCPUUtilization est élevé, essayez d'ajouter plus de processeurs virtuels par fonction.

    aws lambda update-function \
  --function-name my-function \
  ...
  --memory-size 8192

    S'il ExecutionEnvironmentMemoryUtilization est élevé, essayez d'ajouter de la mémoire par processeur virtuel :

    aws lambda update-function \
  --function-name my-function \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "ExecutionEnvironmentMemoryGiBPerVCpu": 4.0
    }
  }'

Accélérations lors de la mise à l'échelle

Problème : vous rencontrez des erreurs de limitation (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 multisimultanéité. Si votre trafic fait plus que doubler en 5 minutes, vous risquez de rencontrer des problèmes à mesure que Lambda fait évoluer les instances et les environnements d'exécution pour répondre à la demande.

Solutions :

  • 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 plus faible afin de conserver une marge de manœuvre supplémentaire en cas de rafales de trafic.

    aws lambda create-capacity-provider \
  --name my-capacity-provider \
  ...
  --capacity-provider-scaling-config '{
    "ScalingMode": "Manual",
    "ScalingPolicies": [
      {
        "PredefinedMetricType": "LambdaCapacityProviderAverageCPUUtilization",
        "TargetValue": 30.0
      }
    ]
  }'

  • Pre-warm capacité : pour les augmentations de trafic planifiées, utilisez l'PutFunctionScalingConfigAPI pour préchauffer la capacité supplémentaire.

    aws lambda put-function-scaling-config \
  --function-name my-function \
  --qualifier 1 \
  --function-scaling-config '{
    "MinExecutionEnvironments": 100
  }'

Réduction lente

Problème : les instances mettent beaucoup de temps à être réduites après une diminution du trafic.

Cause : Les instances gérées Lambda sont progressivement réduites pour maintenir la disponibilité et éviter les changements de capacité rapides qui pourraient 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 statistiques pour suivre le nombre d'instances en cours d'exécution.

Problèmes de simultanéité

Environnements d'exécution avec de faibles limites d'expérience de simultanéité

Problème : Vos fonctions sont ralenties malgré la disponibilité de la capacité.

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

Solutions :

  • Augmentez la simultanéité maximale : si les invocations de vos fonctions utilisent très peu de processeur, augmentez le paramètre de simultanéité maximale à 64 par processeur virtuel.

    aws lambda update-function \
  --function-name ordering-api-backend \
  --capacity-provider-config '{
    "LambdaManagedInstancesCapacityProviderConfig": {
      "PerExecutionEnvironmentMaxConcurrency": 32
    }
  }'

  • Optimisez le code de fonction : révisez votre code de fonction pour réduire la consommation du processeur par appel, ce qui permet une plus grande simultanéité.

  • Réglez la mémoire des fonctions et le processeur virtuel : 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 se heurte à des conditions de concurrence lorsqu'elle est chargée.

Cause : plusieurs threads exécutent la méthode du gestionnaire simultanément et l'état partagé n'est pas sécurisé pour les threads.

Solution :

  • Utilisez AtomicInteger ou AtomicLong pour les 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

  • Accédez aux ID de trace depuis l'objet Lambda Context, et non depuis les variables d'environnement

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

Problèmes d'isolation des états (Node.js exécution)

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

Cause : Les variables globales sont partagées lors d'appels simultanés sur le même thread de travail. Lorsque les opérations asynchrones permettent de contrôler, 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 les ID de demande

  • Accédez aux ID de trace en utilisant InvokeStore.getXRayTraceId() plutôt des variables d'environnement

Pour obtenir des conseils détaillés, consultez la documentation relative à l'Node.js environnement d'exécution 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 à partir de fichiers au format/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 des ID de demande : /tmp/request_{context.request_id}.txt

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

  • Nettoyez les fichiers temporaires avec os.remove() After Use

Pour obtenir des conseils détaillés, 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 présentent une forte utilisation de la mémoire ou des erreurs de mémoire insuffisante.

Cause : Chaque requête 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 réglage 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 pendant l'initialisation

Des performances incohérentes

Problème : les performances des fonctions varient considérablement d'une invocation à 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 indicateurs au niveau de l'instance : effectuez un suivi 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és

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 de fonction sur 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 de votre fonction comme ACTIVE. Cela prend généralement plusieurs minutes.

Impossible de supprimer le fournisseur de capacité

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

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

Solution :

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

  2. Supprimez ou mettez à jour ces versions de fonctions pour supprimer l'association de 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 des fonctions.

Solution :

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

  • Vérifiez la configuration du fournisseur de capacité : confirmez 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érifiez 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 mesures attendues CloudWatch pour votre fournisseur de capacité ou vos fonctions.

Cause : Les métriques sont publiées à intervalles de 5 minutes. Les nouveaux fournisseurs de capacité ou les nouvelles fonctions peuvent ne pas disposer de métriques immédiatement.

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 l'espace de noms (AWS/Lambda) et les dimensions (CapacityProviderNameFunctionName, ouInstanceType) corrects.

Impossible de trouver les CloudWatch journaux

Problème : Votre fonction s'exécute correctement, mais vous ne trouvez pas de 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 des journaux à CloudWatch Logs. Sans 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 CloudWatch journaux à 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. Dans le champ Nom du service, sélectionnez com.amazonaws.region.logs (remplacez region par votre AWS région).

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

  7. Pour Sous-réseaux, sélectionnez les sous-réseaux dans lesquels vous souhaitez créer des interfaces réseau de terminaux. Pour assurer la haute disponibilité, sélectionnez les 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) à partir du groupe de sécurité de votre fonction.

  9. Activez le DNS privé pour le terminal.

  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 connecté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 des sous-réseaux publics 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 conseils détaillés sur les options de connectivité VPC, consultez la section Connectivité VPC pour les instances gérées Lambda.

Difficulté à corréler les journaux des 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 multisimultanés.

Solution :

  • Utilisez la journalisation structurée au format JSON : incluez l'ID de demande dans toutes les instructions de 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 au format JSON et incluez context.request_id

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

Aide supplémentaire

Si les problèmes persistent après avoir essayé ces solutions :

  1. Analysez CloudWatch les métriques : vérifiez les métriques du fournisseur de capacité et de l'environnement d'exécution pour identifier les contraintes en matière de ressources ou les problèmes de dimensionnement.

  2. Consultez AWS CloudTrail les 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