Důležité informace o aplikační platformě pro klíčové úlohy

Klíčovou oblastí návrhu každé klíčové architektury je aplikační platforma. Platforma odkazuje na komponenty infrastruktury a služby Azure, které musí být zřízeny pro podporu aplikace. Tady je několik nadstřešujících doporučení.

• Návrh ve vrstvách Zvolte správnou sadu služeb, jejich konfiguraci a závislosti specifické pro aplikaci. Tento vícevrstvý přístup pomáhá při vytváření logických a fyzických segmentací. Je užitečné definovat role a funkce a přiřazovat příslušná oprávnění a strategie nasazení. Tento přístup nakonec zvyšuje spolehlivost systému.

• Nepostradatelná aplikace musí být vysoce spolehlivá a odolná vůči selhání datacentra a oblastem. Hlavní strategií je vytváření zónové a regionální redundance v konfiguraci aktivní-aktivní. Při výběru služeb Azure pro platformu vaší aplikace zvažte jejich Zóny dostupnosti podporu a nasazení a provozní vzory pro použití více oblastí Azure.

• Ke zvládnutí zvýšeného zatížení použijte architekturu založenou na jednotkách škálování. Jednotky škálování umožňují logicky seskupit prostředky a jednotku je možné škálovat nezávisle na jiných jednotkách nebo službách v architektuře. Pomocí modelu kapacity a očekávaného výkonu můžete definovat hranice, počet a základní měřítko jednotlivých jednotek.

V této architektuře se aplikační platforma skládá z globálního razítka, razítka nasazení a regionálních prostředků. Místní prostředky se zřizují jako součást razítka nasazení. Každé razítko odpovídá jednotce škálování a v případě, že není v pořádku, může být zcela nahrazeno.

Prostředky v každé vrstvě mají odlišné charakteristiky. Další informace najdete v tématu Model architektury typické klíčové úlohy.

Globální prostředky

Některé prostředky v této architektuře sdílí prostředky nasazené v oblastech. V této architektuře se používají k distribuci provozu napříč několika oblastmi, k uložení trvalého stavu pro celou aplikaci a k ukládání globálních statických dat do mezipaměti.

V této architektuře jsou prostředky globální vrstvy Azure Front Door, Azure Cosmos DB, Azure Container Registry a Azure Log Analytics pro ukládání protokolů a metrik z jiných prostředků globální vrstvy.

V tomto návrhu existují další základní prostředky, jako je ID Microsoft Entra a Azure DNS. V tomto obrázku byly vynechány kvůli stručnosti.

Globální nástroj pro vyrovnávání zatížení

Azure Front Door se používá jako jediný vstupní bod pro uživatelský provoz. Azure zaručuje, že Služba Azure Front Door doručí požadovaný obsah bez chyby 99,99 % času. Další podrobnosti najdete v tématu Omezení služby Front Door. Pokud služba Front Door přestane být dostupná, koncový uživatel uvidí, že je systém mimo provoz.

Instance služby Front Door odesílá provoz do nakonfigurovaných back-endových služeb, jako je výpočetní cluster, který je hostitelem rozhraní API a front-endové spa. Chybné konfigurace back-endu ve službě Front Door můžou vést k výpadkům. Abyste se vyhnuli výpadkům způsobeným chybnou konfigurací, měli byste nastavení služby Front Door důkladně otestovat.

Další běžnou chybou může být chybná konfigurace nebo chybějící certifikáty TLS, což může uživatelům zabránit v používání front-endu nebo komunikace služby Front Door s back-endem. Zmírnění může vyžadovat ruční zásah. Pokud je to možné, můžete se například rozhodnout vrátit zpět k předchozí konfiguraci a certifikát znovu vydat. Bez ohledu na to, že se projeví změny, neočekávejte nedostupnost. Použití spravovaných certifikátů nabízených službou Front Door se doporučuje snížit provozní režii, jako je zpracování vypršení platnosti.

Služba Front Door nabízí mnoho dalších funkcí kromě globálního směrování provozu. Důležitou funkcí je firewall webových aplikací (WAF), protože Front Door dokáže kontrolovat provoz, který prochází. Když je nakonfigurovaný v režimu prevence , zablokuje podezřelý provoz ještě před tím, než se dostane do některého z back-endů.

Informace o možnostech služby Front Door najdete v tématu Nejčastější dotazy ke službě Azure Front Door.

Další aspekty globální distribuce provozu najdete v tématu Klíčové pokyny pro dobře navrženou architekturu: Globální směrování.

Container Registry

Azure Container Registry slouží k ukládání artefaktů Open Container Initiative (OCI), konkrétně chartů helmu a imagí kontejnerů. Neúčastní se toku žádosti a přistupuje se k němu jen pravidelně. Před nasazením prostředků razítka se vyžaduje registr kontejneru a neměl by mít závislost na prostředcích regionální vrstvy.

Povolte zónovou redundanci a geografickou replikaci registrů, aby byl přístup k imagím rychlý a odolný vůči selháním. V případě nedostupnosti může instance převzít služby při selhání do oblastí repliky a požadavky se automaticky znovu směrují do jiné oblasti. Počítejte s přechodnými chybami při načítání imagí, dokud nebude převzetí služeb při selhání dokončeno.

K selháním může dojít také v případě, že se image odstraní neúmyslně, nové výpočetní uzly nebudou moct vyžádat image, ale stávající uzly můžou i nadále používat image uložené v mezipaměti. Primární strategií zotavení po havárii je opětovné nasazení. Artefakty v registru kontejneru je možné vygenerovat z kanálů. Registr kontejneru musí být schopný odolat mnoha souběžnému připojení, aby podporoval všechna vaše nasazení.

K povolení geografické replikace se doporučuje použít skladovou položku Premium. Funkce redundance zón zajišťuje odolnost a vysokou dostupnost v rámci konkrétní oblasti. V případě regionálního výpadku jsou repliky v jiných oblastech stále dostupné pro operace roviny dat. Pomocí této skladové položky můžete omezit přístup k imagím prostřednictvím privátních koncových bodů.

Další podrobnosti najdete v tématu Osvědčené postupy pro Azure Container Registry.

Databáze

Doporučuje se, aby se všechny stavy ukládaly globálně do databáze oddělené od regionálních razítek. Sestavte redundanci nasazením databáze napříč oblastmi. V případě důležitých úloh by synchronizace dat napříč oblastmi měla být primárním zájmem. V případě selhání by také měly být požadavky na zápis do databáze funkční.

Replikace dat v konfiguraci aktivní-aktivní se důrazně doporučuje. Aplikace by se měla okamžitě připojit k jiné oblasti. Všechny instance by měly být schopné zpracovávat požadavky na čtení a zápis.

Další informace najdete v tématu Datová platforma pro klíčové úlohy.

Globální monitorování

Azure Log Analytics slouží k ukládání diagnostických protokolů ze všech globálních prostředků. Doporučuje se omezit denní kvótu úložiště, zejména v prostředích, která se používají pro zátěžové testování. Nastavte také zásady uchovávání informací. Tato omezení zabrání jakémukoli nadměrnému překročení, které vzniknou uložením dat, která nejsou potřebná nad rámec limitu.

Důležité informace o základních službách

Systém bude pravděpodobně používat další důležité služby platformy, které můžou způsobit riziko celého systému, jako je Azure DNS a Microsoft Entra ID. Azure DNS zaručuje 100% smlouvu SLA o dostupnosti pro platné požadavky DNS. Microsoft Entra zaručuje alespoň 99,99% dobu provozu. Přesto byste měli vědět o dopadu v případě selhání.

Závislost na základních službách je nevyhnutelné, protože mnoho služeb Azure na nich závisí. Pokud nejsou dostupné, počítejte s přerušením systému. Například:

• Azure Front Door používá Azure DNS k dosažení back-endu a dalších globálních služeb.
• Azure Container Registry využívá Azure DNS k převzetí služeb při selhání požadavků do jiné oblasti.

V obou případech budou obě služby Azure ovlivněny, pokud azure DNS není k dispozici. Překlad ip adres pro požadavky uživatelů ze služby Front Door selže; Image Dockeru se z registru nepřetáhnou. Použití externí služby DNS jako zálohování nezmírní riziko, protože mnoho služeb Azure nepovoluje takovou konfiguraci a spoléhá na interní DNS. Počítejte s úplným výpadkem.

Podobně se ID Microsoft Entra používá pro operace řídicí roviny, jako je vytváření nových uzlů AKS, načítání imagí ze služby Container Registry nebo přístup ke službě Key Vault při spuštění podu. Pokud není ID Microsoft Entra k dispozici, stávající komponenty by neměly být ovlivněné, ale celkový výkon může být snížený. Nové pody nebo uzly AKS nebudou funkční. V případě, že se během této doby vyžadují operace horizontálního navýšení kapacity, očekáváme snížení uživatelského prostředí.

Prostředky razítka místního nasazení

V této architektuře nasadí razítko nasazení úlohu a zřídí prostředky, které se účastní dokončení obchodních transakcí. Kolek obvykle odpovídá nasazení do oblasti Azure. I když oblast může mít více než jedno razítko.

V této architektuře jsou prostředky kolku azure Kubernetes Service, Azure Event Hubs, Azure Key Vault a Azure Blob Storage.

Jednotka škálování

Kolek lze také považovat za jednotku škálování (SU). Všechny komponenty a služby v daném razítku se konfigurují a testují tak, aby obsluhovaly požadavky v daném rozsahu. Tady je příklad jednotky škálování použité v implementaci.

Každá jednotka škálování se nasadí do oblasti Azure a proto primárně zpracovává provoz z dané oblasti (i když může v případě potřeby převzít provoz z jiných oblastí). Toto geografické rozpětí bude pravděpodobně mít za následek vzorce zatížení a pracovní dobu, které se můžou lišit od oblasti po oblast, a proto je každá SU navržená tak, aby se při nečinnosti škálovat nebo snížit.

Můžete nasadit nové razítko pro škálování. Uvnitř razítka můžou být jednotlivé prostředky také jednotky škálování.

Tady je několik aspektů škálování a dostupnosti při výběru služeb Azure v lekci:

• Vyhodnoťte vztahy kapacity mezi všemi prostředky v jednotce škálování. Například pro zpracování 100 příchozích požadavků bude potřeba 5 podů kontroleru příchozího přenosu dat a 3 pody služby katalogu a 1000 RU ve službě Azure Cosmos DB. Proto při automatickém škálování podů příchozího přenosu dat počítejte s škálováním služby katalogu a jednotek RU služby Azure Cosmos DB vzhledem k těmto rozsahům.

• Zátěžový test služeb k určení rozsahu, ve kterém se budou požadavky obsluhovat. Na základě výsledků konfigurují minimální a maximální instance a cílové metriky. Po dosažení cíle se můžete rozhodnout automatizovat škálování celé jednotky.

• Projděte si limity a kvóty škálování předplatného Azure, které podporují kapacitu a nákladový model nastavený obchodními požadavky. Zkontrolujte také limity jednotlivých služeb, které je potřeba vzít v úvahu. Vzhledem k tomu, že jednotky se obvykle nasazují společně, zapojte do limitů prostředků předplatného, které jsou potřeba pro kanárské nasazení. Další informace najdete v tématu Omezení služby Azure.

• Zvolte služby, které podporují zóny dostupnosti pro sestavení redundance. To může omezit vaše technologické volby. Podrobnosti najdete v Zóny dostupnosti.

Další aspekty týkající se velikosti jednotky a kombinace prostředků najdete v tématu Klíčové pokyny v architektuře Dobře navržená architektura: Architektura jednotek škálování.

Výpočtový cluster

Ke kontejnerizaci úlohy musí každý kolek spustit výpočetní cluster. V této architektuře je zvolena služba Azure Kubernetes Service (AKS), protože Kubernetes je nejoblíbenější výpočetní platformou pro moderní kontejnerizované aplikace.

Životnost clusteru AKS je svázaná s dočasným charakterem razítka. Cluster je bezstavový a nemá trvalé svazky. Místo spravovaných disků používá dočasné disky s operačním systémem, protože se neočekává, že budou přijímat údržbu na úrovni aplikace nebo systému.

Pro zvýšení spolehlivosti je cluster nakonfigurovaný tak, aby používal všechny tři zóny dostupnosti v dané oblasti. Pokud chcete navíc povolit smlouvu SLA pro dobu provozu AKS s garantovanou dostupností 99,95% sla řídicí roviny AKS, cluster by měl používat úroveň Standard nebo Premium . Další informace najdete v cenových úrovních AKS.

Další faktory, jako jsou limity škálování, výpočetní kapacita nebo kvóta předplatného, můžou mít také vliv na spolehlivost. Pokud není dosaženo dostatečné kapacity nebo limitů, operace horizontálního navýšení kapacity a vertikálního navýšení kapacity selžou, ale očekává se, že budou fungovat stávající výpočetní prostředky.

Cluster má povolené automatické škálování, aby fondy uzlů v případě potřeby automaticky navyšily kapacitu, což zvyšuje spolehlivost. Při použití více fondů uzlů by měly být všechny fondy uzlů automaticky škálovány.

Na úrovni podu horizontální automatické škálování podů (HPA) škáluje pody na základě nakonfigurovaných metrik procesoru, paměti nebo vlastních metrik. Zátěžový test součástí úlohy, aby vytvořil směrný plán pro hodnoty automatického škálování a HPA.

Cluster je také nakonfigurovaný pro automatické upgrady imagí uzlů a pro správné škálování během těchto upgradů. Toto škálování umožňuje nulový výpadek během provedení upgradů. Pokud cluster v jednom razítku během upgradu selže, nemělo by to mít vliv na ostatní clustery v jiných razítkech, ale upgrady napříč kolky by měly probíhat v různých časech, aby se zachovala dostupnost. Upgrady clusteru se také automaticky zahrnou mezi uzly, aby byly nedostupné současně.

Některé komponenty, jako je cert-manager a ingress-nginx, vyžadují image kontejnerů z externích registrů kontejnerů. Pokud tato úložiště nebo image nejsou dostupná, nemusí se nové instance na nových uzlech (kde image není uložená v mezipaměti) spustit. Toto riziko je možné zmírnit importem těchto imagí do služby Azure Container Registry prostředí.

Pozorovatelnost je v této architektuře důležitá , protože kolky jsou dočasné. Nastavení diagnostiky jsou nakonfigurovaná tak, aby ukládaly všechna data protokolů a metrik do místního pracovního prostoru služby Log Analytics. Služba AKS Container Insights je také povolená prostřednictvím agenta OMS v clusteru. Tento agent umožňuje clusteru odesílat data monitorování do pracovního prostoru služby Log Analytics.

Další aspekty výpočetního clusteru najdete v důležitých doprovodných materiálech v dobře architektuře: Orchestrace kontejnerů a Kubernetes.

Key Vault

Azure Key Vault slouží k ukládání globálních tajných kódů, jako jsou připojovací řetězec do databáze a tajných kódů razítka, jako je připojovací řetězec event Hubs.

Tato architektura používá ovladač CSI úložiště tajných kódů ve výpočetním clusteru k získání tajných kódů ze služby Key Vault. Tajné kódy jsou potřeba při vytváření nových podů. Pokud není služba Key Vault dostupná, nemusí se začít používat nové pody. V důsledku toho může dojít k přerušení; Operace horizontálního navýšení kapacity můžou mít vliv, aktualizace můžou selhat, nová nasazení se nedají spustit.

Key Vault má limit počtu operací. Kvůli automatické aktualizaci tajných kódů je možné dosáhnout limitu, pokud existuje mnoho podů. Můžete se rozhodnout snížit frekvenci aktualizací , abyste se této situaci vyhnuli.

Další důležité informace o správě tajných kódů najdete v tématu Klíčové pokyny v dobře architektuře: Ochrana integrity dat.

Event Hubs

Jedinou stavovou službou v razítku je zprostředkovatel zpráv, Azure Event Hubs, který ukládá žádosti po krátkou dobu. Zprostředkovatel obsluhuje potřebu ukládání do vyrovnávací paměti a spolehlivého zasílání zpráv. Zpracovávané požadavky se uchovávají v globální databázi.

V této architektuře se používá skladová položka Standard a pro zajištění vysoké dostupnosti je povolená redundance zón.

Stav služby Event Hubs ověřuje komponenta HealthService spuštěná ve výpočetním clusteru. Provádí pravidelné kontroly různých zdrojů. To je užitečné při zjišťování podmínek, které nejsou v pořádku. Pokud například nelze odesílat zprávy do centra událostí, razítko by bylo nepoužitelné pro všechny operace zápisu. Služba HealthService by měla tuto podmínku automaticky rozpoznat a nahlásit stav není v pořádku službě Front Door, což vytáčí razítko mimo rotaci.

Pro zajištění škálovatelnosti se doporučuje povolení automatického nafouknutí.

Další informace najdete v tématu Služby zasílání zpráv pro klíčové úlohy.

Další důležité informace o zasílání zpráv najdete v tématu Klíčové pokyny v dobře architektuře: Asynchronní zasílání zpráv.

Účty úložiště

V této architektuře jsou zřízeny dva účty úložiště. Oba účty se nasazují v zónově redundantním režimu (ZRS).

Jeden účet se používá pro vytváření kontrolních bodů služby Event Hubs. Pokud tento účet nereaguje, razítko nebude moct zpracovávat zprávy ze služby Event Hubs a může to mít i vliv na jiné služby v kolku. Tato podmínka se pravidelně kontroluje službou HealthService, což je jedna z komponent aplikací spuštěných ve výpočetním clusteru.

Druhý se používá k hostování jednostrákové aplikace uživatelského rozhraní. Pokud má obsluha statického webu nějaké problémy, služba Front Door tento problém zjistí a neodesílá provoz do tohoto účtu úložiště. Během této doby může služba Front Door používat obsah uložený v mezipaměti.

Další informace o obnovení najdete v tématu Zotavení po havárii a převzetí služeb při selhání účtu úložiště.

Regionální zdroje

Systém může mít prostředky nasazené v oblasti, ale prožít prostředky razítka. V této architektuře se data pozorovatelnosti pro prostředky kolku ukládají v místních úložištích dat.

Monitorování dat pro prostředky kolku

Nasazení monitorovacích prostředků je typickým příkladem regionálních prostředků. V této architektuře má každá oblast samostatný pracovní prostor služby Log Analytics nakonfigurovaný tak, aby ukládaly všechna data protokolů a metrik vygenerovaná z prostředků kolku. Vzhledem k tomu, že zdroje místního prostředí mají razítko, jsou data k dispozici i po odstranění razítka.

Azure Log Analytics a Aplikace Azure lication Insights se používají k ukládání protokolů a metrik z platformy. Doporučuje se omezit denní kvótu úložiště, zejména v prostředích, která se používají pro zátěžové testování. Nastavte také zásady uchovávání informací pro ukládání všech dat. Tato omezení zabrání jakémukoli nadměrnému překročení, které vzniknou uložením dat, která nejsou potřebná nad rámec limitu.

Podobně se Application Insights nasadí také jako regionální prostředek, aby se shromáždila všechna data monitorování aplikací.

Doporučení k návrhu týkající se monitorování najdete v tématu Klíčové pokyny v architektuře Dobře navržená architektura: Modelování stavu.

Další kroky

Nasaďte referenční implementaci, abyste získali úplný přehled o prostředcích a jejich konfiguraci používaných v této architektuře.