Strumienie DynamoDB i tabele globalne

DynamoDB Streams przechwytuje uporządkowaną w czasie sekwencję modyfikacji elementów w tabeli DynamoDB. Za każdym razem, gdy element jest tworzony, aktualizowany lub usuwany, DynamoDB zapisuje rekord strumienia opisujący tę zmianę. Rekordy strumienia są dostępne przez 24 godziny od momentu zapisu.

Streams stanowią podstawę architektur sterowanych zdarzeniami z użyciem DynamoDB. Typowe zastosowania obejmują uruchamianie funkcji Lambda do przetwarzania w czasie rzeczywistym, prowadzenie dziennika audytowego, replikowanie danych do innego magazynu lub unieważnianie pamięci podręcznej po zmianie danych.

Podczas włączania strumienia należy wybrać StreamViewType, który określa, jakie dane zawiera każdy rekord strumienia:

• KEYS_ONLY: tylko atrybuty klucza głównego zmodyfikowanego elementu
• NEW_IMAGE: cały element w postaci po zmianie
• OLD_IMAGE: cały element w postaci sprzed zmiany
• NEW_AND_OLD_IMAGES: zarówno stan elementu sprzed zmiany, jak i po niej

W przypadku audytu należy wybrać NEW_AND_OLD_IMAGES, aby widzieć, co się zmieniło; w przypadku replikacji lub aktualizacji pamięci podręcznej — NEW_IMAGE; a KEYS_ONLY, gdy wystarczy wiedzieć, który element się zmienił, i pobrać jego bieżący stan osobno.

Najczęstszym sposobem korzystania z DynamoDB Stream jest użycie AWS Lambda. Lambda odczytuje strumień i wywołuje Państwa funkcję z partią rekordów strumienia. Lambda automatycznie obsługuje odpytywanie, zapisywanie punktów kontrolnych i ponawianie prób.

Najważniejsze parametry konfiguracji: batch size (liczba rekordów na wywołanie, maksymalnie 10 000), bisect on error (podział nieudanej partii w celu odizolowania błędnego rekordu) oraz destination on failure (SQS lub SNS dla rekordów, których nie można przetworzyć). Lambda odczytuje dane z każdego fragmentu równolegle, dlatego stopień równoległości jest równy liczbie fragmentów w strumieniu.

Praktyczne przypadki użycia DynamoDB Streams na egzaminie SAA-C03:

• Replikacja między regionami: Lambda odczytuje strumień i zapisuje zmiany w tabeli w innym regionie (przed wprowadzeniem Global Tables był to standardowy wzorzec)
• Unieważnianie ElastiCache: gdy element DynamoDB się zmienia, Lambda unieważnia lub aktualizuje odpowiadający mu klucz pamięci podręcznej
• Synchronizacja indeksu wyszukiwania: przekazywanie zmian elementów do OpenSearch Service w celu umożliwienia wyszukiwania pełnotekstowego danych DynamoDB
• Rejestrowanie audytowe: zapisywanie każdej zmiany w S3 lub magazynie zgodności z wymaganiami w celach regulacyjnych
• Mikrousługi sterowane zdarzeniami: uruchamianie usług zależnych, gdy zmienią się określone elementy

DynamoDB Global Tables zapewniają w pełni zarządzaną, wieloregionową replikację multi-active. Każdy region otrzymuje pełną kopię tabeli, a wszystkie kopie mogą jednocześnie obsługiwać zapisy. Zapisy w dowolnym regionie są asynchronicznie replikowane do wszystkich pozostałych regionów w ciągu około 1 sekundy.

Global Tables umożliwiają realizację dwóch kluczowych scenariuszy: odczyty i zapisy z niskimi opóźnieniami dla użytkowników rozproszonych globalnie (każdy użytkownik zapisuje i odczytuje dane z najbliższego regionu) oraz aktywne-aktywne odzyskiwanie po awarii w wielu regionach (aplikacja działa nadal w każdym ocalałym regionie, bez utraty danych zapisanych po ostatniej replikacji).

Aby utworzyć Global Table, należy najpierw utworzyć tabelę z włączonym DynamoDB Streams (NEW_AND_OLD_IMAGES jest wymagane wewnętrznie przez Global Tables). Następnie należy dodać regiony replik. AWS utworzy tabelę repliki w każdym dodanym regionie i rozpocznie dwukierunkową synchronizację danych.

Global Tables (Version 2019.11.21) to obecny standard. Obsługują pojemność On-Demand lub Provisioned z Auto Scaling. Replika w każdym regionie musi mieć tę samą nazwę tabeli. Regiony można dodawać do Global Table i usuwać z niej w dowolnym momencie.

Ponieważ Global Tables umożliwiają jednoczesne zapisy w wielu regionach, mogą wystąpić konflikty zapisów, jeśli dwa regiony zaktualizują ten sam element niemal w tym samym czasie. DynamoDB rozwiązuje konflikty za pomocą podejścia last-writer-wins, opartego na znacznikach czasu przechowywanych w rekordach strumienia.

W praktyce oznacza to, że dwie niemal jednoczesne sprzeczne aktualizacje zakończą się zaakceptowaniem jednej z nich i nadpisaniem drugiej. Aplikacje należy projektować tak, aby unikać jednoczesnych zapisów tego samego elementu z różnych regionów. W przypadkach, w których konflikty występują często, należy rozważyć kierowanie wszystkich zapisów dotyczących konkretnego użytkownika lub encji do jednego regionu macierzystego.

W przypadku Global Tables zapisy w jednym regionie są automatycznie replikowane do wszystkich pozostałych regionów. Każdy replikowany zapis zużywa WCU w regionach docelowych — jeśli mają Państwo 3 regiony, pojedynczy zapis kosztuje łącznie około 3× WCU. Należy odpowiednio zaplanować pojemność.

Odczyty w każdym regionie zużywają RCU lokalnej repliki. Odczyty eventual consistency (domyślne) korzystają z danych lokalnych, natomiast strongly consistent odczyty nie są obsługiwane między regionami. W przypadku większości aplikacji globalnych eventual consistency z opóźnieniem między regionami wynoszącym około 1 sekundy jest wystarczająca.

Kluczowe rozróżnienie na egzaminie SAA-C03: DynamoDB Global Tables działają w trybie multi-active (wszystkie regiony akceptują odczyty ORAZ zapisy), podczas gdy repliki odczytu RDS między regionami są tylko do odczytu (replikę można jedynie promować, aby umożliwić jej zapisy, co przerywa replikację).

Global Tables należy użyć, gdy potrzebne są: zapisy multi-active w wielu regionach, globalny dostęp z opóźnieniem poniżej 100 ms lub odzyskiwanie po awarii w wielu regionach dla danych NoSQL bez utraty danych (RPO równy zero). Repliki RDS między regionami należy wybrać, gdy potrzebne są: globalne skalowanie odczytów relacyjnej bazy danych lub gotowa replika zapasowa, którą można promować podczas przełączania awaryjnego.

Typowe wzorce architektury łączące Streams i Lambda:

• Fan-out: Lambda odczytuje strumień i publikuje dane w SNS, które przekazuje je do wielu kolejek SQS dla niezależnych odbiorców
• Agregacja: Lambda gromadzi zmiany i aktualizuje zagregowane wartości w osobnej tabeli DynamoDB (np. dzienną liczbę zamówień)
• Pamięć podręczna write-behind: przy każdym zdarzeniu strumienia Lambda aktualizuje ElastiCache, aby odczyty mogły być obsługiwane z pamięci podręcznej
• Powiadomienia: strumień uruchamia Lambdę, która wysyła wiadomość e-mail za pośrednictwem SES lub powiadomienie push SNS po zmianie określonego warunku

Jako alternatywę dla DynamoDB Streams można kierować zmiany na poziomie elementów do usługi Amazon Kinesis Data Stream. Jest to przydatne, gdy potrzebują Państwo dłuższego przechowywania danych (do 1 roku w porównaniu z 24 godzinami w natywnej usłudze DynamoDB Streams), większej liczby konsumentów lub integracji z usługami odczytującymi dane z Kinesis.

Integrację z Kinesis Data Streams włącza się dla poszczególnych tabel i nie zastępuje ona DynamoDB Streams — obie funkcje mogą być włączone jednocześnie. Jest to nowsza funkcja (z 2021 roku), która rozszerza potok zdarzeń zmian w DynamoDB bez konieczności implementowania własnej logiki replikacji.

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

W tej lekcji poznali Państwo następujące zagadnienia: DynamoDB Streams przechwytuje zmiany na poziomie elementów przez 24 godziny i integruje się z Lambda na potrzeby przetwarzania sterowanego zdarzeniami, Global Tables zapewniają replikację multi-active w wielu regionach z rozwiązywaniem konfliktów według zasady „wygrywa ostatni zapis”, a integracja z Kinesis Data Streams wydłuża okres przechowywania poza 24-godzinne okno strumienia. W następnej części omówimy strefy hostowane Route 53 i typy rekordów DNS.