Weblabor

Előbb-utóbb minden sikeres internetes vállalkozás eljut arra a pontra, hogy egy gép már nem bírja el a terhelést, és el kell gondolkozni azon, hogyan is osszuk azt el. Ez nem pusztán a rendszergazda feladata, sokszor el kell gondolkozni az ilyen környezetben futtatandó szoftver alkalmasságán is.

KISS – Az egyszerűbb jobb

A talán leggyakrabban elkövetett hiba amikor az ember kinövi az egy szem gépét, hogy megpróbálja a feladatot internetről összeszedett technológiákkal megoldani. Ezek a technológiák ugyan működnek, de rejtenek olyan buktatókat, amik a szolgáltatás minőségének romlásához vezetnek.

Javaslatom tehát azoknak, akik kinőtték a gépüket, hogy próbálják meg először a meglevő szolgáltatásokat szétszedni, áttenni például az adatbázisszervert egy másik gépre, mielőtt valamilyen cluster technológiához nyúlnak. A cluster technológiák önmaguk is egy bonyolultságnövelő tényező, még egy dolog, ami elromolhat, és jókora tapasztalat nélkül csak csökkentik a rendelkezésre állást, mintsem hogy növelnék.

Tehát: éles környezetben kerüljük az ismeretlen technológiákat, és próbáljunk meg alkalmazások szintjén terhelést bontani.

Az optimalizálás sorrendje

Bár az alapszabály úgy szól, hogy a fejlesztő ideje drágább, mint még egy gép, adott esetben érdemes rászánni néhány munkaórát arra, hogy gördülékenyebben fusson a rendszer. Fontos szempont az optimalizálásnál, hogy föntről lefele haladjon az ember. Fölösleges ugyanis egyből az egész rendszermag átírásába kezdeni, ha tizedannyi energiával sokkal jelentősebb sebességnövekedést lehet elérni a kliens oldal optimalizálásával.

Ha mégis elérkezik az a pillanat, hogy a rendszer magjában van valami, ami a terhelést okozza, nagyon lényeges, hogy ne kezdjen el vaktában optimalizálni senki. Lehet, hogy egy algoritmus nem hatékony, de ha óránként csak egyszer fut le, nem ő a ludas a terhelésben. Egy rossz UI döntés ezzel szemben egészen könnyedén okozhatja a gép beborulását.

Egy pár éve az akkori munkahelyemen a kollégák fejlesztettek egy Flash játékot, és ez a játék nagyon megviselte a szervert. Mivel igen komoly tétje volt a játéknak, a felhasználók egy rontott pályánál azonnal kiléptek, és újból kezdték a játékot. Ez azzal járt, hogy a játék lekérte a szerverről a toplistát. Abban a pillanatban, hogy bekerült a játékba a pálya újrakezdését lehetővé tevő gomb, a szerveren a terhelés töredékére esett vissza.

Tehát: rendszerezetten optimalizáljunk, mérjünk, mielőtt elkezdünk kódolni.

Memóriából kiszolgálni

Biztos mindenki mérgelődött már azon, hogy mennyit „reszeli a diszket” a gép, majd egy memóriabővítés után rácsodálkozott arra, hogy az elvileg semmilyen sebességnövekedéssel nem járó művelet után mennyivel gyorsabb lett. Memóriából kiszolgálni a létező leggyorsabb dolog. Szerencsés esetben memóriából kiszolgálva egy gép akár egy gigabites hálózati interface-t is ki tud hajtani 80-90%-ig.

Ha nem teszünk semmit, akkor is jótékony hatással van a kiszolgálás sebességére a sok üres memória, ugyanis az operációs rendszer a rendelkezésre álló üres memóriába betölti az éppen használt fájlokat. Ez az úgy nevezett file cache.

10 GB file cache egy webkiszolgálón

Az ennél hatékonyabb megoldás úgy működik, hogy az alkalmazás részeit tesszük memóriába. Erre változatos technológiák léteznek (amiket a fent említett játékos példánál is lehetett vona használni, ha akkor rendelkezésre állt volna). A talán legismertebb a NoSQL mozgalom egyik előhírnöke, a memcached. Ha az alkalmazás felkészült arra, hogy bizonyos objektumokat pl. a DAO rétegből memcachedben tároljon, az adatbázishoz hozzá sem kell nyúlni. De hogy ne csak adattárolásról beszéljünk, ha az üzleti logika megengedi, akár az egész nyitólapot, vagy egy bonyolult lekérdezés eredményét (pl. top 10 valami) be lehet tárolni memcachedbe, és csak néhány percenként kell újragenerálni.

Figyelem! Ugyan mostanában divatos NoSQL-ben gondolkozni, érdemes figyelembe venni, hogy egy-két gépen a clusterelt üzemeltetésre kihegyezett szoftverek, mint pl. az Apache Cassandra rosszabb eredményeket fognak produkálni mint az SQL adatbázis! Természetesen ugyanez igaz az elosztott fájlelérést biztosító cluster fájlrendszerekre is.

Tehát: legyen elég szabad memória a filecache-nek, használjunk memória tárolókat.

Háttérfolyamatok futtatása

Sokszor, főként böngészős játékok írásánál, előkerül az a kérdés, hogy hogyan is kell(ene) a kvázi valós idejű vagy háttérben futtatandó feladatokat megvalósítani. Ilyenkor aztán előkerülnek az olyan meredekebbnél meredekebb ötletek, mint például a screenben futtatás vagy a crontabból való indítás. Erre a korrekt és technológiailag védhető megoldás egy úgynevezett daemon írása. A daemon egy olyan alkalmazás, ami lekapcsolódik az őt indító terminálról, és a háttérben fut tovább.

Egy daemont írni nem különösebben nehéz, pusztán néhány alapvető operációsrendszer-közeli dologgal kell megismerkedni. Ebben nagyon nagy segítséget tud nyújtani egy rendszergazda, aki ismeri ezeket a követelményeket, de egy operációs rendszerekről szóló könyv vagy egyetemi jegyzet is csodákra képes. Ha a közelben van egy rendszergazda, akkor érdemes kifaggatni a daemon írását megkönnyítendő azokról az eszközökről, amiket az operációs rendszer egyébként is nyújt (pl. start-stop-daemon).

A daemonoknak van több előnye is, nézzünk egy konkrét példát. Feladat egy olyan daemon írása, ami bármikor ébreszthető, ellenben amikor nem csinál semmit, akkor nem eszik CPU-t. Egyszerű megvalósításként elindítjuk a daemont, ami az ő process ID-ját (PID) leteszi valahova, ahol megtalálja az alkalmazás, majd elteszi magát aludni (sleep). Ha a webes frontend szeretne tőle valamit, elolvassa a PID-et, és küld neki egy SIG_INT-et, aminek hatására a sleep meg fog szakadni, a daemon előre beállított signal handlere pedig lefut, értesülve arról, hogy feladat van.

A fenti feladat még PHP-ban is megvalósítható (pcntl és posix library), bonyolultabb feladatokhoz azonban érdemes körülnézni a Python vagy Perl nyelvekben egy kicsit. Természetesen a téma annál azért bonyolultabb, mintsem hogy egy egyszerű scriptből daemont vagy cron scriptet csináljunk. Ügyelni kell adott esetben arra, hogy ne futhasson több példány egyszerre, a rendszerleállításkor konzisztens maradjon az állapot stb. Ezen problémák ecsetelése azonban egy önálló cikket is kimerítene.

Tehát: attól, hogy van egy kalapácsunk, nem minden szög. Ne szégyeljünk a rendszergazdától kérdezni, és operációs rendszereket vagy új programnyelveket tanulni.

Kérdezzünk a rendszergazdától

Általánosan elterjedt tévhit, hogy a fejlesztők lefejlesztik az alkalmazást, a rendszergazdának pedig az a dolga, hogy megteremtse a működéshez szükséges feltételeket. (És nem azért mert rendszergazda vagyok.)

A projekt sikeressége érdekében érdemes a rendszergazdát bevonni a csapatmunkába. Mivel a fő feladata az, hogy minél több szoftvert és technológiát ismerjen, gyakran olyan megoldásokkal szolgálhat, amik egészen egyszerűvé vagy éppen szükségtelenné tesznek egyébként bonyolult feladatokat. A másik oldalról meg olyan a határidőre káros problémáktól óvhat meg egy nagy terhelésű rendszer fejlesztésénél, amikbe fejlesztőként szinte kötelezően belefutnánk.

Tehát: a rendszergazda mély rendszerismerettel rendelkezik, ezt használjuk ki!

Folytatjuk…

Ez a cikk megpróbált rávilágítani azokra a sarokpontokra, amikbe szinte mindenki belefut. Természetesen a téma ennél bővebb, ezért a sorozat következő részeiben azokkal a technológiákkal és problémakörökkel foglalkozunk, amik a tényleges elosztott működéshez szükségesek.

Köszönöm Tyrael és Kayapo segítségét a cikk összeállításában.