Kritikus fontosságú számítási feladatok alkalmazástervezése az Azure-ban

Alkalmazás tervezésekor a funkcionális és a nem funkcionális alkalmazáskövetelmények is kritikus fontosságúak. Ez a tervezési terület olyan architektúramintákat és skálázási stratégiákat ismertet, amelyek segítenek az alkalmazásnak a hibákkal szembeni ellenállóbbá tenni.

Fontos

Ez a cikk az Azure Well-Architected Framework kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a Mi az a kritikus fontosságú számítási feladat?.

Skálázási egységek architektúrája

A megoldások minden funkcionális aspektusának képesnek kell lennie a skálázásra, hogy megfeleljen az igények változásainak. Javasoljuk, hogy skálázási egységek architektúráját használva optimalizálja a végpontok közötti méretezhetőséget a rekeszezéssel, valamint a kapacitás hozzáadásának és eltávolításának folyamatának egységesítéséhez. A skálázási egység olyan logikai egység vagy függvény, amely egymástól függetlenül skálázható. Egy egység kódösszetevőkből, alkalmazásüzemeltési platformokból, a kapcsolódó összetevőket lefedő üzembehelyezési bélyegzőkből és akár előfizetésekből is áll, amelyek támogatják a több-bérlős követelményeket.

Ezt a megközelítést azért javasoljuk, mert az egyes erőforrások és a teljes alkalmazás méretezési korlátait kezeli. Összetett üzembe helyezési és frissítési forgatókönyvekben segít, mert egy skálázási egység egyetlen egységként helyezhető üzembe. Emellett tesztelheti és ellenőrizheti az összetevők adott verzióit egy egységben, mielőtt a felhasználói forgalmat hozzá irányítja.

Tegyük fel, hogy a kritikus fontosságú alkalmazás egy online termékkatalógus. Felhasználói folyamattal rendelkezik a termék megjegyzéseinek és minősítéseinek feldolgozásához. A folyamat API-kat használ a megjegyzések és értékelések lekéréséhez és közzétételéhez, valamint olyan támogató összetevőkhöz, mint az OAuth-végpont, az adattár és az üzenetsorok. Az állapot nélküli API-végpontok részletes funkcionális egységeket jelentenek, amelyeknek alkalmazkodniuk kell az igény szerinti változásokhoz. A mögöttes alkalmazásplatformnak is képesnek kell lennie a skálázásra. A teljesítmény szűk keresztmetszeteinek elkerülése érdekében az alsóbb rétegbeli összetevőknek és függőségeknek is megfelelő mértékben kell skálázniuk. Önállóan, különálló skálázási egységként vagy egy logikai egység részeként együtt skálázhatók.

Példa skálázási egységekre

Az alábbi képen a méretezési egységek lehetséges hatókörei láthatók. A hatókörök a mikroszolgáltatás-podoktól a fürtcsomópontokig és a regionális üzembehelyezési bélyegzőkig terjednek.

Kialakítási szempontok

• Hatókör. A skálázási egységek hatókörét, a skálázási egységek és összetevőik közötti kapcsolatot kapacitásmodell szerint kell meghatározni. Vegye figyelembe a teljesítmény nem funkcionális követelményeit.

• Skálázási korlátok. Az Azure-előfizetés skálázási korlátai és kvótái hatással lehetnek az alkalmazástervezésre, a technológiai lehetőségekre és a skálázási egységek definíciójára. A skálázási egységek segíthetnek megkerülni a szolgáltatások skálázási korlátait. Ha például egy egységben lévő AKS-fürtök csak 1000 csomópontot tartalmazhatnak, két egység használatával 2000 csomópontra növelheti ezt a korlátot.

• Várt terhelés. Az alapvető skálázási követelmények tájékoztatásához használja az egyes felhasználói folyamatokra vonatkozó kérések számát, a kérelmek várható csúcsértékét (másodpercenkénti kérések), valamint a napi/heti/szezonális forgalmi mintákat. A forgalom és az adatmennyiség várható növekedési mintáit is vegye figyelembe.

• Elfogadható csökkentett teljesítmény. Határozza meg, hogy a magas válaszidővel rendelkező csökkentett teljesítményű szolgáltatás elfogadható-e a terhelés alatt. A szükséges kapacitás modellezésekor a terhelés alatt álló megoldás szükséges teljesítménye kritikus tényező.

• Nem funkcionális követelmények. A műszaki és üzleti forgatókönyvek különböző szempontokat foglalnak el a rugalmasság, a rendelkezésre állás, a késés, a kapacitás és a megfigyelhetőség szempontjából. Elemezze ezeket a követelményeket a kulcsfontosságú, végpontok közötti felhasználói folyamatok kontextusában. A tervezés, a döntéshozatal és a technológiai döntések viszonylag rugalmasak lesznek a felhasználói folyamat szintjén.

Tervezési javaslatok

• Határozza meg egy skálázási egység hatókörét és azokat a korlátokat, amelyek a skálázáshoz aktiválják az egységet.

• Győződjön meg arról, hogy az összes alkalmazásösszetevő egymástól függetlenül vagy egy más kapcsolódó összetevőket tartalmazó skálázási egység részeként skálázható.

• Kapacitásmodell és nem funkcionális követelmények alapján határozza meg a méretezési egységek közötti kapcsolatot.

• Definiáljon egy regionális üzembehelyezési bélyeget, amely egyesíti a regionális alkalmazáserőforrások kiépítését, kezelését és működését egy heterogén, de egymástól függő skálázási egységben. A terhelés növekedésével további bélyegek helyezhetők üzembe ugyanazon az Azure-régión belül vagy különböző régiókban a megoldás horizontális skálázásához.

• Használjon Azure-előfizetést skálázási egységként, hogy az egyetlen előfizetésen belüli skálázási korlátok ne korlátozzák a méretezhetőséget. Ez a megközelítés olyan nagy léptékű alkalmazásforgatókönyvekre vonatkozik, amelyek jelentős forgalommal rendelkeznek.

• Modellre van szükség az azonosított forgalmi minták körül, hogy elegendő kapacitás legyen kiépítve csúcsidőkben a szolgáltatás romlásának megelőzése érdekében. Másik lehetőségként optimalizálhatja a kapacitást csúcsidőn kívül is.

• Mérje meg a vertikális felskálázási és felskálázási műveletek végrehajtásához szükséges időt annak biztosítása érdekében, hogy a forgalom természetes változásai ne okozzák a szolgáltatás elfogadhatatlan mértékű romlását. A skálázási műveletek időtartamának nyomon követése operatív metrikaként.

Megjegyzés

Az Azure-beli célzónában történő üzembe helyezéskor győződjön meg arról, hogy a célzóna-előfizetés az alkalmazásnak van szentelve, hogy egyértelmű felügyeleti határt biztosítson, és elkerülje a zajos szomszéd antipatternt.

Globális terjesztés

Nem lehet elkerülni a nagy mértékben elosztott környezetek meghibásodását. Ez a szakasz stratégiákat biztosít a számos hibaforgatókönyv enyhítésére. Az alkalmazásnak képesnek kell lennie ellenállni a regionális és zonális hibáknak. Aktív/aktív modellben kell üzembe helyezni, hogy a terhelés minden régióban el legyen osztva.

Ebből a videóból megtudhatja, hogyan tervezheti meg a kritikus fontosságú alkalmazások hibáit, és hogyan maximalizálhatja a rugalmasságot:

Kialakítási szempontok

• Redundancia. Az alkalmazást több régióban kell üzembe helyezni. Emellett egy régión belül erősen javasoljuk, hogy rendelkezésre állási zónákat használjon az adatközpont szintjén a hibatűrés engedélyezéséhez. A rendelkezésre állási zónák késési kerülete kevesebb, mint 2 ezredmásodperc a rendelkezésre állási zónák között. A zónák között "csevegő" számítási feladatok esetében ez a késés teljesítménybeli büntetést vonhat maga után, és sávszélesség-díjakat vonhat maga után az zónák közötti adatátvitelhez.

• Aktív/aktív modell. Az aktív/aktív üzembehelyezési stratégia azért ajánlott, mert maximalizálja a rendelkezésre állást, és magasabb összetett szolgáltatásiszint-szerződést (SLA) biztosít. Számos alkalmazásforgatókönyv esetében azonban kihívást jelenthet az adatszinkronizálás és a konzisztencia szempontjából. Az adatplatform szintjén felmerülő kihívások kezelése a megnövekedett költségek és a mérnöki munka kompromisszumainak figyelembevételével.

  Az aktív/aktív üzemelő példányok több felhőszolgáltató között lehetővé téve a globális erőforrásoktól való függőség mérséklését egyetlen felhőszolgáltatón belül. A többfelhős aktív/aktív üzembe helyezési stratégia azonban jelentős mértékű összetettséggel jár a CI/CD körül. Emellett az erőforrás-specifikációk és -képességek felhőszolgáltatók közötti különbségei miatt minden egyes felhőhöz speciális üzembehelyezési bélyegekre van szükség.

• Földrajzi eloszlás. Előfordulhat, hogy a számítási feladat megfelelőségi követelményekkel rendelkezik a földrajzi adatok tárolására, az adatvédelemre és az adatmegőrzésre vonatkozóan. Fontolja meg, hogy vannak-e olyan régiók, ahol az adatoknak kell lenniük, vagy ahol erőforrásokat kell üzembe helyezni.

• Kérés forrása. A felhasználók vagy a függő rendszerek földrajzi közelsége és sűrűsége tájékoztatnia kell a tervezési döntéseket a globális elosztásról.

• Kapcsolat. A munkaterhelés felhasználók vagy külső rendszerek általi elérése befolyásolja a tervezést. Fontolja meg, hogy az alkalmazás elérhető-e a nyilvános interneten vagy magánhálózatokon, amelyek VPN- vagy Azure ExpressRoute-kapcsolatcsoportokat használnak.

A platformszintű tervezési javaslatokért és konfigurációs lehetőségekért lásd : Alkalmazásplatform: Globális terjesztés.

Lazán összekapcsolt eseményvezérelt architektúra

Az összekapcsolás jól definiált interfészeken keresztül teszi lehetővé a szolgáltatások közötti kommunikációt. A laza kapcsoló lehetővé teszi, hogy az alkalmazás-összetevő egymástól függetlenül működjön. A mikroszolgáltatás-architektúra stílusa összhangban van a kritikus fontosságú követelményekkel. A kaszkádolt hibák megelőzésével elősegíti a magas rendelkezésre állást.

A laza összekapcsolás érdekében határozottan javasoljuk, hogy eseményvezérelt kialakítást építsen be. A közvetítőn keresztüli aszinkron üzenetfeldolgozás rugalmasságot építhet ki.

Bizonyos esetekben az alkalmazások az üzleti céloktól függően kombinálhatják a laza és szoros összekapcsolást.

Kialakítási szempontok

• Futtatókörnyezeti függőségek. A lazán összekapcsolt szolgáltatásokat nem szabad arra korlátozni, hogy ugyanazt a számítási platformot, programozási nyelvet, futtatókörnyezetet vagy operációs rendszert használják.

• Skálázás. A szolgáltatásoknak képesnek kell lenniük egymástól függetlenül skálázni. Az infrastruktúra- és platformerőforrások használatának optimalizálása.

• Hibatűrés. A hibákat külön kell kezelni, és nem befolyásolhatják az ügyféltranzakciókat.

• Tranzakciós integritás. Vegye figyelembe a különálló szolgáltatásokban előforduló adatlétrehozás és adatmegőrzés hatását.

• Elosztott nyomkövetés. A végpontok közötti nyomkövetés összetett vezénylést igényelhet.

Tervezési javaslatok

• Mikroszolgáltatások határainak igazítása kritikus felhasználói folyamatokkal.

• Ha lehetséges, használjon eseményvezérelt aszinkron kommunikációt a fenntartható skálázás és az optimális teljesítmény támogatásához.

• A konzisztencia garantálásához használjon olyan mintákat, mint a Kimenő üzenetek és a Tranzakciós munkamenet, hogy minden üzenet megfelelően legyen feldolgozva.

Példa: Eseményvezérelt megközelítés

A kritikus online referencia-implementáció mikroszolgáltatásokkal dolgoz fel egyetlen üzleti tranzakciót. Az írási műveleteket aszinkron módon alkalmazza egy üzenetközvetítővel és -feldolgozóval. Az olvasási műveletek szinkronban vannak, és az eredmény közvetlenül a hívónak lesz visszaadva.

Rugalmassági minták és hibakezelés az alkalmazáskódban

A kritikus fontosságú alkalmazásokat úgy kell megtervezni, hogy rugalmasak legyenek, hogy a lehető legtöbb hibaforgatókönyvet kezelni lehessen. Ez a rugalmasság maximalizálja a szolgáltatások rendelkezésre állását és megbízhatóságát. Az alkalmazásnak önjavító képességekkel kell rendelkeznie, amelyeket olyan tervezési mintákkal valósíthat meg, mint az Újrapróbálkozás a visszakapcsolással és a Megszakítóval.

Az alkalmazáslogikában nem teljes mértékben enyhíthető nem átmeneti hibák esetén az állapotmodellnek és az operatív burkolónak korrekciós műveletet kell végrehajtania. Az alkalmazás kódjának tartalmaznia kell a megfelelő kialakítást és naplózást az állapotmodell tájékoztatásához, és szükség szerint elő kell segítenie az ezt követő hibaelhárítást vagy a kiváltó okok elemzését. Elosztott nyomkövetést kell implementálnia, hogy a hívónak átfogó hibaüzenetet biztosítson, amely tartalmaz egy korrelációs azonosítót meghibásodás esetén.

Az Olyan eszközök, mint az Application Insights , segíthetnek az alkalmazáskövetések lekérdezésében, korrelálásában és vizualizációjában.

Kialakítási szempontok

• Megfelelő konfigurációk. Nem ritka, hogy átmeneti problémák kaszkádolt hibákat okoznak. A megfelelő visszalépés nélküli újrapróbálkozás például súlyosbítja a problémát, ha egy szolgáltatás szabályozása folyamatban van. A térbeli újrapróbálkozási késleltetéseket lineárisan is megpróbálhatja, vagy exponenciálisan növelheti őket, hogy a növekvő késések miatt vissza tudja őket kapcsolni.

• Állapotvégpontok. Az alkalmazáskódon belül funkcionális ellenőrzéseket tehet közzé olyan állapotvégpontok használatával, amelyeket külső megoldások lekérdezhetnek az alkalmazás-összetevő állapotának lekéréséhez.

Tervezési javaslatok

Íme néhány gyakori szoftvermérnöki minta a rugalmas alkalmazásokhoz:

Mintázat	Összefoglalás
Queue-Based Load Leveling	Puffert vezet be a fogyasztók és a kért erőforrások között a konzisztens terhelési szintek biztosítása érdekében. A fogyasztói kérések várólistára helyezésekor a feldolgozói folyamat a feldolgozó által beállított ütemben kezeli azokat a kért erőforráson, és a kért erőforrás képes feldolgozni a kéréseket. Ha a fogyasztók választ várnak a kéréseikre, akkor egy külön válaszmechanizmust kell implementálnia. Alkalmazzon egy rangsorolt sorrendet, hogy a legfontosabb tevékenységek legyenek először végrehajtva.
Circuit Breaker	Stabilitást biztosít a helyreállításra való várakozással vagy a kérések gyors elutasításával ahelyett, hogy blokkolva marad, miközben egy elérhetetlen távoli szolgáltatásra vagy erőforrásra vár. Ez a minta olyan hibákat is kezel, amelyek helyreállítása változó ideig tarthat, amikor távoli szolgáltatással vagy erőforrással létesít kapcsolatot.
Bulkhead	A szolgáltatáspéldányok csoportokba való particionálására tett kísérletek a terhelési és rendelkezésre állási követelmények alapján, a hibák elkülönítése a szolgáltatás működésének fenntartása érdekében.
Saga	Kezeli az adatkonzisztenciát a független adattárakat tartalmazó mikroszolgáltatásokban, biztosítva, hogy a szolgáltatások meghatározott esemény- vagy üzenetcsatornákon keresztül frissíthessék egymást. Minden szolgáltatás helyi tranzakciókat hajt végre a saját állapotának frissítéséhez, és közzétesz egy eseményt, amely elindítja a következő helyi tranzakciót a saga-ban. Ha egy szolgáltatásfrissítés sikertelen, a saga kompenzáló tranzakciókat futtat a korábbi szolgáltatásfrissítési lépések ellensúlyozása érdekében. Az egyes szolgáltatásfrissítési lépések maguk is implementálhatnak rugalmassági mintákat, például újrapróbálkozási folyamatokat.
Health Endpoint Monitoring	Funkcionális ellenőrzéseket hajt végre egy alkalmazásban, amelyet a külső eszközök rendszeres időközönként érhetnek el a közzétett végpontokon keresztül. A végpontok válaszait az alkalmazás állapotának tájékoztatására és az operatív válaszok aktiválására szolgáló kulcsfontosságú operatív metrikák használatával értelmezheti, például riasztások létrehozása vagy kompenzáló visszaállítási üzembe helyezés végrehajtása.
Retry	Elegánsan és átláthatóan kezeli az átmeneti hibákat. – Megszakítás, ha a hiba nem valószínű, hogy átmeneti lesz, és nem valószínű, hogy sikeres lesz, ha a műveletet újra megkísérlik. - Próbálkozzon újra, ha a hiba szokatlan vagy ritka, és a művelet valószínűleg sikeres lesz, ha azonnal újra megkísérlik. – Próbálkozzon újra egy késleltetés után, ha a hibát egy olyan feltétel okozza, amely rövid időre lehet szükség a helyreállításhoz, például hálózati kapcsolat vagy nagy terhelésű hibák. Az újrapróbálkozási késleltetés növekedésével megfelelő háttérstratégiát alkalmazhat.
Szabályozás	Szabályozza az alkalmazásösszetevők által használt erőforrások felhasználását, így megvédve őket a túlzott tehertől. Amikor egy erőforrás eléri a terhelési küszöbértéket, az hatástalanítja az alacsonyabb prioritású műveleteket, és csökkenti a nem alapvető funkciókat, hogy az alapvető funkciók mindaddig folytatódjanak, amíg elegendő erőforrás nem áll rendelkezésre a normál működéshez való visszatéréshez.

Íme néhány további javaslat:

• A szállító által biztosított SDK-k, például az Azure SDK-k használata a függő szolgáltatásokhoz való csatlakozáshoz. Egyéni funkciók implementálása helyett használjon beépített rugalmassági képességeket.

• A sikertelen függőségi hívások újrapróbálásakor megfelelő háttérstratégiát alkalmazhat a saját maga által okozott DDoS-forgatókönyvek elkerülése érdekében.

• Az alkalmazásszintű rugalmassági minták használatának konzisztenciájának és sebességének növelése érdekében határozza meg az összes alkalmazás-mikroszolgáltatás-csapat általános mérnöki feltételeit.

• A rugalmassági mintákat bevált szabványosított csomagok, például a Polly for C# vagy a Java Sentinel használatával valósíthatja meg.

• Használjon korrelációs azonosítókat az összes nyomkövetési eseményhez és naplóüzenethez, hogy összekapcsolja őket egy adott kéréssel. Korrelációs azonosítókat ad vissza a hívónak az összes híváshoz, nem csak a sikertelen kérésekhez.

• Strukturált naplózás használata az összes naplóüzenethez. Az alkalmazáskövetésekhez, metrikákhoz és naplókhoz válasszon egy egységes operatív adatgyűjtőt, amely lehetővé teszi az operátorok számára a problémák egyszerű hibakeresését. További információ: Felhőalkalmazások monitorozási adatainak gyűjtése, összesítése és tárolása.

• Győződjön meg arról, hogy a működési adatokat az üzleti követelményekkel együtt használják az alkalmazásállapot-modell tájékoztatásához.

Programozási nyelv kiválasztása

Fontos, hogy a megfelelő programozási nyelveket és keretrendszereket válassza ki. Ezeket a döntéseket gyakran a szervezet képességkészletei vagy szabványosított technológiái határozzák meg. Fontos azonban a különböző nyelvek és keretrendszerek teljesítményének, rugalmasságának és általános képességeinek értékelése.

Kialakítási szempontok

• Fejlesztői készletek képességei. Az Azure service SDK-k által kínált képességek különböző nyelveken érhetők el. Ezek a különbségek befolyásolhatják az Azure-szolgáltatás vagy a programozási nyelv választását. Ha például az Azure Cosmos DB megvalósítható megoldás, előfordulhat, hogy a Go nem megfelelő fejlesztési nyelv, mert nincs belső SDK.

• Funkciófrissítések. Fontolja meg, hogy az SDK milyen gyakran frissül a kiválasztott nyelv új funkcióival. A gyakran használt SDK-k, például a .NET- és Java-kódtárak gyakran frissülnek. Előfordulhat, hogy a más nyelvekhez tartozó egyéb SDK-k vagy SDK-k ritkábban frissülnek.

• Több programozási nyelv vagy keretrendszer. Több technológiával is támogathatja a különböző összetett számítási feladatokat. Azonban el kell kerülnie a szórványt, mert a felügyeleti összetettség és az üzemeltetési kihívásokat is bevezeti.

• Számítási lehetőség. Előfordulhat, hogy az örökölt vagy saját fejlesztésű szoftverek nem futnak a PaaS-szolgáltatásokban. Emellett előfordulhat, hogy nem tud régi vagy saját fejlesztésű szoftvereket belefoglalni a tárolókba.

Tervezési javaslatok

• Értékelje ki az összes releváns Azure SDK-t a szükséges képességekhez és a választott programozási nyelvekhez. Ellenőrizze az igazítást a nem funkcionális követelményekkel.

• Optimalizálja a programozási nyelvek és keretrendszerek kiválasztását a mikroszolgáltatás szintjén. Szükség szerint használjon több technológiát.

• Rangsorolja a .NET SDK-t a megbízhatóság és a teljesítmény optimalizálása érdekében. A .NET Azure SDK-k általában további képességeket biztosítanak, és gyakran frissülnek.

Következő lépés

Tekintse át az alkalmazásplatform szempontjait.

Alkalmazásplatform