Que dois-je faire pour que ma fonction Lambda fonctionne correctement avec mon instance Amazon EC2 ou le planificateur d'instance AWS ?

Date de la dernière mise à jour : 08/09/2021

J'utilise une instance Amazon Elastic Compute Cloud (Amazon EC2) ou le planificateur d'instance AWS avec une fonction AWS Lambda. Mais ma fonction Lambda échoue, ne parvient pas à appeler une autre fonction, ou renvoie des erreurs.

Brève description

Le planificateur d'instance AWS peut entraîner un dysfonctionnement de votre fonction Lambda pour les raisons suivantes :

  • Le kit SDK ne répond pas. Pour résoudre ce problème, suivez les étapes de la section Corriger les délais d'expiration du kit SDK.
  • Vous obtenez un délai d'expiration de fonction. Pour résoudre ce problème, suivez les étapes de la section Désactiver les délais d'expiration des fonctions.
  • Aucune règle Amazon CloudWatch Events n'a été déclenchée. Pour résoudre ce problème, suivez les étapes de la section Vérifier que votre règle planifiée a été appelée.
  • Votre fonction est en cours de limitation. Pour résoudre ce problème, suivez les étapes de la section Empêcher la limitation des fonctions.
  • Vous obtenez des appelles Lambda dupliquées. Pour résoudre ce problème, suivez les étapes de la section Prévenir les erreurs en utilisant l'idempotence.

Remarque : le planificateur d'instance AWS exécute les fonctions Lambda à des intervalles définis à l'aide d'une règle CloudWatch Events pour planifier la fonction Lambda. Il en résulte un appel asynchrone de la fonction Lambda, ce qui a un impact sur la gestion des erreurs de fonction. Si la fonction échoue en raison d'une erreur lors de l'exécution, par défaut, le même événement est relancé à deux reprises. Ensuite, l'événement est annulé. En cas de limitations, l'événement peut être mis en file d'attente jusqu'à six heures avant d'être annulé.

Résolution

Correction des délais d'expiration du kit SDK

Le délai d'expiration par défaut du kit SDK n'est pas remplacé dans les versions antérieures du planificateur d'instance AWS. Si l'appel d'API pour démarrer ou arrêter une instance prend plus de 60 secondes pour répondre dans les versions antérieures, la demande exporte le délai d'expiration.

Pour résoudre ce problème, téléchargez la dernière version du planificateur d'instance AWS ou modifiez la valeur read_timeout de votre objet Config Boto3 (sur le site web de Boto3). Par exemple :

import boto3
from botocore.config import Config

client_config = Config(read_timeout=890)

ec2 = boto3.client('ec2', config=client_config)

Désactiver les délais d'expiration des fonctions

Si le délai de votre fonction Lambda a expiré, vérifiez si la fonction attend de vérifier que l'instance EC2 a été lancée. Pour en savoir plus, consultez Pourquoi ne puis-je pas démarrer ou lancer mon instance EC2 ?

Les instances peuvent prendre quelques minutes avant d'atteindre l'état RUNNING. Votre fonction peut expiré si le temps nécessaire pour atteindre l'état RUNNING est supérieur au délai d'expiration configuré pour la fonction. Pour résoudre ce problème, augmentez le délai d'expiration de votre fonction en modifiant la valeur Timeout de 300 (5 minutes) dans votre modèle AWS CloudFormation. Vous devez disposer de suffisamment de temps pour que l'instance se lance avant que la fonction n'expire. Par exemple :

"Runtime": "python3.7",
"Timeout": 300,
"TracingConfig": {
    "Mode": "Active"
}

Remarque : les fonctions Lambda ont une valeur de délai d'expiration configurable maximale de 15 minutes.

Si votre fonction se trouve dans un cloud privé virtuel, vous devez autoriser votre fonction à accéder à Internet pour effectuer des appels vers l'API d'Amazon EC2.

Vérifier que votre règle planifiée a été appelée

Pour résoudre les problèmes liés à une fonction Lambda qui n'est pas appelée par CloudWatch Events, consultez Pourquoi ma fonction Lambda n'a-t-elle pas été déclenchée par ma règle CloudWatch Events ?

Empêcher la limitation des fonctions

Pour empêcher la limitation des fonctions, consultez Comment dépanner la limitation de fonction Lambda avec les erreurs « Dépassement de taux » et 429 « TooManyRequestsException » ?

Pour les appels asynchrones, les accélérations Lambda de votre compte peuvent affecter la capacité d'appel de votre fonction. Tous les appels asynchrones sont envoyés à une file d'attente d'événements avant d'être appelés. Si une autre fonction a également reçu un nombre élevé d'appels asynchrones, votre file d'attente d'événements peut être mis en attente. Cette attente ne signifie pas que votre fonction n'a pas pu être appelée. Elle signifie que l'événement a été retardé. Vous pouvez voir plusieurs appels une fois que l'attente de file d'attente d'événements est effacé. Par défaut, les événements de votre file d'attente d'événements asynchrones restent dans la file d'attente d'événements asynchrones jusqu'à six heures.

Prévenir les erreurs en utilisant l'idempotence

Pour éviter les erreurs liées aux doublons, rendez votre fonction Lambda idempotente lorsqu'elle est configurée avec un appel asynchrone.

N'oubliez pas que les appels Lambda asynchrones peuvent se produire plusieurs fois en raison de la cohérence éventuelle avec la file d'attente d'événements.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?