Publiczna aplikacja internetowa dla handlu detalicznego wykorzystuje Application Load Balancer (ALB) przed instancjami EC2 w wielu strefach dostępności (AZ) oraz backend Amazon RDS MySQL Multi-AZ. Kontrole stanu grup docelowych wykorzystują protokół HTTP i wskazują na stronę katalogu produktów. Auto Scaling utrzymuje flotę serwerów internetowych w oparciu o kontrole stanu ALB. Ostatnio aplikacja uległa awarii; Auto Scaling wielokrotnie zastępował instancje, podczas gdy metryki serwera internetowego wyglądały normalnie. Dochodzenie wykazało, że baza danych była mocno obciążona, a zapytania były bardzo wolne. Które dwie zmiany razem rozwiążą problem i poprawią monitorowanie ogólnej dostępności i funkcjonalności aplikacji w przyszłości? (Wybierz dwie.)

Poprawne odpowiedzi rozwiązują problem przeciążenia bazy danych i poprawiają monitorowanie. Wdrożenie Amazon ElastiCache zmniejsza obciążenie bazy danych poprzez buforowanie często używanych danych, co przyspiesza odpowiedzi aplikacji i odciąża RDS. Zmiana kontroli stanu ALB na prostą stronę HTML zapewnia, że ALB sprawdza tylko dostępność serwera WWW, a nie jego zależność od przeciążonej bazy danych. Dodanie kontroli stanu Route 53 dla strony produktu, która wymaga dostępu do bazy danych, pozwala na monitorowanie pełnej funkcjonalności aplikacji end-to-end. Alarmy CloudWatch powiadomią o awarii, co umożliwi szybką reakcję. Pozostałe opcje są mniej skuteczne lub niekompletne: Utworzenie replik do odczytu RDS jest dobre dla skalowania odczytów, ale nie rozwiązuje problemu przeciążenia bazy danych głównej przez zapisy ani problemu błędnych kontroli stanu. Zmiana kontroli stanu ALB na TCP jest zbyt podstawowa; nie sprawdza, czy serwer WWW jest w stanie obsłużyć żądania HTTP. Alarm CloudWatch dla RDS z akcją odzyskiwania nie zapobiega przeciążeniu bazy danych, a jedynie reaguje na nie.