Aplikacja SaaS na AWS wykorzystuje AWS Lambda do obliczeń i bazę danych Amazon RDS for MySQL Multi-AZ. Podczas wydarzeń rynkowych o dużym zapotrzebowaniu, liczba połączeń do bazy danych gwałtownie rośnie, a użytkownicy doświadczają wolnych odpowiedzi. Firma musi poprawić skalowalną wydajność i dostępność bazy danych, aby obsłużyć wiele współbieżnych połączeń z Lambda. Które rozwiązanie spełnia te wymagania?

Poprawna odpowiedź to migracja do Amazon Aurora z repliką Aurora i konfiguracja Amazon RDS Proxy. Amazon Aurora oferuje znacznie lepszą skalowalność i wydajność niż RDS for MySQL, a repliki Aurora poprawiają dostępność i umożliwiają rozłożenie obciążenia odczytu. RDS Proxy jest kluczowe dla zarządzania dużą liczbą krótkotrwałych połączeń z Lambda, ponieważ buforuje i ponownie wykorzystuje połączenia, redukując obciążenie bazy danych i poprawiając wydajność aplikacji. Pozostałe opcje są mniej skuteczne: Dodawanie replik odczytu RDS for MySQL za pomocą CloudWatch jest reaktywne i nie rozwiązuje problemu wydajności podstawowej bazy danych ani zarządzania połączeniami. Migracja do Aurora i dodanie repliki odczytu bez puli połączeń nadal naraża bazę danych na dużą liczbę połączeń z Lambda. Inicjowanie puli połączeń poza funkcją Lambda jest trudne do zaimplementowania i zarządzania w środowisku bezserwerowym. Użycie ważonych rekordów Route 53 z repliką odczytu Aurora jest przydatne do dystrybucji ruchu, ale nie rozwiązuje problemu zarządzania połączeniami z Lambda.