Röviden: A rossz metrika és a hibás cooldown miatt a legtöbb Auto Scaling csoport vagy késik, vagy oszcillál. Hogyan állítsd be úgy, hogy tényleg a terheléshez igazodjon?
Az automatikus skálázás ígérete csábító: a rendszer magától nő, ha kell, és zsugorodik, ha nem, te pedig nem fizetsz felesleges kapacitásért. A gyakorlatban a legtöbb Auto Scaling csoport két hibás állapot valamelyikében leledzik: vagy túl lassan reagál (a felhasználó már érzi a lassulást, mire beindul), vagy oszcillál (fel-le kapkod, instabilan). A különbség a metrika, a cooldown és a skálázási logika helyes megválasztásában van.
A rossz metrika
A leggyakoribb hiba a skálázási metrika rossz megválasztása. Sokan a CPU-kihasználtságra skáláznak, mert az kézenfekvő — de sok workload nem CPU-korlátos. Ha a valós szűk keresztmetszet a memória, a kérési sor hossza vagy a válaszidő, akkor a CPU-alapú skálázás vagy túl későn, vagy feleslegesen indul. A skálázási jelnek azt kell tükröznie, ami tényleg korlátozza a rendszert.
A cooldown csapdája
A cooldown (a skálázási akciók közti várakozás) a másik gyakori hiba forrása. Túl rövid cooldown esetén a rendszer oszcillál: alig indított el egy új példányt, máris újabbat indítana, mert a metrika még nem állt be, majd túllő és leskáláz. Túl hosszú cooldown esetén viszont lomha lesz, és a csúcsot lekési. A cooldownt a rendszer valós reakcióidejéhez kell igazítani — mennyi idő, mire egy új példány ténylegesen forgalmat vesz.
Az aszimmetrikus skálázás
Egy hasznos elv, hogy a felskálázás legyen gyors és bátor, a leskálázás pedig lassú és óvatos. A felskálázásnál a kockázat, hogy lekésed a csúcsot és a felhasználó szenved — ezért inkább előbb indíts. A leskálázásnál a kockázat, hogy túl korán elveszed a kapacitást egy átmeneti csökkenésnél, és rögtön újra kell indítanod — ezért inkább várj. Ez az aszimmetria csökkenti az oszcillációt.
A prediktív skálázás
Ahol a terhelésnek ismétlődő, jósolható mintázata van (napi, heti ciklusok), ott a prediktív skálázás sokat segít: nem a már bekövetkezett terhelésre reagál, hanem a várható csúcs előtt előre felkészül. Így a felhasználó nem érzi a felskálázás késleltetését. Ez a reaktív skálázás kiegészítője, nem helyettesítője — a váratlan tüskékre továbbra is a reaktív logika válaszol.
A tesztelés
Az Auto Scaling beállítását tesztelni kell, nem csak beírni és remélni. Terheléses teszttel érdemes megnézni, hogy a rendszer időben és stabilan reagál-e a növekvő és csökkenő terhelésre, oszcillál-e, lekési-e a csúcsot. A beállítás finomhangolása iteratív munka; a valós terhelési mintázat ismerete nélkül csak tippelsz.
A helyes skálázási metrika
A legtöbb Auto Scaling csoport azért reagál rosszul, mert rossz metrikára skálázik. Sokan a CPU-kihasználtságra állítanak, mert az kézenfekvő — de sok workload nem CPU-korlátos. Ha a valós szűk keresztmetszet a memória, a kérési sor hossza vagy a válaszidő, akkor a CPU-alapú skálázás vagy túl későn, vagy feleslegesen indul. A skálázási jelnek azt kell tükröznie, ami tényleg korlátozza a rendszert.
A jó jel gyakran közvetlenül a felhasználói élményt vagy a valós terhelést méri — például a várakozó kérések számát —, nem egy közvetett proxy-metrikát.
A cooldown és az aszimmetria
A cooldown (a skálázási akciók közti várakozás) rossz beállítása oszcillációt vagy lomhaságot okoz. Túl rövid cooldown esetén a rendszer kapkod: alig indított új példányt, máris újabbat indítana, majd túllő és leskáláz. Túl hosszú esetén lekési a csúcsot. A cooldownt a rendszer valós reakcióidejéhez kell igazítani. Hasznos elv az aszimmetria: gyors, bátor felskálázás, lassú, óvatos leskálázás.
- Skálázz a valós szűk keresztmetszetre, ne csak a CPU-ra.
- Igazítsd a cooldownt a példányok tényleges reakcióidejéhez.
- Felfelé gyorsan, lefelé óvatosan — ez csökkenti az oszcillációt.
A prediktív skálázás és a tesztelés
Ahol a terhelésnek ismétlődő, jósolható mintázata van, a prediktív skálázás előre felkészül a várható csúcsra, így a felhasználó nem érzi a felskálázás késleltetését — ez a reaktív logika kiegészítője. Végül a beállítást tesztelni kell terheléses teszttel: időben és stabilan reagál-e, oszcillál-e, lekési-e a csúcsot. A jól hangolt skálázás láthatatlan; a rosszul hangolt vagy késik, vagy kapkod.
Mit jelent ez neked?
Egy Auto Scaling csoport csak akkor ér valamit, ha a helyes jelre, helyes időzítéssel reagál. Válaszd a skálázási metrikát a valós szűk keresztmetszet (gyakran a kérési sor, nem a CPU) alapján, igazítsd a cooldownt a példányok tényleges reakcióidejéhez, és skálázz aszimmetrikusan: gyorsan felfelé, óvatosan lefelé. Ahol a terhelés jósolható, egészítsd ki prediktív skálázással. Végül teszteld terheléssel — a jól hangolt skálázás láthatatlan, a rosszul hangolt vagy késik, vagy kapkod.