Sdílet prostřednictvím

Aspekty aplikační platformy pro klíčové úlohy v Azure

  • Článek

Azure poskytuje mnoho výpočetních služeb pro hostování vysoce dostupných aplikací. Služby se liší schopnostmi a složitostí. Doporučujeme zvolit služby na základě:

  • Nefunkční požadavky na spolehlivost, dostupnost, výkon a zabezpečení.
  • Rozhodovací faktory, jako je škálovatelnost, náklady, provozuschopnost a složitost.

Volba platformy pro hostování aplikací je zásadním rozhodnutím, které ovlivňuje všechny ostatní oblasti návrhu. Například starší nebo proprietární vývojový software nemusí běžet ve službách PaaS nebo v kontejnerizovaných aplikacích. Toto omezení by ovlivnilo vaši volbu výpočetní platformy.

Kriticky důležitá 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 možnostmi výběru, návrhu a konfigurace výpočetních prostředků. Doporučujeme také seznámit se s rozhodovacím stromem Compute.

Důležité

Tento článek je součástí řady klíčových úloh Azure Well-Architected Framework . Pokud tuto řadu neznáte, doporučujeme začít na co je kritická úloha?.

Globální distribuce prostředků platformy

Typický vzor pro kritickou úlohu 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 některé 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 pojmout 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 však může mít více než jedno razítko a razítko může obsahovat více než jednu jednotku. Spolehlivost místní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í:

Diagram znázorňující kritickou architekturu

Metodologie klíčového 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 je aktivní/aktivní a aktivní/pasivní, spolu s požadavky aplikace, protože pro každý přístup existují významné kompromisy. V případě kritických úloh důrazně doporučujeme model aktivní/aktivní.

Ne každá úloha podporuje nebo nevyžaduje souběžné spouštění více oblastí. Pokud chcete určit optimální rozhodnutí o návrhu, měli byste zvážit konkrétní požadavky aplikace proti kompromisům. V některých scénářích aplikací, které mají nižší cíle spolehlivosti, může být vhodným řešením aktivní/pasivní nebo horizontální dělení.

Zóny dostupnosti můžou poskytovat vysoce dostupná regionální nasazení napříč různými datovými centry v rámci oblasti. Téměř všechny služby Azure jsou k dispozici buď v zónové konfiguraci, kde je služba delegovaná na konkrétní zónu, nebo v zónově redundantní konfiguraci, kde platforma automaticky zajišťuje, že se služba rozprostírá napříč zónami a dokáže odolat výpadku zóny. Tyto konfigurace poskytují odolnost proti chybám až na úrovni datacentra.

Na co dát pozor při navrhování

  • Regionální a zónové možnosti. Ne všechny služby a možnosti jsou dostupné ve všech oblastech Azure. Tato úvaha může mít vliv na oblasti, které zvolíte. Zóny dostupnosti také nejsou dostupné ve všech oblastech.

  • Regionální páry. Oblasti Azure jsou seskupené do párů oblastí , které se skládají ze dvou oblastí v jedné zeměpisné oblasti. Některé služby Azure používají spárované oblasti k zajištění provozní kontinuity a k zajištění úrovně ochrany před ztrátou dat. Například geograficky redundantní úložiště Azure (GRS) replikuje data do sekundární spárované oblasti automaticky a zajišťuje, aby data byla odolná, pokud primární oblast není obnovitelná. Pokud má výpadek vliv na 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, místní architektury s razítkem a částečně aktivního/aktivního nasazení. Při částečném nasazení jsou některé komponenty aktivní ve všech oblastech, zatímco jiné jsou umístěné centrálně v primární oblasti.

  • Bezpečné nasazení. Architektura SDP (Safe Deployment Practice) Azure zajišťuje, že všechny změny kódu a konfigurace (plánovaná údržba) na platformě Azure budou postupně zavádět. Během vydání se analyzuje stav z důvodu snížení výkonu. Po úspěšném dokončení kanárkové a pilotní fáze se aktualizace platformy serializují napříč regionálními páry, takže v každém páru se v daném okamžiku aktualizuje jenom jedna oblast.

  • Kapacita platformy. Stejně jako každý poskytovatel cloudu má Azure omezené prostředky. Nedostupnost může být důsledkem omezení kapacity v oblastech. Pokud dojde k regionálnímu výpadku, zvýší se poptávka po prostředcích, protože se úloha pokusí obnovit v rámci spárované oblasti. Výpadek může způsobovat problém s kapacitou, kdy nabídka dočasně nesplňuje poptávku.

Doporučení k návrhu

  • Nasaďte řešení alespoň ve dvou oblastech Azure, abyste se mohli chránit před regionálními výpadky. Nasaďte ho v oblastech, které mají funkce a charakteristiky, které úloha vyžaduje. Funkce by měly splňovat cíle výkonu a dostupnosti při současném splnění požadavků na rezidenci a uchovávání dat.

    Například některé požadavky na dodržování předpisů dat můžou omezit počet dostupných oblastí a potenciálně vynutit ohrožení návrhu. V takových případech důrazně doporučujeme, abyste přidali další investice do provozních obálkových balíčků, abyste mohli předpovídat, detekovat a reagovat na selhání. Předpokládejme, že jste omezeni na geografickou oblast se dvěma oblastmi a pouze jedna z těchto oblastí podporuje zóny dostupnosti (model datacentra 3 + 1). Vytvořte model sekundárního nasazení pomocí izolace domény selhání, abyste umožnili nasazení obou oblastí v aktivní konfiguraci a zajistili, že primární oblast obsahuje více razítek nasazení.

    Pokud vhodné oblasti Azure nenabízí všechny funkce, které potřebujete, připravte se na ohrožení konzistence razítek regionálního nasazení, abyste upřednostnili geografickou distribuci a maximalizovali spolehlivost. Pokud je vhodná pouze jedna oblast Azure, nasaďte ve vybrané oblasti několik razítek nasazení (jednotky regionálního škálování), abyste zmírnili určitá rizika, a pomocí zón dostupnosti zajistíte odolnost proti chybám na úrovni datového centra. Takto významný kompromis v geografickém rozdělení však výrazně omezuje dosažitelnou kombinovanou smlouvu SLA a celkovou spolehlivost.

    Důležité

    Pro scénáře, které cílí na SLO, který je větší nebo roven 99,99 %, doporučujeme minimálně tři oblasti nasazení, aby se maximalizovala složená smlouva SLA a celková spolehlivost. Vypočítejte složenou smlouvu SLA pro všechny toky uživatelů. Ujistěte se, že je složená smlouva SLA v souladu s obchodními cíli.

  • V případě rozsáhlých aplikačních scénářů, které mají velké objemy provozu, navrhněte ř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 regionálního nasazení zajistí vyšší složenou smlouvu SLA. Použití globálních prostředků omezuje nárůst složené smlouvy SLA, kterého dosáhnete přidáním dalších oblastí.

  • Definujte a ověřte cíle bodu obnovení (RPO) a cíle doby obnovení (RTO).

  • V rámci jedné zeměpisné oblasti určete prioritu použití párů oblastí, aby bylo možné využívat serializované zavedení SDP pro plánovanou údržbu a stanovení regionálních priorit pro neplánovanou údržbu.

  • Geograficky spolulokujte prostředky Azure s uživateli, abyste minimalizovali latenci sítě a maximalizovali celkový výkon.

  • Pokud zvolíte oblasti nasazení, srovnejte aktuální dostupnost služeb s plány produktů. Některé služby nemusí být okamžitě dostupné ve všech oblastech.

Rozdělení do kontejnerů

Kontejner obsahuje kód aplikace a související konfigurační soubory, knihovny a závislosti, které aplikace potřebuje ke spuštění. Kontejnerizace poskytuje abstraktní vrstvu pro kód aplikace a jeho závislosti a vytváří oddělení od podkladové hostitelské platformy. Jeden softwarový balíček je vysoce přenosný a může běžet konzistentně napříč různými platformami infrastruktury a poskytovateli cloudu. Vývojáři nemusí přepisovat kód a můžou nasazovat aplikace rychleji a spolehlivěji.

Důležité

Doporučujeme používat kontejnery pro klíčové balíčky aplikací. Zlepšují využití infrastruktury, protože ve stejné virtualizované infrastruktuře můžete hostovat více kontejnerů. Vzhledem k tomu, že kontejner obsahuje veškerý software, můžete aplikaci přesunout mezi různými operačními systémy bez ohledu na moduly runtime nebo verze knihovny. Správa je také jednodušší u kontejnerů 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 kontejneru jsou předem sestavené, můžete omezit spouštění pouze během spouštění aplikace, což zajišťuje rychlou škálovatelnost.

Na co dát pozor při navrhování

  • Monitorování. Pro monitorovací služby může být obtížné přistupovat k aplikacím, které jsou v kontejnerech. Ke shromažďování a ukládání indikátorů stavu kontejneru, jako je využití procesoru nebo paměti RAM, obvykle potřebujete software třetích stran.

  • Zabezpečení. Jádro operačního systému hostitelské platformy se sdílí napříč několika kontejnery, což 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 ve spuštěném systému souborů kontejneru, data se při opětovném vytvoření kontejneru nezachovají. Místo toho data zachovají připojením externího úložiště nebo použitím externí databáze.

Doporučení k návrhu

  • Kontejnerizovat všechny komponenty aplikace. Jako primární model pro balíčky nasazení aplikací použijte image kontejneru.

  • Pokud je to možné, upřednostnit moduly runtime kontejnerů založené na Linuxu. Image jsou jednodušší a nové funkce pro linuxové uzly a kontejnery se často vydávají.

  • Nastavte kontejnery jako neměnné a nahraditelné s 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. Shromážděné protokoly a metriky odešlete do sjednocené jímky dat pro další zpracování a analýzu.

  • Ukládání imagí kontejneru v Azure Container Registry. Geografickou replikaci použijte k replikaci imagí kontejnerů napříč všemi oblastmi. Povolte Microsoft Defender pro registry kontejnerů, abyste zajistili kontrolu ohrožení zabezpečení pro image kontejnerů. Ujistěte se, že přístup k registru je spravovaný Microsoft Entra ID.

Hostování a orchestrace kontejnerů

Několik aplikačních platforem Azure může efektivně hostovat kontejnery. S každou z těchto platforem jsou spojené výhody a nevýhody. Porovnejte možnosti v kontextu vašich obchodních požadavků. Vždy ale optimalizujte spolehlivost, škálovatelnost a výkon. Další informace najdete v těchto článcích:

Důležité

Azure Kubernetes Service (AKS) a Azure Container Apps by měly být mezi vašimi prvními volbami pro správu kontejnerů v závislosti na vašich požadavcích. I když Azure App Service není orchestrátor, jako kontejnerová platforma s nízkým třením, je to stále proveditelná 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 Věnovaném rozhraní Azure Well-Architected Framework – AKS.

Důležité

Existují některá základní rozhodnutí o konfiguraci, která nemůžete 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í služby Azure Network Policy, integrace Microsoft Entra a použití spravovaných identit pro AKS místo instančních objektů.

Spolehlivost

AKS spravuje nativní řídicí rovinu Kubernetes. Pokud řídicí rovina není dostupná, dojde u úlohy k výpadku. Využijte funkce spolehlivosti, které nabízí AKS:

  • Nasaďte clustery AKS v různých oblastech 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 distribuujte řídicí rovinu AKS a uzly agenta mezi fyzicky oddělená datacentra. Pokud je ale latence kolokace problémem, můžete nasazení AKS provést v rámci jedné zóny nebo pomocí skupin umístění bezkontaktní komunikace minimalizovat latenci mezi uzly.

  • Pokud chcete maximalizovat záruky dostupnosti koncových bodů rozhraní Kubernetes API, použijte smlouvu SLA OSS pro produkční clustery.

Škálovatelnost

Vezměte v úvahu limity škálování AKS, jako jsou počet uzlů, fondy uzlů na cluster a clustery na předplatné.

Izolace

Udržujte hranice mezi infrastrukturou používanou úlohami a systémovými nástroji. Infrastruktura sdílení může vést k vysokému využití prostředků a hlučným sousedním scénářům.

  • Pro systémové služby a služby úloh používejte 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 GPU s vysokou pamětí. Obecně platí, že pokud chcete snížit zbytečnou režii na správu, vyhněte se nasazování velkého počtu fondů uzlů.

  • Používejte tainty a tolerance k poskytování vyhrazených uzlů a omezení aplikací náročných na prostředky.

  • Vyhodnoťte požadavky na spřažení aplikací a ochranu proti spřažení a nakonfigurujte vhodné umístění kontejnerů na uzlech.

Zabezpečení

Výchozí vanilla Kubernetes vyžaduje významnou konfiguraci, aby byl zajištěn 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, posílené image uzlů a spravované identity.

  • Použijte pokyny ke konfiguraci uvedené ve standardních hodnotách zabezpečení AKS.

  • Pomocí funkcí AKS můžete zpracovávat identity clusteru a správu přístupu, abyste snížili provozní režii a použili konzistentní správu přístupu.

  • Místo instančních objektů použijte spravované identity, abyste se vyhnuli správě a obměně přihlašovacích údajů. Spravované identity můžete přidat na úrovni clusteru. Na úrovni podů můžete používat spravované identity prostřednictvím ID úloh Microsoft Entra.

  • Integrace Microsoft Entra slouží k centralizované správě účtů a hesel, správě přístupu k aplikacím a rozšířené ochraně identit. Pokud chcete získat nejnižší oprávnění, používejte RBAC Kubernetes s ID Microsoft Entra a minimalizujte udělování oprávnění správce, abyste mohli chránit konfiguraci a přístup k tajným klíčů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é můžou kontejnery provádět, poskytněte nejnižší počet oprávnění a vyhněte se použití eskalace oprávnění root.

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é verze AKS Roadmap a poznámky k verzi na GitHubu, abyste zůstali v aktualizovaném stavu o nadcházejících změnách, vylepšeních a hlavně o verzích a vyřazených verzích Kubernetes.

  • 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, které AKS podporuje pro aktualizaci uzlů nebo clusterů. Tyto metody můžou 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 Kubernetes nebo novějších imagí uzlů, pokud jsou dostupné.

Sítě

Vyhodnoťte síťové moduly plug-in, které nejlépe odpovídají vašemu případu použití. Určete, jestli potřebujete podrobnou kontrolu provozu mezi pody. Azure podporuje 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 řídit provoz v rámci clusteru pomocí zásad sítě Azure nebo Calico.

Monitorování

Vaše 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 metrik Kubernetes, abyste mohli monitorovat stav spuštěných prostředků a úloh.

Zásady správného řízení

Pomocí zásad můžete na clustery AKS konzistentním způsobem používat centralizovaná bezpečnostní opatření. Použití přiřazení zásad v rozsahu předplatného nebo vyšším za účelem zajištění konzistence napříč vývojovými týmy.

  • Pomocí Azure Policy můžete určit, které funkce mají být uděleny podům a jestli je spuštění v rozporu se zásadami. Tento přístup se definuje 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 clusterů a podů AKS pomocí Azure Policy.

  • Doplněk Azure Policy pro AKS slouží k řízení funkcí podů, jako jsou oprávnění uživatele root, a k zakázání podů, které nevyhovují zásadám.

Poznámka

Při nasazení do cílové zóny Azure by implementace cílové zóny měla zajistit zásady Azure, které vám pomůžou zajistit konzistentní spolehlivost a zabezpečení.

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 Azure App Service

V případě webových úloh a scénářů úloh založených na rozhraní API může být App Service proveditelnou alternativou k AKS. Poskytuje kontejnerovou platformu s minimálním třením bez složitosti Kubernetes. Kompletní sadu doporučení najdete v tématu Důležité informace o spolehlivosti pro App Service a efektivitě 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ý scénář selhání. Tento problém byste měli zjistit prediktivním testováním zatížení při monitorování portů pomocí Azure Diagnostics. Pokud dojde k chybám SNAT, musíte buď škálovat mezi více nebo většími pracovními procesy, nebo implementovat postupy kódování, které vám pomůžou zachovat a znovu použít porty SNAT. Mezi postupy kódování, které můžete použít, patří sdružování připojení a opožděné načítání prostředků.

Dalším scénářem selhání je vyčerpání portů TCP. 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 od počátku mohli použít příslušná doporučení. Tímto způsobem se můžete vyhnout dluhu za technickou migraci s tím, jak ř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 na App Service.

  • Mějte na paměti, že App Service má výchozí měkký limit instancí na App Service plán.

  • Použití pravidel automatického škálování Plán App Service se škáluje na více instancí, pokud je splněno 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í a snížení kapacity zajistíte, že automatické škálování může provádět akce pro horizontální navýšení i snížení kapacity. Seznamte se s chováním několika 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 App Service, aby se aplikace mohla škálovat nezávisle na plánu App Service, který ji hostuje. Aplikace se přidělují dostupným uzlům v rámci rovnoměrné distribuce. I když rovnoměrná distribuce není zaručena, platforma zajišťuje, že dvě instance stejné aplikace nejsou hostované ve stejné instanci.

Monitorová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í.

  • Pomocí protokolování diagnostiky můžete ingestovat protokoly na úrovni aplikace a platformy do Log Analytics, Azure Storage nebo nástroje třetí strany prostřednictvím 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 schopnost samoopravit, pokud dojde k selhání. Povolte funkci Automatické ho opravovat , aby se automaticky recyklují pracovní procesy, které nejsou v pořádku.

  • K posouzení všech důležitých podřízených závislostí musíte použít odpovídající kontroly stavu, což pomáhá zajistit celkový stav. Důrazně doporučujeme povolit kontrolu stavu , abyste identifikovali pracovníky, kteří nereagují.

Nasazení

Pokud chcete obejít výchozí limit počtu instancí na App Service plán, nasaďte App Service plány ve více jednotkách škálování v jedné oblasti. Nasaďte App Service plány 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 pro obsluhu normálního zatížení ve špičce.

Registr kontejneru

Registry kontejnerů hostují image, které jsou nasazené do prostředí modulu runtime kontejneru, jako je AKS. Registry kontejnerů pro klíčové úlohy musíte pečlivě nakonfigurovat. Výpadek by neměl způsobovat zpoždění při načítání imagí, zejména během operací škálování. Následující aspekty a doporučení se zaměřují na Azure Container Registry a prozkoumávají kompromisy spojené s centralizovanými a federovanými modely nasazení.

Na co dát pozor při navrhování

  • Formát: Zvažte použití registru kontejneru, který spoléhá na formát a standardy poskytované Dockerem pro operace push i pull. 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 ho můžete nasadit jako vyhrazenou komponentu pro konkrétní úlohy aplikace.

  • Veřejné registry. Image kontejnerů se ukládají v Docker Hub nebo jiných veřejných registrech, které existují mimo Azure a v dané virtuální síti. Nemusí to nutně být problém, ale může to vést k různým problémům, které souvisejí s dostupností služby, omezováním a exfiltrací dat. V některých scénářích aplikací je potřeba replikovat veřejné image kontejnerů do privátního registru kontejnerů, abyste omezili výchozí přenos dat, 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. Nevytvářet závislost na centralizované službě, pokud požadavky na dostupnost a spolehlivost organizace nejsou plně v souladu s aplikací.

    V doporučeném vzoru základní architektury jsou registry kontejnerů globální prostředky, které jsou dlouhodobé. 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í. Věnujte zvláštní pozornost omezením omezení pro případy použití, které závisí na Docker Hub.

  • Určete prioritu Azure Container Registry pro hostování imagí kontejnerů.

Aspekty návrhu a doporučení pro Azure Container Registry

Tato nativní služba poskytuje ř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 nakonfigurovaných oblastí a poskytuje odolnost proti oblastním výpadkům. Pokud se oblast stane nedostupnou, ostatní oblasti budou dál obsluhovat žádosti o image. Jakmile je oblast opět online, Container Registry ji 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ón dostupnosti, podporuje úroveň Premium Container Registry zónovou redundanci , která poskytuje 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í.

Hostujte image v blízkosti výpočetních prostředků, které spotřebovávají, ve stejných oblastech Azure.

Uzamykání obrazu

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í. Pokud se dříve nasazená verze image změní, nasazení se stejnou verzí můžou před změnou a po změně poskytovat odlišné 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

Image se značkou Container Registry jsou ve výchozím nastavení měnitelné, což znamená, že stejnou značku je možné 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

Používejte Microsoft Entra integrované ověřování k nabízení a načítání imagí místo toho, abyste se spoléhali na přístupové klíče. Pokud chcete zvýšit zabezpečení, úplně zakažte používání 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řizuje, škáluje a spravuje prostředky potřebné ke spuštění kódu nasazené aplikace. Azure poskytuje několik bezserverových výpočetních platforem:

  • Azure Functions. Když použijete Azure Functions, logika aplikace se implementuje jako jedinečné 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 uspokojily poptávku.

  • Azure Logic Apps. 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 používá Logic Apps pro zpracování řízené událostmi integrované triggery. 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é a smyčky.

  • Azure API Management. Pomocí API Management můžete publikovat, transformovat, udržovat a monitorovat rozhraní API s rozšířeným zabezpečením pomocí úrovně Consumption.

  • Power Apps a Power Automate. Tyto nástroje poskytují prostředí pro vývoj s minimem 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í.

Bezserverové technologie pro klíčové aplikace poskytují zjednodušený vývoj a provoz, což může být užitečné pro jednoduché obchodní případy použití. Tato jednoduchost však přichází za cenu flexibility z hlediska škálovatelnosti, spolehlivosti a výkonu, což není možné pro většinu kritických scénářů aplikací.

Následující části obsahují aspekty návrhu a doporučení pro použití Azure Functions a Logic Apps jako alternativních platforem pro nekritičtější scénáře pracovních postupů.

Aspekty návrhu a doporučení pro Azure Functions

Klíčové úlohy mají kritické a nekrité systémové toky. Azure Functions je realizovatelnou volbou 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 konfigurovat 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ž operace v jiných plánech. K maximalizaci spolehlivosti a výkonu doporučujeme použít plán Premium.

Existují některé aspekty zabezpečení. Pokud k zveřejnění externího koncového bodu používáte 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 se zlými úmysly správců.

Na Azure Functions kódu musíte použít nástroje pro kontrolu kódu a integrovat je s kanály CI/CD.

Aspekty návrhu a doporučení pro Azure Logic Apps

Podobně jako Azure Functions používá Logic Apps pro zpracování řízené událostmi integrované triggery. 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é, smyčky a další konstruktory.

K dispozici je několik režimů nasazení . Pokud chcete zajistit nasazení s jedním tenantem a zmírnit hlučné sousedské scénáře, doporučujeme režim Standard. Tento režim používá kontejnerizovaný modul runtime Logic Apps s jedním tenantem, který je založený na Azure Functions. V tomto režimu může mít aplikace logiky několik stavových a bezstavových pracovních postupů. Měli byste vědět o limitech konfigurace.

Omezené migrace přes IaaS

Mnoho aplikací, které mají stávající místní nasazení, používá virtualizační technologie a redundantní hardware k zajištění klíčové úrovně spolehlivosti. Modernizaci často brání obchodní omezení, která brání úplnému sladění se vzorem architektury nativních cloudových standardních hodnot (North Star), který se doporučuje pro klíčové úlohy. Proto mnoho aplikací používá fázovaný přístup s počátečními cloudovými nasazeními s využitím virtualizace a 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čů 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 konfiguraci sítě a systému.
  • Úloha nepodporuje spouštění v kontejnerech.
  • Pro úlohy třetích stran není k dispozici žádná podpora dodavatele.

Tato část se zaměřuje na nejlepší způsoby použití Azure Virtual Machines 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í pro cloud a IaaS.

Na co dát pozor při navrhování

  • 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 kvůli požadavkům na správu virtuálních počítačů a operačních systémů. Správa virtuálních počítačů vyžaduje časté zavádění softwarových balíčků a aktualizací.

  • Azure poskytuje možnosti pro zvýšení dostupnosti virtuálních počítačů:

    • Skupiny dostupnosti můžou pomoct chránit před selháním sítě, disku a napájení tím, že distribuují virtuální počítače mezi domény selhání a aktualizační domény.
    • Zóny dostupnosti vám můžou pomoct dosáhnout ještě vyšších úrovní spolehlivosti díky distribuci virtuálních počítačů mezi fyzicky oddělená datacentra v rámci oblasti.
    • Virtual Machine Scale Sets poskytovat funkce pro automatické škálování počtu virtuálních počítačů ve skupině. Poskytují také funkce pro monitorování stavu instancí a automatické opravy instancí, které nejsou v pořádku.

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řípadech, kdy je to potřeba.

  • Správné velikosti skladových položek virtuálních počítačů, aby se zajistilo efektivní 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 datového centra.

    • Pokud nasazujete komerční software, obraťte se na dodavatele softwaru a před nasazením softwaru do produkčního prostředí ho odpovídajícím způsobem otestujte.

  • Pro úlohy, které se nedají nasadit napříč zónami dostupnosti, použijte skupiny dostupnosti , které obsahují tři nebo více virtuálních počítačů.

    • Skupiny dostupnosti zvažte jenom v případě, že zóny dostupnosti nevyhovují požadavkům na úlohy, například pro úlohy s nízkou latencí.

  • Určete prioritu použití Virtual Machine Scale Sets pro škálovatelnost a zónovou redundanci. Tento bod je obzvláště důležitý pro úlohy s různou zátěží. Například pokud počet aktivních uživatelů nebo požadavků za sekundu je proměnlivé zatížení.

  • 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 regionálními výpadky, nasaďte virtuální počítače aplikací napříč několika oblastmi Azure.

  • U úloh, které nepodporují aktivní/aktivní nasazení ve více oblastech, zvažte implementaci nasazení aktivního/pasivního nasazení pomocí virtuálních počítačů s aktivním/teplým pohotovostním režimem pro převzetí služeb při selhání v oblasti.

  • Místo vlastních imagí, které je potřeba udržovat, používejte standardní image z Azure Marketplace.

  • Implementujte automatizované procesy pro nasazení a zavádění změn ve virtuálních počítačích, abyste se vyhnuli jakýmkoli ručním zásahům. 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ě.

Datová platforma