Doporučení pro návrh spolehlivé strategie škálování
se vztahuje na toto doporučení kontrolního seznamu spolehlivosti v Azure Well-Architected Framework:
| RE:06 | Implementujte včasnou a spolehlivou strategii škálování na úrovni aplikace, dat a infrastruktury. Založte strategii škálování na skutečném nebo předpovídaném způsobu použití a minimalizujte ruční zásah. |
|---|
Související průvodce:dělení dat
Tato příručka popisuje doporučení pro návrh spolehlivé strategie škálování.
Definice
| Termín | Definice |
|---|---|
| Vertikální škálování | Přístup ke škálování, který přidává výpočetní kapacitu ke stávají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 ke škálování, který při splnění sady podmínek automaticky přidá nebo odebere prostředky. |
Poznámka
Operace škálování můžou být statické (pravidelně naplánované denní škálování pro přizpůsobení normálních vzorů zatížení), automatické (automatizovaný proces v reakci na splněné podmínky) nebo ruční (operátor provádí jednorázovou operaci škálování v reakci na neočekávané změně zatížení). Vertikální i horizontální škálování je možné provádět prostřednictvím některé 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
Návrh podle vzorů zatížení
Pokud chcete navrhnout spolehlivou strategii škálování pro vaše úlohy, zaměřte se na identifikaci vzorů zatížení pro uživatele a systémové toky pro každou úlohu, která vede k operaci škálování. Tady jsou příklady různých vzorců zatížení:
Static: Každou noc do 11:00 EST je počet aktivních uživatelů nižší než 100 a využití procesoru pro aplikační servery klesne o 90% napříč všemi uzly.
Dynamické, pravidelné a předvídatelné: Každý pondělí ráno se 1000 zaměstnanců ve více oblastech přihlásí k systému ERP.
Dynamické, nepravidelné a předvídatelné: Uvedení produktu na trh probíhá v prvním dni v měsíci a existují historická data z předchozích startů o tom, jak se provoz v těchto situacích zvyšuje.
Dynamické, nepravidelné a nepředvídatelné: Událost ve velkém měřítku způsobuje špičku poptávky po produktu. Například společnosti, které vyrábí a prodávají dehumidifátory, mohou zaznamenat náhlý nárůst provozu po hurikánu nebo jiné povodňové události, když lidé v postižených oblastech potřebují suché místnosti ve svém domě.
Po identifikaci těchto typů vzorů zatížení můžete:
Určete, jak změna zatížení spojená s každým vzorem ovlivňuje vaši infrastrukturu.
Sestavte automatizaci pro spolehlivé řešení škálování.
U předchozích příkladů by mohly být vaše strategie škálování následující:
statických: Máte naplánované škálování výpočetních uzlů na minimální počet (2) mezi 11:00 a 6:00 EST.
dynamické, pravidelné a předvídatelné: Máte naplánované rozšíření výpočetních uzlů na normální denní kapacitu před tím, než začne pracovat první region.
dynamické, nepravidelné a předvídatelné: Na ráno spuštění produktu definujete jednorázové plánované vertikální navýšení kapacity výpočetních a databázových instancí a po jednom týdnu můžete vertikálně snížit kapacitu.
dynamické, nepravidelné a nepředvídatelné: Máte definované prahové hodnoty automatického škálování, které budou zohledňovat neplánované špičky provozu.
Automatizace strategií škálování
Při navrhování automatizace škálování nezapomeňte zohlednit tyto problémy:
Všechny komponenty vaší pracovní zátěže by měly být kandidáty na implementaci škálování. Ve většině případů se globální služby jako Microsoft Entra ID automaticky a transparentně škálují pro vás a vaše zákazníky. Nezapomeňte pochopit možnosti škálování vašich síťových příchozích a výstupních kontrolerů a řešení vyrovnávání zatížení.
tyto komponenty, které nelze škálovat. Příkladem by byly 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ě je monitorujte. Zahrňte tyto konkrétní prostředky do budoucího plánování migrace na škálovatelné služby.
Dobu potřebnou k provedení operace škálování, abyste správně naplánovali operaci před tím, než dojde k dodatečnému zatížení infrastruktury. Pokud například škálování komponenty, jako je API Management, trvá 45 minut, úprava prahové hodnoty škálování na 65% místo 90% vám může pomoct škálovat dříve a připravit se na očekávané zvýšení zatížení.
Vztah komponent toku v souvislosti s pořadím operací škálování. Zajistěte, abyste neúmyslně nepřetěžovali podřízenou komponentu vertikálním navýšením kapacity nadřazené komponenty.
Všechny stavové prvky aplikace, které mohou být přerušeny operací škálování, a spřažení relace (nebo stálost relace), které byly implementovány. Lepivost může omezit vaši schopnost škálování a zavést jediné místa selhání.
potenciální úzká místa. Horizontální navýšení kapacity neřeší všechny problémy s výkonem. Pokud je například back-endová databáze kritickým bodem, nepomůže přidat další webové servery. Před přidáním dalších instancí nejprve identifikujte a vyřešte kritické body v systému. Nejpravděpodobnější příčinou kritických bodů jsou stavové části systému.
Podle návrhu designu nasazovacího razítka pomáhá při celkové správě vaší infrastruktury. Vytváření návrhu měřítka na razítkech jako jednotky škálování je také přínosné. Pomůže vám to přesně řídit operace škálování napříč několika úlohami a podmnožinami úloh. Namísto správy plánů škálování a prahových hodnot automatického škálování pro mnoho různých prostředků můžete aplikovat omezenou sadu definic škálování na šablonu nasazení a podle potřeby ji dále aplikovat na další šablony.
Výměna: Zvětšení kapacity má nákladové důsledky, proto optimalizujte svou strategii, abyste co nejdříve zmenšili kapacitu a pomohli tak udržet náklady pod kontrolou. Ujistěte se, že automatizace, kterou používáte ke 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 dostupná v mnoha službách Azure. Umožňuje snadno nakonfigurovat podmínky pro 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ího automatického škálování pomocí Azure Automation, jako například ukázky kódu na stránce Autoscale your Azure IoT Hub. Nástroje, jako je KEDA, můžete použít pro automatické škálování řízené událostmi, které je dostupné ve službě Azure Kubernetes Service a azure Container Apps.
Azure Monitor pro automatické škálování poskytuje společnou sadu funkcionality pro škálovací sady virtuálních počítačů Azure, Azure App Service, Azure Spring Apps a další. Škálování je možné provádět podle plánu nebo na základě metrik modulu runtime, jako je využití procesoru nebo paměti. Osvědčené postupy najdete v průvodci azure Monitoru.
Kompromisy
Důležité informace o automatickém škálování
Automatické škálování není okamžité řešení. Pouhé přidání prostředků do systému nebo spuštění více instancí procesu nezaručuje, že se výkon systému zlepší. Při návrhu 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 předpokladům o spřažení instancí. Nenavrhujte řešení, která vyžadují, aby kód vždy běžel v konkrétní instanci procesu. Při horizontálním škálování cloudové služby nebo webu nepředpokládáme, že řada požadavků ze stejného zdroje se vždy směruje do stejné instance. Z stejného důvodu navrhujte služby tak, aby byly bezstavové, aby se zabránilo tomu, že by se řada požadavků z aplikace vždy směrovala do stejné instance služby. Při navrhování služby, která čte zprávy z fronty a zpracovává je, neprovádějte žádné předpoklady o tom, která instance služby zpracovává konkrétní zprávu. Automatické škálování může spustit více instancí služby, jak se zvyšuje délka fronty. Model Konkurující spotřebitelé popisuje, jak tento scénář zpracovat.
Pokud řešení implementuje dlouhotrvající úlohu, navrhněte tuto úlohu tak, aby podporovala horizontální navýšení kapacity i horizontální snížení kapacity. Bez řádné péče by takový úkol mohl zabránit tomu, aby se instance procesu při škálování systému hladce vypnula. Nebo může dojít ke ztrátě dat, pokud je proces násilně ukončen. V ideálním případě refaktorujte dlouhotrvající úlohu a rozdělte zpracování, které provádí, do menších samostatných bloků dat. Vzor kanály a filtry poskytuje příklad, jak tohoto řešení dosáhnout.
Alternativně můžete implementovat mechanismus kontrolního bodu, který zaznamenává informace o stavu úlohy v pravidelných intervalech. Tento stav pak můžete uložit v odolném úložišti, ke kterému má přístup libovolná instance procesu, na kterém je spuštěna úloha. Tímto způsobem, pokud je proces vypnutý, může být práce, kterou prováděla, obnovena z posledního kontrolního bodu jinou instancí. Existují knihovny, které poskytují tuto funkci, jako je NServiceBus a MassTransit. Transparentně uchovávají stav, přičemž intervaly odpovídají zpracování zpráv z front v Azure Service Bus.
Když úlohy na pozadí běží na samostatných výpočetních instancích, například v rolích pracovního procesu aplikace hostované v cloudových službách, budete možná 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í (UI), aniž byste zvýšili počet 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ž u balíčků služeb basic, aby splňovaly smlouvy o úrovni služeb (SLA).
Vezměte v úvahu délku fronty, prostřednictvím které uživatelské rozhraní a výpočetní instance na pozadí komunikují. Použijte ji jako kritérium pro strategii automatického škálování. Tento problém je jedním z možných ukazatelů nevyváženosti nebo rozdílu mezi aktuálním zatížením a kapacitou zpracování úlohy na pozadí. Trochu složitější, ale lepší atribut, na kterém se mají 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á doba. Pokud je tato kritická hodnota času nižší než smysluplná obchodní prahová hodnota, není nutné škálovat, i když je délka fronty dlouhá.
Ve frontě může být například 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í zúčastněné strany by pravděpodobně zvážily, že by to bylo časové období, které by neodůvodňovalo výdaje za škálování navíc.
Na druhé straně může ve frontě existovat 500 zpráv se stejný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žívat kritický čas, je vhodné, aby knihovna automaticky přidala relevantní informace do hlaviček zpráv při jejich odesílání a zpracování. Jedna knihovna, která tuto funkci poskytuje, je NServiceBus.
Pokud strategii automatického škálování založíte na čítačích, které měří obchodní procesy, jako je počet objednávek za hodinu nebo průměrná doba běhu komplexní 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 než jednu komponentu nebo výpočetní jednotku.
Pokud chcete zabránit tomu, aby se systém pokusil vertikálně na více instancí škálovat a vyhnout se nákladům spojeným s provozem mnoha tisíc instancí, zvažte omezení maximálního počtu přidaných instancí. Většina mechanismů automatického škálování umožňuje zadat minimální a maximální počet instancí pravidla. 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 špička poptávky může projít časem, kdy jsou tyto dodatečné prostředky k dispozici. V tomto scénáři může být lepší službu omezit. Další informace najdete ve vzorci omezování .
Pokud naopak potřebujete kapacitu ke 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é použít naplánovanou zásadu, která spustí dostatečný počet instancí tak, aby byly splněny maximální požadavky na zatížení ještě před tím, než toto zatížení nastane.
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 vytvoříte vlastní mechanismus automatického škálování, ujistěte se, že tuto funkci zahrnuje. Analyzujte informace, které vám pomůžou měřit efektivitu strategie automatického škálování, a v případě potřeby je vyladit. Můžete v krátkodobém horizontu optimalizovat, jakmile se vzory použití stanou zřetelnější, a v dlouhodobém horizontu, když se firma rozšiřuje nebo se mění 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ů po usnadnění úloh.
Příklad
Podívejte se na referenční architekturu základních hodnot AKS a pokyny ke škálování.
Související odkazy
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.