Lambda@Edge og hændelsesdrevne mønstre

Lambda@Edge lader dig køre Lambda-funktioner på CloudFront edge locations over hele verden – tættere på slutbrugerne – i stedet for i en centraliseret Region. Det gør det muligt at tilpasse HTTP-forespørgsler og -svar med en ekstra latenstid på under et millisekund i CDN-laget. Lambda@Edge-funktioner distribueres globalt og kaldes ved hver CloudFront-hændelse med cache hit eller miss, hvilket gør dem ideelle til letvægtsopgaver med manipulation af forespørgsler.

Lambda@Edge kan opfange trafik på fire punkter i CloudFronts livscyklus for forespørgsler:

• Viewer Request: udløses, når CloudFront modtager en forespørgsel fra seeren (brugeren), før cachen kontrolleres
• Origin Request: udløses, når CloudFront videresender et cache-miss til origin
• Origin Response: udløses, når origin returnerer et svar, før det caches
• Viewer Response: udløses, før CloudFront returnerer svaret til seeren

Lambda@Edge har strengere begrænsninger end almindelig Lambda: højst 128 MB hukommelse (seertevent), 1 GB (origin-events), højst 5 sekunders timeout (seere) og 30 sekunder (origin). Funktioner skal oprettes i us-east-1 og distribueres til edge via CloudFront. Der er ingen understøttelse af VPC, ingen miljøvariabler og ingen Lambda Layers. Disse begrænsninger betyder, at Lambda@Edge er beregnet til letvægts-transformationer, ikke tung behandling.

Lambda@Edge er velegnet til: A/B-test (omskriv URL'er til forskellige origin-stier baseret på cookies), godkendelse (validér JWT'er ved edge, før de videresendes til origin), manipulation af HTTP-headere (tilføj sikkerhedsheadere som HSTS, CSP og X-Frame-Options), normalisering af URL'er (omdirigér www til non-www, eller gennemtving afsluttende skråstreger) samt personalisering (vis forskelligt indhold baseret på seerens land fra headeren CloudFront-Viewer-Country).

CloudFront Functions er ultralette JavaScript-funktioner, der kun kører på stadierne for viewer-forespørgsler og -svar, med en grænse på 2 ms for eksekveringstid og en langt lavere pris. Til enkle anvendelser (omskrivning af URL'er, manipulation af headere og normalisering af cache-nøgler) foretrækkes CloudFront Functions frem for Lambda@Edge, fordi de er hurtigere og billigere. Brug Lambda@Edge, når du har brug for netværkskald, større payloads eller udløsningspunkterne for origin-forespørgsler og -svar.

Hændelsesdrevet arkitektur forbinder tjenester gennem hændelser – meddelelser, der repræsenterer noget, som er sket. I AWS er Lambda den primære hændelsesforbruger: den modtager hændelser fra SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge og flere. Hver hændelse udløser en Lambda-eksekvering, så systemer kan reagere asynkront og uafhængigt uden tæt kobling. Dette mønster muliggør løs kobling, uafhængig skalering og fejlisolering.

Lambda kan konfigureres som en event source mapping for SQS. Lambda poller køen, henter op til en batchstørrelse af meddelelser (op til 10.000 for standardkøer og 10 for FIFO) og kalder funktionen én gang pr. batch. Hvis funktionen mislykkes, returneres hele batchen til køen. Konfigurér et batchvindue for at vente på flere meddelelser, før funktionen kaldes, så gennemløbet forbedres. Brug en DLQ på kilde-SQS-køen til meddelelser, der gentagne gange mislykkes.

DynamoDB Streams registrerer enhver ændring på elementniveau (INSERT, MODIFY, REMOVE) som en ordnet sekvens af hændelser. Lambda læser fra streamen ved hjælp af en event source mapping med TRIM_HORIZON (start fra den ældste) eller LATEST (start fra den nyeste). Lambda behandler poster i rækkefølge inden for en partition. Mislykkede batches blokerer yderligere behandling af den samme partition, indtil problemet er løst – brug bisect on error til at opdele mislykkede batches og isolere problematiske poster.

Lambda behandler Kinesis-poster på samme måde som DynamoDB Streams – én samtidig eksekvering pr. shard. Vigtige konfigurationsmuligheder omfatter paralleliseringsfaktor (op til 10 samtidige Lambda-kald pr. shard, hvor underbatches behandles parallelt) og enhanced fan-out (dedikeret gennemløb på 2 MB/s pr. shard til Lambda-forbrugeren). Disse muligheder øger gennemløbet markant for streams med stor volumen uden at øge antallet af shards.

Amazon EventBridge er den anbefalede hændelsesbus til at forbinde AWS-tjenester og brugerdefinerede applikationer. Hændelser strømmer ind i en bus, og regler filtrerer hændelser efter mønster og dirigerer dem til mål, herunder Lambda, SQS, Step Functions og flere. EventBridge afkobler producenter af hændelser fuldstændigt fra forbrugerne – ingen af dem kender til den anden. Den standardmæssige hændelsesbus modtager hændelser fra AWS-tjenester; opret en brugerdefineret hændelsesbus til hændelser fra din applikation.

Et almindeligt hændelsesdrevet mønster er fan-out: én hændelse udløser flere parallelle behandlingspipelines. Publicér til et SNS-emne, hvorefter flere abonnementer på Lambda-funktioner reagerer uafhængigt. Når der f.eks. afgives en ordre, fordeles hændelsen til en Lambda, der sender en bekræftelsesmail, en Lambda, der opdaterer lagerbeholdningen, og en Lambda, der underretter lageret. Hver forbruger er uafhængig og skaleres separat – ingen enkelt forbruger kan blokere de andre.

I denne lektion lærte du, at Lambda@Edge kører funktioner på CloudFront edge locations med fire udløsningspunkter (viewer-forespørgsel/-svar og origin-forespørgsel/-svar) til opgaver som godkendelse, omskrivning af URL'er og manipulation af headere; at CloudFront Functions er det billigere alternativ med lavere latenstid til enkle transformationer på viewer-stadiet; samt at hændelsesdrevne mønstre ved hjælp af SQS, DynamoDB Streams, Kinesis, EventBridge og SNS-fan-out muliggør løst koblede arkitekturer, hvor Lambda reagerer på hændelser i realtid. Dernæst udforsker vi standard-SQS-køer sammenlignet med FIFO-køer.