maj 5, 2025|4:18 e m
Whether it’s IT operations, cloud migration, or AI-driven innovation – let’s explore how we can support your success.
Att skapa moderna applikationer med hjälp av serverlös teknik och managed services innebär att vem som helst kan bygga distribuerade system med hög tillgänglighet utan att behöva oroa sig för den underliggande infrastrukturen. Men allt är inte bara roligt och lekfullt. Detta föredrag som jag höll på AWS re:Invent 2019 med titeln “Performing chaos engineering in a serverless world” förklarar några av utmaningarna med serverless, vanliga svagheter i serverlösa applikationer samt utmaningar med att använda kaosteknik i serverless. Vänligen se videon.
AWS Serverless Hero Yan Cui har skrivit flera artiklar om latensinjektion för AWS Lambda, se “Hur kan vi tillämpa principerna för kaosteknik på AWS Lambda?” (https://theburningmonk.com/2017/10/how-can-we-apply-the-principles-of-chaos-engineering-to-aws-lambda/) och “Tillämpning av principer för kaosteknik till AWS Lambda med latensinjektion” (https://hackernoon.com/chaos-engineering-and-aws-lambda-latency-injection-ddeb4ff8d983) från oktober 2017. Dessa artiklar förklarar varför vi kan och bör använda kaosteknik i våra serverlösa applikationer samt visar exempel på hur man gör det.
AWS Principal Developer Advocate Architecture Adrian Hornsby byggde vidare på detta genom att först skapa ett Lambda-lager och senare ett Python-bibliotek för felinjektion, chaos_lambda (https://github.com/adhorn/aws-lambda-chaos-injection), vilket ger utvecklare ett enklare sätt att komma igång med kaosexperiment för AWS Lambda. Installera bara biblioteket, linda in dina funktioner med lämpligt felläge och du är redo att börja injicera fel!
För att nå samma nivå av enkelhet för NodeJS-utvecklare skapade jag i slutet av förra året ett NPM-paket som heter failure-lambda (https://github.com/gunnargrosch/failure-lambda). Målet med failure-lambda är i korthet att ha ett enkelt sätt att göra failure injection i AWS Lambda med hjälp av flera olika failure modes. För att göra det ännu enklare bestämde jag mig för att använda en enda wrapper och i stället låta felmodet vara valbart. På så sätt behöver du inte göra kodändringar om du vill växla mellan till exempel latens eller exception injection, du ändrar bara en inställning.
Som vi vet handlar serverlös inte bara om AWS och kaosteknik för serverlös handlar inte bara om AWS Lambda. Av den anledningen finns det nu också samma alternativ för felinjektion för NodeJS-utvecklare som bygger serverlöst med Azure Functions och Cloud Functions. Detta med NPM-paketen failure-azurefunctions (https://github.com/gunnargrosch/failure-azurefunctions) och failure-cloudfunctions (https://github.com/gunnargrosch/failure-cloudfunctions).
Även om allt började med latensinjektion som i Yan Cuis artiklar, är latens långt ifrån det enda möjliga felet vi kan ha i våra serverlösa applikationer. I “failure-lambda”, “failure-azurefunctions” och “failure-cloudfunctions” finns det nu fem olika “failure modes” att välja mellan:
Latency – Tillför den exekverade funktionen en latenstid som styrs med hjälp av ett minimi- och maximiintervall på millisekunder. Detta kan t.ex. användas för att simulera tjänstens latens eller för att testa och hjälpa till att ställa in dina timeout-värden.
Exception – Kastar ett undantag i funktionen. Hjälper dig att testa hur din applikation och kod hanterar undantag.
Statuskod – Din funktion returnerar en valfri statuskod, t.ex. 502 eller 404 i stället för den normala 200. Detta ger dig möjlighet att testa vad som händer när det uppstår fel.
Diskutrymme – Fyller din temporära disk med filer för att skapa ett fel. Om du använder en disk för att lagra temporära filer kan du testa hur programmet beter sig om disken blir full eller om du inte kan lagra på den.
Blacklist (med tillstånd av Jason Barto) – Blockerar anslutningar till angivna värdar. Används för att simulera att tjänster eller tredje part inte är tillgängliga.
Alla dessa felsökningslägen kan användas tillsammans med en felfrekvens som du ställer in. Standardinställningen är att fel uppstår vid varje anrop, men i verkligheten är det troligt att t.ex. en tredje part inte är tillgänglig vid 50 % av anropen till den värden eller att ett undantag inträffar vid en fjärdedel av anropen. Genom att sätta kursen kan du uppnå detta.
