Stanowa aplikacja firmy działa w pamięci na instancjach Amazon EC2. Infrastruktura została wdrożona za pomocą AWS CloudFormation, używając rodziny instancji EC2 M5. Wraz ze wzrostem ruchu, wydajność aplikacji spadła, a użytkownicy doświadczają opóźnień. Które rozwiązanie rozwiąże problemy z NAJWIĘKSZĄ efektywnością operacyjną?

Poprawna odpowiedź rozwiązuje problem spadku wydajności aplikacji stanowej, która działa w pamięci, poprzez zmianę typu instancji na R5, które są zoptymalizowane pod kątem pamięci. Dodatkowo, wdrożenie agenta CloudWatch do zbierania niestandardowych metryk opóźnień aplikacji jest kluczowe dla przyszłego planowania pojemności i proaktywnego zarządzania wydajnością. Pozostałe opcje są mniej efektywne: Zastąpienie instancji M5 instancjami T3 (które są instancjami z możliwością burstowania, przeznaczonymi dla obciążeń o zmiennym zapotrzebowaniu) nie rozwiąże problemu aplikacji działającej w pamięci, a jedynie pogorszy sytuację przy zwiększonym ruchu. Ręczne zmiany przez konsolę nie są zgodne z podejściem Infrastructure as Code (IaC) i CloudFormation. Modyfikacja szablonów CloudFormation do użycia grupy Auto Scaling jest dobrym krokiem, ale ręczne zwiększanie pojemności nie jest optymalne operacyjnie. Ponadto, nie rozwiązuje problemu niedostatecznej pamięci, jeśli instancje M5 są nadal używane. Zmiana na instancje R5 jest właściwa, ale poleganie wyłącznie na wbudowanych metrykach pamięci EC2 CloudWatch może nie być wystarczające do dokładnego monitorowania opóźnień aplikacji i planowania pojemności, ponieważ wbudowane metryki nie dostarczają szczegółowych danych na temat wydajności aplikacji.