Lambda@Edge og hendelsesdrevne mønstre

Lambda@Edge lar Dem kjøre Lambda-funksjoner på CloudFront edge locations over hele verden – nærmere sluttbrukerne – i stedet for i en sentralisert Region. Dette gjør det mulig å tilpasse HTTP-forespørsler og -svar med mindre enn ett millisekund ekstra forsinkelse i CDN-laget. Lambda@Edge-funksjoner distribueres globalt og aktiveres ved hver CloudFront-hendelse for cache-treff eller cache-miss, noe som gjør dem ideelle for lette oppgaver som manipulerer forespørsler.

Lambda@Edge kan avskjære trafikk på fire punkter i CloudFronts livssyklus for forespørsler:

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

Lambda@Edge har strengere begrensninger enn vanlig Lambda: maksimalt 128 MB minne (viewer-hendelser), 1 GB (origin-hendelser), maksimalt 5 sekunder tidsavbrudd (viewer) og 30 sekunder (origin). Funksjoner må opprettes i us-east-1 og distribueres til edge via CloudFront. VPC, miljøvariabler og Lambda Layers støttes ikke. Disse begrensningene betyr at Lambda@Edge er laget for lette transformasjoner, ikke tung behandling.

Lambda@Edge egner seg godt til: A/B-testing (skrive om URL-er til ulike origin-stier basert på informasjonskapsler), autentisering (validere JWT-er på edge før videresending til origin), manipulering av HTTP-headere (legge til sikkerhetsh headere som HSTS, CSP og X-Frame-Options), normalisering av URL-er (viderekoble www til ikke-www eller håndheve avsluttende skråstreker) og personalisering (levere ulikt innhold basert på seerens land fra CloudFront-Viewer-Country-headeren).

CloudFront Functions er svært lette JavaScript-funksjoner som bare kjører på viewer request/response-stadiene, med en grense på 2 ms for kjøretid og betydelig lavere kostnad. For enkle bruksområder (omskriving av URL-er, manipulering av headere og normalisering av cache-nøkler) foretrekkes CloudFront Functions fremfor Lambda@Edge fordi de er raskere og billigere. Bruk Lambda@Edge når De trenger tilgang til nettverkskall, større nyttelaster eller utløserpunktene for origin request/response.

Hendelsesdrevet arkitektur kobler tjenester sammen gjennom hendelser – meldinger som representerer noe som har skjedd. I AWS er Lambda den primære hendelseskonsumenten: den mottar hendelser fra SQS, SNS, DynamoDB Streams, Kinesis, S3, EventBridge og mer. Hver hendelse utløser en Lambda-kjøring, slik at systemer kan reagere asynkront og uavhengig uten tett kobling. Dette mønsteret muliggjør løs kobling, uavhengig skalering og isolering av feil.

Lambda kan konfigureres som en tilordning av hendelseskilde for SQS. Lambda poller køen, henter opptil en batchstørrelse med meldinger (opptil 10 000 for standardkøer og 10 for FIFO) og aktiverer funksjonen én gang per batch. Hvis funksjonen mislykkes, returneres hele batchen til køen. Konfigurer et batchvindu for å vente på flere meldinger før funksjonen aktiveres, slik at gjennomstrømmingen forbedres. Bruk en DLQ på kilde-SQS-køen for meldinger som mislykkes gjentatte ganger.

DynamoDB Streams registrerer hver endring på elementnivå (INSERT, MODIFY, REMOVE) som en ordnet sekvens av hendelser. Lambda leser fra strømmen ved hjelp av en tilordning av hendelseskilde med TRIM_HORIZON (start fra den eldste) eller LATEST (start fra den nyeste). Lambda behandler poster i rekkefølge innenfor en partisjon. Batch-er som mislykkes, blokkerer videre behandling av den samme partisjonen til problemet er løst – bruk bisect on error til å dele opp mislykkede batcher og isolere problematiske poster.

Lambda behandler Kinesis-poster på samme måte som DynamoDB Streams – én samtidig kjøring per shard. Viktige konfigurasjonsalternativer omfatter parallelliseringsfaktor (opptil 10 samtidige Lambda-invokasjoner per shard, som behandler underbatcher parallelt) og enhanced fan-out (dedikert gjennomstrømming på 2 MB/s per shard for Lambda-konsumenten). Disse alternativene øker gjennomstrømmingen betydelig for strømmer med høyt volum uten at antallet shards må økes.

Amazon EventBridge er den anbefalte hendelsesbussen for å koble sammen AWS-tjenester og egendefinerte applikasjoner. Hendelser flyter inn i en buss, og regler filtrerer hendelser etter mønster og ruter dem til mål som Lambda, SQS, Step Functions og flere. EventBridge frikobler hendelsesprodusenter og -konsumenter fullstendig – ingen av dem kjenner til den andre. Den standardiserte hendelsesbussen mottar hendelser fra AWS-tjenester. Opprett en egendefinert hendelsesbuss for hendelser fra applikasjonen Deres.

Et vanlig hendelsesdrevet mønster er fan-out: én hendelse utløser flere parallelle behandlingsforløp. Publiser til et SNS topic, så reagerer flere Lambda-funksjonsabonnementer uavhengig av hverandre. Når en ordre for eksempel legges inn, kan hendelsen fordeles til: en Lambda-funksjon som sender en bekreftelses-e-post, en Lambda-funksjon som oppdaterer lagerbeholdningen, og en Lambda-funksjon som varsler lageret. Hver konsument er uavhengig og skaleres separat – ingen enkeltkonsument kan blokkere de andre.

I denne leksjonen har De lært at Lambda@Edge kjører funksjoner på CloudFront edge locations med fire utløserpunkter (viewer request/response og origin request/response) for oppgaver som autentisering, omskriving av URL-er og manipulering av headere; CloudFront Functions er et rimeligere alternativ med lavere forsinkelse for enkle transformasjoner på viewer-stadiet; og hendelsesdrevne mønstre med SQS, DynamoDB Streams, Kinesis, EventBridge og SNS fan-out muliggjør løst koblede arkitekturer der Lambda reagerer på hendelser i sanntid. Neste tema er standardkøer kontra FIFO-køer i SQS.