Un'applicazione di e-commerce serverless utilizza API Gateway per richiamare funzioni Lambda basate su Java che si connettono a un database Amazon RDS for MySQL. Durante un picco di traffico, le prestazioni dell'API hanno subito un calo e le connessioni al database sono fallite. L'azienda desidera ridurre la latenza di Lambda e supportare i picchi di traffico con modifiche minime. Quale soluzione soddisfa i requisiti con la minima modifica dell'applicazione?

La soluzione corretta implementa RDS Proxy, che gestisce in modo efficiente il pool di connessioni al database, riducendo la latenza e prevenendo i fallimenti delle connessioni durante i picchi di traffico per le funzioni Lambda basate su Java, che tendono ad avere un overhead maggiore per l'inizializzazione delle connessioni. L'archiviazione delle credenziali in Secrets Manager e la configurazione delle autorizzazioni IAM sono best practice di sicurezza. L'aumento della concurrency provisioned per le funzioni Lambda garantisce che un numero sufficiente di istanze sia sempre pronto a elaborare le richieste, riducendo i tempi di cold start e supportando i picchi di traffico. Le opzioni errate: Rifattorizzare il codice per aprire la connessione al di fuori del gestore è una buona pratica, ma non risolve il problema del sovraccarico delle connessioni durante i picchi di traffico e richiede modifiche significative al codice. Aumentare il parametro maxconnections del database potrebbe ritardare il problema ma non lo risolve alla radice, e il riavvio del database causa downtime. La reserved concurrency limita il numero massimo di esecuzioni simultanee e non migliora la latenza o la gestione delle connessioni. L'ultima opzione è simile alla corretta ma propone di aumentare la reserved concurrency, che limita le esecuzioni simultanee invece di garantire istanze pronte per ridurre la latenza.