Firma przetwarza wiadomości za pomocą aplikacji roboczej działającej na trzech instancjach EC2 w grupie Auto Scaling, która używa prostej polityki skalowania. Procesy robocze pobierają wiadomości z kolejki Amazon SQS. Sporadyczne wzrosty liczby wiadomości obniżają wydajność przetwarzania, a administrator SysOps musi skalować grupę Auto Scaling, aby obsłużyć większą liczbę wiadomości w kolejce. Które podejście najlepiej spełnia to wymaganie?

Prawidłowa odpowiedź to użycie CloudWatch metric math do obliczenia przybliżonej liczby widocznych wiadomości na instancję dla kolejki SQS i utworzenie polityki skalowania target-tracking. Ta metoda pozwala na dynamiczne skalowanie grupy Auto Scaling w oparciu o bieżące obciążenie kolejki SQS, zapewniając, że zawsze jest wystarczająca liczba instancji do przetwarzania wiadomości. Obliczenie ApproximateNumberOfMessagesVisible / liczba instancji daje wgląd w obciążenie każdej instancji, co jest idealne do skalowania. Pozostałe opcje są mniej odpowiednie: Oszacowanie wieku najstarszej wiadomości jest wskaźnikiem problemów z przetwarzaniem, ale nie bezpośrednim miernikiem obciążenia, który najlepiej nadaje się do skalowania w górę. Użycie Application Load Balancer (ALB) z metryką ALBRequestCountPerTarget jest nieodpowiednie, ponieważ procesy robocze pobierają wiadomości bezpośrednio z SQS, a nie przez ALB. Skalowanie zaplanowane (scheduled scaling) nie reaguje na sporadyczne wzrosty liczby wiadomości w czasie rzeczywistym, co jest kluczowym wymaganiem.