Földrajzilag elosztott alkalmazás-architektúra tervezése
Amikor a hálózati összetevők egy regionális kimaradás következményeinek mérséklése érdekében több régióba irányítanak kéréseket, az alkalmazás szolgáltatásait úgy kell megterveznünk, hogy az elsődleges és a tartalék régiókban is válaszolni tudjanak ezekre a kérésekre.
A korábbiakból tudható, hogy az Azure Front Doort prioritásos háttér-hozzárendeléssel tervezzük konfigurálni. Elsődleges régióként az USA keleti régióját, az USA nyugati régióját pedig készenléti régióként rendeljük hozzá. Regionális hiba esetén a kérések az App Service-hez vezetnek a nem megfelelő régióban. Mindkét régióban konfigurálni kell azokat az erőforrásokat, amelyek támogatják a feladatátvételt a felhasználó hozzáférés, a replikált tárolás és az alkalmazáskód tekintetében.
Itt vizsgáljuk meg a megoldásban található alkalmazásszolgáltatásokat, és meghatározzuk, hogy módosítani kell-e őket a többrégiós architektúrában való működéshez. Pontosabban az Active Directoryt, a statikus tartalomtárolást, a webalkalmazásokat, a webes API-kat, az üzenetsorokat, az Azure-függvényeket és az adatgyorsítótárakat tekintjük át.
Microsoft Entra ID
A szállítmánykövető portálon a felhasználók egy követési szám megadásával követhetik nyomon vásárlásaik kiszállítását. A rendszeres felhasználók tagként regisztrálhatják magukat, és olyan speciális funkciókhoz is hozzáférhetnek, mint a kiszállítási idő és más statisztikák. A nyomkövetési portált úgy fejlesztettük ki, hogy felhasználói fiókokat tároljon a Microsoft Entra ID-ban.
A Microsoft Entra ID alapértelmezés szerint globális rendszerként van kialakítva. Emiatt a regionális kimaradások nem károsítják, és a rendszernek ezt az összetevőjét nem kell módosítanunk.
Azure Blob Storage
A képek, videók és más statikus tartalmak Azure Storage-fiókokban vannak tárolva nagy bináris objektumokként (blobokként), a felhasználók számára pedig az Azure CDN-en keresztül vannak kézbesítve.
Az eredeti kialakítás szerint a tárfiókot egyetlen régió tartalmazza, mert a helyileg redundáns tárolás (LRS) használata mellett döntöttünk. LRS használata esetén az adatok csak egyetlen adatközponton belül vannak replikálva. A tárfiók így ebben a konfigurációban elérhetetlen lesz egy regionális kimaradás esetén. A CDN által már gyorsítótárazott statikus tartalmak továbbra is elérhetők maradnak a felhasználók számára.
Ugyanez a zónaredundáns tárolásra (ZRS) is igaz. Bár az adatok ebben a konfigurációban különböző adatközpontokba van replikálva, ezek az adatközpontok még mindig egy régióban helyezkednek el. A regionális kimaradás az ebben a konfigurációban lévő tárfiókra is hatással van.
Rendszerünk erősen épít statikus tartalmat gyorsítótárazó CDN-konfigurációra. Fennáll a lehetőség, hogy egy felhasználó egy leállás alatt olyan statikus fájlt kér, amely még nincs meg a CDN gyorsítótárában. Ez a kérés nem megjeleníthető grafikát vagy videót eredményezne.
Ezt a lehetőséget azzal zárhatjuk ki, hogy a tárfiókot több régióba replikáljuk a georedundáns tárolási lehetőség választásával. Egy írásvédett replikációs lehetőség is elérhető, amely megakadályozza a statikus tartalom hozzáadását egy regionális kimaradás során.
Ha engedélyezni szeretnénk a georedundanciát, két lehetőség közül választhatunk. Ezek a lehetőségek az olvasási hozzáférésű georedundáns tárolás (RA-GRS) és az olvasási hozzáférésű georedundáns tárolás (RA-GZRS). A döntés a költségvetésünktől és a szükséges üzemidő százalékától függ.
Azure App Service és Azure-függvényalkalmazások
Szállítmánykövető portálunk két Azure App Service-szolgáltatást valósít meg. Az első App Service egy webalkalmazást üzemeltet, amely implementálja a felhasználó által használt webes felületet, a második pedig a mobilalkalmazások által a szállítmányok adatainak nyomon követésére használt webes API-t. Az összes háttérbeli feladat Azure-függvényalkalmazásként fut.
Eredeti tervünkben mindkét Azure App Service-szolgáltatás egyetlen Azure-régióban helyezkedett el. Létrehozunk egy második App Service-t a másodlagos régióban (AZ USA nyugati régiójában), és ott helyezzük üzembe a webes projektet az új többrégiós architektúra támogatásához. Az Azure Front Door prioritási útválasztási módját úgy konfiguráljuk, hogy kéréseket küldjön a másodlagos régiónak, ha az elsődleges régió nem érhető el.
A lehető leggördülékenyebb feladatátvétel érdekében gondosodni kell arról, hogy a webalkalmazás ne tároljon munkamenetállapot-információkat a memóriában. Úgy módosítjuk a webhelyünket, hogy ne legyen adatvesztés. Ha például a kód a felhasználók szállítmányainak listáját tárolja a memóriában, ez a lista elveszne feladatátvétel esetén.
Ha nincs tárolt munkamenet-állapot, akkor minden webes kérés a másik befolyásolása nélkül kezelhető. Ha egy felhasználó munkamenete közben történik feladatátvétel, annak a felhasználó számára észrevétlennek kell maradnia.
Az Azure-függvényalkalmazásokhoz hasonló módosítást értünk el. Létrehozunk egy külön Azure-függvénypéldányt a másodlagos régióban, és ugyanazt az egyéni kódot helyezzük üzembe, mint az elsődleges régióban.
Fontos
Ha az egyéni kód frissítését helyezzük üzembe az App Service-ben vagy a függvényalkalmazás szolgáltatásában, akkor azt az App Service összes példányához el kell juttatni. Ha automatizálni szeretné ezt a folyamatot, segítségére lehetnek az Azure DevOps által kínált eszközök.
Azure Storage-üzenetsorok
Az eredeti egyrégiós architektúrában üzenetsort használtunk egy Azure Storage-fiókban az App Service és a függvényalkalmazás közötti kommunikáció lebonyolítására. Amikor a webalkalmazásnak vagy a webes API-nak háttérbeli feladatot kell futtatnia, egy az összes szükséges információt tartalmazó üzenetet helyez el az üzenetsorban. A függvényalkalmazás figyeli az üzenetsorban megjelenő új üzeneteket, és az adattárakon lefuttatott megfelelő lekérdezésekkel végrehajtja a háttérbeli feladatot.
Egy így használt üzenetsorral nagy számú webes kérés is szabályozottan kezelhető. Ha sok háttérfeladatot kell futtatni, előfordulhat, hogy az üzenetsor létrejön, de a feladatok nem lesznek elvetve. A feldolgozásukig az üzenetsorban maradnak. A sort feldolgozó függvényalkalmazások végül csökkenteni fogják annak méretét, ha a terhelés visszaesik. Ha az igény továbbra is fennáll, megnöveljük a függvényalkalmazás példányainak számát.
A szállítmánykövető portál többrégiós változatában gondoskodnunk kell arról, hogy feladatátvétel esetén ne vesszenek el az üzenetsor elemei. Az üzenetsor az Azure Storage-ban van definiálva, és felhasználhatjuk ennek georeplikációs redundanciáját.
Ebben az esetben nem használhatunk írásvédett redundancia-beálllítást, mert az üzenetsor olvasási és írási műveleteket is támogat. Az App Service-nek elemeket kell a sorhoz adnia, a függvényalkalmazásnak pedig el kell távolítania az üzenetsorból a befejezett elemeket. Ehelyett használhatunk georedundáns tárolást (GRS) vagy geo- és zónaredundáns tárolást (GZRS).
Azure Redis Cache
Az adattár teljesítményének maximalizálása érdekében használjuk az Azure Redis Cache-t. A Redis gyorsítótárazza az összes olyan lekérdezés eredményét, amelyet az adatbázisból adatokat lekérő alkalmazások generálnak. A hasonló adatokra vonatkozó további lekérdezések nem igényelnek adatbázis-lekérdezést, és a Rendszer a Redis cache-ből olvassa be.
A többrégiós architektúrához létrehozunk egy Redis Cache-példányt az elsődleges és a készenléti régiókban is. Figyelembe kell venni, hogy feladatátvétel esetén a tartalék régióban lévő Redis Cache feltehetően üres lesz. Az üres gyorsítótár nem okoz hibát, de a teljesítmény átmenetileg csökkenhet, mivel az adatok kitöltik az új gyorsítótárat.