Eine serverlose E-Commerce-Anwendung verwendet API Gateway, um Java-basierte Lambda-Funktionen aufzurufen, die sich mit einer Amazon RDS for MySQL-Datenbank verbinden. Während einer Verkehrsspitze litt die API-Leistung und Datenbankverbindungen schlugen fehl. Das Unternehmen möchte die Lambda-Latenz reduzieren und Verkehrsspitzen mit minimalen Änderungen unterstützen. Welche Lösung erfüllt die Anforderungen mit den geringsten Anwendungsänderungen?

Die korrekte Lösung ist, einen RDS Proxy-Endpunkt zu erstellen und die bereitgestellte Parallelität für Lambda zu erhöhen. RDS Proxy verwaltet und multiplexiert Datenbankverbindungen effizient, was die Leistung während Verkehrsspitzen verbessert und Verbindungsprobleme reduziert, ohne dass der Anwendungscode wesentlich geändert werden muss. Die Speicherung von Anmeldeinformationen im AWS Secrets Manager und die Konfiguration von IAM-Berechtigungen sind Best Practices für die Sicherheit. Das Erhöhen der bereitgestellten Parallelität (Provisioned Concurrency) für Lambda stellt sicher, dass eine ausreichende Anzahl von Funktionsinstanzen vorab initialisiert wird, um Spitzenlasten ohne Kaltstarts zu bewältigen. Die Umgestaltung des Lambda-Codes zur Öffnung von Datenbankverbindungen außerhalb des Handlers ist zwar eine Optimierung, erfordert aber Codeänderungen und löst nicht das Problem der Verbindungsmüdigkeit bei hohen Lasten so effektiv wie RDS Proxy. Das Erhöhen von maxconnections in der DB-Parametergruppe kann die Datenbank überlasten und erfordert einen Neustart, was zu Ausfallzeiten führt. Die Erhöhung der reservierten Parallelität (Reserved Concurrency) von Lambda begrenzt die maximale Anzahl gleichzeitiger Ausführungen und hilft nicht, die Latenz zu reduzieren oder Kaltstarts zu vermeiden.