Un'azienda di servizi raccoglie i dati di utilizzo degli smart meter ogni 5 minuti. I dati arrivano tramite Amazon API Gateway, passano a una funzione AWS Lambda e vengono archiviati in una tabella Amazon DynamoDB. Durante un progetto pilota, Lambda ha impiegato 3-5 secondi, ma con l'aumentare del numero di contatori, le durate di Lambda sono aumentate a 1-2 minuti e l'aumento dei tipi di metriche ha ulteriormente incrementato la durata. Si verificano molti errori ProvisionedThroughputExceededException sui PUT di DynamoDB e molti errori TooManyRequestsException da Lambda. Quale combinazione di modifiche risolverà i problemi? (Scegliere due.)

L'errore ProvisionedThroughputExceededException su DynamoDB indica che la tabella non ha sufficienti unità di capacità di scrittura (WCU) per gestire il carico di richieste. Aumentare le WCU risolverà questo problema, consentendo a DynamoDB di accettare più scritture al secondo. L'errore TooManyRequestsException da Lambda, insieme all'aumento delle durate, suggerisce che le funzioni Lambda sono sovraccaricate o che il backend (DynamoDB) non riesce a tenere il passo. Inviare i dati a uno stream Amazon Kinesis da API Gateway e poi elaborarli in batch con Lambda è una soluzione scalabile. Kinesis gestisce l'ingestione di grandi volumi di dati in tempo reale, fungendo da buffer e livellatore di carico, permettendo a Lambda di elaborare i dati in batch in modo più efficiente e riducendo la pressione su DynamoDB. Aumentare la memoria di Lambda non risolve il problema di throughput di DynamoDB né la gestione del volume di richieste. Aumentare la dimensione del payload dagli smart meter aggraverebbe il problema. Utilizzare una coda SQS FIFO non è l'ideale per dati ad alto volume e in tempo reale come quelli degli smart meter, e non risolve intrinsecamente il problema di throughput di DynamoDB.