V tomto článku se dozvíte, jak použít model Reliable Web App. 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í 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 Relecloud prodává lístky prostřednictvím své místní webové aplikace. Relecloud má pozitivní prognózu prodeje a předpokládá zvýšenou poptávku po webové aplikaci pro vytváření lístků. Pro splnění této poptávky definovali cíle pro webovou aplikaci:
- 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í
Místní infrastruktura Relecloudu nebyla nákladově efektivním řešením pro dosažení těchto cílů. Rozhodli se tedy, že migrace webové aplikace 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 Relecloud pro lístky místní, monolitická ASP.NET aplikace. Běžela na dvou virtuálních počítačích a měla databázi Microsoft SQL Serveru. Webová aplikace utrpěla běžné problémy se škálovatelností a nasazováním funkcí. Tento výchozí bod, jejich obchodní cíle a SLO řídily své volby služeb.
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: Relecloud jako aplikační platformu zvolil službu Aplikace Azure Service z následujících důvodů:
Smlouva SLA (High Service Level Agreement): Má vysokou smlouvu SLA, která splňuje cíl úrovně služeb (SLO) produkčního prostředí 99,9 %.
Nižší režijní náklady na správu: Jedná se o plně spravované řešení, které zpracovává škálování, kontroly stavu a vyrovnávání zatížení.
Podpora .NET: Podporuje verzi .NET, ve které je aplikace napsaná.
Funkce kontejnerizace: Webová aplikace může konvergovat v cloudu bez kontejnerizace, ale aplikační platforma také podporuje kontejnerizaci beze změny služeb Azure.
Automatické škálování: Webová aplikace může automaticky vertikálně navýšit, snížit nebo snížit kapacitu na základě uživatelského provozu a nastavení.
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: Relecloud zvolil Microsoft Entra ID z následujících důvodů:
Ověřování a autorizace: Aplikace musí ověřovat a autorizovat zaměstnance call centra.
Škálovatelné: Škáluje se tak, aby podporovala větší scénáře.
Řízení identit uživatelů: Zaměstnanci call centra můžou používat své stávající podnikové identity.
Podpora autorizačního protokolu: 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: Webová aplikace používala místně SQL Server a Relecloud chtěl použít existující schéma databáze, uložené procedury a funkce. V Azure je k dispozici několik produktů SQL, ale Relecloud zvolil Azure SQL Database z následujících důvodů:
Spolehlivost: Úroveň pro obecné účely poskytuje vysokou úroveň SLA a redundanci ve více oblastech. Může podporovat vysoké uživatelské zatížení.
Nižší režijní náklady na správu: Poskytuje spravovanou instanci databáze SQL.
Podpora migrace: Podporuje migraci databází z místního SQL Serveru.
Konzistence s místními konfiguracemi: Podporuje existující uložené procedury, funkce a zobrazení.
Odolnost: Podporuje zálohování a obnovení k určitému bodu v čase.
Odborné znalosti a minimální přepracování: SQL Database využívá interní odborné znalosti a vyžaduje minimální práci na přijetí.
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: Relecloud se rozhodl používat Přehledy aplikace z následujících důvodů:
Integrace se službou Azure Monitor: Poskytuje nejlepší integraci se službou Azure Monitor.
Detekce anomálií: Automaticky detekuje anomálie výkonu.
Řešení potíží: Pomáhá diagnostikovat problémy ve spuštěné aplikaci.
Monitorování: Shromažďuje informace o tom, jak uživatelé aplikaci používají, a umožňuje snadno sledovat vlastní události.
Mezera viditelnosti: 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: Zatížení webové aplikace Relecloud je silně zkosené směrem k prohlížení koncertů a podrobností o místě. Služba Azure Cache for Redis přidala z následujících důvodů:
Nižší režijní náklady na správu: Jedná se o plně spravovanou službu.
Rychlost a svazek: Má vysokou propustnost dat a nízkou latenci čtení pro běžně používaná a pomalá změna dat.
Různorodá podpora: Jedná se o jednotné umístění mezipaměti, které může 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: Externí stav relace podporuje nesticky relace.
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: Relecloud potřeboval nástroj pro vyrovnávání zatížení vrstvy 7, který by mohl směrovat provoz napříč několika oblastmi. Relecloud potřeboval webovou aplikaci pro více oblastí, aby splňovala cíl úrovně služby (SLO) 99,9 %. Relecloud zvolil Azure Front Door z následujících důvodů:
Globální vyrovnávání zatížení: Jedná se o nástroj pro vyrovnávání zatížení vrstvy 7, který může směrovat provoz napříč několika oblastmi.
Firewall webových aplikací: Nativně se integruje se službou Azure Web Application Firewall.
Flexibilita směrování: Umožňuje týmu aplikace nakonfigurovat příchozí přenos dat, aby podporoval budoucí změny v aplikaci.
Akcelerace provozu: K dosažení nejbližšího bodu přítomnosti v Azure používá jakékoli vysílání a najděte 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.
Síť pro doručování obsahu: Umístí Relecloud k používání sítě pro doručování obsahu. Síť pro doručování obsahu poskytuje akceleraci lokality.
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: Relecloud potřebný k ochraně webové aplikace před webovými útoky. Služba Azure Web Application Firewall používala z následujících důvodů:
Globální ochrana: Poskytuje vylepšenou globální ochranu webových aplikací bez obětování výkonu.
Ochrana botnetu: Tým může monitorovat a konfigurovat, aby řešil problémy zabezpečení z botnetů.
Parita s místním prostředím: Místní řešení běželo za firewallem webových aplikací spravovaným IT.
Snadné použití: Firewall webových aplikací se integruje se službou Azure Front Door.
Úložiště konfigurace
Zvolte, jestli chcete do webové aplikace přidat úložiště konfigurace aplikace. Aplikace Azure Configuration je služba pro centrální správu nastavení aplikace a příznaků funkcí. Projděte si osvědčené postupy konfigurace aplikací a rozhodněte se, jestli je tato služba vhodná pro vaši aplikaci.
Příklad: Relecloud chtěl nahradit konfiguraci založenou na souborech centrálním úložištěm konfigurace, které se integruje s aplikační platformou a kódem. Do architektury přidali konfiguraci aplikace z následujících důvodů:
Flexibilita: Podporuje příznaky funkcí. Příznaky funkcí umožňují uživatelům odhlásit a odhlásit se z dřívějších funkcí ve verzi Preview v produkčním prostředí bez opětovného nasazení aplikace.
Podporuje kanál Git: Zdroj pravdivých informací o konfiguračních datech potřebných jako úložiště Git. Kanál potřebný k aktualizaci dat v centrálním úložišti konfigurace.
Podporuje spravované identity: Podporuje spravované identity, které zjednodušují a pomáhají zabezpečit připojení k úložišti konfigurace.
Správce tajných kódů
Azure Key Vault použijte, pokud máte tajné kódy pro správu v Azure. Key Vault můžete začlenit do aplikací .NET pomocí objektu ConfigurationBuilder.
Příklad: Místní webová aplikace Relecloud uložila tajné kódy v konfiguračních souborech kódu, ale je lepším postupem zabezpečení externích tajných kódů. Spravované identity jsou sice upřednostňovaným řešením pro připojení k prostředkům Azure, ale Relecloud měl tajné kódy aplikací, které potřebují ke správě. Služba Relecloud používala službu Key Vault z následujících důvodů:
Šifrování: Podporuje šifrování neaktivních uložených dat a přenášených dat.
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: Poskytuje nativní integraci se službou Azure Configuration Store (App Configuration) a platformou pro hostování webů (App Service).
Řešení úložiště
Vyberte nejlepší řešení úložiště pro vaši webovou aplikaci. Další informace najdete v tématu Kontrola možností úložiště.
Příklad: Místní webová aplikace měla diskové úložiště připojené ke každému webovému serveru, ale tým chtěl použít řešení externího úložiště dat. Relecloud zvolil Službu Azure Blob Storage z následujících důvodů:
Zabezpečený přístup: Webová aplikace může eliminovat koncové body pro přístup k úložišti vystaveným veřejnému internetu s anonymním přístupem.
Šifrování: Šifruje neaktivní uložená data a přenášená data.
Odolnost: Podporuje zónově redundantní úložiště (ZRS). Zónově redundantní úložiště synchronně replikuje data napříč třemi zónami dostupnosti Azure v primární oblasti. Každá zóna dostupnosti je v samostatném fyzickém umístění, které má nezávislý výkon, chlazení a síť. Tato konfigurace by měla zajistit odolnost imagí lístků proti ztrátě.
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: Relecloud používal Private Link z následujících důvodů:
Vylepšená komunikace zabezpečení: Umožňuje aplikacím privátní přístup ke službám na platformě Azure a snižuje síťové nároky úložišť dat, které pomáhají chránit před únikem dat.
Minimální úsilí: Privátní koncové body podporují platformu webové aplikace a databázovou platformu, které webová aplikace používá. Obě platformy zrcadlí stávající místní konfigurace pro minimální změnu.
Zabezpečení sítě
Zvolte, jestli chcete do virtuálních sítí přidat služby zabezpečení sítě. Azure Firewall je stavová síťová brána firewall , která kontroluje síťový provoz. Azure Bastion umožňuje bezpečně se připojit k virtuálním počítačům bez vystavení portů RDP/SSH.
Příklad: Relecloud přijal hvězdicovou topologii sítě a chtěl do centra umístit sdílené služby zabezpečení sítě. Azure Firewall zlepšuje zabezpečení kontrolou veškerého odchozího provozu z paprsků, aby se zvýšilo zabezpečení sítě. Relecloud potřeboval Azure Bastion pro zabezpečená nasazení z přeskakujícího hostitele v podsíti DevOps.
Volba správné architektury
Po definování dostupných prostředků pro webovou aplikaci a výběru nejlepších cloudových služeb je potřeba určit nejlepší architekturu pro vaši webovou aplikaci. Vaše architektura musí podporovat vaše obchodní požadavky, technické požadavky a SLO.
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: Relecloud identifikoval služby na kritické cestě dostupnosti. Pro odhady dostupnosti použili smlouvy SLA Azure. Na základě výpočtu složené smlouvy SLA potřeboval Relecloud architekturu s více oblastmi, aby splňovala cíl úrovně služby (SLO) 99,9 %.
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: Relecloud zvolil 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.
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.