TakéAuto Scaling, Auto-ScalingPokročilý
Definice
Automatické škálování je řízení výpočetní kapacity služby podle aktuální nebo očekávané zátěže bez ručního zásahu operátora. Systém přidává či odebírá instance, kontejnery, vlákna nebo jiné prostředky podle metrik a pravidel, aby aplikace zvládla špičky, neplatila zbytečnou rezervu a zůstala stabilní.
Proč automatické škálování řeší špičky
Automatické škálování přesouvá rozhodnutí o kapacitě z ručního zásahu na pravidla a měření. Provozní tým nenastavuje počet serverů jen podle odhadu, ale nechá platformu sledovat zátěž a spouštět změny. Typickým cílem je vyrovnat dvě rizika: nedostatek kapacity při špičce a zbytečně drahou rezervu v klidném období.
Cloudové služby, kontejnery i některé databázové platformy umí přidat další uzly, kontejnery nebo worker procesy. Automatické škálování se často kombinuje s load balancerem, který rozděluje provoz mezi nové a původní instance.
Signály, podle kterých se kapacita mění
Pravidlo pro škálování potřebuje signál, prahovou hodnotu a reakci. Signálem může být využití CPU, paměť, počet požadavků za sekundu, délka fronty, latence, počet otevřených spojení nebo vlastní aplikační metrika. U fronty bývá lepším signálem počet čekajících zpráv než procesor, protože CPU může být nízké i ve chvíli, kdy uživatelé čekají.
Rozhodování bývá záměrně pomalejší než samotné měření. Platforma obvykle vyhodnocuje hodnoty za určité období, aby nereagovala na krátký výkyv. Bez stabilizačního okna by služba mohla oscilovat: přidat kapacitu, hned ji odebrat a za chvíli znovu přidat.
Horizontální, vertikální a plánované rozšíření
Horizontální škálování přidává další kopie stejné služby. Webová aplikace může běžet ve více kontejnerech a příchozí požadavky se rozdělí mezi ně. Právě tento model je běžný v Kubernetes, kde Horizontal Pod Autoscaler upravuje počet podů podle metrik.
Vertikální škálování mění velikost jednoho běžícího prostředku, například přidá instanci více paměti nebo procesorových jader. Vertikální přístup je užitečný u systémů, které nelze jednoduše rozdělit na mnoho kopií, ale často vyžaduje restart nebo má pevný strop. Plánované škálování reaguje na známý kalendář: kampaň, televizní reklamu, pravidelnou fakturaci nebo večerní špičku.
Limity, které nejdou vyřešit přidáním instancí
Automatické škálování nepřekoná úzké hrdlo, které zůstává sdílené. Databáze s pomalým dotazem, vyčerpaný connection pool, externí API s limitem nebo zámek v aplikaci mohou brzdit provoz i po přidání dalších instancí. V takové situaci může více workerů problém dokonce zhoršit, protože vytvoří větší tlak na stejný slabý bod.
Dobrá architektura proto kombinuje škálování s frontami, časovými limity, backpressure a měřením chyb. Kapacita navíc má chránit službu, ne maskovat nekonečný růst fronty.
Nastavení bez zbytečného rozhazování
Rozumné nastavení začíná minimem a maximem. Minimum drží službu připravenou, maximum chrání rozpočet i závislé systémy. Důležité jsou také zahřívací časy: nová instance může chvíli startovat, načítat cache nebo navazovat spojení, takže reakce nikdy není okamžitá.
Automatické škálování patří do provozního návrhu stejně jako monitoring a alerting. Pravidla se mají testovat při zátěžových zkouškách, protože běžné metriky z klidného provozu často neukážou, co se stane při náhlém nárůstu požadavků.
Příklady z praxe
Kampaň v e-shopu
E-shop spustí reklamní kampaň a počet požadavků na produktové stránky prudce vzroste. Kubernetes HPA sleduje využití CPU u webového deploymentu, postupně přidá další pody a load balancer na ně začne posílat část provozu. Po skončení kampaně se počet podů vrátí k nižší hodnotě, takže tým neplatí plnou kapacitu celý den.
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70Zpracování fronty faktur
Aplikace importuje faktury z fronty zpráv a každý worker zapisuje výsledek do databáze. Automatické škálování přidá workery podle délky fronty, ale horní limit je nastavený tak, aby databáze nepřekročila bezpečný počet spojení. Fronta se odbaví rychleji, aniž by škálování shodilo sdílenou databázovou vrstvu.
Časté omyly
- MýtusZapnu autoscaling a výkonové problémy zmizí.
- Ve skutečnostiAutomatické škálování pomůže jen u zátěže, kterou lze rozdělit na další prostředky. Pomalý dotaz, sdílený zámek, limit externí služby nebo špatná cache se přidáním instancí samy neopraví.
- MýtusČím kratší interval měření, tím lepší škálování.
- Ve skutečnostiPříliš rychlá reakce může způsobit oscilaci a zbytečné náklady. Stabilizační období a vhodná agregace metrik často vedou k lepšímu provozu než okamžitá reakce na každý krátký výkyv.
- MýtusAutomatické škálování znamená jen přidávání serverů.
- Ve skutečnostiAutomatické škálování zahrnuje i odebírání kapacity, změnu velikosti prostředků nebo plánované navýšení před známou špičkou. Smyslem není mít co nejvíc instancí, ale držet kapacitu blízko skutečné potřebě.
Časté dotazy
- Proč se při automatickém škálování někdy přidá kapacita pozdě?
- Automatické škálování reaguje až po naměření problému nebo podle předem nastaveného plánu. Nová instance navíc potřebuje čas na spuštění, registraci v load balanceru, načtení konfigurace a zahřátí cache. Při velmi prudké špičce proto může část uživatelů krátce čekat nebo dostat chybu, pokud služba nemá dostatečné minimum, frontu nebo ochranné limity.
- Může automatické škálování nahradit load balancer?
- Automatické škálování load balancer nenahrazuje, protože řeší jinou část problému. Automatické škálování mění počet dostupných instancí, zatímco load balancer rozděluje požadavky mezi instance, které právě existují a jsou zdravé. U horizontálně škálované webové aplikace bývají obě technologie použité společně: škálování přidá kapacitu a load balancer ji začne využívat.
- Kdy automatické škálování prodraží cloud?
- Automatické škálování se prodraží, když pravidla reagují na šum, ne na skutečnou potřebu. Časté přidávání a odebírání instancí zvyšuje náklady, komplikuje diagnostiku a může zatěžovat závislé služby. Rizikem je také příliš vysoký maximální limit, špatně zvolená metrika nebo chyba v aplikaci, která vyvolá růst zátěže a tím i zbytečné přidávání kapacity.
- Co musí být připravené před zapnutím automatického škálování?
- Automatické škálování dává smysl až ve chvíli, kdy je služba měřitelná a opakovatelně nasaditelná. Pro začátek obvykle stačí znát běžnou zátěž, kritické metriky, startovací čas instance, horní limit rozpočtu a úzká hrdla závislostí. Bez monitoringu a alertingu se pravidla nastavují naslepo a provozní tým nepozná, jestli škálování skutečně pomáhá.
Zdroje
- Horizontal Pod Autoscaling(otevře se v novém okně)
- AWS Auto Scaling(otevře se v novém okně)
- Overview of autoscale in Microsoft Azure(otevře se v novém okně)
- Autoscaling groups of instances(otevře se v novém okně)
Související pojmy
