Sdílet prostřednictvím

Automatické škálování

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 rostoucím objemem práce může aplikace potřebovat více prostředků, aby zachovala požadované úrovně výkonu a splňovala cíle na úrovni služeb (SLA). Vzhledem k tomu, že poptávka se zvolní a další prostředky už nejsou potřeba, je možné je zrušit, aby se minimalizovaly 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í navýšení a snížení kapacity, znamená změnu kapacity prostředku. Aplikaci můžete například přesunout do větší velikosti virtuálního počítače. Vertikální škálování často vyžaduje, aby byl systém při opětovném nasazení dočasně nedostupný. Proto je méně běžné automatizovat vertikální škálování.

  • Horizontální škálování, označované také jako škálování přidáním a škálování odebráním, znamená přidání nebo odebrá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 poptávka klesne, dají se nadbytečné prostředky úhledně vypnout a uvolnit.

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

Poznámka:

Automatické škálování se většinou vztahuje na výpočetní prostředky. I když je možné horizontálně škálovat databázi nebo frontu zpráv, tento proces obvykle zahrnuje dělení dat, což obvykle není automatizované.

Automatické škálování komponent

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

  • Instrumentace a monitorování systémů na úrovni aplikací, služeb a infrastruktury. Tyto systémy zaznamenávají klíčové metriky, jako jsou doby odezvy, délky front, využití procesoru a využití paměti.

  • Rozhodovací logika vyhodnocuje tyto metriky využití za provozu proti předdefinovaným prahovým hodnotám nebo plánům a rozhoduje, jestli se má škálovat.

  • Komponenty a mechanismy provádějí akci škálování. V ideálním případě by se tyto komponenty a mechanismy měly oddělit od samotného kódu úlohy a spravovat jako externí proces. Kód, který je nečinný nebo zahlcený, by neměl být zodpovědný za samotné škálování.

  • Testování, monitorování a ladění možností pro strategii automatického škálování, aby se zajistilo, že funguje podle očekávání.

Azure poskytuje integrované mechanismy automatického škálování, které řeší běžné scénáře. Pokud určitá služba nebo technologie nemá integrovanou funkci automatického škálování nebo pokud máte specifické požadavky na automatické škálování nad rámec svých možností, zvažte vlastní implementaci. Vlastní implementace shromažďuje provozní a systémové metriky, analyzuje metriky a odpovídajícím způsobem škáluje 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ích prostředků.

Všechny tyto možnosti výpočetních prostředků používají funkci automatického škálování služby Azure Monitor k zajištění společné sady funkcí automatického škálování.

  • Azure Functions se liší od předchozích možností výpočetních prostředků, protože nemusíte konfigurovat žádná pravidla automatického škálování. Místo toho Azure Functions při spuštění kódu automaticky přiděluje výpočetní výkon. Azure Functions škáluje kapacitu podle potřeby, aby zvládla zatížení. Další informace najdete v tématu Volba správného plánu hostování pro Azure Functions.

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. Pak můžete definovat vlastní pravidla na základě těchto metrik a pomocí rozhraní REST API Azure Resource Manageru aktivovat automatické škálování. Vlastní řešení ale může vyžadovat značné úsilí, proto ho zvažte jenom v případě, že žádný z předchozích přístupů nesplňuje vaše požadavky.

Pokud splňují vaše požadavky, použijte integrované funkce automatického škálování platformy. Pokud ne, pečlivě zvažte, jestli 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í funkce automatického škálování služby Azure Monitor

Funkce automatického š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čů, App Service a Azure Cloud Services. Š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.

Zvažte následující příklady:

  • Horizontální navýšení kapacity na 10 instancí v pracovní dny a škálování na čtyři instance v sobotu a neděli

  • Pokud je průměrné využití procesoru vyšší než 70 %, horizontálně rozšiřte kapacitu o jednu instanci, a pokud využití procesoru klesne pod 50 %, zmenšete kapacitu o jednu instanci.

  • Škálujte o jednu instanci, pokud počet zpráv ve frontě překročí určitou prahovou hodnotu.

Zvyšte kapacitu zdroje, když se zvýší zatížení, aby se zajistilo zajištění dostupnosti. V době nízkého využití můžete vertikálně snížit kapacitu, abyste mohli optimalizovat náklady. Vždy používejte kombinaci pravidel horizontálního navýšení kapacity a sníž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ý. Prostředek se škáluje 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 o automatickém škálování běžných metrik služby Azure Monitor. Vlastní metriky můžete implementovat také pomocí Application Insights.

Automatické škálování můžete nakonfigurovat pomocí PowerShellu, Azure CLI, šablony Azure Resource Manageru nebo webu Azure Portal. Pro podrobnější řízení použijte rozhraní Resource Manager REST API. Knihovna pro správu 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í pomocí rozhraní REST API. Pro prostředky, ve kterých není k dispozici podpora Resource Manageru nebo pokud používáte 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 Resource Manager.

Při použití automatického škálování 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 nemůžete, použijte reaktivní automatické škálování na základě metrik modulu runtime ke zpracování nepředvídatelných změn v poptávce. Tyto přístupy můžete obvykle 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ší. Další zdroje informací pomáhají zajistit, aby byla kapacita dostupná v případě potřeby, a to bez jakéhokoli zpoždění při spouštění nových instancí. Pro každé naplánované pravidlo definujte metriky, které během tohoto období umožňují reaktivní automatické škálování, aby se zajistilo, že aplikace dokáže zvládnout trvalou, ale nepředvídatelnou špičku v poptávce.

  • Často je obtížné pochopit vztah mezi metrikami a požadavky na kapacitu, zejména při počátečním nasazení aplikace. Na začátku nakonfigurujte trochu další kapacitu a pak monitorujte a vylaďte pravidla automatického škálování, aby se kapacita blížil skutečné zátěži.

  • Nakonfigurujte pravidla automatického škálování a pak monitorujte výkon aplikace v průběhu času. Výsledky tohoto monitorování použijte k úpravě způsobu, jakým se systém v případě potřeby škáluje. Mějte ale na paměti, že automatické škálování není okamžitý proces. Reakce na metriku, jako je průměrné využití procesoru, které překračuje nebo klesne pod zadanou prahovou hodnotu, nějakou dobu trvá.

  • Pravidla automatického škálování, která používají mechanismus detekce založený na atributu měřené aktivační události, používají k aktivaci akce automatického škálování agregovanou hodnotu v průběhu času místo okamžitých hodnot. Atributy triggeru zahrnují využití procesoru nebo délku fronty. Ve výchozím nastavení je agregace průměrem hodnot. Tento přístup brání systému v reakci příliš rychle nebo způsobuje rychlou oscilaci. Poskytuje také čas pro nové instance, které se automaticky spustí, aby plně přešly do provozního režimu. Jiné akce automatického škálování nemůžou nastat, když se nové instance spouští. Pro Azure Cloud Services a Azure Virtual Machines je výchozí období agregace 45 minut. Aby metrika aktivovala automatické škálování v reakci na špičky v poptávce, může to trvat až do tohoto časového období. 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. Funkce Web Apps v rámci služby App Service má dobu průměrování kratší, což umožňuje dostupnost nových instancí přibližně za pět minut po změně průměrné hodnoty spouštěcího měření.

  • Vyhněte se přepínání, kdy se akce horizontálního snížení kapacity a horizontálního navýšení kapacity neustále střídají. Předpokládejme, že existují dvě instance. Horní limit je 80% CPU a dolní limit je 60%. Pokud je zatížení 85%, přidá se další instance. Po nějaké době se zatížení sníží na 60%. Než služba automatického škálování sníží počet instancí, vypočítá rozdělení celkového zatížení (ze tří instancí) po odebrání jedné instance a určí, že je na 90%. Muselo by se okamžitě znovu rozšířit. Takže škálování se přeskočí a možná nikdy neuvidíte očekávané výsledky škálování.

    Je možné řídit flapping situaci výběrem přiměřeného rozmezí mezi prahovými hodnotami pro škálování nahoru a dolů.

  • Ruční škálování se resetuje na základě maximálního a minimálního počtu 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 třemi a šesti. 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ě, pokud ručně nastavíte škálovací kapacitu na osm instancí, automatické škálování ji při dalším spuštění znovu nastaví na šest instancí. 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 snižování kapacity vyžaduje automatické škálování splnění všech pravidel.

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

  • Pokud nakonfigurujete automatické škálování pomocí sady SDK místo 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 použít je s libovolnými z existujících metrik v pravidlech automatického škálování nebo bez nich. 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 můžete použít vlastní čítače k měření konkrétních obchodních procesů.

  • Když nakonfigurujete více zásad a pravidel, můžou být vzájemně v konfliktu. Automatické škálování používá následující pravidla řešení konfliktů k zajištění, že vždy existuje dostatečný počet spuštěných instancí:

    • 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í.

    • Při konfliktu operací zmenšení kapacity má přednost pravidlo, které vede k nejmenšímu 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 Přehled služby App Service Environment.

Aspekty návrhu aplikací

Automatické škálování není okamžité řešení. Přidání prostředků do systému nebo spuštění více instancí procesu nezaručuje vyšší výkon. 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 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í kapacity i horizontální snížení kapacity. Bez správného návrhu by takový úkol mohl zabránit čistému vypnutí instance procesu, když se systém škáluje. Nebo může dojít ke ztrátě dat, pokud je proces vynuceně 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. Příklad najdete v části Kanály a filtry.

  • Alternativně můžete implementovat mechanismus kontrolního bodu, který zaznamenává informace o stavu úlohy v pravidelných intervalech. Uložte tyto informace o stavu v odolném úložišti, ke kterému má přístup jakákoli instance procesu, který spouští úlohu. Takže pokud je proces vypnutý, může být práce, kterou prováděla, obnovena 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í. Můžete například potřebovat nasadit více výpočetních instancí uživatelského rozhraní (UI), aniž byste zvýšili počet výpočetních instancí na pozadí nebo naopak. Můžete nabídnout 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ž prostředky pro základní balíčky služeb. Tento přístup vám pomůže splnit smlouvy o úrovni služeb (SLA).

Další kritéria škálování

  • 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í. Tato kritéria mohou indikovat nerovnováhu nebo rozdíl 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 v přijatelném obchodním rozsahu, není nutné škálovat, i když je délka fronty dlouhá.

    • Ve frontě může být například 50 000 zpráv. Kritická doba nejstarší zprávy je 500 ms a tento koncový bod se zabývá integrací s partnerskou webovou službou pro odesílání e-mailů. Obchodní partneři nemusí tento scénář považovat za dostatečně naléhavý, aby odůvodnil náklady na horizontální navýšení kapacity.

    • Na druhou stranu by ve frontě mohlo být 500 zpráv se stejným kritickým časem 500 ms. Koncový bod je ale součástí kritické cesty v online hře v reálném čase, kde obchodní účastníci definovali dobu odezvy 100 ms nebo kratší. V takovém případě má horizontální navýšení kapacity smysl.

    • Aby bylo možné při rozhodování o automatickém škálování využít kritické období, je užitečné mít knihovnu, která automaticky přidává relevantní informace do hlaviček zpráv během přenosu a zpracování. Jednou z takových knihoven, která tuto funkci poskytuje, je NServiceBus.

  • Pokud strategii automatického škálování založíte na čítačích, které měří obchodní procesy, ujistěte se, že rozumíte vztahu mezi výsledky z těchto typů čítačů a skutečnými požadavky na výpočetní kapacitu. Příklady čítačů zahrnují počet objednávek zadaných každou hodinu nebo průměrný běh složité transakce. 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 nadměrnému horizontálnímu navýšení kapacity systému, zvažte omezení maximálního počtu instancí, které je možné přidat automaticky. Tento přístup také zabraňuje nákladům spojeným s provozem mnoha tisíc 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 nasadíte 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í. Nastavení 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 v tématu Model omezování.

  • Naopak pokud potřebujete kapacitu ke zpracování všech požadavků, když svazek rychle kolísá, zvažte použití agresivní strategie automatického škálování, která spouští další instance rychleji. Ujistěte se, že náklady nejsou hlavním faktorem, který přispívá. 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í. Mezi tyto podrobnosti patří to, co událost aktivovalo, jaké prostředky byly přidány nebo odebrány, a kdy k ní došlo. 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 další prostředky. 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ři implementaci automatického škálování můžou být pro váš scénář relevantní také následující vzory a pokyny:

  • Model omezování popisuje, jak aplikace může nadále fungovat a splňovat dohody o úrovni služeb, když zvýšení poptávky představuje extrémní zátěž na zdroje. Omezení je možné použít s automatickým škálováním, aby se zabránilo zahlcení systému při horizontálním navýšení kapacity systému.

  • Model Konkurující spotřebitelé popisuje, jak implementovat fond instancí služby, které mohou zpracovávat zprávy z jakékoli instance aplikace. Automatické škálování se dá použít ke spuštění a zastavení instancí služby tak, aby odpovídaly očekávané úloze. Tento přístup umožňuje systému zpracovávat více zpráv souběžně za účelem optimalizace propustnosti, zlepšení škálovatelnosti a dostupnosti a vyrovnávání zatížení.

  • Monitorování a diagnostika, včetně instrumentace a metrik, jsou důležité pro shromažďování informací, které můžou řídit proces automatického škálování.

  • Last updated on