Questa è una domanda comune sulla elaborazione degli eventi in Kinesis e cercherò di darvi alcuni punti per costruire la vostra funzione Lambda per gestire tali problemi con i dati "corrotti". Poiché è buona pratica che parti separate del sistema vengano scritte nello stream di Kinesis e in altre parti che leggono dallo stream di Kinesis, è normale che si abbiano tali problemi.
Primo, perché si verificano tali eventi problematici?
L'utilizzo di Kinesis per elaborare gli eventi è un buon modo per suddividere un sistema complesso che esegue sia l'elaborazione front-end (che serve gli utenti finali), sia l'elaborazione back-end di codice/allo stesso tempo (analizzando gli eventi), in due parti indipendenti del tuo sistema. Le persone front-end possono concentrarsi sulla propria attività, mentre le persone di back-end non hanno bisogno di spingere le modifiche del codice al front-end, se vogliono aggiungere funzionalità per servire i loro casi d'uso analitici. Kinesis è un buffer di eventi che interrompe entrambi la necessità di sincronizzazione e semplifica il codice di logica aziendale.
Pertanto, vorremmo eventi scritti nel flusso di essere flessibili nella loro "schema", e se le squadre di front-end desiderano cambiare il formato dell'evento, aggiungere campi, eliminare i campi, modificare il protocollo o la chiavi di crittografia, dovrebbero essere in grado di farlo tutte le volte che vogliono.
Ora spetta ai team che stanno leggendo dal flusso di essere in grado di elaborare tali eventi flessibili in modo efficiente, e non interrompere il loro trattamento ogni volta che tale cambiamento sta accadendo. Pertanto, dovrebbe essere comune che la funzione Lambda visualizzerà eventi che non è in grado di elaborare e "poison-pill" non è un evento raro come ci si potrebbe aspettare.
Secondo, come gestisci tali eventi problematici?
La funzione Lambda riceverà un lotto di eventi da elaborare. Si prega di notare che non si dovrebbero ottenere gli eventi uno per uno, ma in grandi lotti di eventi. Se i tuoi batch sono troppo piccoli, otterrai rapidamente ritardi nel flusso.
Per ogni batch si itererà sugli eventi, li elaborerà e quindi si verificherà in DynamoDB l'ultimo ID di sequenza del batch. Lambda sta facendo la maggior parte di questi passi automaticamente (vedere di più qui: http://docs.aws.amazon.com/lambda/latest/dg/walkthrough-kinesis-events-adminuser-create-test-function.html):
console.log('Loading function');
exports.handler = function(event, context) {
console.log(JSON.stringify(event, null, 2));
event.Records.forEach(function(record) {
// Kinesis data is base64 encoded so decode here
payload = new Buffer(record.kinesis.data, 'base64').toString('ascii');
console.log('Decoded payload:', payload);
});
context.succeed();
};
Questo è ciò che sta accadendo nel "percorso felice" , se tutti gli eventi vengono elaborati senza alcun problema. Ma se si incontrano problemi nel batch e non si "commit" gli eventi con la notifica di esito positivo, il batch avrà esito negativo e si otterranno di nuovo tutti gli eventi nel batch.
Ora è necessario decidere qual è il motivo dell'errore nell'elaborazione.
temporanea problema (throttling, problema di rete ...) - è ok per aspettare un secondo e riprovare per un paio di volte. In molti casi il problema si risolverà da solo.
Occasional Problema (memoria insufficiente ...) - è preferibile aumentare l'allocazione di memoria della funzione Lambda o ridurre la dimensione del batch. In molti casi tale modifica risolverà il problema.
costante fallimento - significa che si deve ignorare l'evento problematico (metterlo in una DLQ - dead-letter-coda) o modificare il codice per gestire la cosa.
Il problema è identificare il tipo di errore nel codice e gestirlo in modo diverso. Devi scrivere il tuo codice Lambda in un modo per identificarlo (tipo di eccezione, ad esempio) e reagire in modo diverso.
È possibile utilizzare l'integrazione con CloudWatch per scrivere tali errori sulla console e creare gli allarmi pertinenti. È possibile utilizzare i registri di CloudWatch anche come modo per registrare la "coda di messaggi non recapitabili" e vedere qual è la fonte del problema.
Sembra ragionevole, ma solo una breve domanda sul bit DynamoDb, perché devo mantenere la posizione (presumo intendete il numero di sequenza)? – Stefano
Perché quando si interrompe un nodo "Kinesis Consumer Application" e si avvia successivamente; dovresti essere in grado di continuare dall'ultimo punto che eri. – az3
Ah sì, questo ha senso. – Stefano