Mappage de source d’événement Lambda

Note

Si vous voulez envoyer des données à une cible autre qu'une fonction Lambda ou enrichir les données avant de les envoyer, consultez Amazon EventBridge Pipes.

Un mappage de source d’événement est une ressource Lambda qui lit à partir d’une source d’événement et appelle une fonction Lambda. Vous pouvez utiliser des mappages de source d’événement pour traiter des éléments d’un flux ou d’une file d’attente dans des services qui n’appellent pas directement des fonctions Lambda. Cette page décrit les services que Lambda fournit pour le mappage des sources d'événements et la manière de régler avec précision le comportement de mise en lots.

Services à partir desquels Lambda lit les événements

• Amazon DynamoDB

• Amazon Kinesis

• Amazon MQ

• Amazon Managed Streaming for Apache Kafka (Amazon MSK)

• Self-managed Apache Kafka

• Amazon Simple Queue Service (Amazon SQS)

• Amazon DocumentDB (compatible avec MongoDB) (Amazon DocumentDB)

Un mappage de source d’événement utilise les autorisations du rôle d’exécution de la fonction pour lire et gérer des éléments dans la source de l’événement. Les autorisations, la structure des événements, les paramètres et le comportement d’interrogation varient selon la source de l’événement. Pour en savoir plus, consultez la rubrique liée pour le service que vous utilisez en tant que source d’événement.

Pour gérer une source d’événement à l’aide de la AWS Command Line Interface (AWS CLI) ou d’un SDKAWS, vous pouvez utiliser les opérations d’API suivantes :

• CreateEventSourceMapping

• ListEventSourceMappings

• GetEventSourceMapping

• UpdateEventSourceMapping

• DeleteEventSourceMapping

Note

Lorsque vous mettez à jour, désactivez ou supprimez un mappage des sources d'événements pour Amazon MQ, Amazon MSK, Apache Kafka autogéré ou Amazon DocumentDB, la prise en compte de vos modifications peut prendre jusqu'à 15 minutes. Avant la fin de cette période, votre mappage des sources d'événements peut continuer à traiter les événements et à invoquer votre fonction à l'aide de vos paramètres précédents. Cela est vrai même lorsque l'état du mappage des sources d'événements affiché dans la console indique que vos modifications ont été appliquées.

L'exemple suivant utilise la AWS CLI pour mapper une fonction nommée my-function à un flux DynamoDB spécifiée par son Amazon Resource Name (ARN), avec une taille de lot de 500.

aws lambda create-event-source-mapping --function-name my-function --batch-size 500 --maximum-batching-window-in-seconds 5 --starting-position LATEST \
--event-source-arn arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2019-06-10T19:26:16.525

Vous devriez voir la sortie suivante :

{
    "UUID": "14e0db71-5d35-4eb5-b481-8945cf9d10c2",
    "BatchSize": 500,
    "MaximumBatchingWindowInSeconds": 5,
    "ParallelizationFactor": 1,
    "EventSourceArn": "arn:aws:dynamodb:us-east-2:123456789012:table/my-table/stream/2019-06-10T19:26:16.525",
    "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
    "LastModified": 1560209851.963,
    "LastProcessingResult": "No records processed",
    "State": "Creating",
    "StateTransitionReason": "User action",
    "DestinationConfig": {},
    "MaximumRecordAgeInSeconds": 604800,
    "BisectBatchOnFunctionError": false,
    "MaximumRetryAttempts": 10000
}

Les mappages de sources d'événements Lambda traitent les événements au moins une fois en raison de la nature distribuée de ses pollers. Par conséquent, votre fonction Lambda peut recevoir des événements dupliqués dans de rares situations. Suivre Bonnes pratiques d'utilisation des fonctions AWS Lambda et créez des fonctions idempotentes pour éviter les problèmes liés aux événements dupliqués.

Comportement de traitement par lots

Les mappages de source d’événements lisent les éléments d’une source d’événement cible. Par défaut, un mappage de source d’événements regroupe des enregistrements dans une même charge utile que Lambda envoie à votre fonction. Pour affiner le comportement du traitement par lots, vous pouvez configurer une fenêtre de traitement par lots (MaximumBatchingWindowInSeconds) et une taille de lot (BatchSize). Une fenêtre de traitement par lots représente l’intervalle de temps maximal pour collecter des enregistrements dans une même charge utile. La taille d’un lot est le nombre maximal d’enregistrements dans un même lot. Lambda appelle votre fonction en présence de l’un des trois critères suivants :

• La fenêtre de traitement par lots atteint sa valeur maximale. Le comportement de la fenêtre de traitement par lots varie selon la source d’événement spécifique.

  • Pour les sources d’événements Kinesis, DynamoDB et Amazon SQS : la fenêtre de traitement par lot par défaut est de 0 seconde. Cela signifie que Lambda envoie des lots à votre fonction le plus rapidement possible. Si vous configurez un MaximumBatchingWindowInSeconds, la fenêtre de traitement par lots suivante commence dès que l’appel de fonction précédent est terminé.

  • Pour les sources d'événements Amazon MSK, Apache Kafka autogérées, Amazon MQ et Amazon DocumentDB : la fenêtre de traitement par lots par défaut est de 500 ms. Vous pouvez configurer MaximumBatchingWindowInSeconds à n’importe quelle valeur comprise entre 0 et 300 secondes par incréments de secondes. Une fenêtre de traitement par lots commence dès l’arrivée du premier registre.

    Note

    Parce que vous ne pouvez que changer MaximumBatchingWindowInSeconds par incréments de secondes, vous ne pouvez pas revenir à la fenêtre de traitement par lots par défaut de 500 ms après l’avoir modifiée. Pour restaurer la fenêtre de traitement par lots par défaut, vous devez créer un mappage de source d’événement.

• La taille du lot est atteinte. La taille minimale du lot est de 1. La taille par défaut et la taille maximale du lot dépendent de la source d’événement. Pour plus d’informations sur ces valeurs, consultez la spécification BatchSize pour l’opération de l’API CreateEventSourceMapping.

• La taille de la charge utile atteint 6 Mo. Vous ne pouvez pas modifier cette limite.

Le diagramme suivant illustre ces trois conditions. Supposons qu’une fenêtre de traitement par lots commence à t = 7 secondes. Dans le premier scénario, la fenêtre de traitement par lots atteint son maximum de 40 secondes à t = 47 secondes après avoir accumulé 5 enregistrements. Dans le second scénario, la taille du lot atteint 10 avant l’expiration de la fenêtre de traitement par lots, de sorte que la fenêtre de traitement par lots se termine plus tôt. Dans le troisième scénario, la taille maximale de la charge utile est atteinte avant l’expiration de la fenêtre de traitement par lots, de sorte que la fenêtre de traitement par lots se termine plus tôt.

L’exemple suivant montre un mappage de source d’événement qui effectue une lecture à partir d’un flux Kinesis. Si un lot d’événements échoue à toutes les tentatives de traitement, le mappage de source d’événement envoie les détails du lot à une file d’attente SQS.

Le lot d’événements correspond à l’événement que Lambda envoie à la fonction. Il s’agit d’un lot de registres ou de messages compilés à partir des éléments que le mappage de source d’événement lit jusqu’à l’expiration de la fenêtre de lot actuelle.

Pour les flux Kinesis et DynamoDB, un mappage des sources d'événements crée un itérateur pour chaque partition dans le flux et traite les éléments dans chaque partition dans l'ordre. Vous pouvez configurer le mappage de source d’événement pour lire uniquement les nouveaux éléments qui apparaissent dans le flux, ou pour démarrer avec des éléments plus anciens. Les éléments traités ne sont pas supprimés du flux et peuvent être traités par d’autres fonctions ou d’autres consommateurs.

Lambda envoi le prochain lot pour traitement sans attendre que les Extensions Lambda configurées soient terminées. En d'autres termes, vos extensions peuvent continuer à s'exécuter pendant que Lambda traite le prochain lot d'enregistrements. Cela peut causer des problèmes de limitation si vous enfreignez l'un des paramètres ou l'une des limites de simultanéité de votre compte. Pour détecter s'il s'agit d'un problème éventuel, surveillez vos fonctions et vérifiez si vous observez des métriques de simultanéité plus élevées que prévu pour votre mappage des sources d'événements.

Par défaut, si votre fonction renvoie une erreur, le mappage de la source d’événements retraite l’ensemble du lot jusqu’à ce que la fonction réussisse ou que les éléments du lot arrivent à expiration. Pour s’assurer d’un traitement dans l’ordre, le mappage de la source d’événement met en pause le traitement dans la partition concernée jusqu’à la résolution de l’erreur. Vous pouvez configurer le mappage des sources d'événements pour ignorer les anciens événements ou traiter plusieurs lots en parallèle. Si vous traitez plusieurs lots en parallèle, le traitement dans l’ordre est toujours garanti pour chaque clé de partition, mais le mappage de la source d’événement traite simultanément plusieurs clés de partition dans la même partition.

Pour les sources de flux (DynamoDB et Kinesis), vous pouvez configurer le nombre maximal de tentatives que Lambda effectue lorsque votre fonction renvoie une erreur. Les erreurs de service ou les limitations où le lot n'atteint pas votre fonction ne comptent pas dans les tentatives de réessai.

Vous pouvez également configurer le mappage de source d’événement pour envoyer un enregistrement d’appel à un autre service lorsqu’il rejette un lot d’événements. Lambda prend en charge les destinations suivantes pour les mappages de source d’événement.

• Amazon SQS – File d’attente SQS.

• Amazon SNS – Rubrique SNS.

L’enregistrement d’appel contient des détails sur le lot d’événements ayant échoué au format JSON.

L’exemple suivant illustre un enregistrement d’appel pour un flux Kinesis.

Exemple enregistrement d’appel

{
    "requestContext": {
        "requestId": "c9b8fa9f-5a7f-xmpl-af9c-0c604cde93a5",
        "functionArn": "arn:aws:lambda:us-east-2:123456789012:function:myfunction",
        "condition": "RetryAttemptsExhausted",
        "approximateInvokeCount": 1
    },
    "responseContext": {
        "statusCode": 200,
        "executedVersion": "$LATEST",
        "functionError": "Unhandled"
    },
    "version": "1.0",
    "timestamp": "2019-11-14T00:38:06.021Z",
    "KinesisBatchInfo": {
        "shardId": "shardId-000000000001",
        "startSequenceNumber": "49601189658422359378836298521827638475320189012309704722",
        "endSequenceNumber": "49601189658422359378836298522902373528957594348623495186",
        "approximateArrivalOfFirstRecord": "2019-11-14T00:38:04.835Z",
        "approximateArrivalOfLastRecord": "2019-11-14T00:38:05.580Z",
        "batchSize": 500,
        "streamArn": "arn:aws:kinesis:us-east-2:123456789012:stream/mystream"
    }
}

Lambda prend également en charge le traitement dans l’ordre pour les files d’attente FIFO (premier entré, premier sorti), en effectuant une augmentation d’échelle en fonction du nombre de groupes de messages actifs. Pour les files d’attente standard, les éléments ne sont pas nécessairement traités dans l’ordre. Lambda adapte son échelle pour traiter une file d’attente standard le plus rapidement possible. Lorsqu’une erreur se produit, Lambda renvoie les lots à la file d’attente en tant qu’éléments individuels et peut les traiter dans un regroupement différent de celui du lot d’origine. Parfois, le mappage de source d’événement peut recevoir deux fois le même élément de la file d’attente, même en l’absence d’erreur de fonction. Lambda supprime de la file d’attente les éléments qui ont été traités avec succès. Vous pouvez configurer la file d’attente source pour envoyer des éléments vers une file d’attente de lettres mortes si Lambda ne peut pas les traiter.

Pour en savoir plus sur les services qui appellent directement des fonctions Lambda, consultez Utilisation de AWS Lambda avec d'autres services.