Felhőbeli kihívások: Méretezhetőség
Az eddigiek alapján egy elosztott program megtervezéséhez és megvalósításához hozzátartozik a programozási modell megválasztása, valamint a szinkron, a párhuzamosság és az architektúra problémáinak kezelése. Felhőalapú program fejlesztésekor a tervezőnek ezeken felül több más olyan problémát is alaposan meg kell fontolnia, amelyek felhőkörnyezetekben kritikusak. A továbbiakban a skálázhatósággal, kommunikációval, heterogenitással, szinkronizációval, hibatűréssel és ütemezéssel kapcsolatos problémákról lesz szó.
Méretezhetőség
Egy elosztott program akkor minősül skálázhatónak ha a felhasználók, adatok és erőforrások számának jelentős növekedése esetén is hatékony marad. A probléma jelentőségének belátásához elég a sok népszerű alkalmazásra és platformra gondolni, amelyeket jelenleg kínálnak a felhasználók millióinak internetes szolgáltatásokként. Ami az adatokat illeti, a big data és a terabájtos adatmennyiségek korában (az Intel kifejezésével a „tera érában”1), az elosztott programok általában webes adatok száz vagy ezer gigabájtos, terabájtos vagy petabájtos mennyiségeivel dolgoznak. Az adatforrások 2010-ben globálisan mintegy 1,2 ZB-ot (1,2 millió petabájtot) generáltak, a 2020-ra vonatkozó előrejelzések szerint pedig ennek a mennyiségnek a közel 44-szeres növekedése várható.2 Az olyan internetes szolgáltatások, mint az e-kereskedelem és a közösségi hálózatok nap mint nap a felhasználók milliói által generált adattömeget kezelnek. Az erőforrások tekintetében a felhőbeli adatközpontok máris számítógépek tíz- vagy százezreit üzemeltetik. Az előrejelzések szerint pedig a gépek száma a többszörösére nő majd.
Az n csomóponton történő végrehajtás a valóságban sohasem éri el a teljesítmény ideális n-szeres növekedését. Ebben több ok is közrejátszik:
- Ahogyan a 13. ábrán látható, a programok egyes részei (például az inicializálás) sohasem párhuzamosíthatók.
- Nagyon valószínű, hogy a tevékenységek terhelése nem egyenletes, különösen az olyan elosztott rendszerekben, mint az erősen heterogén felhők. A 13.(b) ábra bemutatja, hogy a terhelés egyenetlensége általában késlelteti a programot, amelyet mindig korlátoz a leglassabb tevékenység. Egy program a csak akkor fejeződhet be, miután az utolsó tevékenysége is befejeződik.
- A skálázhatóságot súlyosan érintik az olyan többletterhelések, mint a kommunikációval és szinkronizálással járó többletmunka.
13. ábra: Párhuzamos gyorsítás: a) ideális eset és (b) valós eset
Ezek a problémák lényegesek az elosztott és szekvenciális programok teljesítményének összehasonlításakor. A gyorsítási tényezőt meghatározó, széles körben használt képlet, amely a különböző többletmunkákat is figyelembe veszi az Amdahl-törvény. A számítás szemléltetéséhez tételezzük fel, hogy egy $T$ program szekvenciális verziója $T_{s}$ időegység alatt fut le, a párhuzamos/elosztott verzió pedig $T_{p}$ időegység alatt fut le egy $n$ csomópontból álló fürtön. Tegyük fel továbbá, hogy a program $f$ hányada nem párhuzamosítható, tehát az $(1 – f)$ hányada párhuzamosítható. Amdahl törvénye szerint a $P$ párhuzamos/elosztott végrehajtásával járó, a szekvenciálishoz viszonyított gyorsítás az alábbi képlettel definiálható:
$$ Gyorsítás_{p} = \frac{T_{s}}{T_{p}} = \frac{T_{s}}{T_{s} \times {f + T_{s}} \times \frac{1 - f}{n}} = \frac{1}{f + \frac{1 - f}{n}} $$
Bár a képlet egyszerűnek tűnik, van egy nagy horderejű következménye: korlátlan számú géppel rendelkező fürtöt és konstans $s$ értéket feltételezve kifejezhető vele a maximálisan elérhető gyorsítás, ha az alábbiak szerint kiszámítjuk a $P$ végtelen sok processzorral elérhető gyorsítását:
$$ \lim_{n\to\infty} Gyorsítás_{p} = \lim_{n\to\infty} \frac{1}{f + \frac{1 - f}{n}} = \frac{1}{f} $$
Az elemzés lényegi résznek megértéséhez tételezzük fel, hogy a szekvenciális rész $f$ aránya csupán 2%. Korlátlan számú gépre kiszámítva a képlet azt az eredményt adja, hogy a maximális gyorsítás csupán 50-szeres. Az $f$ értékét 0,5%-ra csökkentve a maximális gyorsítás 200-szoros lesz. Ebből látható, hogy az elosztott rendszerekkel rendkívül nehéz megvalósítani a skálázhatóságot, hiszen $f$-nek szinte 0-nak kell lennie, és ez az elemzés még nem veszi figyelembe az egyenetlen terheléssel, a szinkronizálással és a kommunikációval járó többletmunkát. A gyakorlatban a szinkronizációs többletmunka (például a határalapú szinkronizálás és a zárolások végrehajtása) a gépek számával együtt nő, gyakran nemlineárisan.3 A kommunikációs többletmunka is jelentősen nagyobb a nagyméretű elosztott rendszerekben, mivel nem minden gép osztozhat rövid fizikai összeköttetésen. Rövidesen szó lesz arról is, hogy a kiegyensúlyozatlan terhelés heterogén környezetben jelentős tényezővé válik. A valós problémák mellett hangsúlyozandó, hogy webes mennyiségű bemenő adat esetén a szinkronizációs és kommunikációs többletmunka sokkal kisebb is lehet, ha sokkal kevesebbel járul hozzá a teljes végrehajtáshoz, mint a számítások. Szerencsére sok big data jellegű alkalmazásnál ez az utóbbi helyzet áll fenn.
Hivatkozások
- S. Chen és S. W. Schlosser (2008). MapReduce Megfelel az alkalmazások szélesebb fajtáinak IRP-TR-08-05, Intel Research
- M. Zaharia, A. Konwinski, A. Joseph, R. Katz, and I. Stoica (2008). A MapReduce teljesítményének javítása heterogén környezetekben OSDI
- Y. Solihin (2009). A párhuzamos számítógépes architektúra alapjai Solihin Könyvek