4
votes

Exécuter un lambda sur chaque entrée DynamoDb dans les délais?

Existe-t-il un moyen d'exécuter un Lambda sur chaque enregistrement de table DynamoDb?

J'ai une table Dynamo avec nom, nom, e-mail et un Lambda qui prend nom, nom, e-mail comme paramètres. J'essaye de configurer l'environnement de telle sorte que, chaque jour, le Lambda s'exécute automatiquement pour chaque valeur qu'il trouve dans Dynamo; ne peut pas faire tous les enregistrements dans un Lambda car il ne sera pas mis à l'échelle (expirera une fois que d'autres utilisateurs seront ajoutés).

J'ai actuellement une règle CloudWatch configurée qui déclenche le lambda dans les délais, mais j'ai dû ajouter manuellement les paramètres au déclencheur de Dynamo - Ce n'est pas automatique et pas dynamique / non connecté à la dynamo.

-

Une autre option serait d'exécuter un lambda à chaque fois qu'un enregistrement DynamoDb est mis à jour ... Je pourrais mettre à jour tous les enregistrements chaque semaine, puis lors de leur mise à jour, le Lambda serait déclenché mais je ne sais pas non plus si c'est possible.

/ p>

Un aperçu de l'une ou l'autre de ces approches serait apprécié!


0 commentaires

3 Réponses :


3
votes

Existe-t-il un moyen d'exécuter un Lambda sur chaque enregistrement de table DynamoDb?

Pour votre cas spécifique où tout ce que vous voulez faire est de traiter chaque ligne d'une table DynamoDB de manière évolutive, j'essaierais d'utiliser un fanout Lambda -> SQS -> Lambdas comme ceci:

  1. Configurez une règle d'événements CloudWatch qui se déclenche selon un calendrier. Faites en sorte que cela déclenche une fonction Lambda dispatch .

  2. Le travail de la fonction Lambda dispatch est de lire toutes les entrées de votre table DynamoDB et d'écrire des messages dans une file d'attente jobs SQS, une par élément DynamoDB.

  3. Créez une fonction Lambda worker qui fait tout ce que vous voulez avec un élément donné de votre table DynamoDB.

  4. Connectez le worker Lambda à la file d'attente SQS jobs afin qu'une instance de celui-ci soit distribuée chaque fois que quelque chose est mis dans la file d'attente.

    < / li>

3 commentaires

J'ai trouvé ce super tutoriel sur la façon de faire exactement cela, merci pour le conseil! youtube.com/watch?v=lQvTubduQwQ


Étape 2 ; lorsque j'envoie un lambda pour analyser toutes les entrées du DDB, je ne peux pas le terminer. Étant donné que la limite est de 15 minutes, je ne sais pas trop comment procéder. Mon DDB est de 200 Go


Découvrez les destinations Lambda - une nouvelle fonctionnalité qui vous permet d'appeler un lambda de manière asynchrone, en lui indiquant ce qu'il faut faire lorsqu'il se termine. Demandez à votre distribution lambda de demander une page d'éléments de votre table DDB via l'opération d'analyse, de lancer tous les éléments de cette page de résultats dans SQS, puis d'appeler un autre lambda, via Lambda Destinations, pour traiter la page de résultats suivante (en passant le jeton de pagination renvoyé de la première page de résultats). Plus d'informations sur les destinations ici aws.amazon.com/blogs/compute/ …



2
votes

Le facteur limitant étant les délais d'expiration lambda, exécutez plusieurs lambdas à l'aide des fonctions step. Effectuer un scan paginé de la table; chaque lambda renverra le LastEvaluatedKey et le passera au prochain appel de la page suivante.


1 commentaires

Pour améliorer la concurrence, vous pouvez également effectuer un scan parallèle avec plusieurs lambdas commençant à différents segments.



1
votes

Je pense que votre meilleure option est, comme vous l'avez souligné, d'exécuter un Lambda chaque fois qu'un enregistrement DynamoDB est mis à jour. Ceci est possible grâce aux flux DynamoDB .

Les flux sont un enregistrement ordonné des modifications apportées à une table. Celles-ci peuvent appeler un Lambda, donc c'est automatique (cependant attention, le changement n'apparaît qu'une seule fois dans le flux, configurez un DLQ en cas d'échec de votre Lambda). Cette approche évolue bien et est également assez évolutive. Si besoin est, vous pouvez soit pousser les événements du flux vers un SQS ou Kinesis, soit distribuer, etc., en fonction des besoins.


1 commentaires

Je ne pense pas que DLQ n'est pas nécessaire, AWS Lambda gère les flux DynamoDb comme les flux Kinesis: le traitement s'arrêtera lorsqu'une erreur est générée pour un enregistrement dans le flux. Tout est retenté jusqu'à ce qu'il réussisse ou expire. docs.aws.amazon.com/lambda/latest/dg/ with-ddb.html