V tomto článku se dozvíte, jak naplánovat implementaci modelu Spolehlivé webové aplikace. Model Reliable Web App je sada principů a technik implementace, které definují, jak byste při migraci do cloudu měli upravovat webové aplikace (replatformovat). Zaměřuje se na minimální aktualizace kódu, které je potřeba udělat, aby byly úspěšné v cloudu.
Pro usnadnění použití těchto pokynů existuje referenční implementace modelu Reliable Web App, který můžete nasadit.
Architektura referenční architektury implementace Stáhněte si soubor Visia této architektury.
Následující doprovodné materiály používají referenční implementaci jako příklad v celém příkladu. Pokud chcete naplánovat implementaci modelu Spolehlivé webové aplikace, postupujte takto:
Definování obchodních cílů
Prvním krokem při přechodu na cloud computing je vyjádřit vaše obchodní cíle. Model Reliable Web App zdůrazňuje důležitost nastavení okamžitých i budoucích cílů pro vaši webovou aplikaci. Tyto cíle ovlivňují vaši volbu cloudových služeb a architekturu vaší webové aplikace v cloudu.
Příklad: Fiktivní společnost Contoso Fiber chtěla rozšířit svou místní webovou aplikaci CAMS (Customer Account Management System) tak, aby se dostala do jiných oblastí. Pro splnění zvýšené poptávky ve webové aplikaci stanovili následující cíle:
- Použití změn kódu s nízkými náklady a vysokou hodnotou
- Dosažení cíle úrovně služeb (SLO) 99,9 %
- Přijetí postupů DevOps
- Vytváření prostředí optimalizovaných pro náklady
- Zvýšení spolehlivosti a zabezpečení
Společnost Contoso Fiber zjistila, že jejich místní infrastruktura nebyla nákladově efektivním řešením pro škálování aplikace. Rozhodli se tedy, že migrace webové aplikace CAMS do Azure je nákladově nejefektivnější způsob, jak dosáhnout svých okamžitých a budoucích cílů.
Volba správných spravovaných služeb
Když přesunete webovou aplikaci do cloudu, měli byste vybrat služby Azure, které splňují vaše obchodní požadavky, a v souladu s aktuálními funkcemi místní webové aplikace. Sladění pomáhá minimalizovat úsilí o přeformulování. Použijte například služby, které umožňují zachovat stejný databázový stroj a podporovat stávající middleware a architektury. Následující části obsahují pokyny pro výběr správných služeb Azure pro vaši webovou aplikaci.
Příklad: Před přechodem do cloudu byla webová aplikace CAMS společnosti Contoso Fiber místní monolitická webová aplikace v Javě. Jedná se o aplikaci Spring Boot s databází PostgreSQL. Webová aplikace je obchodní aplikace podpory. Je to pro zaměstnance. Zaměstnanci společnosti Contoso Fiber tuto aplikaci používají ke správě případů podpory od svých zákazníků. Místní webová aplikace trpí běžnými výzvami. Mezi tyto výzvy patří rozšířené časové osy pro sestavování a dodávání nových funkcí a problémů se škálováním různých komponent aplikací v rámci vyššího zatížení.
Aplikační platforma
Zvolte nejlepší platformu pro hostování aplikací pro vaši webovou aplikaci. Azure nabízí mnoho různých výpočetních možností, které splňují řadu požadavků na webové aplikace. Nápovědu k zúžení možností najdete v rozhodovacím stromu výpočetních prostředků Azure.
Příklad: Společnost Contoso Fiber zvolila jako aplikační platformu službu Aplikace Azure Service z následujících důvodů:
Přirozený progrese. Společnost Contoso Fiber nasadila na místní server soubor Spring Boot
jara chtěla minimalizovat velikost změny architektury pro tento model nasazení. App Service poskytuje robustní podporu pro spouštění aplikací Spring Boot a pro Contoso Fiber bylo přirozené progrese, aby používala App Service. Azure Spring Apps je také atraktivní alternativou pro tuto aplikaci. Pokud webová aplikace Contoso Fiber CAMS místo Spring Bootu používala Jakarta EE, byla by služba Azure Spring Apps vhodnější. Další informace najdete v tématu Co je Azure Spring Apps? a Java EE, Jakarta EE a MicroProfile v Azure.Vysoká smlouva SLA. Má vysokou smlouvu SLA, která splňuje požadavky pro produkční prostředí.
Nižší režijní náklady na správu Jedná se o plně spravované řešení hostování.
Funkce kontejnerizace App Service funguje s privátními registry imagí kontejnerů, jako je Azure Container Registry. Společnost Contoso Fiber může tyto registry použít ke kontejnerizaci webové aplikace v budoucnu.
Automatické škálování Webová aplikace může rychle vertikálně navýšit, snížit nebo snížit kapacitu na základě provozu uživatelů.
Správa identit
Vyberte nejlepší řešení správy identit pro vaši webovou aplikaci. Další informace najdete v tématu Porovnání řešení správy identit a metod ověřování.
Příklad: Contoso Fiber zvolilo Microsoft Entra ID z následujících důvodů:
Ověřování a autorizace. Zpracovává ověřování a autorizaci zaměstnanců.
Škálovatelnost. Škáluje se tak, aby podporovala větší scénáře.
Řízení identit uživatelů. Zaměstnanci můžou používat své stávající podnikové identity.
Podpora pro autorizační protokoly Podporuje OAuth 2.0 pro spravované identity.
Databáze
Vyberte nejvhodnější databázi pro vaši webovou aplikaci. Nápovědu ke zužování možností najdete v rozhodovacím stromu úložiště dat Azure.
Příklad: Contoso Fiber zvolila Azure Database for PostgreSQL a možnost flexibilního serveru z následujících důvodů:
Spolehlivost. Model nasazení flexibilního serveru podporuje zónově redundantní vysokou dostupnost napříč několika zónami dostupnosti. Tato konfigurace a udržuje záložní pohotovostní server v jiné zóně dostupnosti v rámci stejné oblasti Azure. Konfigurace replikuje data synchronně na pohotovostní server.
Replikace mezi oblastmi Má funkci repliky pro čtení, která umožňuje asynchronně replikovat data do databáze repliky jen pro čtení v jiné oblasti.
Výkon. Poskytuje předvídatelný výkon a inteligentní ladění pro zlepšení výkonu databáze pomocí skutečných dat o využití.
Nižší režijní náklady na správu Jedná se o plně spravovanou službu Azure, která snižuje povinnosti správy.
Podpora migrace: Podporuje migraci databází z místních databází PostgreSQL s jedním serverem. Nástroj pro migraci můžou použít ke zjednodušení procesu migrace.
Konzistence s místními konfiguracemi Podporuje různé komunitní verze PostgreSQL, včetně verze, kterou Contoso Fiber aktuálně používá.
Odolnost. Flexibilní nasazení serveru automaticky vytvoří zálohy serveru a uloží je pomocí zónově redundantního úložiště (ZRS) ve stejné oblasti. Svou databázi můžou obnovit k určitému bodu v čase během doby uchovávání záloh. Funkce zálohování a obnovení vytvoří lepší cíl bodu obnovení (přijatelné množství ztráty dat), než by společnost Contoso Fiber mohla vytvořit místně.
Monitorování výkonu aplikací
Zvolte monitorování výkonu aplikace pro vaši webovou aplikaci. Aplikační Přehledy je řešení pro správu výkonu aplikací nativní pro Azure (APM). Je to funkce řešení monitorování Azure, Azure Monitoru.
Příklad: Contoso Fiber přidala aplikaci Přehledy z následujících důvodů:
Detekce anomálií Automaticky detekuje anomálie výkonu.
Řešení potíží. Pomáhá diagnostikovat problémy ve spuštěné aplikaci.
Telemetrická data. Shromažďuje informace o tom, jak uživatelé aplikaci používají, a umožňuje snadno odesílat vlastní události, které chcete ve své aplikaci sledovat.
Mezera v viditelnosti v místním prostředí. Místní řešení nemělo řešení pro monitorování výkonu aplikací. Aplikační Přehledy poskytuje snadnou integraci s aplikační platformou a kódem.
Mezipaměť
Zvolte, jestli chcete přidat mezipaměť do architektury webové aplikace. Azure Cache for Redis je primární řešení mezipaměti Azure. Jedná se o spravované úložiště dat v paměti založené na softwaru Redis.
Příklad: Contoso Fiber potřebovala mezipaměť, která poskytuje následující výhody:
Rychlost a hlasitost. Má vysokou propustnost dat a nízkou latenci čtení pro běžně používaná a pomalu se měnící data.
Různorodá podpora. Jedná se o jednotné umístění mezipaměti, které můžou používat všechny instance webové aplikace.
Externí úložiště dat Místní aplikační servery prováděly místní ukládání do mezipaměti virtuálního počítače. Toto nastavení nenačítá data s vysokou četností a nemohla zneplatnit data.
Nesticky relace. Mezipaměť umožňuje webové aplikaci externalizovat stav relace pomocí nesticky relací. Většina webových aplikací v Javě spuštěných v místním prostředí používá ukládání do mezipaměti na straně klienta. Ukládání do mezipaměti na straně klienta se neškálí správně a zvyšuje nároky na paměť na hostiteli. Díky použití služby Azure Cache for Redis má Contoso Fiber plně spravovanou škálovatelnou službu mezipaměti, která zlepšuje škálovatelnost a výkon svých aplikací. Společnost Contoso Fiber používala architekturu abstrakce mezipaměti (Spring Cache) a k prohození poskytovatele mezipaměti potřebovala pouze minimální změny konfigurace. Povolila jim přejít od poskytovatele Ehcache na poskytovatele Redis.
Load Balancer
Vyberte nejlepší nástroj pro vyrovnávání zatížení pro vaši webovou aplikaci. Azure má několik nástrojů pro vyrovnávání zatížení. Nápovědu k zúžení možností najdete v tématu Výběr nejvhodnějšího nástroje pro vyrovnávání zatížení pro vaši aplikaci.
Příklad: Contoso Fiber zvolil jako globální nástroj pro vyrovnávání zatížení službu Front Door z následujících důvodů:
Flexibilita směrování Umožňuje týmu aplikace nakonfigurovat příchozí přenos dat, aby podporoval budoucí změny v aplikaci.
Zrychlení provozu. Pomocí libovolného vysílání se dostane k nejbližšímu bodu přítomnosti Azure a najde nejrychlejší trasu do webové aplikace.
Vlastní domény. Podporuje vlastní názvy domén s flexibilním ověřováním domény.
Sondy stavu Aplikace potřebuje inteligentní monitorování sond stavu. Azure Front Door používá odpovědi z sondy k určení nejlepšího zdroje pro směrování požadavků klientů.
Podpora monitorování Podporuje integrované sestavy s řídicím panelem typu all-in-one pro front Door i vzory zabezpečení. Můžete nakonfigurovat výstrahy, které se integrují se službou Azure Monitor. Umožňuje aplikaci protokolovat jednotlivé požadavky a neúspěšné sondy stavu.
Ochrana před útoky DDoS Má integrovanou ochranu před útoky DDoS vrstvy 3-4.
Firewall webových aplikací
Zvolte bránu firewall webových aplikací, která chrání vaši webovou aplikaci před webovými útoky. Firewall webových aplikací Azure (WAF) je firewall webových aplikací Azure a poskytuje centralizovanou ochranu před běžnými webovými zneužitími a ohroženími zabezpečení.
Příklad: Contoso Fiber zvolila firewall webových aplikací pro následující výhody:
Globální ochrana. Poskytuje zvýšenou globální ochranu webových aplikací bez obětování výkonu.
Ochrana botnetu Můžete nakonfigurovat pravidla ochrany robota pro monitorování útoků botnetu.
Parita s místním prostředím Místní řešení běželo za bránou firewall webových aplikací spravovanou IT.
Správce tajných kódů
Azure Key Vault použijte, pokud máte tajné kódy pro správu v Azure.
Příklad: Contoso Fiber má tajné kódy ke správě. Služba Key Vault používala z následujících důvodů:
šifrování Podporuje šifrování neaktivních uložených a přenášených dat.
Podporuje spravované identity. Aplikační služby můžou používat spravované identity pro přístup k úložišti tajných kódů.
Monitorování a protokolování: Usnadňuje přístup k auditu a generuje výstrahy při změně uložených tajných kódů.
Integrace. Podporuje dvě metody pro přístup k tajným kódům webové aplikace. Contoso Fiber může použít nastavení aplikace v hostitelské platformě (App Service), nebo může odkazovat na tajný kód v kódu aplikace (soubor vlastností aplikace).
Zabezpečení koncových bodů
Zvolte, jestli chcete povolit privátní přístup pouze ke službám Azure. Azure Private Link poskytuje přístup k řešením typu platforma jako služba přes privátní koncový bod ve vaší virtuální síti. Provoz mezi vaší virtuální sítí a službou prochází přes páteřní síť Microsoftu.
Příklad: Společnost Contoso Fiber zvolila private Link z následujících důvodů:
Lepší zabezpečení. Umožňuje aplikaci privátní přístup ke službám v Azure a snižuje síťové nároky úložišť dat, aby se chránila před únikem dat.
Minimální úsilí. Privátní koncové body podporují platformu webové aplikace a databázovou platformu, kterou webová aplikace používá. Obě platformy zrcadlí stávající místní nastavení, takže se vyžadují minimální změny.
Volba správné architektury
Po definování dostupných prostředků pro vaši webovou aplikaci a výběru správných cloudových služeb musíte určit nejlepší architekturu pro vaši webovou aplikaci. Vaše architektura musí podporovat vaše obchodní požadavky, technické požadavky a cíl na úrovni služeb.
Volba redundance architektury
Obchodní cíle určují úroveň infrastruktury a redundance dat, které vaše webová aplikace potřebuje. SLO webové aplikace poskytuje dobrý směrný plán pro pochopení požadavků na redundanci. Vypočítá složenou smlouvu SLA všechny závislosti na kritické cestě dostupnosti. Závislosti by měly zahrnovat služby Azure a jiná řešení než Microsoft.
Přiřaďte odhad dostupnosti pro každou závislost. Smlouvy o úrovni služeb (SLA) poskytují dobrý výchozí bod, ale smlouvy SLA nepočítá s kódem, strategiemi nasazení a rozhodováním o připojení k architektuře.
Příklad: Referenční implementace používá dvě oblasti v konfiguraci aktivní-pasivní. Společnost Contoso Fiber měla 99,9% SLO a potřebovala ke splnění cíle úrovně služby (SLO) použít dvě oblasti. Konfigurace aktivní-pasivní odpovídá cíli Contoso Fiber na minimální změny kódu pro tuto fázi na cestě ke cloudu. Konfigurace aktivní-pasivní poskytuje jednoduchou strategii dat. Vyhne se nutnosti nastavit synchronizaci dat na základě událostí, horizontální oddíly dat nebo jinou strategii správy dat. Veškerý příchozí provoz směřuje do aktivní oblasti. Pokud dojde k selhání v aktivní oblasti, společnost Contoso Fiber ručně zahájí plán převzetí služeb při selhání a směruje veškerý provoz do pasivní oblasti.
Volba síťové topologie
Zvolte správnou síťovou topologii pro požadavky na web a sítě. Hvězdicová síťová topologie je standardní konfigurace v Azure. Poskytuje výhody nákladů, správy a zabezpečení. Podporuje také možnosti hybridního připojení k místním sítím.
Příklad: Společnost Contoso Fiber zvolila hvězdicovou topologii sítě, aby se zvýšilo zabezpečení nasazení ve více oblastech s nižšími náklady a režií na správu.
Volba redundance dat
Zajištění spolehlivosti dat jejich distribucí napříč oblastmi a zónami dostupnosti Azure; čím větší je jejich geografické oddělení, tím vyšší spolehlivost.
Nastavte cíl bodu obnovení (RPO). Cíl bodu obnovení definuje maximální možnou ztrátu dat během výpadku a určuje, jak často data potřebují replikaci. Například cíl bodu obnovení o jedné hodině znamená přijetí až hodinové hodnoty nedávné ztráty dat.
Implementujte replikaci dat. Sladění replikace dat s vaší architekturou a RPO Azure obvykle podporuje synchronní replikaci v rámci zón dostupnosti. Využijte více zón k snadnému zvýšení spolehlivosti. U webových aplikací ve více oblastech v nastavení aktivní-pasivní replikace replikujte data do pasivní oblasti podle cíle bodu obnovení webové aplikace, čímž se zajistí, že frekvence replikace překročí cíl bodu obnovení. Konfigurace aktivní-aktivní vyžadují synchronizaci dat téměř v reálném čase napříč oblastmi, což může vyžadovat úpravy kódu.
Vytvořte plán převzetí služeb při selhání. Vývoj plánu převzetí služeb při selhání (zotavení po havárii) s využitím strategií reakce na výpadky, které jsou určeny výpadky nebo ztrátou funkčnosti. Zadejte cíle doby obnovení (RTO) pro maximální přijatelný výpadek. Ujistěte se, že proces převzetí služeb při selhání je rychlejší než RTO. Rozhodněte se o automatizovaných nebo ručních mechanismech převzetí služeb při selhání pro konzistenci a řízení a podrobně si promyslete návrat k normálnímu provoznímu procesu. Otestujte plán převzetí služeb při selhání, abyste zajistili efektivitu.
Příklad: Pro Azure Database for PostgreSQL používá referenční implementace zónově redundantní vysokou dostupnost se servery pohotovostního režimu ve dvou zónách dostupnosti. Databáze se také asynchronně replikuje do repliky pro čtení v pasivní oblasti.
Další krok
Tento článek vám ukázal, jak naplánovat implementaci modelu Reliable Web App. Dalším krokem je použití metod implementace modelu Reliable Web App.