Perspektiva architektury s dobře navrženou architekturou Azure na Aplikace Azure Service (Web Apps)

Určení priority toků uživatelů: Ne všechny toky jsou stejně důležité. Přiřaďte jednotlivým tokům priority, které vám povedou rozhodnutí 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ídejte 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í.

Další informace najdete v tématu Analýza režimu selhání pro aplikace Azure.

Redundance sestavení: 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. Instance aplikace se například sváže s úložištěm objektů blob. 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í.

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 vést k nespolehlivému. Zvažte správný přístup ke škálování na základě charakteristik vašich úloh. Někdy můžete vertikálně navýšit kapacitu a zpracovat zatížení. Pokud se však zatížení stále zvyšuje, navyšte kapacitu na nové instance. Upřednostněte 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.

Zvolená úroveň plánu služby App Service má vliv na š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 před všechna razítka s externím nástrojem pro vyrovnávání zatížení distribuovali provoz mezi ně. Použití brány Aplikace Azure 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 tématu Základní hodnoty kritické pro Službu App Service.

Plán služby App Service distribuuje provoz napříč instancemi a monitoruje jejich stav. Upozorňujeme, že externí nástroj pro vyrovnávání zatížení nemusí okamžitě zjistit, jestli selže jedna instance.

Plánování obnovitelnosti: Redundance je zásadní pro kontinuitu podnikových procesů. Převzetí služeb při selhání do jiné instance, pokud jedna instance není dostupná. Prozkoumejte možnosti automatického opravy 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 zabránila selhání v ovlivnění celého systému.

• Vzor vyrovnávání zatížení založený na frontě fronty pracovních položek, které slouží jako vyrovnávací paměť pro vyhlazení špiček provozu.

• Vzor opakování zpracovává přechodné selhání kvůli výpadkům sítě, vyřazeným databázovým připojením nebo zaneprázdněným službám.

• Model Jistič 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.

Testování spolehlivosti: Proveďte zátěžové testování za účelem vyhodnocení spolehlivosti a výkonu vaší aplikace při zatížení. Testovací plány by měly zahrnovat scénáře, které ověřují vaše automatizované operace obnovení.

Injektáž chyb použijte k úmyslnému zavedení selhání a ověření mechanismů samoopravení a samozáchování. 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.

Pomocí sond stavu identifikujte nereagující pracovní procesy: Služba App Service má integrované funkce, které pravidelně testují příkaz ping na konkrétní cestu vaší webové aplikace. Z nástroje pro vyrovnávání zatížení se odeberou nereagující instance a nahradí se novou instancí.

Kontrola standardních hodnot zabezpečení: Pokud chcete vylepšit stav zabezpečení vaší aplikace hostované v plánu služby App Service, projděte si standardní hodnoty zabezpečení pro Službu App Service.

Používejte nejnovější modul runtime a knihovny: Důkladně otestujte sestavení aplikace před aktualizacemi, abyste včas zachytili problémy a zajistili hladký přechod na novou verzi. App Service podporuje zásady podpory jazyka runtime pro aktualizaci existujících zásobníků a vyřazení zásobníků ukončení podpory.

Vytvořte segmentaci přes hranice izolace, která bude obsahovat porušení zabezpečení: Použijte 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í 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žití ří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ého plánu, přispěvatel webu a obecný přispěvatel, čtenář a vlastník.

Řízení síťového provozu do a z aplikace: Nezpřístupňujte koncové body aplikace veřejnému internetu. Místo toho přidejte privátní koncový bod do webové aplikace, která je umístěná ve vyhrazené podsíti. Frontu aplikace pomocí reverzního proxy serveru, který komunikuje s tímto privátním koncovým bodem. Zvažte použití služby Application Gateway nebo Azure Front Door pro tento účel.

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.

Komplexní zobrazení najdete v tématu Síťové funkce služby App Service.

Šifrování dat: Ochrana přenášených dat pomocí kompletního 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. Služba App Service ve výchozím nastavení povoluje verzi 1.2. Další informace najdete v tématu Přehled protokolu 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ů.

Omezte prostor pro útoky: Odeberte výchozí konfigurace, které nepotřebujete. Můžete například zakázat vzdálené ladění, místní ověřování pro lokality správce správy 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.

Ochrana tajných kódů 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 protokoly prostředků pro vaši aplikaci: Povolte pro aplikaci protokoly prostředků, abyste vytvořili komplexní záznamy aktivit, které poskytují cenná data během vyšetřování, která sledují incidenty zabezpečení.

Při vyhodnocování hrozeb zvažte protokolování jako součást procesu modelování hrozeb.

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.

Vyhodnoťte zlevněné možnosti: 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 instanci horizontálního navýšení kapacity ve vašem plánu na základě času přidělení instance virtuálního počítače. Věnujte pozornost nevyužitým výpočetním prostředkům, které můžou zvýšit náklady v důsledku přetížení kvůli neoptimálnímu výběru skladové položky nebo špatně nakonfigurované konfiguraci škálování na více instancí.

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ě k izolaci vašeho řešení nebo trezorů klíčů za účelem ochrany tajných kódů úloh, můžou také přidat náklady, které se integrují s vašimi prostředky služby App Service. Další informace najdete v tématu Fakturační model služby App Services.

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.

Vyhodnoťte účinek strategie škálování na náklady: Při implementaci automatického škálování musíte správně navrhnout, otestovat a nakonfigurovat horizontální navýšení kapacity a škálování. 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ělovat 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 podle potřeby vertiká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 a spusťte předprodukční prostředí. Tyto úrovně jsou nízké výkon a nízké náklady. 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 úlohy generují. Zvažte použití vzorů, jako jsou back-endy pro vzor front-endů a vzor agregace brány, což může minimalizovat počet požadavků a snížit náklady.

Pravidelně kontrolujte 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 jsou blue-green nasazení, která přepínají 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 nevracení paměti, které můžou mít vliv na existující instance i nové instance. Ujistěte se, že důkladně testujete změny. Provozní pokyny najdete v tématu Efektivita provozu.

Správa vydaných verzí: 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účtují další náklady, protože slot běží ve stejném prostředí virtuálního počítače jako produkční instance.

Spusťte automatizované testy: Než zvýšíte úroveň vydání webové aplikace, důkladně otestujete její výkon, funkčnost a integraci s dalšími komponentami. Použijte Zátěžové testování Azure, 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í.

Nasazení neměnných jednotek: Implementujte model razítka 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 App Service.

Každé razítko představuje samostatnou jednotku, ve které můžete rychle škálovat nebo škálovat. 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žujte provozní 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í 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é.

Správa certifikátů: Pro vlastní domény je potřeba 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í.

Identifikovat a monitorovat ukazatele výkonu: Nastavte cíle pro klíčové ukazatele aplikace, jako je objem příchozích požadavků, doba, kterou aplikace přijme k reakci 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 například application Přehledy. Další informace najdete v referenčních informacích 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 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.

Optimalizujte strategii škálování: Pokud je to možné, místo ruční úpravy počtu instancí při změně zatížení aplikace používejte automatické škálování . 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. V případě potřeby zvažte přetížení prostředků.

Při definování pravidel automatického škálování přihlédněte k době, kterou aplikace potřebuje k inicializaci. Tuto režii zvažte, když provedete všechna rozhodnutí o škálování.

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í, přispívají do modulu runtime. Ukládáním do mezipaměti minimalizujte dobu zpracování a latenci. Ukládání výsledků dotazů do mezipaměti, aby nedocházelo k opakovaným odezvám databáze nebo back-endu, a zkracujte dobu zpracování pro následné požadavky.

Další informace o používání místní a distribuované mezipaměti v úloze najdete v tématu Ukládání do mezipaměti.

Zkontrolujte antipatterny výkonu: Abyste měli jistotu, že webová aplikace provádí a škáluje v souladu s vašimi obchodními požadavky, vyhněte se typickým antipatternům. Tady jsou některé antipatterny, které App Service opravuje.