Sdílet prostřednictvím

Osvědčené postupy architektury pro Službu 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í. App Service jako řešení PaaS abstrahuje základní infrastrukturu, která vám umožní soustředit se na vývoj aplikací. Funkce Web Apps služby App Service spouští vaše aplikace v kontextu plánu služby App Service. Tento plán určuje prostředky, operační systém, oblast a cenový model (SKU), které se používají k hostování vaší aplikace.

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 App Service. Pokyny v tomto článku poskytují architektonická doporučení, která odpovídají principům pilířů Well-Architected Framework.

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.

Reliability

Úč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 úloh

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čení priority 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žby 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. Pokud umístíte velkou aplikaci do jednoho plánu, může to mít za následek problémy s pamětí nebo procesorem, které ovlivňují 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ídání potenciálních selhání: Naplánujte strategie zmírnění rizik pro potenciální selhání. Následující tabulka uvádí příklady analýzy režimu selhání.

    Failure Mitigation
    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 model Opakování a model Jistič. Monitorujte externí závislosti a nastavte odpovídající č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.

  • 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 do několika oblastí, abyste zajistili, ž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. Pokud aplikace používá zónově redundantní nasazení, zvažte konfiguraci přidruženého účtu úložiště s zónově redundantním úložištěm.

  • Použijte více instancí: K okamžitému selhání dojde v případě, že aplikaci spustíte pouze na jedné instanci. Přidáním více instancí do vaší aplikace můžete zajistit vysokou dostupnost. Pokud jedna instance selže, ostatní instance stále můžou zpracovávat příchozí požadavky. Kód aplikace by měl být schopný zpracovat více instancí bez problémů se synchronizací při čtení ze zdrojů dat 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ějte spolehlivou strategii škálování: Neočekávané zatížení aplikace může způsobit, že se stane nespolehlivou. Zvažte správný přístup ke škálování na základě charakteristik vašich úloh. Horizontální škálování nebo horizontální navýšení kapacity umožňuje přidat další instance pro distribuci zatížení. Vertikální škálování nebo vertikální navýšení kapacity zvyšuje kapacitu existující instance, jako je procesor nebo 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. U ručního přístupu zvolte automatický přístup nebo automatické škálování. Během operací škálování vždy udržujte vyrovnávací paměť dodatečné kapacity, aby se zabránilo snížení výkonu.

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

    Při návrhu strategie škálování zvažte požadavky na síťový protokol a ujistěte se, že jsou pokryté vzory přenosů IPv4 i IPv6. App Service podporuje příchozí připojení IPv6 společně s protokolem IPv4. Sítě pouze s protokolem IPv6 můžou překonat problémy s vyčerpáním protokolu IPv4. Klienti jen pro IPv6 ale vyžadují překladatelské služby IPv4-to-IPv6, pokud není povolený protokol IPv6, což vytváří potenciální režii překladu sítě. Další informace najdete v tématu Příchozí a odchozí IP adresy ve službě Azure App Service.

  • Zajistěte správnou inicializaci aplikace, aby se nové instance rychle zahřívaly a mohly přijímat požadavky. Usilujte o bezstavové aplikace, pokud 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 nasazení stejných razítek, přičemž každé razítko má spuštěnou vlastní instanci plánu služby App Service a 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í s více oblastmi. Tento přístup je ideální pro klíčové aplikace, pokud je zásadní spolehlivost. Další informace najdete v základním nastavení kritickém pro misi u služby App Service.

  • Naplánujte si 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 návrhové vzory pro dosažení elegantní degradace výkonu při přechodných selháních, 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é selhání kvůli výpadkům sítě, padajícím databázovým připojením 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.

    Další informace najdete v tématu Vzory návrhu architektury, které podporují spolehlivost.

  • 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. Další informace najdete v tématu Chyba a knihovna akcí nástroje 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 Omezení služby App Service.

  • Pomocí funkce kontroly stavu identifikujte nereagující workers: App Service má integrované funkce, které pravidelně pingují konkrétní cestu vaší webové aplikace. Platforma ověřuje tuto cestu pomocí příkazu ping, aby zjistila, zda je vaše aplikace zdravá a zda reaguje na požadavky.

    Když se váš web škáluje na více instancí, App Service vyloučí všechny instance, které nejsou v pořádku, z obsluhy požadavků. Tento proces zlepšuje celkovou dostupnost.

    Cesta kontroly stavu vaší aplikace by se měla dotazovat na základní součásti vaší aplikace, jako je databáze, mezipaměť nebo služba zasílání zpráv. Tento krok pomáhá zajistit, aby stav vrácený cestou kontroly stavu byl přesným obrázkem celkového stavu vaší aplikace.

  • Použijte funkci automatického oprav: Někdy může vaše aplikace zaznamenat neočekávané chování, které může jednoduché restartování vyřešit. Pomocí funkce automatického opravování definujte podmínku , která aktivuje automatické hojení, a akci , která se spustí při splnění této podmínky. Další informace najdete v přehledu diagnostiky služby App Service.

  • Sestava skóre odolnosti služby App Service: Pokud chcete zkontrolovat přizpůsobená doporučení osvědčených postupů, projděte si přehled diagnostiky služby App Service.

Doporučení pro konfiguraci

Recommendation Benefit
(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 poskytuje 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 nemají 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á.
(Web Apps) 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á instance služby 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í.
(App Service) Nepoužívejte funkce zálohování a obnovení služby App Service pro propojené databáze. Použití nativních nástrojů pro zálohování a obnovení pro propojené databáze poskytuje spolehlivější a vyladěnější řešení obnovení pro úložiště stavů webové aplikace.

Zálohování propojených databází prostřednictvím služby App Service je zastaralé.
(Web Apps) 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.
(Web Apps) 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.
(Web Apps) Povolte funkci AlwaysOn , když webová aplikace hostuje webovou úlohu. Webové aplikace můžou vyprší časový limit po určité době HTTP nečinnosti. Nastavení AlwaysOn pomáhá zajistit spolehlivé spouštění nepřetržitých i aktivovaných webových úloh.

Zabezpečení

Úč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 úloh

Zahajte strategii návrhu na základě kontrolního seznamu pro kontrolu návrhu pro zabezpečení a identifikujte ohrožení zabezpečení a kontrolní mechanismy, které zlepšují 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í aplikace hostované v plánu služby App Service, projděte si standardní hodnoty zabezpečení pro Službu App Service.

  • Použijte nejnovější modul runtime a knihovny: Důkladně otestujte buildy aplikace předtím, než provedete aktualizace, abyste chytili problémy včas a pomohli zajistit 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řte segmentaci prostřednictvím hranic izolace k omezení porušení zabezpečení: 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ě. Integrace aplikací App Service s 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 poskytují ú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 vnitřní přístup k webové aplikaci a 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žití ovládacích prvků zabezpečení sítě: Integrujte službu App Service s virtuální sítí, abyste mohli řídit odchozí provoz. Pomocí privátních koncových bodů můžete řídit příchozí provoz, omezit přístup k instanci služby App Service z vaší virtuální sítě a zakázat veřejný přístup k internetu. Další informace naleznete v tématu Směrování sítě.

    Nasaďte firewall webových aplikací (WAF), který pomáhá chránit 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 pomáhají zabránit exfiltraci dat.

    Další informace najdete v tématu Síťové funkce služby App Service.

  • Šifrování dat: Pomozte chránit přenášená data 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 .

    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 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, což minimalizuje riziko zachycení provozu.

  • Omezte prostor pro útok: 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 pomocí zásad Azure. Další informace najdete v tématu Zásady Azure.

  • Implementujte omezující zásady 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žití spravovaných identit: Povolte spravované identity pro vaši instanci služby App Service, abyste měli bezpečnější přístup k jiným službám Azure bez nutnosti spravovat přihlašovací údaje.

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

  • Povolení protokolů prostředků pro vaši aplikaci: Povolte pro vaši 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í. Další informace naleznete v protokolech prostředků Azure Monitor.

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

Doporučení pro konfiguraci

Recommendation Benefit
(Web Apps) Přiřaďte spravované identity 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.
(Web Apps) 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 TLS, což pomáhá zajistit ochranu citlivých dat a vytvořit vztah důvěryhodnosti uživatelů.
(Web Apps) 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 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.
(Web Apps) 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.
(Web Apps) Implementace 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 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é poskytuje ř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.
(Web Apps) 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ů.
(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 Web Apps a jeho prostředím.

Kontrolní seznam návrhu úloh

Zahajte svou strategii návrhu na základě kontrolního seznamu přezkumu návrhu pro optimalizaci nákladů pro investice. Dolaďte návrh tak, aby úloha byla v souladu s rozpočtem přiděleným 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ů můžete pomocí cenové kalkulačky Azure vyhodnotit přibližné náklady spojené s různými úrovněmi na základě počtu instancí, které plánujete spustit. Každá úroveň služby App Service poskytuje 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 instance rozšíření v rámci vašeho plánu podle času přidělení instance VM. Věnujte pozornost nedostatečně využitým výpočetním prostředkům, které můžou zvýšit náklady v důsledku nadměrného přidělení kvůli neoptimálnímu výběru SKU nebo špatné konfiguraci š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 trezory klíčů, které chrání tajné kódy úloh, můžou také integrovat s prostředky služby App Service a přidat náklady. Další informace najdete v tématu Vysvětlení celého modelu fakturace služby App Service.

  • 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 účinky strategie škálování na náklady: Při implementaci automatického škálování musíte správně navrhnout, testovat a konfigurovat jak pro škálování nahoru, tak 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é poskytují 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 použití úrovně Basic nebo úrovně Free ke 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 Úroveň 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 vzor Backends for Frontends a vzor agregace na bráně, abyste minimalizovali počet požadavků a snížili 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ě. Kvůli využití šířky pásma a dlouhodobému uchovávání dat protokolování se můžou nahromadit další výdaje.

    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ést problémy, jako jsou výjimky nebo úniky paměti, které mohou ovlivnit stávající a nové instance. Ujistěte se, že důkladně testujete změny. Další informace o provozních pokynech najdete v tématu Efektivita provozu.

Doporučení pro konfiguraci

Recommendation Benefit
(App Service) Zvolte úrovně Free nebo úrovně Basic pro nižší prostředí. Tyto úrovně doporučujeme pro experimentální použití. Vrstvy odeberte, pokud je už nepotřebujete. Úrovně Free a úrovně 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 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 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.
(Web Apps) 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ář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 efektivity provozu poskytují strategii návrhu vysoké úrovně pro dosažení těchto cílů pro provozní požadavky úlohy.

Kontrolní seznam návrhu úloh

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.

  • 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účtuje další náklady, protože slot běží ve stejném prostředí virtuálního stroje jako produkční instance.

    Použijte funkci prohození s náhledem (vícefázové prohození). Přepnutí s náhledem umožňuje otestovat aplikaci v přípravních slotech s produkčními nastaveními a také aplikaci zahřát. Po provedení testů a ohřátí všech potřebných propojovacích cest můžete dokončit výměnu. Aplikace pak bude přijímat produkční provoz bez restartování.

  • Spouštění automatizovaných testů: Než zvýšíte úroveň vydání webové aplikace, důkladně otestujte její výkon, funkčnost a integraci s dalšími komponentami. Použijte zátěžové testování Azure. Integruje se s Apache JMeter, oblíbeným nástrojem 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í: Využijte kanály kontinuální integrace a průběžného nasazování s Azure DevOps nebo GitHub Actions k automatizaci nasazení a snížení ručního úsilí. Další informace najdete v tématu Průběžné nasazování do služby App Service.

  • Nasazení neměnných jednotek: Implementujte šablonu razítka nasazení pro oddě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ý 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. Další informace najdete v základním nastavení kritickém pro misi u služby 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ádějte změny přímo v produkčním prostředí, aby byla zajištěna stabilita 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é.

  • Správa certifikátů: U vlastních domén 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í.

Recommendation Benefit
(Web Apps) Monitorujte stav 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.
(Web Apps) 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ů:

- 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.
(Web Apps) Využijte výhod certifikátů spravovaných službou 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.

Udržování dříve nasazené produkční verze v slotu vám umožní vrátit se k poslednímu známému dobrému stavu, pokud zjistíte problém po nasazení.

Umožňuje zajistit, aby se všechny instance před prohozením do produkčního prostředí zahřívaly, aby nedocházelo k přechodným obavám o nasazení související se spuštěním.

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 úloh

Zahajte strategii návrhu na základě kontrolního seznamu pro kontrolu efektivity výkonu. Definujte směrný plán založený na klíčových ukazatelích výkonu pro Web Apps.

  • Identifikace a monitorování ukazatelů výkonu: Nastavte cíle pro klíčové ukazatele aplikace, jako je objem příchozích požadavků, čas, který aplikace přijme, aby reagovala 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 aplikací, 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í.

  • Zvolte správnou úroveň: Používejte vyhrazené výpočetní prostředky pro produkční úlohy. Úrovně Premium v3 poskytují 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.

  • Optimalizace strategie š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á vyžaduje pouze nastavení limitů, aniž byste museli definovat pravidla.

    Máte k dispozici dostatek prostředků, které vám pomůžou zajistit 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žití 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 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. Následující tabulka popisuje některé antipatterny, které App Service opravuje.

    Antipattern Description
    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í pro konfiguraci

Recommendation Benefit
(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ého limitu 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.

Tradeoffs

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šší 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 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é pronikat do jiných aplikací ve sdíleném prostředí, což může ovlivnit zabezpečení. Pro důležité aplikace, které vyžadují vysokou dostupnost a výkon, izolovaná prostředí, jako je App Service Environment v3 , poskytují vyhrazené prostředky, ale s vyššími náklady. 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á zabránit 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. 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í pomáhá zajistit, 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 (nebo instance prewarm) můžete přetěžovat, 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ř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.

Sestavování redundance

Nadbytečnost zajišťuje odolnost, ale také zvyšuje 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 meziregionální komunikaci. Určete, jestli může redundance zóny splňovat vaše SLA.

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. Některé z předchozích doporučení je možné auditovat prostřednictvím služby Azure Policy. 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 (nebo Snadné ověřování) 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ích služby App Service a dalších zásadách Azure Policy , 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.

Další informace najdete v tématu Azure Advisor.

Příklad architektury

Základní architektura, která ukazuje klíčová doporučení: základní architektura služby App.

Další kroky

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

  • Last updated on