Doporučení pro návrh spolehlivé strategie škálování
Platí pro toto doporučení kontrolního seznamu spolehlivosti azure Well-Architected Framework:
| RE:06 | Implementujte včasnou a spolehlivou strategii škálování na úrovni aplikace, dat a infrastruktury. |
|---|
Související průvodce:Dělení dat
Tato příručka popisuje doporučení pro návrh spolehlivé strategie škálování.
Definice
| Období | Definice |
|---|---|
| Vertikální škálování | Přístup škálování, který přidává výpočetní kapacitu k existujícím prostředkům. |
| Horizontální škálování | Přístup škálování, který přidává instance daného typu prostředku. |
| Automatické škálování | Přístup škálování, který automaticky přidá nebo odebere prostředky, když je splněna sada podmínek. |
Poznámka
Operace škálování můžou být statické (pravidelně plánované denní škálování, aby vyhovovalo normálním vzorcům zatížení), automatické (automatizovaný proces v reakci na splnění podmínek) nebo ruční (operátor provádí jednorázovou operaci škálování v reakci na neočekávané změny zatížení). Vertikální i vodorovné škálování je možné provést libovolnou z těchto metod. Automatické vertikální škálování ale vyžaduje další vývoj vlastní automatizace a může způsobit výpadky v závislosti na škálovaných prostředcích.
Klíčové strategie návrhu
Pokud chcete navrhnout spolehlivou strategii škálování pro vaše úlohy, zaměřte se na identifikaci vzorů zatížení pro uživatelské a systémové toky pro každou úlohu, která vede k operaci škálování. Tady jsou příklady různých vzorů zatížení:
Statická: Každou noc do 23:00 EST je počet aktivních uživatelů nižší než 100 a využití procesoru pro aplikační servery klesne na všech uzlech o 90 %.
Dynamické, pravidelné a předvídatelné: Každé pondělí ráno se k systému ERP přihlásí 1000 zaměstnanců z více oblastí.
Dynamické, nepravidelné a předvídatelné: Uvedení produktu na trh probíhá první den v měsíci a k dispozici jsou historická data z předchozích uvedení na trh o tom, jak se v těchto situacích zvýší provoz.
Dynamická, nepravidelná a nepředvídatelná: Událost velkého rozsahu způsobuje prudké zvýšení poptávky po produktu. Například společnosti, které vyrábějí a prodávají odvlhčovače, mohou zaznamenat náhlé nárůsty provozu po hurikánu nebo jiné povodni, když lidé v postižených oblastech potřebují vyschnout místnosti ve svém domě.
Po identifikaci těchto typů vzorů zatížení můžete:
Zjistěte, jak změna zatížení spojená s jednotlivými vzory ovlivní vaši infrastrukturu.
Sestavte automatizaci pro spolehlivé řešení škálování.
V předchozích příkladech by vaše strategie škálování mohly být:
Statické: Máte naplánované škálování výpočetních uzlů na minimální počet (2) mezi 23:00 a 6:00 EST.
Dynamické, pravidelné a předvídatelné: Před zahájením práce v první oblasti máte naplánované škálování výpočetních uzlů na normální denní kapacitu.
Dynamické, nepravidelné a předvídatelné: Definujete jednorázové naplánované vertikální navýšení kapacity výpočetních a databázových instancí ráno po uvedení produktu na trh a po jednom týdnu zase vertikálně snížit kapacitu.
Dynamické, nepravidelné a nepředvídatelné: Máte definované prahové hodnoty automatického škálování, které zohledňují neplánované špičky provozu.
Při návrhu automatizace škálování nezapomeňte zohlednit tyto problémy:
Všechny komponenty úloh by měly být kandidáty pro implementaci škálování. Ve většině případů se globální služby, jako je Microsoft Entra ID, škáluje automaticky a transparentně podle vás a vašich zákazníků. Nezapomeňte porozumět možnostem škálování kontrolerů příchozího a výchozího přenosu dat sítě a řešení vyrovnávání zatížení.
Komponenty, u kterých nejde škálovat na více instancí. Příkladem mohou být velké relační databáze, které nemají povolené horizontální dělení a nelze je refaktorovat bez významného dopadu. Zdokumentujte limity prostředků publikované vaším poskytovatelem cloudu a pečlivě tyto prostředky monitorujte. Tyto konkrétní prostředky zahrňte do budoucího plánování migrace na škálovatelné služby.
Doba potřebná k provedení operace škálování, abyste operaci správně naplánovali, než dodatečné zatížení narazí na vaši infrastrukturu. Pokud například komponentě, jako je API Management, trvá škálování 45 minut, může vám přizpůsobení prahové hodnoty škálování na 65 % místo 90 % pomoct škálovat dříve a připravit se na očekávané zvýšení zatížení.
Vztah komponent toku z hlediska pořadí operací škálování. Ujistěte se, že nechtěně nepřetěžujete podřízenou komponentu tím, že nejprve škálujete nadřazenou komponentu.
Všechny stavové prvky aplikace, které mohou být přerušeny operací škálování, a jakékoli spřažení relací (nebo stálost relace), které jsou implementovány. Stálost může omezit vaše možnosti škálování a přináší jednotlivé body selhání.
Potenciální kritické body. Horizontální navýšení kapacity nevyřeší všechny problémy s výkonem. Pokud je například vaše back-endová databáze kritickým bodem, nepomůže přidat další webové servery. Nejprve identifikujte a vyřešte kritické body v systému před přidáním dalších instancí. Kritickými body jsou s největší pravděpodobností stavové části systému.
Postup návrhu razítka nasazení vám pomůže s celkovou správou infrastruktury. Přínosné je také založení návrhu škálování na razítek jako jednotek měřítka. Pomůže vám to pevně řídit operace škálování napříč několika úlohami a podmnožinami úloh. Místo správy plánů škálování a prahových hodnot automatického škálování mnoha různých prostředků můžete použít omezenou sadu definic škálování na razítko nasazení a pak je podle potřeby zrcadlit napříč razítky.
Kompromis: Vertikální navýšení kapacity má vliv na náklady, takže optimalizujte strategii pro co nejrychlejší vertikální snížení kapacity, abyste měli náklady pod kontrolou. Ujistěte se, že automatizace, kterou používáte k vertikálnímu navýšení kapacity, má také triggery pro vertikální snížení kapacity.
Usnadnění Azure
Funkce automatického škálování je k dispozici v mnoha službách Azure. Umožňuje snadno nakonfigurovat podmínky pro automatické horizontální škálování instancí. Některé služby mají omezené nebo žádné integrované funkce pro automatické škálování, proto nezapomeňte tyto případy zdokumentovat a definovat procesy pro řešení škálování.
Mnoho služeb Azure nabízí rozhraní API, která můžete použít k návrhu vlastních automatických operací škálování pomocí Azure Automation, jako jsou ukázky kódu v části Automatické škálování Azure IoT Hub. Nástroje, jako je KEDA, můžete použít pro automatické škálování řízené událostmi, které je k dispozici v Azure Kubernetes Service a Azure Container Apps.
Automatické škálování služby Azure Monitor poskytuje společnou sadu funkcí automatického škálování pro Azure Virtual Machine Scale Sets, Azure App Service, Azure Spring Apps a další. Škálování je možné provádět podle plánu nebo na základě metriky za běhu, jako je využití procesoru nebo paměti. Osvědčené postupy najdete v příručce ke službě Azure Monitor .
Kompromisy
Aspekty automatického škálování
Automatické škálování není okamžitým řešením. Prosté přidání prostředků do systému nebo spuštění dalších instancí procesu nezaručí zlepšení výkonu systému. Při navrhování strategie automatického škálování zvažte následující body:
Systém musí být navržený tak, aby byl horizontálně škálovatelný. Vyhněte se vytváření předpokladů o spřažení instancí. Nenavrhujte řešení, která vyžadují, aby byl kód vždy spuštěný v konkrétní instanci procesu. Při horizontálním škálování cloudové služby nebo webu nepředpokládejte, že řada požadavků ze stejného zdroje se vždy směruje do stejné instance. Ze stejného důvodu navrhujte služby jako bezstavové, abyste se vyhnuli potřebě vždy směrovat sérii požadavků z aplikace do stejné instance služby. Při návrhu služby, která čte a zpracovává zprávy z fronty, nevyvozujte předpoklady o tom, jaká instance služby zpracovává konkrétní zprávu. Automatické škálování může s rostoucí délkou fronty spustit více instancí služby. Model Konkurenční příjemci popisuje, jak tento scénář zpracovat.
Pokud řešení implementuje dlouhotrvající úlohu, navrhněte tuto úlohu tak, aby podporovala horizontální navýšení i snížení kapacity. Bez náležité péče by taková úloha mohla zabránit čistému vypnutí instance procesu, když se systém škáluje. Nebo může ztratit data, pokud se proces vynutil ukončením. Dlouhotrvající úlohu ideálně refaktorujte a rozdělte zpracování, které provádí, do menších a diskrétních bloků. Model Kanály a filtry poskytuje příklad, jak tohoto řešení dosáhnout.
Případně můžete implementovat mechanismus kontrolních bodů, který zaznamenává informace o stavu úkolu v pravidelných intervalech. Tento stav pak můžete uložit do odolného úložiště, ke kterému může přistupovat libovolná instance procesu, který úlohu spouští. Tímto způsobem, pokud je proces vypnutý, může být práce, kterou prováděl, obnovena od posledního kontrolního bodu jinou instancí. Existují knihovny, které tuto funkci poskytují, například NServiceBus a MassTransit. Transparentně uchovávají stav, kdy intervaly odpovídají zpracování zpráv z front v Azure Service Bus.
Pokud úlohy na pozadí běží na samostatných výpočetních instancích, například v rolích pracovních procesů aplikace hostované v cloudových službách, možná budete muset škálovat různé části aplikace pomocí různých zásad škálování. Můžete například potřebovat nasadit další výpočetní instance uživatelského rozhraní bez zvýšení počtu výpočetních instancí na pozadí nebo naopak. Pokud nabízíte různé úrovně služeb, jako jsou balíčky služeb Basic a Premium, možná budete muset škálovat výpočetní prostředky pro balíčky služeb Premium agresivněji než balíčky služeb Basic, aby splňovaly smlouvy o úrovni služeb (SLA).
Zvažte délku fronty, přes kterou uživatelské rozhraní a výpočetní instance na pozadí komunikují. Použijte ho jako kritérium pro vaši strategii automatického škálování. Tento problém je jedním z možných ukazatelů nerovnováhy nebo rozdílu mezi aktuálním zatížením a kapacitou zpracování úlohy na pozadí. Trochu složitějším, ale lepším atributem, na kterém je možné založit rozhodnutí o škálování, je použít čas mezi odesláním zprávy a dokončením jejího zpracování. Tento interval se označuje jako kritický čas. Pokud je tato hodnota kritického času nižší než smysluplná obchodní prahová hodnota, není nutné škálovat, i když je fronta dlouhá.
Například ve frontě může být 50 000 zpráv. Ale kritická doba nejstarší zprávy je 500 ms a koncový bod se zabývá integrací s webovou službou třetí strany pro odesílání e-mailů. Obchodní účastníci by to pravděpodobně považovali za časové období, které by neodůvodňovalo utrácet další peníze za škálování.
Na druhou stranu může být ve frontě 500 zpráv se stejným kritickým časem 500 ms, ale koncový bod je součástí kritické cesty v některé online hře v reálném čase, kde obchodní účastníci definovali dobu odezvy 100 ms nebo méně. V takovém případě by horizontální navýšení kapacity dávalo smysl.
Pokud chcete při rozhodování o automatickém škálování použít kritický čas, je užitečné, aby knihovna při odesílání a zpracování zpráv automaticky přidávala relevantní informace do hlaviček zpráv. Jednou z knihoven, která tuto funkci poskytuje, je NServiceBus.
Pokud svou strategii automatického škálování založíte na čítačích, které měří obchodní procesy, jako je počet zadaných objednávek za hodinu nebo průměrná doba běhu složité transakce, ujistěte se, že plně rozumíte vztahu mezi výsledky z těchto typů čítačů a skutečnými požadavky na výpočetní kapacitu. V reakci na změny čítačů obchodních procesů může být nutné škálovat více komponent nebo výpočetních jednotek.
Pokud chcete zabránit tomu, aby se systém nepokoušal o nadměrné škálování na více instancí a abyste se vyhnuli nákladům spojeným s provozem mnoha tisíc instancí, zvažte omezení maximálního počtu automaticky přidaných instancí. Většina mechanismů automatického škálování umožňuje zadat minimální a maximální počet instancí pro pravidlo. Kromě toho zvažte řádné snížení funkčnosti, které systém poskytuje, pokud byl nasazen maximální počet instancí a systém je stále přetížen.
Mějte na paměti, že automatické škálování nemusí být nejvhodnějším mechanismem pro zvládnutí náhlého nárůstu zatížení. Zřízení a spuštění nových instancí služby nebo přidání prostředků do systému nějakou dobu trvá a poptávka ve špičce může pominout, než budou tyto dodatečné prostředky k dispozici. V tomto scénáři může být lepší službu omezovat. Další informace najdete v tématu Model omezování.
Pokud naopak potřebujete kapacitu pro zpracování všech požadavků, když objem rychle kolísá a náklady nejsou hlavním faktorem, zvažte použití agresivní strategie automatického škálování, která spouští více instancí rychleji. Můžete také využít naplánovanou zásadu, která spustí dostatečný počet instancí pro zvládnutí maximálního zatížení před tím, než se toto zatížení očekává.
Mechanismus automatického škálování by měl monitorovat proces automatického škálování a protokolovat podrobnosti o každé události automatického škálování (co ho aktivovalo, jaké prostředky byly přidány nebo odebrány a kdy). Pokud vytváříte vlastní mechanismus automatického škálování, ujistěte se, že tuto funkci zahrnuje. Analýza těchto informací vám pomůže měřit efektivitu strategie automatického škálování a v případě potřeby ji ladit. Ladit můžete jak z krátkodobého hlediska, kdy jsou zřetelnější vzorce využití, tak z dlouhodobého hlediska, kdy se rozvíjí obchod nebo vyvíjí požadavky aplikace. Pokud aplikace dosáhne horního limitu definovaného pro automatické škálování, může mechanismus také upozornit operátora, který může v případě potřeby ručně spustit více prostředků. Za těchto okolností může být operátor také zodpovědný za ruční odebrání těchto prostředků, jakmile se zatížení zjednoduší.
Příklad
Projděte si doprovodné materiály ke škálování základní architektury AKS.
Související odkazy
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro