Firma tworzy nowe rozwiązanie uczenia maszynowego w AWS. Modele są implementowane jako niezależne mikrousługi, które pobierają około 1 GB danych modelu z Amazon S3 podczas uruchamiania i ładują je do pamięci. Użytkownicy uzyskują dostęp do modeli za pośrednictwem asynchronicznego API: przesyłają żądanie lub partię żądań i określają, gdzie mają zostać wysłane wyniki. Setki użytkowników będzie korzystać z modeli o nieregularnych wzorcach użytkowania — niektóre modele mogą być bezczynne przez dni lub tygodnie, podczas gdy inne otrzymują tysiące żądań w krótkich seriach. Który projekt powinien zalecić architekt rozwiązań, aby spełnić te wymagania?

Prawidłowa odpowiedź to kierowanie żądań do SQS i przetwarzanie ich przez Amazon ECS z Auto Scaling. SQS doskonale sprawdza się w przypadku asynchronicznych API i nieregularnych wzorców użycia, zapewniając buforowanie i niezawodność. Amazon ECS, szczególnie z Fargate, jest odpowiedni dla mikrousług wymagających 1 GB danych modelu w pamięci, ponieważ Lambda ma ograniczenia pamięci i czasu wykonania, które mogą być problematyczne dla dużych modeli. Auto Scaling w ECS, oparty na rozmiarze kolejki SQS, efektywnie zarządza zasobami, skalując się w górę podczas szczytów i w dół podczas bezczynności, minimalizując koszty. Pozostałe opcje są mniej optymalne: Lambda ma limit pamięci (10 GB) i czasu wykonania (15 minut), co może być niewystarczające dla dużych modeli ML i ich ładowania. NLB nie jest idealny do asynchronicznych API. ALB i ECS z SQS to dobry początek, ale AWS App Mesh służy do zarządzania ruchem między mikrousługami, a nie do skalowania instancji klastra ECS w oparciu o rozmiar kolejki SQS. Lambda z SQS jest możliwa, ale ponownie, ograniczenia Lambdy mogą być problemem. Auto Scaling dla vCPU funkcji Lambda nie jest standardowym sposobem skalowania Lambdy; Lambda skaluje się automatycznie w oparciu o liczbę wywołań.