Kritikus fontosságú alapkonfiguráció az App Service-ben

Azure App Service

Azure Front Door

Azure által felügyelt Redis

Azure App Configuration

Azure Monitor

Ez a cikk bemutatja, hogyan helyezhet üzembe kritikus fontosságú webalkalmazásokat az Azure App Service használatával. Az architektúra kiindulópontként a megbízható webalkalmazás-mintát használja. Ezt az architektúrát akkor használja, ha régi számítási feladattal rendelkezik, és szolgáltatásként (PaaS) szeretne platformszolgáltatást bevezetni.

.NET- megbízható webalkalmazás-mintája útmutatást nyújt a felhőbe áthelyezett webalkalmazások frissítéséhez vagy visszaírásához. Ez a megközelítés segít minimalizálni a szükséges kódmódosításokat, és megcélozza a 99,9-es szolgáltatási szintű célkitűzést (SLO)%. A kritikus fontosságú számítási feladatok magas megbízhatósági és rendelkezésre állási követelményekkel rendelkeznek. A 99,95%, 99,99%vagy újabb SLO eléréséhez kiegészítő, kritikus fontosságú tervezési mintákat és működési szigort kell alkalmaznia. Ez a cikk a kulcsfontosságú műszaki területeket, valamint a kritikus fontosságú tervezési eljárások bevezetésének és megvalósításának módját ismerteti.

Jegyzet

A cikk útmutatása a Well-Architected Keretrendszer kritikus fontosságú számítási feladatok sorozatának tervezési módszertanán és ajánlott eljárásain alapul.

A következő szakaszok a következőket ismertetik:

Tekintse át a meglévő számítási feladatokat, hogy megismerje annak összetevőit, a felhasználói és rendszerfolyamatokat, valamint a rendelkezésre állási és méretezhetőségi követelményeket.
skálázási egységek architektúrájának fejlesztése és implementálása a végpontok közötti skálázhatóság optimalizálásához a rekeszezéssel, valamint a kapacitás hozzáadásának és eltávolításának folyamatának szabványosításához.
Állapot nélküli, rövid élettartamú skálázási egységek vagy üzembehelyezési bélyegek implementálása a méretezhetőség és a leállási idő nélküli üzemelő példányok engedélyezéséhez.
Annak meghatározása, hogy feloszthatja-e a számítási feladatot összetevőkre a méretezhetőségre való felkészüléshez. A folyamatok méretezhetőségéhez és leválasztásához egyedi összetevőkre van szükség.
Felkészülhet globális terjesztési egy számítási feladat üzembe helyezésével több Azure-régióban az ügyfélhez való közelség javítása és a lehetséges regionális kimaradásokra való felkészülés érdekében.
Az összetevők leválasztása és egy eseményvezérelt architektúra implementálása.

Építészet

Az alábbi ábra a megbízható webalkalmazás-mintáraalkalmazza az előző szempontokat.

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

A piros mező egy skálázási egységet jelöl, amely a skálázási szolgáltatásokat együtt skálázza. A hatékony skálázáshoz optimalizálja az egyes szolgáltatások méretét, termékváltozatát és az elérhető IP-címeket. Az Azure App Configuration által kiszolgált kérelmek maximális száma például korrelál a skálázási egység által biztosított másodpercenkénti kérelmek számával. Ha több kapacitást ad hozzá egy régióhoz, több különálló méretezési egységet is hozzá kell adnia.

Ezek az egyes méretezési egységek nem függenek egymástól, és csak az egyes méretezési egységen kívüli megosztott szolgáltatásokkal kommunikálnak. Ezeket a méretezési egységeket egy kék-zöld üzembe helyezési használhatja új méretezési egységek üzembe helyezésével, a megfelelő működés ellenőrzésével és az éles forgalom fokozatos áthelyezésével.

Ebben a forgatókönyvben a méretezési egységek ideiglenesek, ami javítja a bevezetési folyamatokat, és skálázhatóságot biztosít a régiókon belül és régiók között. Ha ezt a módszert alkalmazza, az állandó rekordrendszer adatait csak az adatbázisban tárolja, mert az adatbázis replikálódik a másodlagos régióba.

A skálázási egységen belül vagy mellett az Azure Managed Redis használatával olyan kiegészítő alkalmazásállapotokat tárolhat, mint a gyorsítótáradatok, a munkamenet állapota, a sebességkorlát számlálói, a funkciójelzők és a koordinációs metaadatok a skálázási egységen belül. Az aktív georeplikálás lehetővé teszi, hogy a Redis-adatok aszinkron módon replikáljanak régiók között a rugalmasság javítása és a helyreállítási idő célkitűzéseinek csökkentése érdekében a regionális feladatátvételi forgatókönyvek során. Ez a képesség általában olyan kiegészítő állapotokra vonatkozik, amelyeknek meg kell túlélniük a regionális kimaradásokat, míg a teljesen újraépíthető gyorsítótáradatok helyiek maradnak egy skálázási egységben.

A skálázási egységek cseréjekor vagy kivonásakor az alkalmazásoknak transzparens módon kell tudniuk újracsatlakozni a Redis-végponthoz. Gyorsítótárazott adatok tervezése az alábbi módok valamelyikével:

Újraépíthető állapot, amely a rendelkezésre állás befolyásolása nélkül újra feltölthető gyorsítótár-bejegyzéseket tartalmaz
Tartós kiegészítő állapot, amelyet a gyorsítótár rendelkezésre állása, megőrzése és georeplikációs funkciói védenek

Az Application Insights ki van zárva a méretezési egységből. Kizárhatja az adatokat tároló vagy figyelő szolgáltatásokat. Különítse el őket saját erőforráscsoportjukba saját életciklusukkal.

Ha lecserél egy skálázási egységet, vagy újat helyez üzembe, őrizze meg az előzményadatokat, és használjon egy példányt minden régióhoz.

További információ: Kritikus fontosságú számítási feladatok alkalmazástervezése az Azure.

Összetevők

Ez az architektúra a következő összetevőket használja.

Az App Service egy teljes körűen felügyelt platform webalkalmazások létrehozására, üzembe helyezésére és skálázására. Ebben az architektúrában az App Service az alkalmazás-üzemeltetési platformként szolgál az egyes méretezési egységeken belül. A magas rendelkezésre állási és méretezhetőségi követelményekkel rendelkező, kritikus fontosságú webalkalmazások számítási infrastruktúrája.
Az Azure Managed Redis egy Redis Enterprise-alapú, teljes mértékben felügyelt, memórián belüli adatplatform. Ebben az architektúrában az Azure Managed Redis alacsony késésű hozzáférést biztosít a kiegészítő alkalmazásállapothoz az egyes méretezési egységeken belül vagy mellett, például gyorsítótárazást, munkamenet-adatokat, sebességkorlátozást, funkciójelzőket és elosztott koordinációt. Támogatja a fürtözést, a rendelkezésre állási zónákat, az opcionális adatmegőrzést és az aktív georeplikálást, így alkalmas a kritikus fontosságú számítási feladatokhoz.
Az alkalmazáskonfiguráció egy olyan szolgáltatás, amely központilag kezeli az alkalmazásbeállításokat és a funkciójelzőket. Ebben az architektúrában az Alkalmazáskonfiguráció a méretezési egységen belül tárolja az alkalmazás konfigurációs beállításait. Kapacitása közvetlenül korrelál a másodpercenkénti kérelmek számával, amelyeket az egyes méretezési egységek képesek kezelni.
Az Azure SQL az SQL Server adatbázismotorra épülő felügyelt SQL-adatbázis-szolgáltatások gyűjteménye. Ebben az architektúrában az Azure SQL az állandó adatokat tároló háttéradatbázis, amely másodlagos régiókba replikálódik.
Az Application Insights egy alkalmazásteljesítmény-kezelési szolgáltatás, amely monitorozási és elemzési képességeket biztosít. Ebben az architektúrában az Application Insights telemetriát gyűjt az alkalmazásból. A skálázási egységekből ki van zárva, hogy fenntartsa saját életciklusát az előzményadatok megőrzéséhez és a keresztbélyegek monitorozásához.

Alternatívák

A megbízható webalkalmazás-mintában a következőkre van lehetőség:

Az App Service helyett használja az Azure Kubernetes Service-t (AKS). Ez a lehetőség jól működik olyan összetett számítási feladatok esetében, amelyek nagy számú mikroszolgáltatással rendelkeznek. Az AKS nagyobb ellenőrzést biztosít a mögöttes infrastruktúra felett, és lehetővé teszi az összetett többtényezős beállításokat.
A számítási feladat tárolóba helyezése. Az App Service támogatja a tárolók használatát, de ebben a példában a számítási feladat nincs tárolóba rendezve. Tárolók használatával növelheti a megbízhatóságot és a hordozhatóságot.

További információ: Alkalmazásplatformokkal kapcsolatos szempontok az Azure-kritikus fontosságú számítási feladataihoz.

A magas rendelkezésre állás szempontjai

A választott alkalmazásplatformtól függetlenül javasoljuk, hogy rangsorolja a rendelkezésre állási zónák használatát az éles számítási feladatokhoz.

rendelkezésre állási csoportok több tartalék és frissítési tartományra kiterjedő központi telepítéseket egy adatközpontban. rendelkezésre állási zónák az üzembe helyezéseket az Azure-régióban lévő egyes adatközpontokban. A rendelkezésre állási zónákat gyakran rangsorolja a rendszer, de a használt stratégia a számítási feladattól függ. Például a késésre érzékeny vagy a csevegőfeladatok előnyére válhat a rendelkezésre állási csoportok rangsorolása. Ha elosztja a számítási feladatot a rendelkezésre állási zónák között, az növelheti a késést és a zónák közötti forgalom költségeit. Rendelkezésre állási zónák használatakor győződjön meg arról, hogy a skálázási egység összes szolgáltatása támogatja őket. A megbízható webalkalmazás-minta összes szolgáltatása támogatja a rendelkezésre állási zónákat.

Az adatplatform kiválasztása

A választott adatplatform hatással van az általános számítási feladatok architektúrájára, különösen az aktív-aktív vagy aktív-passzív üzemi modellek platformjának támogatására. A megbízható webalkalmazás-mintában az Azure SQL szolgál az elsődleges relációs adatplatformként. Az Azure SQL natív módon nem támogatja az olyan aktív-aktív kiépítéseket, amelyekben egyidejű írás történik több régióban. Ennek eredményeképpen ez a minta általában egy aktív-passzív stratégiát követ az adatbázisrétegen. Az alkalmazásszinten részleges aktív-aktív megközelítés lehetséges, ha írásvédett replikákat helyez üzembe több régióban, miközben az összes írási műveletet egyetlen elsődleges régióba irányítja.

Összetett architektúrákban több adatbázis is gyakori, például olyan mikroszolgáltatás-architektúrákban, amelyek mindegyik szolgáltatáshoz rendelkeznek adatbázissal. A több adatbázis lehetővé teszi egy több elsődleges írási adatbázis, például az Azure Cosmos DB bevezetését, amely javítja a magas rendelkezésre állást és az alacsony késést. A régiók közötti késés korlátozásokat okozhat. Fontos figyelembe venni a nem funkcionális követelményeket és tényezőket, például a konzisztenciát, az működőképességet, a költségeket és az összetettséget. Lehetővé teszi az egyes szolgáltatások számára, hogy külön adattárakat és speciális adattechnológiákat használjanak az egyedi követelményeknek való megfelelés érdekében. További információ: Adatplatformokkal kapcsolatos szempontok az Azure-kritikus fontosságú számítási feladataihoz.

Gyorsítótárazási platform

A nagy írási terheltségű vagy nagyon alacsony írási késést igénylő munkafolyamatok esetében a kérelmi útvonalon közvetlenül a relációs adatbázisba történő írás méretezhetőségi vagy késési szűk keresztmetszetet okozhat. Ezekben a forgatókönyvekben az Azure Managed Redis alkalmazásszintű adatplatformként jelenik meg az írási átviteli sebesség felgyorsítása és a rekordrendszer adatbázisának védelme érdekében.

Ha ezt a megközelítést választja, az Azure Managed Redis a kiválasztott adattartományok kezdeti írási célpontjaként szolgál, míg az adatok aszinkron módon maradnak az Azure SQL-ben egy visszaírási vagy visszaírási minta használatával. Ez a kialakítás lehetővé teszi, hogy az alkalmazás elnyelje az alacsony késésű írási sorozatokat, miközben az Azure SQL-t mint mérvadó rekordrendszert tartja fenn. A tipikus használati esetek közé tartoznak a munkamenet-frissítések, számlálók, sebességkorlátozás, állapotváltások, telemetriai összesítések és egyéb olyan adatok, amelyek képesek elviselni a végleges konzisztenciát.

Az Azure Managed Redis támogatja az aktív georeplikálást is, amellyel a Redis által támogatott adatok aszinkron módon replikálhatók régiók között. Szelektív alkalmazás esetén az aktív georeplikáció lehetővé teszi, hogy az alkalmazásállapot adott kategóriái aktív-aktív alkalmazástervekben vegyenek részt, még akkor is, ha az elsődleges relációs adatbázis aktív-passzív marad. Ez a képesség jelentősen csökkentheti a regionális feladatátvételi forgatókönyvekben a KPO-kat.

A kritikus fontosságú számítási feladatok a mögöttes gyorsítótárazás mellett gyakran előzetes vagy előrehozott gyorsítótárazást használnak az adatok proaktív betöltésére az Azure Managed Redisbe az előre jelzett hozzáférési minták, ütemezett feladatok vagy változási események alapján. Az előbetöltés csökkenti az új skálázási egységek hidegindítási késését, és javítja a végkésleltetést a forgalom kiugrása során, ami különösen fontos, amikor a skálázási egységek átmenetiek.

Állapotmodell definiálása

A több adatközpontra és földrajzi régióra kiterjedő összetett többtényezős számítási feladatokban meg kell határoznia egy állapotmodellt.

Állapotmodell definiálása:

Felhasználói és rendszerfolyamatok definiálása
A szolgáltatások közötti függőségek meghatározása és értelmezése
Annak megismerése, hogy a szolgáltatáskimaradások vagy a teljesítménycsökkenés milyen hatással lehet a teljes számítási feladatra
Az ügyfélélmény monitorozása és vizualizációja a megfelelő monitorozás és a manuális és automatizált műveletek javítása érdekében.

Az előző diagram azt mutatja be, hogy egy adott összetevő ( például az Alkalmazáskonfiguráció) kimaradása vagy romlása hogyan okozhatja az ügyfél potenciális teljesítménycsökkenését. Ha skálázási egységekre bontja az összetevőket, az lehetővé teszi, hogy ne küldjön forgalmat az alkalmazás érintett részére, például egy érintett skálázási egységre vagy a teljes régióra.

A skálázási egységek állapotának meghatározására szolgáló kritériumokat az állapotmodell határozza meg. Ez a modell ezután csatlakozik a skálázási egység állapotvégponthoz, amely lehetővé teszi a globális terheléselosztó számára, hogy lekérdezhesse a skálázási egység állapotát, és ezeket az információkat használhassa útválasztási döntésekhez.

További információ: Kritikus fontosságú számítási feladatok állapotmodellezése és megfigyelhetősége az Azure.

Biztonság és hálózatkezelés

A kritikus fontosságú számítási feladatokra szigorú hálózatkezelési és biztonsági követelmények vonatkoznak. Különösen a helyszíni környezetből migrált számítási feladatokra alkalmazza a szorgalmat, mert nem minden helyszíni biztonsági gyakorlat fordítható felhőkörnyezetre. Javasoljuk, hogy az alkalmazás migrálása során újraértékelje a biztonsági követelményeket.

Az identitás gyakran a natív felhőbeli minták elsődleges biztonsági szegélye. A nagyvállalati ügyfeleknek nagyobb biztonsági intézkedésekre lehet szükségük. A hálózati biztonsági követelmények kielégítése érdekében az Azure PaaS-szolgáltatások az Azure Private Link használatával valósíthatják meg a hálózatot biztonsági szegélyként. A Private Link segítségével biztosítható, hogy a szolgáltatások csak egy virtuális hálózaton belülről legyenek elérhetők. Ezután minden szolgáltatás csak privát végpontokon keresztül érhető el. Az alábbi ábra azt mutatja be, hogy az egyetlen nyilvános internetes végpont az Azure Front Door.

Ahhoz, hogy a megbízható webalkalmazás-minta biztonsági szegélyként állítsa be a hálózatot, a következőt kell használnia:

Private Link az azt támogató összes szolgáltatáshoz.
Az Azure Front Door Premium az egyetlen internetkapcsolattal rendelkező nyilvános végpont.
Ugrómezők az Azure Bastionon keresztüli szolgáltatások eléréséhez.
Saját üzemeltetésű buildügynökök, amelyek hozzáférhetnek a szolgáltatásokhoz.

A kritikus fontosságú alkalmazások egy másik gyakori hálózati követelménye a kimenő forgalom korlátozása az adatkiszivárgás megakadályozása érdekében. Korlátozza a kimenő forgalmat úgy, hogy az alhálózatot elhagyó összes forgalmat egy tűzfaleszközön keresztül irányítja át, ahol a forgalom szűrve van, mielőtt továbblépne a következő ugrásra.

Üzembe helyezés és tesztelés

A hibás kiadások vagy emberi hibák által okozott állásidő problémát jelenthet olyan számítási feladatok esetében, amelyeknek mindig rendelkezésre kell állniuk. Az alábbiakban néhány fontos területet érdemes figyelembe venni:

Nulla állásidős üzemelő példányok
Rövid élettartamú kék-zöld környezetek
Az egyes és csoportosított összetevők életciklus-elemzése
Folyamatos ellenőrzés

nulla állásidős üzembe helyezési kulcsfontosságúak a kritikus fontosságú számítási feladatokhoz. Azoknak a számítási feladatoknak, amelyeknek mindig működőképesnek kell lenniük, nem rendelkezhetnek karbantartási időszakkal az újabb verziók bevezetéséhez. A korlátozás megkerüléséhez az Azure kritikus fontosságú architektúrája a nulla állásidős üzembe helyezési mintát követi. A módosítások olyan új méretezési egységekként vagy bélyegekként jelennek meg, amelyeket a forgalom növekményes irányítása előtt tesztelnek. Miután az összes forgalmat az új bélyegre irányítják, a régi bélyegek le lesznek tiltva és eltávolítva.

További információ: Kritikus fontosságú számítási feladatok üzembe helyezése és tesztelése az Azure.

Következő lépések

Visszacsatolás

Hasznos volt ez az oldal?