Autoscaling nenahrazuje kapacitní plánování CIO MAG

Dokumentace Kubernetes popisuje autoscaling jako řídicí smyčku, nikoli okamžitou rezervu. HPA vyhodnocuje metriky v periodách. Node autoscaler reaguje na Pody, které nelze naplánovat, a poté komunikuje s cloudovým providerem. Samotná dokumentace upozorňuje, že provisioning může narazit na limit, nekompatibilní konfiguraci nebo nedostupnost kapacity.

AWS u instancí samostatně řeší warmup. Nový stroj může být ve stavu InService, ale jeho aplikace ještě stahuje artefakty, plní cache nebo stabilizuje spotřebu. Překvapivý detail zní: autoscaling může nově spouštěnou instanci už započítat do rozhodování o přidání další kapacity, přestože její užitečný výkon ještě není plný.

Manažerské shrnutí

01Autoscaling má zpoždění. Detekce, rozhodnutí, provisioning, start a warmup se sčítají do času, během kterého musí služba přežít na stávající kapacitě.

02Kvóta je tvrdá hranice. Řídicí smyčka nevytvoří zdroj, který provider, účet nebo topologie v dané chvíli neposkytne.

03Plánuje se přeživší výkon. Kapacita musí pokrýt špičku, ztrátu zóny, pomalé závislosti a režim řízené degradace.

Čas do kapacity má pět částí

Pro plánování nestačí doba startu virtuálního stroje. Od prvního zvýšení zátěže do užitečné kapacity se sčítá interval metriky, vyhodnocení politiky, získání zdroje, start aplikace a dosažení stavu, ve kterém instance skutečně dokončuje produkční práci.

Fáze	Co ji prodlužuje	Co měřit
Detekce	Agregace metriky a nevhodný signál	Čas od růstu příchodů k rozhodnutí scale out
Provisioning	Kvóta, nedostupný typ instance a plánovací omezení	Čas k přidělení reálného zdroje a počet odmítnutí
Start	Image, bootstrap, připojení sítě a volume	Čas od přidělení k běžící aplikaci
Warmup	JIT, cache, načtení modelu a registrace u load balanceru	Čas k prvnímu a plnému užitečnému výkonu
Stabilizace	Přerozdělení spojení, front a shardů	Čas k návratu p99 a front do bezpečné oblasti

KAPACITNÍ PRAVIDLO

Minimální běžící rezerva musí unést přírůstek provozu po celý experimentálně naměřený čas do plné užitečné kapacity. Pokud služba překročí bod zlomu dříve, autoscaling reaguje příliš pozdě bez ohledu na správnost politiky.

Aplikační scaling nepřidá databázový výkon

Horizontální přidání frontendů pomůže pouze tehdy, když ostatní vrstvy přijmou více práce. Databáze může mít limit spojení, fronta maximální propustnost, externí API kvótu a licencovaná služba pevný počet souběžných operací. Autoscaler potom zlepší počet producentů zátěže, nikoli počet dokončených transakcí.

Kapacitní model proto musí sledovat celou kritickou cestu a vyjádřit závislosti. Google SRE používá intent based capacity planning, které místo prostého počtu strojů zachycuje požadovanou redundanci, geografii a vztahy služeb. Nejde o univerzální nástroj pro každý podnik, ale o důležitý princip: kapacita má být popsána požadovaným výsledkem a omezeními, nikoli historickým počtem instancí.

ZÁTĚŽOVÝ TEST

Začněte na minimální produkční kapacitě a zvyšte provoz rychlostí realistické špičky. Měřte čas k první nové instanci, čas k jejímu plnému výkonu, p99, fronty a propustnost každé sdílené závislosti. Test opakujte se ztrátou jedné zóny.

Modelový scénář z praxe: Pody vznikly, uzly nebyly

Modelová služba používala HPA podle CPU a node autoscaling. Při marketingové špičce HPA rychle vytvořil nové Pody, ale část zůstala Pending. Potřebovaly typ uzlu s lokálním diskem a konkrétní zónou. Předem nakonfigurovaná skupina dosáhla maxima a provider v dané zóně neměl požadovaný typ okamžitě k dispozici.

Řídicí smyčky pracovaly správně, avšak neměly zdroj, který by mohly použít. Organizace přidala alternativní typ uzlu, zvýšila minimální rezervu před plánovanými kampaněmi, upravila requests a připravila degradovaný režim bez méně důležité funkce. Kapacitní plán se přestal ptát, zda je autoscaler zapnutý. Začal měřit, jakou poptávku dokáže služba dokončit před a po ztrátě dostupné kapacity.

POZNÁMKA Z PRAXE

Pending Pod není nová kapacita. Je to žádost o kapacitu. Dokud uzel neexistuje a aplikace na něm nedokončuje užitečnou práci, nesmí být započítán do provozní rezervy.

Co úspěšný scale out neprokazuje

Jednorázové přidání instancí při klidném testu neprokazuje dostupnost stejné kapacity během regionální špičky ani při výpadku zóny. Neověřuje kvóty dalších služeb, limity databáze ani chování při návratu z extrémní zátěže. Historická dostupnost určitého typu zdroje není smluvní rezervace budoucí kapacity.

Naopak statická rezerva není automaticky lepší než autoscaling. Stojí peníze a při špatném odhadu může být stále nedostatečná. Cílem je kombinace ověřené základní rezervy, automatické reakce, předvídatelného plánování událostí a řízené degradace, když poptávku nelze bezpečně obsloužit celou.

HRANICE DŮKAZU

Dokumentace popisuje chování řídicích smyček a jejich omezení. Neurčuje bezpečnou rezervu konkrétní služby. Tu lze odvodit až z jejího bodu zlomu, warmupu, závislostí a požadovaného scénáře poruchy.

Autoscaling je vykonavatel plánu

Kapacitní rozhodnutí má určit očekávanou poptávku, bezpečnou provozní oblast, dobu do nové kapacity, přeživší režim, kvóty a funkce, které lze dočasně omezit. Autoscaler potom tento plán provádí v přesně vymezeném prostoru.

Nosná teze zní: autoscaling neumí vytvořit čas, kvótu ani downstream kapacitu, kterou architektura nemá. Dokáže pouze automatizovat reakci na podmínky, které organizace předem změřila a připravila.