Å lage moderne applikasjoner ved hjelp av serverløs teknologi og administrerte tjenester betyr at hvem som helst kan bygge distribuerte og svært tilgjengelige systemer uten å måtte bekymre seg for den underliggende infrastrukturen. Men det er ikke bare lek og moro. Dette foredraget jeg holdt på AWS re:Invent 2019 med tittelen «Performing chaos engineering in a serverless world» forklarer noen av utfordringene med serverless, vanlige svakheter i serverless-applikasjoner samt utfordringer ved bruk av kaos-engineering i serverless. Vennligst se videoen.
Injiser feil i funksjonene våre
AWS Serverless Hero Yan Cui har skrevet flere artikler om latency injection for AWS Lambda, se «How can we apply the principles of chaos engineering to AWS Lambda?» () og «Applying principles of chaos engineering to AWS Lambda with latency injection» () fra oktober 2017. (https://theburningmonk.com/2017/10/how-can-we-apply-the-principles-of-chaos-engineering-to-aws-lambda/) og «Applying principles of chaos engineering to AWS Lambda with latency injection» (https://hackernoon.com/chaos-engineering-and-aws-lambda-latency-injection-ddeb4ff8d983) fra oktober 2017. Disse artiklene forklarer hvorfor vi kan og bør bruke kaosteknikk i serverløse applikasjoner, og viser eksempler på hvordan vi kan gjøre det.
Adrian Hornsby, Principal Developer Advocate Architecture hos AWS, utvidet dette ved først å lage et Lambda-lag og senere et Python-bibliotek for feilinjeksjon, chaos_lambda (https://github.com/adhorn/aws-lambda-chaos-injection), som gir utviklere en enklere måte å komme i gang med kaoseksperimenter for AWS Lambda på. Bare installer biblioteket, pakk inn funksjonene dine med riktig feilmodus, og du er klar til å begynne å injisere feil!
For å oppnå samme nivå av enkelhet for NodeJS-utviklere opprettet jeg sent i fjor en NPM-pakke kalt failure-lambda (https://github.com/gunnargrosch/failure-lambda). Målet med failure-lambda er kort sagt å ha en enkel måte å gjøre feilinjeksjon i AWS Lambda ved hjelp av flere forskjellige feilmodi. For å gjøre det enda enklere bestemte jeg meg for å bruke en enkelt wrapper og i stedet la feilmodusen være valgbar. På den måten trenger du ikke å gjøre endringer i koden hvis du vil bytte mellom for eksempel latency eller unntaksinjeksjon, du endrer bare en innstilling.
Som vi vet, handler serverless ikke bare om AWS, og kaosutvikling for serverless handler ikke bare om AWS Lambda. Derfor finnes det nå også de samme alternativene for feilinjeksjon for NodeJS-utviklere som bygger serverløst ved hjelp av Azure Functions og Cloud Functions. Dette med NPM-pakkene failure-azurefunctions (https://github.com/gunnargrosch/failure-azurefunctions) og failure-cloudfunctions (https://github.com/gunnargrosch/failure-cloudfunctions).
Feilmodi og feilfrekvens
Selv om alt dette startet med latency-injeksjon som i Yan Cuis artikler, er latency langt fra den eneste mulige feilen vi kan ha i serverløse applikasjoner. I failure-lambda, failure-azurefunctions og failure-cloudfunctions er det nå fem ulike feilmodi å velge mellom:
Latency – Tilfører latenstid til den utførte funksjonen, kontrollert ved hjelp av et minimums- og maksimumsspenn på millisekunder. Dette kan for eksempel brukes til å simulere ventetid i tjenesten eller til å teste og angi tidsavbruddsverdier.
Exception – Kaster et unntak i funksjonen. Hjelper deg med å teste hvordan applikasjonen og koden din håndterer unntak.
Statuskode – Funksjonen din returnerer en valgfri statuskode, for eksempel 502 eller 404 i stedet for den vanlige 200. Dette gir deg muligheten til å teste hva som skjer når det oppstår feil.
Diskplass – Fyller den midlertidige disken med filer for å skape en feil. Hvis du bruker en disk til å lagre midlertidige filer, kan du teste hvordan programmet ditt oppfører seg hvis disken blir full eller du ikke kan lagre på den.
Blacklist (med tillatelse fra Jason Barto) – Blokkerer tilkoblinger til bestemte verter. Brukes til å simulere at tjenester eller tredjeparter ikke er tilgjengelige.
Alle disse feilmodusene kan brukes sammen med en feilfrekvens som du angir. Standardinnstillingen er å injisere feil ved hvert anrop, men i virkeligheten er det sannsynlig at for eksempel en tredjepart ikke er tilgjengelig ved 50 % av anropene til den aktuelle verten, eller at et unntak kastes ved en fjerdedel av anropene. Ved å sette hastigheten kan du oppnå dette.