A felhőszolgáltatások manapság erősen felértékelték a skálázhatóságot. Hogyan lehet megoldani, hogy a szolgáltatás, amelynek induláskor legfeljebb néhány tíz vagy száz felhasználót kell kiszolgálnia, akár több ezer vagy nagyságrendekkel több felhasználót is képes legyen kiszolgálni rugalmasan?

Mindez komplex problémakör. Hiszen ma már nem is csupán skálázhatóságról, sokkal elasztikusságról, rugalmasságról kell beszélni, ha a felhőszolgáltatások teljesítményigényét nézzük. Érdemes röviden történetileg is áttekinteni, hogyan alakult az elmúlt 20-25 évben ez a problémakör a mainframe-ektől a mai rendszerekig.

Kezdetben volt az erős, erősebb, legerősebb

Nagyjából két évtizede a skálázhatóság egyetlen dologgal függött össze: a hardver erejével. Ha több felhasználót akart egy rendszer kiszolgálni, akkor erősebb hardver kellett. Ezt az elvet követték a mainframe-ek és a midrange szerverek is. A gyártók egyre nagyobb és egyre erősebb, azaz egyre több processzort és egyre több memóriát kezelő hardvereket építettek, ezt a módszert scale-up-nak hívjuk. És ha nőtt az erőforrásigény, újabb, még erősebb szervereket vásároltak. Ennek a felfelé skálázhatóságnak azonban több nagy hátránya is volt, ami az általános elterjedését akadályozta. Extrémen drágák voltak ezek a rendszerek, speciális környezetet nyújtottak, ráadásul felülről korlátosat, azaz ha egy szervezet elérte a bővíthetőség határait, akkor újat, erősebbet kellett vásárolni.

Az áttörést az x86 platform hozta, amely paradox módon erős korlátokkal skálázható felfelé, bár több processzort és több magot is tud kezelni. A Google azonban mégis ehhez a platformhoz fordult, hogy keresőjéhez rugalmasan növelhető, óriási erőforrásokat biztosítson. Ehhez azonban a skálázhatóságot ki kellett vinnie a szerver belsejéből (scale out) – szemben a mainframe és midrange megoldásokkal, melyek ugyanezt a szerver belsejében oldották meg (scale up).

Ez a módszer az erőforrás-tervezést is rugalmasabbá tette, hiszen ha meghibásodott egy olcsó x86-os szerver, akkor egyszerűen ki kellett cserélni. Ugyanakkor persze volt a megoldásnak egy hátránya is: a Google nem általánosan alkalmazható megoldást választott, hanem a saját alkalmazásaihoz illesztette mindezt.

És akkor jött a virtualizáció

Sokan ma is bölcsek köveként tekintenek a virtualizációra, amely nagyban javította a hardverek erejének a kihasználtságát. A virtualizáció ugyanis a hardverek felől közelített a skálázhatóság problémájához. Daraboljuk fel a hardvert, és használjuk az egyes elemeit különböző feladatokra.

Ez a módszer kiváló arra, hogy a hardverek teljesítményét maximálisan kihasználjuk, ugyanakkor a skálázhatóság szempontjából zsákutcának bizonyult, mivel – az alapelvből adódóan – a virtualizáció csak lefelé skálázást tesz lehetővé. Később, a munkaterhek közel valósidejű  "pakolgatásával" egy minimális mértékű felfelé történő skálázást is sikerült "szimulálni", azonban ez nem képes általános skálázhatóságot nyújtani.

A virtualizáció sem lett a "bölcsek köve": csak lefelé skálázhatóságot biztosít

A virtualizáció azonban annyiban valóban forradalmi változás volt, hogy magát az elvet különböző szinteken lehet megvalósítani. Bizonyos esetekben, például a PHP-nál egyébként kiválóan alkalmazható a módszer, mivel a PHP magában viszonylag rosszul skálázható, ezért a nagy teljesítményű gépek feldarabolása jól érzékelhető teljesítménynövekedést hoz. Persze itt is van a megoldásnak egy korlátja: vigyázni kell arra, hogy a overhead ne legyen túl nagy, azaz az erőforrásokat ne foglalja le túlságosan a virtualizálás, hiszen az az alkalmazásoktól veszi el a teret. Azaz amit nyerünk a réven, azt sokszor elveszítjük a vámon.

A nagy adatbázisok problémája

A skálázhatóság a hatalmas adatbázisok esetében is komoly kihívás, és mivel minden valamirevaló alkalmazásnak van adatbázis-igénye, ezt a problémát is kezelni kell. A skálázhatóság közkedvelt változata, hogy több szervernode fut egy közös tárhely felett. Ez a megoldás elég hamar korlátokba ütközik, mert a storage sávszélesség nem korlátlan.

A másik változat, a  Parallel Query, amikor is az adatbázist különböző szervercsomópontokon futtatjuk, amik a szétosztott lekérdezési feladatokat a saját adatbázisukban végrehajtják. Ez a megoldás nagyon jól skáláz, de a relációs adatmodell miatt a kereszthivatkozások alapvetően tönkreteszik a teljesítményt. A modern adatbázisok már nem relációs felépítésűek (NoSQL), így ott a párhuzamosítás (pl. a Google-féle map-reduce) már nagyon komoly eredményeket és elasztikusságot jelent.

Vissza a felhőhöz!

Ma azonban a skálázhatóság leggyakrabban a különböző webes alkalmazásoknál merül fel leginkább. A Facebooktól a Preziig, a Ustreamtől a Dropboxig minden sikeres cég a webet látja annak a platformnak, amelyen sikeres lehet, de ma már gyakorlatilag nincs olyan, széles körben is igénybe vehető szolgáltatás, amely valamilyen szinten ne jelenne meg a weben. Bankok, biztosítók, webshopok és így tovább mind ott látják a kitörési pontot.

Itt is élesen vetődik fel a skálázhatóság. Az, hogy a webes kérések eljussanak az alkalmazáshoz, viszonylag jól megoldott. A webszerverek skálázása ma már bevett technika. Ez azonban voltaképpen csak azt biztosítja, hogy a kérések szintjén nem következik be dugulás a forgalomban. A jól skálázható webszerver tíz konkurens felhasználó kérését éppúgy problémamentesen irányítja tovább, mint ezrét. Attól azonban, hogy a kérés eljut az alkalmazásig, maga az alkalmazás még nem tudja feltétlenül kiszolgálni a megnövekedett terhelést.

Virtualizáljuk a platformot!

Ha erre keresünk megoldást, ma úgy tűnik, ha nem is teljesen általános, de jó megoldást ad a platform szintű virtualizáció és skálázás. Java környezetek esetében például ez úgy valósul meg, hogy nem csupán a JVM-eket (Java Virtual Machine) skálázzuk, hanem a futtatókonténereket is, és így az alkalmazáslogika terhelését osztjuk el. Ez azt is eredményezi, hogy több gépet is össze lehet kapcsolni, és így az infrastruktúra szintű (pl. operációs rendszer, IaaS) skálázhatóságtól eltérően itt valódi felfelé skálázás (scale-out) valósulhat meg. Ahhoz, hogy ennek a mechanizmusnak a működési sajátságai ne a fejlesztőket terhelje (akik különben sem szeretnek skálázható szoftvereket írni), platform szintre kell emelni a futtatókörnyezetek virtualizációját és méretezését, valamint elrejteni a fejlesztők és üzemeltetők elől.

Ezt nevezzük platformszintű virtualizációnak, amely alapelvében a klasszikus virtualizációra hasonlít, azaz az erőforrások felosztásán alapul. Ugyanakkor biztosítja azt, hogy egyrészt sokkal nagyobb "alkalmazássűrűséget" lehet elérni a fentebb említett túlságosan nagy overhead nélkül (mint operációs rendszer szintű, vagy JVM-szintű skálázás esetén), valamint a felfelé skálázás is megoldottá válik, mivel az alkalmazáslogika teljesítménye szervereken átívelően növelhető, szinte korlátlanul. Így működik például a Red Hat OpenShift megoldása.

Az OpenShift olyan szuperkönnyű alkalmazáskonténereket valósít meg, amiknek az overheadje a klasszikus virtualizációnál több nagyságrenddel kisebb. Szinte minden alkalmazáskörnyezetet támogat, a standardnak számító JavaEE alapú JBoss-tól a Pythonon és a PHP-n át a Ruby-ig és a node.js-ig. Az alkalmazáskonténerek közötti terhelésmegosztást, a szükséges konténerek indítását, leállítását is automatikusan elvégzi, sőt a feljesztési és build workflow-t is képes integrálni. Ami az adatbázisokat illeti, a relációsakkal az OpenShift sem tud csodát tenni, de ha nem „tömjük tele” tárolt eljárásokkal, hanem a köztesrétegben tartjuk az üzleti logikát, akkor elég messzire juthatunk. Másrészről, az OpenShift támogatja a nem relációs adatbázisokat is, amik már platformszinttől elvárható módon skáláznak, és számos adatbázisfeladatra kiválóan alkalmasak.

Ha most indulnék...

Mindebből praktikusan az következik, hogy egy webes felületről elérhető felhőszolgáltatásban gondolkodó nagyra törő – milliós felhasználói tábort megcélzó – szolgáltató számára két út járható egy rugalmas, jól skálázható rendszer felépítésére: vagy megépíti magának az alkalmazásához igazított speciális elasztikus hátteret (lásd pl. Google), vagy igénybe vesz valamilyen platform-szintű szolgáltatást (PaaS – Platform as a Service).

Szentiványi Gábor,
az ULX Kft. ügyvezető igazgatója

Ugyanakkor én a köztes utat választanám: egy hibrid rendszert. Olyan rendszert ma már viszonylag olcsón fel lehet építeni, amely néhány ezer felhasználót gond nélkül kiszolgál. Ez egyrészt biztosítja a belső futtató környezetet, valamint a fejlesztéshez a tesztkörnyezet.

Majd pedig amikor a felhasználók száma megnövekszik, a szolgáltatás egy a belső rendszerrel kompatibilis futtató környezetet biztosító standard platformszolgáltató rendszerére vihetőés a munkaterhek a kettő között szabadon mozgathatók. Ez egyaránt lehet vállalaton belüli (privát platform szintű felhő) vagy kívüli (publikus platform-szintű felhő).

Ez az út – már csak a rendszer alapjainak helyben tartása miatt is – nagyobb biztonságot és hosszú távú flexibilitást ad.