Szerző: Gálffy Csaba

2013. július 12. 13:16

RAMPconf: tanulságok a növekedésről

Számtalan jótanáccsal látták el a ma is zajló RAMPconf konferencia résztvevőit a skálázódó rendszerek veteránjai. A nagy terhelésre tervezett online szolgáltatások építésénél néhány vezérelvre érdemes figyelni - ezeket gyűjtöttük össze.

Egyetlen órában összefoglalta a skálázódó rendszerek problémáit és azok implikációit a RAMPconf keynote-előadója, Theo Schlossnagle. A gondolatmenete világosan követhető: az új, magas komplexitású skálázódó rendszerek olyan kihívások elé állították a hagyományos szoftverházakat, amelyeknek ezek nem tudtak megfelelni (átláthatóság, gyors fejlesztési tempó, közvetlen támogatás). Ez a kényszer szülte a közösségi támogatással rendelkező szabad szoftveres ökoszisztémát, amely ma a nagy rendszerek elsöprő többségénél dolgozik.

Az eredeti dilemma - fejlessz magadnak vagy vegyél mástól - így egy harmadik alternatívával gazdagodott, ez a vedd át más szabad szoftveres megoldását. Míg a fejlesztés drága, lassú, és nehezen fenntartható, a vásárlással pedig feladjuk a hozzáférést a kódhoz, a fejlesztés irányához, a harmadik út, az adoptálás kombinálja a saját fejlesztés átláthatóságát és a külső fejlesztés/támogatás megbízhatóságát és olcsóságát - persze csak olyan esetekben, amikor van olyan minőségi szoftver, amit lehet adoptálni.

A szabad szoftverre Schlossnagle szerint azért is szükség van, mert a modern skálázódó rendszerek elemei között nincsenek merev határok, a potenciális problémák átívelnek az egyes részelemeken. Emiatt szükséges, hogy a rendszer építői-fejlesztői-működtetői átlássák a teljes architektúrát, akár a felhasznált kód szintjén is - erre a vásárolt szoftver esetében nincs lehetőség.

Az egyszerűség gyönyörködtet

A webes skálázódó rendszerek közös dilemmája a scale-up vagy scale-out, vagyis hogy a nagyobb terhelést erősebb hardverrel, vagy több hardverrel érdemes-e inkább megoldani. A RAMPconf előadói szerint rövid távon az erősebb gépekkel ideig-óráig meg lehet oldani a terhelés problémáit, de egy bizonyos határon túl muszáj nagy elosztott rendszereket használni, vagyis nagyon sok, egyszerű és olcsó gépre bízni a feladatok párhuzamos kiszolgálását. Ennek a lépésnek azonban súlyos ára van, a rendszer komplexitása az egekbe szökik, a szükséges kompetenciák pedig hirtelen meghaladják az egyszeri üzemeltető komfortzónáját.

A szemléletváltást jól érzékelteti a pet ("házikedvenc") és cattle ("ipari marha") példája. Az első megközelítésben a szerver saját nevet kap, egyedi, kézzel konfigurált és egyedileg felügyelt, ha "beteg" lesz, akkor vigyázó ápolással "gyógyítjuk meg". Ezzel szemben a cattle-szerver sorozatszámot kap, konfigurációja azonos legtöbb társával és ha problémássá válik, akkor egyszerűen lecserélhető. A megközelítés kiterjeszthető egészen a stateless kiszolgálókig, amelyek előrekonfigurált módon, saját adat őrzése nélkül végzik a feladatukat, kiesésük a rendszer szempontjából megengedhető.

A megközelítés azt diktálja, hogy az ötletes, a céget valóban megkülönböztető, versenyelőnyt nyújtó mérnöki fogásokat azokon a területeken koncentráljuk, amelyek a központi kompetenciához, az alkalmazáshoz a legszorosabban kapcsolódnak, mindenhol máshol igyekezzünk a "default", alapbeállításoknál maradni. Ez megkönnyíti később az új technológiák bevezetését, amelyeket így nem kell hosszú tesztelésnek és integrációnak alávetni, az ismert környezetek könnyebben párosíthatóak, ha pedig problémába futunk, akkor biztosak lehetünk benne, hogy nem nálunk van a hiba. A komplexitás megfojtja a fürgeséget - mondta Dathan Pattishall is, aki számos cég, köztük a Flickr skálázódási problémáit orvosolta karrierje során.

Ahol kell és jó a testreszabás

Néhány gyönyörű példát mutatott a megengedhető és kívánatos optimalizációkra Anka Márton, a LogMeIn alapítója és korábbi műszaki vezetője. A szolgáltatás egyik kulcseleme a nagyszámú bejövő és kimenő kapcsolat hatékony kezelése. Ezt a korai időszakban úgy kezelte az infrastruktúra, hogy minden kapcsolat egy új szálat kapott a processzoron, ez azonban óriási többletterhelést eredményez, és pusztán a szálak közötti kontextusváltás képes leterhelni egy kétmagos processzort néhány ezer kapcsolat esetén. A megoldás az IOCP (IO connection port) bevezetése volt, amely jóval kevesebb threadet használ, így egy-egy gép sokkal nagyobb, akár tízszeres kapcsolatszámmal is elbírt.

Jöhet a malware-cunami az iPhone-okra?

Nyílik az iOS, de tényleg annyira veszélyes ez? Annyira azért nem kell félni, elég sok kontroll van még az Apple-nél.

Jöhet a malware-cunami az iPhone-okra? Nyílik az iOS, de tényleg annyira veszélyes ez? Annyira azért nem kell félni, elég sok kontroll van még az Apple-nél.

Hasonló példa, hogy az alapbeállítások módosításával sikerült egy-egy biztonságos kapcsolat memóriaigényét 96 kilobájtról 20 kilobájtra leszorítani. Ez nem hangzik túl nagynak, de egymillió kapcsolat esetén már 72 gigabájt memóriamegtakarítást hoz, ez még ma sem filléres tétel, néhány évvel ezelőtt, a módosítás bevezetésekor pedig még nagyobb hatása volt. Ezek a módosítások ugyan nem a LogMeIn alkalmazáshoz kötődnek, a cég központi kompetenciájához, a nagyszámú folyamatos kapcsolat kezeléséhez azonban igen.

Naplózz mindent és építs profilt

A gyors növekedésben lazán összedrótozott rendszerekben viszonylag sűrűek a problémák, ha jól tervezett az architektúra, akkor ez a felhasználó számára láthatatlan marad, leálláshoz nem vezet. Ettől függetlenül érdemes minden, a rendszer működését leíró adatot naplózni, a szokatlanul lassú futástól a részelemek leállásáig. És pontosan milyen paramétereket érdemes naplózni? Az összeset - mondta Rajiv Eranki, a Dropbox skálázási erőfeszítéseit vezető mérnök. Korábban voltak próbálkozások cégen belül arra, hogy korlátozzák az összegyűjtött adat mennyiségét, de minden ilyen próbálkozás ahhoz vezetett, hogy később hasznos információk hiányoztak, maradt tehát az "ultra verbose logging".

A naplók elemzése mellett fontos információforrást jelent a felhasználói viselkedés folyamatos követése is. Ez egyrészt fontos a szolgáltatás fejlesztése szempontjából (user experience, üzleti szempontok), de a skálázódási kérdések esetében is döntő lehet, a rendszer adoptálható a felhasználók szokásaihoz. Ha például a felhasználók töredéke felelős a terhelés jelentős részéért, a széles tömegek pedig aránylag kisebb forgalmat jelentenek, akkor értelme lehet az infrastruktúra kétfelé optimalizálásnak: a rendszer egy része így a nagyétvágyú (és általában fizetős) felhasználókra szabva, a másik pedig a tömegek kiszolgálására. A megfelelő műszaki döntésekkel mindkét felhasználó csoport jobb élményt kaphat, miközben az infrastruktúra költségei csökkenthetőek.

Végy fel korán!

A legtöbb startup igyekszik minél hosszabban minél alacsonyabban tartani a dolgozók számát. Ez azonban az informatikusok esetén nem túl jó stratégia: az architektúrát alapjaiban meghatározó kezdeti döntések a később csatlakozók számára értelmetlenek lesznek, sem az okokat, sem az implikációkat nem fogják úgy érteni, mint a kezdőcsapat. Érdemes tehát már a kezdetektől nagyobb számú mérnökkel indulni, megtérül a korai befektetés.

A másik, sokszor hangoztatott jótanács a folyamatos tesztelésre vonatkozik. A skálázódó rendszerek komplexek, a támogatás-tesztelés jellemzően a saját csapat feladata, így nem lehet eléggé elővigyázatosnak lenni. Az előadók tapasztalatai szerint hatékony megoldás például, ha az elosztott rendszer gépeit rendszeresen újraindítjuk - ennek nem szabad semmilyen hatással lennie a működésre, viszonyt kikényszeríti a hibatűrés beépítését minden szinten.

A konferencia ma is folytatódik, az exkluzív közvetítés a HWSW oldalán követhető élőben.

Nagyon széles az a skála, amin az állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról