DynamoDB Streams en Global Tables

DynamoDB Streams legt een chronologische reeks wijzigingen op itemniveau in een DynamoDB-tabel vast. Telkens wanneer een item wordt aangemaakt, bijgewerkt of verwijderd, schrijft DynamoDB een streamrecord waarin de wijziging wordt beschreven. Streamrecords zijn 24 uur beschikbaar nadat ze zijn geschreven.

Streams vormen de basis van gebeurtenisgestuurde architecturen met DynamoDB. Veelgebruikte toepassingen zijn onder andere het activeren van Lambda-functies voor realtimeverwerking, het bijhouden van een auditlogboek, het repliceren van gegevens naar een andere opslaglocatie of het ongeldig maken van een cache wanneer gegevens veranderen.

Bij het inschakelen van een stream kiest u een StreamViewType die bepaalt welke gegevens elk streamrecord bevat:

• KEYS_ONLY: alleen de primaire-sleutelattributen van het gewijzigde item
• NEW_IMAGE: het volledige item zoals het er na de wijziging uitziet
• OLD_IMAGE: het volledige item zoals het er vóór de wijziging uitzag
• NEW_AND_OLD_IMAGES: zowel de toestand van het item vóór als na de wijziging

Kies NEW_AND_OLD_IMAGES voor auditing (om te zien wat er is gewijzigd), NEW_IMAGE voor replicatie of cache-updates en KEYS_ONLY wanneer u alleen hoeft te weten welk item is gewijzigd en de huidige toestand afzonderlijk ophaalt.

De meest gebruikelijke manier om een DynamoDB Stream te consumeren is met AWS Lambda. Lambda leest de stream uit en roept uw functie aan met een batch streamrecords. Lambda handelt het uitlezen, het opslaan van controlepunten en automatisch opnieuw proberen af.

Belangrijke configuratieparameters zijn: batchgrootte (het aantal records per aanroep, maximaal 10.000), splitsen bij fout (een mislukte batch opsplitsen om het problematische record te isoleren) en bestemming bij mislukking (SQS of SNS voor records die niet kunnen worden verwerkt). Lambda leest elke shard parallel uit, dus de mate van parallellisme is gelijk aan het aantal shards in de stream.

Praktische toepassingen van DynamoDB Streams voor het SAA-C03-examen:

• Replicatie tussen regio's: Lambda leest de stream en schrijft wijzigingen naar een tabel in een andere regio (voordat Global Tables bestonden, was dit het standaardpatroon)
• ElastiCache ongeldig maken: wanneer een DynamoDB-item verandert, maakt Lambda de bijbehorende cachesleutel ongeldig of werkt deze bij
• Synchronisatie van zoekindexen: stuur itemwijzigingen naar OpenSearch Service om zoeken in volledige tekst op DynamoDB-gegevens mogelijk te maken
• Auditlogging: schrijf elke wijziging naar S3 of een opslaglocatie voor naleving van regelgeving
• Gebeurtenisgestuurde microservices: activeer achterliggende services wanneer specifieke items veranderen

DynamoDB Global Tables bieden volledig beheerde replicatie over meerdere regio's met meerdere actieve regio's. Elke regio krijgt een volledige kopie van de tabel en alle kopieën kunnen gelijktijdig worden beschreven. Schrijfacties in elke regio worden asynchroon binnen ongeveer 1 seconde naar alle andere regio's gerepliceerd.

Global Tables maken twee belangrijke scenario's mogelijk: lezen en schrijven met lage latentie voor wereldwijd verspreide gebruikers (elke gebruiker schrijft naar en leest uit de dichtstbijzijnde regio) en actief-actief noodherstel in meerdere regio's (de applicatie blijft actief in elke overgebleven regio, zonder gegevensverlies sinds de laatste replicatie).

Om een Global Table aan te maken, maakt u eerst een tabel met ingeschakelde DynamoDB Streams (NEW_AND_OLD_IMAGES is intern vereist voor Global Tables). Vervolgens voegt u replicaregio's toe. AWS maakt in elke toegevoegde regio een replicatabel aan en begint gegevens in beide richtingen te synchroniseren.

Global Tables (Version 2019.11.21) zijn de huidige standaard en ondersteunen On-Demand- of Provisioned-capaciteit met Auto Scaling. Elke replicatabel in een regio moet dezelfde tabelnaam hebben. U kunt op elk moment regio's aan een Global Table toevoegen of eruit verwijderen.

Omdat Global Tables schrijven in meerdere regio's tegelijk toestaan, kunnen er schrijfconflicten ontstaan wanneer twee regio's vrijwel op hetzelfde moment hetzelfde item bijwerken. DynamoDB lost conflicten op met een aanpak waarbij de laatste schrijver wint, op basis van tijdstempels in de streamrecords.

In de praktijk betekent dit dat twee vrijwel gelijktijdige conflicterende updates ertoe leiden dat één update wint en de andere wordt overschreven. Applicaties moeten zo worden ontworpen dat gelijktijdige schrijfacties naar hetzelfde item vanuit verschillende regio's worden voorkomen. Overweeg voor toepassingen waarin conflicten vaak voorkomen om alle schrijfacties voor een specifieke gebruiker of entiteit naar één thuisregio te routeren.

Met Global Tables worden schrijfacties in één regio automatisch naar alle andere regio's gerepliceerd. Elke gerepliceerde schrijfactie verbruikt WCU's in de doelregio's—bij 3 regio's kost één schrijfactie dus ongeveer 3× de WCU's over alle regio's. Plan de capaciteit dienovereenkomstig.

Lezingen in elke regio verbruiken de RCU's van de lokale replica. Eventual-consistente lezingen (de standaard) gebruiken lokale gegevens, terwijl sterk consistente lezingen niet tussen regio's worden ondersteund. Voor de meeste wereldwijde applicaties is eventual consistency binnen ongeveer 1 seconde tussen regio's acceptabel.

Een belangrijk onderscheid voor het SAA-C03-examen: DynamoDB Global Tables zijn multi-actief (alle regio's accepteren lees- EN schrijfacties), terwijl RDS-leesreplica's tussen regio's alleen-lezen zijn (u kunt een replica alleen promoveren om deze schrijfbaar te maken, waarbij de replicatie wordt verbroken).

Gebruik DynamoDB Global Tables wanneer u het volgende nodig hebt: actief-actieve schrijfacties in meerdere regio's, wereldwijde toegang met een latentie van minder dan 100 ms of noodherstel in meerdere regio's met een RPO van nul voor NoSQL-gegevens. Gebruik RDS-replica's tussen regio's wanneer u het volgende nodig hebt: wereldwijde schaalbaarheid voor lezen in een relationele database of een warme stand-by voor noodherstel die u bij een failover kunt promoveren.

Veelvoorkomende architectuurpatronen waarin Streams en Lambda worden gecombineerd:

• Fan-out: Lambda leest de stream en publiceert naar SNS, dat de berichten verdeelt over meerdere SQS-wachtrijen voor onafhankelijke consumenten
• Aggregatie: Lambda verzamelt wijzigingen en werkt geaggregeerde totalen bij in een afzonderlijke DynamoDB-tabel (bijvoorbeeld het dagelijkse aantal bestellingen)
• Write-behind-cache: bij elke streamgebeurtenis werkt Lambda ElastiCache bij, zodat lezingen vanuit de cache kunnen worden afgehandeld
• Meldingen: de stream activeert Lambda, die een SES-e-mail of SNS-pushmelding verstuurt wanneer een specifieke voorwaarde verandert

Als alternatief voor DynamoDB Streams kun je wijzigingen op itemniveau doorsturen naar een Amazon Kinesis Data Stream. Dit is handig wanneer je een langere bewaartermijn nodig hebt (maximaal 1 jaar tegenover 24 uur voor native DynamoDB Streams), meer consumers wilt gebruiken of wilt integreren met services die gegevens uit Kinesis lezen.

Integratie met Kinesis Data Streams wordt per tabel ingeschakeld en vervangt DynamoDB Streams niet: je kunt beide tegelijkertijd inschakelen. Dit is een nieuwere functie (uit 2021) die de pipeline voor wijzigingsgebeurtenissen van DynamoDB uitbreidt zonder dat je aangepaste replicatielogica nodig hebt.

In deze les heb je geleerd dat DynamoDB Streams wijzigingen op itemniveau 24 uur lang vastleggen en integreren met Lambda voor gebeurtenisgestuurde verwerking, dat Global Tables replicatie over meerdere actieve regio's bieden met conflictoplossing volgens het principe dat de laatste schrijver wint, en dat integratie met Kinesis Data Streams de bewaartermijn verlengt tot voorbij het venster van 24 uur van de stream. Hierna bekijken we gehoste zones van Route 53 en typen DNS-records.