Amazon DOP-C02: Architektury sterowane zdarzeniami i automatyzacja — Przewodnik do nauki

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Część AWS DevOps Engineer Professional DOP-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Architektury sterowane zdarzeniami oddzielają producentów od konsumentów, kładą nacisk na komunikację asynchroniczną i sprawiają, że systemy są odporne na skoki obciążenia i awarie. Główne zasady to luźne powiązanie poprzez zdarzenia/wiadomości, skalowanie sterowane przez konsumentów, idempotentne procedury obsługi oraz jawna obsługa błędów i obserwowalność. AWS dostarcza elementy składowe do tworzenia trwałych kolejek, systemów pub/sub, magistral zdarzeń, przetwarzania strumieniowego, orkiestracji i automatyzacji operacyjnej. Opanowanie współdziałania pomiędzy Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, mapowaniami źródeł zdarzeń Lambda, AWS Systems Manager Automation i OpsCenter, a także Kinesis Data Streams i Firehose, pozwala budować skalowalne, odporne na awarie i audytowalne potoki automatyzacji i danych.

Wiadomości i pozyskiwanie danych: SQS, SNS, Kinesis i Firehose

Amazon SQS dostarcza trwałe, skalowalne kolejki do oddzielania komponentów. Kolejki standardowe oferują dostarczanie co najmniej raz (at-least-once) i porządkowanie na zasadzie „best-effort” z praktycznie nieograniczoną przepustowością; nadają się do obsługi przez równoległe procesy robocze, które tolerują zduplikowane i nieuporządkowane wiadomości dzięki kluczom idempotencji i zapisom warunkowym. Kolejki FIFO wymuszają uporządkowane dostarczanie w ramach grupy wiadomości i semantykę przetwarzania dokładnie raz (exactly-once) z deduplikacją (w oknie pięciu minut). Gwarantują one kolejność i pojedyncze przetworzenie, ale kosztem absolutnej przepustowości: użyj wielu grup wiadomości, aby zrównoleglić przetwarzanie w ramach FIFO, lub włącz tryb wysokiej przepustowości dla FIFO, aby przetwarzać tysiące wiadomości na sekundę. Skonfiguruj limit czasu widoczności (visibility timeout) dla kolejki lub pojedynczej wiadomości tak, aby przekraczał maksymalny czas przetwarzania; w przypadku konsumentów Lambda ustaw limit czasu widoczności na co najmniej sześciokrotność limitu czasu wykonania funkcji, aby umożliwić ponowienia, zanim wiadomość ponownie stanie się widoczna. Używaj odpytywania długiego (long polling), aby zredukować liczbę pustych odbiorów. Kolejki niedoręczonych wiadomości (DLQ) przechwytują wiadomości, których nie da się przetworzyć (poison messages), gdy wiadomość przekroczy wartość maxReceiveCount; później można je ponownie skierować (redrive) z DLQ do kolejki źródłowej w celu ponownego przetworzenia po wprowadzeniu poprawek. Monitoruj metrykę ApproximateAgeOfOldestMessage, aby wykrywać zaległości i sterować zmianami współbieżności/autoskalowania.

Amazon SNS zapewnia zarządzaną usługę pub/sub o wysokiej przepustowości. Wydawcy wysyłają wiadomość raz do tematu; SNS rozsyła ją (fan-out) do wielu subskrypcji (SQS, Lambda, HTTP/S, e-mail, mobile). Polityki filtrowania subskrypcji wykorzystują atrybuty wiadomości, aby kierować tylko odpowiednie powiadomienia do poszczególnych subskrybentów, zmniejszając koszty i obciążenie systemów docelowych; pozwalają wyrażać predykaty, takie jak dokładne dopasowanie, prefiks, zakresy numeryczne, „wszystko oprócz” (anything-but) i „istnieje” (exists). Używaj SNS do rozgłaszania (fan-out), oddzielonych powiadomień i powiadomień mobilnych (push). Włącz ponowienia i rozważ użycie kolejek DLQ dla każdej subskrypcji w celu obsługi niedostarczalnych wiadomości. W przypadku wymagań dotyczących uporządkowanego rozgłaszania, tematy SNS FIFO w połączeniu z subskrypcjami w postaci kolejek SQS FIFO wymuszają zachowanie kolejności i deduplikację.

Kinesis Data Streams dostarcza uporządkowane strumienie o niskim opóźnieniu z równoległością na poziomie fragmentów (shard) na potrzeby analityki w czasie rzeczywistym i przetwarzania zdarzeń. Producenci zapisują rekordy z kluczami partycji do fragmentów; konsumenci (Lambda, KCL, konsumenci Enhanced Fan-Out, Kinesis Data Analytics) odczytują je w kolejności w ramach każdego fragmentu z wykorzystaniem punktów kontrolnych (checkpointing). Użyj pojemności na żądanie (on-demand) dla nieprzewidywalnego obciążenia lub alokowanych fragmentów (provisioned shards) z możliwością reshardingu dla przewidywalnej przepustowości. Dostosuj klucze partycji, aby zrównoważyć obciążenie „gorących” fragmentów (hot shards) i monitoruj metrykę IteratorAge w celu wykrycia opóźnień po stronie konsumentów. Enhanced Fan-Out oferuje dedykowaną przepustowość 2 MB/s na strumień konsumenta z niskim opóźnieniem dzięki mechanizmowi push przez HTTP/2.

Kinesis Data Firehose to w pełni zarządzana usługa dostarczania danych do pozyskiwania w czasie zbliżonym do rzeczywistego do S3, Amazon OpenSearch Service, Splunk lub punktów końcowych HTTP, z opcjonalną transformacją za pomocą Lambda, buforowaniem (według rozmiaru/czasu), kompresją i szyfrowaniem. Jako źródła danych może używać bezpośrednich wywołań PutRecord/PutRecordBatch, strumieni Kinesis Data Streams lub subskrypcji CloudWatch Logs/Events. Używaj Firehose, gdy potrzebujesz zarządzanego dostarczania z transformacją i grupowaniem (batching) i nie chcesz tworzyć ani obsługiwać kodu konsumenta. Partycjonowanie dynamiczne pozwala kierować rekordy do prefiksów w S3 na podstawie kluczy, co umożliwia wydajne przetwarzanie w dalszych etapach.

Routing, orkiestracja i harmonogramowanie: EventBridge i Step Functions

Amazon EventBridge to centralna magistrala zdarzeń (event bus) służąca do routingu, zarządzania (governance) i integracji między kontami oraz domenami zdarzeń. Używaj domyślnej magistrali dla zdarzeń z usług AWS, niestandardowych magistral do segmentacji domen i stosowania uprawnień, a także magistral partnerskich do integracji z SaaS. Reguły dopasowują zdarzenia za pomocą wzorców opartych na treści (content-based patterns) i kierują je do ponad 200 usług AWS. Używaj transformerów wejściowych (input transformers) do kształtowania ładunków (payloads) oraz archiwizacji/odtwarzania (archive/replay) do ponownego przetwarzania historycznych zdarzeń podczas odzyskiwania systemu lub wdrażania nowych konsumentów. Polityki zasobów (resource policies) umożliwiają routing zdarzeń między kontami w celu konsolidacji zarządzania na koncie platformowym. EventBridge Pipes zapewniają konfigurowalne przepływy punkt-punkt (point-to-point) ze źródeł zdarzeń (SQS, Kinesis, DynamoDB Streams, samodzielnie zarządzany Apache Kafka na Amazon MSK i inne) do celów, z wbudowanym filtrowaniem, przetwarzaniem wsadowym (batching), transformacją i wzbogacaniem za pomocą Lambda lub Step Functions — jest to idealne rozwiązanie, gdy nie chcesz zarządzać pełną aplikacją konsumencką, a potrzebujesz jedynie lekkiej mediacji. EventBridge Scheduler umożliwia jednorazowe i cykliczne (cron) harmonogramy wywoływania celów z rolą wykonawczą (execution role), obsługą stref czasowych i opcjonalnymi elastycznymi oknami czasowymi (flexible time windows) w celu ograniczenia zjawiska „thundering herd” (nagłego, masowego napływu żądań).

AWS Step Functions orkiestruje rozproszone przepływy pracy (workflows) zdefiniowane w Amazon States Language, używając stanów takich jak Task, Choice, Parallel, Map (w tym Distributed Map), Wait, Pass, Succeed/Fail oraz solidnych wzorców Retry/Catch. Głębokie integracje z usługami eliminują potrzebę pisania kodu klejącego (glue code) do wywoływania API AWS, włączając w to wzorce synchroniczne (.sync) i wzorce wywołania zwrotnego (callback) z tokenami zadań (task tokens). Wybierz Standard Workflows dla długotrwałych orkiestracji wymagających audytu, z gwarancją jednokrotnego wykonania każdego stanu (exactly-once), trwających do jednego roku i z ceną za przejście między stanami; historia wykonań jest zachowywana, zapewniając dużą widoczność i wbudowane ślady X-Ray. Wybierz Express Workflows dla wysokoprzepustowych, krótkotrwałych orkiestracji (od sekund do minut), gdzie możesz zamienić cenę za żądanie i czas trwania oraz semantykę wykonania „co najmniej raz” (at-least-once) na ogromną skalowalność; używaj ich do wzbogacania danych wejściowych ze strumieni, routerów zdarzeń i mikroorkiestracji, w których zadania można uczynić idempotentnymi. Stosuj wzorce takie jak saga z zadaniami kompensującymi (compensating tasks) i scentralizowaną obsługą błędów; przenieś logikę ponownych prób (retries) i timeoutów do maszyny stanów, aby uprościć kod zadań.

Wyzwalacze zasobów obliczeniowych i mechanizmy przeciwciśnienia (Backpressure): Mapowania źródeł zdarzeń Lambda

Mapowania źródeł zdarzeń Lambda (ESM) łączą źródła oparte na odpytywaniu (poll-based) z funkcjami Lambda i kontrolują współbieżność, przetwarzanie wsadowe (batching) oraz obsługę błędów.

• SQS: Lambda skaluje się horyzontalnie, odpytując kolejkę i wywołując funkcję z wsadami (do 10 wiadomości; maksymalne okno wsadowe do 300 sekund). W przypadku kolejek Standard skalowanie jest agresywne w zależności od głębokości kolejki i przepustowości wiadomości; w przypadku kolejek FIFO, Lambda zachowuje kolejność w obrębie każdej grupy wiadomości (message group) i przetwarza jeden wsad na grupę naraz. Skonfiguruj maksymalną współbieżność (maximum concurrency) w ESM, aby ograniczyć skalę workerów i chronić systemy podrzędne; połącz to z rezerwowaną/prowizjonowaną współbieżnością (reserved/provisioned concurrency), aby zagwarantować pojemność. Użyj częściowej odpowiedzi wsadowej (partial batch response), aby potwierdzać tylko pomyślnie przetworzone rekordy i ponownie umieszczać w kolejce te, które zawiodły, unikając ponownego przetwarzania całego wsadu. Ustaw visibility timeout kolejki na wartość przekraczającą łączny czas najgorszego scenariusza ponownych prób. Kolejki DLQ i polityki redrive izolują wiadomości typu „poison pill”.

• Kinesis Data Streams: Domyślnie jedno współbieżne wywołanie Lambda na fragment (shard) zapewnia zachowanie kolejności w obrębie fragmentu. Zwiększ ParallelizationFactor do 10, aby przetwarzać wiele wsadów na fragment współbieżnie, gdy kolejność między podsekwencjami nie jest krytyczna. Rozmiar wsadu do 10 000 rekordów (6 MB) i maksymalne okno wsadowe do 5 minut pozwalają amortyzować koszty i zwiększyć przepustowość. Użyj opcji bisect on function error, aby binarnie wyszukać błędne rekordy we wsadzie, oraz miejsc docelowych dla niepowodzeń (on-failure destinations) lub maksymalnej liczby ponownych prób/wieku rekordu, aby odrzucić lub przekierować nieprzetwarzalne rekordy. Monitoruj IteratorAge, aby wykryć opóźnienia konsumenta i w razie potrzeby dokonać reshardingu lub zwiększyć paralelizację.

• DynamoDB Streams: Semantyka podobna do Kinesis; rozmiar wsadu do 1000 rekordów (6 MB) i model z jednym fragmentem (shard) na klucz partycji. Konsumenci otrzymują uporządkowane mutacje na poziomie elementu (INSERT, MODIFY, REMOVE). Stosuj te same mechanizmy obsługi błędów (bisekcja przy błędzie, maksymalna liczba prób, wiek rekordu) i filtrowanie. Użyj typu widoku strumienia (stream view type), który zawiera atrybuty potrzebne konsumentowi (NewImage, OldImage, NewAndOldImages lub KeysOnly), aby zoptymalizować rozmiar ładunku.

Filtrowanie zdarzeń w ESM zmniejsza liczbę wywołań poprzez odrzucanie nieistotnych zdarzeń już na poziomie mechanizmu odpytującego (poller). Użyj agregacji w oknach przesuwnych (tumbling window) na strumieniach z Lambda, aby agregować rekordy w czasie, realizując wzorce przetwarzania w mini-wsadach.

Automatyzacja operacji i naprawa: Systems Manager Automation i OpsCenter

AWS Systems Manager Automation dostarcza runbooki (dokumenty typu Automation) napisane w JSON/YAML, zawierające kroki takie jak aws:runCommand, aws:executeScript, aws:invokeLambda, aws:approve, aws:createStack i aws:executeAutomation. Automatyzacje akceptują parametry, generują dane wyjściowe, posiadają wersjonowanie z historią zmian i działają z dedykowaną rolą AutomationAssumeRole w celu zapewnienia zasady najmniejszych uprawnień oraz operacji międzykontowych i międzyregionalnych. Można kontrolować współbieżność i progi błędów dla całych flot, wymagać zatwierdzeń i okien Change Calendar oraz integrować się z powiadomieniami przez SNS. Automatyzacje można wywoływać zgodnie z harmonogramem, z reguł EventBridge (w celu naprawy w czasie niemal rzeczywistym w odpowiedzi na zdarzenia z AWS Health, CloudWatch lub API), z akcji naprawczych AWS Config w celu egzekwowania polityk (na przykład stosowania domyślnych tagów do woluminów EBS lub dołączania domyślnego profilu instancji do instancji EC2) oraz z OpsCenter.

OpsCenter agreguje problemy operacyjne w postaci OpsItems z alarmów CloudWatch, AWS Config, zdarzeń Health lub niestandardowych źródeł. Każdy OpsItem śledzi status, priorytet, deduplikację, powiązane zasoby i linki do runbooków. Można kojarzyć runbooki „jednego kliknięcia” dla standardowych napraw i włączać automatyczną naprawę, konfigurując reguły EventBridge lub Config tak, aby uruchamiały określoną automatyzację, gdy OpsItem jest tworzony lub aktualizowany do pasującego stanu (na przykład grupa bezpieczeństwa zezwalająca na dostęp przez SSH z 0.0.0.0/0, niezgodność z polityką łatania lub nieudane kopie zapasowe). Użyj Systems Manager Explorer, aby wizualizować stan floty i otwarte OpsItems na różnych kontach i w różnych regionach. To połączenie — OpsItems jako trwałe zapisy oraz runbooki Automation jako skodyfikowane poprawki — umożliwia audytowalne i spójne operacje na dużą skalę.

Wskazówki projektowe i operacyjne

Projektuj z myślą o idempotentności dla wszystkich konsumentów, ponieważ dostarczanie co najmniej raz (at-least-once) jest powszechne. Preferuj sterowane zdarzeniami rozgałęzienie (fan-out) za pomocą SNS lub reguł EventBridge dla równoległych reakcji o niskim opóźnieniu; preferuj SQS do buforowania obciążeń i ochrony producentów przed powolnością konsumentów; preferuj Kinesis, gdy wymagane jest ścisłe zachowanie kolejności w obrębie partycji (shard) i strumienie z możliwością ponownego odtwarzania na potrzeby analityki. Używaj EventBridge Pipes do lekkiej, zarządzanej integracji między źródłami a celami, gdy dedykowany konsument to przerost formy nad treścią, a EventBridge Scheduler do wyzwalaczy czasowych bez konieczności utrzymywania infrastruktury cron.

Dobierz odpowiednie wartości timeoutów i ponowień. W przypadku SQS, timeout widoczności musi przekraczać maksymalny czas przetwarzania wraz z ponowieniami; dla strumieni ogranicz liczbę ponowień i ustaw MaximumRecordAgeInSeconds, aby uniknąć niekończącego się ponownego odtwarzania błędnych rekordów. Systematycznie używaj kolejek DLQ lub miejsc docelowych dla niepowodzeń (on-failure destinations) oraz dodawaj dashboardy i alarmy dla metryk SQS ApproximateAgeOfOldestMessage, Lambda ConcurrentExecutions/Throttles/Errors, IteratorAge, Step Functions ExecutionFailed/TimedOut i EventBridge FailedInvocations. Gdy nieuniknione są skoki ruchu, a umowy SLA dotyczące opóźnień są rygorystyczne, użyj alokowanej współbieżności Lambda (provisioned concurrency), aby wstępnie przygotować (rozgrzać) pojemność. W kwestii zarządzania (governance), preferuj EventBridge z politykami zasobów dla routingu między kontami oraz archiwizację/odtwarzanie w celu wsparcia ewolucji konsumentów i odzyskiwania po incydentach.

Praktyczny scenariusz problemowy

Shopify musi zmodernizować przetwarzanie zamówień podczas wyprzedaży błyskawicznych (flash-sale), dodając jednocześnie analitykę w czasie rzeczywistym i zautomatyzowane działania naprawcze, gdy usługi podrzędne (downstream) spowalniają lub ulegają awarii.

1. Przyjmowanie i rozgałęzianie zdarzeń dotyczących zamówień

• Użyj tematu SNS FIFO do publikowania zdarzeń OrderPlaced z procesu finalizacji zakupu, gwarantując uporządkowane, zdeduplikowane powiadomienia dla każdego OrderId. Subskrypcje obejmują:
  • Kolejkę SQS FIFO (Order-Workers) do realizacji zamówień, z zachowaniem kolejności.
  • Niestandardową magistralę zdarzeń EventBridge (CommerceBus) do zarządzania i dodatkowego routingu.
  • Strumień dostarczania Kinesis Data Firehose do dostarczania zamówień do S3 w czasie zbliżonym do rzeczywistego, z kompresją GZIP na potrzeby analityki. Dlaczego SNS FIFO: Zapewnia semantykę „dokładnie raz” (exactly-once) z zachowaniem kolejności oraz skalowalne rozgałęzienie (fan-out) do wielu subskrybentów bez sprzęgania producentów z konsumentami.

2. Buforowanie i przetwarzanie realizacji zamówień

• Lambda konsumuje komunikaty z kolejki SQS FIFO za pomocą mapowania źródła zdarzeń (event source mapping) z rozmiarem partii (batch size) 10, włączoną częściową odpowiedzią dla partii (partial batch response) i maksymalną współbieżnością ograniczoną w celu ochrony podrzędnych API magazynowych. Timeout widoczności kolejki jest ustawiony na sześciokrotność timeoutu Lambdy, aby uwzględnić ponowienia. Kolejka DLQ przechwytuje komunikaty typu „poison message” (nieprzetwarzalne) przy maxReceiveCount=3; przepływ pracy typu „redrive” później ponownie przetwarza naprawione komunikaty. Dlaczego SQS FIFO + Lambda ESM: Wymusza sekwencyjność dla każdego zamówienia, izoluje spowolnienia usług podrzędnych dzięki buforowaniu i zapewnia szczegółową obsługę błędów.

3. Orkiestracja wieloetapowej sagi

• Przepływ pracy Step Functions Standard orkiestruje przechwytywanie płatności, rezerwację zapasów, weryfikację pod kątem oszustw i rezerwację wysyłki, z ponowieniami, timeoutami i zadaniami kompensującymi (zwrot pieniędzy, uzupełnienie zapasów) na ścieżkach awarii. Pierwsze zadanie (Task) jest wyzwalane przez funkcję Lambda wywołaną przez konsumenta SQS. Dlaczego Standard: Długotrwały, audytowalny postęp stanu „dokładnie raz” (exactly-once) w systemach zewnętrznych z rozbudowaną obsługą błędów.

4. Kierowanie zdarzeń domenowych do poszczególnych funkcjonalności

• CommerceBus odbiera zdarzenia Order* za pomocą PutEvents od usług-producentów oraz z subskrypcji SNS. Reguły EventBridge:
  • Dopasowują OrderPlaced, aby powiadomić dział marketingu (Lambda) i utworzyć zgłoszenie do wsparcia (integracja z AWS Support API), gdy zamówienie składają klienci o wysokiej wartości.
  • Przekierowują OrderFailed do magistrali zdarzeń centralnego konta operacyjnego, używając polityki zasobów do zarządzania między kontami. Dlaczego EventBridge: Scentralizowany routing, filtrowanie, dostarczanie między kontami oraz możliwość dodawania nowych konsumentów bez zmiany producentów.

5. Przesyłanie danych od partnera do wzbogacania za pomocą Pipe

• EventBridge Pipes łączy kolejkę SQS Standard partnera (jednostki SKU z zamówień oczekujących) z przepływem pracy Step Functions Express, który wzbogaca elementy za pomocą funkcji Lambda i przesyła wyniki do wewnętrznej kolejki SQS w celu uzupełnienia zapasów. Dlaczego Pipes + Express: Zarządzana integracja o niskim narzucie z lekkim wzbogacaniem przy wysokiej przepustowości i niskim koszcie.

6. Analityka i wyszukiwanie w czasie rzeczywistym

• Kinesis Data Stream zbiera zdarzenia typu clickstream i operacyjne. Lambda (konsument Enhanced Fan-Out) przeprowadza sesjonizację, a Kinesis Data Analytics agreguje wskaźniki KPI. Firehose dostarcza przetransformowane zamówienia i dane analityczne do data lake na S3 oraz do Amazon OpenSearch Service z dynamicznym partycjonowaniem według daty/rynku w celu zapewnienia wydajnych zapytań. Dlaczego Streams + Firehose: Uporządkowane przetwarzanie analityczne o niskim opóźnieniu, z zarządzanym dostarczaniem i transformacją do systemów przechowywania i wyszukiwania.

7. Automatyzacja oparta na czasie

• EventBridge Scheduler uruchamia zadanie cron co minutę, aby opublikować InventorySnapshotRequested do CommerceBus, co wyzwala przepływ pracy Step Functions Express, który kompiluje migawki z różnych magazynów w celu zapewnienia dokładności stanów magazynowych w czasie zbliżonym do rzeczywistego. Dlaczego Scheduler: Natywny, odporny na awarie cron bez niestandardowej infrastruktury.

8. Zautomatyzowane działania naprawcze i operacyjne

• Reguły AWS Config wykrywają otwarty port SSH lub publiczne listy ACL S3 w sieciach VPC realizacji zamówień. Zarządzane działania naprawcze (Managed remediations) wywołują runbooki Systems Manager Automation w celu skorygowania odchyleń (drift). Alarmy CloudWatch dla metryk ApproximateAgeOfOldestMessage (SQS) i IteratorAge (Lambda) tworzą elementy OpsItems w OpsCenter; powiązane runbooki skalują alokowaną współbieżność (provisioned concurrency) dla określonych funkcji Lambda, zwiększają zarezerwowaną pojemność Step Functions lub tymczasowo poszerzają okna przetwarzania wsadowego. Reguła EventBridge dla zdarzeń AWS Health dotyczących konserwacji EC2 wskazuje dokument SSM Automation w celu płynnego restartu dotkniętych instancji podczas okien konserwacyjnych. Dlaczego OpsCenter + Automation: Scentralizowane, audytowalne śledzenie problemów z jedno-klikowymi lub automatycznymi działaniami naprawczymi opartymi na zasadzie najmniejszych uprawnień, które działają bezpiecznie na wielu kontach/regionach.

Ten projekt wytrzymuje skoki ruchu podczas wyprzedaży błyskawicznych dzięki buforowaniu i rozgałęzianiu, zachowuje niezmienniki biznesowe poprzez orkiestrację, dostarcza analitykę w ciągu sekund i zamyka pętlę dzięki zautomatyzowanym działaniom naprawczym opartym na politykach.

← Wysoka dostępność · Wszystkie domeny · Pamięć masowa →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →