Kinesis Lambda Taille de lot minimum du consommateur

Question

J'utilise AWS Lambda (node.js) en tant que client AWS Kinesis. Je peux voir que vous pouvez définir une taille de lot maximale, mais je me demande si je peux définir une taille de lot minimum. Alors que je peux assurer que chaque lambda gérera au moins 50 (ou n'importe quel nombre) des enregistrements. Je souhaiterais avoir une taille de lot minimum car le consommateur lambda établira une connexion à une instance RDS MySQL et j'essaye de maintenir le nombre de connexions simultanées à un bas niveau.

S'il n'y a pas de fonctionnalité de configuration qui définirait un minimum, des idées de contournement seraient appréciées.

Merci.

Answer 1

Première question: combien de fragments avez-vous ouverts dans le flux? Vous obtenez seulement 1 instance du lambda par fragment en cours d'exécution. Donc, si vous n'avez qu'un seul fragment, vous n'aurez qu'un seul lambda à la fois sur votre instance RDS.

Avez-vous des données qui indiquent que c'est un problème?

Ce qui suit est un pirater qui peuvent ou peuvent ne pas fonctionner de manière fiable. Et ne devrait probablement pas être utilisé dans un environnement prod.

Pour une taille de lot minimum, vous pouvez renvoyer un error à partir de votre fonction node.js lambda si la taille du lot est inférieure au nombre d'enregistrements souhaité.

E.g.

handler(event, context, callback) { 
    const records = event.Records; 
    if (records.length() < minBatchSize) { 
    callback('insufficient batch size'); 
    } else { 
    processRecords(records, callback); 
    } 
} 

MAIS deux problèmes viennent à l'esprit:

1) Vous ne pouvez pas le faire indéfiniment sans courir le risque de perte de données car il y a une limite de temps maximale de l'événement qui est configuré sur votre flux. Après cette heure, les enregistrements disparaissent du flux. Notez que vous payez un supplément pour cette fonctionnalité (voir extended data retention).

Vous pouvez déduire l'âge du lot à partir des métriques d'âge de l'itérateur de fragment lambda/kinesis, voir http://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html.

Je ne suis pas sûr de la fiabilité de ceci, surtout si vous avez plus d'un fragment, mais par ex.

handler(event, context, callback) { 
    const records = event.Records; 
    if (records.length() < minBatchSize) { 
    if (calculateLambdaAge() > tooLongDelayThreshold) { 
     processRecords(records, callback); 
    } else { 
     callback(new Error('insufficient batch size')); 
    } 
    } else { 
    processRecords(records, callback); 
    } 
} 

calculateLambdaAge() { 
    // interrogate cloudwatch 
} 

Si CloudWatch ne vous dira pas, vous devrez peut-être de garder une trace de vous-même quelque part qui est au moins aussi évolutive que votre RDS (Redis/dynamo). 2) Plutôt que de vous efforcer de rendre le # 1 fiable, est-ce que cet effort supplémentaire pourrait simplement être utilisé pour augmenter la taille de votre instance RDS et rendre votre utilisation actuelle plus efficace?

---

J'ai parlé this et this lors de la constitution des échantillons de code.