Návrh experimentů chaosu
Vaše nepostradatelná aplikace musí být odolná a připravená reagovat na selhání. Je ale obtížné předpovědět potenciální scénáře selhání v cloudu. Chaos engineering umožňuje provádět experimenty selhání v řízeném prostředí k identifikaci problémů, které mohou vzniknout během vývoje a nasazení. Záměrně vložíte skutečné chyby a zjistíte, jak systém reaguje.
V této lekci použijete Azure Chaos Studio. Tato služba vám pomůže měřit, pochopit a zlepšit odolnost cloudových aplikací a služeb. Připraví vás, abyste rychle reagovali, pokud dojde k selhání za nepříznivých podmínek v produkčním prostředí.
Analýza režimu selhání
Při návrhu experimentu chaosu je prvním aktem provedení analýzy režimu selhání (FMA) komponent aplikace za účelem identifikace potenciálních scénářů selhání:
Uveďte všechny komponenty, které jsou relevantní pro tok uživatele, který musí být dostupný a funkční. Tok uživatele rezervace například používá služby Aplikace Azure Services, Azure Functions a databázi Azure Cosmos DB.
Pro každou komponentu uveďte možné případy selhání, jejich dopad a případné zmírnění rizik.
Pojďme se podívat na výsledek FMA provedený pro komponenty ukázky toku uživatelů rezervace Contoso Shoes.
Aplikace Azure Service pro hostování front-endové aplikace
| Riziko | Dopad | Možné zmírnění rizik |
|---|---|---|
| Výpadek zóny dostupnosti | Instance v této zóně můžou být nedostupné. Úplný výpadek se neočekává, protože v plánu služby App Service je povolená redundance zón. |
Povolte dodatečné zatížení zbývajících instancí a poskytněte pro tento scénář dostatečný prostor pro dosažení cílů výkonu. |
| Vyčerpání portů SNAT | Odchozí připojení se nedají vytvořit. V důsledku toho podřízená volání, jako jsou volání databáze, selžou. | Pro připojení k podřízeným komponentám použijte privátní koncové body. |
| Jednotlivé instance nejsou v pořádku | Uživatelský provoz směrovaný do instance, která není v pořádku, může vidět nízký výkon nebo dokonce úplně selhat. | Použijte funkci kontrola Stav služby aplikace. Tato funkce způsobí, že instance, které nejsou v pořádku, se automaticky identifikují a nahradí novými instancemi, které jsou v pořádku. |
Logika rezervace ve službě Azure Functions
| Riziko | Dopad | Možné zmírnění rizik |
|---|---|---|
| Nízký (studený) výkon spuštění | Vzhledem k tomu, že se používá plán Consumption služby Azure Functions, nové instance nemají záruky výkonu. Vysoká poptávka po službě (od "hlučných sousedů") může způsobit, že funkce rezervace zaznamená dlouhou dobu spouštění, která ovlivňuje cíle výkonu. |
Upgradujte na plán Azure Functions Premium. |
| Základní výpadek úložiště | Pokud se základní účet úložiště stane nedostupným, funkce přestane fungovat. | Použijte výpočetní prostředky s vyrovnáváním zatížení s regionálním úložištěm nebo výpočetními prostředky s vyrovnáváním zatížení se sdíleným úložištěm GRS. |
Databáze Azure Cosmos DB
| Riziko | Dopad | Možné zmírnění rizik |
|---|---|---|
| Přejmenování databáze nebo kolekce | Kvůli neshodě v konfiguraci může dojít ke ztrátě dat. Aplikace nemá přístup k žádným datům, dokud se konfigurace neaktualizuje a jeho součásti se restartují. | Zabráníte této situaci pomocí zámků na úrovni databáze a kolekce. |
| Výpadek oblasti zápisu | Pokud dojde k výpadku primární oblasti (nebo oblasti zápisu), účet Služby Azure Cosmos DB při konfiguraci automatického převzetí služeb při selhání služby Azure Cosmos DB automaticky zvýší sekundární oblast zápisu na novou primární oblast zápisu. Převzetí služeb při selhání nastane v jiné oblasti v pořadí podle priority oblasti, kterou jste zadali. | Nakonfigurujte účet databáze tak, aby používal více oblastí a automatické převzetí služeb při selhání. Pokud dojde k selhání, služba automaticky převezme služby služby při selhání a zabrání jakýmkoli trvalým problémům v aplikaci. |
| Rozsáhlé omezování kvůli nedostatku jednotek žádostí (RU) | Některá razítka můžou běžet horká na využití služby Azure Cosmos DB, zatímco ostatní můžou i nadále obsluhovat požadavky. | Používejte lepší distribuci zatížení na více razítek nebo přidejte další jednotky RU. |
Návrh experimentu chaosu
Pokud chcete navrhnout experiment chaosu, vyberte několik případů selhání. Volba může být založená na pravděpodobnosti, že k selhání dojde nebo na možném dopadu.
Cílem experimentu je ověřit míry odolnosti, které jste implementovali ve své aplikaci. Předpokládejme například, že aplikaci spustíte ve službě App Service a povolíte redundanci zón. Pokud všechny základní instance v zóně poklesnou, očekáváte, že vaše aplikace bude stále spuštěná.
Pomocí nástroje Chaos Studio vložte chyby do příslušných komponent. Chaos Studio nabízí knihovnu chyb , ze které si můžete vybrat. Protože ale knihovna chyb nepokrývá všechno, možná budete muset svůj scénář upravit. Nebo možná budete muset najít další nástroje, které vám pomůžou s vložením chyby.
Důležité
Cílení pouze na neprodukční prostředí během experimentů. Vkládání chyb do produkčního prostředí může být rizikové a vyžaduje zkušenosti a plánování.
Příklad: Výpadek služby Azure Cosmos DB a převzetí služeb při selhání
Předpokládejme, že vyberete scénář selhání selhání oblasti zápisu služby Azure Cosmos DB uvedený v tabulce. Hypotéza je: Převzetí služeb při selhání iniciované službou by nemělo mít žádný trvalý dopad na aplikaci. Pokud se tato hypotéza prokáže jako pravdivá, ověřili jste, že míra odolnosti replikace do více oblastí má požadovaný pozitivní vliv na spolehlivost aplikace.
K simulaci této chyby použijte selhání služby Azure Cosmos DB z knihovny chyb Chaos Studio.
Tento příklad je určený pro převzetí služeb při selhání služby Azure Cosmos DB, které běží 10 minut (PT10M) a používá West US 2 se jako nová oblast zápisu. Předpokládá se, že West US 2 už je nastavená jako jedna z oblastí replikace čtení.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
Po skončení experimentu chaos Studio přepne oblast zápisu zpět na původní hodnotu.
Než budete moct vkládat chybu proti prostředku Azure, musíte pro tento prostředek povolit odpovídající cíle a nastavení možností . Toto nastavení řídí chyby, které můžou běžet proti prostředkům povoleným pro injektáž chyb. Pokud používáte cíle a možnosti společně s dalšími bezpečnostními opatřeními, můžete se vyhnout náhodnému nebo škodlivému injektáži chyb.
Teď, když jste navrhli zátěžové testy i experimenty chaosu, musíte je automatizovat do svých kanálů, aby běžely konzistentně a pravidelně. V další lekci se dozvíte o přidání testů kanálů CI/CD.