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!

Azért ezt sokszor erős mítosznak érzem. Egy fejlesztő 150-300k-s éves béréből ugyanennyi megtakarítást lazán tud hozni ott, ahol ennyit keres, így már az első évben megtérül.

Azt látom, hogy ezek erősen ciklikus dolgok. Van ez az "olcsóbb a cloud, mint az ember" mentalitás, aztán amikor mindenki rászokik erre a kultúrára, és hirtelen nagyon durván elszaladnak a költségek, akkor jön a menedzsment, hogy "úristen, very big", azonnal csinálj valamit, és beindul a kapkodás.

Minden attól függ. Az egyik véglet amit te írsz. A másik véglet meg, az álljunk át még x86-ról ARM-ra is, mert az olcsóbb. Én ezt látom most a jelenlegi munkahelyemen, és már ott tartunk, hogy nemcsak munkaigényben, hanem konkrétan az átmeneti időszak miatt (sokmindent párhuzamosan mindkettőre kell támogatni, meg tesztelni) a cloud költségben is többet buktunk rajta, mint amennyit nyertünk volna. Elég szofisztikált belső fejlesztésű cost-management toolunk van, amiből kb minden attribútum szerinti bontásban lehet lekérdezni. Persze, lehet, hogy hosszútávon megtérül, de lehet, hogy nem.

A "válasszunk újabb instance type-ot azonos architektúrán belül", valahol a kettő között van. Ha szerencséd van és nem kell vegyes felállást kezelni, vagy nem kell a VPC-idet átszervezni, hogy másik AZ-t tudjál használni, valamint ha nem kell az átmeneti időszak miatt duplán perf tesztelni, akkor sima ügy. Ha mégis, akkor elég nehéz megmondani, hogy hol van az értelmes kompromisszum.

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

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

Kezd beindulni a szekér, kezd fogyni az erőforrás? Az AWS-nél ugyanezt tapasztalom. Fogynak a gépek, főleg a GPU-sok. Pár éve még ritka volt, hogy nem tudtunk gépet indítani, mert nem volt kapacitás, most az a ritka, ha van. :D

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

Bár rossz a grafikon felbontása (hogy néz ki nagyobb felbontáson?), eléggé szabályos görbének tűnik, mintha valami görbére illesztett leszabályozást látnál. Én a helyedben kipróbálnám egyre növekvő konstans loaddal, szerintem esélyes, hogy hasonlót fogsz látni idővel, és a mértékét is ki tudod mérni, mert ez tényleg nem hiperaktív szomszédokra utal.

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

Ahogy nézem a híreket már nem sokáig, legalábbis a teljes költés viszonylatában. :)

Kezd beindulni a szekér, kezd fogyni az erőforrás?

Olyasmi lehet.

Bár rossz a grafikon felbontása (hogy néz ki nagyobb felbontáson?), eléggé szabályos görbének tűnik, mintha valami görbére illesztett leszabályozást látnál.

Szeptemberről ennyi adat maradt, amúgy az oldotta meg, hogy átmozgattam másik DC-be, nem magától javult meg.

Én a helyedben kipróbálnám egyre növekvő konstans loaddal, szerintem esélyes, hogy hasonlót fogsz látni idővel, és a mértékét is ki tudod mérni, mert ez tényleg nem hiperaktív szomszédokra utal.

A workload konstans, időnként tüskékkel, az ilyen erőforráscsökkenés meg kisebb-nagyobb idő és kisebb-nagyobb beszakadással attól függetlenül jön. Még mindig az a tippem, hogy egy host-ra mozgatnak túl sok VPS-t, mert úgy olcsóbb nekik és aki átmozgatja, az jobban jár, de azok a kevesek (DC közötti mozgás IP cím váltással jár, nem mindenkinek jó az).

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.

Koszi, megnezem hogy van-e ilyenre rahatasom.

Az EKS clusterjeinkben ASG-k kezelik az EC2 instance-okat 3 AZ-n keresztul. OnD eseten szepen egyenletesen kerjuk/kapjuk a VM-eket. Latszik, hogy Spot esetben is arra torekszik, de van ugy hogy egy AZ-n belulrol kapjuk az osszes Spotot. Namarmost ha enforce-olom a Spread placement strategiat, akkor szerintem azzal csak azt ernem el, hogy kevesebb Spotot kapok, mert tovabb probalkozik a kiurult AZ-bol szerezni Spotot.

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.

( kukukk v | 2024. 10. 29., k – 08:51 )

OVH-val mi a helyzet? Nekik is elég tág palettájuk van már cloud szolgáltatások terén.

A többi DC fizikailag közel lévő DC-t jelent (amelyek ha jól emlékszem, szintén veszélyben voltak), vagy szét van szórva a control plane több, messzebb lévő helyre, esetleg több clusterrel dolgozol?

Ha utóbbiak, érdekelnének a részletek, tapasztalatok, megosztanád esetleg?

Három kontinensen vannak a DC-k, a control plane is szét van szórva több helyre, az etcd ugyan nyünnyög időnként, hogy több mint 100ms a roundtrip, de más bajt nem vettem észre, évek óta így megy. Egy-egy DC más-más olcsó VPS szolgáltatónál van, szóval ha bármelyik letérdel, az nem okoz különösebb kiesést. És olcsó.

https://iotguru.cloud

Köszönöm!

A control plane-t mivel menedzseled? IaC? Hány node? mTLS van köztük, vagy valami VPN? Hálózati partíciókkal nem szívtál még?

A worker node-ok kezelésére (auto scaling, cluster be/ki, hibásak kivétele stb) mit használsz? Milyen networking megoldás van közöttük?

Ingress?

A control plane-t mivel menedzseled? IaC? Hány node? mTLS van köztük, vagy valami VPN? Hálózati partíciókkal nem szívtál még?

A control plane fix (és a worker node is többnyire), mert a workload, amire használom, nem igényel gyakran scaling-et. Öt control plane node van, VPN-en beszélnek.

A worker node-ok kezelésére (auto scaling, cluster be/ki, hibásak kivétele stb) mit használsz? Milyen networking megoldás van közöttük?

Stabil a workload, szóval nincs automatikus scaling, arra inkább felhőt használnék. A networking az Calico, az ingress meg nginx és az felett pedig Amazon Route53 health check alapon.

Olcsó, most a cluster áll: ~50 vCPU, 150 GB memóra, 4TB SSD storage havi ~120 dollárért.

https://iotguru.cloud

ez az iotguru vagy a cives jatek?

Aham, meg pár hobbiprojekt, mint a https://mav-stat.info meg például a https://toolsboox.com/ vagy a https://egysoros.com/. Meg ezen játszok, ha valamit ki akarok próbálni, illetve ezen tudok demózni, ha cégeknek be akarom mutatni vagy meg akarom tanítani a Kubernetes alapjait. :)

https://iotguru.cloud

A storage (gondolom kell perzisztens) micsoda? Helyi, valami elosztott/közösen használt, migrálod őket, ha költözteted a node-ot stb?

Az adatok nagy része Cassandra, a maradék storage igény meg történelmi okokból GlusterFS, ezekkel viszonylag egyszerű a költözés, mert hozzácsapom az új node-ot, aztán hagyok időt, amíg rendezik a soraikat és utána a régi node kivehető, aztán újra rendezik a soraikat. Igazából zero-administration.

Amire nekem kell, arra jó, a Rook és társai kicsit overkill ahhoz, ami nálam van. De raktam már össze cluster-t ezekkel is.

https://iotguru.cloud

Egyrészt annyira nem számít a performance, hogy áttérjek, másrészt a Cassandra a Scylla előtt jár pár feature kapcsán (a Scylla inkább Cassandra 3.x drop-in és az új feature az leginkább Enterprise pénzes ágban van), és a Scylla több dolgot is eldobott a performance oltárán, például a LWT ACID támogatást multiple partition esetén vagy a UDF - user defined function "stored procedure" - lehetőségét, bár kezdték behozni experimental feature formájában, de nyilván nem Java function.

Szóval szerintem a Scylla akkor éri meg, ha az embernek van egy kurva nagy cluster, amit alap szinten használ és DataStax - Scylla az összevetés, nem community - community, de látszólag akkor se mindig éri meg, mert sok-sok cég nem tért át.

https://iotguru.cloud

( n.balazs v | 2024. 10. 29., k – 19:55 )

Szép és hasznos munka. Gratulálok hozzá!