Kontinuerlig validering med Azure Load Testing och Azure Chaos Studio

När molnbaserade program och tjänster blir mer komplexa kan det vara svårt att distribuera ändringar och nya versioner för dem. Avbrott orsakas ofta av felaktiga distributioner eller versioner. Men fel kan också inträffa efter distributionen, när ett program börjar ta emot verklig trafik, särskilt i komplexa arbetsbelastningar som körs i mycket distribuerade molnmiljöer med flera klienter och som underhålls av flera utvecklingsteam. Dessa miljöer kräver mer återhämtningsåtgärder, till exempel omprövningslogik och autoskalning, som vanligtvis är svåra att testa under utvecklingsprocessen.

Därför är kontinuerlig validering i en miljö som liknar produktionsmiljön viktig, så att du kan hitta och åtgärda eventuella problem eller buggar så tidigt i utvecklingscykeln som möjligt. Arbetsbelastningsteam bör testa tidigt i utvecklingsprocessen (skift till vänster) och göra det bekvämt för utvecklare att göra tester i en miljö som ligger nära produktionsmiljön.

Verksamhetskritiska arbetsbelastningar har höga tillgänglighetskrav, med mål på 3, 4 eller 5 nior (99,9 %, 99,99 % respektive 99,999 %). Det är viktigt att implementera rigorös automatiserad testning för att nå dessa mål.

Kontinuerlig validering beror på varje arbetsbelastning och på arkitekturegenskaper. Den här artikeln innehåller en guide för att förbereda och integrera Azure Load Testing och Azure Chaos Studio i en vanlig utvecklingscykel.

1 – Definiera tester baserat på förväntade tröskelvärden

Kontinuerlig testning är en komplex process som kräver korrekt förberedelse. Vad som kommer att testas och de förväntade resultaten måste vara tydliga.

I PE:06 – Rekommendationer för prestandatestning och RE:08 – Rekommendationer för att utforma en strategi för tillförlitlighetstestning rekommenderar Azure Well-Architected Framework att du börjar med att identifiera viktiga scenarier, beroenden, förväntad användning, tillgänglighet, prestanda och skalbarhetsmål.

Du bör sedan definiera en uppsättning mätbara tröskelvärden för att kvantifiera de förväntade prestandan för de viktigaste scenarierna.

Dricks

Exempel på tröskelvärden är det förväntade antalet användarinloggningar, begäranden per sekund för ett visst API och åtgärder per sekund för en bakgrundsprocess.

Du bör använda tröskelvärden för att utveckla en hälsomodell för ditt program, både för testning och drift av programmet i produktion.

Använd sedan värdena för att definiera ett belastningstest som genererar realistisk trafik för testning av programmets baslinjeprestanda, validering av förväntade skalningsåtgärder och så vidare. Ihållande artificiell användartrafik behövs i förproduktionsmiljöer, eftersom det är svårt att avslöja körningsproblem utan användning.

Belastningstestning säkerställer att ändringar som görs i programmet eller infrastrukturen inte orsakar problem och att systemet fortfarande uppfyller de förväntade prestanda- och testkriterierna. En misslyckad testkörning som inte uppfyller testvillkoren anger att du behöver justera baslinjen eller att ett oväntat fel inträffade.

Även om automatiserade tester representerar daglig användning bör du köra manuella belastningstester regelbundet för att kontrollera hur systemet svarar på oväntade toppar.

Den andra delen av kontinuerlig validering är inmatning av fel (kaosteknik). Det här steget verifierar systemets återhämtning genom att testa hur det svarar på fel. Dessutom fungerar alla återhämtningsåtgärder, till exempel omprövningslogik, autoskalning och andra, som förväntat.

2 – Implementera validering med belastningstestning och Chaos Studio

Microsoft Azure tillhandahåller dessa hanterade tjänster för att implementera belastningstestning och kaosteknik:

• Azure Load Testing genererar syntetisk användarbelastning för program och tjänster.
• Azure Chaos Studio ger möjlighet att utföra kaosexperiment genom att systematiskt mata in fel i programkomponenter och infrastruktur.

Du kan distribuera och konfigurera både Chaos Studio och Load Testing via Azure-portalen, men i samband med kontinuerlig validering är det viktigare att du har API:er för att distribuera, konfigurera och köra tester på ett programmatiskt och automatiserat sätt. Genom att använda dessa två verktyg tillsammans kan du se hur systemet reagerar på problem och dess förmåga att läka sig själv som svar på infrastruktur- eller programfel.

Följande video visar en kombinerad implementering av Chaos and Load Testing integrerat i Azure DevOps:

Om du utvecklar en verksamhetskritisk arbetsbelastning kan du dra nytta av referensarkitekturer, detaljerad vägledning, exempelimplementeringar och kodartefakter som tillhandahålls som en del av Azure Mission-Critical-projektet och Azure Well-Architected Framework.

Den verksamhetskritiska implementeringen distribuerar tjänsten För belastningstestning via Terraform och innehåller en samling PowerShell Core-omslutningsskript för att interagera med tjänsten via dess API. Dessa skript kan bäddas in direkt i en distributionspipeline.

Ett alternativ i referensimplementeringen är att köra belastningstestet direkt från den slutpunkt till slutpunkt -pipeline (e2e) som används för att starta enskilda (grenspecifika) utvecklingsmiljöer:

Pipelinen kör automatiskt ett belastningstest, med eller utan kaosexperiment (beroende på val) parallellt:

Kommentar

Att köra kaosexperiment under ett belastningstest kan resultera i högre svarstider, högre svarstider och tillfälligt ökade felfrekvenser. Du ser högre tal tills en utskalningsåtgärd har slutförts eller en redundansväxling har slutförts, jämfört med en körning utan kaosexperiment.

Beroende på om kaostestning är aktiverat och val av experiment kan baslinjedefinitionerna variera, eftersom toleransen för fel kan vara olika i "normalt" tillstånd och "kaos"-tillstånd.

3 – Justera tröskelvärden och upprätta en baslinje

Justera slutligen tröskelvärdena för belastningstest för vanliga körningar för att kontrollera att programmet (fortfarande) ger den förväntade prestandan och inte ger några fel. Ha en separat baslinje för kaostestning som tolererar förväntade toppar i felfrekvenser och tillfälligt nedsatt prestanda. Den här aktiviteten är kontinuerlig och måste upprepas regelbundet. Till exempel när du har introducerat nya funktioner, ändrat tjänst-SKU:er och andra.

Azure Load Testing-tjänsten har en inbyggd funktion som kallas testvillkor som gör det möjligt att ange vissa kriterier som ett test måste klara. Den här funktionen kan användas för att implementera olika baslinjer.

Funktionen är tillgänglig via Azure-portalen och via API:et för belastningstestning, och de omslutningsskript som utvecklats som en del av Azure Mission-critical ger ett alternativ för att överlämna en JSON-baserad baslinjedefinition.

Vi rekommenderar starkt att du integrerar dessa tester direkt i dina CI/CD-pipelines och kör dem under de tidiga stegen i funktionsutvecklingen. Ett exempel finns i exempelimplementeringen i den Azure Mission-kritiska referensimplementeringen.

Sammanfattningsvis är fel oundvikligt i alla komplexa distribuerade system och lösningen måste därför utformas (och testas) för att hantera fel. Vägledning och referensimplementeringar för verksamhetskritiska arbetsbelastningar i Well-Architected Framework kan hjälpa dig att utforma och använda mycket tillförlitliga program för att härleda maximalt värde från Microsoft-molnet.

Gå vidare

Granska designområdet för distribution och testning för verksamhetskritiska arbetsbelastningar.

Designområde: Distribution och testning

Relaterade resurser

• Dokumentation om Azure Load Testing
• Dokumentation om Azure Chaos Studio