Firma prowadzi usługę dostarczania jedzenia. Z powodu niedawnego wzrostu, system przetwarzania zamówień firmy doświadcza problemów ze skalowaniem w godzinach szczytowego ruchu. Obecna architektura obejmuje instancje Amazon EC2 w grupie Auto Scaling, które zbierają zamówienia z aplikacji. Druga grupa instancji EC2 w grupie Auto Scaling realizuje zamówienia. Proces zbierania zamówień odbywa się szybko, ale proces realizacji zamówień może trwać dłużej. Dane nie mogą zostać utracone z powodu zdarzenia skalowania. Architekt rozwiązań musi zapewnić, że zarówno proces zbierania zamówień, jak i proces realizacji zamówień mogą odpowiednio skalować się w godzinach szczytowego ruchu. Które rozwiązanie spełni te wymagania?
Wybierz odpowiedź
Dotknij opcji, aby sprawdzić swoją odpowiedź.
Poprawna odpowiedź: Utwórz dwie kolejki Amazon Simple Queue Service (Amazon SQS). Użyj jednej kolejki SQS do zbierania zamówień. Użyj drugiej kolejki SQS do realizacji zamówień. Skonfiguruj instancje EC2 tak, aby odpytywały swoje odpowiednie kolejki. Skaluj grupy Auto Scaling na podstawie liczby wiadomości w każdej kolejce..
Dlaczego to jest odpowiedź
Poprawna odpowiedź to użycie dwóch kolejek Amazon SQS i skalowanie grup Auto Scaling na podstawie liczby wiadomości w każdej kolejce. Amazon SQS jest w pełni zarządzaną usługą kolejkowania wiadomości, która oddziela komponenty aplikacji, umożliwiając im niezależne skalowanie. Oddzielenie procesów zbierania i realizacji zamówień za pomocą kolejek SQS pozwala każdemu procesowi skalować się niezależnie w zależności od obciążenia. Skalowanie grup Auto Scaling w oparciu o liczbę wiadomości w kolejce SQS (np. metryka ApproximateNumberOfMessagesVisible) jest efektywnym sposobem na dynamiczne dostosowywanie pojemności do bieżącego zapotrzebowania, zapewniając, że żadne dane nie zostaną utracone i system będzie działał płynnie w godzinach szczytu. Pozostałe opcje są mniej odpowiednie: Monitorowanie tylko CPUUtilization może nie być wystarczające, ponieważ proces realizacji zamówień może być I/O-bound lub memory-bound. Ustawienie minimalnej pojemności na szczytowe obciążenie jest nieefektywne kosztowo. Tworzenie dodatkowych grup Auto Scaling na żądanie za pomocą SNS i CloudWatch jest zbyt złożone i nieoptymalne w porównaniu do natywnego skalowania Auto Scaling opartego na metrykach SQS. Skalowanie na podstawie "powiadomień wysyłanych przez kolejki" jest niejasne i nie odzwierciedla standardowego mechanizmu skalowania Auto Scaling z SQS.
Zdaj egzamin — bez niekończącego się szukania odpowiedzi
Uzyskaj wszystkie zweryfikowane pytania i wyjaśnienia do tego egzaminu w jednym miejscu i zaoszczędź godziny przygotowań. Ponad 1000 certyfikacji · Ponad 20 języków · Zacznij za darmo.
Zdaj egzamin szybciej → Karta nie jest wymagana