Vysoce dostupná webová aplikace pro více oblastí

Tato ukázková architektura je založená na ukázkové architektuře základní webové aplikace a rozšiřuje ji tak, aby zobrazovala:

• Osvědčené postupy pro zlepšení škálovatelnosti a výkonu ve webové aplikaci Aplikace Azure Service
• Spuštění aplikace služby Aplikace Azure Service ve více oblastech za účelem dosažení vysoké dostupnosti

Architektura

Stáhněte si soubor aplikace Visio s touto architekturou.

Workflow

Tento pracovní postup řeší aspekty architektury ve více oblastech a vychází z webové aplikace Basic.

• Primární a sekundární oblasti. Tato architektura používá k dosažení vysoké dostupnosti dvě oblasti. Aplikace se nasazuje do každé oblasti. V běžném provozu se síťový provoz směruje do primární oblasti. Pokud se primární oblast stane nedostupnou, provoz se přesměruje do sekundární oblasti.
• Front Door. Azure Front Door je doporučený nástroj pro vyrovnávání zatížení pro implementace ve více oblastech. Integruje se s firewallem webových aplikací (WAF), který chrání před běžným zneužitím a používá nativní funkce ukládání obsahu služby Front Door do mezipaměti. V této architektuře je služba Front Door nakonfigurovaná pro směrování podle priority , která odesílá veškerý provoz do primární oblasti, pokud nebude k dispozici. Pokud primární oblast přestane být dostupná, služba Front Door směruje veškerý provoz do sekundární oblasti.
• Geografická replikace účtů úložiště, SLUŽBY SQL Database a/nebo Azure Cosmos DB

Komponenty

Klíčové technologie používané k implementaci této architektury:

• Microsoft Entra ID je cloudová služba pro správu identit a přístupu, která umožňuje zaměstnancům přistupovat ke cloudovým aplikacím vyvinutým pro vaši organizaci.
• Azure DNS je hostitelská služba určená pro domény DNS a zajišťuje překlad názvů s využitím infrastruktury Microsoft Azure. Pokud svoje domény hostujete v Azure, můžete spravovat svoje DNS záznamy pomocí stejných přihlašovacích údajů, rozhraní API a nástrojů a za stejných fakturačních podmínek jako u ostatních služeb Azure. Pokud chcete použít vlastní název domény (například contoso.com), vytvořte záznamy DNS, které mapuje vlastní název domény na IP adresu. Další informace naleznete v tématu Konfigurace vlastního názvu domény ve službě Azure App Service.
• Azure Content Delivery Network je globální řešení pro doručování obsahu s velkou šířkou pásma tím, že ho uložíte do mezipaměti na strategicky umístěných fyzických uzlech po celém světě.
• Azure Front Door je nástroj pro vyrovnávání zatížení vrstvy 7. V této architektuře směruje požadavky HTTP na webový front-end. Front Door také poskytuje firewall webových aplikací (WAF), který chrání aplikaci před běžným zneužitím a ohrožením zabezpečení. Front Door se také používá pro řešení Content Delivery Network (CDN) v tomto návrhu.
• Aplikace Azure Service je plně spravovaná platforma pro vytváření a nasazování cloudových aplikací. Umožňuje definovat sadu výpočetních prostředků pro webovou aplikaci, která bude spouštět, nasazovat webové aplikace a konfigurovat sloty nasazení.
• Aplikace Azure Functions je možné použít ke spouštění úloh na pozadí. Funkce jsou vyvolány triggerem, například událostí časovače nebo zprávou umístěnou do fronty. V případě dlouhotrvajících stavových úloh použijte Durable Functions.
• Azure Storage je řešení cloudového úložiště pro moderní scénáře ukládání dat, které nabízí vysoce dostupné, široce škálovatelné, odolné a zabezpečené úložiště pro celou řadu datových objektů v cloudu.
• Azure Redis Cache je vysoce výkonná služba ukládání do mezipaměti, která poskytuje úložiště dat v paměti pro rychlejší načítání dat na základě opensourcové implementace Redis Cache.
• Azure SQL Database je relační databáze jako služba v cloudu. SQL Database sdílí základ kódu s databázovým strojem Microsoft SQL Serveru.
• Azure Cosmos DB je globálně distribuovaná plně spravovaná, plně spravovaná, nízká latence, vícemodelová databáze multi query-API pro správu dat ve velkém měřítku.
• Azure Cognitive Search se dá použít k přidání funkcí vyhledávání, jako jsou návrhy vyhledávání, přibližné vyhledávání a vyhledávání specifické pro jazyk. Azure Search se obvykle používá v kombinaci s dalším úložištěm dat, zejména pokud primární úložiště dat vyžaduje striktní konzistenci. V takovém případě ukládejte autoritativní data v jiném úložišti dat a index vyhledávání ve službě Azure Search. Ve službě Azure Search lze také konsolidovat jeden index vyhledávání z více úložišť dat.

Podrobnosti scénáře

Existuje několik obecných přístupů k dosažení vysoké dostupnosti napříč oblastmi:

• Aktivní/pasivní s aktivním pohotovostním režimem: provoz přejde do jedné oblasti, zatímco druhý čeká na aktivní pohotovostní režim. Aktivní pohotovostní režim znamená, že služba App Service v sekundární oblasti je přidělená a je vždy spuštěná.

• Aktivní/pasivní s studeným pohotovostním režimem: provoz směřuje do jedné oblasti, zatímco druhý čeká na studený pohotovostní režim. Studený pohotovostní režim znamená, že služba App Service v sekundární oblasti není přidělená, dokud nebude potřeba převzetí služeb při selhání. Tento přístup je méně nákladný, ale obecně bude trvat déle, než v případě selhání přejde do režimu online.

• Aktivní/Aktivní: Obě oblasti jsou aktivní a požadavky jsou mezi nimi vyrovnávat zatížení. Pokud bude jedna oblast nedostupná, vytáhne se z obměna.

Tento odkaz se zaměřuje na aktivní/pasivní s aktivním pohotovostním režimem.

Potenciální případy použití

Tyto případy použití můžou těžit z nasazení ve více oblastech:

• Návrh plánu provozní kontinuity a zotavení po havárii pro aplikace LoB

• Nasaďte klíčové aplikace, které běží ve Windows nebo Linuxu.

• Vylepšete uživatelské prostředí tím, že aplikace budou dostupné.

Doporučení

Vaše požadavky se mohou od popsané architektury lišit. Jako výchozí bod použijte doporučení uvedená v této části.

Oblastní párování

Každá oblast Azure je spárovaná s jinou oblastí na stejném území. Obecně byste měli volit oblasti ze stejného páru oblastí (například USA – východ 2 a USA – střed). Výhody tohoto postupu jsou následující:

• Pokud dojde k rozsáhlému výpadku, je u každého páru upřednostněno obnovení alespoň jedné oblasti.
• Plánované aktualizace systému Azure se u spárovaných oblastí nasazují postupně, aby se minimalizoval případný výpadek.
• Ve většině případů se oblastní páry nacházejí ve stejné geografické oblasti, aby splňovaly požadavky na rezidenci dat.

Ujistěte se však, že obě oblasti podporují všechny služby Azure, které vaše aplikace potřebuje. Viz Služby v jednotlivých oblastech. Další informace o oblastních párech najdete v článku Provozní kontinuita a zotavení po havárii (BCDR): Spárované oblasti Azure.

Skupiny prostředků

Zvažte umístění primární oblasti, sekundární oblasti a služby Front Door do samostatných skupin prostředků. Toto přidělení umožňuje spravovat prostředky nasazené do každé oblasti jako jednu kolekci.

Aplikace služby App Service

Webovou aplikaci a webové rozhraní API doporučujeme vytvořit jako samostatné aplikace služby App Service. Tak je budete moct spouštět jako samostatné, nezávisle škálovatelné plány služby App Service. Pokud tuto úroveň škálovatelnosti zatím nepotřebujete, můžete aplikace nasadit ve stejném plánu a v případě potřeby je do dvou různých plánů přesunout později.

Konfigurace služby Front Door

Směrování: Front Door podporuje několik mechanismů směrování. Pro scénář popsaný v tomto článku použijte prioritní směrování. Díky tomuto nastavení služba Front Door odesílá všechny požadavky do primární oblasti, pokud koncový bod pro tuto oblast nebude nedostupný. Od tohoto okamžiku služby při selhání automaticky převezme sekundární oblast. Nastavte fond původu s různými hodnotami priority, 1 pro aktivní oblast a 2 nebo vyšší pro pohotovostní nebo pasivní oblast.

Sonda stavu: Front Door používá k monitorování dostupnosti jednotlivých back-endů sondu HTTPS. Sonda poskytuje službě Front Door test úspěšného nebo neúspěšného převzetí služeb při selhání pro převzetí služeb při selhání sekundární oblasti. Funguje na základě odeslání žádosti do určené cesty adresy URL. Pokud sonda ve stanoveném období časového limitu nezíská odpověď HTTP 200, tak selže. Můžete nakonfigurovat frekvenci sondy stavu, počet vzorků potřebných k vyhodnocení a počet úspěšných vzorků požadovaných pro označení původu jako v pořádku. Pokud služba Front Door označí původ jako degradovaný, převezme služby při selhání druhému zdroji. Podrobnosti najdete v tématu Sondy stavu.

Osvědčeným postupem je vytvořit cestu sondy stavu ve zdroji aplikace, která hlásí celkový stav aplikace. Tato sonda stavu by měla kontrolovat kritické závislosti, jako jsou aplikace služby App Service, fronta úložiště a SQL Database. V opačném případě může sonda hlásit zdroj, který je v pořádku, když kritické části aplikace skutečně selhávají. Na druhou stranu nepoužívejte sondy stavu ke kontrole služeb s nízkou prioritou. Když například emailová služba přestane fungovat, aplikace se může přepnout na druhého poskytovatele nebo prostě emaily odeslat později. Další diskuzi o tomto vzoru návrhu najdete v tématu Model monitorování koncových bodů stavu.

Zabezpečení původu z internetu je důležitou součástí implementace veřejně přístupné aplikace. Informace o doporučených vzorech návrhu a implementace microsoftu pro zabezpečení příchozí komunikace s příchozím přenosem dat vaší aplikace pomocí služby Front Door najdete v implementaci zabezpečeného příchozího přenosu dat sítě.

CDN. K ukládání statického obsahu do mezipaměti použijte nativní funkci CDN služby Front Door. Hlavní výhodou služby CDN je snížení latence pro uživatele – obsah se ukládá do mezipaměti na hraničním serveru, který je geograficky umístěný blízko uživatele. Služba CDN také pomáhá snížit zatížení aplikace, protože aplikace nemusí zpracovávat přenosy. Služba Front Door navíc nabízí akceleraci dynamického webu, která umožňuje poskytovat lepší uživatelské prostředí pro vaši webovou aplikaci, než by bylo k dispozici pouze u ukládání statického obsahu do mezipaměti.

SQL Database

K zajištění odolnosti databází použijte aktivní geografickou replikaci a skupiny automatického převzetí služeb při selhání. Aktivní geografická replikace umožňuje replikovat databáze z primární oblasti do jedné nebo více (až čtyř) dalších oblastí. Skupiny automatického převzetí služeb při selhání vycházejí z aktivní geografické replikace tím, že vám umožní převzít služby při selhání sekundární databázi bez jakýchkoli změn kódu vašich aplikací. Převzetí služeb při selhání se dá provést ručně nebo automaticky podle definic zásad, které vytvoříte. Abyste mohli používat skupiny automatického převzetí služeb při selhání, budete muset nakonfigurovat připojovací řetězce s připojovací řetězec převzetí služeb při selhání automaticky vytvořené pro skupinu převzetí služeb při selhání, a ne připojovací řetězec jednotlivých databází.

Azure Cosmos DB

Azure Cosmos DB podporuje geografickou replikaci napříč oblastmi v modelu aktivní-aktivní s více oblastmi zápisu. Alternativně můžete určit jednu oblast jako zapisovatelnou oblast a ostatní jako repliky jen pro čtení. Pokud dojde k výpadku oblasti, můžete převzetí služeb při selhání provést výběrem jiné oblasti, která má být oblastí zápisu. Klientská sada SDK odesílá žádosti na zápis do aktuální oblasti zápisu automaticky, takže po převzetí služby při selhání nemusíte konfiguraci klienta aktualizovat. Další informace najdete v tématu Globální distribuce dat se službou Azure Cosmos DB.

Úložiště

Pro Azure Storage použijte geograficky redundantní úložiště s přístupem pro čtení (RA-GRS). V úložišti RA-GRS se data replikují do sekundární oblasti. K datům v sekundární oblasti máte prostřednictvím samostatného koncového bodu přístup jen pro čtení. U geograficky replikovaných účtů úložiště se podporuje převzetí služeb při selhání iniciované uživatelem do sekundární oblasti. Iniciace převzetí služeb při selhání účtu úložiště automaticky aktualizuje záznamy DNS, aby sekundární účet úložiště byl novým primárním účtem úložiště. Převzetí služeb při selhání by se mělo provést pouze tehdy, když se domníváte, že je to nezbytné. Tento požadavek je definován plánem zotavení po havárii vaší organizace a měli byste zvážit důsledky popsané v části Důležité informace níže.

Pokud dojde k regionálnímu výpadku nebo havárii, tým azure Storage se může rozhodnout provést geografické převzetí služeb při selhání do sekundární oblasti. U těchto typů převzetí služeb při selhání se nevyžaduje žádná akce zákazníka. V těchto případech spravuje tým úložiště Azure také navrácení služeb po obnovení do primární oblasti.

V některých případech bude replikace objektů blob bloku dostatečným řešením replikace pro vaši úlohu. Tato funkce replikace umožňuje zkopírovat jednotlivé objekty blob bloku z primárního účtu úložiště do účtu úložiště ve vaší sekundární oblasti. Výhody tohoto přístupu představují podrobnou kontrolu nad tím, jaká data se replikují. Můžete definovat zásady replikace pro podrobnější řízení typů objektů blob bloku, které se replikují. Příklady definic zásad zahrnují, ale nejsou omezené na:

• Replikují se pouze objekty blob bloku přidané po vytvoření zásady.
• Replikují se pouze objekty blob bloku přidané po daném datu a čase.
• Replikují se pouze objekty blob bloku odpovídající dané předponě.

Služba Queue Storage se v tomto scénáři odkazuje jako na alternativní možnost zasílání zpráv do služby Azure Service Bus. Pokud však pro řešení zasílání zpráv používáte službu Queue Storage, platí zde pokyny uvedené výše vzhledem k geografické replikaci, protože úložiště front se nachází v účtech úložiště. Je ale důležité pochopit, že se zprávy nereplikují do sekundární oblasti a jejich stav je z oblasti nedostupný.

Azure Service Bus

Abyste mohli využívat nejvyšší odolnost nabízenou pro Azure Service Bus, použijte úroveň Premium pro vaše obory názvů. Úroveň Premium využívá zóny dostupnosti, díky čemuž jsou obory názvů odolné vůči výpadkům datového centra. Pokud dojde k rozsáhlé havárii ovlivňující více datových center, může vám pomoct funkce geografického zotavení po havárii, která je součástí úrovně Premium. Funkce geografického zotavení po havárii zajišťuje, že se při spárování nepřetržitě replikuje celá konfigurace oboru názvů (fronty, témata, odběry a filtry) z primárního oboru názvů do sekundárního oboru názvů. Umožňuje kdykoli zahájit přechod mezi primárním serverem a sekundárním převzetím služeb při selhání pouze jednou. Přesun převzetí služeb při selhání přepíše zvolený název aliasu pro obor názvů do sekundárního oboru názvů a pak přeruší párování. Převzetí služeb při selhání je téměř okamžité po zahájení.

Azure Cognitive Search

Ve službě Cognitive Search se dostupnost dosahuje prostřednictvím několika replik, zatímco provozní kontinuita a zotavení po havárii (BCDR) se dosahuje prostřednictvím několika vyhledávacích služeb.

Ve službě Cognitive Search jsou repliky kopie vašeho indexu. Více replik umožňuje službě Azure Cognitive Search provádět restartování počítače a údržbu na jedné replice, zatímco spouštění dotazů pokračuje na jiných replikách. Další informace o přidávání replik naleznete v tématu Přidání nebo omezení replik a oddílů.

Službu Azure Cognitive Search můžete využít Zóny dostupnosti přidáním dvou nebo více replik do vyhledávací služby. Každá replika se umístí do jiné zóny dostupnosti v rámci oblasti.

Důležité informace o BCDR najdete v dokumentaci k více službám v samostatných geografických oblastech .

Azure Cache for Redis

I když všechny úrovně Azure Cache for Redis nabízejí replikaci standardu pro zajištění vysoké dostupnosti, doporučuje se úroveň Premium nebo Enterprise poskytovat vyšší úroveň odolnosti a obnovitelnosti. Úplný seznam funkcí odolnosti a obnovitelnosti a možností pro tyto úrovně najdete v tématu Vysoká dostupnost a zotavení po havárii. Vaše obchodní požadavky určují, která úroveň je pro vaši infrastrukturu nejvhodnější.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti. Při navrhování vysoké dostupnosti napříč oblastmi zvažte tyto body.

Azure Front Door

Azure Front Door automaticky převezme služby při selhání, pokud primární oblast přestane být dostupná. Když služba Front Door převezme služby při selhání, je čas (obvykle přibližně 20 až 60 sekund), když se klienti nemůžou spojit s aplikací. Dobu trvání ovlivňují následující faktory:

• Frekvence sond stavu Čím častěji se odesílají sondy stavu, tím rychlejší může služba Front Door detekovat výpadky nebo návrat původního zdroje, který je v pořádku.
• Konfigurace velikosti vzorku Tato konfigurace určuje, kolik vzorků je nutné pro sondu stavu zjistit, že primární zdroj je nedostupný. Pokud je tato hodnota příliš nízká, můžete z občasných problémů získat falešně pozitivní výsledky.

Front Door je možným bodem selhání v systému. Pokud služba selže, klienti nebudou mít během výpadku přístup k vaší aplikaci. Projděte si smlouvu o úrovni služeb (SLA) služby Front Door a zjistěte, jestli použití samotné služby Front Door splňuje vaše obchodní požadavky na vysokou dostupnost. Pokud ne, zvažte přidání jiného řešení správy provozu jako navrácení služeb po obnovení. Pokud služba Front Door selže, změňte záznamy kanonického názvu (CNAME) v DNS tak, aby odkazovaly na jinou službu pro správu provozu. Tento krok je nutné provést ručně a vaše aplikace bude nedostupná, dokud se změny DNS nerozšíří.

Azure Front Door Standard a Úroveň Premium kombinují možnosti služby Azure Front Door (Classic), Azure CDN Standard od Microsoftu (classic) a Azure WAF do jedné platformy. Použití služby Azure Front Door Standard nebo Premium snižuje body selhání a umožňuje rozšířené řízení, monitorování a zabezpečení. Další informace najdete v tématu Přehled úrovně služby Azure Front Door.

SQL Database

Cíl bodu obnovení (RPO) a odhadovaný cíl doby obnovení (RTO) pro SLUŽBU SQL Database jsou zdokumentované v přehledu provozní kontinuity se službou Azure SQL Database.

Mějte na paměti, že aktivní geografická replikace efektivně zdvojnásobí náklady na každou replikovanou databázi. Pro replikaci se obvykle nedoporučuje sandboxové, testovací a vývojové databáze.

Azure Cosmos DB

Cíl bodu obnovení a doby obnovení (RTO) pro službu Azure Cosmos DB je možné konfigurovat prostřednictvím použitých úrovní konzistence, které poskytují kompromisy mezi dostupností, odolností dat a propustností. Azure Cosmos DB poskytuje minimální rto 0 pro uvolněnou úroveň konzistence s více hlavními instancemi nebo RPO 0 pro silnou konzistenci s jedním hlavním serverem. Další informace o úrovních konzistence služby Azure Cosmos DB najdete v tématu Úrovně konzistence a stálost dat ve službě Azure Cosmos DB.

Úložiště

Úložiště RA-GRS poskytuje trvalé úložiště, ale při zvažování výkonu převzetí služeb při selhání je důležité vzít v úvahu následující faktory:

• Předvídejte ztrátu dat: Replikace dat do sekundární oblasti se provádí asynchronně. Proto pokud dojde k geografickému převzetí služeb při selhání, měla by se předpokládat nějaká ztráta dat, pokud se změny primárního účtu plně nesynchronovaly do sekundárního účtu. Můžete zkontrolovat vlastnost Čas poslední synchronizace sekundárního účtu úložiště a zobrazit čas posledního zápisu dat z primární oblasti do sekundární oblasti.

• Naplánujte cíl doby obnovení (RTO) odpovídajícím způsobem: Převzetí služeb při selhání sekundární oblasti obvykle trvá přibližně hodinu, takže při výpočtu parametrů RTO by měl váš plán zotavení po havárii vzít v úvahu tyto informace.

• Pečlivě naplánujte navrácení služeb po obnovení: Je důležité vědět, že při převzetí služeb při selhání účtu úložiště dojde ke ztrátě dat v původním primárním účtu. Pokus o navrácení služeb po obnovení do primární oblasti bez pečlivého plánování je rizikový. Po dokončení převzetí služeb při selhání se nová primární oblast v oblasti převzetí služeb při selhání nakonfiguruje pro místně redundantní úložiště (LRS). Musíte ho ručně překonfigurovat jako geograficky replikované úložiště, aby se iniciovala replikace do primární oblasti, a pak dostatek času na to, aby se účty synchronizovaly.

• Přechodná selhání, jako je výpadek sítě, neaktivují převzetí služeb při selhání úložiště. Navrhněte svou aplikaci tak, aby byla odolná vůči přechodným selháním. Mezi možnosti omezení rizik patří:

  • Čtěte ze sekundární oblasti.
  • Dočasně se pro nové operace zápisu (například řazení zpráv do fronty) přepněte na jiný účet úložiště.
  • Zkopírujte data ze sekundární oblasti do jiného účtu úložiště.
  • Poskytněte omezenou funkčnost, dokud se systém neobnoví.

Další informace najdete v tématu Co dělat v případě výpadku služby Azure Storage.

Důležité informace o použití replikace objektů pro objekty blob najdete v požadavcích a upozorněních v dokumentaci k replikaci objektů blob bloku.

Azure Service Bus

Je důležité si uvědomit, že funkce geografického zotavení po havárii, která je součástí úrovně Premium Azure Service Bus, umožňuje okamžitou kontinuitu operací se stejnou konfigurací. Nereplikuje ale zprávy uchovávané ve frontách nebo odběrech témat ani ve frontách nedoručených zpráv. Proto je potřeba strategie zmírnění rizik, která zajistí bezproblémové převzetí služeb při selhání sekundární oblasti. Podrobný popis dalších aspektů a strategií pro zmírnění rizik najdete v dokumentaci k důležitým bodům, které je potřeba vzít v úvahu a co je potřeba vzít v úvahu.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.

Omezte příchozí provoz , nakonfigurujte aplikaci tak, aby přijímala provoz jenom ze služby Front Door. Tím se zajistí, že veškerý provoz prochází přes WAF před dosažením aplikace. Další informace najdete v tématu Návody uzamknutí přístupu k back-endu jenom službě Azure Front Door?

Sdílení prostředků mezi zdroji (CORS) Pokud vytváříte web a webové rozhraní API jako samostatné aplikace, web nemůže provádět volání AJAX na straně klienta do rozhraní API, pokud nepovolíte CORS.

Služby App Services mají podporu CORS integrovanou, takže není potřeba psát žádný další kód aplikace. Viz článek Využití aplikace API z JavaScriptu pomocí CORS. Přidejte web do seznamu povolených zdrojů pro rozhraní API.

Šifrování služby SQL Database použijte transparentní šifrování dat, pokud potřebujete šifrovat neaktivní uložená data v databázi. Tato funkce provádí šifrování a dešifrování celé databáze v reálném čase (včetně záloh a souborů transakčních protokolů) a nevyžaduje žádné změny v aplikaci. Šifrování přidává určitou latenci, proto doporučujeme oddělit data, která mají být zabezpečená, uložit je do samostatné databáze a povolit šifrování pouze pro tuto databázi.

Identita Při definování identit pro komponenty v této architektuře použijte systémové spravované identity , pokud je to možné, abyste snížili potřebu správy přihlašovacích údajů a rizika spojená se správou přihlašovacích údajů. Pokud není možné používat spravované identity systému, ujistěte se, že každá identita spravovaná uživatelem existuje pouze v jedné oblasti a nikdy se nesdílí přes hranice oblastí.

Brány firewall služeb Při konfiguraci bran firewall služby pro komponenty se ujistěte, že k službám mají přístup pouze místní služby v oblasti a že služby povolují pouze odchozí připojení, která jsou explicitně nutná pro replikaci a funkce aplikace. Zvažte použití služby Azure Private Link k dalšímu vylepšenému řízení a segmentaci. Další informace o zabezpečení webových aplikací najdete v tématu Standardní vysoce dostupná zónově redundantní webová aplikace.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.

Ukládání do mezipaměti Použití ukládání do mezipaměti ke snížení zatížení serverů, které obsluhují obsah, který se často nemění. Každý cyklus vykreslení stránky může mít vliv na náklady, protože spotřebovává výpočetní prostředky, paměť a šířku pásma. Tyto náklady se dají výrazně snížit pomocí ukládání do mezipaměti, zejména u služeb statického obsahu, jako jsou jednostrákové aplikace JavaScriptu a obsah streamování médií.

Pokud má vaše aplikace statický obsah, snižte zatížení front-endových serverů pomocí CDN. Pro data, která se často nemění, použijte Azure Cache for Redis.

Bezstavové aplikace nakonfigurované pro automatické škálování jsou nákladově efektivnější než stavové aplikace. V případě ASP.NET aplikace, která používá stav relace, ji uložte do paměti se službou Azure Cache for Redis. Další informace najdete v tématu ASP.NET Zprostředkovatel stavu relace pro Azure Cache for Redis. Další možností je použít Azure Cosmos DB jako back-endové úložiště stavu prostřednictvím poskytovatele stavu relace. Viz Použití služby Azure Cosmos DB jako ASP.NET stavu relace a poskytovatele ukládání do mezipaměti.

Funkce zvažují umístění aplikace funkcí do vyhrazeného plánu služby App Service, aby úlohy na pozadí neběžely ve stejných instancích, které zpracovávají požadavky HTTP. Pokud se úlohy na pozadí spouští přerušovaně, zvažte použití plánu Consumption, který se účtuje na základě počtu použitých spuštění a prostředků, a ne podle hodin.

Další informace najdete v části náklady v architektuře Microsoft Azure Well-Architected Framework.

K odhadu nákladů použijte cenovou kalkulačku. Tato doporučení v této části vám můžou pomoct snížit náklady.

Azure Front Door

Fakturace služby Azure Front Door má tři cenové úrovně: odchozí přenosy dat, příchozí přenosy dat a pravidla směrování. Další informace najdete v tématu Ceny služby Azure Front Door. Cenový graf nezahrnuje náklady na přístup k datům ze služeb původu a přenos do služby Front Door. Tyto náklady se účtují na základě poplatků za přenos dat, které jsou popsané v podrobnostech o cenách šířky pásma.

Azure Cosmos DB

Existují dva faktory, které určují ceny služby Azure Cosmos DB:

• Zřízená propustnost nebo jednotky žádostí za sekundu (RU/s)

  Ve službě Azure Cosmos DB je možné zřídit dva typy propustnosti, standardní a automatické škálování. Standardní propustnost přiděluje prostředky potřebné k zajištění vámi zadaných RU/s. V případě automatického škálování zřídíte maximální propustnost a Azure Cosmos DB okamžitě vertikálně navyšuje nebo snižuje kapacitu v závislosti na zatížení s minimálním 10 % maximální propustnosti automatického škálování. Standardní propustnost se účtuje za zřízenou propustnost po hodinách. Propustnost automatického škálování se účtuje za maximální spotřebovanou propustnost po hodinách.

• Spotřebované úložiště. Účtuje se vám paušální sazba za celkové množství úložiště (GB) spotřebované za data a indexy za danou hodinu.

Další informace najdete v části věnované nákladům v tématu Dobře navržená architektura Microsoft Azure.

Efektivita výkonu

Hlavní výhodou služby Azure App Service je schopnost škálovat aplikaci podle zatížení. Tady jsou některé aspekty, které byste měli mít na paměti při plánování škálování vaší aplikace.

Aplikace služby App Service

Pokud vaše řešení obsahuje několik aplikací služby App Service, zvažte jejich nasazení v rámci samostatných plánů služby App Service. Budete je tak moct nezávisle škálovat, protože poběží v oddělených instancích.

SQL Database

Zvyšuje škálovatelnost databáze SQL tím, že databázi horizontálně rozdělí. Horizontální dělení umožňuje škálovat databázi na více instancí pomocí nástrojů služby Elastic Database. Mezi potenciální výhody horizontálního dělení patří:

• Lepší propustnost transakcí.
• Dotazy můžou rychleji procházet podmnožinu dat.

Azure Front Door

Služba Front Door může provádět přesměrování zpracování SSL a také snižuje celkový počet připojení TCP s back-endovou webovou aplikací. To zlepšuje škálovatelnost, protože webová aplikace spravuje menší objem metod handshake SSL a připojení TCP. Tyto zvýšení výkonu platí i v případě, že požadavky předáte webové aplikaci jako HTTPS, a to z důvodu vysoké úrovně opětovného použití připojení.

Azure Search

Služba Azure Search eliminuje režijní náklady na komplexní vyhledávání dat v primárním úložišti a díky škálování dokáže vyrovnávat zatížení. Viz článek Úrovně škálování prostředků pro dotazy a indexování úloh ve službě Azure Search.

Provozní dokonalost

Efektivita provozu se týká provozních procesů, které nasazují aplikaci a udržují ji v provozu, a je rozšířením pokynů pro spolehlivost architektury Well-Architected Framework. Tyto pokyny poskytují podrobný přehled návrhu odolnosti vůči architektuře vaší aplikační architektury, aby se zajistilo, že jsou vaše úlohy dostupné a můžou se zotavit z selhání v libovolném měřítku. Základním návrhem tohoto přístupu je navrhnout infrastrukturu aplikací tak, aby byla vysoce dostupná, optimálně napříč několika geografickými oblastmi, jak je znázorněno v tomto návrhu.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Arvind Boggaram Pandurangaiah Setty | Vedoucí konzultant

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Podrobné informace o službě Azure Front Door – metody směrování provozu

• Vytvoření sond stavu, které hlásí celkový stav aplikace na základě vzorů monitorování koncových bodů

• Povolení skupin automatického převzetí služeb při selhání Azure SQL

• Zajištění provozní kontinuity a zotavení po havárii pomocí spárovaných oblastí Azure

Související prostředky

• N-vrstvá aplikace s více oblastmi je podobný scénář. Zobrazuje n-vrstvou aplikaci běžící v několika oblastech Azure.

• Principy návrhu pro aplikace Azure