Hogyan teljesítenek a felhős szerverek terhelés alatt?

Egyéb

Egy ideje már fut a https://sparecores.com oldal, amelyen a felhős erőforrásokat (compute, storage, network) próbáljuk egységes formában, összehasonlíthatóan begyűjteni, illetve lekérdezhetővé tenni. Jelenleg az AWS, Azure, GCP és a Hetzner (cloud) adatai szerepelnek az oldalon.

Az adatbázis nem csak API-okon lekérdezhető adatokból áll, hanem ténylegesen el is indítjuk a gépeket, így azokról olyan információkat is ki tudunk nyerni, amelyeket máshonnan nem lehet beszerezni.

Az adatgyűjtés mellett különféle teljesítményméréseket is végzünk, amelyek szintén bekerülnek a publikált adatok közé, ezeket API-on, adatbázisból, illetve a weben is meg lehet találni.

Nemrég végigmértük a gépek többmagos teljesítményét, illetve azok változását is a terhelés függvényében. Ennek kapcsán született egy cikk, amely azt próbálja körbejárni, hogy milyen hatásokkal kell megküzdenünk, amikor azt szeretnénk tudni, hogyan változik a bérelt erőforrásunk teljesítménye a (többmagos) terhelés függvényében.

A cikk itt érhető el: https://sparecores.com/article/multi-core-scalability

( _Franko_ v | 2024. 10. 28., h – 15:23 )

Izé... eddigi tapasztalataim szerint az a helyzet, hogy a GCP, AWS vagy Azure között úgyis az ökoszisztéma és a cloud engineer szava dönt, a Hetzner meg teljesen más ligában focizik.

Hozzátenném, hogy a Hetzner egy ideig jó volt, de az utóbbi fél évben VPS kapcsán kicsit elkurvultak, amikor csinálsz egy új instance, akkor minden fasza, kiszalad a világból, aztán ~ egy-két hét után azt látod, hogy picsalassú lesz, ilyenkor kérsz másik plan, akkor ismét jó egy jó darabig, aztán megint belassul, szóval az, hogy frissen mit tud, az sajnos jelenleg nem sokat számít... :/

Jó az irány, de a Hetzner mellé kellene leginkább a többi olcsó, mint Vultr, DO, Hostinger, és társai.

https://iotguru.cloud

Izé... eddigi tapasztalataim szerint az a helyzet, hogy a GCP, AWS vagy Azure között úgyis az ökoszisztéma és a cloud engineer szava dönt, a Hetzner meg teljesen más ligában focizik.

Nekem pár hete (hónapja?) már szembe jött, szeretem.

Abban általánosságban véve igazad van, hogy a "nagyok", illetve a "kicsik" közt jellemzően nem úgy döntesz, hogy hol olcsóbb, vagy jobb az ár/teljesítmény (bár pld. nekünk volt egy projektünk, ahol az volt az elvárás, hogy egy queue-ba beledobálhassanak "darálós" jobokat, és azt lehetőleg minél hatékonyabban futtassuk, mindegy, hol), hanem általában már adott, és/vagy az egyéb szolgáltatások/kiépült infra/tudás döntik el.

De ami ebben igazán fasza, az az, hogy ha AWS-only vagy, ott is össze tudod hasonlítani a gépeket. Az egyik ügyfelünknél (AWS) pld. azt látjuk, hogy amikor instance-ot kell választaniuk, megnézik a vCPU/memóriát (nekik kb. ez számít), és mivel mindig is azt használták, beállítják a c/m5-öt, miközben az adott terhelésre (memória/CPU load) bőven lenne jobb instance is.
A cloudban is megvannak a "maradiak", akik TF-mal felhúzzák az infrát, aztán ott rohad évekig a pazarló instance, nagyívben tesznek rá, hogy túllőttek a méretezésnél, vagy feleslegesen drágát raktak be. 

Sokszor a cikkben előhozott dolgokkal sincsenek tisztában, és halál komolyan képesek azt mondani ott dolgozó arcok, hogy ha 16 vCPU-d van, akkor 16 CPU-d van.

Na nekik be lehet dobni egy ilyen oldalt, és el lehet magyarázni, hogy mit is látnak:

https://sparecores.com/compare?instances=W3sidmVuZG9yIjoiYXdzIiwic2Vydm…

Szerintem kurva hasznos.

Ezeknek a "régi instance-on ragadásoknak" gyakori praktikus oka, hogy az újabb instance type nem minden régióban és AZ-ben érhető el. Kellemetlen, amikor a VPC-d fel van setupolva mondjuk régiónként 2-3 AZ-ra (nagyobb régiókban van összesen mondjuk 6 AZ), és abból 1 vagy 2-n hiányzik az újabb type. Ilyenkor agyrém tud lenni, hogy az IaC-ban megoldjad és karbantartsd a kivételeket. Másrészt az instance-onkénti teljesítmény így elég eltérő lehet, ami egy ALB mögött elég kellemetlen tud lenni. Vagy mondjuk az alkalmazásodat perf teszteled az újabb instance type-on, de 1-2 régióban még a régi van (vagy fordítva).

Nyilván az m5/c5-re ma már nincs mentség, de mondjuk pl ARM oldalon r7g/m7g/c7g még mindig nincs mindenütt, és közben már van m8g/r8g/c8g is 1-2 régióban.

Aztán persze úgymarad, mert nem nézegeted minden hónapban, hogy megjött-e már az új instance oda ahova kéne.

Régóta vágyok én, az androidok mezonkincsére már!

Ilyenkor agyrém tud lenni, hogy az IaC-ban megoldjad és karbantartsd a kivételeket.

Preferencia lista? Ha A nincs, akkor B, ha az sincs, akkor C, stb.

Nem feltétlenül azért hasal el a provisioning, mert az adott AZ nem támogtja az adott instance típust, simán lehet, hogy pillanatnyilag nem tud olyat felajánlani.

Az szerintem kicsit más kérdés, hogy pillanatnyilag van-e kapacitás, én konkrétan csak arról az esetről beszélek, amikor az adott AZ-ben egyáltalán nem elérhető az instance type. Különösen az újabbaknál van egy elég hosszú (akár több, mint 1 éves) átmeneti időszak, amíg fokozatosan telepítik az új hardvert. És sokszor nem az összes AZ kapja meg, főleg az egzotikusabb fajtákat.

A preferencia lista pontosan azért problémás, amit fentebb írtam. Ha pl egy ALB mögé inhomogén instance-okat raksz, akkor weighted target groupokkal kell megoldanod, hogy kb képességeiknek megfelelő mennyiségű terhelést kapjanak. Nem mondom, hogy lehetetlen, de megint egy extra bonyolítás, amit finomhangolni, teljesítménytesztelni kell stb. Sokszor egy sima homogén ASG scaling policy jól beállítása is sok iterációból áll.

A másik, hogy általában ha teljesítménytesztelned kell az alkalmazást, akkor melyikkel menjen a teszt? Mindig a legrégebbi instance type-pal, ami bárhol előfordulhat? Vagy mindegyikkel? Mikor mondhatod az ügyfélnek (ha mondjuk kell capacity statement-et adni), hogy nőtt a kapacitás, csak ha már mindenhonnan kikopott a régi?

Szóval a lényeg, hogy mindent meg lehet oldani, csak elég gyorsan nő a ráfordítandó munkamennyiség, és megérthető hogy egy idő után sokan hagyják a fenébe.

Régóta vágyok én, az androidok mezonkincsére már!

Ilyenkor agyrém tud lenni, hogy az IaC-ban megoldjad és karbantartsd a kivételeket

Terraformban ez nekem is fájna, de Pulumival seperc alatt megoldanám.
Amikor létre kell hoznom az instance-ot, megnézem, hogy adott régióban milyen instance-ok elérhetők, és keresnék a Spare Cores adatbázisban egy olyat, ami kielégíti a referenciafeltételeket (CPU/memória/CPU teljesítmény). :D

(ez nyilván nem segít azon, ha kapacitáshiány van, sajnos azt univerzálisan nem lehet előre lekérdezni, arra esetleg valami fallback mechanizmust lehet hákolni a korábbi adatokból)

ARM oldalon r7g/m7g/c7g még mindig nincs mindenütt, és közben már van m8g/r8g/c8g is 1-2 régióban

Ezt is mutatjuk :)

https://sparecores.com/server/aws/c7g.2xlarge, https://sparecores.com/server/aws/c8g.2xlarge

Aztán persze úgymarad, mert nem nézegeted minden hónapban, hogy megjött-e már az új instance oda ahova kéne.

Nálunk a gép nézegeti, amint megjelenik egy új instance, és jónak találja, már használja is. (mondjuk aznap :)

De valóban, a mi use-case-ünk speciális.

A Hetznernél shared gépnél tapasztalod ezt, vagy dedicatednél? Ha utóbbi, megosztanád melyiknél, esetleg melyik DC-ben?
A picsalassúról van valami kézzelfogható (mi, mennyire)?

Valóban általában egyszer futtatunk egy tesztet (hiszen pénzbe kerül), de amúgy gyűjtünk historikus adatokat is, és gondolkoztunk is hasonlón, de (még) nem jutottunk el idáig.

Napos (24 órás) méréseket már csináltunk, de ezek is egyszeriek voltak egyelőre:

shared x86:
https://github.com/SpareCores/sc-inspector-data/blob/main/data/hcloud/c…
https://github.com/SpareCores/sc-inspector-data/blob/main/data/hcloud/c…

shared arm:
https://github.com/SpareCores/sc-inspector-data/blob/main/data/hcloud/c…

dedicated x86:
https://github.com/SpareCores/sc-inspector-data/blob/main/data/hcloud/c…

Tervezünk még továbbiakat is hozzáadni, de először az AWS/Azure/GCP-t szerettük volna látni, mert mi is ezeket használjuk leginkább (eleve az ötlet egy belső projektből jött, ahol batch jobokra keressük meg mindig az épp akkor legolcsóbb/legjobb instance-ot).

A Hetznernél shared gépnél tapasztalod ezt, vagy dedicatednél?

Nyilván shared, dedicated esetén furcsa lenne vCPU overbooking.

A picsalassúról van valami kézzelfogható (mi, mennyire)?

Nagy általánosságban harmada-fele lesz a teljesítmény.

Tervezünk még továbbiakat is hozzáadni, de először az AWS/Azure/GCP-t szerettük volna látni, mert mi is ezeket használjuk leginkább (eleve az ötlet egy belső projektből jött, ahol batch jobokra keressük meg mindig az épp akkor legolcsóbb/legjobb instance-ot).

Az egy igen speciális use-case. :)

https://iotguru.cloud

Nyilván shared, dedicated esetén furcsa lenne vCPU overbooking.

A sharednél ezt azért nem érzem váratlannak. Esetleg a mértéke lehet meglepő, a nagyoknál vsz. a szofisztikáltabb rendszer (CPU kreditek stb) miatt ritkább ilyen durva visszaesés, de nincs vele tapasztalatom.

Dedikált: elolvastad a cikket? :)
Egy AWS c7i-metal teljesítménye kb. 20%-ot ingadozik terhelés függvényében (stress-ng relative multicore performance grafikont nézd), egy GCP c4-highmem-192 még rosszabb, kb. negyedével is visszaeshet a magonkénti teljesítmény.

Ezek dedicated gépek, nincs vCPU overbooking. Van viszont turbo boost, esetleg thermal/current limit a CPU-kon, így az általad látott teljesítmény a szomszédaidtól is függ. Pont, mint a shared instance-oknál. :)

Az egy igen speciális use-case. :)

ML model tréning, 2024-ben nem tűnik annyira speciálisnak, sőt, nekem úgy tűnik, hogy mintha az egész világ erre lenne rágyógyulva mostanában.

A sharednél ezt azért nem érzem váratlannak. Esetleg a mértéke lehet meglepő, a nagyoknál vsz. a szofisztikáltabb rendszer (CPU kreditek stb) miatt ritkább ilyen durva visszaesés, de nincs vele tapasztalatom.

Mivel korábban nem műveltek ilyet, én váratlannak érzem, hogy jelentősebb az overbooking, mint korábban.

Ezek dedicated gépek, nincs vCPU overbooking. Van viszont turbo boost, esetleg thermal/current limit a CPU-kon, így az általad látott teljesítmény a szomszédaidtól is függ. Pont, mint a shared instance-oknál. :)

Hogyne, nyilván, ilyenek vannak, csak nem ez van, hanem az, hogy konstans kapsz egy durvább leskálázást, például egész napra vagy több napon keresztül elveszik több mint egy vCPU: https://imgur.com/a/9hFOPK0

ML model tréning, 2024-ben nem tűnik annyira speciálisnak, sőt, nekem úgy tűnik, hogy mintha az egész világ erre lenne rágyógyulva mostanában.

Hát, divatos, de attól még speciális use-case.

https://iotguru.cloud

( VincentV | 2024. 10. 28., h – 16:35 )

Grat a projecthez, nagyon jó ötlet.

Köszönjük! Szívesen vesszük az ötleteket!

Mint fent írtam, az eredeti problémánk az volt, hogy batch jobokra megtaláljuk a legjobb (a múltbéli futások alapján erőforrásban OK, lehetőleg a legolcsóbb) instance-okat (AWS), de nálunk is sűrűn felmerül, hogy "milyen instance is kellene erre a feladatra", remélhetőleg ebben is segít az oldal.

Mi -ahogy a cikkben is van- spot blocks-szal évekig használtuk, csak aztán megszűnt. :)

Egy ideig próbálkoztunk, de aztán feladtuk, sokszor nem hogy indítani nem tudunk (ezt mondjuk kezeljük, végigmegyünk a listán "jósági" sorrendben), de ha mégis, pár percen belül jön a termination notice, szóval gyakorlatilag használhatatlan.

Nekem is ez a tapasztalatom. 20 percet vársz pending-ben, aztán kapsz 5 perc futási időt. De mondjuk érdekes, hogy a cikketek szerint lehet találni olyan dugi AZ-ket ahol viszonylag nyugiban tud futni (persze amíg fel nem fedezik mások...).

Régóta vágyok én, az androidok mezonkincsére már!

A kozelmultig `m4.large`-okat hasznaltunk spot-kent. Napokig futott folyamatosan. Nemreg valtottunk modernebbre (m5a, m6a, ...), azok tenyleg gyakrabban cserelodnek. Nem is az a gond, hogy orankent vagy naponta cserelodik, hanem az, hogy sokszor egyszerre veszik vissza mindet, igy elofordul hogy a podjaink pendingben varakoznak egy kicsit. Probaljuk ugy beloni az ond/spot aranyt, hogy toleralni tudjuk az ilyeneket. Egyebkent is ez Dev env, nem a Prod.

Najó, de ugye tudnod kell, hogy az adott instance type-ra mondjuk pont az us-west-2c AZ a nyerő, miközben a 2a és 2b szar. Ami ráadásul cloud accountoként változik is, mert kitalálták ezt az "ügyfelenként megpermutáljuk az AZ-ket" c. játékot. (Majd miután kiderült, hogy resource sharing miatt ez mekkora anomáliákat okoz, ezért bevezették az usw2-az1, usw2-az2 stb. jelölést, amit külön lookupolnod kell, hogy neked melyik us-west2X melyik fizikai usw2-azY-nak felel meg...)

Régóta vágyok én, az androidok mezonkincsére már!

Erről is írtunk :)

https://sparecores.com/article/ids-vs-names

Nekem nem kell tudnom semmit. Ha indítani akarunk valamit, megvan, hogy mi kell (mennyi CPU/memória), a gép megnézi, hogy épp mi elérhető az adott régióban, felállítja a toplistát (adott szempontok alapján, pld. ha mindegy, milyen gyorsan fut, lehet lassú és olcsó instance-ot választani, ha gyorsan kell futnia, gyorsakat és olcsókat választ előre), és elkezd végiggyalogolni rajta. Az első sikeres indításnál megvan a delikvensünk, fut a taszk.

Disclaimer: speciális a use-case-ünk.