Káoszkísérletek tervezése
A kritikus fontosságú alkalmazásnak rugalmasnak kell lennie, és készen kell állnia a hibákra való reagálásra. A felhőben azonban nehéz előrejelezni a lehetséges meghibásodási forgatókönyveket. A chaos engineering lehetővé teszi, hogy hibakísérleteket végezzen ellenőrzött környezetben, hogy azonosítsa a fejlesztés és üzembe helyezés során valószínűleg felmerülő problémákat. Szándékosan injektálja a valós hibákat, és megfigyeli, hogyan reagál a rendszer.
Ebben a leckében az Azure Chaos Studiót fogjuk használni. A szolgáltatás segít a felhőalkalmazások és szolgáltatások rugalmasságának mérésében, megértésében és javításában. Készen áll arra, hogy gyorsan válaszoljon, ha ez a hiba éles környezetben kedvezőtlen körülmények között fordul elő.
Hibamód elemzése
Káoszkísérlet tervezésekor az első lépés az alkalmazás-összetevők hibamód-elemzése (FMA) végrehajtása a lehetséges hibaforgatókönyvek azonosítása érdekében.
Listázhatja a felhasználói folyamat szempontjából releváns összes összetevőt, amelyeknek elérhetőnek és működőképesnek kell lenniük. A kivétel felhasználói folyamata például Azure-alkalmazás Services, Functions és Cosmos DB-adatbázist használ.
Minden egyes összetevő esetében sorolja fel a lehetséges meghibásodási eseteket, azok hatását és az esetleges kockázatcsökkentéseket.
Lássuk az FMA eredményét, amely a Contoso Shoes-pénztár felhasználói folyamat példájának összetevőihez készült.
Azure-alkalmazás szolgáltatás az előtérbeli alkalmazás üzemeltetéséhez
| Kockázat | Hatás | Lehetséges kockázatcsökkentés |
|---|---|---|
| Rendelkezésre állási zóna kimaradása | Előfordulhat, hogy az adott zónában lévő példányok elérhetetlenné válnak. A teljes üzemkimaradás nem várható, mert a zónaredundancia engedélyezve van az App Service-csomagban. | Engedélyezze a további terhelést a fennmaradó példányokra, és elegendő fejteret biztosítson ehhez a forgatókönyvhöz, miközben továbbra is eléri a teljesítménycélokat. |
| SNAT-portok kimerülése | Kimenő kapcsolatok nem hozhatók létre. Ennek eredményeképpen az alsóbb rétegbeli hívások, például az adatbázis hívásai meghiúsulnak. | Privát végpontok használata az alsóbb rétegbeli összetevőkhöz való csatlakozáshoz. |
| Az egyes példányok állapota nem megfelelő | A nem megfelelő példányra irányított felhasználói forgalom gyenge teljesítményt vagy akár teljes meghiúsulásokat is tapasztalhat. | Az alkalmazás Szolgáltatásállapot ellenőrzési funkció automatikusan azonosítja és lecseréli a nem kifogástalan állapotú példányokat. |
Azure Functions a kifizetési logikához
| Kockázat | Hatás | Lehetséges kockázatcsökkentés |
|---|---|---|
| Lassú (hideg) indítási teljesítmény | Mivel az Azure Functions Consumption-csomag használatban van, az új példányok nem rendelkeznek teljesítménygaranciával. A szolgáltatás iránti nagy igény (a "zajos szomszédoktól") miatt a kivételi függvény hosszú indítási időtartamot tapasztalhat, amely hatással van a teljesítménycélokra. | Frissítsen az Azure Functions Premium-csomagra. |
| Mögöttes tárterület-kimaradás | Ha a mögöttes tárfiók elérhetetlenné válik, a függvény leáll. | Használjon elosztott terhelésű számítást regionális tárolóval , vagy terheléselosztásos számítást GRS megosztott tárhellyel. |
Azure Cosmos DB-adatbázis
| Kockázat | Hatás | Lehetséges kockázatcsökkentés |
|---|---|---|
| Adatbázis vagy gyűjtemény átnevezése | A konfiguráció eltérése miatt adatvesztés történhet. Az alkalmazás nem fog tudni hozzáférni semmilyen adathoz, amíg a konfiguráció nem frissül, és az összetevők újraindulnak. | Ezt a helyzetet adatbázis- és gyűjteményszintű zárolásokkal akadályozhatja meg. |
| Régióleállás írása | Ha az elsődleges régió (vagy írási régió) kimaradásba ütközik, az Azure Cosmos DB-fiók automatikusan előléptet egy másodlagos régiót az új elsődleges írási régióként, amikor az automatikus (szolgáltatás által felügyelt) feladatátvétel az Azure Cosmos DB-fiókon van konfigurálva. A feladatátvétel egy másik régióba történik a megadott régió prioritásának sorrendjében. | Konfigurálja az adatbázisfiókot több régióval és automatikus feladatátvétellel. Ha hiba történik, a szolgáltatás automatikusan feladatátvételt fog végrehajtani, és megakadályozza az alkalmazás esetleges tartós problémáit. |
| A kérelemegységek (kérelemegységek) hiánya miatti széles körű szabályozás | Egyes bélyegek gyakran futnak az Azure Cosmos DB kihasználtságán, míg mások továbbra is kiszolgálhatják a kéréseket. | Használjon jobb terheléselosztást több bélyeghez, vagy adjon hozzá több kérelemegységet. |
Káoszkísérlet tervezése
Egy káoszkísérlet megtervezéséhez válasszon néhány hibaesetet. A választás a hiba bekövetkezésének valószínűségén vagy a lehetséges hatáson alapulhat.
A kísérlet célja az alkalmazásban implementált rugalmassági mértékek ellenőrzése. Tegyük fel például, hogy az alkalmazást az App Service-ben futtatja, és engedélyezve van a zónaredundancia. Ha egy zóna összes mögöttes példánya leáll, az alkalmazás továbbra is fut.
A Chaos Studio használatával szúrja be a hibákat a megfelelő összetevőkbe. A Chaos Studio a hibák tárát kínálja, amely közül választhat. Mivel azonban a hibatár nem fed le mindent, előfordulhat, hogy módosítania kell a forgatókönyvet. Vagy előfordulhat, hogy további eszközöket kell találnia a hiba beadásához.
Fontos
Csak egy nem éles környezetet céloz meg a kísérletekkel. A hibák éles környezetbe történő injektálása kockázatos lehet, és tapasztalatot és tervezést igényel.
Példa: Azure Cosmos DB leállása és feladatátvétel
Tegyük fel, hogy a táblázatban felsorolt Azure Cosmos DB "írási régiókimaradás" hibaforgatókönyvét választja. A hipotézis a következő: A szolgáltatás által kezdeményezett feladatátvétel nem okozhat tartós hatást az alkalmazásra. Ha ez a hipotézis igaznak bizonyul, ellenőrizte, hogy a több régióba történő replikálás rugalmassági mértéke pozitív hatással van-e az alkalmazás megbízhatóságára.
A hiba szimulálásához használja a Chaos Studio hibatárából származó Azure Cosmos DB-hibát .
Ez a példa egy 10 percig (PT10M) futó És az új írási régióként használt Azure Cosmos DB-feladatátvételre mutat West US 2 . Feltételezi, hogy az West US 2 olvasási replikációs régiók egyikeként már be van állítva.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
A kísérlet befejezése után a Chaos Studio visszaállítja az írási régiót az eredeti értékére.
Mielőtt hibát szúrhat be egy Azure-erőforrásba, engedélyeznie kell az adott erőforráshoz tartozó célokat és képességeket . Ez a beállítás szabályozza azokat a hibákat, amelyek a hibainjektáláshoz engedélyezett erőforrásokon futtathatók. Ha más biztonsági intézkedésekkel célokat és képességeket használ, elkerülheti a véletlen vagy rosszindulatú hibainjektálást.
Most, hogy mind a terhelési teszteket, mind a káoszkísérleteket megtervezte, automatizálnia kell őket a folyamatokban, hogy azok folyamatosan és rendszeresen fussanak. A következő leckében megismerheti a CI/CD-folyamatok tesztjeinek hozzáadását.