Designkaosexperiment
Ditt verksamhetskritiska program måste vara motståndskraftigt och vara redo att svara på fel. Men det är svårt att förutsäga potentiella felscenarier i molnet. Med chaos engineering kan du utföra felexperiment i en kontrollerad miljö för att identifiera problem som sannolikt kommer att uppstå under utveckling och distribution. Du injicerar avsiktligt verkliga fel och observerar hur systemet reagerar.
I den här lektionen använder vi Azure Chaos Studio. Tjänsten hjälper dig att mäta, förstå och förbättra din molnprogram- och tjänståterhämtning. Du är beredd att svara snabbt om det här felet inträffar under ogynnsamma förhållanden i produktionen.
Utföra analys av felläge
När du utformar ett kaosexperiment är det första steget att utföra fellägesanalys (FMA) av programkomponenterna för att identifiera potentiella felscenarier.
Visa en lista över alla komponenter som är relevanta för ett användarflöde som måste vara tillgängligt och funktionellt. Till exempel använder utcheckningsanvändarflödet Azure App Services, Functions och Cosmos DB-databasen.
För varje komponent anger du möjliga felfall, deras inverkan och eventuella åtgärder.
Nu ska vi se resultatet av FMA gjort för komponenterna i contoso Shoes-exemplet för utcheckning av användarflöden.
Azure App Service för att vara värd för klientdelsprogrammet
| Risk | Påverkan | Möjlig åtgärd |
|---|---|---|
| Avbrott i tillgänglighetszonen | Instanser i den zonen kan bli otillgängliga. Fullständigt avbrott förväntas inte eftersom zonredundans är aktiverat i App Service-planen. |
Tillåt extra belastning på de återstående instanserna och ge tillräckligt med utrymme för det här scenariot samtidigt som prestandamålen uppnås. |
| SNAT-portöverbelastning | Det går inte att skapa utgående anslutningar. Därför misslyckas underordnade anrop, till exempel anrop till databasen. | Använd privata slutpunkter för att ansluta till underordnade komponenter. |
| Enskilda instanser blir inte felfria | Användartrafik som dirigeras till en instans med fel kan se dåliga prestanda eller till och med misslyckas helt. | Funktionen App Tjänststatus check gör att felaktiga instanser identifieras automatiskt och ersätts med nya felfria instanser. |
Azure Functions för utcheckningslogik
| Risk | Påverkan | Möjlig åtgärd |
|---|---|---|
| Långsam (kall) startprestanda | Eftersom Azure Functions-förbrukningsplanen används har nya instanser inga prestandagarantier. Hög efterfrågan på tjänsten (från "bullriga grannar") kan orsaka att utcheckningsfunktionen upplever en lång startvaraktighet som påverkar prestandamålen. |
Uppgradera till Azure Functions Premium-planen. |
| Underliggande lagringsstopp | Om det underliggande lagringskontot blir otillgängligt slutar funktionen att fungera. | Använd belastningsutjämningsberäkning med regional lagring eller belastningsutjämning med delad GRS-lagring. |
Azure Cosmos DB-databas
| Risk | Påverkan | Möjlig åtgärd |
|---|---|---|
| Byta namn på en databas eller samling | På grund av matchningsfel i konfigurationen kan data gå förlorade. Programmet kommer inte att kunna komma åt några data förrän konfigurationen har uppdaterats och dess komponenter har startats om. | Förhindra den här situationen med hjälp av lås på databas- och samlingsnivå. |
| Avbrott i skrivregionen | Om den primära regionen (eller skrivregionen) drabbas av ett avbrott höjer Azure Cosmos DB-kontot automatiskt upp en sekundär region till den nya primära skrivregionen när automatisk (tjänsthanterad) redundansväxling konfigureras på Azure Cosmos DB-kontot. Redundansväxlingen sker i en annan region i den ordning som du har angett. | Konfigurera databaskontot med flera regioner och automatisk redundans. Om det uppstår ett fel redundansväxlar tjänsten automatiskt och förhindrar eventuella ihållande problem i programmet. |
| Omfattande begränsning på grund av brist på enheter för begäranden (RU:er) | Vissa stämplar kan köras frekvent på Azure Cosmos DB-användning medan andra fortfarande kan hantera begäranden. | Använd bättre belastningsfördelning till fler stämplar eller lägg till fler RU:er. |
Utforma ett kaosexperiment
Om du vill utforma ett kaosexperiment väljer du några felfall. Valet kan baseras på sannolikheten för att felet inträffar eller den möjliga effekten.
Målet med experimentet är att verifiera återhämtningsåtgärder som du har implementerat i ditt program. Anta till exempel att du kör ditt program på App Service med zonredundans aktiverat. Om alla underliggande instanser i en zon går ned förväntar du dig att programmet fortfarande körs.
Använd Chaos Studio för att mata in felen i relevanta komponenter. Chaos Studio erbjuder ett bibliotek med fel som du kan välja mellan. Men eftersom felbiblioteket inte täcker allt kan du behöva justera scenariot. Eller så kan du behöva hitta fler verktyg som hjälper dig att mata in felet.
Viktigt!
Rikta endast in dig på en icke-produktionsmiljö med dina experiment. Att mata in fel i produktionsmiljön kan vara riskabelt och kräver erfarenhet och planering.
Exempel: Avbrott och redundans i Azure Cosmos DB
Anta att du väljer felscenariot "skrivregionsfel" i Azure Cosmos DB som anges i tabellen. Hypotesen är: En tjänstinitierad redundans bör inte leda till någon varaktig inverkan på programmet. Om den här hypotesen visar sig vara sann har du verifierat att ditt återhämtningsmått för replikering till flera regioner har önskad positiv effekt på programmets tillförlitlighet.
Om du vill simulera det här felet använder du Azure Cosmos DB-felet från Chaos Studio-felbiblioteket.
Det här exemplet är för en Azure Cosmos DB-redundans som körs i 10 minuter (PT10M) och som använder West US 2 som den nya skrivregionen. Det förutsätter att redan West US 2 har konfigurerats som en av läsreplikeringsregionerna.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
När experimentet är slut växlar Chaos Studio tillbaka skrivregionen till sitt ursprungliga värde.
Innan du kan mata in ett fel mot en Azure-resurs måste du aktivera motsvarande mål och funktioner för den resursen. Den här inställningen styr de fel som kan köras mot de resurser som är aktiverade för felinmatning. När du använder mål och funktioner med andra säkerhetsåtgärder kan du undvika oavsiktlig eller skadlig felinmatning.
Nu när du har utformat både belastningstester och kaosexperiment måste du automatisera dem i dina pipelines så att de körs konsekvent och regelbundet. I nästa lektion får du lära dig mer om att lägga till testerna i dina CI/CD-pipelines.