Mi az a skálázhatóság?
Nagyméretű, összetett rendszerek esetén gyakori követelmény a skálázhatóság. Egy rendszert akkor mondunk skálázhatónak, ha nagyobb terhelés alatt képes a teljesítményét növelni további erőforrások (tipikusan hardver) hozzáadásával.
Az informatikai (beleértve a hardver, a kommunikáció, a szoftver) skálázhatóság képes egy rendszer, hálózat, vagy egy folyamat áteresztőképességének növelésére. Jelentősége abban rejlik például, hogy a felhasználó elől rejtve maradhat egy rendszer jelenlegi terheltsége, így érhető el, hogy a nagyobb rendszerek (Google kereső, Facebook, Yahoo, stb) egyidejűleg több millió felhasználót képesek fennakadás nélkül kiszolgálni.
Korábban a vállalkozásoknak a szezonális csúcshoz kellett méretezniük informatikai rendszereiket. Ez nemcsak nagyobb IT erőforrásokat tett szükségessé, de megnövelte a működtetési költségeket is. A felhőalapú megoldásoknak köszönhetően a vállalkozások csúcsidőben felskálázhatják erőforrásaikat, majd a csendesebb időszakban csökkenthetik azokat. Mivel nincs szükség drága hardverek vásárlására, így csökkenthetik a beruházásra fordított összegeket. Fontos hangsúlyozni, hogy itt a skálázhatóság nemcsak a kapacitás növelését, hanem igény esetén annak csökkentését is jelenti.
A skálázhatóság két fő típusa:
felfelé vagy vertikálisan skálázható: nagyobb hardver kapacitás (gyorsabb vagy több processzor, nagyobb vagy gyorsabb memória és merevlemez) nagyobb számítási teljesítményt ad
kifelé vagy horizontálisan skálázható: újabb szerverek hozzáadásával növelhető a teljesítmény
A skálázhatóság elméleti korlátja a lineáris skálázhatóság, ebben az esetben a számítási kapacitás N-szeresére növelése a teljesítmény N-szeresére növekedését eredményezi.
Egy-egy skálázott rendszer tervezése összetett folyamat, annak függvényében, hogy mit várunk el egy ilyen rendszertől (magasfokú rendelkezésre állás, nagy áteresztőképesség stb). Fontos, hogy bármilyen számítástechnikai rendszer skálázhatóságát a CAP tétel határozza meg. A CAP tétel röviden azt mondja ki, hogy egy elosztott rendszerben (amely alatt több, egymással összekötött és egymással adatot megosztó végpontot értünk) a következő három tulajdonság közül egyszerre csak kettő érhető el egy adatrekord írását és olvasását tekintve:
- Konzisztencia (C, consistency): Egy kliens általi olvasási művelet garantáltan a legutolsó írás eredménye által létrejött rekordot adja vissza (vagy hibát jelez).
- Elérhetőség (A, availability): Minden kliens általi kérésre érkezik válasz (időtúllépések nélkül), azonban nincs garancia arra, hogy ez a legutolsó írás eredménye.
- Felosztási tolerancia (P, partition tolerance): A rendszer működőképes marad akkor is, ha bizonyos végpontok kiesése által az elosztott rendszer előre nem látható módon különálló részekre oszlik.
Fontos megjegyezni, hogy egyáltalán nincs annyi opciónk, mint elsőre tűnhet, hiszen a hálózat, amelyen keresztül a végpontok kommunikálnak, sosem százszázalékos megbízhatóságú. Ez teljesen kívül esik a mi irányításunkon, tehát a felosztási toleranciát mindig, minden körülmények támogatnia kell a rendszerünknek. Így valójában csak a konzisztenciát és az elérhetőséget illetően van mozgásterünk, ez alapján pedig két stratégia alkotható meg:
CP (konzisztencia és felosztási tolerancia): A kliens általi kérés ebben az esetben időtúllépési hibát generálhat. Ez a stratégia jó választás lehet akkor, ha az üzleti igény jellege miatt atomi írást és olvasást követelünk meg.
AP (elérhetőség és felosztási tolerancia): A válasz itt az adott végponton elérhető legfrissebb adatot tartalmazza, ez azonban lehet, hogy már elavult (amennyiben egy másik végponton keresztül végbement közben egy írási művelet). Jó választás az elérhetőséget preferálni abban az esetben, ha az üzleti igény megenged némi flexibilitást annak tekintében, hogy az adatok pontosan mikor szinkronizálódnak a végpontok között (ezt takarja az eventual consistency), vagy akkor, ha azt szeretnénk, hogy a rendszerünk külső hibák ellenére is működőképes maradjon.
Látható tehát, hogy mindenképpen kompromisszum-kényszerben vagyunk (mint oly sok esetben, amikor szoftverrendszerekkel dolgozunk…). Átmeneti és tartós hálózati problémák bármikor előfordulhatnak, ez pedig kívül esik a rendszerünk határain, kontrollálni nem tudjuk.
Az elosztott rendszereknek rengeteg előnye van — és a skálázhatóság megvalósításához többnyire elengedhetetlenek —, de a komplexitást is növelik. Ezért is különösen fontos a korlátok és lehetőségek alapos ismerete, hogy jól informált tervezési döntéseket tudjuk hozni, hisz ha a kezdetekkor rossz választást teszünk, az akár az egész projektet is veszélyeztetheti.
A skálázható felhőtechnológia
A leállások megelőzése
Egy rendszer leállása a termelékenység legfőbb ellensége. A felhőalapú infrastruktúrák sokkal stabilabban működnek, mint egy helyi informatikai rendszer, ezért segíteni tudnak a kiesések minimalizálásában, illetve elkerülésében. Kulcsszolgáltatás lehet a biztonságos backup és a gyors visszaállítás. A tapasztalat azt mutatja, hogy számos cég az adatmentéseit ugyanabban az épületben tárolja, mint az élesben használt adatokat – még az is megeshet, hogy ugyanabban a szerverteremben. Könnyű belátni, hogy ez nem igazán katasztrófatűrő megoldás, a „cloud computing” ugyanakkor ezt a problémát is áthidalja.
Igény szerinti skálázhatóság
A felhőben működő erőforrások egyik legvonzóbb tulajdonsága, hogy hardverberuházás nélkül, bármikor növelhető vagy csökkenthető a felhasználásra kerülő informatikai kapacitás. Ez a gyártás vezérlését és támogatását is nagymértékben skálázhatóvá teszi. A vertikális skálázással a processzorok számát, a memória és a tárhely mennyiségét, vagyis egy adott szerver teljesítményét lehet megnövelni.
A horizontális skálázás során a szerverek számát növelik vagy csökkentik.
A diagonális skálázás pedig e két módszer kombinációját jelenti.
Adatvezérelt döntések
A leghatékonyabb gyártói döntéseket adatok intelligens elemzése alapján lehet meghozni. A felhőtechnológia megkönnyíti az adatok rögzítését, tárolását, elemzését, továbbá jelentések készítését, miáltal a cég gyorsan tud megalapozott döntésre jutni, ami például az előállítási ciklus lerövidüléséhez vezethet.
Minőség-ellenőrzés
Egy felhőalapú rendszer képes egységes minőségellenőrzési rendszer működtetésére, nyomon követve a teljes gyártási folyamatot, a különféle eszközöket, platformokat, munkafázisokat.
Egy kis visszatekintés: 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ó 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 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 a hardverigénye 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.
Mi lenne az optimális?
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).
A köztes út: egy hibrid rendszer. 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.
Források: 24.hu, wikipedia, bitport.hu