Riak skálázódás a Kiip-nél: 25M művelet/nap

A Riak egy nyílt forráskódú, jól skálázódó, hibatűrő elosztott adatbázis.

A követkető előadásban Armon Dadgar and Mitchell Hashimoto arról beszél, hogy hogyan és miért kezdték el a Riakot használni a Kiip-nél, milyen problémákat kellett leküzdeniük (növekvő igények - 25M művelet/nap) és milyen megoldásokat találtak rájuk: a MongoDB migrálását Riak-ra. A felvétel 2012. májusában, a San Franciscoban szervezett Riak Meetup-on készült.

Itt az előadás kivonatát olvashatod.

Kiip infrastruktúra

A Kiip egy mobil jutalom (mobil hirdetés) hálózat: az alkalmazásokban lévő virtuális eredmények segítségével kötik össze a márkaneveket és cégeket (hirdetőket) a fogyasztókkal.

A Kiipnél kezdetben MySQL-re építettek, de még azelőtt MongoDB-re váltottak, hogy valódi használat lett volna az oldalukon. A használat során, valamint a forgalom és az adatmennyiség növekedésével a következő problémákkal szembesültek:

• A globális MongoDB írás lock limitálta a beérkező írás műveleteket. A megoldásuk az írási műveletek 10 másodperces aggregálása volt, mivel a batch feldolgozással a lock-művelet ritkábban blokkolt.

• Mivel az olvasási sebességre még mindig limitáltak voltak (1000x olvasás/sec), erős cache-használatot vezettek be.

• Az analitikai lekérdezések túl sok adatot érintettek, az IO-műveletek limitálták a sebességet. Bloom-filter használata egy időre megoldotta ezt a problémát.

• Mivel újra elérték a globális lock limitáló hatását, két részre osztották az adatbázist: az írás-intenzív analitikai adatok kerültek az egyik klaszterbe, a többi adat a másikba.

• Mivel a gépeken tárolt lokális adatmennyiség is egyre nőtt, az index méretéhez kapcsolódó memóriahasználat elérte a gép fizikai határát. ETL (Extract / Transform / Load = Kinyerés / Átalakítás / Betöltés) folyamat segítségével átalakították az adatfeldolgozást, leválasztva a régebbi adatokat az adatbázisról, majd S3-ra archiválják őket.

• Később az ETL feldolgozás teljesen lemaradt a napi ütemezéstől, további adatbázis-elválasztásra volt szükség.

Végül, miután rájöttek, hogy minden API válaszidő a MongoDB-től függött, elkezdtek más adatbázis után nézni. A következő véleményük alakult ki:

• Elvetették az RDBMS rendszereket, mivel nem akartak saját sharding réteget fejleszteni, illetve annak a komplexitásával foglalkozni.
• A társ-alapítójuk a Diggtől érkezett, ahol a Cassandra tapasztalatok nem voltak túl kedvezőek.
• A HBase egy üzemeltetési rémálomnak tűnt.
• A CouchDB csak alkalmazás-szinten kezeli a horizontális skálázódást, kizárták a lehetőségét.
• A Riak megfelelően tudományos alapokra épül, valamint a fejlesztők és üzemeltetők is elégedettek voltak vele.

Adatmigrálás Riakra

Első lépésben a gyorsan növekvő adatokat jelölték meg, hogy Riakra migrálják: a session és az eszköz adatokkal kezdték, mivel ezek exponenciális mértékben növekedtek.

A session adatok előnye, hogy természetükből adódóan kulcs-érték párokat alkotnak, jól illeszkedve a Riak profiljához. Az adat-hozzáférési rétegük módosításán túl más változtatásra nem volt szükség. A python kliensnek volt néhány problémája a protobuf kezeléssel, és néhány más hibát azóta a kliensben javítottak (pl. keepalive header).

Az átállás egyszerű volt, leállás nélkül történt:

• új adatokat a Riakba írnak
• olvasáskor először a Riakból olvasnak, ha ott nincs adat, akkor a MongoDB-hez fordultak
• Egy héttel később a MongoDB-t teljesen leállították.

Az eszköz adatok egy kicsit eltérőek voltak, végül olyan kulcs-használat mellett döntöttek, amit egy hash-függvényből generáltak. A többi próbálkozásuk (pl. másodlagos indexek használata, map-reduce vagy azonosító indirekció) túl lassú volt, nagy késleltetésekkel (0.2-2 másodperc).

Riak élesben (3 hónapon túl)

A Kiip csapata a nagyon stabilnak találta a Riakot, csak néhány dolgot fájlalnak, és adtak néhány tanácsot és tippet, ami másokon is segíthet:

• Skálázódj korán. Ha a rendszer eléri a telítettségi pontot, akkor nagyon nehéz bármit is kezdeni a terheléssel. A késleltetés rohamosan nő a nagy IO használat miatt, és az új node hozzáadása rövid távon csak tovább növeli ezt (amíg az adatok átkerülnek rá). Monitorozd a késleltetést!

• Ne használj másodlagos indexet (2i) valós-idejű lekérdezésekhez, csak háttérfolyamatokhoz (5ms vs 2000ms). A LevelDB használatával minden index réteg egy extra lemez-hozzáférést jelent, ami növeli a késleltetést.

• A JavaScript VM sok memóriát igényel, ebből könnyen ki lehet fogyni, szabályozd az egyszerre használt darabszámot.

• Ne indítsd újra a node-okat gyors egymásutánban. Egy rossz automatizmus furcsa helyzethez vezethet, ami elrontja a teljesítményt és néha inkonzisztens állapothoz vezethet.

Egyetlen eszköz sem megoldás mindenre, a Riak sem kivétel. A Kiipnél még mindig használnak MongoDB-t a földrajzi adatok tárolására, bár azt rövidesen PostGIS-re fogják migrálni. PostgreSQL-t is használnak olyan adatok tárolására, amelyek nem gyorsan növekednek, és nem feltétlen kulcs-érték formában akarják kezelni őket.

A skálázódás nehéz, de a horizontálisan skálázódó kulcs-érték adatokhoz a Riak megfelelő választásnak tűnik.

Soós István

szoftvermérnök, üzleti tanácsadó

A maker-mozgalom, az önálló tanulás és az agilis módszerek támogatója. Gyakori témái: gépi intelligenci, adat- és kockázatelemzés, elosztott rendszerek, tudásmenedzsment.