0. lépés: A Terv!

A Racing Bazár Magyarország piacvezető autóalkatrész-apróhirdető weboldala. Plusz, egy komplex, egyedi fejlesztésű apróhirdetés-portálrendszer, amely még több más hirdetőoldal motorját is adja. Adatbázisában több millió apróhirdetés, több százezer regisztrált felhasználó, több tízmillió fotó található. Kiszolgál havonta jópár-százezer egyedi felhasználót, sokmillió oldalletöltést.

Ez a motor a saját Dell PowerEdge szerverparkunkon fut. Viszont most, hogy felfuttatunk több új, külföldi oldalt is ezzel a motorral, megszületett egy döntés: nem szeretnénk a továbbiakban az infrastruktúrát üzemeltetni, ezért az egészet felpakoljuk a felhőbe, konkrétan a Windows Azure felhőszolgáltatásba.

Mi ennek a döntésnek az oka?

Alapvetően két dolog:

1. Szolgáltatásként kapott infrastruktúra és adatbázis-motorok
2. Skálázhatóság

Ez a két pont nem hiszem hogy sokkoló lenne, úgy általában ezek a fő előnyei a felhőnek. De mit jelentenek ezek konkrétan számunkra?

Az első pont azt jelenti, hogy megszabadulunk az infrastruktúra üzemeltetésének nagy részétől. Rengeteg időnk és energiánk ment el az webszerverek, adatbázis szerverek, és hasonlók konfigurálására, monitorozására, performancia-optimalizálására. Mivel kis csapat vagyunk, nincs ezekre külön-külön emberünk, így ezekhez az erőforrást a termékfejlesztéstől kellett elvegyük. Ez viszont oda is vezetett, hogy nem mindig tudtunk olyan mélységű jártasságot szerezni, amilyet szakmai igényességünk megkívánt volna.

A skálázhatóságot talán senkinek nem kell magyaráznom. On-premise szerverpark esetén annyi erőforrással kell rendelkezni, amely kényelmesen kiszolgálja a csúcs-időszakokat is, ami költséges és felesleges dolog. Egyébként az előzetes tervezés során gyakran meglepődve tapasztaltam, hogy nem is olyan könnyű erről a paradigmáról fejben átállni - gyakran automatikusan legnagyobb terheléshez számoltuk a költségeket egész hónapra, majd nagyon megörültem mikor eszembe jutott, hogy pl. az éjszakai időre ennek a költségnek csak fele-harmada fog jelentkezni.

Miért Windows Azure?

A Windows Azure-al kapcsolatban vagyunk szinte az indulása óta, 2010 óra mindig van valami termékünk vagy komponensük a Microsoft felhőjében. Ennek fő oka, hogy elsősorban Microsoft technológiákat használunk, a Microsoft ekoszisztémájában mozgunk. Semmi tapasztalatom nincs más felhőszolgáltókról, és most, ennek a projektnek a keretében sem lesz.

Van már rálátásunk az Azure gyengéire és erősségeire, és látjuk azt hogy a Microsoft komolyan gondolja, sok energiát beletesz.

Tetszik a fejlődés tempója, tetszik hogy van válaszuk mindenre. Tisztában vagyok vele, hogy ez az egész felhő még béta-állapotban lévőnek tekinthető, ami probléma lehet például ügyfélmunkánál - szerencsére mi termékfejlesztők vagyunk, amúgy is folyamatosan reszeljük a komponenseinket, így talán nem fog fájni, ha néha becsúszik valami extra fejlesztési feladat.

Hogyan fogjuk ezt végrehajtani?

Fél év tervezés után, 2 év alatt kompletten átírjuk az egész rendszert, majd fél év tesztelés során tökéletesre csiszoljuk, deploy, mindenki boldog, pezsgő.

Na, ez az ami nem fog megtörténni. :)))

Nem csak azért nem, mert nem láttam még élőben működni egy ilyen ciklust (kedvenc példám, amikor egy  ~50 fős csapat tagjaként részt vettem egy bő két hónapig tartó tervezésben. Kb 12-en 8 héten keresztül napi 4-6 órát meetingezve alaposan megterveztük a rendszert, majd mikor a 9. héten leültünk megvalósítani, kb 1.5 óra kódolás után borult az egész egy-két becsúszott kereszt-referencia miatt.)

Hanem azért, mert nincs elég tapasztalatunk az Azure szolgáltatások működésével kapcsolatban, annyi legalábbis biztosan nincs, hogy az egy megbízható tervezés alapját adja.

A másik oka ennek, hogy a hirtelen nagy változtatásoknak leggyakrabban sírás a vége: a felhasználóink, látogatóink, partnereink nem szeretik, a terheléses tesztekkel soha nem sikerül a valóságot szimulálni, a deploy után elkerülhetetlenül jelentkező bugok pedig egy keserű szájízt adnak az egész dolognak.

Ehelyett, inkrementálisan térünk át rá, komponensenként külön-külön, azon belül is mindig egy kisebb jelentőségű részfeladattal kezdve, hogy fájdalommentesen tudjuk élesben tesztelni, skálázni, finomhangolni.

Különösen nagy tekintettel leszünk a költségekre, hiszen a költséghatékonyság elsődleges cél az egész projekt során: úgy módosítjuk a kódunkat, működési logikánkat, hogy a lehető legkisebb költséggel használjuk ki az Azure erőforrásokat.

Hogy nem ez áll a programozástechnikai nagykönyvben? Hát nem. Mi egyébként is ezt az utat követjük a fejlesztés során, ebben van leginkább tapasztalatunk. 

Vegyük számba, milyen komponensekkel működünk most,  és azokhoz milyen válaszokra számítunk az Azure-tól

Adatbázis: MongoDb

Jelenleg MongoDb adatbázismotort használunk. Van öszesen 3 replica set-ünk, összesen 7 taggal (plusz az arbiterek), amelyek összesen kb. 90 Gb memórián osztoznak. 

Megtehetnénk, hogy megtartjuk a MongoDb-t és Azure VM-ekre telepítjük azokat (illetve korábban egy más projektünknél, a nincsmail.hu-nál ezt meg is tettük), de egyrészt ez, főleg a memória miatt nagyon költséges volna (és ugye a MongoDb igényli is memóriát), másrészt pont a lényeget veszítenénk el: továbbra is a nyakunkon maradna az adatbázis-szerverek üzemeltetésének a terhe.

Mi inkább áttérünk a DocumentDb-re, ami nagyjából a MongoDb mintájára épül. Ennek során refaktoráljuk, optimalizáljuk a dataprovider rétegünket is, hogy a DocumentDb-t is minél költséghatékonyabban használhassuk ki.

A NoSql join-hiányát eddig leginkább denormalizálással, és kliens-oldali joinokkal használtuk ki. Szétnézve azonban az Azure eszköztárában, adódik egy új lehetőség: a pre-populált táblák (vagy más néven materialized view-ek) használata a Table Storage segítségével. A Table Storage a legolcsóbb és leggyorsabb adattárolási lehetőség, ameddig elegendő az egyetlen index. Terveim szerint a háttérben workerek fognak dolgozni azon, hogy a view model-eket (amiket mi LiveModel-nek hívunk) legenerálják, elő-feldolgozzák, és Table-ökben eltárolják, ezáltal a webalkalmazásnak nem lesz más dolga, mint ezeket egyetlen lekérdezéssel, elsődleges kulcs alapján betölteni, majd szinte változtatás nélkül megjeleníteni.

Keresőszerver: Apache SolR

Az Apache SolR az egyik legjobb termék, ami az utóbbi években a kezembe került, bár mostanában sokat szívtunk vele a Java VM gyengeségei miatt.

Az Azure Search valami nagyon hasonló dolog, és szintén a Lucene szövegfeldolgozó könyvtárra épül, de a Solr-nél jóval-jóval egyszerűbb valaminek tűnik. Hogy tudja-e számunkra helyettesíteni a SolR-t? Pár órányi kutakodás után arra jutottam, hogy ez csak egyféleképpen fog kiderülni, mégpedig ha kipróbáljuk, valamelyik kisebb al-rendszerünkön.

Legrosszabb esetben felteszünk SolR-t egy VM-re, ez közel sem igényel annyi erőforrást, mint mondjuk a MongoDb.

Képek kiszolgálása

Jelenleg a kép-adatbázisunk mérete közel egy terabyte, kb. 15 millió fájl. Nincs dedikált SAN-unk, ezeket Dell PowerEdge szervereken , Raid5-ös tömbökön tároljuk.

Ez az adatmennyiség backupolhatatlan, a napi mentés közel egy napig (de néha tovább) tartana, de a nagyobb baj az, egy esetleges katasztrófa esetén a backup visszaállítása távolról akár 2 hétbe, de lokálisan is napokba tartana.

Erre a jelenlegi megoldásunk egy saját képtároló rendszer, amely backupolás helyett 2 (vagy akár több) éles kép-adatbázist tart folyamatosan szinkronban, különböző fizikai szervereken, természetesen duplázva mindent. Így nem lesz ugyan kezelhetőbb  a fájlrendszer, de legalább védve vagyunk a hardver-meghibásodás okozta adatvesztéstől, illetve szolgáltatás-kieséstől.

Mondanom sem kell, ez sok kép mind-mind egyenként kiált a blob storage-ért :)

Webes felületek

A webes felületeknek (publikus UI, admin felületek, ) leginkább gyorsnak és kieséstől mentesnek kell lennie. Az Azure fő előnye itt a skálázhatóság mellett a gyors deploy: jelenleg egy web app frissítés 5-10 perces leállással jár: IIS leállítás, fájlok felmásolása, IIS, app elindítása. Az Azure Cloud Services  production-staging megoldása révén egy deploy  élesítése 2-3 másodperc alatt megtörténik, ráadásul ez véd azon (sajnos meglepően gyakran előforduló) bénázás ellen is, amikor valami elnézett apróság miatt az új deployunk rögtön hibákat kezd dobálni, ami miatt szükséges megint egy deploy, újabb 5-10 perces leállással...

A webes réteget egyébként is szeretném jelentősen vékonyabbá tenni: az üzleti logika jelentős részét áttesszük háttér-taskokba, arra törekedve, hogy a web app fő feladata a table storage-ben tárolt előre-generált tartalom megjelenítése legyen.

Időzített feladatok, háttér-taskok

Az időzített feladatokat jelenleg egy saját fejlesztésű ütemezővel futtatják Windows service-ek. Mivel a serviceknek nincs olyan frappáns egy-két kattintásos telepítési mechanizmusa mint pl. a web appok esetén a Web Deploy, régóta gondolkozunk már, hogy ezeket is web appokba csomagoljuk.

Azure esetében rendelkezésünkre áll a WebJobs, amely koncepciója pont megfelel annak, amire nekünk szükségünk van. Külön szépsége, hogy a backend folyamatokat végző kódok telepíthetőek akár közvetlenül a webszerverre is, kisebb projekteknél ez szabad szemmel is látható költségcsökkentést jelenthet.

API-k, mobil alkalmazások

... nem tudom :)  

Jelenleg iOS és Android mobil alkalmazásaink vannak, amelyek webes REST Api-n keresztül kommunikálnak a rendszer többi részével. Látom hogy számos megoldása van az Azure-nak és a Microsoft-nak is a platformfüggetlen mobil app fejlesztésre és az azt támogató API-k működtetésére, de ezekbe most nem folytunk bele. 

Merre tovább?

Nagy vonalakban, erről van szó. Van persze még számos, itt nem tárgyalt kérdés, feladat és probléma, amelyeket akkor fogunk kivesézni, amikor odaérünk.

Következő lépés a fent már említett LiveModel-ek kialakítása lesz. Egyetlen LiveModellel kezdünk, amelynek keretében kialakítjuk az architektúrát, megpróbáljuk felmérni a potenciális gyenge pontokat, kitaláljuk hogyan tudjuk monitorozni, health-checkelni, és elsősorban felmérjük a költségeit.

Tartsatok akkor is velünk! :)