Kinesis Data Streams for sanntidsbehandling av hendelser

Kinesis Data Streams (KDS) er en robust datastrømmetjeneste for ordnede data i sanntid. Data organiseres i en strøm som består av én eller flere shards. Hver shard er en ordnet sekvens av dataposter. Produsenter legger poster i shards ved hjelp av en partisjonsnøkkel som bestemmer hvilken shard som mottar posten. Konsumenter leser poster fra shards og behandler dem i den rekkefølgen de ankom i hver shard.

Hver shard støtter skrivegjennomstrømming på 1 MB/s eller 1 000 poster/s og lesegjennomstrømming på 2 MB/s (delt mellom alle standardkonsumenter på den sharden). Den totale kapasiteten til strømmen skalerer lineært med antallet shards. Bruk formelen: shards_needed = max(write_MB_per_s / 1, read_MB_per_s / 2). Hvis produsentene når skrivegrensen, oppstår feil av typen ProvisionedThroughputExceededException — løs dette ved å dele opp shards eller fordele partisjonsnøklene jevnere.

Partisjonsnøkkelen er en streng som Kinesis hasher (MD5) for å bestemme hvilken shard som mottar en post. En godt valgt partisjonsnøkkel fordeler poster jevnt mellom shards (forebygging av overbelastede shards). For IoT kan De bruke enhets-ID. For klikkstrømmer kan De bruke økt-ID eller bruker-ID. Unngå partisjonsnøkler med få mulige verdier (for eksempel landenavn med bare fem verdier), siden de fører til overbelastede shards der én shard mottar en uforholdsmessig stor del av skrivebelastningen, mens andre står ubenyttet.

Standardkonsumenter deler lesegjennomstrømmingen på 2 MB/s per shard ved å bruke GetRecords med polling. Hvis De har tre konsumenter på en shard og hver trenger 2 MB/s, blir de begrenset når de deler totalt 2 MB/s. Enhanced Fan-Out (EFO) gir hver registrerte konsument sin egen dedikerte lesestrøm på 2 MB/s via en vedvarende HTTP/2-tilkobling for push (SubscribeToShard). EFO medfører en kostnad per konsument-shard-time, men eliminerer all konkurranse om lesekapasiteten.

Lambda integreres direkte med Kinesis Data Streams via en Event Source Mapping. Lambda poller strømmen, leser grupper med poster og starter funksjonen Deres. Konfigurer BatchSize (1–10 000 poster), StartingPosition (TRIM_HORIZON for de eldste, LATEST for de nyeste) og BisectBatchOnFunctionError for å dele grupper som feiler. Parallelisation Factor (1–10) lar Lambda starte flere samtidige kjøringer per shard for å holde tritt med strømmer som beveger seg raskt.

Kinesis Client Library (KCL) er et applikasjonsrammeverk for å bygge robuste Kinesis-konsumenter i Java (eller på flere språk via MultiLangDaemon). KCL håndterer opptelling av shards, lease-administrasjon (fordeling av shards mellom arbeiderinstanser), kontrollpunktlagring av fremdrift i DynamoDB og kontrollert håndtering av oppsplitting og sammenslåing av shards. Hver KCL-arbeider behandler én eller flere shards, og KCL omfordeler automatisk shards når arbeidere skaleres ut eller feiler. KCL foretrekkes fremfor rå polling med SDK for konsumentapplikasjoner i produksjon.

Kinesis Data Streams lagrer poster i 24 timer som standard (kan utvides til 7 dager eller opptil 365 dager med Long-Term Retention mot en tilleggskostnad). I motsetning til SQS blir konsumerte poster ikke slettet etter konsumering — de forblir tilgjengelige til lagringstiden utløper. Dette gjør det mulig for flere konsumenter å lese de samme postene uavhengig av hverandre, og muliggjør avspilling ved å tilbakestille en konsuments kontrollpunkt til et tidligere sekvensnummer — svært nyttig ved feilretting eller utfylling av historiske data for nye tjenester.

Kinesis Data Streams støtter to kapasitetsmoduser. Provisioned mode: De administrerer antallet shards manuelt og betaler per shard-time. On-Demand mode: Kinesis skalerer automatisk shard-kapasiteten basert på innkommende gjennomstrømming (som standard opptil 200 MB/s skriving og 400 MB/s lesing), og De betaler per GB med data som skrives og hentes. On-demand-modus egner seg godt for varierende eller uforutsigbare trafikkmønstre der De ikke ønsker å administrere skaleringen av shards.

Kinesis garanterer rekkefølge innenfor en shard — poster med samme partisjonsnøkkel går alltid til samme shard og leses i den rekkefølgen de ble skrevet. Det finnes imidlertid ingen garanti for rekkefølge på tvers av shards. Hvis applikasjonen Deres krever global rekkefølge for alle poster, kan De bruke én enkelt shard (som begrenser gjennomstrømmingen til 1 MB/s) eller utforme systemet på nytt slik at rekkefølge bare er nødvendig innenfor en gruppe med samme partisjonsnøkkel (for eksempel rekkefølge per enhet). Dette er en vanlig forskjell på eksamen sammenlignet med SQS FIFO, som tilbyr streng deduplisering og rekkefølge.

Kinesis Data Streams krypterer poster på tjenersiden når de er lagret ved hjelp av AWS KMS (CMK eller AWS-administrert nøkkel) når kryptering på tjenersiden er aktivert. Alle data under overføring krypteres med TLS. For applikasjoner som kjører i en VPC og ikke skal sende strømmens data over det offentlige internett, kan De bruke et VPC Interface Endpoint (PrivateLink) for Kinesis, slik at trafikken forblir i AWS-nettverkets interne ryggrad — noe som er viktig for regulerte arbeidsbelastninger.

På SAA-C03-eksamen bør De sammenligne Kinesis Data Streams med alternativene. Kinesis kontra SQS: Kinesis bevarer rekkefølgen innenfor en shard og støtter flere konsumenter som leser de samme dataene; SQS sletter meldinger etter konsumering. Kinesis kontra MSK (Kafka): MSK er administrert Apache Kafka — bruk det når De trenger kompatibilitet med Kafka-protokollen, avansert konfigurasjon av topics eller migrerer fra Kafka lokalt. Bruk Kinesis for AWS-basert strømming med tettere integrasjon med Lambda, Firehose og Flink. Velg Kinesis med mindre oppgaven spesifikt nevner Kafka eller krav om Kafka-kompatibilitet.

I denne leksjonen lærte De: Kinesis Data Streams tilbyr oppdelte, ordnede og robuste datastrømmer med 24 timers standardlagring og mulighet for avspilling, Enhanced Fan-Out gir hver konsument en dedikert kapasitet på 2 MB/s per shard og eliminerer konkurranse om lesekapasiteten, og On-Demand-modus skalerer shards automatisk for uforutsigbar trafikk. Neste tema er mønstrene choreography og orchestration i hendelsesdrevet arkitektur.