Automatické škálování

  • Článek
  • 13 min ke čtení

Automatické škálování je proces dynamického přidělování prostředků podle požadavků 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í. S využitím diagnostiky Azure a metrik orientovaných na aplikace společně s vlastním kódem můžete například monitorovat a exportovat metriky aplikací. 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

Azure monitor automatické škálování nabízí společnou sadu funkcí automatického škálování pro služby Virtual Machine Scale sets, Azure App Service 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:

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

Po zvýšení zátěže můžete škálovat prostředek, aby se zajistila dostupnost. Podobně v případě nízkého využití Škálujte, abyste mohli optimalizovat náklady. Vždy používejte kombinaci možností škálování na více instancí a škálování na více instancí. V opačném případě bude automatické škálování provedeno pouze v jednom směru, dokud nebude dosaženo prahové hodnoty (maximální nebo minimální počty instancí) nastavené v profilu.

Vyberte výchozí počet instancí, který bude pro vaše zatížení bezpečný. Na základě této hodnoty se škáluje, pokud nejsou nastavené maximální nebo minimální počty 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 taky 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, zda můžete odhadnout zatížení aplikace dostatečně přesně, aby bylo možné použít naplánované automatické škálování, přidat a odebrat instance pro uspokojení předpokládaných vrcholů 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á prostředky na základě časového plánu, kdy víte, že aplikace je nejvytíženě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 taky čas pro nové instance, které se automaticky začnou vyrovnávat do běžícího režimu, aby se zabránilo dalším akcím automatického škálování, ke kterým dochází při spouštění nových instancí. 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. Můžete změnit období agregace pomocí sady SDK, ale doby méně než 25 minut můžou způsobovat 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 tomu přepíná , kde se průběžné a škálovatelné akce na horizontálním navýšení kapacity přecházejí zpátky. Předpokládejme, že existují dvě instance a horní limit je 80% CPU, nižší limit je 60%. Pokud je zatížení v 85%, přidá se další instance. Po určité době se zatížení sníží na 60%. Před škálováním v systému vypočítá služba automatického škálování distribuci celkového zatížení (ze tří instancí) při odebrání instance a převezme ji až 90%. To znamená, že by se muselo horizontální horizontální navýšení kapacity. Proto přeskočí horizontální navýšení kapacity a nikdy se vám nemusí zobrazovat očekávané výsledky škálování.

    Situaci přepíná můžete nastavit tak, že vyberete odpovídající okraj mezi mezními hodnotami škálování na více instancí a škálováním na více instancí.

  • Ruční škálování se resetuje podle maximálního a minimálního počtu instancí použitých pro automatické škálování. Pokud ručně aktualizujete počet instancí na hodnotu vyšší nebo nižší, než je maximální hodnota, modul automatického škálování se automaticky změní na minimum (Pokud je nižší) nebo na 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 jste ručně nastavili měřítko na osm instancí, při dalším spuštění bude automatické škálování v dalším spuštění škálovat až na šest instancí. Ruční škálování je dočasné, Pokud neobnovíte také pravidla automatického škálování.

  • Modul automatického škálování zpracovává současně pouze jeden profil. Pokud není podmínka splněná, zkontroluje další profil. Zachovejte klíčové metriky mimo výchozí profil, protože tento profil je zkontrolován 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ěno nějaké pravidlo. Při horizontálním navýšení kapacity vyžaduje automatické škálování splnění všech pravidel.

Podrobnosti o tom, jak Azure Monitor škálují, 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 v clusteru probíhají služby virtual machine scale sets na back-endu, takže musíte 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 horizontální navýšení nebo navýšení kapacity Service Fabric clusteru 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 škálování na více instancí vždy mají přednost před operacemi škálování na více instancí.
    • Když dojde ke 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í.

  • V App Service Environment se k definování pravidel automatického škálování dá použít libovolný fond pracovních procesů nebo metriky front-endu. 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. Vzor konkurenčních 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álů a filtrů poskytuje příklad toho, jak to můžete 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 platí, že pokud je proces vypnutý, lze práci, kterou prováděli, obnovit z posledního kontrolního bodu pomocí jiné instance.

  • Když se úlohy na pozadí spouští na samostatných výpočetních instancích, například v rolích pracovních procesů aplikace hostované v cloudu – , může být potřeba š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 horizontálně navyšovat kapacitu výpočetních prostředků u balíčků služby úrovně Premium agresivněji než u balíčků služby úrovně Basic.

  • Zvažte jako kritérium pro strategii automatického škálování použít délku fronty, přes kterou komunikují uživatelské rozhraní a výpočetní instance na pozadí. To je nejlepší indikátor nevyváženosti nebo rozdílu mezi aktuálním zatížením a kapacitou zpracování úlohy na pozadí.

  • 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 horizontální navýšení kapacity 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 tématu model 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. Všimněte si, že za těchto okolností může operátor při ručním odstraňování těchto prostředků za běhu také odpovídat.

Při implementaci automatického škálování můžou pro váš scénář být relevantní také následující modely 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í.