Folyamatos ellenőrzés az Azure Load Testing és az Azure Chaos Studio használatával

Mivel a natív felhőbeli alkalmazások és szolgáltatások egyre összetettebbé válnak, a módosítások és az új kiadások üzembe helyezése kihívást jelenthet számukra. A kimaradásokat gyakran hibás üzemelő példányok vagy kiadások okozzák. A hibák azonban az üzembe helyezés után is előfordulhatnak, amikor egy alkalmazás valós forgalmat kezd fogadni, különösen olyan összetett számítási feladatok esetében, amelyek nagy mértékben elosztott több-bérlős felhőkörnyezetekben futnak, és amelyeket több fejlesztői csapat tart fenn. Ezek a környezetek több rugalmassági intézkedést igényelnek, például újrapróbálkozási logikát és automatikus skálázást, amelyeket általában nehéz tesztelni a fejlesztési folyamat során.

Ezért fontos az éles környezethez hasonló környezetek folyamatos ellenőrzése, hogy a fejlesztési ciklusban a lehető leghamarabb megtalálhassa és kijavíthassa a problémákat vagy hibákat. A számítási feladatokért felelős csapatoknak a fejlesztési folyamat korai szakaszában (balra) kell tesztelni, és kényelmessé kell tenni a fejlesztők számára, hogy az éles környezethez közeli környezetben végezhessenek tesztelést.

A kritikus fontosságú számítási feladatok magas rendelkezésre állási követelményekkel rendelkeznek, 3, 4 vagy 5 kilences célokkal (99,9%, 99,99% vagy 99,999%). Fontos, hogy szigorú automatizált tesztelést implementáljunk, hogy elérjük ezeket a célokat.

A folyamatos ellenőrzés az egyes számítási feladatoktól és az architekturális jellemzőktől függ. Ez a cikk útmutatást nyújt az Azure Load Testing és az Azure Chaos Studio rendszeres fejlesztési ciklusba való előkészítéséhez és integrálásához.

1 – Tesztek meghatározása a várt küszöbértékek alapján

A folyamatos tesztelés egy összetett folyamat, amely megfelelő előkészítést igényel. A tesztelendőknek és a várt eredményeknek egyértelműnek kell lenniük.

A PE:06 - Javaslatok a teljesítményteszteléshez és az RE:08 - Javaslatok megbízhatósági tesztelési stratégia kialakításához az Azure Well-Architected Framework azt javasolja, hogy először azonosítsa a legfontosabb forgatókönyveket, függőségeket, várható használatot, rendelkezésre állást, teljesítményt és méretezhetőségi célokat.

Ezután meg kell határoznia egy mérhető küszöbérték-halmazt a fő forgatókönyvek várható teljesítményének számszerűsítéséhez.

Tipp.

A küszöbértékek közé tartoznak például a felhasználói bejelentkezések várt száma, az adott API-ra vonatkozó kérések másodpercenkénti száma, valamint a háttérfolyamatok másodpercenkénti műveletei.

Küszöbértékek használatával fejleszthet állapotmodellt az alkalmazáshoz, mind tesztelésre, mind az alkalmazás éles környezetben való üzemeltetésére.

Visualization of key system flows using green and red connected circles.

Ezután az értékekkel definiáljon egy terheléstesztet , amely reális forgalmat generál az alkalmazás alapkonfigurációs teljesítményének teszteléséhez, a várt méretezési műveletek érvényesítéséhez stb. Az éles üzem előtti környezetekben tartós mesterséges felhasználói forgalomra van szükség, mert használat nélkül nehéz felfedni a futásidejű problémákat.

A terheléstesztelés biztosítja, hogy az alkalmazás vagy az infrastruktúra módosításai ne okozzanak problémákat, és a rendszer továbbra is megfeleljen a várt teljesítmény- és tesztelési feltételeknek. Egy sikertelen tesztfuttatás, amely nem felel meg a tesztelési feltételeknek, azt jelzi, hogy módosítania kell az alaptervet, vagy váratlan hiba történt.

Load test run results screen showing failed load test run.

Annak ellenére, hogy az automatizált tesztek a napi használatot jelölik, rendszeresen kell manuális terheléses teszteket futtatnia annak ellenőrzéséhez, hogy a rendszer hogyan reagál a váratlan csúcsokra.

A folyamatos ellenőrzés második része a hibák injektálása (káosztechnika). Ez a lépés ellenőrzi a rendszer rugalmasságát azáltal, hogy teszteli, hogyan reagál a hibákra. Emellett az összes rugalmassági intézkedés, például az újrapróbálkozási logika, az automatikus skálázás és mások a várt módon működnek.

2 – Érvényesítés implementálása a Terhelésteszteléssel és a Chaos Studióval

A Microsoft Azure ezeket a felügyelt szolgáltatásokat biztosítja a terheléstesztelés és a káosztervezés implementálásához:

  • Az Azure Load Testing szintetikus felhasználói terhelést eredményez az alkalmazások és szolgáltatások számára.
  • Az Azure Chaos Studio lehetővé teszi a káoszkísérletek elvégzését azáltal, hogy szisztematikusan injektálja a hibákat az alkalmazás összetevőibe és infrastruktúrájába.

A Chaos Studiót és a terheléstesztelést az Azure Portalon is üzembe helyezheti és konfigurálhatja, de a folyamatos ellenőrzés kontextusában fontosabb, hogy api-kkal programozott és automatizált módon telepítse, konfigurálja és futtassa a teszteket. A két eszköz együttes használata lehetővé teszi, hogy megfigyelje, hogyan reagál a rendszer a problémákra, és hogyan képes öngyógyulni az infrastruktúra- vagy alkalmazáshibákra válaszul.

Az alábbi videó az Azure DevOpsba integrált Chaos és Load Testing együttes implementációját mutatja be:

Ha kritikus fontosságú számítási feladatot fejleszt, használja ki az Azure Mission-Critical projekt és az Azure Well-Architected Framework részeként biztosított referenciaarchitektúrákat, részletes útmutatást, minta implementációkat és kódösszetevőket.

A kritikus fontosságú implementáció üzembe helyezi a Terheléstesztelési szolgáltatást a Terraformon keresztül, és PowerShell Core burkolószkriptek gyűjteményét tartalmazza a szolgáltatás API-jával való interakcióhoz. Ezek a szkriptek közvetlenül egy üzembehelyezési folyamatba ágyazhatók be.

A referencia-implementáció egyik lehetősége, hogy közvetlenül a végpontok közötti (e2e) folyamaton belül hajtja végre a terhelési tesztet, amelyet az egyes (ágspecifikus) fejlesztési környezetek felpörgetésére használnak:

Run pipeline screen with the load testing checkbox ticked.

A folyamat automatikusan lefuttat egy terhelési tesztet káoszkísérletekkel vagy anélkül (a kiválasztástól függően):

Azure DevOps pipeline run with chaos and load testing.

Megjegyzés:

Ha káoszkísérleteket futtat egy terheléses teszt során, az nagyobb késést, magasabb válaszidőt és átmenetileg megnövekedett hibaarányt eredményezhet. Nagyobb számokat fog megfigyelni, amíg egy vertikális felskálázási művelet be nem fejeződik, vagy a feladatátvétel befejeződik, ha egy káoszkísérlet nélküli futtatáshoz hasonlítjuk.

Chart showing increased response time during chaos experiment.

Attól függően, hogy engedélyezve van-e a káosztesztelés és a kísérletek kiválasztása, az alapkonfigurációk eltérőek lehetnek, mivel a hibák tűréshatára "normál" és "káosz" állapotban eltérő lehet.

3 – Küszöbértékek módosítása és alapterv létrehozása

Végül módosítsa a terhelésteszt küszöbértékeit a rendszeres futtatásokhoz, hogy ellenőrizze, hogy az alkalmazás (továbbra is) biztosítja-e a várt teljesítményt, és nem okoz-e hibát. A káoszteszteléshez külön alapkonfigurációval rendelkezik, amely tolerálja a hibaarányok várható kiugró emelkedését és az ideiglenesen csökkentett teljesítményt. Ez a tevékenység folyamatos, és rendszeresen meg kell ismételni. Például az új funkciók bevezetése, a szolgáltatási termékváltozatok módosítása és mások bevezetése után.

Az Azure Load Testing szolgáltatás egy tesztfeltételnek nevezett beépített képességet biztosít, amely lehetővé teszi bizonyos feltételek megadását, amelyeket egy tesztnek át kell adnia. Ez a képesség különböző alapkonfigurációk implementálásához használható.

Test criteria screen with response time and error criteria marked as Failed.

Ez a képesség az Azure Portalon és a terheléstesztelési API-on keresztül érhető el, és az Azure Mission-critical részeként kifejlesztett burkolószkriptek lehetővé teszik egy JSON-alapú alapkonfiguráció átadását.

Javasoljuk, hogy ezeket a teszteket közvetlenül integrálja a CI/CD-folyamatokba , és futtassa őket a funkciófejlesztés korai szakaszában. Példaként tekintse meg a minta implementációt az Azure Mission-kritikus referencia-implementációban.

Összefoglalva, a hiba minden összetett elosztott rendszerben elkerülhetetlen, ezért a megoldást a hibák kezeléséhez ki kell építeni (és tesztelni) kell. A jól megtervezett keretrendszer kritikus fontosságú számítási feladatokra vonatkozó útmutatásai és referencia-implementációi segítségével rendkívül megbízható alkalmazásokat tervezhet és üzemeltethet a Microsoft-felhőből származó maximális érték kinyerése érdekében.

Következő lépés

Tekintse át a kritikus fontosságú számítási feladatok üzembehelyezési és tesztelési tervezési területét.