Návrh geograficky distribuované architektury aplikací
Když naše síťové komponenty směrují požadavky do více oblastí, abychom snížili dopady regionálního výpadku, musíme navrhnout aplikační služby, které na tyto požadavky reagují v primárních i pohotovostních oblastech.
Připomeňme si z dřívějška, že plánujeme nakonfigurovat Azure Front Door s prioritním přiřazením back-endu. Oblast USA – východ přiřadíme jako primární oblast a oblast USA – západ jako pohotovostní oblast. Pokud dojde k selhání v regionu, požadavky se směrují do služby App Service v nepostiženém regionu. Musíme nakonfigurovat prostředky v každé oblasti, aby podporovaly přístup uživatelů, replikované úložiště a kód aplikace pro tato převzetí služeb při selhání.
Tady se podíváme na aplikační služby v našem řešení a určíme, jestli je potřeba je upravit tak, aby fungovaly v architektuře s více oblastmi. Konkrétně se podíváme na službu Active Directory, úložiště statického obsahu, webové aplikace, webová rozhraní API, fronty, funkce Azure a mezipaměti dat.
Microsoft Entra ID
Na našem portálu pro sledování zásilek můžou uživatelé sledovat doručení svých nákupů zadáním sledovacího čísla. Běžní uživatelé se ale můžou zaregistrovat k členství pro přístup k pokročilým funkcím, jako je výzva k doručení a další statistika. Vyvinuli jsme sledovací portál pro ukládání uživatelských účtů v Microsoft Entra ID.
Microsoft Entra ID je ve výchozím nastavení navržen jako globální systém. Proto není zranitelná vůči oblastním selháním a tuto komponentu systému nemusíme upravovat.
Úložiště Azure Blob
Statický obsah, jako jsou obrázky a videa, se ukládá v účtech Azure Storage jako binární velké objekty (Bloby) a jsou poskytovány uživatelům prostřednictvím Azure CDN.
V našem původním návrhu je účet úložiště obsažený v jedné oblasti, protože jsme se rozhodli použít místně redundantní úložiště (LRS). Naše data se replikují pouze v rámci jednoho datacentra s LRS. Účet úložiště proto není k dispozici, pokud v této konfiguraci dojde k výpadku oblasti. Veškerý statický obsah, který už cdN ukládá do mezipaměti, zůstane uživatelům k dispozici.
Totéž platí pro zónově redundantní úložiště (ZRS). I když se data v této konfiguraci replikují do různých datových center, všechna tato datová centra jsou stále ve stejné oblasti. Výpadek v regionu ovlivňuje také účet úložiště v této konfiguraci.
V našem návrhu spoléháme silně na konfiguraci CDN pro ukládání statického obsahu do mezipaměti. Je možné, že během výpadku může uživatel požádat o statický soubor, který ještě není v mezipaměti CDN. Výsledkem tohoto požadavku by byla grafika nebo video, které se nedá zobrazit.
Tuto možnost můžeme eliminovat tím, že účet úložiště replikujeme do více oblastí, když zvolíme možnost geograficky redundantního úložiště. K dispozici je také možnost replikace jen pro čtení, která brání přidání statického obsahu během regionálního výpadku.
Máme dvě možnosti, ze kterých si můžeme vybrat, když potřebujeme povolit geografickou redundanci. Tyto možnosti jsou Read-Access Geo-Redundant úložiště (RA-GRS) a Read-Access geografickéZone-Redundant úložiště (RA-GZRS). Volba, kterou provedeme, závisí na našem rozpočtu a procentu potřebného času.
Azure App Service a aplikace Funkcí Azure
Náš portál pro sledování zásilek implementuje dvě služby Azure App Services. První služba App Service hostuje webovou aplikaci, která implementuje uživatelské webové rozhraní, a druhá hostuje webové rozhraní API používané mobilními aplikacemi ke sledování dat zásilek. Všechny naše úlohy na pozadí běží jako aplikace Azure Functions.
V našem původním návrhu se každá služba Azure App Service lokalizuje do jedné oblasti Azure. Vytvoříme druhou službu App Service v sekundární oblasti (USA – západ) a nasadíme tam webový projekt pro podporu nové architektury s více oblastmi. Režim směrování priority služby Azure Front Door nakonfigurujeme tak, aby odesílal požadavky do sekundární oblasti, pokud primární oblast není k dispozici.
Pokud chcete zajistit, aby převzetí služeb při selhání bylo co nejplynulejší, ujistěte se, že webová aplikace neukládá žádné informace o stavu relace do paměti. Změníme náš web, abychom měli jistotu, že neskončíme ztrátou dat. Pokud například náš kód ukládá seznam zásilek uživatelů v paměti, byl by tento seznam ztracen v případě selhání.
Každý webový požadavek se zpracovává, aniž by to mělo vliv na ostatní, pokud se neuloží žádný stav relace. Pokud k převzetí služeb při selhání dojde uprostřed relace uživatele, mělo by být pro uživatele transparentní.
Podobnou změnu provedeme v aplikacích Azure Functions. V sekundární oblasti vytvoříme samostatnou instanci funkce Azure Functions a nasadíme do ní stejný vlastní kód, který se spustí v primární oblasti.
Důležitý
Když nasadíte aktualizaci vlastního kódu ve službě App Service nebo službě Function App Service, nezapomeňte ji distribuovat do všech instancí služby App Service. Pokud chcete tento proces automatizovat, Azure DevOps má nástroje, které vám můžou pomoct.
Fronty služby Azure Storage
V naší původní jednoregionální architektuře jsme použili frontu v účtu Azure Storage ke správě komunikace mezi App Service a funkční aplikací. Když webová aplikace nebo webové rozhraní API potřebuje spustit úlohu na pozadí, umístí zprávu se všemi požadovanými informacemi ve frontě. Funkce aplikace monitoruje frontu nových zpráv a vykonává úlohu na pozadí prováděním potřebných dotazů do úložišť dat.
Vysokou poptávku ve webových požadavcích můžeme spravovat seřazeným způsobem, když tímto způsobem používáme frontu. Pokud je spuštěno mnoho úloh na pozadí, může se fronta nahromadit, ale úlohy se nezahodí. Zůstanou ve frontě, dokud nejsou zpracovány. Funkční aplikace pracují přes frontu a při poklesu poptávky zmenšují její velikost. Pokud poptávka přetrvává, zvýšíme počet instancí aplikace funkcí.
U portálu pro sledování zásilek určeného pro více regionů musíme zajistit, aby se při přepnutí na záložní systém neztratily položky fronty. Naše fronta je definovaná ve službě Azure Storage a pro geografickou replikaci můžeme použít možnost redundance.
Mějte na paměti, že nemůžeme použít možnost redundance přístupu pro čtení, protože naše fronta podporuje operace čtení a zápisu. App Service musí do fronty přidávat položky a funkční aplikace musí z fronty odebírat dokončené položky. Místo toho použijte úložiště Geo-Redundant (GRS) nebo úložištěZone-Redundant geografické (GZRS).
Azure Redis Cache
K maximalizaci výkonu úložiště dat používáme Azure Redis Cache. Redis ukládá všechny výsledky dotazů vygenerované z našich aplikací do mezipaměti, protože požadují data z naší databáze. Jakékoli další dotazy na podobná data nepotřebují databázový dotaz a načítají se z mezipaměti Redis.
Pro architekturu s více oblastmi vytvoříme instanci Redis Cache v primárních i pohotovostních oblastech. Mějte na paměti, že když dojde k přepnutí, bude mezipaměť Redis Cache v záložní oblasti pravděpodobně prázdná. Tato prázdná mezipaměť nezpůsobí žádné chyby, ale výkon může dočasně klesat, protože data vyplňují novou mezipaměť.