Perspektiva dobře architektuře Azure Web Apps ve službě Aplikace Azure Service

  • Článek

Aplikace Azure Service je výpočetní řešení typu platforma jako služba (PaaS), které můžete použít k hostování úloh na platformě Azure. Je to plně spravovaná služba, která abstrahuje základní výpočetní prostředky a snižuje odpovědnost za sestavování, nasazování a škálování na platformu. Služba App Service se vždy spouští v rámci plánu služby App Service. Zvolený plán služby určuje oblast, ve které se úloha spouští, konfigurace výpočetních prostředků a operační systém. Pro App Service je k dispozici více fakturačních modelů.

Tento článek předpokládá, že jste jako architekt zkontrolovali rozhodovací strom výpočetních prostředků a jako výpočetní prostředky pro vaši úlohu zvolili Službu App Service. Pokyny v tomto článku poskytují doporučení architektury, která jsou namapovaná na principy pilířů architektury Azure Well-Architected Framework.

Důležité

Jak používat tohoto průvodce

Každá část obsahuje kontrolní seznam návrhu, který představuje oblasti zájmu architektury spolu se strategiemi návrhu lokalizovanými do oboru technologie.

Zahrnuté jsou také doporučení týkající se technologických možností, které můžou pomoct tyto strategie materializovat. Doporučení nepředstavují vyčerpávající seznam všech konfigurací dostupných pro funkci Web Apps služby Aplikace Azure Service a jejich závislostí. Místo toho zobrazí seznam klíčových doporučení mapovaných na perspektivy 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á demonstruje klíčová doporučení: základní architektura služby App Service

Rozsah technologií

Tato kontrola se zaměřuje na vzájemně nesouvisející rozhodnutí pro následující prostředky Azure:

  • Plány služby App Service
  • Web Apps

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 tím, že vytváří dostatečnou odolnost a schopnost rychle se zotavit ze 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 strategii návrhu na základě kontrolního seznamu pro kontrolu návrhu pro 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č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 instance 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í.

    Selhání Zmírnění
    Selhání základních nebo abstraktovaných komponent služby App Service Redundance 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 model Opakování a model Jistič. Monitorujte externí závislosti a nastavte příslušné časové limity.
    Selhání kvůli směrování provozu do instancí, které nejsou v pořádku Monitorování stavu instance Zvažte odezvu a vyhněte se odesílání požadavků na instance, které nejsou v pořádku.

    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. Směrování provozu do jiných zón v případě selhání jedné zóny 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 jedním uzlem a Azure Front Door pro nasazení s více oblastmi 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í.

Doporučení
Služba nebo plán Doporučení Výhoda
Plán služby App Service Zvolte úroveň Premium 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. Další informace najdete v přehledu plánu služby App Service.		 Plán služby App Service úrovně Premium nabízí pokročilé funkce škálování a zajišťuje redundanci v případě selhání.
Plán služby App Service Povolte redundanci zón.

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.		 Aplikace může odolat selháním v jedné zóně, když se mezi zóny rozdělí více instancí. Provoz se automaticky přesune na instance v pořádku v jiných zónách a udržuje spolehlivost aplikací, pokud jedna zóna není dostupná.
App Service 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í zahlcení provozu jakéhokoli jednoho uzlu. 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 rychlé relace, aby služba App Service mohl přidávat nebo odebírat instance pro horizontální škálování.
App Service Definujte pravidla automatického opravy na základě počtu požadavků, pomalých požadavků, limitů paměti a dalších indikátorů, které jsou součástí standardní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.
App Service Povolte funkci kontroly stavu a zadejte 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.

Zabezpečení

Účelem pilíře zabezpečení je poskytnout úlohu záruky důvěrnosti, integrity a dostupnosti .

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 strategii návrhu na základě kontrolního seznamu pro kontrolu návrhu zabezpečení a identifikujte ohrožení zabezpečení a kontroly, abyste zlepšili stav zabezpečení. Rozšiřte strategii tak, aby podle potřeby zahrnovala více přístupů.

  • 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.

Doporučení
Služba nebo plán Doporučení Výhoda
App Service Přiřaďte spravované identity webové aplikaci. Pokud chcete zachovat hranice izolace, nesdílejte ani znovu nepoužívejte identity napříč aplikacemi.

Pokud pro nasazení používáte kontejnery, ujistěte se, že se bezpečně připojíte ke svému registru kontejneru.		 Aplikace načte tajné kódy ze služby Key Vault, aby se ověřila vnější komunikace z aplikace. Azure identitu spravuje a nevyžaduje zřízení ani obměně tajných kódů.

Máte jedinečné identity pro členitost řízení. Jedinečné identity usnadňují odvolání, pokud dojde k ohrožení identity.
App Service Konfigurace vlastních domén 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 SSL (Secure Sockets Layer) nebo TLS, který zajišťuje ochranu citlivých dat a vytváří vztah důvěryhodnosti uživatelů.
App Service Vyhodnoťte, jestli je integrované ověřování služby App Service správným mechanismem 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 poskytovateli přihlašování a podporuje OpenID Připojení. 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 dosáhne aplikace.
App Service Nakonfigurujte aplikaci pro integraci virtuální sítě.

Používejte privátní koncové body pro aplikace služby App Service. Zablokujte veškerý veřejný provoz.

Směrování načtení image kontejneru prostřednictvím integrace virtuální sítě Veškerý odchozí provoz z aplikace prochází přes virtuální síť.		 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.
App Service Implementace posílení zabezpečení:
- Zakažte 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 se zpřísnily příchozí žádosti.
- 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.
App Service Jako nastavení aplikace vždy používejte odkazy služby Key Vault.
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ů.
Plán služby App Service Povolte 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í.
Plán služby App Service Povolte protokolování diagnostiky a přidejte do aplikace instrumentaci. Protokoly se odesílají do účtů Azure Storage, Azure Event Hubs a Log Analytics. Další informace o typech protokolů auditu najdete 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 zjišťování vzorců výdajů, stanovení priorit investic do kritických oblastí a optimalizaci v jiných oblastech, aby splňovaly rozpočet 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 kontroly návrhu pro optimalizaci nákladů pro investice a vylaď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.

  • 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.

Doporučení
Služba nebo plán Doporučení Výhoda
Plán služby App Service Zvolte úrovně 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.
Plán služby App Service Využijte slevy a prozkoumejte upřednostňované ceny pro:
– Nižší prostředí s plány vývoje/testování
- Rezervace Azure a plány úspor 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 čemuž 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.
App Service Monitorujte náklady , na které se účtují prostředky App Service. Spusťte nástroj pro analýzu nákladů na webu Azure Portal.

Vytvářejte rozpočty a výstrahy , které budou informovat zúčastněné strany.		 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 poskytnout rozpočtové kontroly, aby se zabránilo nadměrnému přespívání.
Plán služby App Service Škálování při poklesu poptávky Pokud chcete provést škálování, definujte pravidla škálování, abyste snížili počet instancí ve službě Azure Monitor. Zabránit wastage a snížit zbytečné výdaje.

Efektivita provozu

Efektivita provozu se primárně zaměřuje na postupy vývoje , pozorovatelnost a správu verzí.

Principy návrhu efektivity 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 efektivitu provozu pro definování procesů pozorovatelnosti, testování a nasazení souvisejících s Web Apps.

  • 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í.

Služba nebo plán Doporučení Výhoda
App Service Monitorujte stav instancí a aktivujte sondy stavu instance.

Nastavte konkrétní cestu pro zpracování požadavků sondy stavu.		 Problémy můžete rychle rozpoznat a provést nezbytné akce pro zachování dostupnosti a výkonu.
App Service Povolte diagnostické protokoly 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ů:
- Zapíše 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.
App Service 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.
Plán služby App Service Před prohozením s produkčním slotem ověřte změny aplikace v přípravném slotu . Vyhněte se výpadkům a chybám.

Pokud po prohození 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 v případě, že se zvyšuje zatížení díky správě 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 vysoké úrovně pro dosažení těchto cílů kapacity proti očekávanému využití.

Kontrolní seznam návrhu

Zahajte strategii návrhu založenou na kontrolním seznamu pro kontrolu návrhu pro efektivitu výkonu pro definování směrného plánu na základě klíčových ukazatelů výkonu pro Web Apps.

  • 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.

    Antipattern Popis
    Zaneprázdněný front-end Úlohy náročné na prostředky můžou zvyšovat doby odezvy pro požadavky uživatelů a způsobovat tak vysokou latenci.
    Přesuňte procesy, které spotřebovávají značné 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.
    Žádné 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í Výhoda
Povolte nastavení AlwaysOn, když aplikace sdílejí jeden plán služby App Service. Aplikace App Service se automaticky uvolní, když jsou nečinné, aby se ukládaly prostředky. Další požadavek aktivuje studený start, což může způsobit vypršení časových limitů požadavků. Aplikace není nikdy uvolněna s povolenou funkcí AlwaysOn.
Zvažte použití protokolu 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 znacích pilíře, budete možná muset navrhnout kompromisy. Tady je několik příkladů výhod a nevýhod.

Hustota

Spolulokujte více aplikací v rámci stejného plánu služby App Service, abyste minimalizovali prostředky. 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 můžou v průběhu času používat nečinné prostředky z jiné aplikace.

Zvažte také nevýhody. Například špičky využití nebo nestability aplikace můžou ovlivnit výkon jiných aplikací. Incidenty v jedné aplikaci můžou také probrat jiné aplikace ve sdíleném prostředí, které můžou ovlivnit zabezpečení.

Izolace

Izolace pomáhá předejít interferenci. 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. Kolize prostředků se minimalizuje z hlediska výkonu. 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 (předwarmové instance) můžete zrušit, abyste zajistili bezpečnostní síť. 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ředzbrojený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.

Sestavování redundance

Redundance nabízí odolnost, ale také účtují 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, stane se 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ů.

  • Ovládací prvky identit jsou zavedené. Aplikace například používá spravované identity k ověření v jiných prostředcích. Integrované ověřování služby App Service ověřuje příchozí požadavky.

  • Pokud chcete omezit prostor pro útoky, můžete zakázat funkce, jako je vzdálené ladění a základní ověřování.

Komplexní zásady správného řízení najdete v předdefinovaných definicích 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í.

Další kroky

Zvažte následující články jako zdroje informací, které ukazují doporučení zvýrazněná v tomto článku.