Współbieżność, ograniczanie i zarezerwowana współbieżność

Lambda skaluje działanie, uruchamiając wiele jednoczesnych wykonań funkcji — po jednym dla każdego równoczesnego zdarzenia. Gdy w tym samym czasie nadejdzie 100 żądań, Lambda uruchomi 100 równoległych instancji funkcji. AWS automatycznie zarządza podstawową infrastrukturą. Domyślny limit współbieżności na poziomie konta wynosi 1000 jednoczesnych wykonań w każdym regionie (jest to limit miękki, który można zwiększyć za pośrednictwem wniosku o zwiększenie limitu usługi).

Współbieżność oblicza się według wzoru: Współbieżność = liczba żądań na sekundę × średni czas trwania w sekundach. Jeśli funkcja obsługuje 500 żądań na sekundę, a każde z nich trwa 0,2 sekundy, potrzebnych jest 100 jednoczesnych wykonań. Zrozumienie tego wzoru pomaga przewidzieć, czy limity konta są wystarczające i czy przed wydarzeniem o dużym natężeniu ruchu należy wystąpić o ich zwiększenie.

Gdy Lambda otrzymuje więcej żądań, niż pozwala na to limit współbieżności, ogranicza nadmiarowe żądania. W przypadku wywołań synchronicznych (np. za pośrednictwem API Gateway) ograniczone żądania natychmiast otrzymują błąd 429 TooManyRequestsException, który musi obsłużyć wywołujący. W przypadku wywołań asynchronicznych (np. zdarzeń S3) Lambda umieszcza zdarzenia w kolejce i ponawia próby przez maksymalnie 6 godzin, a następnie wysyła je do kolejki komunikatów niedostarczonych.

Zarezerwowana współbieżność gwarantuje określoną liczbę jednoczesnych wykonań konkretnej funkcji, rezerwując je z puli konta. Służy dwóm celom: (1) gwarantuje dostępność zasobów — funkcja zawsze będzie mieć dostęp do tej liczby wykonań, nawet jeśli inne funkcje zużywają limit konta; (2) ogranicza współbieżność — funkcja nigdy nie przekroczy zarezerwowanej wartości, chroniąc zależności niższych warstw przed przeciążeniem.

To ważny scenariusz egzaminacyjny: funkcja Lambda zapisuje dane w bazie RDS, która ma limit 50 połączeń. Bez kontroli współbieżności Lambda mogłaby skalować się do setek jednoczesnych wykonań i wyczerpać wszystkie połączenia z bazą danych, powodując błędy każdej funkcji. Ustawienie zarezerwowanej współbieżności na 40 gwarantuje, że Lambda nigdy nie przekroczy 40 jednoczesnych połączeń z bazą danych, chroniąc instancję RDS. To kluczowy wzorzec dla każdej funkcji Lambda korzystającej z usługi z limitem połączeń.

Współbieżność aprowizowana wstępnie inicjalizuje określoną liczbę środowisk wykonawczych Lambda, aby były gotowe do odpowiedzi natychmiast, bez zimnego startu. Ma to kluczowe znaczenie w przypadku interfejsów API wrażliwych na opóźnienia, dla których nawet zimny start trwający 100 ms jest nieakceptowalny. Za współbieżność aprowizowaną płaci się według stawki godzinowej, nawet gdy te środowiska są bezczynne, dlatego warto połączyć ją z funkcją Auto Scaling, aby dostosowywać jej poziom do przewidywanych wzorców ruchu.

Te pojęcia są często mylone, ale służą różnym celom. Zarezerwowana współbieżność ogranicza i gwarantuje przydział zasobów z puli konta — NIE eliminuje zimnych startów. Współbieżność aprowizowana wstępnie rozgrzewa środowiska wykonawcze, aby wyeliminować zimne starty — NIE uniemożliwia innym funkcjom korzystania z tej samej puli. Zarezerwowanej współbieżności należy używać do ograniczania przepustowości, a aprowizowanej współbieżności do poprawy opóźnień. Obie można stosować jednocześnie dla tej samej funkcji.

Lambda nie osiąga pełnej współbieżności natychmiast. Obowiązuje limit skokowego wzrostu na poziomie konta (początkowe tempo skalowania), które różni się w zależności od regionu — typowo obejmuje 3000 początkowych wykonań, a następnie 500 dodatkowych wykonań na minutę aż do osiągnięcia limitu. W przypadku aplikacji, w których przewidywane są nagłe, bardzo duże skoki ruchu (ruch wirusowy, wyprzedaże błyskawiczne), należy użyć współbieżności aprowizowanej, aby wstępnie rozgrzać wystarczającą liczbę środowisk i zapobiec ograniczaniu wywołań podczas początkowego napływu ruchu.

Współbieżność Lambda należy monitorować za pomocą następujących kluczowych metryk CloudWatch:

• ConcurrentExecutions: bieżąca liczba uruchomionych instancji
• Throttles: liczba ograniczonych wywołań (w prawidłowo działającym systemie powinna wynosić zero)
• UnreservedConcurrentExecutions: niezastrzeżona pula na poziomie konta
• ProvisionedConcurrencyUtilization: stopień wykorzystania aprowizowanej pojemności

Należy ustawić alarmy dla Throttles, aby otrzymywać powiadomienia, zanim ograniczanie wywołań wpłynie na użytkowników końcowych.

Projektując systemy, które wywołują Lambda synchronicznie (API Gateway, bezpośrednie wywołania SDK), należy zaimplementować po stronie wywołującej wycofywanie wykładnicze z losowym opóźnieniem. AWS SDK mają wbudowaną logikę ponawiania prób, ale w przypadku Lambda obsługiwanej przez API Gateway trzeba obsługiwać odpowiedzi 429 w aplikacji klienckiej. W przypadku Lambda wyzwalanej przez SQS sama usługa SQS obsługuje ponawianie prób; należy odpowiednio ustawić parametr Maximum Receives w kolejce źródłowej i skonfigurować DLQ dla wyczerpanych prób.

W przypadku Kinesis Data Streams i DynamoDB Streams współbieżność Lambda jest ograniczona liczbą fragmentów (Kinesis) lub partycji (DynamoDB). Każdy fragment/partycja jest przetwarzany dokładnie przez jedno jednoczesne wykonanie Lambda. Jeśli mają Państwo 10 fragmentów Kinesis, Lambda uruchomi dla tego wyzwalacza maksymalnie 10 jednoczesnych wykonań. Oznacza to, że problemy z ograniczaniem wywołań w przypadku wyzwalaczy opartych na strumieniach zwykle rozwiązuje się przez zwiększenie liczby fragmentów, a nie podnoszenie limitów współbieżności.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: zarezerwowana współbieżność zarówno gwarantuje, jak i ogranicza liczbę jednoczesnych wykonań funkcji, chroniąc usługi niższych warstw i zapewniając dostępność; współbieżność aprowizowana wstępnie inicjalizuje środowiska, aby eliminować zimne starty w zadaniach wrażliwych na opóźnienia; natomiast ograniczanie liczby wywołań przejawia się błędami 429 w przypadku wywołań synchronicznych oraz ponawianiem prób po umieszczeniu zdarzeń w kolejce w przypadku wywołań asynchronicznych — należy je monitorować za pomocą metryki CloudWatch Throttles. W następnej części omówimy warstwy Lambda i pakiety wdrożeniowe służące do zarządzania dużymi zależnościami.