Facebook: képes skálázódni a MySQL
Hosszú idő után először beszélt hivatalos szereplő a Facebook belső rendszeréről, kitérve a tárolók hierarchiájára, illetve a részben saját fejlesztésű, és egészen testre szabott szoftverkörnyezetre is. A cég elégedett, ma is ugyanazt az utat választaná.
Nem igaz, hogy a MySQL nem skálázódik extrém feladatokra - vonhatták le a tanulságot a Facebook vezető mérnökei által tartott előadás végén a hallgatók. Ugyan korábban hosszas vita folyt különféle fórumokon arról, hogy a közösségi szolgáltatás jó lóra tett-e azzal, hogy MySQL-re bízta a felhasználói adatbázis kezelését, a Facebook mérnökei szerint a szoftverrel nincsenek problémák, jól skálázódik extrém terhelésre is - bár ehhez természetesen alaposan bele kellett nyúlni.
Nagyon, nagyon nagy adat
Az előadás bevezetőjében Domas Mituzas, a Facebook egyik adatbázismérnöke sorolta a MySQL-re bízott feladatokat: ez a szoftver kezel minden felhasználói interakciót, lájkokat, megosztásokat, státuszüzeneteket, a bejelöléseket, értesítéseket is. Mindezt 800 millió regisztrált felhasználó mellett, amelyek közül 500 millió minden nap belép az oldalra, 350 millióan pedig legalább ugyanilyen rendszerességgel frissítik is a státuszukat. A feladatot rendkívül összetetté teszi, hogy minden interakció végighullámzik a kapcsolati hálón, amely meghatványozza a rendszer által elvégzendő munkát. Az eredmény 60 millió adatbázis-lekérdezés és négymillió sor megváltoztatása - másodpercenként.
Következő beszélőként Mark Konetchy vette át a szót és bemutatta a Facebook növekedésének valóban megdöbbentő ütemét. Ugyan a jogi osztály a legtöbb információt nem engedi ki, annyit azért lehet tudni, hogy a szerverek száma két év alatt megháromszorozódott, a nyers felhasználói adat mennyisége pedig meghétszereződött. A replikációt és gyorsítótárazást is beleszámolva a Facebook által kezelt adatmennyiség két év alatt hússzorosára emelkedett. Ilyen ütemű növekedés kezeléséhez növelni kellett a csomópontonkénti kapacitást, amely így ötszörösére nőtt, a maximális kezelhető dataset pedig kiszolgálónként tízszeresére nőtt.
Az összes adatmennyiség titkos információnak számít, azt azonban tudni lehet, hogy a kapacitás 55 százaléka mechanikus merevlemezeken, 20 százaléka pedig SSD-n található, a maradékért pedig a HDD-SSD hibridek létrehozását lehetővé tévő Flashcache technológia felel. Ez utóbbit a Facebook saját használatára fejlesztette ki, majd nyílt forráskódúvá tette. A szoftver segítségével operációs rendszer szintjén köthetőek hibrid rendszerbe a különálló SSD és HDD egységek - ez a megoldás az SSD-k sebességének és a HDD-k kapacitásának jó kombinációját adja. A megközelítés egyébként a fogyasztói oldalon is egyre nagyobb teret hódít, a Seagate Momentus XT és az Intel Smart Response Techology is hasonló elvre épül. A gyorsítótárazást a Flashcache mellett a már jól ismert memcached is segíti, a két szoftver és az SSD-k együttműködése annyira kiforrott mára, hogy a Facebook szerint a lekérdezések több mint 90 százalékát gyorsítótárból tudják kiszolgálni.
A fejlesztés következő lépésében a Facebook a terhelés kiegyenlítésére koncentrál a kiszolgálók között, így automatikus mechanizmus fogja a sűrűbben használt adategységeket az alacsony kihasználtságú csomópontokra mozgatni. Másik irány a MySQL által használt tömörítés optimalizálása lesz, amellyel rengeteg tárhely megspórolható középtávon. Hosszútávú terv a strukturálatlan adatok fokozatos migrálása lesz a Hadoop-alapú HBase-be, a Facebook Messages már ezt a szoftverkörnyezetet használja, a közösségi oldal korábbi szolgáltatásai azonban MySQL-t alkalmaznak ott is, ahol ez kevésbé hatékony.
Zártat ne
Mark Callaghan magyarázata szerint a Facebook számára sosem volt kérdéses, hogy az infrastruktúrát nyílt forráskódú szoftverek felhasználásával kell felépítenie - az általa felsorakoztatott érvek pedig különös hangsúllyal esnek latba, ugyanis több mint 8 évig dolgozott az Oracle műszaki csapatának egyik vezetőjeként. A nyílt forráskód melletti legfontosabb érv, hogy a közösségi oldal robbanásszerű növekedésével a zárt szoftverek fejlődése egyszerűen nem lett volna képes lépést tartani - a frissítések, foltozások és új verziók túl lassan jönnek ki a tulajdonosi szoftverekből, így a Facebook kénytelen volt saját kezébe venni az infrastruktúrájának fejlesztését.
Ugyanez a lassúság jellemző az általános terméktámogatásra is, a felmerülő gondokat a saját mérnökcsapat órákon belül meg tudja oldani, míg a kereskedelmi támogatás sokszor napokig ül a problémán, mondja Callaghan. A zárt szoftverek teljesítménye érdekesebb kérdés, Callaghan szerint a Facebook meghívta a nagy szoftvercégeket a termékeik nyilvános tesztelésére, ezt azonban egyikük sem vállalta.
A zárt szoftverek elleni második érv a magas licencelési költségek volt. Ugyan a nyílt forráskódú rendszerek fenntartásához több mérnökre van szükség, a Facebook által használt több százezer szervernél azonban egyértelműen olcsóbb a mérnököket fizetni mint a szoftvereket. A Facebooknak így egész egyszerűen jobban megéri a MySQL és a hozzá kapcsolódó egyéb szoftverek házon belüli fejlesztése és adaptálása, mint a hasonló, a kívánt képességekkel már rendelkező szoftverek megvásárlása. A koncepció nagyban emlékeztet a Google hozzáállására, a keresőóriás az első perctől nyílt forráskódú szoftvereket használt, amelyet saját fejlesztésű eszközökkel egészített ki.
Az IT munkaerőpiac kilábalása állandó délibáb lett Túl sok, számos esetben ellentétes hatás éri az IT munkaerőpiacot, a kínálati piac a béreket, a költséges AI pedig a headcountot eszi.
A Facebook képviselői szerint ezzel az alternatívák száma nagyon leszűkült, a döntéskor elérhető kompetenciák nyomán pedig a választás a MySQL-re esett. Callaghan szerint a kérdés soha nem az volt, hogy a MySQL alkalmas lesz-e a megkövetelt feladat elvégzésére, inkább az, hogy mennyi munkát kell belefektetni ahhoz, hogy alkalmassá tegyék rá. Az előadás szerint sokat, a Facebook szerint azonban erre szükség volt, az alternatív nyílt forráskódú szoftverek ugyanis nem eléggé érettek és megbízhatóak a Facebook-szintű feladatok elvégzéséhez. Ez elsősorban a NoSQL adatbázis-kezelőre vonatkozott, amelynek egyelőre nincsenek a Facebookkal összemérhető referenciaként használható implementációi.
Az alternatív adatbázis-kezelők ellen szólt az is, hogy a strukturálatlan adatok kezelését a közösségi oldalnál a HBase végzi - Callaghan szerint a Facebook jóval több HBase-mérnököt alkalmaz, mint MySQL-gurut. Ennek az az oka, hogy a HBase (Hadoop) finomhangolása jóval több időt igényel, mint a MySQL-é. A skálázódás problémájára visszatérve Callaghan kijelentette, hogy a MySQL képes elvégezni gyakorlatilag bármekkora feladatot, a szoftver alkalmas extrém terhelésekhez való adaptációra is. A Facebook megoldása az adatbázis szilánkokra ("shard") bontása volt, így több ezer párhuzamos ilyen szilánk fut egyszerre. Ez, a korábban említett komplex adathierarchiával együtt képes kiszolgálni akár néhány százmillió felhasználót is egyszerre.
A teljes, mintegy másfél órás előadás itt nézhető meg: