Un sito web ad alto traffico è in esecuzione su EC2 e utilizza Kinesis Data Streams per raccogliere i log web. L'applicazione consumer di Kinesis, anch'essa su EC2, rimane indietro quando i dati aumentano e i record vengono persi. Quale soluzione migliora la gestione dello stream con il minor overhead operativo?

La metrica GetRecords.IteratorAgeMilliseconds di CloudWatch indica il ritardo del consumer rispetto all'ultimo record scritto nello stream. Un valore elevato significa che il consumer è in ritardo. Scalare orizzontalmente il consumer aggiungendo istanze EC2 permette di elaborare più shard in parallelo, riducendo il ritardo. Aumentare il periodo di conservazione dello stream Kinesis previene la perdita di dati nel caso in cui il consumer non riesca a elaborare i record entro il periodo di conservazione standard. Questa soluzione è efficace e ha un overhead operativo relativamente basso rispetto ad altre opzioni. Le altre opzioni sono meno ideali: Spostare i log su S3 e usare EMR introduce complessità e latenza aggiuntive per l'elaborazione in tempo quasi reale. Migrare a Lambda potrebbe essere una soluzione, ma se il volume di dati è molto elevato, anche Lambda potrebbe avere difficoltà o costi elevati, e non risolve direttamente il problema del ritardo del consumer Kinesis senza un'adeguata configurazione di concorrenza. Aggiungere shard allo stream Kinesis aumenta la capacità dello stream, ma se il consumer non scala di conseguenza, il problema del ritardo persisterà. Il problema qui è la capacità di elaborazione del consumer, non necessariamente la capacità dello stream.