Földrajzilag elosztott architektúra tervezése
Az Azure globális rendszer. Egy több Azure-régióban is jelen lévő architektúra megtervezésével olyan alkalmazás készíthető, amely még az egész régiót érintő katasztrófáknak is ellenáll.
A szállítmánykövető portál azért skálázható, mert skálázható Azure-erőforrásokra épül. Emellett számos hibával szemben ellenálló, mert összetevői több példányt is tartalmazhatnak. Az igazgatótanács azonban aggódik amiatt, hogy egy nagy méretű katasztrófa fennakadást okozhat, mivel a portál teljes egészében az USA keleti Azure-régiójában található. Ön egy módosított architektúrát szeretne javasolni, amelyben a feladatokat egy második régió veheti át az USA keleti régiójában bekövetkező hiba esetén.
Itt megtudhatja, hogyan módosíthatja az alkalmazás architektúráját egy földrajzilag elosztott alkalmazás támogatásához. Azt is látjuk, hogy az ilyen architektúra miért előnyös az üzleti szempontból kritikus alkalmazások számára.
Az eredeti webalkalmazás-architektúra
Tekintsük át a nyomkövetési portál architektúratervét és a megoldásban használt összetevőket. Miután megértettük, hogyan használjuk az összes alkatrészt, megvizsgálhatjuk, hogyan támogathatjuk ezeket az összetevőket georedundáns forgatókönyvekben.
A követési portál kialakítása az alábbi ábrán látható referenciaarchitektúra alapján történik.
Figyelje meg, hogy az alkalmazás csak egy Azure-erőforráscsoportot használ. Ez az erőforráscsoport lehetővé teszi az összes erőforrás logikai csoportosítását és kezelését, és leegyszerűsíti a felügyeletet. Úgy döntöttünk, hogy ezt az erőforráscsoportot az USA keleti régiójában helyezzük üzembe. Bár az erőforráscsoport nem követeli meg, hogy a benne lévő erőforrásokhoz is ugyanazt az Azure-régiót használjuk, mi úgy döntöttünk, hogy az alkalmazásban üzembe helyezett összes erőforráshoz is az USA keleti régióját használjuk.
Alkalmazásunk három kategóriába tartozó Azure-erőforrásokat használ. Tekintsük át az egyes kategóriákat, és nézzük meg, hogy mely erőforrások vannak használatban.
Hálózati összetevők
A nyomkövetési portál az alábbi hálózati szolgáltatásokat használja.
| Szolgáltatás | Leírás |
|---|---|
| Azure DNS | Az Azure DNS-t konfiguráltuk a DNS-rekordok Azure-beli üzemeltetésére. Az Azure DNS lehetővé teszi a DNS-rekordok kezelését az Azure Portalon található Azure-hitelesítő adatainkkal. |
| Application Gateway | Az Application Gateway-terheléselosztót konfiguráltuk arra, hogy elossza a forgalmat a webes előtér példányai között. Ez a szolgáltatás egyetlen Azure-régióban helyezkedik el. |
| Azure CDN | Az Azure CDN-t konfiguráltuk a nem biztonságos statikus tartalom, például a webhely tartalmához tartozó grafika kézbesítésének maximalizálására. Ez a globális szolgáltatás gyorsítótárazza a statikus tartalmakat a jelenléti pontokon világszerte. |
Alkalmazásösszetevők
A követő portál az alábbi szolgáltatásokkal tesz eleget a kód, a gyorsítótár és a köztes tárolás követelményeinek.
| Szolgáltatás | Leírás |
|---|---|
| Microsoft Entra ID | A felhasználók Microsoft Entra-fiókokkal férnek hozzá a nyomkövetési portálhoz. A címtár és a fiók automatikusan globálisan replikálva van. |
| Azure App Service | A követő portál két Azure App Service-szolgáltatást használ. Az első dinamikus weblapokat futtat, a második pedig egy webes API-t. |
| Azure-függvényalkalmazások | A követő portál Azure-függvényalkalmazásokat használ az össze háttérbeli feladat futtatásához. Néhány ilyen feladat rendszeres ütemezés szerint fut, mások az üzenetsorban lévő üzeneteket dolgozzák fel. |
| Azure Storage-üzenetsorok | A nyomkövetési portál Azure Storage-üzenetsorokat használ az Azure Function Apps használatával. A követő portál a generált üzeneteket az üzenetsorba helyezi, ahonnan a függvényalkalmazások feldolgozzák azokat. |
| Redis Cache | A követő portál Redis Cache-gyorsítótárat használ az előtér-alkalmazás szolgáltatása és az adattárolási rendszerek között, hogy maximalizálja a lekérdezések teljesítményét. |
| Azure Blob Storage | A statikus tartalmak, például a grafikus és videofájlok bináris nagyméretű objektumokként (blobok) vannak tárolva egy Azure Storage-fiókban, és az Azure CDN-en keresztül lesznek kézbesítve. |
| Azure Search | A követési portálon engedélyeztük az Azure Search szolgáltatást. Az Azure Search lehetővé teszi, hogy az összes tartalom kereshető legyen, és keresési javaslatokat és homályos keresési eredményeket nyújtsunk felhasználóinknak. |
Adattárolási összetevők
A nyomkövetési portál a következő tartós tárolási szolgáltatásokat használja.
| Szolgáltatás | Leírás |
|---|---|
| Azure SQL Database | Az olyan relációs adatokat, mint a megrendelése és az ügyfelek adatai az Azure SQL Database-ben tároljuk. |
| Cosmos DB | A részben strukturált adatokat, amilyen a termékkatalógus, a Cosmos DB-ben tároljuk. |
Az eredeti architektúra hátrányai
A követő portál meglévő architektúrája a skálázhatóság és rendelkezésre állás szempontjai alapján lett megtervezve.
Ha például az igény magas, és a felhasználói webes kérelmekre adott válaszok lassúak, érdemes lehet további példányokat hozzáadni az előtér-webalkalmazáshoz az App Service-ben. Ekkor az Application Gateway az újonnan létrehozott példányokhoz irányíthatja a kéréseket.
Vannak azonban olyan forgatókönyvek, amelyekben az architektúra kialakításának kihívásai vannak, amelyeket meg kell oldani, vagy akár meg is hiúsulhat. Vizsgáljuk meg ezeket a helyzeteket, hogy jobban megérthessük azok hatását a követő portálra.
Regionális hibák
Bizonyos nagyszabású események képesek lehetnek egy teljes Azure-régió működésének megszakítására. Az Azure-adatközpontok rendkívül rugalmasak, de egy hatalmas időjárási esemény, például hurrikán vagy árvíz megzavarhatja a régió szolgáltatását.
Az ilyen események rendkívüliek és ritkák, és sok vállalat véli úgy, hogy ezt a kockázatot vállalhatják. Annak következményei azonban, hogy egy regionális meghibásodás működésképtelenné teszi a követő portált olyan nagy kockázattal járnak, hogy a vállalat vezetősége ennek kizárása mellett döntött.
Szolgáltatói szerződések
Az Azure-szolgáltatások többsége az üzemidőt garantáló szolgáltatói szerződést (SLA) kínál. Egy Azure-szolgáltatásokból álló alkalmazás-architektúra tervezésekor az alkalmazás teljes SLA-ját az összes többi szolgáltatás SLA-jának összetételeként számítjuk ki.
Ez az SLA az összetevő szolgáltatások SLA-inak szorzataként számítható ki. Tegyük fel például, hogy az alkalmazás Azure-alkalmazás Szolgáltatásból (99,95%SLA) és Microsoft Entra-azonosítóból (99,9% SLA) áll. Az ezekből kiszámított végső SLA 99,85%.
Ha ez az százalékos üzemidő nem elég az alkalmazás számára, akkor megoldható, hogy az alkalmazás feladatait hiba esetén egy másik régió vegye át.
Globális, regionális és konfigurálható összetevők
Kialakított rendszerünk egyes összetevői alapértelmezetten globálisak, így a regionális hibák ezeket nem érintik.
Az összetevők egy része egyetlen régióra korlátozódik. Ilyen például az Application Gateway. Ki kell választanunk egy alternatív szolgáltatást az ilyen típusú összetevőkhöz.
Egyes összetevők konfigurálhatók úgy, hogy több régiót is támogassanak. Használhatjuk például a statikus tartalmat tároló Azure Storage-fiók georedundáns tárolás (GRS) beállítását. A GRS egy másik régióba replikálja a blobokat.
Az alábbi táblázat azt mutatja be, hogy mely összetevők globálisak, regionálisak és konfigurálhatók.
| Összetevő | Több régió támogatása | Megjegyzések |
|---|---|---|
| Azure DNS | Globális | Nem szükséges módosítani. |
| Application Gateway | Regionális | Minden Application Gateway-példány csak egyetlen régióra terjed ki. |
| Azure CDN | Globális | Nincs szükség módosításokra, a tartalom alapértelmezés szerint globálisan gyorsítótárazva van. |
| Microsoft Entra ID | Globális | Nem szükséges módosítani. |
| Azure App Service | Regionális | Az alkalmazás minden példánya csak egy régióban helyezkedik el. |
| Azure-függvényalkalmazások | Regionális | Egy függvényalkalmazás minden példánya csak egy régióban helyezkedik el. |
| Azure Storage-üzenetsorok | Konfigurálható | Dönthet úgy, hogy több régióba replikál egy Azure Storage-fiókot. |
| Azure Redis Cache | Regionális | A gyorsítótár minden példánya csak egy régióban helyezkedik el. |
| Azure Blob Storage | Konfigurálható | Dönthet úgy, hogy több régióba replikál egy Azure Storage-fiókot. |
| Azure Search | Regionális | A keresési szolgáltatás minden példánya csak egy régióban helyezkedik el. |
| Azure SQL Database | Konfigurálható | A georeplikálás használatával szinkronizálhatja az adatokat több régióba. |
| Azure Cosmos DB | Konfigurálható | A georeplikálás használatával szinkronizálhatja az adatokat több régióba. |
A javasolt elosztott architektúra
Némi vizsgálat után az alábbi ábrán látható módon javasolja az architektúrát.
Ebben az elrendezésben van egy aktív régió (az USA keleti régiója), és egy tartalék régió (az USA nyugati régiója). A szokásos körülmények közözz az USA keleti régiója kezeli az összetevők összes kérését. Ha egy katasztrófa regionális kimaradást okoz, az alkalmazás feladatait az USA nyugati régiója veszi át.
Vizsgáljuk meg az eredeti architektúra magas szintű módosításait. Ezeket a változásokat részletesebben is megismerheti a későbbi egységekben.
Networking
Az Azure DNS és az Azure CDN alapértelmezés szerint globális rendszer, és rugalmasan ellenáll a regionális hibáknak. A helyén hagyjuk őket.
Azure Application Gateway létrehozásakor a szolgáltatást egyetlen régióhoz rendeljük hozzá. Ezt a biztonsági rést úgy szüntetjük meg, hogy lecseréljük ezt a szolgáltatást az Azure Front Doorra. A Front Door több App Services-szolgáltatást is lekérdezhet, és kezelheti az App Service feladatátvételét az USA keleti régiójából az USA nyugati régiójába.
Alkalmazásszolgáltatások
A Microsoft Entra ID egy globális rendszer, és nem igényel módosítást.
Az Azure Storage-fiókok konfigurálhatók úgy, hogy több régióba replikálják a tartalmat. A konfiguráció módosításához az egyik georedundáns tárolási lehetőséget használjuk.
A többi összetevő, köztük az App Service, a Function Apps, a Redis Cache és az Azure Search regionális. Az új architektúratervben az USA nyugati régiójában duplikált példányokat hozunk létre ezekből az összetevőkből. Ebben az elrendezésben az új régió hiba esetén átveheti a feladatokat.
Adattárolás
Az Azure SQL Database és az Azure Cosmos DB is támogatja az adatok más régióba való georeplikációját. Ezeket a szolgáltatásokat úgy konfiguráljuk, hogy az USA keleti régiójában lévő adatokat az USA nyugati régiójában lévő egyenértékű szolgáltatásokra replikáljuk.
Regionális párok
Az Azure-régiók olyan területek egy földrajzi helyen belül, ahol egy vagy több Azure-adatközpont helyezkedik el. Minden régió párosítva van az ugyanazon a földrajzi helyen lévő többi régióval. A párokon belül a frissítéseket és a tervezett karbantartásokat egyszerre csak egy régión végzik el. Több régiót érintő hiba esetére a párokban legalább egy régió elsődlegesként van kijelölve a gyors helyreállításhoz.
Ajánlott az alkalmazás kétrégiós architektúráját egy régiópár két tagjában elhelyezni. Az USA keleti régiójának párja például az USA nyugati régiója. A javasolt kialakítás az USA keleti régióját használja az aktív régióhoz, az USA nyugati régióját pedig a készenléti régióhoz.