Papíron a Graviton4 elég jó számokat produkál. Ti használjátok saját fejlesztésű applikációk esetén? Mik a tapasztalatok vele?
Elsősorban nem az érdekel, hogy egy managed service esetén g-s instance type-ot választotok-e, mert ott mindegy, transzparens számunkra. Inkább az érdekelne, hogy az ARM-re váltás extra effortja megéri-e (multi-arch container image, többféle ECS/EKS node-ok, ilyesmik) a cloudban.
Futottatok bele ARM specifikus (compiler) bugba? Okoz bármi nehézséget debugolás során (nyilván x86-on fejlesztünk)?
Webes/microservice applikációk esetén mérhető tényleges gyorsulás vagy csak költségcsökkentésre jó?
Graviton Spot instance-okat mennyire gyakran veszik vissza/rotálják?
Köszönöm.
- 1062 megtekintés
Hozzászólások
Pár napja néztem, de alapvetően nem lelkesedtem fel, szóval én is várom a tapasztalatokat. Egy ügyfélnél merült volna fel még, de ott aztán Azure lett végül...
- A hozzászóláshoz be kell jelentkezni
Mi miatt nem vonzo? Mitol tartottal?
- A hozzászóláshoz be kell jelentkezni
Kevés cuccom van AWS-ben és jelenleg aktív ügyfél cucca sincs ott, szóval kipróbálni nem tudom, projektem nincs rá, a saját cuccomat meg nem éri meg migrálni csak azért, hogy lássam.
- A hozzászóláshoz be kell jelentkezni
Korábbi helyemen csináltunk ilyet.
A CPU teljesítmény kb egy szinten volt a mi workloadjaink esetén mint az x86-os esetben. Mivel a Graviton még az AMD-nél is olcsóbb volt, így hatékonyságban az volt a legjobb.
Mi nem futottunk bele egy ARM64 specifikus bugba sem azokkal a containerekkel amiket migráltunk.
A legnagyobb szívás egy olyan 3rd party kóddal volt amit már nem fejlesztettek, mi is épp kivezettük, de egy fél évig még életben kellett tartani és DaemonSet-ként futott minden node-on. Ehhez kellett saját build container és pipeline. A saját cuccokat a fejlesztő csapatok migrálták (volna), ők azt mondták hogy csak bebökték hogy kérnek ARM64 image-et is és kész is volt.
A Kubernetes clusterben minden node-on volt egy CPU architektúra label és emellett a Graviton instance-okon egy Taint is hogy a még nem migrált containerek ne kerüljenek oda. Így egy Deployment preferálhatott Graviton instance-t (affinity), illetve jelezhette hogy azokon is el tud futni (toleration). Nem volt bonyolult.
Végül nem lett teljes migráció mert... nem tudom. A management minden magyarázat nélkül dobta az egészet. Ez egy ilyen szakma...
A spot instance-ok kilövési rátáját meg tudod nézni a https://aws.amazon.com/ec2/spot/instance-advisor/ oldalon. Függ a régiótól és a konkrét instance type-tól is.
Összességében ha nem túl nagy az effort akkor megéri váltani mert olcsóbb és hatékonyabb, de csodát azért ne várj. Mi egy olyan max 10%-os megtakarítást számoltunk az EC2 költségen.
- A hozzászóláshoz be kell jelentkezni
Koszi az infot.
Graviton4 2024-ben debutalt, akkor Ti meg a korabbi generaciot hasznaltatok? Graviton4 eseten igernek jelentos performance elonyt x86-hoz es korabbi Gravitonhoz kepest. Mondjuk egy picit dragabb is lett.
AMD-nél is olcsóbb volt
Just FYI, a 7.gen instance-oknal az Intel mar olcsobb az AMD-nel, ergo AMD a legdragabb mar.
Az meg hatra van, hogy leellenorizzem, hogy minden (nem altalunk buildelt) image-hez van-e arm64 varians.
Az a gondom, hogy ha nem sikerul mindennel valtani, akkor maradnia kell x86-os nodegroupoknak is, tehat (hiaba olcsobb a Graviton) tobb node-nak kell futnia, ami nyilvan tobbe kerul osszessegeben.
Az jol mukodik Deployment vagy DaemonSet eseten, hogy multi-arch image eseten automatikusan a megfelelot hasznalja? Tehat egy Deploymenten belul vegyesen fut x db. amd64-es es y db. arm64-es Pod.
- A hozzászóláshoz be kell jelentkezni
Igen, talán még Graviton2 volt, lehet hogy már 3. Akkor még az 5. gen instance-okat használtunk x86-ra, ott még az AMD volt olcsóbb. Változik a világ.
Teljesen jól megy egy Deploymenten vagy DaemonSeten belül a multi-arch. Az instance a saját platformjának megfelelő image-et rángatja le a registry-ből.
Ki kell számolni hogy nálatok konkrétan megéri-e a teljes vagy részleges váltás és hogy ezt milyen ütemben lehet és érdemes kivitelezni.
- A hozzászóláshoz be kell jelentkezni
Én pl nem x64-en fejlesztek hanem arm-on (konkrétan M1).
Nem AWS-en hanem heztnernél futottam bele olyanba hogy asszem openebs (de lehet rosszul emlékszem) valami image-e nem volt meg arm-ra és csak néztem bután hogy egy architektúra váltás után (nyilván terraform) nem indul el a storage. Lett emiatt aztán longhorn, az megy.
Szóval ilyesmikbe lehet belefutni hogy egy image vagy egy library nincs meg arm-ra.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Nekünk eddig a munkahelyemen bevált, sok microservice át lett állítva graviton-ra. A legtöbb baj abból van, hogy ha jól számolom 22 régióban vagyunk kinn, mindegyikben legalább 3 availability-zone-ban. Graviton 4 (m8g, r8g) nagyon kevésben érhető el. Sőt akad két-három régió, ahol a Graviton 3 (m7g, r7g) sincs, vagy nem mindegyik AZ-ben van. Szóval pillanatnyilag 3 generációt kell párhuzamosan támogatni... És perf tesztben, meg méretezésben az m6g-től m8g-ig elég széles spektrumról beszélünk.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Koszi, erre nem is gondoltam, akkor ezt is ellenoriznem kell.
- A hozzászóláshoz be kell jelentkezni
Ugyanazon arm64 container image-et hasznaltok graviton 2-4-re? Nem buildeltek maskeppen hogy kihasznaljatok az uj proci ujdonsagait?
- A hozzászóláshoz be kell jelentkezni
Egyelőre nem merült fel, hogy külön image legyen. Elég szopás az x86-64 és arm64 párhuzamos támogatása is, ráadásul folyamatban van az AL2->AL2023 EC2 base image átállás is.
Ami service-ekhez eddig közöm volt (főleg go, python és java) nem használtak ARMv8.2-nél újabb feature set-et, a többség default ARMv8A. (Amúgy pl egy upstreamből származó go binárisnál nem is olyan egyszerű kideríteni, hogy melyik target-re lett fordítva...) Valószínűleg volna potenciál finomabb feature level-re beállított buildelésben, de amíg legalább a graviton2 (armv8.2)-től nem tudunk megszabadulni, addig nem hiszem, hogy nagyon érdemes volna rámozdulni.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Ugy latom a go nem is tud specifikusan ra forditani: https://go.dev/wiki/GoArm#supported-architectures
- A hozzászóláshoz be kell jelentkezni
Deep rabbithole: https://github.com/golang/go/issues/60905
Amúgy itt már le van dokumentálva a GOARM64 környezeti változó is, ami a fentebbi oldalról hiányzik: https://go.dev/wiki/MinimumRequirements#arm64
Nem véletlen, hogy úgy voltam vele, hogy egyelőre jobb, ha félretesszük ezt a problémát.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Most ezzel probalkozunk:
GOAMD64=v3 # ez AWS 5. gen es folotte
GOARM64=v9.0,lse,crypto # kifejezetten Graviton 4-re
- A hozzászóláshoz be kell jelentkezni
nem feltétlenül mérvadó: java-val (hosszú) évek óta használunk arm-os gépeket (db és app-szerverként is), a verziójuk idő- és az-függő (4-es még nincs). semmi hátrányát nem láttuk és nem futottunk bele (arm-specifikus) bugokba sem
- A hozzászóláshoz be kell jelentkezni
Igaz nem graviton, de hetzner amperone-os nodejait probáltam, még mikor az volt a legolcsóbb, különösebb kompatibilitási gondba nem futottam bele, viszont volt olyan procesem ami videót kódolt át, ott az arm instance kb szögre fele annyi teljesítményt nyújtott mint ugyanabban a méretben az epyc verzió.
- A hozzászóláshoz be kell jelentkezni
Nem vmi hw encodong feature hianyzott az armosbol, ami az epycbe meg benne van?
- A hozzászóláshoz be kell jelentkezni
Nem, sw codec-el mentem (azzal a legjobb a minőség).
- A hozzászóláshoz be kell jelentkezni
Perf. tesztek: https://www.phoronix.com/review/aws-graviton4-benchmarks
- A hozzászóláshoz be kell jelentkezni
This 30% generational improvement allowed Graviton4 to come out about 5% faster overall than the Intel Xeon R7i instance. The AMD EPYC instance was still the fastest overall with around 25% greater performance overall, but when diving down into the specific benchmarks/workloads that outcome can vary.
Hjam, ha nincs architektúra függőség, akkor az ár/teljesítmény dönthet, ha ARM kell, akkor érdemes G4-et választani.
- A hozzászóláshoz be kell jelentkezni
A sparecores.com-on az összes instance (AWS, GCP, Azure, Hetzner(cloud), UpCloud) mért adatai összehasonlíthatók.
A Phoronix cikkben említettek pld. itt.
- A hozzászóláshoz be kell jelentkezni
Amikor Gravitont teszteltek, akkor ujraforditjatok az appot az architekturara optimalizaltan? Vagy stock arm64 binarisokkal teszteltek?
- A hozzászóláshoz be kell jelentkezni
Utóbbi (ahogy x86-nál is).
- A hozzászóláshoz be kell jelentkezni
Az ARM sokat fejlodott az evek alatt: https://developer.arm.com/documentation/102378/0201/Armv8-x-and-Armv9-x…
Wikipediarol osszeszedve:
- Graviton(1): ARMv8-A ISA including Neon, crc, crypto
- Graviton2: ARMv8.2-A ISA including 2×128 bit Neon, LSE, fp16, rcpc, dotprod, crypto
- Graviton3: ARMv8.4-A ISA including 4×128 bit Neon, 2×256 bit SVE, LSE, rng, bf16, int8, crypto
- Graviton4: ARMv9.0-A (=8.5) ISA plus the SVE2-crypto extension
Szoval sajat appok eseten (amit igyis-ugyis buildelni kell) mindenkepp erdemes kihasznalni az ujdonsagokat. A napokban neztem, Graviton4 sok regioban es AZ-ben elerheto, talan nem jelent nagy rizikot, ha Graviton4-re buildelunk mar.
- A hozzászóláshoz be kell jelentkezni
Milyen saját alkalmazásod van, milyen nyelvben, ami profitálhat ebből? Mérted esetleg, hogy mennyit hoz?
- A hozzászóláshoz be kell jelentkezni
Van jonehany (10+) Go nyelven irt microservice-unk. Folyamatban van a meres, csak nem egyszeru, mert szinte mind hasznal vmi DB/Mongo/Redis-t mogotte, nyilvan azok okozzak a szuk keresztmetszetet terheles teszt alatt. Valoszinu vmi mockolt valtozaton kellene lemerni.
Csak amiatt kerdeztem, mert lattam, hogy szamoltok kulonfele benchmark pontokat. Ha csak par szazalekot is jelent, lehet hogy masfele billeg a merleg nyelve. Phoronix-ek irjak a gcc parametereit, ebbol gondolom hogy forditjak az applikaciokat, amivel epp tesztelnek. Lehet ez az oka, hogy osszessegeben naluk jobban szerepelt a Graviton4 mint nalatok.
- A hozzászóláshoz be kell jelentkezni