AWS event source mapping — co to jest i jak działa?

Czym jest event source mapping?

Event source mapping (ESM, „mapowanie źródła zdarzeń") to zasób Lambda, który czyta elementy z usług strumieniowych i kolejkowych, a potem wywołuje funkcję z paczkami rekordów (batches). Tak definiuje go dokumentacja AWS Lambda. Wewnątrz mapowania działają komponenty zwane event pollers^?event pollers: Komponenty wewnątrz mapowania, które aktywnie odpytują źródło o nowe rekordy i uruchamiają funkcję. Lambda domyślnie skaluje je automatycznie w zależności od ruchu. — to one aktywnie odpytują źródło o nowe wiadomości i uruchamiają funkcję.

Najprostszy model mentalny: ESM to zarządzany konsument obsługiwany przez Lambdę. Zamiast pisać kod, który w pętli dopytuje SQS, Kinesis czy Kafkę o nowe rekordy, konfigurujesz ESM — a Lambda uruchamia infrastrukturę odpytującą za ciebie, zbiera rekordy w paczki i wywołuje twoją funkcję.

Cały przepływ w jednym obrazku:

Ważne doprecyzowanie: ESM nie jest osobną usługą AWS. To zasób zarządzany przez Lambdę, który łączy wspierane źródło (kolejkę lub strumień) z funkcją. Nie przechowuje logiki biznesowej — odpowiada za niezawodne pobieranie danych, grupowanie ich w paczki, filtrowanie, skalowanie i podstawową obsługę błędów.

Jak to działa?

Model działania to pull, a nie push — to jedno z najważniejszych rozróżnień w całym temacie. Lambda samodzielnie odpytuje źródło, zbiera rekordy, buduje z nich paczkę i wywołuje funkcję synchronicznie, przekazując paczkę w polu Records.

Zachowanie grupowania kontrolują dwa parametry: BatchSize (maksymalna liczba rekordów w paczce) oraz MaximumBatchingWindowInSeconds (maksymalny czas zbierania rekordów, od 0 do 300 sekund). Lambda wywołuje funkcję, gdy spełniony zostanie którykolwiek z trzech warunków:

gdzie … to czas zbierania, … — okno MaximumBatchingWindowInSeconds, a … — liczba zebranych rekordów. Limitu 6 MB nie da się zmienić.

Domyślne okno zbierania zależy od źródła. Dla Kinesis, DynamoDB i SQS wynosi 0 sekund — Lambda wywołuje funkcję, gdy tylko pojawią się rekordy. Dla MSK, self-managed Kafka, Amazon MQ i DocumentDB domyślne okno to 500 ms.

Sam BatchSize to nie kolejny parametr do zapamiętania, lecz świadomy kompromis:

Dla strumieni Kinesis i DynamoDB Lambda domyślnie zachowuje kolejność rekordów w obrębie sharda^?sharda: Jednostka podziału i równoległości strumienia Kinesis lub DynamoDB Streams; rekordy w obrębie jednego sharda są przetwarzane z zachowaniem kolejności. i zwykle przetwarza jedną paczkę z sharda naraz. Można jednak zwiększyć równoległość na shard przez ParallelizationFactor (od 1 do 10) — wtedy z jednego sharda przetwarzanych jest kilka paczek jednocześnie, a Lambda nadal utrzymuje kolejność dla rekordów o tym samym partition key^?partition key: Klucz, według którego rekordy trafiają do konkretnego sharda; rekordy o tym samym kluczu zachowują wzajemną kolejność..

Kolejka vs strumień — dwa różne modele

To rozróżnienie jest najważniejszym modelem mentalnym w temacie. Choć ESM wygląda jak jeden mechanizm, zachowanie „SQS → Lambda" i „Kinesis → Lambda" jest fundamentalnie inne.

W SQS pobrana wiadomość jest czasowo ukrywana przez visibility timeout. Jeśli przetwarzanie paczki się powiedzie, wiadomości są usuwane z kolejki; jeśli nie — po upływie visibility timeout stają się znów widoczne i mogą zostać przetworzone ponownie. W Kinesis i DynamoDB Streams Lambda nie usuwa rekordów: ESM śledzi pozycję odczytu (checkpoint^?checkpoint: Zapamiętana pozycja odczytu w strumieniu; ESM przesuwa checkpoint w miarę przetwarzania, dzięki czemu wie, od którego rekordu kontynuować.) i przesuwa się dalej w strumieniu, a rekordy znikają dopiero po upływie okresu retencji — niezależnie od tego, czy zostały przetworzone.

Z jakich elementów się składa?

Na event source mapping składa się kilka konfigurowalnych warstw:

• Event pollers — komponenty odpytujące źródło. Domyślnie Lambda skaluje je automatycznie na podstawie ruchu.
• Konfiguracja batchingu — BatchSize i MaximumBatchingWindowInSeconds, plus twardy limit 6 MB na paczkę.
• Pozycja startowa — parametr istotny tylko dla źródeł strumieniowych:
  • Strumienie (Kinesis, DynamoDB, Kafka/MSK) — określa, od którego miejsca zaczyna się odczyt: od najstarszych dostępnych rekordów albo tylko od nowych.
  • Kolejki (SQS, Amazon MQ) — nie mają tego parametru; konsumpcja zawsze rusza od aktualnie dostępnych wiadomości.
• Filtrowanie (FilterCriteria) — pozwala odrzucać nieinteresujące rekordy, zanim trafią do funkcji.
• Obsługa błędów — mechanizmy zależą od typu źródła:
  • Strumienie (Kinesis, DynamoDB) — konfigurowalna liczba ponowień i maksymalny wiek rekordu, dzielenie paczki przy błędzie (BisectBatchOnFunctionError) oraz miejsce docelowe (destination) dla odrzuconych paczek.
  • Kolejki (SQS) — nieudana paczka wraca do kolejki po upływie visibility timeout; po przekroczeniu maxReceiveCount wiadomości trafiają do kolejki martwych listów (DLQ) skonfigurowanej na samej kolejce, nie na ESM.
  • Wspólne — ReportBatchItemFailures (raportowanie częściowych niepowodzeń) działa zarówno dla strumieni, jak i SQS, więc ponawiane są tylko rekordy, które faktycznie zawiodły.
• Skalowanie — automatyczne lub, dla wybranych źródeł, tryb provisioned z jawnymi limitami pollerów.

Najczęściej strojone pokrętła w jednym miejscu:

Filtrowanie zasługuje na uwagę. Jak opisuje dokumentacja filtrowania zdarzeń, obiekt FilterCriteria zawiera listę wzorców w składni identycznej z regułami Amazon EventBridge. Domyślnie można zdefiniować do pięciu filtrów na jedno mapowanie (do dziesięciu po zwiększeniu limitu), łączonych logiką OR. Dostępne operatory to m.in. prefix, suffix, exists, anything-but, porównania numeryczne i equals-ignore-case. Filtrowanie działa dla DynamoDB, Kinesis, Amazon MQ, MSK i self-managed Kafka oraz SQS — ale nie dla DocumentDB. Konsekwencja architektoniczna jest istotna: rekordy, które nie pasują do filtra, nigdy nie docierają do funkcji, więc filtrowanie realnie zmniejsza liczbę (i koszt) wywołań Lambdy.

Do czego może być używane?

AWS Lambda obsługuje obecnie mapowania źródeł zdarzeń dla siedmiu kategorii źródeł: Amazon DocumentDB, DynamoDB Streams, Kinesis Data Streams, Amazon MQ, Amazon MSK, self-managed Apache Kafka oraz Amazon SQS.

W praktyce oznacza to szereg typowych zastosowań:

• Przetwarzanie kolejek zadań — SQS jako bufor między systemami, z Lambdą jako workerem konsumującym wiadomości paczkami.
• Przetwarzanie strumieni danych — Kinesis lub Kafka do analityki w czasie zbliżonym do rzeczywistego, telemetrii IoT, logów, kliknięć.
• Reakcja na zmiany w bazie — DynamoDB Streams pozwala uruchamiać funkcję przy każdej zmianie rekordu (np. do indeksowania, replikacji, powiadomień).
• Integracja z systemami kolejkowymi — Amazon MQ (ActiveMQ/RabbitMQ) dla aplikacji korzystających z klasycznych brokerów wiadomości.

Wspólnym mianownikiem jest asynchroniczna konsumpcja z kolejek i strumieni — zwykle z batchingiem i często przy dużej przepustowości. ESM jest jednak właściwym mechanizmem także dla niskiego wolumenu (np. kilka wiadomości SQS na minutę).

Event source mapping a wywołanie push

Najważniejsze porównanie to różnica między modelem pull (ESM) a wywołaniem push. Uwaga na terminologię: w konsoli AWS zarówno SQS, jak i S3 dodaje się przez „Add trigger", więc słowo „trigger" bywa mylące. Istotny jest kierunek przepływu:

Usługi push (S3, SNS, EventBridge) same pchają zdarzenia do Lambdy, a konfiguracja wyzwalacza jest przechowywana po stronie usługi źródłowej. ESM działa odwrotnie: to zasób wewnątrz Lambdy, który sam odpytuje źródło.

W porównaniu z ręcznym budowaniem własnego konsumenta (np. aplikacją na EC2 odpytującą Kinesis w pętli) ESM zdejmuje z zespołu odpowiedzialność za odpytywanie, checkpointing, skalowanie pollerów i podstawową obsługę błędów — kosztem mniejszej kontroli nad niskopoziomowym zachowaniem.

Obsługa błędów i idempotentność

Domyślnie, gdy funkcja zwróci błąd, ESM ponawia całą paczkę. Dla strumieni oznacza to zatrzymanie sharda aż do sukcesu lub wygaśnięcia rekordów — jeden „trujący" rekord potrafi zablokować cały shard:

Bez dodatkowej konfiguracji błąd na C może spowodować ponowne przetworzenie także A, B, D i E — czyli rekordów, które już się udały. Włączenie ReportBatchItemFailures pozwala funkcji zwrócić, które konkretnie rekordy zawiodły (po numerze sekwencyjnym), dzięki czemu Lambda ponawia tylko od nich. Dodatkowo BisectBatchOnFunctionError dzieli paczkę na pół przy błędzie, zawężając obszar ponowień.

Ponieważ dostarczanie jest „co najmniej raz", ta sama wiadomość może zostać przetworzona dwukrotnie — np. „obciąż klienta kwotą 100 zł" wykona się dwa razy i podwójnie obciąży konto. Rozwiązaniem jest idempotentna^?idempotentna: Właściwość operacji, dla której wielokrotne wykonanie z tym samym wejściem daje ten sam efekt co jednokrotne — warunek poprawności przy dostarczaniu „co najmniej raz". funkcja, która rozpoznaje już przetworzone zdarzenia:

eventId = 12345

jeśli juzPrzetworzone(12345):
    zignoruj
w przeciwnym razie:
    obciazKlienta()
    oznaczJakoPrzetworzone(12345)

Dlatego AWS tak mocno akcentuje idempotentność — to nie ostrożnościowa uwaga, lecz warunek poprawności przy modelu at-least-once.

Zarządzanie i infrastruktura jako kod

ESM tworzy się i konfiguruje przez konsolę AWS, CLI, SDK lub jako infrastrukturę jako kod (CloudFormation, AWS SAM). Trzy operacje API domykają cały cykl życia mapowania:

Za hosting pollerów i skalowanie odpowiada AWS — nie utrzymujesz żadnej własnej infrastruktury odpytującej.

Najważniejsze ograniczenia i wyzwania

• Dostarczanie co najmniej raz — duplikaty są wpisane w model; wymagana idempotentność.
• Blokowanie sharda przy błędzie — bez ReportBatchItemFailures czy BisectBatchOnFunctionError jeden wadliwy rekord blokuje cały shard.
• Limit 6 MB na paczkę — sztywny i niekonfigurowalny.
• Filtrowanie ma granice — pięć wzorców domyślnie, brak wsparcia dla DocumentDB, operator exists działa tylko na liściach drzewa JSON.
• Nieoczywiste metryki współbieżności — AWS ostrzega, że z powodu krótkich odstępów między wywołaniami Lambda może chwilowo raportować wyższą współbieżność niż liczba shardów.
• Nieodwracalna zmiana okna 500 ms — po edycji nie wrócisz do domyślnej wartości bez nowego mapowania.

Dlaczego to jest istotne?

Event source mapping wygląda na drobiazg konfiguracyjny, a w praktyce decyduje o tym, czy architektura event-driven działa stabilnie. To właśnie tu rozstrzyga się kolejność przetwarzania, odporność na błędy, koszt (przez współbieżność) i opóźnienia. Deweloper, który traktuje ESM jak „czarną skrzynkę", prędzej czy później trafia na klasyczne problemy: zablokowany shard przez jeden wadliwy rekord, nieoczekiwane duplikaty albo funkcję wywoływaną zbyt często przy zbyt małych paczkach.

Znaczenie tego mechanizmu rośnie wraz z popularnością architektur sterowanych zdarzeniami i strumieniami. Coraz więcej systemów — od telemetrii IoT, przez analitykę czasu rzeczywistego, po pipeline'y danych do modeli AI — opiera się na strumieniach Kinesis i Kafki oraz kolejkach SQS. W tych scenariuszach ESM jest cichym spoiwem łączącym źródło danych z logiką przetwarzania.

Wprowadzony przez Amazona tryb provisioned (dla MSK, Kafki i SQS) pokazuje kierunek: coraz większy nacisk na przewidywalne, niskoopóźnieniowe przetwarzanie dużych wolumenów. Dla juniora wniosek jest prosty: dobre zrozumienie modelu pull, kontrastu kolejka vs strumień oraz obsługi błędów w ESM to inwestycja, która zwraca się przy każdym poważniejszym projekcie na Lambdzie.

Jeśli po lekturze potrafisz spojrzeć na „SQS → Lambda" i bez wahania powiedzieć: „SQS nie wywołuje Lambdy — to Lambda przez ESM odpytuje SQS, batchuje wiadomości i synchronicznie wywołuje funkcję, a po sukcesie wiadomości są usuwane; dostarczanie jest at-least-once, więc funkcja musi być idempotentna" — to temat ESM jest naprawdę zrozumiany.

Źródła

• AWS Lambda Developer Guide — How Lambda processes records from stream and queue-based event sources — link
• AWS Lambda Developer Guide — Control which events Lambda sends to your function (event filtering) — link
• AWS Lambda Developer Guide — Configuring partial batch response with Kinesis Data Streams and Lambda — link
• AWS Lambda Developer Guide — Using Lambda to process records from Amazon Kinesis Data Streams — link