Hvis du ønsker å bygge en serverløs arkitektur i AWS, eller i det minste en del av det, så vil AWS Lambda-tjenesten være den viktigste delen av det.
Det er en serverløs databehandlingsfunksjon (vanligvis skrevet i Node.JS eller Python programmeringsspråk) som du kan utvikle og kjøre uten å starte opp noen backend-klynger eller servere. Du kan koble til flere AWS Lambda-funksjoner for å danne mer komplekse prosesser.
En viktig egenskap ved Lambda-funksjonen er imidlertid dens begrensning når det gjelder behandlingstidsvarighet. Dette definerer til syvende og sist når det er riktig formål å bruke AWS Lambda-funksjonen.
Kilde: aws.amazon.com
Innholdsfortegnelse
Hva er tidsavbruddsintervallet?
Tidsavbruddsfunksjonen til AWS Lambda-funksjonen er en innstilling som definerer den maksimale tiden som en funksjon kan kjøre før den avsluttes.
Lambdafunksjoner er designet for å være kortvarige og statsløse, og det er slik de skal brukes. Det er ikke et sjeldent unntak å se hvordan team prøver å bruke Lambda-funksjonen for langvarige prosesser. De gjør det bare fordi de ønsker å utnytte fordelene med den serverløse naturen til AWS Lambda. Det er alltid mye billigere å kjøre en kode uten at det er nødvendig å starte opp en server med en bestemt CPU og minnekonfigurasjon. Så intensjonen er lett å forstå.
Men hvis en funksjon kjører for lenge, kan det føre til ressursutnyttelse og ytelsesproblemer. Du risikerer at ressursene låses, og siden du har fordelen av en langvarig prosess, bryr du deg mest sannsynlig ikke om optimalisering av trinnene inne i prosessene. Plutselig er en ventetid på fem minutter ikke noe særlig problem. Du har råd til å la den være til stede selv om den, for selve prosessen, kan være ubrukelig.
Som standard er tidsavbruddet for en Lambda-funksjon satt til bare 3 sekunder. I så fall må du regne med at koden du kjører i en Lambda-funksjon må fullføres innen tre sekunder. Dette er flott hvis du vil bygge en arkitektur med veldig rask kommunikasjon og responstider, potensielt med millioner av transaksjoner på veldig kort tid. Men det ville begrense brukbare tilfeller av Lambda-funksjon ganske betydelig, så du kan øke denne grensen opp til maksimalt 900 sekunder (15 minutter). Når denne tidsavbruddet er nådd, vil Lambda avslutte funksjonen og returnere en feilkode.
Hvordan sette opp tidsavbruddsfunksjonen?
Kilde: aws.amazon.com
Du kan angi tidsavbrudd for en Lambda-funksjon ved å bruke AWS Management Console, AWS CLI eller AWS SDK-ene.
Her er de konkrete trinnene for hvordan du oppnår dette:
Du kan også bruke AWS CLI-kommandolinjen til å oppdatere tidsavbruddet for en Lambda-funksjon. Her er en eksempelkommando:
<code>aws lambda update-function-configuration --function-name [My_Lambda_Function_Name] --timeout 900
Denne kommandoen setter tidsavbruddet for [My_Lambda_Function_Name] til 15 minutter. Bare legg inn det virkelige navnet på funksjonen og ønsket tidsavbruddsverdi i sekunder.
Noen betraktninger
Tidsavbruddsinnstillingen gjelder for hele funksjonen, ikke bare individuelle kodeblokker eller operasjoner innenfor funksjonen. Så hvis funksjonen din utfører en langvarig operasjon, som å behandle en stor fil eller lage en nettverksforespørsel, må du sørge for at tidsavbruddet fortsatt er nok til at operasjonen kan fullføres, selv i verste fall .
Det er verdt å merke seg at Lambda-funksjonene er designet for å være kortvarige og statsløse. De er ment å utføre små, diskrete oppgaver. Hvis du opplever at Lambda-funksjonen din tar lang tid å fullføre, kan det være greit å vurdere å dele den opp i flere mindre funksjoner. Du kan deretter ringe dem én etter én ved hjelp av en utløser. For eksempel hvis utgangen fra forrige Lambda-funksjon er lagret på en spesifikk S3-bøtte.
I tillegg, hvis du trenger å kjøre en langvarig prosess som overskrider 15-minutters grensen, kan du vurdere å bruke AWS Step Functions for å orkestrere en serie Lambda-funksjoner eller andre AWS-tjenester for å oppnå ønsket resultat.
Beste praksis
Arbeidsintervallet til selve timeouten ser ikke ut til å være stort nok for noen omfattende samtaler. Mesteparten av tiden ender utviklere opp med å sette den opp direkte til 15 minutter for alle Lambda-funksjoner. Selv om funksjonen vil ende opp mye tidligere, er det ingen negativ bivirkning av det.
Likevel er det fortsatt noen beste fremgangsmåter å merke seg.
#1. Definer passende verdi
Du bør angi timeout-verdien basert på forventet utførelsestid for funksjonen. Dette betyr i utgangspunktet å sette en verdi som ikke er for kort, men heller ikke unødvendig lang.
Det kan være lurt å sørge for at den totale tiden for en enkelt Lambda-funksjon ikke er mer enn tre minutter, for eksempel bare på grunn av arkitektoniske eller generelle ytelsesårsaker til applikasjonen din.
På samme måte vil du kanskje sørge for at Lambda-funksjonen ikke avsluttes tidligere enn, la oss si, tre minutter. En av grunnene kan være at du vil fylle ut et antall forsøk i Lambda-koden. For eksempel i tilfelle noen av ressursene som trengs for å fullføre koden er opptatt eller låst.
Så før du setter opp tidsavbruddet til 15 minutter, bør du tenke litt over hva som kan være den optimale verdien av utførelsestid. Å definere mer presise verdier er bare et annet verktøy for å gi noen grenser til hele utviklingsteamet.
#2. Overvåking over tid
Når du har angitt tidsavbruddsgrensene, gjør en innsats for å overvåke utføringstiden til dine Lambda-funksjoner. Dette vil gi deg viktig innsikt om hvorvidt den opprinnelige avgjørelsen var riktig eller trenger noen justeringer.
Du kan bruke CloudWatch-beregninger og logger for å spore utførelsestiden for funksjonene. Identifiser deretter de som tar lengre tid enn forventet, samt de som er mye raskere å fullføre enn forventet.
#3. Asynkron påkalling
Hvis Lambda-funksjonen din utløses av en hendelse som ikke krever en umiddelbar respons, for eksempel en filopplasting eller en melding fra en kø, bruk asynkron påkalling for å redusere risikoen for tidsavbrudd. Dette vil få funksjonen til å kjøre i bakgrunnen uten å vente på svar. Dette kan selvfølgelig føre til redusert antall timeouts. Dette er ganske enkelt fordi du ikke trenger å inkludere ventetiden som funksjonen trenger for den ressursen i den totale utførelsestiden til Lambdaen.
#4. Bruk trinnfunksjoner for komplekse prosesser
Hvis du trenger å kjøre en langvarig prosess som overskrider grensen på 15 minutter, kan du bruke AWS Step Functions til å orkestrere en serie Lambda-funksjoner eller andre AWS-tjenester for å oppnå dette resultatet. Step Function vil dele opp prosessen i mindre, mer håndterbare oppgaver som du kan utføre innenfor tidsavbruddsgrensen.
Du kan til og med kjøre flere lambdafunksjoner parallelt innenfor en trinnfunksjon. La deretter trinnfunksjonen vente på alle parallelle lambdafunksjoner før du fortsetter. Dette er en form for horisontal skalering hvor flere lambdafunksjoner kan dele ett problem og løse det delvis sammen.
Til slutt trenger du bare å samle inn delresultatene og bygge opp den endelige oppløsningen, som en etter den frittstående lambda-funksjonen kan være tilstrekkelig.
#5. Optimaliser koden
Du kan optimalisere Lambda-funksjonskoden for å redusere utførelsestiden og forbedre ytelsen. Dette er nyttig hvis tidsavbruddsintervallet ikke er tilstrekkelig bare av og til. I så fall kan det være verdt å søke etter kodeoptimalisering for å fjerne slike feiltilfeller.
Hvordan påvirker tidsavbrudd fakturering?
Kilde: aws.amazon.com
Tidsavbruddsinnstillingen for en AWS Lambda-funksjon påvirker ikke faktureringen for funksjonen direkte. AWS Lambda fakturerer basert på antall forespørsler og varigheten av funksjonens utførelsestid.
Hvis du øker timeout-innstillingen for en Lambda-funksjon, kan det føre til lengre utførelsestider. Men bare hvis funksjonen virkelig trenger den ekstra tiden. Hvis du kombinerer det med en høyere frekvens av en funksjon som tar lengre tid å utføre, ja, du kan forvente høyere kostnader.
Men hvis funksjonen ikke aktiveres ofte eller hvis den fullfører prosessen raskere enn tidsavbruddsverdien er nådd, kan innvirkningen på fakturering være minimal.
Dette er grunnen til at det å sette opp alle Lambda-funksjoner til en tidsavbrudd på 15 minutter som standard kanskje ikke er hovedårsaken til økningen i kostnadene for den totale behandlingen.
Imidlertid fører det absolutt til en indirekte økning i de totale kostnadene. Utviklere vil føle at de har en viss reserve å bruke, og de vil kanskje ikke optimalisere koden i en slik grad de sannsynligvis ville gjort hvis tidsavbruddene var mer restriktive, men likevel realistiske.
En annen ting er at AWS Lambda tilbyr et gratis nivå som inkluderer 1 million gratis forespørsler og 400 000 GB-sekunders beregningstid per måned. Hvis Lambda-funksjonen din faller innenfor grensene for gratis nivå, betaler du ikke for funksjonens utførelsestid uavhengig av tidsavbruddsinnstillingen.
Siste ord
AWS Lambda-funksjon er et kraftig verktøy, spesielt for serverløs prosessering i AWS-skyen. Det har sin hensikt og sine grenser som vi bør være klar over. La oss ikke prøve å bruke den til brukstilfeller som den ikke er designet for.
Den er perfekt for enkle, asynkrone og ideelt utløste handlinger som ikke krever utførelsestid lenger enn 15 minutter. Hvis du trenger noe mer komplekst, bruk AWS Step Functions for å kombinere flere Lambda-funksjoner til en enkelt orkestrert prosess. Eller gi opp billigere serverløs prosessering og bruk servere med passende konfigurasjon og datakraft for å utføre oppgaven din.
Deretter kan du sjekke ut introduksjonen til AWS Lambda for nybegynnere.