Firma uruchamia trójwarstwową aplikację internetową, która przetwarza zamówienia klientów. Warstwa internetowa wykorzystuje instancje Amazon EC2 za Application Load Balancerem. Warstwa przetwarzania wykorzystuje instancje EC2. Firma rozdzieliła warstwy internetową i przetwarzania za pomocą Amazon Simple Queue Service (Amazon SQS). Warstwa przechowywania to Amazon DynamoDB. W godzinach szczytu niektórzy użytkownicy zgłaszają opóźnienia w przetwarzaniu zamówień. Podczas tych opóźnień instancje EC2 osiągają 100% wykorzystania procesora, a kolejka SQS jest przepełniona. Szczyty są zmienne i nieprzewidywalne. Firma musi poprawić wydajność aplikacji. Które rozwiązanie spełnia te wymagania?

Poprawna odpowiedź to użycie polityki śledzenia celu Amazon EC2 Auto Scaling dla instancji warstwy przetwarzania, z atrybutem ApproximateNumberOfMessages jako metryką skalowania. Problemem jest przeciążenie instancji EC2 warstwy przetwarzania i przepełniona kolejka SQS, co wskazuje na niewystarczającą moc obliczeniową do obsługi wiadomości. Polityka śledzenia celu Auto Scaling dynamicznie dostosuje liczbę instancji EC2, aby utrzymać określoną wartość metryki. ApproximateNumberOfMessages w SQS bezpośrednio odzwierciedla obciążenie warstwy przetwarzania, co pozwala na proaktywne skalowanie przed wystąpieniem opóźnień. Skalowanie zaplanowane nie jest idealne, ponieważ szczyty są nieprzewidywalne. Amazon ElastiCache for Redis poprawiłoby wydajność DynamoDB, ale nie rozwiązałoby problemu przeciążonych instancji EC2 przetwarzających zamówienia. Amazon CloudFront buforuje treści statyczne i dynamiczne, ale nie skaluje warstwy przetwarzania ani nie rozwiązuje problemu przeciążonej kolejki SQS.