Un site de commerce électronique utilise une fonction Lambda qui écrit les commandes dans une base de données Amazon RDS for MySQL. Le service doit renvoyer les confirmations de commande immédiatement. Lors d'un pic marketing, l'équipe des opérations a constaté des erreurs de type « trop de connexions » provenant de RDS, même si les métriques du cluster de base de données indiquent un bon état du CPU et de la mémoire. Que doit faire le développeur pour corriger les erreurs de connexion ?

La bonne réponse est d'ouvrir la connexion à la base de données en dehors du gestionnaire Lambda et d'utiliser Amazon RDS Proxy. Les fonctions Lambda sont sans état et peuvent s'adapter rapidement, ce qui peut entraîner un grand nombre de connexions simultanées à la base de données, dépassant les limites de connexion de RDS même si les ressources CPU/mémoire sont suffisantes. Ouvrir la connexion en dehors du gestionnaire permet de la réutiliser entre les invocations de la même instance d'environnement d'exécution Lambda. RDS Proxy est conçu pour gérer efficacement les pools de connexions et les réutiliser, réduisant ainsi la charge sur la base de données et évitant les erreurs de "trop de connexions". Les autres options sont incorrectes car : Augmenter maxuserconnections et redémarrer le cluster peut ne pas résoudre le problème fondamental de la gestion des connexions par Lambda et peut masquer d'autres problèmes. Utiliser Amazon SQS FIFO pour mettre en mémoire tampon les commandes introduirait une latence, ce qui est incompatible avec l'exigence de renvoyer les confirmations de commande immédiatement. De plus, ajuster la concurrence Lambda ne résout pas le problème de la gestion des connexions persistantes par la base de données.