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

Az alkalmazások tervezésekor mind a funkcionális, mind a nem funkcionális alkalmazáskövetelmények 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 ellenállóvá tenni a hibákat.

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ás minden funkcionális aspektusának képesnek kell lennie a skálázásra, hogy megfeleljen az igények változásainak. Javasoljuk, hogy egy skálázási egység architektúráját használva optimalizálja a végpontok közötti méretezhetőséget a horizontális felosztással, valamint a kapacitás hozzáadásának és eltávolításának folyamatát is egységesítse. 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ó. Az egység kódösszetevőkből, alkalmazásüzemeltetési platformokból, a kapcsolódó összetevőket lefedő üzembehelyezési bélyegekbő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. Segít az összetett üzembe helyezési és frissítési forgatókönyvekben, mivel egy skálázási egység egy egységként telepíthető. Emellett tesztelheti és ellenőrizheti az összetevők bizonyos verzióit egy egységben, mielőtt a felhasználói forgalmat hozzá irányítanák.

Tegyük fel, hogy a kritikus fontosságú alkalmazás egy online termékkatalógus. Felhasználói folyamatokkal 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ére és közzétételére, valamint olyan támogató összetevőkre, mint az OAuth-végpontok, az adattárak é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 ennek megfelelően skálázni. 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. Egymástól függetlenül, külön skálázási egységként vagy egy logikai egység részeként is 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ási podoktól a fürtcsomópontokig és a regionális üzembehelyezési bélyegekig 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.

• Méretezési korlátok. Az Azure-előfizetések méretezé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 méretezési korlátait. Ha például egy egységben egy AKS-fürtnek csak 1000 csomópontja lehet, két egység használatával 2000 csomópontra növelheti ezt a korlátot.

• Várható 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át (kérések másodpercenként), valamint a napi/heti/szezonális forgalmi mintákat. A forgalom és az adatmennyiség várható növekedési mintáit is figyelembe kell vegye.

• Elfogadható csökkentett teljesítmény. Határozza meg, hogy a magas válaszidővel rendelkező csökkentett szolgáltatás elfogadható-e terhelés esetén. A szükséges kapacitás modellezése során 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 figyelembe véve állnak 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 felhasználói folyamat szintjén viszonylag rugalmasan tervezhet, hozhat döntéseket és technológiai döntéseket.

Tervezési javaslatok

• Határozza meg a méretezé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 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.

• Adjon meg egy regionális üzembehelyezési bélyeget, amely egységesí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 ugyanabban az Azure-régióban vagy más régióban a megoldás horizontális skálázásához.

• Azure-előfizetést használjon 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.

• Az azonosított forgalmi mintákhoz szükséges kapacitás modellezése annak érdekében, hogy a szolgáltatás romlásának megakadályozása érdekében csúcsidőben elegendő kapacitás legyen kiépítve. 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 vertikális műveletek elvégzéséhez szükséges időt, 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 műveleti metrikaként.

Feljegyzés

Az Azure-beli célzónában való üzembe helyezéskor győződjön meg arról, hogy a célzóna-előfizetés dedikált az alkalmazás számára, hogy egyértelmű felügyeleti határt biztosítson, és elkerülje a zajos szomszéd antipattern használatát.

Globális terjesztés

Nem lehet elkerülni a meghibásodást bármely magas elosztású környezetben. Ez a szakasz stratégiákat biztosít számos hibaforgatókönyv enyhítésére. Az alkalmazásnak képesnek kell lennie ellenállni a regionális és az 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ákkal engedélyezze a hibatűrést az adatközpont szintjén. A rendelkezésre állási zónák késési szegélye kevesebb, mint 2 ezredmásodperc a rendelkezésre állási zónák között. A zónák közötti "csevegő" számítási feladatok esetében ez a késés teljesítménybeli büntetést vonhat maga után az zónák közötti adatátvitel esetében.

• 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 kompromisszumoinek figyelembevételével.

  Az aktív/aktív üzembe helyezés több felhőszolgáltatón keresztül lehetséges, hogy egy felhőszolgáltatón belül mérsékelje a globális erőforrásoktól való függőséget. A többfelhős aktív/aktív üzembehelyezési stratégia azonban jelentős mértékű összetettséghez vezet a CI/CD körül. Emellett az erőforrás-specifikációk és a felhőszolgáltatók képességei közötti különbségek miatt minden egyes felhőhöz speciális üzembehelyezési bélyegekre van szükség.

• Földrajzi eloszlás. A számítási feladat megfelelőségi követelményekkel rendelkezhet 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 adatoknak kell lenniük, vagy ahol erőforrásokat kell üzembe helyezni.

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

• Kapcsolatok. 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 a VPN- vagy Azure ExpressRoute-kapcsolatcsoportokat használó magánhálózatokon.

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ásközi kommunikációt. A laza összekapcsolás lehetővé teszi az alkalmazás-összetevők egymástól függetlenül történő működését. 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áshoz erősen javasoljuk, hogy eseményvezérelt kialakítást építsen be. A közvetítőn keresztüli aszinkron üzenetfeldolgozás rugalmasságot hozhat létre.

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

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 egymástól függetlenül kell skálázniuk. Optimalizálja az infrastruktúra és a platformerőforrások használatát.

• Hibatűrés. A hibákat külön kell kezelni, és nem befolyásolhatja 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 fontosságú 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 kezelje. Ez a rugalmasság maximalizálja a szolgáltatás rendelkezésre állását és megbízhatóságát. Az alkalmazásnak öngyógyító képességekkel kell rendelkeznie, amelyeket olyan tervezési minták használatával valósíthat meg, mint az Újrapróbálkozások a Backoff é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 elvégeznie. Az alkalmazáskódnak tartalmaznia kell a megfelelő rendszerezést és naplózást az állapotmodell tájékoztatásához, és szükség szerint elő kell segítenie a 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 Alkalmazás Elemzések, 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. Ha például a szolgáltatás szabályozása folyamatban van, a megfelelő visszalépés nélküli újrapróbálkozás súlyosbítja a problémát. A térbeli újrapróbálkozások lineárisan késleltethetők, vagy exponenciálisan növelhetők, hogy a növekvő késések révén visszahátrázhatók legyenek.

• Állapotvégpontok. Az alkalmazáskódon belüli funkcionális ellenőrzéseket olyan állapotvégpontok használatával teheti elérhetővé, 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:

Minta	Összegzés
Queue-Based Load Leveling	Puffert vezet be a felhasználók és a kért erőforrások között a konzisztens terhelési szintek biztosítása érdekében. Mivel a fogyasztói kérések várólistára kerülnek, a feldolgozói folyamat a kért erőforráson kezeli azokat a feldolgozó által beállított ütemben, é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, egy külön válaszmechanizmust kell implementálnia. Rangsorolt sorrend alkalmazása a legfontosabb tevékenységek első végrehajtása érdekében.
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, nem pedig blokkolással, miközben egy elérhetetlen távoli szolgáltatásra vagy erőforrásra vár. Ez a minta kezeli azokat a hibákat is, amelyek a távoli szolgáltatáshoz vagy erőforráshoz való csatlakozáskor változó ideig tarthatnak.
Bulkhead	A szolgáltatáspéldányok csoportokba történő particionálására tett kísérletek a terhelési és rendelkezésre állási követelmények alapján, a szolgáltatásfunkciók fenntartásához szükséges hibák elkülönítésével.
Saga	A független adattárakat tartalmazó mikroszolgáltatások adatkonzisztenciáját úgy kezeli, hogy a szolgáltatások meghatározott esemény- vagy üzenetcsatornákon keresztül frissítik 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 megvalósíthatják a rugalmassági mintákat, például újrapróbálkozhatnak.
Health Endpoint Monitoring	Olyan funkcionális ellenőrzéseket valósít meg 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 a főbb működési metrikák használatával értelmezheti az alkalmazás állapotának tájékoztatására és a működési válaszok aktiválására, például riasztások indítására vagy kompenzáló visszaállítási üzembe helyezés végrehajtására.
Retry	Elegánsan és transzparensen kezeli az átmeneti hibákat. - Megszakítás, ha a hiba nem valószínű, hogy átmeneti, é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. - Ha a hibát egy olyan feltétel okozza, amely rövid ideig tarthat a helyreállításhoz, például hálózati kapcsolat vagy nagy terhelésű hibák okozzák, próbálkozzon újra. Az újrapróbálkozási késleltetés növekedésével megfelelő visszalépési stratégiát alkalmazhat.
Szabályozás	Szabályozza az alkalmazásösszetevők által használt erőforrások felhasználását, így védve őket a túlzott teherbeeséstől. Amikor egy erőforrás eléri a terhelési küszöbértéket, az csökkenti 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.

• Megfelelő visszalépési stratégiát alkalmazhat a sikertelen függőségi hívások újrapróbálkozásakor, hogy elkerülje az ön által okozott DDoS-forgatókönyvet.

• Az alkalmazásszintű rugalmassági minták használatának konzisztenciáját és sebességét hajtó általános mérnöki kritériumok meghatározása minden alkalmazás-mikroszolgáltatási csapat számára.

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

• 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ások nyomkövetéséhez, metrikáihoz és naplóihoz válasszon egy egységes üzemeltetési 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ó: Monitorozási adatok gyűjtése, összesítése és tárolása felhőalkalmazásokhoz.

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

Programozási nyelv kiválasztása

Fontos a megfelelő programozási nyelvek és keretrendszerek kiválasztása. Ezeket a döntéseket gyakran a szervezet készsé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 kié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 eltérőek. 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 más nyelvek más SDK-jait vagy SDK-jait ritkábban frissítik.

• 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 kerülnie kell a terjeszkedést, mert a felügyeleti összetettség és a működési kihívások elé állítja.

• Számítási lehetőség. Előfordulhat, hogy az örökölt vagy védett szoftverek nem futnak a PaaS-szolgáltatásokban. Emellett előfordulhat, hogy nem tud régi vagy védett 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 több technológiát is használhat.

• 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