Perspektiva architektury Azure Well-Architected ve službě Azure App Service (Web Apps)
Azure App Service je platforma jako služba (PaaS), která poskytuje plně spravované hostitelské prostředí pro sestavování, nasazování a škálování webových aplikací. Jako řešení PaaS app Service abstrahuje základní infrastrukturu, která vám umožní soustředit se na vývoj aplikací. App Service (Web App) spouští aplikace v kontextu plánu služby App Service, který určuje prostředky, operační systém, oblast a cenový model (SKU) používaný k hostování vaší aplikace.
Tento článek předpokládá, že jako architekt jste si prostudovali rozhodovací strom výpočetních prostředků a jako výpočetní prostředek pro vaši úlohu zvolili App Service. Pokyny uvedené v tomto článku nabízejí doporučení pro architekturu, která jsou přiřazena k principům pilířů Azure Well-Architected Frameworku.
Důležitý
Jak používat tohoto průvodce
Každá část obsahuje kontrolní seznam návrhu , který zdůrazňuje architektonické úvahy a strategie pro Azure App Service. doporučení nabízejí konkrétní pokyny k implementaci těchto strategií.
Doporučení nepředstavují vyčerpávající seznam všech konfigurací dostupných pro funkci Web Apps služby Azure App Service a jejich závislostí. Namísto toho uvádějí klíčová doporučení přiřazená k perspektivám návrhu. Pomocí doporučení můžete vytvořit testování konceptu nebo optimalizovat vaše stávající prostředí.
Základní architektura, která ukazuje klíčová doporučení: základní architektura služby App.
oboru technologie
Tato kontrola se zaměřuje na vzájemně nesouvisející rozhodnutí pro následující prostředky Azure:
- Plány služby App Service
- Webové aplikace
Další nabídky Azure jsou přidružené ke službě App Service, jako jsou Azure Functions, Azure Logic Apps a App Service Environment. Tyto nabídky jsou mimo rozsah pro tento článek. Služba App Service Environment se občas odkazuje na objasnění funkcí nebo možností základních nabídek služby App Service.
Spolehlivost
Účelem pilíře spolehlivosti je poskytovat nepřetržitou funkčnost budování dostatečné odolnosti a schopnost rychle se zotavit z selhání.
Principy návrhu spolehlivosti poskytují strategii návrhu vysoké úrovně použité pro jednotlivé komponenty, systémové toky a systém jako celek.
Kontrolní seznam návrhu
Zahajte svou strategii návrhu na základě kontrolního seznamu pro revizi návrhu zaměřeného na spolehlivost. Určete její význam pro vaše obchodní požadavky a mějte na paměti úrovně a funkce služby App Service a její závislosti. Rozšiřte strategii tak, aby podle potřeby zahrnovala více přístupů.
určit prioritu toků uživatelů: Ne všechny toky jsou stejně důležité. Identifikujte kritické cesty ve vaší aplikaci a přiřaďte jednotlivým tokům priority, které vám pomůžou při rozhodování o návrhu. Návrh toku uživatele může ovlivnit, které úrovně služeb a počet instancí, které zvolíte pro plán a konfiguraci služby App Service.
Vaše aplikace může například zahrnovat front-endové a back-endové vrstvy, které komunikují prostřednictvím zprostředkovatele zpráv. Můžete se rozhodnout segmentovat úrovně ve více webových aplikacích, abyste umožnili nezávislé škálování, správu životního cyklu a údržbu. Umístění velké aplikace do jednoho plánu může vést k problémům s pamětí nebo procesorem a ovlivnit spolehlivost.
Pro zajištění optimálního výkonu na straně uživatelského rozhraní možná budete potřebovat více instancí na front-endu. Back-end ale nemusí vyžadovat stejný počet instancí.
Předvídat potenciální selhání: Plánování strategií zmírnění potenciálních selhání Následující tabulka uvádí příklady analýzy režimu selhání.
Selhání Zmírnění Selhání základních nebo abstraktovaných komponent služby App Service Mít redundanci komponent v instancích a závislostech. Monitorujte stav instancí, výkonu sítě a výkonu úložiště. Selhání externích závislostí Použijte vzory návrhu, jako je vzor Opakování a vzor jističe . Monitorujte externí závislosti a nastavte příslušné časové limity. Selhání kvůli směrování provozu do nefunkčních instancí Monitorování stavu instance Zvažte odezvu a vyhněte se odesílání požadavků na nefunkční instance. Další informace najdete v tématu analýza režimu selhání pro aplikace Azure.
Sestavení redundance: Sestavte redundanci v aplikaci a podpůrné infrastruktuře. Rozprostřete instance napříč zónami dostupnosti, aby se zlepšila odolnost proti chybám. Pokud selže jedna zóna, provoz se směruje do jiných zón. Nasaďte aplikaci napříč několika oblastmi, abyste měli jistotu, že vaše aplikace zůstane dostupná, i když dojde k výpadku celé oblasti.
Vytvořte podobné úrovně redundance v závislých službách. Příkladem je, když se instance aplikace připojují k blob úložišti. Zvažte konfiguraci přidruženého účtu úložiště s zónově redundantním úložištěm (ZRS), pokud aplikace používá zónově redundantní nasazení.
použít více instancí: Spuštění aplikace pouze na jedné instanci je okamžitým kritickým bodem selhání. Přidělte vaší aplikaci více instancí, abyste zajistili vysokou dostupnost. Pokud jedna instance selže, ostatní instance stále můžou zpracovávat příchozí požadavky. Mějte na paměti, že kód aplikace by měl být schopný zpracovat více instancí bez problémů se synchronizací při čtení nebo zápisu do zdrojů dat.
Mají redundanci v síťových komponentách. Použijte například zónově redundantní IP adresy a nástroje pro vyrovnávání zatížení.
mít spolehlivou strategii škálování: Neočekávané zatížení aplikace může být nespolehlivé. Zvažte správný přístup ke škálování na základě charakteristik vašich úloh. Horizontální škálování (horizontální navýšení kapacity) umožňuje přidat další instance pro distribuci zatížení, zatímco vertikální škálování (vertikální navýšení kapacity) zahrnuje zvýšení kapacity existující instance (procesor, paměť). Buďte opatrní při nadměrném zřizování, protože přidávání nepotřebných instancí zvyšuje náklady bez hmatatelných výhod výkonu.
Někdy můžete zvýšit kapacitu a zvládnout zátěž. Pokud se však zatížení stále zvyšuje, navyšte kapacitu na nové instance. Upřednostněte automatické nebo automatické škálování před ručními přístupy. Během operací škálování vždy udržujte vyrovnávací paměť dodatečné kapacity, aby se zabránilo snížení výkonu[Volba možnosti škálování pro App Service](Automatické škálování ve službě Azure App Service)
Úroveň plánu služby App Service , kterou zvolíte, ovlivňuje škálování z hlediska počtu instancí a výpočetních jednotek.
Zajistěte správnou inicializaci aplikace, aby se nové instance rychle zahřívaly a mohly přijímat požadavky.
Snažte se o bezstavové aplikace, kdykoli je to možné. Spolehlivé škálování stavu pomocí nových instancí může zvýšit složitost. Vezměte v úvahu externí úložiště dat, které můžete škálovat nezávisle, pokud potřebujete uložit stav aplikace. Uložení stavu relace v paměti může vést ke ztrátě stavu relace, pokud dojde k potížím s aplikací nebo službou App Service. Omezuje také možnost šíření zatížení mezi další instance.
Pravidelně testujte pravidla automatického škálování. Simulujte scénáře načítání a ověřte, že se vaše aplikace škáluje podle očekávání. Události škálování byste měli protokolovat, abyste mohli řešit problémy, které by mohly nastat, a optimalizovat strategii škálování v průběhu času.
Služba App Service má omezení počtu instancí v rámci plánu, což může mít vliv na spolehlivost škálování. Jednou strategií je použít identické razítka nasazení, přičemž každá spuštěná instance plánu služby App Service má vlastní koncový bod. Je nezbytné, abyste pro ochranu všech razítek použili externí nástroj pro vyrovnávání zatížení, který bude distribuovat provoz mezi razítka. Azure Application Gateway můžete použít pro nasazení s jednou zónou a Azure Front Door pro nasazení ve více oblastech. Tento přístup je ideální pro klíčové aplikace, kde je zásadní spolehlivost. Další informace najdete v základním nastavení kritickém pro misi u služby App Service.
Naplánujte obnovitelnost: Redundance je zásadní pro kontinuitu podnikových procesů. Přepnutí do jiné instance, pokud jedna instance není přístupná. Prozkoumejte možnosti automatického léčení ve službě App Service, jako je automatická oprava instancí.
Implementujte vzory návrhu, které zvládnou řádné snížení výkonu u přechodných selhání, jako jsou problémy s připojením k síti, a rozsáhlé události, jako jsou regionální výpadky. Zvažte následující vzory návrhu:
model Bulkhead segmentuje vaši aplikaci do izolovaných skupin, aby se zabránilo selhání v ovlivnění celého systému.
vzor vyrovnávání zatížení Queue-Based fronty pracovních položek, které slouží jako vyrovnávací paměť pro vyhlazení špiček provozu.
Vzor Opakování zpracovává přechodné chyby způsobené výpadky sítě, přerušenými databázovými připojeními nebo zaneprázdněnými službami.
model jističe brání aplikaci v opakovaném pokusu o provedení operace, která pravděpodobně selže.
Webové úlohy můžete použít ke spouštění úloh na pozadí ve webové aplikaci. Pokud chcete tyto úlohy spolehlivě spustit, ujistěte se, že aplikace, která hostuje vaši úlohu, běží nepřetržitě podle plánu nebo na základě triggerů řízených událostmi.
Další informace najdete v tématu vzory spolehlivosti.
Proveďte testování spolehlivosti: Proveďte zátěžové testování a vyhodnoťte spolehlivost a výkon vaší aplikace při zatížení. Testovací plány by měly zahrnovat scénáře, které ověřují vaše automatizované operace obnovení.
Pomocí zavádění chyb úmyslně vyvolejte selhání a ověřte své samonápravné a samoochranné mechanismy. Prozkoumejte knihovnu chyb , kterou poskytuje Azure Chaos Studio.
App Service omezuje prostředky na hostované aplikace. Tento limit určuje plán služby App Service. Ujistěte se, že testy ověřují, že aplikace běží v rámci těchto limitů prostředků. Další informace najdete v tématu limity, kvóty a omezení předplatného a služeb Azure.
použijte funkci Kontrola stavu k identifikaci nereagujících pracovníků: Služba App Service má funkce, které pravidelně odesílají ping na konkrétní cestu vaší webové aplikace. Platforma použije ping na tuto cestu, aby určila, jestli je vaše aplikace funkční a odpovídá na požadavky. Když se váš web škáluje na více instancí, Služba App Service vyloučí všechny instance, které nejsou v pořádku, z obsluhy požadavků a zlepší vaši celkovou dostupnost. Cesta kontroly stavu vaší aplikace by se měla dotazovat na důležité součásti vaší aplikace, jako je databáze, mezipaměť nebo služba zasílání zpráv. Tím se zajistí, že stav vrácený cestou kontroly stavu je přesným obrázkem celkového stavu vaší aplikace. Nastavte svoji cestu pro kontrolu stavu
použít funkci automatického opravování: Někdy může u vaší aplikace docházet k neočekávanému chování, které by bylo možné vyřešit jednoduchým restartováním. Funkce automatického opravování vám umožňují definovat podmínku, která by aktivovala automatické hojení, a akci, která se spustí při splnění podmínky. diagnostické nástroje služby App Service a funkce automatického opravy
Zpráva o skóre odolnosti služby App Service: Pokud chcete zkontrolovat přizpůsobená doporučení osvědčených postupů, podívejte se na Zprávu o skóre odolnosti služby App Service.Zpráva o skóre odolnosti služby App Service
Doporučení
| Doporučení | Prospěch |
|---|---|
| (App Service) Zvolte úroveň Premium v3 plánu služby App Service pro produkční úlohy. Nastavte maximální a minimální počet pracovníků podle plánování kapacity. Více informací najdete v přehledu plánu služby App Service . |
Plán služby App Service úrovně Premium V3 nabízí pokročilé funkce škálování a zajišťuje redundanci v případě selhání. |
| (App Service) Povolit zónovou redundanci. Zvažte zřízení více než tří instancí za účelem zvýšení odolnosti proti chybám. Zkontrolujte regionální podporu redundance zón, protože tuto funkci nenabízí všechny oblasti. |
Vaše aplikace dokáže odolat selhání v jedné zóně, pokud jsou instance rozděleny mezi více zón. Provoz se automaticky přesune na funkční instance v jiných zónách a zachová spolehlivost aplikace, pokud jedna zóna není dostupná. |
| (Webová aplikace) Zvažte zakázání funkce spřažení požadavků aplikace (ARR). Spřažení ARR vytvoří rychlé relace, které přesměrují uživatele na uzel, který zpracovával předchozí požadavky. | Příchozí požadavky se rovnoměrně distribuují napříč všemi dostupnými uzly, když zakážete spřažení ARR. Rovnoměrně distribuované požadavky zabraňují, aby jakýkoli jednotlivý uzel nepřetížil síťový provoz. Požadavky je možné bez problémů přesměrovat na jiné uzly, které jsou v pořádku, pokud uzel není k dispozici. Vyhněte se spřažení relací, abyste zajistili, že vaše instance služby App Service zůstane bezstavová. Bezstavová služba App Service snižuje složitost a zajišťuje konzistentní chování napříč uzly. Odeberte lepkavé relace, aby App Service mohla přidávat nebo odebírat instance pro horizontální škálování. |
| (Webová aplikace) Definujte pravidla automatického léčení na základě počtu požadavků, pomalých požadavků, limitů paměti a dalších indikátorů, které jsou součástí výchozích hodnot výkonu. Tuto konfiguraci zvažte jako součást strategie škálování. | Automatická pravidla opravy pomáhají aplikaci automaticky obnovit z neočekávaných problémů. Nakonfigurovaná pravidla aktivují akce opravy, když dojde k porušení prahových hodnot. Automatické opravy umožňují automatickou proaktivní údržbu. |
| (Webová aplikace) Povolit funkci kontroly stavu a zadat cestu, která odpovídá na požadavky kontroly stavu. | Kontroly stavu můžou včas detekovat problémy. Systém pak může automaticky provést nápravné akce, když selže požadavek na kontrolu stavu. Nástroj pro vyrovnávání zatížení směruje provoz mimo instance, které nejsou v pořádku, což uživatele směruje na uzly, které jsou v pořádku. |
Bezpečnost
Účelem pilíře zabezpečení je poskytnout důvěrnosti, integritě a dostupnosti zárukám úlohy.
Principy návrhu zabezpečení poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů použitím přístupů k technickému návrhu týkajícímu se hostování ve službě App Service.
Kontrolní seznam návrhu
Zahajte svou strategii návrhu na základě kontrolního seznamu pro kontrolu návrhu pro zabezpečení a identifikujte zranitelnosti a kontrolní mechanismy ke zlepšení zabezpečení. Rozšiřte strategii tak, aby podle potřeby zahrnovala více přístupů.
Kontrola standardních hodnot zabezpečení: Pokud chcete zlepšit stav zabezpečení aplikace hostované v plánu služby App Service, projděte si standardní hodnoty zabezpečení pro službu App Service.
Používat nejnovější modul runtime a knihovny: Důkladně otestujte sestavení aplikace, než provedete aktualizace, abyste včas zachytili problémy a zajistili hladký přechod na novou verzi. App Service podporuje zásady podpory modulu runtime jazyka pro aktualizaci existujících stohů a vyřazení stohů s ukončenou podporou.
Vytvoření segmentace pomocí izolačních hranic k zamezení průniku: Aplikujte segmentaci identity. Například implementovat řízení přístupu na základě role (RBAC) pro přiřazení konkrétních oprávnění na základě rolí. Pokud chcete omezit přístupová práva jenom na to, co je potřeba, postupujte podle principu nejnižšího oprávnění. Vytvořte také segmentaci na úrovni sítě. vložení aplikací služby App Service do virtuální sítě Azure pro izolaci a definování skupin zabezpečení sítě (NSG) pro filtrování provozu.
Plány služby App Service nabízejí úroveň služby App Service Environment, která poskytuje vysoký stupeň izolace. Se službou App Service Environment získáte vyhrazené výpočetní prostředky a sítě.
Použít řízení přístupu u identit: Omezte jak vnitřní přístup k webové aplikaci, tak přístup ven z webové aplikace k jiným prostředkům. Tato konfigurace používá řízení přístupu u identit a pomáhá udržovat celkový stav zabezpečení úlohy.
Pro všechny potřeby ověřování a autorizace použijte ID Microsoft Entra. Používejte předdefinované role, jako je přispěvatel webových plánů, přispěvatel webua obecný přispěvatel, čtenář avlastníka .
Použít ovládací prvky zabezpečení sítě: Integrujte službu App Service s virtuální sítí k řízení odchozího provozu. Pomocí privátních koncových bodů můžete řídit příchozí provoz a omezit přístup ke službě App Service z vaší virtuální sítě a zakázat veřejný přístup k internetu. zabezpečení sítě, řízení příchozího a odchozího provozu
Nasaďte firewall webových aplikací (WAF) pro ochranu před běžnými ohroženími zabezpečení. Application Gateway i Azure Front Door mají integrované funkce WAF.
Nakonfigurujte pravidla reverzního proxy serveru a nastavení sítě odpovídajícím způsobem, abyste dosáhli požadované úrovně zabezpečení a řízení. Přidejte například pravidla NSG v podsíti privátního koncového bodu, která budou přijímat pouze provoz z reverzního proxy serveru.
Odchozí provoz z aplikace do jiných služeb PaaS by měl být přes privátní koncové body. Zvažte umístění komponenty brány firewall, která omezí odchozí provoz do veřejného internetu. Oba přístupy brání exfiltraci dat.
Pro podrobný přehled si přečtěte téma síťové funkce služby App Service.
Šifrování dat: Ochrana přenášených dat pomocí protokolu TLS (Transport Layer Security). K úplnému šifrování neaktivních uložených dat použijte klíče spravované zákazníkem. Další informace najdete v tématu Šifrování neaktivních uložených dat pomocí klíčů spravovaných zákazníkem.
Nepoužívejte starší protokoly, jako jsou TLS 1.0 a 1.1. Ujistěte se, že všechny webové aplikace používají jenom HTTPS a vynucujte protokol TLS 1.2 nebo vyšší. Výchozí minimální verze protokolu TLS je 1.2. Další informace naleznete v přehledu TLS služby App Service .
Všechny instance vaší služby App Service mají výchozí název domény. Použijte vlastní doménu a zabezpečte ji pomocí certifikátů.
kompletní šifrování TLS: Kompletní šifrování TLS je k dispozici v plánech služby App Service úrovně Premium. Tato funkce šifruje provoz během celé transakce a minimalizuje riziko zachycení provozu.
Snížit prostor pro útoky: Odeberte výchozí konfigurace, které nepotřebujete. Můžete například zakázat vzdálené ladění, lokální ověřování pro weby Správce zdrojového kódu (SCM) a základní ověřování. Zakažte nezabezpečené protokoly, jako je HTTP a FILE Transfer Protocol (FTP). Vynucujte konfigurace prostřednictvím zásad Azure. Další informace najdete v tématu zásady Azure.
Implementace omezujících zásad sdílení prostředků mezi zdroji (CORS): Pomocí omezujících zásad CORS ve webové aplikaci můžete přijímat pouze žádosti z povolených domén, hlaviček a dalších kritérií. Vynucujte zásady CORS pomocí integrovaných definic zásad Azure.
Používat spravované identity: Povolte spravovaným identitám pro službu App Service zabezpečený přístup k dalším službám Azure, aniž byste museli spravovat přihlašovací údaje. Informace o spravovaných identitách.
Chránit tajné kódy aplikací: Potřebujete zpracovávat citlivé informace, jako jsou klíče rozhraní API nebo ověřovací tokeny. Místo pevného zakódování těchto tajných kódů přímo do kódu aplikace nebo konfiguračních souborů můžete v nastavení aplikace použít odkazy služby Azure Key Vault. Když se aplikace spustí, App Service automaticky načte hodnoty tajných kódů ze služby Key Vault pomocí spravované identity aplikace.
Povolte záznamy prostředků pro vaši aplikaci: Povolte záznamy prostředků pro vaši aplikaci k vytvoření komplexních tras aktivit, které poskytují cenná data během vyšetřování po bezpečnostních incidentech. Podrobné pokyny najdete v pokynech k monitorování protokolů .
Při vyhodnocování hrozeb zvažte protokolování jako součást procesu modelování hrozeb.
Doporučení
| Doporučení | Prospěch |
|---|---|
| (Webová aplikace) Přiřazení spravovaných identit webové aplikaci. Pokud chcete zachovat hranice izolace, nesdílejte ani znovu nepoužívejte identity napříč aplikacemi. Ujistěte se, že jste bezpečně připojeni k registru kontejneru , pokud používáte kontejnery pro nasazení. |
Aplikace načte tajné kódy ze služby Key Vault, aby se ověřila vnější komunikace z aplikace. Azure spravuje identitu a nevyžaduje zřízení ani rotaci žádných tajemství. Máte jedinečné identity pro granularitu řízení. Jedinečné identity usnadňují odvolání, pokud dojde k ohrožení identity. |
| (Webová aplikace) Nakonfigurujte vlastní domény pro aplikace. Zakažte HTTP a přijměte pouze požadavky HTTPS. |
Vlastní domény umožňují zabezpečenou komunikaci prostřednictvím protokolu HTTPS pomocí protokolu TLS (Transport Layer Security), který zajišťuje ochranu citlivých dat a vytváří důvěryhodnost uživatelů. |
| (Webová aplikace) vyhodnotuje, jestli integrované ověřování služby App Service je správný mechanismus pro ověřování uživatelů, kteří přistupují k vaší aplikaci. Integrované ověřování služby App Service se integruje s ID Microsoft Entra. Tato funkce zpracovává ověřování tokenů a správu identit uživatelů napříč několika zprostředkovateli přihlašování a podporuje OpenID Connect. Díky této funkci nemáte autorizaci na podrobné úrovni a nemáte mechanismus pro testování ověřování. | Při použití této funkce nemusíte používat knihovny ověřování v kódu aplikace, což snižuje složitost. Uživatel je již ověřen, když požadavek dorazí k aplikaci. |
| (Webová aplikace) Nakonfigurujte aplikaci pro integraci virtuální sítě. Použijte privátní koncové body pro aplikace App Service. Zablokujte veškerý veřejný provoz. Směrování načítání image kontejneru přes integraci virtuální sítě. Veškerý odchozí provoz z aplikace prochází virtuální sítí. |
Získejte výhody zabezpečení při používání virtuální sítě Azure. Aplikace může například bezpečně přistupovat k prostředkům v síti. Přidejte privátní koncový bod, který pomáhá chránit vaši aplikaci. Privátní koncové body omezují přímé vystavení veřejné síti a umožňují řízený přístup přes reverzní proxy server. |
| (Webová aplikace) Jak provést posílení zabezpečení: - Zakázat základní ověřování, která používá uživatelské jméno a heslo ve prospěch ověřování založeného na ID microsoftu Entra. – Vypněte vzdálené ladění, aby se neotevíraly příchozí porty. – Povolte zásady CORS, aby zpřísnily příchozí požadavky. - Zakažte protokoly, například FTP. |
Jako zabezpečenou metodu nasazení nedoporučujeme základní ověřování. Microsoft Entra ID využívá ověřování založené na tokenech OAuth 2.0, které nabízí řadu výhod a vylepšení, která řeší omezení spojená se základním ověřováním. Zásady omezují přístup k prostředkům aplikace, povolují pouze požadavky z konkrétních domén a zabezpečí žádosti mezi oblastmi. |
| (Webová aplikace) vždy používat odkazy služby Key Vault jako nastavení aplikace. |
Tajné kódy jsou oddělené od konfigurace vaší aplikace. Nastavení aplikace se šifruje v klidovém stavu. App Service také spravuje obměny tajných kódů. |
| (App Service) povolit Microsoft Defender for Cloud for App Service. | Získejte ochranu prostředků spuštěných v plánu služby App Service v reálném čase. Chraňte se před hrozbami a vylepšete celkový stav zabezpečení. |
| (App Service) Povolení diagnostického protokolování a přidání monitorovacích nástrojů do vaší aplikace. Protokoly se odesílají do účtů Azure Storage, Azure Event Hubs a Log Analytics. Další informace o typech protokolů auditu naleznete v tématu Podporované typy protokolů. | Protokolování zachycuje vzory přístupu. Zaznamenává relevantní události, které poskytují cenné přehledy o interakci uživatelů s aplikací nebo platformou. Tyto informace jsou zásadní pro účely odpovědnosti, dodržování předpisů a zabezpečení. |
Optimalizace nákladů
Optimalizace nákladů se zaměřuje na detekci vzorců útraty, stanovení priorit investic do kritických oblastí a optimalizaci v jiných tak, aby byly v souladu s rozpočtem organizace při plnění obchodních požadavků.
Principy návrhu optimalizace nákladů poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů a dosažení kompromisů v technickém návrhu souvisejícím s vašimi webovými aplikacemi a prostředím, ve kterém běží.
Kontrolní seznam návrhu
Zahajte strategii návrhu na základě kontrolního seznamu pro kontrolu návrhu pro optimalizaci nákladů pro investice a dolaďte návrh tak, aby úloha odpovídala rozpočtu přidělenému pro danou úlohu. Váš návrh by měl využívat správné možnosti Azure, monitorovat investice a hledat příležitosti k optimalizaci v průběhu času.
Odhad počátečních nákladů: V rámci cvičení modelování nákladů použijte cenovou kalkulačku Azure k vyhodnocení přibližných nákladů spojených s různými úrovněmi na základě počtu instancí, které plánujete spustit. Každá úroveň služby App Service nabízí různé možnosti výpočetních prostředků.
Průběžně monitorujte nákladový model a sledujte výdaje.
Vyhodnocení slevových možností: Vyšší úrovně zahrnují vyhrazené výpočetní instance. Slevu za rezervaci můžete použít, pokud má vaše úloha předvídatelný a konzistentní vzor využití. Ujistěte se, že analyzujete data o využití a určete typ rezervace, která vyhovuje vašim úlohám. Další informace najdete v tématu Úspora nákladů s rezervovanými instancemi služby App Service.
Vysvětlení měřičů využití: Azure účtuje hodinovou sazbu s poměrem za sekundu na základě cenové úrovně vašeho plánu služby App Service. Poplatky se vztahují na každou instance rozšíření v rámci vašeho plánu podle času přidělení instance VM. Věnujte pozornost málo využívaným výpočetním prostředkům, které mohou zvýšit vaše náklady v důsledku přetížení kvůli neoptimálnímu výběru produktové položky nebo špatně nakonfigurovanému škálování směrem dolů.
Další funkce služby App Service, jako je registrace vlastní domény a vlastní certifikáty, můžou přidávat náklady. Další prostředky, jako jsou virtuální sítě, které izolují vaše řešení, nebo úložiště klíčů pro ochranu citlivých dat úloh, jež se integrují s vašimi prostředky služby App Service, mohou také navyšovat náklady. Další informace o modelu fakturace App Services najdete v tématu .
Zvažte kompromisy mezi hustotou a izolací: Plány služby App Service můžete použít k hostování více aplikací na stejném výpočetním prostředí, což šetří náklady se sdílenými prostředími. Další informace naleznete v tématu Kompromisy.
Vyhodnotit účinek vaší strategie škálování na náklady: Při implementaci automatického škálování musíte správně navrhovat, testovat a konfigurovat pro škálování směrem nahoru a dolů. Stanovení přesných maximálních a minimálních limitů automatického škálování
Proaktivně inicializujete aplikaci pro spolehlivé škálování. Například nečekejte, dokud procesor nedosáhne 95% využití. Místo toho aktivujte škálování přibližně na 65%, aby bylo možné přidělit a inicializovat nové instance během procesu škálování dostatek času. Tato strategie ale může vést k nevyužité kapacitě.
Doporučujeme kombinovat a vyvážit mechanismy vertikálního navýšení a horizontálního navýšení kapacity. Aplikace může například nějakou dobu vertikálně navýšit kapacitu a poté dle potřeby horizontálně navýšit kapacitu. Prozkoumejte vysoké úrovně, které nabízejí velkou kapacitu a efektivní využití prostředků. Na základě vzorů využití jsou vyšší úrovně Premium často nákladově efektivnější, protože jsou schopnější.
Optimalizace nákladů na prostředí: Zvažte úroveň Basic nebo Free pro spouštění předprodukčních prostředí. Tyto úrovně jsou nízkovýkonné a nízkonákladové. Pokud používáte úroveň Basic nebo Free, použijte zásady správného řízení k vynucení úrovně, omezení počtu instancí a procesorů, omezení škálování a omezení uchovávání protokolů.
Implementace vzorů návrhu: Tato strategie snižuje objem požadavků, které vaše úloha generuje. Zvažte použití vzorů, jako jsou backendy pro frontendy a vzor agregace brány, což může minimalizovat počet požadavků a snížit náklady.
Pravidelně kontrolovat náklady související s daty: Rozšířené doby uchovávání dat nebo nákladné úrovně úložiště můžou vést k vysokým nákladům na úložiště. Další výdaje se můžou kumulovat z důvodu využití šířky pásma i dlouhodobého uchovávání dat protokolování.
Zvažte implementaci ukládání do mezipaměti, abyste minimalizovali náklady na přenos dat. Začněte místním ukládáním do mezipaměti v paměti a pak prozkoumejte možnosti distribuovaného ukládání do mezipaměti, abyste snížili počet požadavků na back-end databázi. Pokud se vaše databáze nachází v jiné oblasti, zvažte náklady na přenosy šířky pásma, které jsou spojené s komunikací mezi oblastmi.
Optimalizace nákladů na nasazení: Využijte sloty nasazení k optimalizaci nákladů. Slot běží ve stejném výpočetním prostředí jako produkční instance. Používejte je strategicky pro scénáře, jako je blue-green nasazení, umožňující přepínání mezi sloty. Tento přístup minimalizuje výpadky a zajišťuje hladké přechody.
Používejte sloty nasazení s opatrností. Můžete zavádět problémy, jako jsou výjimky nebo úniky paměti, které mohou ovlivnit jak stávající instance, tak i nové instance. Ujistěte se, že důkladně testujete změny. Provozní pokyny najdete v tématu provozní efektivita.
Doporučení
| Doporučení | Prospěch |
|---|---|
| (App Service) Zvolte úroveň Free nebo Basic pro nižší prostředí. Tyto úrovně doporučujeme pro experimentální použití. Vrstvy odeberte, pokud je už nepotřebujete. | Úrovně Free a Basic jsou v porovnání s vyššími úrovněmi vhodné pro rozpočet. Poskytují nákladově efektivní řešení pro neprodukční prostředí, která nepotřebují úplné funkce a výkon plánů Premium. |
| (App Service) Využijte slevy a prozkoumejte upřednostňované ceny pro: - Nižší prostředí s plány pro vývoj/testování. - rezervace Azure a úsporné plány Azure pro vyhrazené výpočetní prostředky, které zřídíte ve vrstvě Premium V3 a ve službě App Service Environment. Používejte rezervované instance pro stabilní úlohy, které mají předvídatelné vzory použití. |
Plány pro vývoj/testování poskytují snížené sazby za služby Azure, díky kterým jsou nákladově efektivní pro neprodukční prostředí. Využijte rezervované instance k předplacení výpočetních prostředků a získejte významné slevy. |
| (Webová aplikace) Sledujte náklady, které vznikají využíváním zdrojů služby App Service. Spusťte nástroj pro analýzu nákladů na webu Azure Portal. Vytvářet rozpočty a výstrahy k upozornění zúčastněných stran. |
V rané fázi můžete identifikovat špičky nákladů, neekektivnosti nebo neočekávané výdaje. Tento proaktivní přístup vám pomůže zajistit rozpočtovou kontrolu, aby se zabránilo nadměrnému přečerpání. |
| (App Service) Škálování při poklesu poptávky Pokud se chcete škálovat, definujte pravidla škálování, která snížit počet instancí ve službě Azure Monitor. | Zabránit plýtvání a snížit zbytečné výdaje. |
Efektivita provozu
Efektivita provozu se primárně zaměřuje na postupy vývojových postupů, pozorovatelnosti a správy verzí.
Principy návrhu Efektivita provozu poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů směrem k provozním požadavkům úlohy.
Kontrolní seznam návrhu
Začněte strategii návrhu založenou na kontrolním seznamu pro kontrolu návrhu pro provozní efektivitu pro definování procesů pozorovatelnosti, testování a nasazení souvisejících s Web Apps.
Spravovat vydané verze: Efektivní správa vydaných verzí pomocí slotů nasazení Aplikaci můžete nasadit do slotu, provést testování a ověřit její funkčnost. Po ověření můžete aplikaci bezproblémově přesunout do produkčního prostředí. Tento proces neúčtuje další náklady, protože slot běží ve stejném prostředí virtuálního stroje jako produkční instance.
Použijte prohození s náhledem (vícefázové prohození) Prohození s náhledem umožňuje otestovat aplikaci v přípravných slotech proti produkčním nastavením a také aplikaci zahřát. Po provedení testů a připravení všech potřebných cest pak můžete provést přepnutí a aplikace začne běžet přijímat produkční provoz bez restartování.
Spusťte automatizované testy: Před povýšením nové verze webové aplikace důkladně otestujte její výkon, funkčnost a integraci s dalšími komponentami. Použijte azure Load Testing, který se integruje s Apache JMeter, což je oblíbený nástroj pro testování výkonu. Prozkoumejte automatizované nástroje pro další typy testování, jako je Například Fantom pro funkční testování.
Automatizace nasazení: Použití kanálů CI/CD s Azure DevOps nebo GitHub Actions k automatizaci nasazení a snížení ručního úsilí průběžného nasazování do služby Azure App Service.
Nasazení neměnných jednotek: Implementujte vzor kolků nasazení pro rozdělení služby App Service do neměnného razítka. App Service podporuje použití kontejnerů, které jsou ze své podstaty neměnné. Zvažte vlastní kontejnery pro webovou aplikaci služby App Service.
Každý modul představuje samostatnou jednotku, kterou můžete rychle rozšířit nebo zmenšit. Jednotky založené na tomto razítku jsou dočasné a bezstavové. Bezstavový návrh zjednodušuje provoz a údržbu. Tento přístup je ideální pro klíčové aplikace. Příklad najdete v tématu základní hodnoty kritické pro službu App Service.
K označení jednotek s opakovatelností a konzistencí použijte technologii infrastruktury jako kódu (IaC), například Bicep.
Udržovat produkční prostředí v bezpečí: Vytvořte samostatné plány služby App Service pro spouštění produkčních a předprodukčních prostředí. Neprovádejte změny přímo v produkčním prostředí, abyste zajistili stabilitu a spolehlivost. Samostatné instance umožňují flexibilitu při vývoji a testování před povýšením změn do produkčního prostředí.
Používejte nízká prostředí k prozkoumání nových funkcí a konfigurací izolovaným způsobem. Udržujte vývojová a testovací prostředí dočasné.
Spravovat certifikáty: Pro vlastní domény musíte spravovat certifikáty TLS.
Máte zavedené procesy pro nákup, obnovení a ověření certifikátů. Pokud je to možné, tyto procesy přesměrováte do služby App Service. Pokud používáte vlastní certifikát, musíte jeho obnovení spravovat. Zvolte přístup, který nejlépe odpovídá vašim požadavkům na zabezpečení.
| Doporučení | Prospěch |
|---|---|
| (Webová aplikace) Monitorujte stav vašich instancí a aktivujte sondy stavu instance. Nastavte konkrétní cestu pro zpracování požadavků zdravotní sondy. |
Problémy můžete rychle rozpoznat a provést nezbytné akce pro zachování dostupnosti a výkonu. |
| (Webová aplikace) Povolení diagnostických protokolů pro aplikaci a instanci. Časté protokolování může zpomalit výkon systému, přidat náklady na úložiště a zavést riziko, pokud máte nezabezpečený přístup k protokolům. Postupujte podle těchto osvědčených postupů: - Zaznamenejte správnou úroveň informací. – Nastavte zásady uchovávání informací. – Uchovávejte záznam auditu autorizovaných přístupů a neoprávněných pokusů. – Zacházet s protokoly jako s daty a používat ovládací prvky ochrany dat. |
Diagnostické protokoly poskytují cenné přehledy o chování vaší aplikace. Monitorujte vzory provozu a identifikujte anomálie. |
| (Webová aplikace) Využijte výhod spravovaných certifikátů služby App Service k přesměrování správy certifikace do Azure. | App Service automaticky zpracovává procesy, jako jsou nákupy certifikátů, ověření certifikátu, obnovení certifikátu a import certifikátů ze služby Key Vault. Případně nahrajte certifikát do služby Key Vault a autorizujete poskytovatele prostředků služby App Service, aby k němu přistupoval. |
| (App Service) Ověřte změny aplikace v přípravném slotu před jejich výměnou s produkčním slotem. | Vyhněte se výpadkům a chybám. Pokud po výměně zjistíte problém, rychle se vraťte k poslednímu známému dobrému stavu. |
Efektivita výkonu
Efektivita výkonu se týká zachování uživatelského prostředí, i když se zvyšuje zatížení správou kapacity. Strategie zahrnuje škálování prostředků, identifikaci a optimalizaci potenciálních kritických bodů a optimalizaci výkonu ve špičce.
Principy návrhu efektivity výkonu poskytují strategii návrhu na vysoké úrovni pro dosažení těchto cílů týkajících se kapacity s ohledem na očekávané využití.
Kontrolní seznam návrhu
Začněte strategii návrhu, která je založena na kontrolním seznamu pro revizi návrhu výkonnostní efektivity pro definování výchozí hodnoty na základě klíčových ukazatelů výkonu pro webové aplikace.
Identifikovat a monitorovat indikátory výkonu: Nastavte cíle klíčových ukazatelů pro aplikaci, jako je objem příchozích požadavků, doba, po kterou aplikace reaguje na požadavky, čekající požadavky a chyby v odpovědích HTTP. Zvažte klíčové ukazatele jako součást standardních hodnot výkonu pro úlohu.
Zachyťte metriky služby App Service, které tvoří základ ukazatelů výkonu. Shromážděte protokoly, abyste získali přehled o využití prostředků a aktivitách. Ke shromažďování a analýze dat o výkonu z aplikace použijte nástroje pro monitorování výkonu (APM), jako je Application Insights. Další informace najdete v referenci k datům monitorování služby App Service .
Zahrnuje instrumentaci na úrovni kódu, trasování transakcí a profilaci výkonu.
Posouzení kapacity: Simulujte různé scénáře uživatelů a určete optimální kapacitu, kterou potřebujete ke zpracování očekávaného provozu. Pomocí zátěžového testování můžete pochopit, jak se vaše aplikace chová pod různými úrovněmi zatížení.
Vyberte správnou úroveň: Pro produkční úlohy použijte vyhrazené výpočetní prostředky. Úrovně Premium V3 nabízejí větší skladové položky se zvýšenou kapacitou paměti a procesoru, více instancí a dalších funkcí, jako je redundance zón. Další informace najdete v tématu cenová úroveň Premium V3.
Optimalizovat strategii škálování: Pokud je to možné, použijte automatické škálování místo ruční úpravy počtu instancí při změně zatížení aplikace. Při automatickém škálování služba App Service upravuje kapacitu serveru na základě předdefinovaných pravidel nebo triggerů. Ujistěte se, že provedete odpovídající testování výkonu a nastavíte správná pravidla pro správné aktivační události.
Pokud upřednostníte jednoduchost během počátečního nastavení, použijte možnost automatického škálování, která nevyžaduje definování pravidel a stačí nastavit limity.
Máte k dispozici dostatek prostředků, abyste zajistili optimální výkon. Přidělte prostředky odpovídajícím způsobem, aby se zachovaly výkonnostní cíle, jako je doba odezvy nebo propustnost. Zvažte nadměrné přidělení prostředků v případě potřeby.
Při definování pravidel automatického škálování přihlédněte k době, kterou aplikace potřebuje k inicializaci. Zvažte tuto režii při činění všech rozhodnutí o škálování.
Použít ukládání do mezipaměti: Načítání informací z prostředku, který se často nemění a je nákladný pro přístup, má vliv na výkon. Složité dotazy, včetně spojení a několika vyhledávání, ovlivňují dobu běhu. Ukládáním do mezipaměti minimalizujte dobu zpracování a latenci. Uložte výsledky dotazů do mezipaměti, abyste se vyhnuli opakovaným dotazům do databáze nebo back-end systému a zkrátili dobu zpracování pro následné požadavky.
Další informace o používání místní a distribuované mezipaměti v úloze naleznete v tématu Ukládání do mezipaměti.
Zkontrolujte antivzory výkonu: Abyste zajistili, že webová aplikace funguje a škáluje v souladu s vašimi obchodními požadavky, vyhněte se typickým antivzorům. Tady jsou některé antipatterny, které App Service opravuje.
Antivzor Popis zaneprázdněný front-end Úlohy náročné na prostředky můžou zvýšit dobu odezvy uživatelských požadavků a způsobit vysokou latenci.
Přesuňte procesy, které spotřebovávají významné prostředky, do samostatného back-endu. Pomocí zprostředkovatele zpráv zařadíte úlohy náročné na prostředky, které back-end převezme do asynchronního procesu.bez ukládání do mezipaměti Obsluha požadavků z zprostředkující mezipaměti před back-endovou databází za účelem snížení latence hlučný soused Víceklientové systémy sdílejí prostředky mezi tenanty. Aktivita jednoho tenanta může mít negativní vliv na použití systému jiného tenanta. App Service Environment poskytuje plně izolované a vyhrazené prostředí pro spouštění aplikací App Service.
Doporučení
| Doporučení | Prospěch |
|---|---|
| (App Service) Povolit nastavení AlwaysOn, když aplikace sdílejí jeden plán služby App Service. Aplikace App Service se automaticky vypnou, když jsou nečinné, ke snížení spotřeby prostředků. Další požadavek aktivuje studený start, což může způsobit vypršení časových limitů požadavků. | Aplikace není nikdy uvolněna, pokud je povolena funkce Always On. |
| (Web Apps) Zvažte použití HTTP/2 pro aplikace ke zlepšení efektivity protokolu. | Zvolte HTTP/2 přes HTTP/1.1, protože HTTP/2 plně multiplexuje připojení, znovu používá připojení ke snížení režie a komprimuje hlavičky, aby se minimalizoval přenos dat. |
Kompromisy
Pokud použijete přístupy v kontrolních seznamech pilíře, možná budete muset učinit návrhové kompromisy. Tady je několik příkladů výhod a nevýhod.
hustota a izolace
vyšší hustoty: Umístěte více aplikací v rámci stejného plánu služby App Service pro optimalizaci využití zdrojů. Všechny aplikace sdílejí prostředky, jako je procesor a paměť, což může ušetřit peníze a snížit provozní složitost. Tento přístup také optimalizuje využití prostředků. Aplikace mohou využívat nečinné prostředky z jiné aplikace, pokud se časem mění vzorce zátěže.
Zvažte také nevýhody, jako je soutěž o prostředky. Například špičky využití nebo nestability aplikace můžou ovlivnit výkon jiných aplikací. Incidenty v jedné aplikaci mohou také ovlivnit jiné aplikace ve sdíleném prostředí, což může ovlivnit zabezpečení. Pro důležité aplikace vyžadující vysokou dostupnost a výkon izolované prostředí, jako je App Service Environment V3 (ASE), poskytují vyhrazené prostředky, ale za vyšší cenu. Zvažte použití sdílených prostředí pro nekritické úlohy a izolovaná prostředí pro klíčové aplikace.
vyšší izolace: Izolace pomáhá vyhnout se rušení. Tato strategie se vztahuje na zabezpečení, výkon a dokonce i oddělení vývoje, testování a produkčních prostředí.
App Service Environment poskytuje lepší kontrolu nad zabezpečením a ochranou dat, protože každá aplikace může mít vlastní nastavení zabezpečení. Vaše prostředí může obsahovat porušení zabezpečení, protože izolace omezuje poloměr výbuchu. Minimalizuje se soutěž prostředků s ohledem na výkon. Izolace umožňuje nezávislé škálování na základě konkrétní poptávky a individuálního plánování kapacity.
Nevýhodou je tento přístup dražší a vyžaduje provozní rigorii.
spolehlivá strategie škálování
Dobře definovaná strategie škálování zajišťuje, aby vaše aplikace zvládla různá zatížení bez ohrožení výkonu. Existují však kompromisy ohledně nákladů. Operace škálování nějakou dobu trvá. Při přidělování nových prostředků musí být aplikace správně inicializována, aby bylo možné efektivně zpracovávat požadavky. Prostředky můžete přidělit nad rámec (předehřát instance), abyste zajistili připravenost. Bez této dodatečné kapacity může během fáze inicializace dojít ke zpoždění při poskytování požadavků, což má vliv na uživatelské prostředí. Operace automatického škálování se můžou aktivovat dostatečně brzy, aby se povolila správná inicializace prostředků v době, kdy zákazníci prostředky používají.
Nevýhodou je, že nadsaděné prostředky stojí více. Za každou instanci, včetně předchystaných instancí, se vám účtují poplatky za sekundu. Vyšší úrovně zahrnují předzbrojené instance. Určete, jestli stojí za investice možnosti s dražšími úrovněmi.
vytváření redundance
Redundance nabízí odolnost, ale také přináší náklady. Cíle na úrovni služby (SLO) pro vaši úlohu určují přijatelné prahové hodnoty výkonu. Pokud redundance překročí požadavky na SLO, dochází k plýtvání. Vyhodnoťte, jestli nadbytečná redundance zlepšuje cíle úrovně služby nebo zvyšuje zbytečnou složitost.
Zvažte také nevýhody. Například redundance s více oblastmi poskytuje vysokou dostupnost, ale zvyšuje složitost a náklady kvůli synchronizaci dat, mechanismům převzetí služeb při selhání a komunikaci mezi oblastmi. Určete, jestli může redundance zón splňovat vaše cíle úrovně služby.
Zásady Azure
Azure poskytuje rozsáhlou sadu předdefinovaných zásad souvisejících se službou App Service a jejími závislostmi. Sada zásad Azure může auditovat některá z předchozích doporučení. Můžete například zkontrolovat, jestli:
Jsou zavedeny správné síťové ovládací prvky. Můžete například začlenit segmentaci sítě umístěním služby App Service do služby Azure Virtual Network prostřednictvím injektáže virtuální sítě, abyste měli větší kontrolu nad konfigurací sítě. Aplikace nemá veřejné koncové body a připojuje se ke službám Azure prostřednictvím privátních koncových bodů.
Kontroly identity jsou zavedeny. Aplikace například používá spravované identity k autentizaci vůči jiným prostředkům. Integrované ověřování služby App Service (Easy Auth) ověřuje příchozí požadavky.
Funkce, jako je vzdálené ladění a základní ověřování, jsou zakázané, aby se snížil prostor pro útoky.
Komplexní zásady správného řízení najdete v předdefinovaných definic azure Policy a dalších zásadách, které by mohly ovlivnit zabezpečení výpočetní vrstvy.
Doporučení azure Advisoru
azure Advisor je individuální cloudový konzultant, který vám pomůže postupovat podle osvědčených postupů pro optimalizaci nasazení Azure. Tady je několik doporučení, která vám můžou pomoct zlepšit spolehlivost, zabezpečení, nákladovou efektivitu, výkon a efektivitu provozu instancí webových aplikací.
- spolehlivost
- zabezpečení
- optimalizace nákladů
- Výkon
- Provozní dokonalost
Další kroky
Zvažte následující články jako zdroje informací, které ukazují doporučení zvýrazněná v tomto článku.
Tyto referenční architektury použijte jako příklady použití těchto doporučení pro úlohu.
Pokud jste webovou aplikaci nikdy nenasadili, přečtěte si téma základní webová aplikace.
Pro základní architekturu jako výchozí bod pro nasazení na produkční úrovni si projděte téma : Vysoce dostupná zónově redundantní webová aplikace.
K vytvoření odborných znalostí implementace použijte následující produktovou dokumentaci: