Důležité informace o aplikační platformě pro klíčové úlohy v Azure
Azure poskytuje mnoho výpočetních služeb pro hostování vysoce dostupných aplikací. Služby se liší v možnostech a složitosti. Doporučujeme zvolit služby na základě:
- Nefunkční požadavky na spolehlivost, dostupnost, výkon a zabezpečení.
- Rozhodovací faktory, jako jsou škálovatelnost, náklady, funkčnost a složitost.
Volba hostitelské platformy aplikace je zásadní rozhodnutí, které ovlivňuje všechny ostatní oblasti návrhu. Starší nebo proprietární vývojový software se například nemusí spouštět ve službách PaaS nebo kontejnerizovaných aplikacích. Toto omezení by ovlivnilo vaši volbu výpočetní platformy.
Nepostradatelná aplikace může používat více než jednu výpočetní službu k podpoře více složených úloh a mikroslužeb, z nichž každá má odlišné požadavky.
Tato oblast návrhu poskytuje doporučení související s výběrem výpočetních prostředků, návrhem a možnostmi konfigurace. Doporučujeme vám také seznámit se s rozhodovacím stromem Compute.
Důležité
Tento článek je součástí klíčové řady úloh architektury Azure Well-Architected Framework. Pokud tuto řadu neznáte, doporučujeme začít s tím, co je kritická úloha?
Globální distribuce prostředků platformy
Typický vzor pro klíčové úlohy zahrnuje globální prostředky a regionální prostředky.
Služby Azure, které nejsou omezené na konkrétní oblast Azure, se nasazují nebo konfigurují jako globální prostředky. Mezi případy použití patří distribuce provozu napříč několika oblastmi, ukládání trvalého stavu pro celou aplikaci a ukládání globálních statických dat do mezipaměti. Pokud potřebujete zajistit architekturu jednotek škálování i globální distribuci, zvažte optimální distribuci nebo replikaci prostředků napříč oblastmi Azure.
Další prostředky se nasazují regionálně. Tyto prostředky, které se nasazují jako součást razítka nasazení, obvykle odpovídají jednotce škálování. Oblast ale může mít více než jedno razítko a razítko může mít více než jednu jednotku. Spolehlivost regionálních prostředků je zásadní, protože zodpovídají za provoz hlavní úlohy.
Následující obrázek znázorňuje návrh vysoké úrovně. Uživatel přistupuje k aplikaci prostřednictvím centrálního globálního vstupního bodu, který pak přesměruje požadavky na vhodné razítko místního nasazení:
Klíčové metodologie návrhu vyžaduje nasazení ve více oblastech. Tento model zajišťuje regionální odolnost proti chybám, aby aplikace zůstala dostupná i v případě, že dojde k výpadku celé oblasti. Při návrhu aplikace s více oblastmi zvažte různé strategie nasazení, jako jsou aktivní/aktivní a aktivní/pasivní, společně s požadavky na aplikace, protože pro každý přístup existují významné kompromisy. Pro důležité úlohy důrazně doporučujeme aktivní/aktivní model.
Ne každá úloha podporuje nebo vyžaduje souběžné spouštění více oblastí. Při určování optimálního rozhodnutí o návrhu byste měli zvážit konkrétní požadavky na aplikace. Pro určité scénáře aplikace, které mají nižší cíle spolehlivosti, mohou být vhodné alternativy pro aktivní/pasivní nebo horizontální dělení.
Zóny dostupnosti můžou poskytovat vysoce dostupná regionální nasazení napříč různými datacentry v rámci oblasti. Téměř všechny služby Azure jsou k dispozici buď v zónové konfiguraci, kde je služba delegovaná do konkrétní zóny, nebo zónově redundantní konfigurace, kde platforma automaticky zajišťuje, že služba pokrývá napříč zónami a dokáže odolat výpadku zóny. Tyto konfigurace poskytují odolnost proti chybám až na úrovni datacentra.
Aspekty návrhu
Regionální a zónové funkce. Ne všechny služby a možnosti jsou dostupné v každé oblasti Azure. Tento faktor by mohl mít vliv na vámi zvolené oblasti. Zóny dostupnosti také nejsou dostupné v každé oblasti.
Regionální páry. Oblasti Azure jsou seskupené do párů oblastí, které se skládají ze dvou oblastí v jedné geografické oblasti. Některé služby Azure používají spárované oblasti k zajištění kontinuity podnikových procesů a zajištění úrovně ochrany před ztrátou dat. Geograficky redundantní úložiště Azure (GRS) například automaticky replikuje data do sekundární spárované oblasti, aby byla data odolná, pokud primární oblast není obnovitelná. Pokud výpadek ovlivní více oblastí Azure, má pro obnovení prioritu alespoň jedna oblast v každé dvojici.
Konzistence dat V případě problémů s konzistencí zvažte použití globálně distribuovaného úložiště dat, razítekované regionální architektury a částečně aktivního/aktivního nasazení. V částečném nasazení jsou některé komponenty aktivní ve všech oblastech, zatímco jiné se nacházejí centrálně v primární oblasti.
Bezpečné nasazení. Architektura SDP (Safe Deployment) Azure zajišťuje, že všechny změny kódu a konfigurace (plánovaná údržba) na platformě Azure procházejí postupné zavedení. Během vydávání se analyzuje stav snížení výkonu. Po úspěšném dokončení kanárských a pilotních fází se aktualizace platformy serializují napříč regionálními páry, takže se v daném okamžiku aktualizuje pouze jedna oblast v jednotlivých párech.
Kapacita platformy. Stejně jako každý poskytovatel cloudu má Azure konečné prostředky. Nedostupnost může být výsledkem omezení kapacity v oblastech. Pokud dojde k oblastnímu výpadku, zvyšuje se poptávka po prostředcích při pokusu o zotavení v rámci spárované oblasti. Výpadek může způsobit problém s kapacitou, kdy nabídka dočasně nesplňuje poptávku.
Doporučení k návrhu
Nasaďte řešení do aspoň dvou oblastí Azure, abyste lépe chránili před oblastmi výpadky. Nasaďte ho v oblastech s možnostmi a charakteristikami, které úloha vyžaduje. Možnosti by měly splňovat cíle výkonu a dostupnosti při plnění požadavků na rezidenci a uchovávání dat.
Některé požadavky na dodržování předpisů dat můžou například omezit počet dostupných oblastí a potenciálně vynutit ohrožení návrhu. V takových případech důrazně doporučujeme přidat další investice do provozních obálk, které předpovídají, detekují a reagují na selhání. Předpokládejme, že jste omezeni na zeměpisnou oblast se dvěma oblastmi a pouze jedna z těchto oblastí podporuje zóny dostupnosti (model 3 + 1 datacentra). Vytvořte sekundární model nasazení pomocí izolace domény selhání, abyste umožnili nasazení obou oblastí v aktivní konfiguraci a zajistili, že primární oblast bude mít více razítek nasazení.
Pokud vhodné oblasti Azure nenabízí všechny funkce, které potřebujete, připravte se na ohrožení konzistence místních razítek nasazení, abyste upřednostnili geografickou distribuci a maximalizovali spolehlivost. Pokud je vhodná jenom jedna oblast Azure, nasaďte ve vybrané oblasti několik razítek nasazení (jednotky regionálního škálování) ke zmírnění některých rizik a použijte zóny dostupnosti k zajištění odolnosti proti chybám na úrovni datacentra. Takový významný kompromis v geografickém rozdělení ale výrazně omezuje dosažitelné složeného cíle úrovně služeb a celkovou spolehlivost.
Důležité
Pro scénáře, které cílí na cíl úrovně služby, která je větší nebo rovna 99,99 %, doporučujeme minimálně tři oblasti nasazení. Vypočítejte složené SLO pro všechny toky uživatelů. Zajistěte, aby tyto cíle byly v souladu s obchodními cíli.
V případě vysoce škálovatelných aplikačních scénářů, které mají značné objemy provozu, navrhujte řešení pro škálování napříč několika oblastmi, abyste mohli procházet potenciální omezení kapacity v rámci jedné oblasti. Další razítka místního nasazení můžou dosáhnout vyššího složeného cíle úrovně služby. Další informace najdete v tématu implementace cílů ve více oblastech.
Definujte a ověřte cíle bodu obnovení (RPO) a plánovanou dobu obnovení (RTO).
V rámci jedné geografické oblasti upřednostňujte použití párů oblastí, aby bylo možné využít serializované zavedení protokolu SDP pro plánovanou údržbu a regionální stanovení priorit pro neplánovanou údržbu.
Geograficky společně přidělujte prostředky Azure uživatelům, abyste minimalizovali latenci sítě a maximalizovali kompletní výkon.
- K zajištění optimální latence sítě pro distribuované uživatelské základny můžete použít také řešení, jako je síť pro doručování obsahu (CDN) nebo ukládání do mezipaměti edge. Další informace najdete v tématu Globální směrování provozu, služby doručování aplikací a ukládání do mezipaměti a doručování statického obsahu.
Když zvolíte oblasti nasazení, srovnejte aktuální dostupnost služeb s plány produktů. Některé služby nemusí být okamžitě dostupné v každé oblasti.
Vytváření kontejnerů
Kontejner obsahuje kód aplikace a související konfigurační soubory, knihovny a závislosti, které aplikace potřebuje spustit. Kontejnerizace poskytuje abstraktní vrstvu pro kód aplikace a její závislosti a vytváří oddělení od základní hostitelské platformy. Jeden softwarový balíček je vysoce přenosný a může konzistentně běžet napříč různými platformami infrastruktury a poskytovateli cloudu. Vývojáři nemusí přepisovat kód a můžou rychleji a spolehlivěji nasazovat aplikace.
Důležité
Doporučujeme používat kontejnery pro klíčové balíčky aplikací. Zlepšují využití infrastruktury, protože můžete hostovat více kontejnerů ve stejné virtualizované infrastruktuře. Vzhledem k tomu, že veškerý software je součástí kontejneru, můžete aplikaci přesunout napříč různými operačními systémy bez ohledu na moduly runtime nebo verze knihoven. Správa je také jednodušší s kontejnery než u tradičního virtualizovaného hostování.
Důležité aplikace musí rychle škálovat, aby se zabránilo kritickým bodům výkonu. Vzhledem k tomu, že image kontejnerů jsou předem připravené, můžete omezit spouštění pouze při spouštění aplikace, což poskytuje rychlou škálovatelnost.
Aspekty návrhu
Monitorování. Monitorování služeb pro přístup k aplikacím, které jsou v kontejnerech, může být obtížné. Obvykle potřebujete software třetích stran ke shromažďování a ukládání indikátorů stavu kontejneru, jako je využití procesoru nebo paměti RAM.
Zabezpečení. Jádro operačního systému hostitelské platformy se sdílí napříč několika kontejnery a vytváří jediný bod útoku. Riziko přístupu k hostitelskému virtuálnímu počítači je však omezené, protože kontejnery jsou izolované od základního operačního systému.
Stav. I když je možné ukládat data do systému souborů spuštěného kontejneru, data se při opětovném vytvoření kontejneru neuchovají. Místo toho zachovají data připojením externího úložiště nebo použitím externí databáze.
Doporučení k návrhu
Kontejnerizace všech komponent aplikace Použití imagí kontejneru jako primárního modelu pro balíčky nasazení aplikací
Pokud je to možné, upřednostnit moduly runtime kontejnerů založené na Linuxu. Image jsou odlehčí a často se vydávají nové funkce pro uzly a kontejnery s Linuxem.
Vytváření neměnných a nahraditelných kontejnerů krátkými životními cykly
Nezapomeňte shromáždit všechny relevantní protokoly a metriky z kontejneru, hostitele kontejneru a základního clusteru. Odešlete shromážděné protokoly a metriky do sjednocené jímky dat pro další zpracování a analýzu.
Ukládání imagí kontejneru ve službě Azure Container Registry Pomocí geografické replikace můžete replikovat image kontejnerů napříč všemi oblastmi. Povolte Microsoft Defender pro registry kontejnerů a poskytněte tak kontrolu ohrožení zabezpečení imagí kontejnerů. Ujistěte se, že přístup k registru spravuje ID Microsoft Entra.
Hostování a orchestrace kontejnerů
Několik aplikačních platforem Azure může efektivně hostovat kontejnery. Existují výhody a nevýhody spojené s každou z těchto platforem. Porovnejte možnosti v kontextu vašich obchodních požadavků. Vždy ale optimalizujte spolehlivost, škálovatelnost a výkon. Další informace naleznete v těchto článcích:
Důležité
Služba Azure Kubernetes Service (AKS) a Azure Container Apps by měly být mezi vašimi prvními možnostmi správy kontejnerů v závislosti na vašich požadavcích. I když Aplikace Azure Service není orchestrátor, jako platforma pro kontejnery s nízkým třením, je to stále možná alternativa k AKS.
Aspekty návrhu a doporučení pro Azure Kubernetes Service
AKS, spravovaná služba Kubernetes, umožňuje rychlé zřizování clusterů bez nutnosti složitých aktivit správy clusteru a nabízí sadu funkcí, která zahrnuje pokročilé možnosti sítí a identit. Kompletní sadu doporučení najdete v tématu Azure Well-Architected Framework – AKS.
Důležité
Existuje několik základních rozhodnutí o konfiguraci, která se nedají změnit bez opětovného nasazení clusteru AKS. Mezi příklady patří volba mezi veřejnými a privátními clustery AKS, povolením služby Azure Network Policy, integrací Microsoft Entra a použitím spravovaných identit pro AKS místo instančních objektů.
Spolehlivost
AKS spravuje nativní řídicí rovinu Kubernetes. Pokud řídicí rovina není dostupná, dojde k výpadkům úloh. Využijte výhody funkcí spolehlivosti, které nabízí AKS:
Nasaďte clustery AKS napříč různými oblastmi Azure jako jednotku škálování, abyste maximalizovali spolehlivost a dostupnost. Využijte zóny dostupnosti k maximalizaci odolnosti v rámci oblasti Azure tím, že distribuuje řídicí rovinu AKS a uzly agentů mezi fyzicky oddělená datacentra. Pokud je ale latence kolokace problém, můžete provést nasazení AKS v rámci jedné zóny nebo pomocí skupin umístění bezkontaktní komunikace minimalizovat latenci mezi uzlu.
Využijte smlouvu SLA pro dobu provozu AKS pro produkční clustery k maximalizaci záruk dostupnosti koncových bodů rozhraní API Kubernetes.
Škálovatelnost
Vezměte v úvahu omezení škálování AKS, jako je počet uzlů, fondy uzlů na cluster a clustery na předplatné.
Pokud limity škálování představují omezení, využijte strategii jednotky škálování a nasaďte s clustery další jednotky.
Povolte automatické škálování clusteru, aby automaticky upravil počet uzlů agenta v reakci na omezení prostředků.
Pomocí horizontálního automatického škálování podů můžete upravit počet podů v nasazení na základě využití procesoru nebo jiných metrik.
U scénářů s vysokým škálováním a nárůstem zvažte použití virtuálních uzlů pro rozsáhlé a rychlé škálování.
Definujte požadavky a omezení prostředků podů v manifestech nasazení aplikací. Pokud ne, může docházet k problémům s výkonem.
Izolace
Udržujte hranice mezi infrastrukturou používanou úlohami a systémovými nástroji. Sdílení infrastruktury může vést ke scénářům vysokého využití prostředků a hlučného souseda.
Pro systémové služby a služby úloh použijte samostatné fondy uzlů. Vyhrazené fondy uzlů pro komponenty úloh by měly být založené na požadavcích na specializované prostředky infrastruktury, jako jsou virtuální počítače s GPU s vysokou pamětí. Obecně platí, že pokud chcete snížit nepotřebné režijní náklady na správu, vyhněte se nasazování velkého počtu fondů uzlů.
Pomocí taintů a tolerance můžete poskytovat vyhrazené uzly a omezovat aplikace náročné na prostředky.
Vyhodnoťte požadavky na spřažení aplikací a anti-spřažení a nakonfigurujte odpovídající umístění kontejnerů na uzlech.
Zabezpečení
Výchozí vanilla Kubernetes vyžaduje významnou konfiguraci, která zajistí vhodný stav zabezpečení pro klíčové scénáře. AKS řeší různá bezpečnostní rizika. Mezi funkce patří privátní clustery, auditování a přihlašování ke službě Log Analytics, image posílených uzlů a spravované identity.
Použijte pokyny ke konfiguraci uvedené v standardních hodnotách zabezpečení AKS.
Pomocí funkcí AKS můžete zpracovávat správu identit clusteru a přístupu, abyste snížili provozní režii a použili konzistentní správu přístupu.
Používejte spravované identity místo instančních objektů, abyste se vyhnuli správě a obměně přihlašovacích údajů. Spravované identity můžete přidat na úrovni clusteru. Na úrovni podu můžete spravované identity používat prostřednictvím ID úloh Microsoft Entra.
Integrace Microsoft Entra slouží k centralizované správě účtů a heslům, správě přístupu k aplikacím a rozšířené ochraně identit. Použijte Kubernetes RBAC s Microsoft Entra ID pro nejnižší oprávnění a minimalizujte udělení oprávnění správce, abyste mohli chránit konfiguraci a přístup k tajným kódům. Omezte také přístup ke konfiguračnímu souboru clusteru Kubernetes pomocí řízení přístupu na základě role v Azure. Omezte přístup k akcím, které mohou kontejnery provádět, poskytněte nejnižší počet oprávnění a vyhněte se eskalaci kořenových oprávnění.
Upgrady
Clustery a uzly je potřeba pravidelně upgradovat. AKS podporuje verze Kubernetes v souladu s cyklem vydávání nativních Kubernetes.
Přihlaste se k odběru veřejného plánu AKS a poznámky k verzi na GitHubu, abyste zůstali aktuální o nadcházejících změnách, vylepšeních a nejdůležitějších verzích Kubernetes a vyřazení verzí.
Použijte pokyny uvedené v kontrolním seznamu AKS, abyste zajistili soulad s osvědčenými postupy.
Mějte na paměti různé metody podporované službou AKS pro aktualizaci uzlů nebo clusterů. Tyto metody mohou být ruční nebo automatizované. K definování časových období údržby pro tyto operace můžete použít plánovanou údržbu . Nové obrázky se vydávají každý týden. AKS také podporuje kanály automatického upgradu pro automatické upgrade clusterů AKS na novější verze imagí Kubernetes nebo novějších uzlů, pokud jsou k dispozici.
Sítě
Vyhodnoťte síťové moduly plug-in, které nejlépe vyhovují vašemu případu použití. Určete, jestli potřebujete podrobnou kontrolu provozu mezi pody. podpora Azure s kubenet, Azure CNI a přineste si vlastní CNI pro konkrétní případy použití.
Určete prioritu použití Azure CNI po posouzení požadavků na síť a velikosti clusteru. Azure CNI umožňuje používat zásady sítě Azure nebo Calico pro řízení provozu v rámci clusteru.
Sledování
Monitorovací nástroje by měly být schopné zaznamenávat protokoly a metriky ze spuštěných podů. Měli byste také shromažďovat informace z rozhraní API pro metriky Kubernetes, abyste mohli monitorovat stav spuštěných prostředků a úloh.
Pomocí služby Azure Monitor a Application Insights můžete shromažďovat metriky, protokoly a diagnostiku z prostředků AKS pro účely řešení potíží.
Povolte a zkontrolujte protokoly prostředků Kubernetes.
Konfigurace metrik Prometheus ve službě Azure Monitor Přehledy kontejnerů ve službě Monitor poskytují onboarding, umožňují funkce monitorování a umožňují pokročilejší funkce prostřednictvím integrované podpory Prometheus.
Řízení
Zásady použijte k konzistentnímu použití centralizovaných ochranných opatření pro clustery AKS. Přiřazení zásad můžete použít v oboru předplatného nebo vyšší, aby se řídila konzistence napříč vývojovými týmy.
Pomocí Služby Azure Policy můžete řídit, které funkce se udělují podům a jestli jsou spuštěné v rozporu se zásadami. Tento přístup je definován prostřednictvím předdefinovaných zásad poskytovaných doplňkem Azure Policy pro AKS.
Vytvořte konzistentní standardní hodnoty spolehlivosti a zabezpečení pro konfigurace clusteru a podů AKS pomocí služby Azure Policy.
Pomocí doplňku Azure Policy pro AKS můžete řídit funkce podů, jako jsou kořenová oprávnění, a zakázat pody, které nevyhovují zásadám.
Poznámka:
Když nasadíte do cílové zóny Azure, zásady Azure, které vám pomůžou zajistit konzistentní spolehlivost a zabezpečení, by měla být poskytována implementací cílové zóny.
Klíčové referenční implementace poskytují sadu základních zásad pro zajištění doporučené spolehlivosti a konfigurace zabezpečení.
Aspekty návrhu a doporučení pro službu Aplikace Azure Service
Pro scénáře úloh založených na webových a rozhraních API může být App Service možná alternativou k AKS. Poskytuje nízkotřekovou kontejnerovou platformu bez složitosti Kubernetes. Kompletní sadu doporučení najdete v tématu Aspekty spolehlivosti pro App Service a efektivitu provozu pro App Service.
Spolehlivost
Vyhodnoťte použití portů TCP a SNAT. Připojení TCP se používají pro všechna odchozí připojení. Porty SNAT se používají pro odchozí připojení k veřejným IP adresám. Vyčerpání portů SNAT je běžným scénářem selhání. Tento problém byste měli prediktivní detekovat zátěžovým testováním při monitorování portů pomocí diagnostiky Azure. Pokud dojde k chybám SNAT, musíte škálovat více nebo větších pracovních procesů nebo implementovat postupy kódování, které vám pomůžou zachovat a opakovaně používat porty SNAT. Mezi příklady postupů kódování, které můžete použít, patří sdružování připojení a opožděné načítání prostředků.
Vyčerpání portů TCP je dalším scénářem selhání. Nastane, když součet odchozích připojení z daného pracovního procesu překročí kapacitu. Počet dostupných portů TCP závisí na velikosti pracovního procesu. Doporučení najdete v tématu Porty TCP a SNAT.
Škálovatelnost
Naplánujte budoucí požadavky na škálovatelnost a růst aplikací, abyste mohli začít používat příslušná doporučení. Tímto způsobem se můžete vyhnout dluhu technické migrace, protože řešení roste.
Povolte automatické škálování, abyste zajistili dostupnost odpovídajících prostředků pro žádosti o služby. Vyhodnoťte škálování jednotlivých aplikací pro hostování s vysokou hustotou ve službě App Service.
Mějte na paměti, že služba App Service má výchozí a měkký limit instancí na plán služby App Service.
Použijte pravidla automatického škálování. Plán služby App Service se škáluje na více instancí, pokud je splněné jakékoli pravidlo v rámci profilu, ale škáluje se pouze v případě, že jsou splněna všechna pravidla v rámci profilu. Pomocí kombinace pravidel horizontálního navýšení kapacity a horizontálního navýšení kapacity zajistíte, že automatické škálování může provádět akce horizontálního navýšení kapacity i horizontálního navýšení kapacity. Seznamte se s chováním více pravidel škálování v jednom profilu.
Mějte na paměti, že škálování jednotlivých aplikací můžete povolit na úrovni plánu služby App Service, aby se aplikace mohla škálovat nezávisle na plánu služby App Service, který ho hostuje. Aplikace se přidělují dostupným uzlům prostřednictvím přístupu s nejlepším úsilím pro rovnoměrnou distribuci. I když není zaručená rovnoměrná distribuce, platforma zajišťuje, že dvě instance stejné aplikace nejsou hostované ve stejné instanci.
Sledování
Monitorujte chování aplikace a získejte přístup k relevantním protokolům a metrikám, abyste měli jistotu, že vaše aplikace funguje podle očekávání.
Protokolování diagnostiky můžete použít k ingestování protokolů na úrovni aplikace a platformy do Log Analytics, Azure Storage nebo nástroje třetí strany prostřednictvím služby Azure Event Hubs.
Monitorování výkonu aplikací pomocí Application Insights poskytuje podrobné přehledy o výkonu aplikací.
Klíčové aplikace musí mít možnost samoléčit, pokud dojde k selháním. Povolte funkci Automatické oprava , aby se automaticky recyklovávaly pracovní procesy, které nejsou v pořádku.
K vyhodnocení všech kritických podřízených závislostí, které pomáhají zajistit celkový stav, musíte použít odpovídající kontroly stavu. Důrazně doporučujeme povolit kontrolu stavu, abyste identifikovali nereagované pracovní procesy.
Nasazení
Pokud chcete obejít výchozí limit instancí na plán služby App Service, nasaďte plány služby App Service v několika jednotkách škálování v jedné oblasti. Nasaďte plány služby App Service v konfiguraci zóny dostupnosti, abyste zajistili distribuci pracovních uzlů napříč zónami v rámci oblasti. Zvažte otevření lístku podpory, abyste zvýšili maximální počet pracovních procesů na dvojnásobek počtu instancí, které potřebujete k zajištění normálního zatížení ve špičce.
Registr kontejneru
Registry kontejnerů hostují image nasazené v prostředích runtime kontejnerů, jako je AKS. Pro důležité úlohy je potřeba pečlivě nakonfigurovat registry kontejnerů. Výpadek by neměl způsobit zpoždění při načítání imagí, zejména při operacích škálování. Následující aspekty a doporučení se zaměřují na Službu Azure Container Registry a prozkoumejte kompromisy spojené s centralizovanými a federovanými modely nasazení.
Aspekty návrhu
Formát. Zvažte použití registru kontejneru, který využívá formát a standardy poskytované Dockerem pro operace nabízení i vyžádání obsahu. Tato řešení jsou kompatibilní a většinou zaměnitelná.
Model nasazení: Registr kontejneru můžete nasadit jako centralizovanou službu, kterou využívá více aplikací ve vaší organizaci. Nebo ji můžete nasadit jako vyhrazenou komponentu pro konkrétní úlohu aplikace.
Veřejné registry. Image kontejnerů se ukládají ve službě Docker Hub nebo v jiných veřejných registrech, které existují mimo Azure a v dané virtuální síti. To nemusí být nutně problém, ale může vést k různým problémům souvisejícím s dostupností služeb, omezováním a exfiltrací dat. V některých scénářích aplikace je potřeba replikovat image veřejného kontejneru v privátním registru kontejnerů, abyste omezili odchozí provoz, zvýšili dostupnost nebo se vyhnuli potenciálnímu omezování.
Doporučení k návrhu
Použijte instance registru kontejneru, které jsou vyhrazené pro úlohu aplikace. Vyhněte se vytváření závislostí na centralizované službě, pokud nejsou požadavky organizace na dostupnost a spolehlivost plně v souladu s aplikací.
V doporučeném vzoru základní architektury jsou registry kontejnerů globálními prostředky, které už dlouho žijí. Zvažte použití jednoho globálního registru kontejneru pro každé prostředí. Použijte například globální produkční registr.
Ujistěte se, že smlouva SLA pro veřejný registr odpovídá vašim cílům spolehlivosti a zabezpečení. Poznamenejte si zvláštní omezení omezení pro případy použití, které závisí na Docker Hubu.
Určete prioritu služby Azure Container Registry pro hostování imagí kontejnerů.
Aspekty návrhu a doporučení pro Azure Container Registry
Tato nativní služba poskytuje celou řadu funkcí, včetně geografické replikace, ověřování Microsoft Entra, automatizovaného sestavování kontejnerů a oprav prostřednictvím úloh služby Container Registry.
Spolehlivost
Nakonfigurujte geografickou replikaci do všech oblastí nasazení, abyste odebrali místní závislosti a optimalizovali latenci. Container Registry podporuje vysokou dostupnost prostřednictvím geografické replikace do několika konfigurovaných oblastí a zajišťuje odolnost proti oblastním výpadkům. Pokud oblast přestane být dostupná, ostatní oblasti budou dál obsluhovat požadavky na image. Jakmile je oblast opět online, služba Container Registry se obnoví a replikuje do ní změny. Tato funkce také poskytuje kolokaci registru v rámci každé nakonfigurované oblasti, což snižuje latenci sítě a náklady na přenos dat mezi oblastmi.
V oblastech Azure, které poskytují podporu zóny dostupnosti, úroveň Premium Container Registry podporuje redundanci zón, která zajišťuje ochranu před zónovým selháním. Úroveň Premium také podporuje privátní koncové body , které pomáhají zabránit neoprávněnému přístupu k registru, což může vést k problémům se spolehlivostí.
Hostování imagí blízko využívání výpočetních prostředků ve stejných oblastech Azure
Uzamykání obrázků
Obrázky se můžou odstranit například v důsledku ruční chyby. Container Registry podporuje uzamčení verze image nebo úložiště , aby se zabránilo změnám nebo odstraněním. Když se dříve nasazená verze image změní, nasazení stejné verze můžou před změnou a po změně poskytovat různé výsledky.
Pokud chcete chránit instanci služby Container Registry před odstraněním, použijte zámky prostředků.
Označené obrázky
Označené image Container Registry jsou ve výchozím nastavení proměnlivé, což znamená, že stejnou značku lze použít u více imagí nabízených do registru. V produkčních scénářích to může vést k nepředvídatelným chováním, které by mohlo ovlivnit dobu provozu aplikace.
Správa identit a přístupu
Integrované ověřování Microsoft Entra použijte k nabízení a vyžádání imagí místo toho, abyste se museli spoléhat na přístupové klíče. Pokud chcete zvýšit zabezpečení, plně zakažte použití přístupového klíče správce.
Bezserverové výpočetní prostředí
Bezserverová architektura poskytuje prostředky na vyžádání a eliminuje potřebu správy infrastruktury. Poskytovatel cloudu automaticky zřídí, škáluje a spravuje prostředky potřebné ke spuštění nasazeného kódu aplikace. Azure poskytuje několik bezserverových výpočetních platforem:
Funkce Azure Functions. Když používáte Azure Functions, logika aplikace se implementuje jako samostatné bloky kódu nebo funkcí, které se spouští v reakci na události, jako je požadavek HTTP nebo zpráva fronty. Každá funkce se škáluje podle potřeby, aby splňovala poptávku.
Azure Logic Apps. Služba Logic Apps je nejvhodnější pro vytváření a spouštění automatizovaných pracovních postupů, které integrují různé aplikace, zdroje dat, služby a systémy. Podobně jako Azure Functions služba Logic Apps používá integrované triggery pro zpracování řízené událostmi. Místo nasazení kódu aplikace ale můžete vytvářet aplikace logiky pomocí grafického uživatelského rozhraní, které podporuje bloky kódu, jako jsou podmíněné podmínky a smyčky.
Azure API Management. Službu API Management můžete použít k publikování, transformaci, údržbě a monitorování rozhraní API rozšířeného zabezpečení pomocí úrovně Consumption.
Power Apps a Power Automate Tyto nástroje poskytují prostředí pro vývoj bez kódu nebo bez kódu s jednoduchou logikou pracovního postupu a integracemi, které lze konfigurovat prostřednictvím připojení v uživatelském rozhraní.
Pro klíčové aplikace poskytují bezserverové technologie zjednodušený vývoj a provoz, což může být cenné pro jednoduché případy použití firmy. Tato jednoduchost ale přináší náklady na flexibilitu z hlediska škálovatelnosti, spolehlivosti a výkonu a to není možné pro většinu důležitých scénářů aplikace.
Následující části obsahují aspekty návrhu a doporučení pro používání Azure Functions a Logic Apps jako alternativních platforem pro scénáře nekritických pracovních postupů.
Aspekty návrhu a doporučení pro Azure Functions
Klíčové úlohy mají kritické a nekritické systémové toky. Azure Functions je realizovatelná volba pro toky, které nemají stejné přísné obchodní požadavky jako kritické systémové toky. Je vhodný pro toky řízené událostmi, které mají krátkodobé procesy, protože funkce provádějí jedinečné operace, které běží co nejrychleji.
Zvolte možnost hostování Azure Functions, která je vhodná pro úroveň spolehlivosti aplikace. Doporučujeme plán Premium, protože umožňuje nakonfigurovat velikost výpočetní instance. Plán Dedicated je nejméně bezserverová možnost. Poskytuje automatické škálování, ale tyto operace škálování jsou pomalejší než ty z ostatních plánů. Doporučujeme použít plán Premium k maximalizaci spolehlivosti a výkonu.
Existuje několik aspektů zabezpečení. Pokud k zveřejnění externího koncového bodu použijete trigger HTTP, použijte firewall webových aplikací (WAF) k zajištění úrovně ochrany koncového bodu HTTP před běžnými externími vektory útoku.
Pro omezení přístupu k privátním virtuálním sítím doporučujeme používat privátní koncové body. Můžou také zmírnit rizika exfiltrace dat, jako jsou scénáře správců se zlými úmysly.
Potřebujete použít nástroje pro kontrolu kódu v kódu Azure Functions a integrovat tyto nástroje s kanály CI/CD.
Aspekty návrhu a doporučení pro Azure Logic Apps
Podobně jako Azure Functions služba Logic Apps používá integrované triggery pro zpracování řízené událostmi. Místo nasazení kódu aplikace ale můžete vytvářet aplikace logiky pomocí grafického uživatelského rozhraní, které podporuje bloky, jako jsou podmíněné vzorce, smyčky a další konstrukce.
K dispozici je několik režimů nasazení. Doporučujeme standardní režim, který zajistí nasazení s jedním tenantem a zmírní scénáře hlučného souseda. Tento režim používá kontejnerizovaný modul runtime Logic Apps s jedním tenantem, který je založený na službě Azure Functions. V tomto režimu může aplikace logiky mít několik stavových a bezstavových pracovních postupů. Měli byste vědět o limitech konfigurace.
Omezené migrace prostřednictvím IaaS
Mnoho aplikací, které mají existující místní nasazení, využívá virtualizační technologie a redundantní hardware k zajištění klíčové úrovně spolehlivosti. Modernizace často brání obchodním omezením, která brání plnému sladění se vzorem architektury nativní pro cloud (North Star), který se doporučuje pro klíčové úlohy. To je důvod, proč mnoho aplikací přijímá fázovaný přístup s počátečním cloudovým nasazením pomocí virtualizace a služby Azure Virtual Machines jako primárního modelu hostování aplikací. V určitých scénářích může být vyžadováno použití virtuálních počítačů infrastruktury jako služby (IaaS):
- Dostupné služby PaaS neposkytují požadovaný výkon ani úroveň řízení.
- Úloha vyžaduje přístup k operačnímu systému, konkrétní ovladače nebo konfigurace sítě a systému.
- Úloha nepodporuje spouštění v kontejnerech.
- Pro úlohy třetích stran neexistuje žádná podpora dodavatele.
Tato část se zaměřuje na nejlepší způsoby použití virtuálních počítačů a přidružených služeb k maximalizaci spolehlivosti aplikační platformy. Zdůrazňuje klíčové aspekty klíčové metodologie návrhu, která transponuje scénáře migrace nativních pro cloud a IaaS.
Aspekty návrhu
Provozní náklady na používání virtuálních počítačů IaaS jsou výrazně vyšší než náklady na používání služeb PaaS z důvodu požadavků na správu virtuálních počítačů a operačních systémů. Správa virtuálních počítačů vyžaduje časté zavedení softwarových balíčků a aktualizací.
Azure poskytuje možnosti pro zvýšení dostupnosti virtuálních počítačů:
- Zóny dostupnosti vám můžou pomoct dosáhnout ještě vyšší úrovně spolehlivosti tím, že distribuují virtuální počítače mezi fyzicky oddělená datacentra v rámci oblasti.
- Škálovací sady virtuálních počítačů Azure poskytují funkce pro automatické škálování počtu virtuálních počítačů ve skupině. Poskytují také možnosti pro monitorování stavu instance a automatické opravy instancí, které nejsou v pořádku.
- Škálovací sady s flexibilní orchestrací můžou pomoct chránit před selháním sítě, disku a napájení tím, že automaticky distribuují virtuální počítače napříč doménami selhání.
Doporučení k návrhu
Důležité
Pokud je to možné, používejte služby a kontejnery PaaS, abyste snížili provozní složitost a náklady. Virtuální počítače IaaS používejte jenom v případě, že potřebujete.
Správné velikosti skladových položek virtuálních počítačů pro zajištění efektivního využití prostředků
Nasaďte tři nebo více virtuálních počítačů napříč zónami dostupnosti, abyste dosáhli odolnosti proti chybám na úrovni datacentra.
- Pokud nasazujete komerční off-the-police software, obraťte se na dodavatele softwaru a proveďte odpovídající testování před nasazením softwaru do produkčního prostředí.
Pro úlohy, které nemůžete nasadit napříč zónami dostupnosti, použijte flexibilní škálovací sady virtuálních počítačů, které obsahují tři nebo více virtuálních počítačů. Další informace o tom, jak nakonfigurovat správný počet domén selhání, najdete v tématu Správa domén selhání ve škálovacích sadách.
Určete prioritu použití škálovacích sad virtuálních počítačů pro zajištění škálovatelnosti a redundance zón. Tento bod je zvlášť důležitý pro úlohy, které mají různá zatížení. Pokud je například počet aktivních uživatelů nebo požadavků za sekundu různá zátěž.
Nepřistupujte přímo k jednotlivým virtuálním počítačům. Pokud je to možné, používejte před nimi nástroje pro vyrovnávání zatížení.
Pokud chcete chránit před oblastmi výpadků, nasaďte virtuální počítače aplikací napříč několika oblastmi Azure.
- Podrobnosti o optimálním směrování provozu mezi aktivními oblastmi nasazení najdete v oblasti návrhu sítě a připojení.
U úloh, které nepodporují nasazení typu aktivní/aktivní ve více oblastech, zvažte implementaci nasazení typu aktivní/pasivní pomocí aktivních/teplých pohotovostních virtuálních počítačů pro regionální převzetí služeb při selhání.
Používejte standardní image z Azure Marketplace místo vlastních imagí, které je potřeba udržovat.
Implementujte automatizované procesy pro nasazení a zavedení změn virtuálních počítačů, abyste se vyhnuli ručnímu zásahu. Další informace najdete v tématu Aspekty IaaS v oblasti návrhu provozních postupů .
Implementujte experimenty chaosu pro vkládání chyb aplikací do komponent virtuálních počítačů a sledujte zmírnění chyb. Další informace najdete v tématu Průběžné ověřování a testování.
Monitorujte virtuální počítače a ujistěte se, že se diagnostické protokoly a metriky ingestují do sjednocené jímky dat.
Implementujte postupy zabezpečení pro klíčové scénáře aplikací, pokud je to možné, a osvědčené postupy zabezpečení pro úlohy IaaS v Azure.
Další krok
Projděte si důležité informace o datové platformě.