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.
Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.
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: