Doporučení pro návrh spolehlivé strategie škálování
Platí pro toto doporučení kontrolního seznamu pro spolehlivost architektury 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
| Pojem | 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í:
Statická: Každý večer 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ých pondělí ráno se k systému ERP přihlásí 1000 zaměstnanců ve více oblastech.
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 velkého rozsahu způsobuje špičku v poptávce 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í.
V předchozích příkladech můžou být vaše strategie škálování:
Statická: 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é škálování výpočetních uzlů na normální denní kapacitu před zahájením práce první oblasti.
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é: Pro neplánované špičky provozu jsou definované prahové hodnoty automatického škálování.
Automatizace strategií škálování
Při navrhování automatizace škálování nezapomeňte zohlednit tyto problémy:
Aby všechny komponenty vaší úlohy měly být kandidáty na implementaci škálování. Ve většině případů se globální služby, jako je Microsoft Entra ID , automaticky a transparentně škáluje na 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 na více instancí. 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.
Doba, kterou trvá provedení operace škálování, abyste operaci správně naplánovali, než dojde k dalšímu zatížení vaší infrastruktury. Pokud například škálování komponenty, jako je API Management, trvá 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í 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é můžou být přerušeny operací škálování a všechny spřažení relací (nebo stálost relace), které jsou implementovány. Stickiness může omezit schopnost škálování a zavést jediné body selhání.
Potenciální kritické body. 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. Kritickými body jsou s největší pravděpodobností stavové části systému.
Po vzoru návrhu razítka nasazení vám pomůže celková sprá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. 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 na razítko nasazení použít omezenou sadu definic škálování a podle potřeby ho zrcadlit.
Kompromis: Vertikální navýšení kapacity má vliv na náklady, takže optimalizujte strategii tak, aby se co nejdříve škálovala, abyste udrželi 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ích operací automatického škálování pomocí služby Azure Automation, jako jsou ukázky kódu v automatickém škálování služby 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.
Automatické škálování služby Azure Monitor poskytuje společnou sadu funkcí automatického škálování pro azure Virtual Machine Scale Sets, Aplikace Azure 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 Monitorem.
Kompromisy
Důležité informace o automatickém š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 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. 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 spustit více instancí služby s rostoucí délkou fronty. Model Konkurenční 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í i snížení kapacity. Bez péče by takový úkol mohl zabránit tomu, aby se instance procesu při škálování systému vypínání čistě vypnula. Nebo může dojít ke ztrátě dat, pokud proces vynutil ukončení. 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 toho, 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, ve kterém jsou intervaly v souladu se zpracováním zpráv z front ve službě 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, ve 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í. Jednou z knihoven, 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 omezovat. Další informace najdete v modelu 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é 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ů po usnadnění úloh.
Příklad
Pokyny ke škálování základní architektury AKS najdete v referenčních materiálech k referenční architektuře AKS.
Související odkazy
Kontrolní seznam pro spolehlivost
Projděte si kompletní sadu doporučení.