Az Azure Spring Apps üzembe helyezése több régióban

Ez a referenciaarchitektúra egy olyan megközelítést ír le, amely több Azure Spring Apps-példányt futtat régiók között egy aktív-aktív konfigurációban.

Ez a kialakítás az Azure Spring Apps alaparchitektúrájára épül. Az alapkonfiguráció egy Java Spring Boot-alkalmazást helyez üzembe több rendelkezésre állási zónában egyetlen régión belül. A több zóna az alkalmazás számítási feladatait különböző helyekre osztva képes eltűrni a helyi hibákat az Azure-régióban.

Ha azonban a teljes régióban kimaradás lép fel, az alapterv elérhetetlenné válik a felhasználó számára. Ennek a tervnek az a célja, hogy magas rendelkezésre állást hozzon létre, amely képes ellenállni a regionális kimaradásoknak.

Ez az architektúra a következő célok eléréséhez hasznos:

• Az alkalmazás általános rugalmasságának és szolgáltatásiszint-célkitűzésének (SLO) növelése.
• Globális elérés engedélyezése az alkalmazáshoz.
• Közelebb hozza a számítási feladatot a végfelhasználóhoz, és a lehető legkisebb késést érje el.
• Használjon másodlagos régiót feladatátvételi helyként az elsődleges régióhoz, és válasszon aktív-passzív kialakítást.

Az alkalmazás rugalmasságának és megbízhatóságának növelése érdekében az alkalmazást több régióban is üzembe helyezheti. Ehhez a kialakításhoz egy globális útválasztóra van szüksége az alkalmazásokhoz érkező kérelmek régiók közötti terheléselosztásához. Az architektúra globális útválasztója más célokkal is foglalkozik.

A többrégiós beállítás legnagyobb kihívása az alkalmazás adatainak replikálása több régió között. Ez a probléma nem érinti a többzónás beállítást. Az Azure rendelkezésre állási zónákat nagy teljesítményű hálózat köti össze 2 ms-nál kisebb utazási késéssel. Ez a késési időszak a legtöbb alkalmazás számára elegendő.

Architektúra

Az alábbi ábra a megközelítés architektúrájának szemléltetését mutatja be:

Összetevők

Az architektúra összetevői megegyeznek az alaparchitektúrával. Az alábbi lista csak az alaparchitektúra módosításait emeli ki. Az Azure-szolgáltatásokkal kapcsolatos termékdokumentációért tekintse meg a Kapcsolódó erőforrások szakaszt.

• Az Azure Front Door globális terheléselosztóként működik. Ezt a szolgáltatást azért használják, mert képes magasabb rendelkezésre állást biztosítani alacsonyabb késéssel, nagyobb skálázással és gyorsítótárazással a peremhálózaton.

Munkafolyamat

A referenciaarchitektúra a következő munkafolyamatot valósítja meg:

1. A felhasználó kérést küld az alkalmazás HTTP-állomásának nevére, például www.contoso.com. Az Azure DNS feloldja a gazdagép nevének kérését az Azure Front Door felé.

2. Az Azure Front Door különböző terheléselosztási konfigurációkkal továbbítja a bejövő kéréseket Azure-alkalmazás átjáró nyilvános végpontjára minden régióban. Az Application Gateway-példányok ugyanazzal az egyéni tartománynévvel és TLS-tanúsítványnévvel vannak konfigurálva, mint az Azure Front Door.

3. Az Integrált Azure Web Application Firewalllal rendelkező Application Gateway ellenőrzi a kérést. A webalkalmazási tűzfal csak a megadott Azure Front Door-profilból engedélyezi a bejövő kéréseket.

4. Az Application Gateway továbbítja az engedélyezett forgalmat a terheléselosztó IP-címére a kiépített Spring Apps-példányban.

5. A belső terheléselosztó csak az Application Gatewayről a háttérszolgáltatásokra irányítja a forgalmat. Ezeket a szolgáltatásokat a Spring Apps-példány üzemelteti minden régióban egy virtuális hálózaton belül.

6. A kérés feldolgozása során az alkalmazás kommunikál a virtuális hálózaton belüli többi Azure-szolgáltatással. Ilyen például az azure Key Vaulttal kommunikáló alkalmazás a titkos kódok és az állapot tárolására szolgáló adatbázis esetében.

Globális terjesztés

Ha magas rendelkezésre állásra tervez, beállíthatja ezt az architektúrát aktív-aktív, aktív-passzív, meleg készenléti, vagy aktív-passzív, hideg készenléti módban.

A választás az alkalmazás rendelkezésre állási követelményeitől függ. Ez az architektúra két régióban használ aktív-aktív üzembe helyezést, mivel a mintaszervezet magas üzemidejű SLA-val (szolgáltatásiszint-szerződéssel) szeretne globális jelenléttel rendelkezni. Ha kritikus fontosságú alkalmazásokat futtat, és magasabb rendelkezésre állást szeretne, több régiót kell használnia.

Aktív-aktív

Aktív-aktív módban az összes régió egyszerre dolgozza fel a kéréseket. Az aktív-aktív mód legnagyobb kihívása az adatszinkronizálás fenntartása a régiók között. Ez a mód költséges módszer, mivel szinte minden összetevőért kétszer kell fizetnie.

Aktív-passzív, készenléti állapotban

Aktív-passzív módban, gyakori készenléti állapotban a másodlagos régió nem kap kéréseket az Azure Front Doortól, amíg az elsődleges régió aktív. Győződjön meg arról, hogy az alkalmazás adatait az elsődlegesről a másodlagos régióba replikálja. Ha hiba történik az elsődleges régióban, módosítania kell a háttéradatbázisok szerepköreit, és át kell adnia az Azure Front Dooron keresztül a másodlagos régióba történő összes forgalmat.

Aktív-passzív módban a feladatátvétel várhatóan eltarthat egy ideig, ami megkönnyíti az összes adat szinkronizálását. A gyakori készenléti állapotú aktív-passzív mód azonban ugyanolyan költséges, mint az aktív-aktív mód használata.

Aktív-passzív hideg készenléti állapottal

A hideg készenléti állapotú aktív-passzív módban az elsődleges régió rendelkezik az összes erőforrással, és kiszolgálja a forgalmat. A másodlagos régió kevesebb összetevővel vagy alacsonyabb számítási erőforrásokkal rendelkező összetevővel rendelkezhet. A technológiai lehetőségek attól függenek, hogy az üzleti követelményeknek megfelelően mennyi állásidő elfogadható. A másodlagos régió beállításának mértéke a költségeket is befolyásolja. Győződjön meg arról, hogy legalább az alkalmazásadatok megtalálhatók a másodlagos régióban.

Ahogy már említettük, az aktív-passzív mód magában foglalja a feladatátvételt is, így egyszerűbb az összes adat szinkronizálása. A legköltséghatékonyabb módszer a hideg készenléti állapotú aktív-passzív mód, mivel nem helyezi üzembe az összes erőforrást mindkét régióban.

Ha a teljes megoldásbeállítás sablonokat használ, egyszerűen üzembe helyezhet egy hideg készenléti másodlagos régiót az erőforrások igény szerinti létrehozásával. Terraform-, Bicep- vagy Azure Resource Manager-sablonokat használhat, és automatizálhatja az infrastruktúra beállítását egy folyamatos integrációs/folyamatos üzembe helyezési (CI/CD) folyamatban. A másodlagos régió újratelepítésével rendszeresen tesztelnie kell a konfigurációt, hogy a sablonok vészhelyzetben üzembe helyezhetők legyenek.

Az üzembehelyezési bélyegek mintája azért ajánlott, mert egy alkalmazás vagy összetevő több független példánya telepíthető egyetlen sablonból több régióba.

Mód összehasonlítása

Az alábbi táblázat összefoglalja az egyes módok adatainak szinkronizálásához szükséges erőfeszítéseket, és összehasonlítja a költségeket.

Útválasztás régiók között

Ez a referenciaarchitektúra földrajzi csomópontokat (Geodes) használ, ahol bármely régió bármilyen kérést kiszolgálhat.

Az Azure Front Door a két üzembehelyezési régió között egyenlő útválasztással van konfigurálva. Az Azure Front Door más forgalomirányítási módszereket is biztosít a forráshoz. Ha az ügyfeleket a legközelebbi forráshoz szeretné irányítani, a késésalapú útválasztás a legértelmesebb. Ha aktív-passzív megoldást tervez, a prioritásalapú útválasztás megfelelőbb.

A referenciaarchitektúra-példa egy egyenlő súlyozású terheléselosztási szabályt használ a két régió között. Az Azure Front Door a következőkkel van konfigurálva:

• Egy egyéni tartomány és egy átviteli rétegbeli biztonsági (TLS) tanúsítvány ugyanazzal a névvel, mint az alkalmazás gazdagépének neve, például www.contoso.com.

• Régiónként egy forrás, ahol az alkalmazás üzembe van helyezve, ahol minden forrás egy Azure-alkalmazás átjárópéldány.

Erőforráscsoport elrendezése

Az Azure-erőforráscsoportok használatával egyetlen gyűjteményként kezelheti az egyes régiókban üzembe helyezett erőforrásokat. Fontolja meg az elsődleges régió, a másodlagos régió és az Azure Front Door külön erőforráscsoportokba helyezését az alábbi ábrán látható módon:

Az ábrán az erőforráscsoportok alábbi konfigurációja látható:

• Az Azure Front Door az erőforráscsoportban Application-shared van üzembe helyezve.
• A nyugat-európai régióban (weu) üzemeltetett összes erőforrás az Application-weu erőforráscsoportban van üzembe helyezve.
• Az USA keleti régiójában (eus) üzemeltetett erőforrások az Application-eus erőforráscsoportban találhatók.
• A Japán keleti régiójában (jae) üzemeltetett erőforrások az Application-jae erőforráscsoportban találhatók.

Az ugyanabban az erőforráscsoportban lévő erőforrások közös életciklussal rendelkeznek, és könnyen létrehozhatók és törölhetők együtt. Minden régió saját erőforráskészlettel rendelkezik egy dedikált erőforráscsoportban, amely a régiónév alapján egy elnevezési konvenciót követ. Az Azure Front Door a saját erőforráscsoportjában található, mert akkor is léteznie kell, ha más régiókat adnak hozzá vagy távolítanak el.

Fordított proxy beállítása

Az Azure Front Door globális terheléselosztást végez a régiók között. Ez a fordított proxy segít elosztani a forgalmat, ha egy számítási feladatot több régióban helyez üzembe. Alternatív megoldásként használhatja az Azure Traffic Managert. A Traffic Manager egy DNS-alapú forgalom terheléselosztó, amely csak a tartomány szintjén egyensúlyozza a terhelést.

Az Azure Front Door integrált tartalomkézbesítési hálózatokkal (CDN-ekkel) rendelkezik, amelyek a Microsoft globális peremhálózatáról szolgáltatnak tartalmakat a világszerte elosztott jelenléti pontok (PoP-k) segítségével.

A jelenlegi megoldás két fordított proxyt használ az alaparchitektúra konzisztenciájának fenntartásához. Az Azure Front Door a globális útválasztó. Az Application Gateway régiónként terheléselosztóként működik. A legtöbb esetben ez a beállítás nem szükséges. Az Application Gatewayt a következő követelmények teljesülése esetén távolíthatja el:

• Mivel az Azure Web Application Firewall az Application Gatewayhez van csatolva, ehelyett webalkalmazási tűzfalat kell csatolnia az Azure Front Door szolgáltatáshoz.
• Meg kell győződnie arról, hogy a bejövő hívások csak az Azure Front Door-példányból származnak. Az ellenőrzést és az X-Azure-FDID header Azure Front Door IP-tartományait a Spring Cloud Gateway alkalmazásban is hozzáadhatja. További információ: Az Azure Front Door használata fordított proxyként a Spring Cloud Gateway használatával.

A különböző fordított proxyforgatókönyvekről, azok beállításáról és biztonsági szempontjairól az Azure Spring Apps fordított proxyn keresztüli közzétételét ismertető cikkben olvashat.

Háttéradatbázis

A többrégiós üzembe helyezéshez adatreplikációs stratégiával kell rendelkeznie. Ha az alkalmazás több régióban elérhető, szinkronizálni kell az adatokat, hogy a felhasználók ne láthassák az elavult adatokat.

A jelenlegi architektúra egy MySQL-adatbázist használ a háttéradatbázishoz, de ez a konfiguráció nem foglalkozik az adatszinkronizálással. Adatbázis-technológia kiválasztásakor ellenőrizze, hogyan replikálhatja és szinkronizálhatja az adatokat a régiók között. Az egyik lehetőség az Azure SQL Database, amely aktív georeplikációs funkcióval rendelkezik, amely folyamatosan szinkronizált, olvasható másodlagos adatbázist biztosít egy elsődleges adatbázishoz.

Ezt a funkciót a következő esetekben használhatja:

• Ha a másodlagos régió hideg készenléti állapotú, amely nem fogad aktív kéréseket
• Feladatátvétel, ha az elsődleges régió meghibásodik
• Elsődleges és másodlagos adatbázisok beállítása a két régió közötti virtuális hálózati társviszony-létesítésen keresztül a saját régiójukhoz való privát kapcsolattal.

Egy másik megközelítés az Azure Cosmos DB használata. Ez a szolgáltatás globálisan eloszthatja az adatokat, ha transzparens módon replikálja az adatokat az Azure Cosmos DB-fiók összes régiójába. Az Azure Cosmos DB több írási régióval is konfigurálható. További információ: Geode-minta.

Automatikus üzembe helyezés

A lehető legnagyobb mértékben automatizálja az infrastruktúra üzembe helyezését és az alkalmazáskód üzembe helyezését.

Az infrastruktúra üzembe helyezésének automatizálása garantálja az infrastruktúra azonos konfigurálását, ami segít elkerülni az olyan konfigurációs eltéréseket, mint a régiók között. Az infrastruktúra-automatizálás a feladatátvételi műveleteket is tesztelheti.

Alkalmazástelepítés esetén győződjön meg arról, hogy az üzembehelyezési rendszerek arra a több régióra irányulnak, amelyekre telepíteniük kell őket. Több régiót is használhat kék-zöld vagy kanári telepítési stratégiában. Ezekkel az üzembe helyezési stratégiákkal új alkalmazásverziókat hozhat létre egy régióban tesztelés céljából, és a tesztelés sikeressége után más régiókba is.

Teljesítmény és skálázhatóság

Ez az architektúra jobban megfelel az alaparchitektúrának az alkalmazásigények kielégítése érdekében, mivel a terhelés régiók közötti elosztását teszi lehetővé. Ha úgy konfigurálja az Azure Front Doort, hogy a késés alapján irányozza a kéréseket, a felhasználók jobb válaszidőt kapnak, mivel a kérések a hozzájuk legközelebbi régiókhoz vannak irányítva.

Az adatbázis beállításától függően előfordulhat, hogy az adatok régiók közötti szinkronizálása további késéssel jár. Ezt a késést az Azure Cosmos DB nyugodtabb konzisztenciaszinttel való használatával háríthatja el.

Ez a referenciaarchitektúra számos olyan összetevőt tartalmaz, amelyek metrika alapján automatikusan skálázhatók:

• Az Azure Front Door igény szerint automatikusan skálázható. Az Azure Front Door egyéb funkcióit, például a forgalomgyorsítást és a gyorsítótárazási képességeket is használhatja, hogy közelebb hozza az eszközöket a végfelhasználókhoz.
• Az Application Gateway támogatja az automatikus skálázást. További információ: Application Gateway v2 és Web Application Firewall v2 skálázása.
• Az Azure Spring Apps az automatikus skálázást is támogatja. További információ: Automatikus skálázás beállítása alkalmazásokhoz.

Költségekkel kapcsolatos szempontok

Ez a megoldás gyakorlatilag megduplázza az alaparchitektúra költségbecsléseit.

A többrégiós megoldáshoz kapcsolódó költségek fő mozgatórugói a következők:

• Az elsődleges és másodlagos adatbázisoknak ugyanazt a szolgáltatási szintet kell használniuk; ellenkező esetben előfordulhat, hogy a másodlagos adatbázis nem tartja lépést a replikáció változásaival.
• A jelentős régiók közötti forgalom növeli a költségeket. Az Azure-régiók közötti hálózati forgalom díjakat von maga után.

A költségek kezeléséhez vegye figyelembe az alábbi javaslatokat a megvalósításhoz:

• Használja az erőforrások leskálázott verzióit, például az Azure Spring Appst és az Application Gatewayt a készenléti régióban, és csak akkor skálázza fel az erőforrásokat, ha a készenléti állapot aktívvá válik.
• Ha az üzleti forgatókönyvek lehetővé teszik, hozzon létre egy aktív-passzív beállítást a költségek megtakarításához.
• Többzónás beállítás implementálása egyetlen régióban a rendelkezésre állási és rugalmassági üzleti igények kielégítése érdekében. Ez a lehetőség költséghatékonyabb lehet, mert csak egyszer kell fizetnie a legtöbb erőforrásért.
• Válassza ki azt az alternatív beállítást, amely csak egy fordított proxyt használ a költségek megtakarításához. Ne feledje, hogy az alternatíva biztonságának fenntartása érdekében további konfigurációt kell alkalmaznia.

Az azure-díjszabás kalkulátorával becsültük meg az architektúra szolgáltatásainak költségeit egy kis léptékű alkalmazás ésszerű alapértelmezett értékeivel. Ezt a becslést az alkalmazás várható átviteli sebessége alapján frissítheti.

Egyéb szempontok

A többzónás alapkonfigurációs architektúra tervezési szempontjai a cikkben ismertetett többrégiós megoldásra is vonatkoznak. Tekintse át a következő szempontokat a többrégiós architektúra kontextusában:

• Hálózati biztonság. Fontos a hálózaton keresztüli kommunikáció szabályozása. Ez a megoldás csak az Azure Front Door bejövő hívásait teszi lehetővé, ahol a hívásokat az Application Gatewayre irányítják minden régióban. Az Application Gatewayről a hívások a háttérbeli Azure Spring Apps szolgáltatáshoz vezetnek. Az Azure Spring Apps és az olyan támogató szolgáltatások közötti kommunikációt, mint a Key Vault, privát végpontok használatával is vezérelheti. További információ: Alapkonfigurációs architektúra: Hálózati biztonság.

• Identitás- és hozzáféréskezelés. Biztonságosabb hozzáférést valósíthat meg felügyelt identitások használatával a különböző összetevők közötti kapcsolódáshoz. Ilyen például, hogy az Azure Spring Apps hogyan használ felügyelt identitást a Key Vaulthoz való csatlakozáshoz. További információ: Alaparchitektúra: Identitás- és hozzáférés-kezelés.

• Figyelés. Rendszerezést adhat hozzá, és engedélyezheti az elosztott nyomkövetést, hogy adatokat gyűjtsön az alkalmazásból. Ezt az adatforrást a platformdiagnosztikával kombinálva betekintést nyerhet az alkalmazásba. További információ: Alapkonfigurációs architektúra: Monitorozás.

• Titkos kódok kezelése. A többrégiós megoldás egyetlen kulcstartóban tárolja az alkalmazás titkos kulcsait és tanúsítványait. További információ: Alapszintű architektúra: Titkos kódok kezelése.

Forgatókönyv üzembe helyezése

A referenciaarchitektúra üzembe helyezése az Azure Spring Apps többrégiós referenciaarchitektúrájában érhető el a GitHubon. Az üzembe helyezés Terraform-sablonokat használ.

Az architektúra üzembe helyezéséhez kövesse a részletes utasításokat.

Közreműködők

A Microsoft fenntartja ezt a tartalmat. A következő közreműködő fejlesztette ki az eredeti tartalmat.

Fő szerző:

• Gitte Vermeiren | FastTrack for Azure Engineer

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépések

Ha ezt a számítási feladatot a szervezet központi csapatai által felügyelt megosztott szolgáltatásokkal szeretné integrálni, helyezze üzembe egy Azure-alkalmazás kezdőzónájában.

Kapcsolódó erőforrások

Az architektúrában használt Azure-szolgáltatások és -funkciók dokumentációját a következő cikkekben találja:

• Azure Spring Apps
• Azure Front Door
• Azure-alkalmazás Átjáró 2-ben
• Azure Database for MySQL
• Azure Key Vault
• Azure DNS
• Azure Web Application Firewall
• Azure Private Link
• Microsoft Entra által felügyelt identitások Azure-erőforrásokhoz

Az architektúra konfigurációs lehetőségeinek részletesebb megismeréséhez az alábbi útmutatókat ajánljuk:

• Az Azure Spring Apps felfedése fordított proxyn keresztül
• Magas rendelkezésre állású kék/zöld üzembe helyezés alkalmazásokhoz
• A fordított proxy és a háttérbeli webalkalmazás közötti eredeti HTTP-gazdagépnév megőrzése

Ez az architektúra a Microsoft Azure Well-Architected Framework alappilléreivel összhangban lett kialakítva. Javasoljuk, hogy tekintse át az egyes pillérek tervezési alapelveit.