Kritikus fontosságú alaparchitektúra az Azure-ban

Ez az architektúra útmutatást nyújt egy kritikus fontosságú számítási feladat azure-ra való tervezéséhez. Natív felhőbeli képességeket használ a megbízhatóság és a működési hatékonyság maximalizálása érdekében. A jól megtervezett, kritikus fontosságú számítási feladatok tervezési módszertanát alkalmazza egy internetkapcsolattal rendelkező alkalmazásra, ahol a számítási feladat nyilvános végponton keresztül érhető el, és nem igényel privát hálózati kapcsolatot más vállalati erőforrásokhoz.

Megbízhatósági szint

A megbízhatóság relatív fogalom, és ahhoz, hogy a számítási feladatok megfelelően megbízhatóak legyenek, tükröznie kell az azt körülvevő üzleti követelményeket, beleértve a szolgáltatásiszint-célkitűzéseket (SLO) és a szolgáltatásiszint-szerződéseket (SLA), hogy rögzítsék az alkalmazás rendelkezésre állási idejének százalékos arányát.

Ez az architektúra 99,99%-os SLO-t céloz meg, amely 52 perc 35 másodperces engedélyezett éves állásidőnek felel meg. Ezért minden átfogó tervezési döntés célja ennek a cél SLO-nak a megvalósítása.

Főbb tervezési stratégiák

Számos tényező befolyásolhatja az alkalmazások megbízhatóságát, például a meghibásodás utáni helyreállítás képességét, a regionális rendelkezésre állást, az üzembe helyezés hatékonyságát és a biztonságot. Ez az architektúra olyan átfogó tervezési stratégiákat alkalmaz, amelyek célja ezeknek a tényezőknek a kezelése és a cél megbízhatósági szint elérése.

• Redundancia rétegekben

  • Üzembe helyezés aktív-aktív modellben több régióban. Az alkalmazás két vagy több Olyan Azure-régióban van elosztva, amelyek aktív felhasználói forgalmat kezelnek.

  • Használja a rendelkezésre állási zónákat az összes figyelembe vett szolgáltatáshoz, hogy maximalizálja a rendelkezésre állást egyetlen Azure-régióban, és elosztsa az összetevőket fizikailag különálló adatközpontok között egy régión belül.

  • Válassza ki a globális terjesztést támogató erőforrásokat.

  Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: globális terjesztés.

• Üzembehelyezési bélyegek

  Regionális bélyeg üzembe helyezése skálázási egységként , ahol az erőforrások logikai készlete egymástól függetlenül építhető ki, hogy lépést tartson az igények változásával. Minden egyes bélyeg több beágyazott méretezési egységet is alkalmaz, például az előtérbeli API-kat és a háttérprocesszorokat, amelyek egymástól függetlenül skálázhatók és skálázhatók.

  Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: skálázási egységek architektúrája.

• Megbízható és megismételhető üzemelő példányok

  • Alkalmazza az infrastruktúra mint kód (IaC) elvét olyan technológiákkal, mint a Terraform, hogy verziókövetést és szabványosított üzemeltetési megközelítést biztosítson az infrastruktúra-összetevők számára.

  • Nulla állásidős kék/zöld üzembehelyezési folyamat implementálása. A létrehozási és kiadási folyamatokat teljes mértékben automatizáltan kell üzembe helyezni a bélyegek egyetlen működési egységként való üzembe helyezéséhez, kék/zöld üzembe helyezéssel, folyamatos ellenőrzéssel.

  • Alkalmazza a környezetkonzisztenciát az összes figyelembe vett környezetre ugyanazzal az üzembehelyezési folyamatkóddal az éles és az üzem előtti környezetekben. Ez kiküszöböli a környezetek üzembe helyezésével és folyamatváltozásaival kapcsolatos kockázatokat.

  • Folyamatos ellenőrzéssel rendelkezhet az automatizált tesztelés DevOps-folyamatok részeként történő integrálásával, beleértve a szinkronizált terhelést és a káosztesztelést is, hogy teljes mértékben ellenőrizze az alkalmazáskód és a mögöttes infrastruktúra állapotát.

  Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: üzembe helyezés és tesztelés.

• Működési megállapítások

  • Összevont munkaterületekkel rendelkezik a megfigyelhetőségi adatokhoz. A globális erőforrások és regionális erőforrások monitorozási adatai egymástól függetlenül vannak tárolva. A központosított megfigyelhetőségi tároló nem ajánlott egyetlen meghibásodási pont elkerülése érdekében. A munkaterületek közötti lekérdezések egységes adatgyűjtőt és egyetlen üvegablakot szolgálnak a műveletekhez.

  • Hozzon létre egy rétegzett állapotmodellt , amely az alkalmazás állapotát forgalmi fénymodellhez rendeli a környezetfüggőség érdekében. Az állapotpontszámokat minden egyes összetevőre kiszámítjuk, majd a felhasználói folyamat szintjén összesítjük, és a fő nem funkcionális követelményekkel, például a teljesítménnyel kombináljuk az alkalmazás állapotának számszerűsítésére szolgáló együtthatóként.

  Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: Állapotmodellezés.

Architektúra

*Töltse le az architektúra Visio-fájlját .

Az architektúra összetevői széles körben kategorizálhatók így. Az Azure-szolgáltatásokkal kapcsolatos termékdokumentációért tekintse meg a kapcsolódó erőforrásokat.

Globális erőforrások

A globális erőforrások hosszú élettartamúak, és megosztják a rendszer élettartamát. Képesek globálisan elérhetővé válnak egy többrégiós üzemi modell kontextusában.

Íme az összetevőkkel kapcsolatos magas szintű szempontok. A döntésekkel kapcsolatos részletes információkért tekintse meg a globális erőforrásokat.

Globális terheléselosztó

A globális terheléselosztó kritikus fontosságú a regionális üzemelő példányok felé irányuló forgalom megbízható irányításához, és bizonyos szintű garanciával rendelkezik a háttérszolgáltatások rendelkezésre állása alapján egy régióban. Emellett ennek az összetevőnek képesnek kell lennie a bejövő forgalom vizsgálatára, például webalkalmazási tűzfalon keresztül.

Az Azure Front Door az összes bejövő ügyfél http(s) forgalmának globális belépési pontjaként szolgál, és a webalkalmazási tűzfal (WAF) képességei a 7. réteg bejövő forgalmának védelmére vonatkoznak. A TCP Anycast használatával optimalizálja az útválasztást a Microsoft gerinchálózatával, és lehetővé teszi a transzparens feladatátvételt csökkentett regionális állapot esetén. Az útválasztás olyan egyéni állapotmintáktól függ, amelyek ellenőrzik a kulcsfontosságú regionális erőforrások összetett hőfokát. Az Azure Front Door egy beépített tartalomkézbesítési hálózatot (CDN) is biztosít a webhely-összetevő statikus eszközeinek gyorsítótárazásához.

Egy másik lehetőség a Traffic Manager, amely egy DNS-alapú 4. rétegbeli terheléselosztó. A hiba azonban nem minden ügyfél számára átlátható, mivel a DNS-propagálásnak meg kell történnie.

Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: Globális forgalomirányítás.

Adatbázis

A számítási feladathoz kapcsolódó összes állapot egy külső adatbázisban, az Azure Cosmos DB for NoSQL-ben van tárolva. Ez a beállítás azért lett kiválasztva, mert rendelkezik a teljesítmény és a megbízhatóság finomhangolásához szükséges funkciókészlettel, mind az ügyfél, mind a kiszolgáló oldalán. Erősen ajánlott, hogy a fiókban engedélyezve legyen a több főkiszolgálós írás.

A fiók minden regionális bélyegre replikálva van, és engedélyezve van a zónaredundancia is. Emellett az automatikus skálázás a tároló szintjén is engedélyezve van, így a tárolók szükség szerint automatikusan skálázják a kiosztott átviteli sebességet.

További információ: Adatplatform a kritikus fontosságú számítási feladatokhoz.

Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: Globálisan elosztott több írási adattár.

Container Registry

Az Azure Container Registry az összes tárolórendszerkép tárolására szolgál. Georeplikációs képességekkel rendelkezik, amelyek lehetővé teszik az erőforrások számára, hogy egyetlen beállításjegyzékként működjenek, és több régiót szolgálnak ki több fő regionális adatbázissal.

Biztonsági intézkedésként csak a szükséges entitásokhoz való hozzáférés engedélyezése és a hozzáférés hitelesítése. A megvalósítás során például a rendszergazdai hozzáférés le van tiltva. A számítási fürt tehát csak Microsoft Entra szerepkör-hozzárendelésekkel tud képeket lekérni.

Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: Tárolóregisztrációs adatbázis.

Regionális erőforrások

A regionális erőforrások üzembehelyezési bélyegző részeként vannak kiépítve egyetlen Azure-régióban. Ezek az erőforrások semmit sem osztanak meg egy másik régió erőforrásaival. Ezek egymástól függetlenül eltávolíthatók vagy replikálhatók további régiókba. Azonban globális erőforrásokat osztanak meg egymással.

Ebben az architektúrában egy egységes üzembehelyezési folyamat bélyeget helyez üzembe ezekkel az erőforrásokkal.

Íme az összetevőkkel kapcsolatos magas szintű szempontok. A döntésekkel kapcsolatos részletes információkért tekintse meg a regionális bélyegforrásokat.

Előtétprogram

Ez az architektúra egyetlenoldalas alkalmazást (SPA) használ, amely kéréseket küld a háttérszolgáltatásoknak. Ennek az az előnye, hogy a webhely élményéhez szükséges számítást a kiszolgálók helyett az ügyfél tölti ki. Az SPA statikus webhelyként üzemel egy Azure Storage-fiókban.

Egy másik lehetőség az Azure Static Web Apps, amely további szempontokat vezet be, például a tanúsítványok közzétételi módját, a globális terheléselosztóhoz való kapcsolódást és egyéb tényezőket.

A statikus tartalmakat általában az ügyfélhez közeli tárolóban gyorsítótárazják egy tartalomkézbesítési hálózat (CDN) használatával, hogy az adatok gyorsan kiszolgálhatók legyenek anélkül, hogy közvetlenül kommunikálnak a háttérkiszolgálókkal. Költséghatékony módszer a megbízhatóság növelésére és a hálózati késés csökkentésére. Ebben az architektúrában az Azure Front Door beépített CDN-képességei a statikus webhelytartalom gyorsítótárazására szolgálnak a peremhálózaton.

Számítási fürt

A háttérbeli számítás egy három mikroszolgáltatásból álló alkalmazást futtat, és állapot nélküli. A tárolók létrehozása tehát megfelelő stratégia az alkalmazás üzemeltetéséhez. Az Azure Kubernetes Service (AKS) azért lett kiválasztva, mert megfelel a legtöbb üzleti követelménynek, és a Kubernetes széles körben elterjedt számos iparágban. Az AKS támogatja a fejlett méretezhetőséget és az üzembe helyezési topológiákat. Az AKS Uptime SLA-szint kifejezetten ajánlott a kritikus fontosságú alkalmazások üzemeltetéséhez, mivel rendelkezésre állási garanciákat biztosít a Kubernetes vezérlősíkjához.

Az Azure más számítási szolgáltatásokat is kínál, például az Azure Functionst és a Azure-alkalmazás-szolgáltatásokat. Ezek a lehetőségek további felügyeleti feladatokat is kivetnek az Azure-ra a rugalmasság és a sűrűség árán.

Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: Container Orchestration és Kubernetes.

Regionális üzenetközvetítő

A teljesítmény optimalizálásához és a maximális terhelés alatti válaszképesség fenntartásához a kialakítás aszinkron üzenetkezelést használ az intenzív rendszerfolyamatok kezeléséhez. Mivel a kérések gyorsan visszakerülnek az előtérbeli API-kba, a kérés üzenetközvetítőben is várólistára kerül. Ezeket az üzeneteket később egy háttérszolgáltatás használja fel, amely például egy adatbázis írási műveletét kezeli.

A teljes bélyeg állapot nélküli, kivéve bizonyos pontokat, például az üzenetközvetítőt. Az adatok rövid ideig várólistára kerülnek a közvetítőben. Az üzenetközvetítőnek legalább egyszer garantálnia kell a kézbesítést. Ez azt jelenti, hogy az üzenetek az üzenetsorba kerülnek, ha a közvetítő elérhetetlenné válik a szolgáltatás visszaállítása után. A fogyasztó felelőssége azonban annak meghatározása, hogy ezek az üzenetek továbbra is feldolgozásra szorulnak-e. Az üzenetsor le lesz ürítve, miután az üzenet feldolgozása és tárolása globális adatbázisban történik.

Ebben a kialakításban az Azure Event Hubs lesz használatban. Egy további Azure Storage-fiók van kiépítve az ellenőrzőpontokhoz. Az Event Hubs az ajánlott választás a nagy átviteli sebességet igénylő használati esetekhez, például az eseménystreameléshez.

További üzenetgaranciát igénylő használati esetekben az Azure Service Bus használata ajánlott. Lehetővé teszi a kétfázisú véglegesítéseket egy ügyféloldali kurzorral, valamint olyan funkciókat, mint a beépített üzenetsor és a deduplikációs képességek.

További információ: Üzenetkezelési szolgáltatások a kritikus fontosságú számítási feladatokhoz.

Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: Lazán összekapcsolt eseményvezérelt architektúra.

Regionális titkos tár

Mindegyik bélyeg saját Azure Key Vault-tárolóval rendelkezik, amely titkos kulcsokat és konfigurációkat tárol. Vannak olyan gyakori titkos kódok, mint például a globális adatbázis kapcsolati sztring, de egyetlen bélyegre, például az Event Hubs kapcsolati sztring is egyedi információk találhatók. A független erőforrások emellett egyetlen meghibásodási pontot is elkerülnek.

Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: Az adatintegritási védelem.

Üzembe helyezési folyamat

A kritikus fontosságú alkalmazások buildelési és kiadási folyamatait teljesen automatizálni kell. Ezért nem kell manuálisan végrehajtani a műveletet. Ez a kialakítás teljesen automatizált folyamatokat mutat be, amelyek minden alkalommal következetesen üzembe helyeznek egy érvényesített bélyeget. Egy másik alternatív módszer az, hogy csak egy meglévő bélyegen helyezik üzembe a gördülő frissítéseket.

Forráskódtár

A GitHubot a forráskezeléshez használják, amely magas rendelkezésre állású Git-alapú platformot biztosít az alkalmazáskód és az infrastruktúrakód együttműködéséhez.

Folyamatos integrációs/folyamatos kézbesítési (CI/CD) folyamatok

Automatizált folyamatokra van szükség egy küldetési számítási feladat létrehozásához, teszteléséhez és üzembe helyezéséhez az előkészítési és éles környezetekben. Az Azure Pipelines a gazdag eszközkészlete alapján van kiválasztva, amely az Azure-t és más felhőplatformokat célozza meg.

Egy másik lehetőség a GitHub Actions a CI/CD-folyamatokhoz. A hozzáadott előny az, hogy a forráskód és a folyamat szétosztható. Az Azure Pipelinest azonban a cd gazdagabb képességei miatt választották ki.

Tekintse meg a jól megtervezett, kritikus fontosságú számítási feladatokat: DevOps-folyamatokat.

Ügynökök létrehozása

Az implementáció a Microsoft által üzemeltetett buildügynököket használja az összetettség és a felügyeleti többletterhelés csökkentésére. A saját üzemeltetésű ügynökök olyan helyzetekben használhatók, amelyekhez meg kell edzett biztonsági helyzetre van szükség.

Megfigyelhető erőforrások

Az alkalmazásból és az infrastruktúrából származó operatív adatoknak rendelkezésre kell állniuk a hatékony működés és a megbízhatóság maximalizálása érdekében. Ez a referencia alapkonfigurációt biztosít egy alkalmazás holisztikus megfigyelhetőségének eléréséhez.

Egyesített adatgyűjtő

• Az Azure Log Analytics egységes fogadóként használható az összes alkalmazás- és infrastruktúra-összetevő naplóinak és metrikáinak tárolására.
• Azure-alkalmazás Elemzések alkalmazásteljesítmény-kezelési (APM) eszközként használják az összes alkalmazásmonitorozási adat gyűjtésére és közvetlenül a Log Analyticsben való tárolására.

A globális erőforrások és regionális erőforrások monitorozási adatait egymástól függetlenül kell tárolni. Egyetlen, központosított megfigyelhetőségi tároló használata nem ajánlott egyetlen meghibásodási pont elkerülése érdekében. A munkaterületek közötti lekérdezéssel egyetlen üvegpanel érhető el.

Ebben az architektúrában egy régió erőforrásainak monitorozásának függetlennek kell lennie a bélyegtől, mert ha lebont egy bélyeget, akkor is meg kell őriznie a megfigyelhetőséget. Minden regionális bélyeg saját dedikált alkalmazás-Elemzések és Log Analytics-munkaterülettel rendelkezik. Az erőforrások régiónként vannak kiépítve, de túllépik a bélyegeket.

Hasonlóképpen, a megosztott szolgáltatások, például az Azure Front Door, az Azure Cosmos DB és a Container Registry adatai a Log Analytics-munkaterület dedikált példányában vannak tárolva.

Adatarchiválás és -elemzés

Az aktív műveletekhez nem szükséges működési adatokat a Log Analyticsből az Azure Storage-fiókokba exportálja adatmegőrzési célból, és elemzési forrást biztosít az AIOps számára, amely az alkalmazásállapot-modell és az üzemeltetési eljárások optimalizálására alkalmazható.

Tekintse meg a jól megtervezett kritikus fontosságú számítási feladatokat: Prediktív műveletek és AI-műveletek.

Kérelem- és processzorfolyamatok

Ez a kép a referencia-implementáció kérését és háttérprocesszor-folyamatát mutatja.

A folyamat leírása a következő szakaszokban található.

Webhelykérési folyamat

1. A rendszer a webes felhasználói felületre vonatkozó kérelmet küld egy globális terheléselosztónak. Ebben az architektúrában a globális terheléselosztó az Azure Front Door.

2. A WAF-szabályok kiértékelése történik. A WAF-szabályok pozitívan befolyásolják a rendszer megbízhatóságát azáltal, hogy számos támadás ellen védenek, például a helyek közötti szkriptelés (XSS) és az SQL-injektálás ellen. Az Azure Front Door hibát ad vissza a kérelmezőnek, ha egy WAF-szabályt megsértenek, és a feldolgozás leáll. Ha nincsenek waf-szabályok megsértve, az Azure Front Door folytatja a feldolgozást.

3. Az Azure Front Door útválasztási szabályokkal határozza meg, hogy melyik háttérkészletnek továbbít egy kérést. A kérések útválasztási szabályhoz való egyeztetésének menete. Ebben a referencia-implementációban az útválasztási szabályok lehetővé teszik az Azure Front Door számára a felhasználói felület és a frontend API-kérések különböző háttérerőforrásokhoz való átirányítását. Ebben az esetben a "/*" minta megegyezik a felhasználói felület útválasztási szabályával. Ez a szabály átirányítja a kérést egy háttérkészletre, amely az egyoldalas alkalmazást (SPA) üzemeltető statikus webhelyeket tartalmazó tárfiókokat tartalmazza. Az Azure Front Door a készlet háttérrendszereihez rendelt prioritást és súlyt használja a háttérrendszer kiválasztásához a kérés irányításához. Forgalomirányítási módszerek a forrás felé. Az Azure Front Door állapottesztekkel biztosítja, hogy a kérések ne legyenek kifogástalan állapotú háttérrendszerekhez irányítva. Az SPA-t a kiválasztott tárfiókból, statikus webhelytel szolgáljuk fel.

   Feljegyzés

   Az Azure Front Door Classic háttérkészleteit és háttérrendszereit az Azure Front Door Standard vagy prémium szintű forráscsoportoknak és forráscsoportoknak nevezzük.

4. Az SPA API-hívást indít az Azure Front Door előtérbeli gazdagépének. Az API-kérés URL-címe "/api/*".

Előtérbeli API-kérések folyamata

5. A WAF-szabályok kiértékelése a 2. lépéshez hasonlóan történik.

6. Az Azure Front Door megfelel az API útválasztási szabályának a "/api/*" minta szerinti kérésnek. Az API útválasztási szabálya átirányítja a kérést egy háttérkészletbe, amely tartalmazza az NGINX bejövőforgalom-vezérlők nyilvános IP-címeit, amelyek tudják, hogyan irányíthatók a kérések a megfelelő szolgáltatáshoz az Azure Kubernetes Service-ben (AKS). A korábbiakhoz hasonlóan az Azure Front Door a háttérrendszerekhez rendelt prioritást és súlyt használja a megfelelő NGINX bejövőforgalom-vezérlő háttérrendszer kiválasztásához.

7. GET-kérelmek esetén az előtérbeli API olvasási műveleteket hajt végre egy adatbázisban. Ebben a referencia-implementációban az adatbázis egy globális Azure Cosmos DB-példány. Az Azure Cosmos DB számos olyan funkcióval rendelkezik, amelyek kiváló választást kínálnak egy kritikus fontosságú számítási feladathoz, beleértve a több írási régiók egyszerű konfigurálásának lehetőségét is, lehetővé téve az olvasások és írások másodlagos régiókba történő automatikus feladatátvételét. Az API az újrapróbálkozással konfigurált ügyfél SDK-t használja az Azure Cosmos DB-vel való kommunikációhoz. Az SDK meghatározza az elérhető Azure Cosmos DB-régiók optimális sorrendjét az ApplicationRegion paraméter alapján.

8. POST vagy PUT kérelmek esetén a Frontend API írást végez egy üzenetközvetítőnek. A referencia-implementációban az üzenetközvetítő az Azure Event Hubs. Másik lehetőségként a Service Bust is választhatja. A kezelő később felolvassa az üzenetközvetítő üzeneteit, és elvégzi a szükséges írásokat az Azure Cosmos DB-be. Az API az ügyféloldali SDK-t használja az írások végrehajtásához. Az ügyfél újrapróbálkozáshoz konfigurálható.

Háttérprocesszor-folyamat

9. A háttérprocesszorok feldolgozzák az üzenetközvetítő üzeneteit. A háttérprocesszorok az ügyfél SDK-val végzik az olvasást. Az ügyfél újrapróbálkozáshoz konfigurálható.

10. A háttérprocesszorok elvégzik a megfelelő írási műveleteket a globális Azure Cosmos DB-példányon. A háttérprocesszorok az újrapróbálkozással konfigurált ügyfél SDK-t használják az Azure Cosmos DB-hez való csatlakozáshoz. Az ügyfél előnyben részesített régiólistája több régióval is konfigurálható. Ebben az esetben, ha egy írás sikertelen, az újrapróbálkozás a következő előnyben részesített régióban történik.

Tervezési területek

Javasoljuk, hogy tekintse át ezeket a tervezési területeket a kritikus fontosságú architektúra meghatározásakor javasolt és ajánlott eljárásokhoz.

** Az architektúrára jellemző tervezési területekre vonatkozó szempontokat jelzi.

Kapcsolódó erőforrások

Az architektúrában használt Azure-szolgáltatások termékdokumentációját az alábbi cikkekben találja.

• Azure Front Door
• Azure Cosmos DB
• Azure Container Registry
• Azure Log Analytics
• Azure Key Vault
• Azure Service Bus
• Azure Kubernetes Service
• Azure Application Insights
• Azure-eseményközpontok
• Azure Blob Storage

Az architektúra üzembe helyezése

A referencia-implementáció üzembe helyezése a megfontolt erőforrások teljes körű megismeréséhez, beleértve a kritikus fontosságú környezetekben való üzembe helyezés módját is. Egy üzembe helyezési útmutatót tartalmaz, amely az Azure-ban a kritikus fontosságú alkalmazások fejlesztésének megoldásorientált megközelítését mutatja be.

Következő lépések

Ha ki szeretné terjeszteni az alaparchitektúrát a bejövő és kimenő forgalom hálózati vezérlőivel, tekintse meg ezt az architektúrát.