Pourquoi le traitement de mes flux DynamoDB prend-il autant de temps ?

Résolution

Lorsque vous utilisez AWS Lamdba pour consommer des flux DynamoDB, il se peut que certains enregistrements soient écrits dans une table mais qu’ils ne soient pas traités par Lambda. Le traitement de ces dossiers peut même prendre plusieurs heures. Pour résoudre le problème, examinez la métrique IteratorAge de Lambda.

Lorsque la métrique IteratorAge augmente, Lambda ne traite pas efficacement les enregistrements qui sont écrits dans le flux DynamoDB. La métrique IteratorAge peut augmenter pour les raisons suivantes.

Erreurs d'invocation

Lambda est conçu pour traiter des lots d'enregistrements en séquence et effectuer une nouvelle tentative en cas d'erreur. Si une fonction renvoie une erreur chaque fois qu'elle est invoquée, la fonction Lambda continue d'essayer de traiter les enregistrements. La fonction continue d'essayer de traiter les enregistrements jusqu'à ce qu'ils expirent ou qu'ils dépassent l'âge maximum configuré sur le mappage des sources d'événements. Étant donné que les enregistrements présents dans les flux ne sont pas en cours de traitement, un pic peut se produire dans la métrique IteratorAge. Vous pouvez vérifier que la métrique Erreurs Lambda ne présente pas de pics dans la métrique d’erreurs. Vous pouvez également consulter vos journaux Lambda pour plus d'informations.

Pour éviter que les erreurs d'invocation ne provoquent un pic dans la métrique IteratorAge, envoyez les enregistrements vers une file d'attente de lettres mortes (DLQ). Lorsque vous créez le mappage des sources d'événements, saisissez les informations suivantes pour les paramètres spécifiques :

• Nombre de nouvelles tentatives : Ce paramètre est le nombre de fois que la fonction lambda s'exécute en cas d'erreur. Mettez à jour cette valeur en fonction de votre cas d'utilisation et envoyez les enregistrements à la DLQ après que la fonction ait effectué un certain nombre de nouvelles tentatives.
• Fractionner le lot en cas d'erreur : Ce paramètre divise un lot en deux lots avant que la fonction n’effectue une nouvelle tentative sur le lot. Utilisez ce paramètre pour fractionner le lot et poursuivre l'invocation avec les lots de plus petite taille. La division du lot peut aider à isoler les enregistrements erronés à l'origine de l'erreur d'invocation.

Erreurs de limitation

Lorsque vous utilisez des flux DynamoDB, il est recommandé de ne pas avoir plus de deux consommateurs par partition afin d'éviter toute limitation. Dans la mesure où Lambda traite les enregistrements de manière séquentielle, il ne peut pas continuer à traiter les enregistrements si une invocation en cours est limitée. Si vous devez utiliser plus de deux consommateurs, utilisez Amazon Kinesis ou un modèle de diffusion en éventail. Pour Lambda, utilisez une limite de simultanéité dans Lambda afin d’éviter toute limitation.

Débit Lambda

Le débit lambda est le temps nécessaire à une invocation unique d'une fonction lambda pour traiter un enregistrement ou un lot d'enregistrements. Les facteurs suivants peuvent affecter le débit d'une fonction Lambda :

Durée d'exécution

Si la valeur de la ](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html#monitoring-metrics-performance)métrique Durée[ est élevée, le débit de la fonction est faible et entraîne une augmentation de la métrique IteratorAge pour la fonction. Pour réduire la durée d'exécution de la fonction, augmentez la mémoire allouée à celle-ci.

Vous pouvez également optimiser votre code de fonction afin de réduire le temps nécessaire au traitement des enregistrements.

Exécutions Lambda simultanées

La simultanéité est le nombre de requêtes en cours d’envoi que votre fonction Lambda gère simultanément. Une augmentation du nombre d'appels Lambda simultanés peut améliorer le traitement de vos enregistrements de flux. Pour chaque requête simultanée, Lambda provisionne une instance distincte de votre environnement d'exécution. Le nombre maximal d’exécutions Lambda simultanées est calculé comme suit :
Exécutions simultanées = nombre de partitions x lots simultanés par partition (facteur de parallélisation)

Dans un flux DynamoDB, il existe un mappage biunivoque entre le nombre de partitions de la table et le nombre de partitions de flux. Le nombre de partitions est déterminé par la taille de la table et son débit. Chaque partition de la table peut accepter jusqu'à 3 000 unités de requête de lecture ou 1 000 unités de requête d'écriture, ou une combinaison linéaire des deux. Aussi, pour accroître la simultanéité, augmentez la capacité provisionnée de la table afin d'augmenter le nombre de partitions. Vous pouvez configurer le nombre de lots simultanés par partition dans le mappage des sources d'événements. La valeur par défaut est 1 et peut être augmentée jusqu'à 10. Par exemple, si la table compte 10 partitions et que le nombre de lots simultanés par partition est défini sur 5, vous pouvez avoir jusqu'à 50 exécutions simultanées.

Pour traiter la modification au niveau de l’élément dans le bon ordre à tout moment, les éléments dotés de la même clé de partition sont placés dans le même lot. La clé de partition de votre table doit avoir une cardinalité élevée et votre trafic ne peut pas générer de touches de raccourci. Par exemple, si vous définissez la valeur de Lots simultanés par partition sur 10 et que votre trafic en écriture cible une seule clé de partition, vous ne pouvez avoir qu'une seule exécution simultanée par partition.

Taille du lot et fenêtre de traitement par lots

Le comportement de traitement par lots de Lambda peut réduire le débit de la fonction lorsqu'il n'est pas correctement réglé. Pour optimiser le traitement de vos flux DynamoDB, ajustez la fenêtre de traitement par lots et la taille du lot en fonction de votre cas d'utilisation.

Si la taille du lot est définie sur une valeur trop faible, la fonction est fréquemment invoquée avec un petit nombre d'enregistrements. Ces appels fréquents ralentissent le traitement du flux. Si la valeur de taille du lot est trop élevée, la durée de votre fonction peut augmenter.

Si la valeur de la fenêtre de traitement par lots et le nombre d'enregistrements de cette fenêtre ne sont pas optimisés, il se peut que le même fragment soit invoqué de manière inutile. Ces invocations inutiles peuvent ralentir le traitement du flux. Si la valeur de la fenêtre de traitement par lots est trop élevée, vous risquez d'attendre plus longtemps pour que la fonction traite les flux. Ce temps de traitement plus long augmente la valeur de IteratorAge.

Pour augmenter votre débit et diminuer la valeur de IteratorAge, il est recommandé de tester plusieurs combinaisons de fenêtre de traitement par lots et de taille de lot.

Informations connexes

Métriques de performance

Comprendre la mise à l’échelle et le débit de Lambda

Comprendre la mise à l'échelle des fonctions Lambda

Utilisation de l'adaptateur Amazon Kinesis DynamoDB Streams pour traiter les enregistrements de flux

DynamoDB Streams et déclencheurs Lambda