Szerver erőforrás tervezés Poisson eloszlással

Ha egy webes vagy helyi infra szolgáltatás régebb óta üzemel, akkor az azt kiszolgáló szerver háttér jó eséllyel vagy alul van tervezve, vagy pedig felül. Kérdés hogy melyik és mennyire? 2 fajta megközelítést használhatunk ennek elemzésére.

 

Az első a 3 szigma limit vizsgálat, melyet előző blogom videójában is bemutattam. Ennek lényege, hogy az utolsó nagyobb időszak erőforrás terheltségére (pl.: memória használat kérésenként és sávszélesség terhelés kérésenként) számítunk egy határértéket úgy, hogy az átlagához hozzáadjuk szórásának 3-szorosát. Előtte log transzformációt végzünk az adatokon, ha az értékek ferdesége nagyobb mint 2.

Ez a határérték azt mutatja, hogy maximum mennyire kell terveznünk a rendelkezésre álló kérdéses erőforrás nagyságát, hogy biztonsággal ki tudja szolgálni a kéréseket. Ha nem megoldható a 3 szigma megbízhatóság, akkor számolhatunk 2-vel is. De ajánlott a 3.

Több szerver is kiszolgálhatja az igényeket, ha véletlenszerűen szétosztjuk közöttük a bejövő kéréseket. Ekkor a nagy számok törvényének matematikai tétele garantálja azt, hogy egyenlő módon lesz szétosztva a terhelés és így továbbra is érvényes rájuk a fenti számítás, függetlenül attól, hogy 1 vagy több szerverrel tervezünk. Ami fontos, hogy azonos kapacitással rendelkezzenek.

A szolgáltatás ismertsége nőhet és ezért, vagy egyéb más okból kifolyólag folyamatosan változhat a bejövő igények mennyisége, ezért időnként újra kell vizsgálni a fentieket a legutolsó friss időszakon, ami ne legyen túl kicsi intervallum. Mozgó átlag ábrázolása grafikonban segíthet eldönteni, hogy mikortól van trend váltás és így mikortól nézzük az időszakot.

 

Egy másik fajta szempontból ad plusz rálátást, hogy ha nem csak a felhasznált erőforrás mértékét elemezzük, hanem a bejövő kérések számát. Ezt Poisson eloszlással tudjuk modellezni, ha a kérések egymástól függetlenek. Lehetne itt is használni a fenti metódust, de ez a modell egy picit jobban illeszkedik ebben az esetben a gyakorlathoz, mert nem azonos időnként jelennek meg valamilyen mennyiségek, hanem 1 db kérés jelenik többször fix időszakon belül. Tehát egy picit más a megközelítés.

https://i.imgur.com/2BcyUk9.png

https://i.imgur.com/iJ8E4zt.png

Ez azt mutatja, hogy mekkora az esélye az egységnyi idő alatt beérkező kérések számának. Tudjuk, hogy az átlagnál több kérésnek kisebb az esélye, de ezzel konkrétan meg is kapjuk, hogy mennyi.

Ehhez szükség van egy időablak meghatározására, például 1 óra, és ehhez a múltbeli kérések számát tárolnunk és ez alapján egy átlagot kell számolnunk. Vagyis ha le van tárolva, hogy 1 óra alatt mennyi kérés érkezett a múltban (ez egyetlen szám óránként), akkor ezen számoknak vesszük az átlagát.

Ha ez meg van, akkor ezen valós átlaghoz meg kell keresnünk a Poisson eloszlás kumulatív verziójában azt, hogy mekkora kérésnek kisebb az esélye egy bizonyos valószínűségnél. Ehhez szintén 3 szigma határértéket választok, ami 0.27%. Pontosabb értéke: 0.2699796063260207%. Kiszámítása Excelben (gyök kettővel osztani kell a szigma értékét):

=1-ERF(3/2^0.5)

Kumulatív valószínűség azért kell, mert nem egy konkrét érték valószínűségét keressük, hanem ezen konkrét érték feletti összesét, mert azokra sem fogunk tervezni, mert a határérték feletti értékeket mind extrémnek tekintjük. Tehát a kumulatív valószínűség egy elválasztó határvonalat ad a határ alatti összes és a határ feletti összes érték előfordulási esélyében.

A kapott érték fogja mutatni, hogy a választott időablakon belül maximum mekkora kérés számra tervezzünk. Ha nincs rá költség keret, akkor itt is használhatunk 3 helyett 2 szigma megbízhatóságot.

 

Hogyan számoljuk ki a kumulatív Poisson valószínűséghez tartozó határértéket?

Excel függvénnyel tudom legegyszerűbben szemléltetni. Tekintsük az alábbit:

Legyen „M” értéke a kiszámolt átlag az adott időablakra és „X” értékéből azt a legkisebb értéket keressük, mely nagyobb az átlagnál és az alábbi számítás eredménye kisebb mint 0.0027. Az utolsó 1-es paraméter azért kell, hogy kumulatív számítást végezzünk. Ha „M” az óránkénti kérések számának átlaga, akkor „X” db vagy ennél több beérkező kérés esélyét így kapjuk meg:

=1-POISSON.DIST(X, M, 1)

Ezt le is lehet programozni, mint inverz kumulatív Poisson eloszlás és felezéses próbálkozással gyorsan megtalálni a határértéket, mely log2 lépés alatt lefut. Ugye nem lehet zárt képletet adni az inverz megoldásra, mert egyrészt kumulatív, ami eleve summát vagy integrált tartalmaz (ha Gamma eloszlással váltjuk ki például), illetve van benne faktor vagy Gamma függvény, ami szintén integrál. Viszont a felezéses keresés gyors és elégséges.

Illetve simán Excelben is legenerálhatjuk lépésenként lefelé és egy „IF” függvénnyel vizsgálhatjuk, hogy az eredmény kisebb-e, mint 3 szigma. Amint az első legkisebb értéknél ez teljesül, azonnal meg van a válasz.

 

https://i.imgur.com/04EK7aD.png

Csináltam egy minta Excel táblát, melynél az első oszlopban megadjuk a választott szigma értékét (pl.: 3), a másodikban a múltbeli adatunkból kiszámolt átlagot (pl.: 100, vagyis óránként átlagosan 100 kérés), és a következő 3 oszlopot pedig lehúzzuk sokáig úgy, hogy automatikus módon kitöltse a következő értéket. Ezen oszlopokban azt látjuk, hogy az átlagnál mennyivel több kérésnek (3. oszlop), mekkora esélye van (4. oszlop) és ez kisebb-e mint a választott limitünk (5. oszlop). Ha igen, akkor meg van a végső válaszunk, hogy mekkora kérés mennyiségre kell terveznünk. A sárga cellák módosítandók.

Tehát a fenti képen látható esetben óránként maximum 129 kérésre kell terveznünk (100 az átlag plusz 29-es értéknél lépi át a limitet).

 

Google sheet link:

(ha módosítani szeretnétek, töltsétek le és nyissátok meg, érdemes kipróbálni más értékeket a sárga cellákban, melyek hatására módosul a szükséges tervezés felső határának értéke):

https://docs.google.com/spreadsheets/d/1JBd3vZkooJfQi2Z6_9L5NEpyvCvF9HY…

...

Hozzászólások

Köszi, jövő héten erre pont szükségem lesz.

> Ekkor a nagy számok törvényének matematikai tétele garantálja azt,

 

Egyebkent teged nem zavar, hogy kb. mindegyik ujsagiro (index.hu, multkor a lotuszcsoportos youtubeos urge, stb, stb) rosszul hasznalja?

Multkor idojarasjelentesben hallottam, hogy a nagy szamok torvenye ertelmeben, lehet, hogy holnap akar a jegeso is lesz. Azaz, hogy elobb-utobb bejon ha sokszor probalkozunk.

 

Miert is erdemes akkor a matematikaban meg jobban elmerulni? csak egy szamkivetett:) meg jobban meg nem ertett csodapok leszel.

Ahh, en mar fel is adtam a matekot. Igy jobban vegyulok.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Igen, sokan nem tudják hogy ez egy bizonyított tétel és olyan értelemben használják, hogy előbb utóbb bejön valami. Zavarni nem zavar, viszont írtam rá egy blog bejegyzést face-en éppen ezért.

https://www.facebook.com/andras.horvath.940098/posts/1903758016466585

Szerkesztve: 2022. 05. 08., v – 22:53

Jajjj ezt most igy vasarnap este, lefekves elott kemeny emlekeket idezett elo.

Jo sok evvel ezelott Sztochabol tanultuk ezeket. Emlekszem, hogy csinaltam egy oldalt ahol Erlang-eloszlast lehetett szamolni (nem is tudom mar miez de koze van a Poisson-folyamatokhoz, talan azt mutatja meg hogy mennyit kell varakoznia egy beerkezo keresnek, meg valami telefonkozponthoz is koze van :D) es cserebe megkaptam a kegyelem kettest a targybol. :)

Érdekes, köszi. Mi sokkal egyszerűbben csináljuk. Van egy rendelkezésre álló erőforrás limit, és annak a kihasználtsága, amit több napos időszak eloszlásának 90-körüli percentiliséből számolnak. Ez ugye egy könnyítés, mert a ritka kiugró felhasználást mondhatni a ház állja, van egy elég nagy pool, ami elnyeli a kis kilengéseket. Van egy elvárás, hogy a kihasználtság legalább x% legyen, hogy ne legyen pazarlás. Évente párszor ez alapján rendelünk több erőforrást (vagy épp visszaadunk, de az ritka). Illetve van monitoring, ami szól, ha a kihasználtság több, mint y%, és azonnali beavatkozás kell. Ha jól becsültük előre az organikus növekedést, akkor ilyen alert nem jön. De ezen kívül van még csomó dinamikus része a dolognak, terheléselosztás, virtuális CPU méretezés a pillanatnyi terhelés függvényében, oversubscription, stb., de ezek eléggé automatizáltak.

Percentilis alapból nagyon jó megoldás, mert hibatűrő, mivel nem érzékeny az anomália szintű kiugrásokra, viszont nem tud reagálni az információba kódolt varianciára. Ezt teszi már előre a fenti normál eloszlású modell.

A 90%-os szintje a percentilisnek kevésnek tűnik nekem, mert 10-ből 1-szer nem tudja kezelni. A fenti 3 szigma meg 370 esetből 1 hibát jelent ugye.

Azt írod, hogy van egy nagy pool, ami elnyeli a kicsi tüskéket. Ha a tiétek a teljes pool, akkor ennek a memória-terhelés ingadozására lenne érdekes szerintem egy számítás, mert akkor az ott mindent egybevenne. Ha CPU tüskék elnyelésére gondoltál, azok túlterhelése nem szokott problémát jelenteni egy bizonyos szint felett, mert akkor várakozásba állnak a folyamatok. Szemben a memória terheléssel, ahol gond ha csúcson van.

Az automatizált része jól hangzik. Meg persze költség szempont is van, abszolút lehet olyan, hogy kisebb megbízhatóság kell és majd inkább várakozik az ügyfél folyamat egy erőforrás felszabadulásra, így igény-tüskéket egymás mellé tömve a kihasználtságban.