Sdílet prostřednictvím

Automatické škálování

  • Článek

Automatické škálování je proces dynamického přidělování prostředků tak, aby odpovídaly požadavkům na výkon. S tím, jak roste objem práce, může aplikace potřebovat k udržení požadovaných úrovní výkonu a plnění smluv o úrovni služeb (SLA) další prostředky. S klesajícími požadavky, když už další prostředky nejsou potřeba, je možné zrušit jejich přidělení a minimalizovat tak náklady.

Automatické škálování využívá výhody elasticity prostředí hostovaných v cloudu, přičemž snižuje režii na správu. Operátor díky tomu už nemusí soustavně monitorovat výkon systému a rozhodovat se, jestli je potřeba přidat nebo odebrat prostředky.

Aplikaci je možné škálovat dvěma hlavními způsoby:

  • Vertikální škálování, označované také jako vertikální navyšování a snižování kapacity, znamená změnu kapacity prostředku. Například můžete přesunout aplikaci na větší virtuální počítač. Vertikální škálování často vyžaduje, aby byl systém během opětovného nasazování dočasně nedostupný. Proto je automatizace vertikálního škálování méně běžná.

  • Horizontální škálování, označované také jako horizontální navyšování a snižování kapacity, znamená přidávání nebo odebírání instancí prostředku. Během zřizování nových prostředků zůstává aplikace spuštěná bez přerušení. Po dokončení procesu zřizování se řešení nasadí na tyto další prostředky. Pokud se požadavky sníží, tyto další prostředky je možné řádně vypnout a uvolnit.

Řada cloudových systémů, včetně Microsoft Azure, podporuje automatické horizontální škálování. Zbývající část tohoto článku se zaměřuje na horizontální škálování.

Poznámka:

Automatické škálování se většinou týká výpočetních prostředků. Přestože je možné horizontálně škálovat i databázi nebo frontu zpráv, obvykle to zahrnuje dělení dat, což obecně není automatizované.

Automatické škálování komponent

Strategie automatického škálování obvykle zahrnuje následující části:

  • Systémy instrumentace a monitorování na úrovni aplikace, služby a infrastruktury. Tyto systémy zachycují klíčové metriky, jako jsou doba odezvy, délky front, využití procesoru a využití paměti.
  • Rozhodovací logika, která tyto metriky vyhodnocuje proti předdefinovaným prahovým hodnotám nebo plánům a rozhoduje, kdy provést škálování.
  • Komponenty, které škálují systém.
  • Testování, monitorování a ladění strategie automatického škálování pro zajištění, že funguje podle očekávání.

Azure poskytuje integrované mechanismy automatického škálování, které řeší běžné scénáře. Pokud nějaká konkrétní služba nebo technologie nezahrnuje integrované funkce automatického škálování nebo pokud máte na automatické škálování specifické požadavky nad rámec jeho možností, můžete zvážit vlastní implementaci. Vlastní implementace může shromažďovat provozní a systémové metriky, analyzovat je a následně odpovídajícím způsobem škálovat prostředky.

Konfigurace automatického škálování pro řešení Azure

Azure poskytuje integrované automatické škálování pro většinu možností výpočetního prostředí.

Všechny tyto možnosti výpočetního prostředí využívají společnou sadu funkcí automatického škálování, kterou poskytuje automatické škálování služby Azure Monitor.

  • Azure Functions se od předchozích možností výpočetního prostředí liší, protože nevyžaduje konfiguraci žádných pravidel automatického škálování. Místo toho Azure Functions automaticky přiděluje výpočetní výkon za běhu kódu a podle potřeby horizontálně navyšuje kapacitu s ohledem na zatížení. Další informace najdete v tématu Výběr správného plánu hostování pro Azure Functions.

A konečně, někdy může být užitečné vlastní řešení automatického škálování. Můžete například použít diagnostiku Azure a metriky založené na aplikacích spolu s vlastním kódem k monitorování a exportu metrik aplikace. Následně můžete definovat vlastní pravidla založená na těchto metrikách a pomocí rozhraní REST API Resource Manageru aktivovat automatické škálování. Implementace vlastního řešení však není jednoduchá a měli byste ji zvážit pouze v případě, že vaše požadavky nesplňuje žádný z předchozích přístupů.

Pokud splňují vaše požadavky, využijte integrované funkce automatického škálování platformy. Pokud ne, pečlivě zvažte, jestli skutečně potřebujete složitější funkce škálování. Mezi příklady dalších požadavků může patřit větší členitost řízení, různé způsoby detekce aktivačních událostí pro škálování, škálování napříč předplatnými a škálování dalších typů prostředků.

Použití automatického škálování služby Azure Monitor

Automatické škálování služby Azure Monitor poskytuje společnou sadu funkcí automatického škálování pro škálovací sady virtuálních počítačů, službu Aplikace Azure a cloudovou službu Azure. Š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.

Příklady:

  • Škálování na více instancí na 10 instancí ve všední dny a škálování na méně instancí na 4 instance v sobotu a neděli.
  • Škálování na více instancí o jednu instanci v případě, že průměrné využití procesoru přesáhne 70 %, a škálování na méně instancí o jednu instanci, pokud využití procesoru klesne pod 50 %.
  • Škálování na více instancí o jednu instanci v případě, že počet zpráv ve frontě překročí určitou prahovou hodnotu.

Vertikálně navyšte kapacitu prostředku, když se zvýší zatížení, aby se zajistila dostupnost. Podobně můžete v době nízkého využití vertikálně snížit kapacitu, abyste mohli optimalizovat náklady. Vždy používejte kombinaci pravidel horizontálního navýšení kapacity a horizontálního navýšení kapacity. V opačném případě se automatické škálování provádí pouze v jednom směru, dokud nedosáhne prahové hodnoty (maximálního nebo minimálního počtu instancí) nastaveného v profilu.

Vyberte výchozí počet instancí, který je pro vaši úlohu bezpečný. Škáluje se na základě této hodnoty, pokud není nastaven maximální nebo minimální počet instancí.

Seznam předdefinovaných metrik najdete v tématu Běžné metriky automatického škálování služby Azure Monitor. Vlastní metriky můžete implementovat také pomocí Application Insights.

Automatické škálování můžete konfigurovat pomocí PowerShellu, Azure CLI, šablony Azure Resource Manageru nebo webu Azure Portal. Pokud potřebujete podrobnější řízení, použijte rozhraní REST API Azure Resource Manageru. Knihovna pro správu služeb monitorování Azure a Knihovna Microsoft Insights (ve verzi Preview) jsou sady SDK, které umožňují shromažďovat metriky z různých prostředků a provádět automatické škálování s využitím rozhraní REST API. V případě prostředků bez podpory Azure Resource Manageru nebo pokud používáte službu Azure Cloud Services, můžete k automatickému škálování použít rozhraní REST API pro správu služeb. Ve všech ostatních případech použijte Azure Resource Managera.

Při použití automatického škálování Azure zvažte následující body:

  • Zvažte, jestli můžete predikovat zatížení aplikace dostatečně přesně, abyste mohli použít plánované automatické škálování a přidávat a odebírat instance tak, aby splňovaly očekávané špičky v poptávce. Pokud to není možné, využijte ke zvládnutí nepředvídatelných změn v poptávce reaktivní automatické škálování na základě metrik modulu runtime. Tyto přístupy obvykle můžete kombinovat. Můžete například vytvořit strategii, která přidává prostředky podle plánu časů, kdy víte, že je aplikace nejsložitější. Taková strategie pomůže zajistit dostupnost kapacity v případě potřeby bez jakéhokoli zpoždění souvisejícího se spouštěním nových instancí. Pro každé naplánované pravidlo definujte metriky, které v daném období umožní reaktivní automatické škálování a tím zajistí, že aplikace zvládne stabilní, ale nepředvídatelné špičky v poptávce.

  • Často je obtížné porozumět vztahu mezi metrikami a požadavky na kapacitu, a to zejména při prvotním nasazení aplikace. Zpočátku zřiďte o trochu větší kapacitu a následně monitorujte a laďte pravidla automatického škálování tak, aby se kapacita přiblížila skutečnému zatížení.

  • Nakonfigurujte pravidla automatického škálování a pak monitorujte výkon aplikace v průběhu času. Výsledky tohoto monitorování využijte k úpravě způsobu škálování systému v případě potřeby. Mějte však na paměti, že automatické škálování není okamžitý proces. Reakce na metriky, například když průměrné využití procesoru přesáhne (nebo klesne pod) zadanou prahovou hodnotu, nějakou dobu trvá.

  • Pravidla automatického škálování využívající mechanismus detekce založený na naměřeném atributu triggeru (například využití procesoru nebo délka fronty), používají k aktivaci akce automatického škálování místo aktuálních hodnot agregovanou hodnotu v průběhu času. Ve výchozím nastavení je agregovaná hodnota průměrem těchto hodnot. Tím se brání příliš rychlé reakci systému nebo rychlému kolísání. Umožňuje také čas pro nové instance, které se automaticky začnou usadit do spuštěného režimu, což brání dalším akcím automatického škálování v době, kdy se nové instance spouští. U služeb Azure Cloud Services a Azure Virtual Machines je výchozí období agregace 45 minut, takže aktivace automatického škálování metrikou v reakci na špíčky v poptávce může trvat až tuto dobu. Agregační období můžete změnit pomocí sady SDK, ale období kratší než 25 minut můžou způsobit nepředvídatelné výsledky. U služby Web Apps je průměrované období mnohem kratší, což umožňuje zpřístupnění nových instancí přibližně do pěti minut od změny průměrné míry triggeru.

  • Vyhněte se prolnutí , kdy se akce horizontálního snížení kapacity a horizontálního navýšení kapacity neustále vrací zpět a zpět. Předpokládejme, že existují dvě instance a horní limit je 80 % procesoru, dolní limit je 60 %. Když je zatížení 85 %, přidá se další instance. Po nějaké době se zatížení sníží na 60 %. Před horizontálním navýšením kapacity služba automatického škálování vypočítá rozdělení celkového zatížení (ze tří instancí), když se instance odebere, a přebere ji na 90 %. To znamená, že by se muselo okamžitě škálovat na více instancí. Takže horizontální navýšení kapacity přeskočí a nemusí se zobrazovat očekávané výsledky škálování.

    Situaci flappingu je možné řídit výběrem přiměřeného okraje mezi prahovými hodnotami horizontálního navýšení kapacity a horizontálním snížením kapacity.

  • Ruční škálování se resetuje maximálním a minimálním počtem instancí používaných pro automatické škálování. Pokud ručně aktualizujete počet instancí na vyšší nebo nižší hodnotu, než je maximální hodnota, modul automatického škálování se automaticky škáluje zpět na minimum (pokud je nižší) nebo maximum (pokud je vyšší). Například nastavíte rozsah mezi 3 a 6. Pokud máte jednu spuštěnou instanci, modul automatického škálování se při příštím spuštění škáluje na tři instance. Podobně platí, že pokud škálovací kapacitu nastavíte ručně na osm instancí, při příštím spuštění automatického škálování se škáluje zpět na šest instancí při dalším spuštění. Ruční škálování je dočasné, pokud také resetujete pravidla automatického škálování.

  • Modul automatického škálování zpracovává současně pouze jeden profil. Pokud podmínka není splněná, zkontroluje další profil. Udržujte klíčové metriky mimo výchozí profil, protože tento profil je zaškrtnutý jako poslední. V rámci profilu můžete mít více pravidel. Při horizontálním navýšení kapacity se automatické škálování spustí, pokud je splněné nějaké pravidlo. Při horizontálním snížení kapacity automatické škálování vyžaduje splnění všech pravidel.

Podrobnosti o tom, jak azure Monitor škáluje, najdete v tématu Osvědčené postupy pro automatické škálování.

  • Pokud konfigurujete automatické škálování pomocí sady SDK, a ne pomocí portálu, můžete určit podrobnější plán, během kterého jsou pravidla aktivní. Můžete také vytvořit vlastní metriky a společně s existujícími metrikami nebo bez nich je použít ve svých pravidlech automatického škálování. Můžete například chtít použít alternativní čítače, například počet požadavků za sekundu nebo průměrnou dostupnost paměti, nebo použít vlastní čítače k měření konkrétních obchodních procesů.

  • Při automatickém škálování Service Fabric se typy uzlů v clusteru skládají ze škálovacích sad virtuálních počítačů na back-endu, takže je potřeba nastavit pravidla automatického škálování pro každý typ uzlu. Před nastavením automatického škálování vezměte v úvahu počet uzlů, které musíte mít. Minimální počet uzlů, který je potřeba pro primární typ uzlu, vychází ze zvolené úrovně spolehlivosti. Další informace najdete v tématu Škálování nebo snížení kapacity clusteru Service Fabric pomocí pravidel automatického škálování.

  • Pomocí portálu můžete propojit prostředky, jako jsou dotazy a instance služby SQL Database, s instancí cloudové služby. To vám umožní snadněji přistupovat k jednotlivým možnostem konfigurace ručního a automatického škálování pro každý z propojených prostředků. Další informace najdete v tématu Postup: Propojení prostředku s cloudovou službou.

  • Pokud nakonfigurujete více zásad a pravidel, může mezi nimi docházet ke vzájemným konfliktům. Pro zajištění, aby vždy byl spuštěný dostatečný počet instancí, využívá automatické škálování následující pravidla řešení konfliktů:

    • Operace horizontálního navýšení kapacity mají vždy přednost před operacemi horizontálního navýšení kapacity.
    • Při konfliktu operací horizontálního navýšení kapacity má přednost pravidlo, které iniciuje největší nárůst počtu instancí.
    • V případě konfliktu operací horizontálního snížení kapacity má přednost pravidlo, které vyvolává nejmenší snížení počtu instancí.

  • Ve službě App Service Environment lze k definování pravidel automatického škálování použít jakýkoli fond pracovních procesů nebo front-endové metriky. Další informace najdete v tématu Automatické škálování a App Service Environment.

Aspekty návrhu aplikace

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 vyvozování předpokladů o afinitě instance – nenavrhujte řešení, která vyžadují, aby byl kód vždy spuštěný na konkrétní instanci procesu. Při horizontálním škálování cloudové služby nebo webu nepředpokládejte, že se série požadavků ze stejného zdroje bude vždy směrovat 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 ohledem na rostoucí délku fronty spouštět další instance služby. 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 náležité péče může taková úloha bránit řádnému vypnutí instance procesu při horizontálním snižování kapacity nebo může způsobit ztrátu dat, pokud dojde k vynucenému ukončení procesu. Dlouhotrvající úlohu ideálně refaktorujte a rozdělte zpracování, které provádí, do menších a diskrétních bloků. Vzor Kanály a filtry poskytuje příklad toho, jak toho dosáhnout.

  • Alternativně můžete implementovat mechanismus kontrolních bodů, který v pravidelných intervalech zaznamenává informace o stavu úlohy a ukládá je do odolného úložiště, ke kterému mají přístup všechny instance procesu, který úlohu spouští. Tímto způsobem, pokud je proces vypnutý, lze práci, kterou prováděl, pokračovat z posledního kontrolního bodu pomocí jiné instance. 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í. Například můžete potřebovat nasadit další výpočetní instance s uživatelským rozhraním, aniž byste zvýšili počet výpočetních instancí na pozadí, nebo naopak. Pokud nabízíte různé úrovně služby (například balíčky služby úrovně Basic a Premium), možná budete s ohledem na plnění smluv SLA potřebovat škálovat výpočetní prostředky na více instancí u balíčků služby úrovně Premium agresivněji než u balíčků služby úrovně Basic.

  • 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í. Toto je jeden z možných ukazatelů nevyváženosti nebo rozdílu mezi aktuálním zatížením a kapacitou zpracování úlohy na pozadí. Existuje o něco složitější, ale lepší atribut pro základní rozhodnutí o škálování. Použijte čas mezi odesláním zprávy a dokončením jejího zpracování, který 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ý čas nejstarší zprávy je 500 ms a tento koncový bod se zabývá integrací s webovou službou třetí strany pro odesílání e-mailů. Je pravděpodobné, že obchodní zúčastněné strany by zvážily, že by to bylo časové období, které by neodůvodňovalo výdaje navíc za škálování.
    • Na druhou stranu může ve frontě existovat 500 zpráv se stejným časem 500 ms kritickým časem, ale koncový bod je součástí kritické cesty v některé online hře v reálném čase, kde obchodní účastníci definovali 100 ms nebo kratší dobu odezvy. V takovém případě by horizontální navýšení kapacity dávalo smysl.
    • Aby bylo možné využít kritický čas při rozhodování o automatickém škálování, je užitečné mít knihovnu automaticky přidávat relevantní informace do hlaviček zpráv, zatímco se odesílají a zpracovávají. Jednou z takových knihoven, která tuto funkci poskytuje, je NServiceBus.

  • Pokud svou strategii automatického škálování zakládáte na čítačích měřících obchodní procesy, jako je počet zadaných objednávek za hodinu nebo průměrná doba zpracování složité transakce, ujistěte se, že plně chápete vztah 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 potřeba škálovat více než jednu komponentu nebo výpočetní jednotku.

  • Abyste zabránili nadměrným pokusům systému o škálování na více instancí a abyste se vyhnuli nákladům souvisejícím se spouštěním mnoha tisíc instancí, zvažte omezení maximálního počtu instancí, které je možné automaticky přidat. Většina mechanismů automatického škálování umožňuje určit pro pravidlo minimální a maximální počet instancí. Kromě toho zvažte snížení úrovně funkcí poskytovaných systémem bez výpadku v případě, že 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 zpracování náhlého nárůstu úloh. 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 dříve, než tyto nové prostředky budou k dispozici. V tomto scénáři může být vhodnější službu omezit. Další informace najdete v modelu omezování.

  • Pokud naopak potřebujete kapacitu ke zpracování všech požadavků v případě rychlého kolísání jejich objemu a náklady nejsou významným faktorem, zvažte použití agresivní strategie automatického škálování, při které se další instance spouští 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 ji aktivovalo, jaké prostředky se přidaly nebo odebraly 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 omezení definovaného pro automatické škálování, mechanismus může také upozornit operátora, který v případě potřeby může ručně spustit další prostředky. Mějte na paměti, že za těchto okolností může být operátor zodpovědný také za ruční odebrání těchto prostředků po usnadnění úloh.

Při implementaci automatického škálování můžou být pro váš scénář relevantní také následující vzory a pokyny:

  • Model omezení využití sítě. Tento model popisuje, jak může aplikace i nadále fungovat a splňovat smlouvy SLA v případě, že zvýšení poptávky představuje extrémní zatížení prostředků. Kombinací omezování a automatického škálování je možné zabránit přetížení systému, zatímco se horizontálně navyšuje jeho kapacita.

  • Model konkurenčních spotřebitelů: Tento model popisuje, jak implementovat fond instancí služby, který dokáže zpracovávat zprávy z jakékoli instance aplikace. Pomocí automatického škálování je možné spouštět a zastavovat instance služby s ohledem na předpokládané zatížení. Díky tomuto přístupu může systém zpracovávat více zpráv souběžně, což umožňuje optimalizovat propustnost, zlepšit škálovatelnost a dostupnost a vyrovnávat zatížení.

  • Monitorování a diagnostika. Instrumentace a telemetrie jsou důležité pro shromažďování informací, které můžou podpořit proces automatického škálování.