Wybór platformy obliczeniowej AWS pod kątem obciążenia pod względem kosztów nie jest łatwym zadaniem. Zrobiłem obliczenia dla jednego z projektów, nad którymi pracuję i postanowiłem podzielić się swoimi odkryciami. W tym artykule przeprowadzę bardzo ogólne i uproszczone porównanie, aby nakreślić sposób dokonania porównania.

Nie będąc ekspertem w wykorzystywaniu wszystkich opcji obliczeniowych, zachęcam do skorzystania z sekcji komentarzy w celu skorygowania moich błędnych założeń lub zasugerowania ulepszeń i pomysłów, które należy uwzględnić w procesie porównywania.

Ustawienia konfiguracji

Korzystając z kalkulatora cen AWS , możemy porównać miesięczny koszt usług mniej więcej równoważnych konfiguracji mocy obliczeniowej. Odkryłem już, że jest to trudne zadanie do wykonania. Każda usługa ma własny typ konfiguracji do wyboru, mający różne specyfikacje nie tylko dla vCPU i pamięci, ale także dla ograniczeń przepustowości sieci, ograniczeń w używaniu procesorów graficznych lub woluminów EBS i tak dalej.

Dla uproszczenia porównajmy usługi z wymaganiami samego posiadania 1 vCPU i około 2 GB pamięci. W przypadku Lambdy vCPU skaluje się wraz z konfigurowalnym rozmiarem pamięci. Lambda otrzymuje 1 vCPU na 1,769 GB pamięci , więc to będzie nasz wybór dla Lambdy. Fargate ma konfigurowalną liczbę vCPU i rozmiar pamięci, więc możemy wybrać dokładnie 1 vCPU i 2 GB dostępnej pamięci. W przypadku EC2, przy tak niskiej wartości vCPU i pamięci w obecnej generacji typów instancji EC2, naszą jedyną opcją jest rodzina T, która ma imponującą wydajność. Daje to kolejny poziom złożoności, ponieważ cena instancji jest ustalana na podstawie wykorzystania niższego lub równego podstawowej wydajności procesora, a dodatkowe opłaty są naliczane, gdy zużycie przekracza plan bazowy. Jednak w typach instancji poprzedniej generacji typ instancji m1.small dość dobrze spełnia wymagania z 1 vCPU i 1,7 GB pamięci, więc będziemy go używać zamiast typu instancji z rodziny T. Ponadto dla uproszczenia porównania nie uwzględniono następujących opcji:

• Procesory o architekturze ARM
• System operacyjny inny niż Linux
• Wykrywaj instancje i wyszukuj zadania Fargate
• Przesyłanie i przechowywanie danych
• Zarezerwowane instancje i plany oszczędności obliczeniowych

Intuicyjnie EC2 powinno być najtańszą usługą, a następnie Fargate i Lambda. Powodem jest to, że każda następna usługa wymaga mniej administrowania infrastrukturą niż poprzednia, pozostawiając zadania zarządzania infrastrukturą AWS. Poniższy wykres przedstawia miesięczną cenę każdej usługi na podstawie procentowego wykorzystania czasu.

Ceny EC2 są rzeczywiście najniższe, tuż za nimi plasuje się Fargate, podczas gdy ceny Lambda są około dwukrotnie wyższe niż ceny Fargate. Ceny EC2 można jeszcze bardziej obniżyć, wykorzystując typ instancji typu burstable z rodziny T, w zależności od rzeczywistych potrzeb obciążenia.

Czynniki rozliczeniowe i początkowe

Jak widzieliśmy powyżej, koszt uruchomienia Lambdy jest dość wysoki w porównaniu z Fargate i EC2. Przyjrzyjmy się teraz czynnikom, które mogą mieć wpływ na to, dlaczego nadal możemy wybrać Lambdę do obliczeń pomimo jej wyższej ceny.

Pierwszą rzeczą do rozważenia jest okres rozliczeniowy usług. Opłata EC2 jest naliczana co sekundę, przy czym czas trwania wynosi co najmniej 60 sekund. Rozliczanie rozpoczyna się w momencie uruchomienia instancji i kończy się w momencie zakończenia lub zatrzymania instancji. Fargate jest rozliczane za sekundę, a także za minimalny czas trwania 60 sekund. Rozliczanie rozpoczyna się po pobraniu obrazu i zatrzymuje się po zakończeniu zadania. Z drugiej strony Lambda jest rozliczana za milisekundę bez minimalnego progu. Rozliczanie rozpoczyna się, gdy kod inicjujący lub programu obsługi zaczyna działać i zatrzymuje się, gdy kod powraca lub kończy się w inny sposób.

Jest to jeden z powodów, dla których Lambda jest dobrym wyborem dla obciążeń, które są wykonywane rzadko i są krótkotrwałe.

Po drugie, uruchomienie nowej instancji EC2 zajmuje około minuty lub więcej, podobnie jak uruchomienie nowego zadania Fargate. Dla porównania, utworzenie nowej instancji Lambda zajmuje zwykle kilkaset milisekund w przypadku środowisk wykonawczych z językami interpretowanymi i do kilku sekund w przypadku środowisk wykonawczych z językami skompilowanymi.

W zależności od obciążenia może się zdarzyć, że nie będziesz mógł czekać ani minuty na uruchomienie instancji EC2 lub zadania Fargate, a tym samym będziesz musiał utrzymać działanie instancji lub zadania. Inaczej jest w przypadku Lambdy, ponieważ zwykle czekasz kilka sekund, aby uruchomić nową instancję. Możesz także utrzymać instancję Lambda w cieple za niewielką cenę, pingując ją co kilka minut przez zdarzenie CloudWatch.

Aby podkreślić dwa czynniki opisane powyżej, możemy teraz porównać rozliczanie usług dla przetwarzania typu obsługującego interfejs API sieci Web, w przypadku którego nie chcemy mieć opóźnień w uruchamianiu i być gotowym do obsługi ruchu w dowolnym momencie.

Zarówno instancja EC2, jak i zadanie Fargate muszą być wykorzystywane przez 100% czasu, aby uniknąć problemów z uruchamianiem. Z drugiej strony rozliczenia lambda zależą od rzeczywistego czasu, w którym działa kod modułu obsługi w celu obsługi ruchu do internetowego interfejsu API. W związku z tym korzystanie z Lambdy jest preferowane, dopóki Lambda nie jest wykorzystywana przez około 40 do 50% czasu, pomimo wyższej ceny za tę samą moc obliczeniową. To sprawia, że ​​Lambda nadaje się do zadań szybkiego przetwarzania, na przykład zadań IO, takich jak odczyt danych z DynamoDB i tak dalej.

Przykład ze świata rzeczywistego

Używamy funkcji Lambda w jednym z naszych projektów do obsługi żądań API. Ma konfigurację pamięci 2 GB głównie w celu zminimalizowania opóźnień zimnego startu, w przeciwnym razie może mieć niższą konfigurację. Wykorzystuje bibliotekę .NET, która ma ponad 4 MB, więc różnice w zimnym starcie między np. 512 MB pamięci a 2 GB są zauważalne.

Ruch na Lambdzie systematycznie wzrastał w ciągu ostatnich miesięcy i chcemy się dowiedzieć, czy nie nadszedł czas, aby rozważyć migrację do innej usługi.

Według dziennych wskaźników wykorzystania, funkcja jest wywoływana średnio około 250 tys. razy dziennie, co daje 2,89 żądań na sekundę. Średni czas wykonania wynosi około 250 ms. 2,89 razy 250 to w przybliżeniu 723. Oznacza to, że funkcja jest używana przez około 70% czasu.

Bardziej szczegółowe metryki jednominutowych interwałów pokazują, że wzorce wywołań są kolczaste, jednak ogólnie obciążenie jest obsługiwane przez niewiele mniej niż 10 jednoczesnych wystąpień funkcji.

Zebrane metryki sygnalizują, że przekroczyliśmy próg, przy którym rozliczenia Lambda były optymalne. Potencjalnie, aby obsłużyć ruch przy tej samej mocy obliczeniowej i mieć miejsce na rozbudowę, moglibyśmy wykorzystać np. 2 zadania Multi-AZ Fargate, z których każde ma 0,5 vCPU i 1 GB pamięci. Z powyższych wykresów wynika, że ​​zmniejszyłoby to miesięczne koszty rozliczeń z 53,50 USD do 36,04 USD. Moglibyśmy spróbować jeszcze bardziej obniżyć koszty, wykorzystując instancje EC2 o odpowiednich rozmiarach i hostując tam kontener lub aplikację. Jest to oczywiście tylko przybliżony pomysł teoretyczny, który wymagałby weryfikacji w rzeczywistym zastosowaniu.

Na zakończenie chciałbym wspomnieć, że surowe koszty fakturowania należy rozszerzyć o uwzględnienie złożoności i kosztów zarządzania infrastrukturą. W przypadku konkretnych scenariuszy może to oznaczać, że chociaż np. koszty rozliczeniowe EC2 mogą być o kilka procent niższe niż w przypadku Fargate lub Lambda, różnica nie rekompensuje dodatkowej złożoności rozwiązania.

Nazywamy się ACTUM Digital , a ten artykuł został napisany przez Milana Gatyasa , kierownika technicznego .NET w dziale Apollo. Zapraszamy do kontaktu.