Sokat beszélünk a cloud computingról, de a Gmail-en kívül használjuk-e valamire? Az alábbiakból kiderül, hogy már jelen állapotában is szolgáltatást lehet rá alapozni.
Kevés nagyobb lebőgést lehet annál elképzelni, mint amikor a nagy dérrel-dúrral beharangozott és elindított weblapot vagy webszolgáltatást az érdeklődők első rohama térdre kényszeríti. Márpedig a webszerverek terheléstesztelése nélkül jó esély van erre, ahogy nem egy esetben láthattuk az elmúlt években.
Ezért is tartottuk dicséretesnek, hogy az egyik ügyfelünk felkért bennünket, hogy teszteljük le az új weboldalukat terhelhetőség szempontjából is, mielőtt élesítenék azt. Nem csak arra voltak kíváncsiak, hogy hány látogatót képes egyszerre kezelni, hanem arra is, miként viselkedik egy DoS-támadás esetén.
Szoftveroldalról nem akkora durranás a terheléstesztelés: mi is hamar megírtunk egy Python-scriptet, ami tartalmazta a webhely URL-jeinek listáját; ezek közül véletlenszerűen választott a szoftver. Modelleztük a normál felhasználó viselkedését, aki kattint, megvárja az oldal betöltését, olvas, újra kattint, majd előbb-utóbb kilép. A DDoS-támadás szimulálásánál kicsit másképp jártunk el. Megkerestük azt a feladatot, amely vélhetően a lehető legjobban leterheli a szervert -- mivel egyszerű weboldalakról volt szó, úgy döntöttünk, hogy az "a" betűre keresünk rá. Elküldtük a kérést, és amikor a szerver már válaszolni akart, megszakítottuk a kapcsolatot, és újat nyitottunk. Mindezt egy központi vezérlőprocessz fogta össze, hogy a támadást egy pontból lehessen irányítani.
Keményebb dió volt a hardver kérdése. Egy ilyen tesztnek -- ha komoly terhelést akarunk szimulálni -- meglehetősen nagy a számítási kapacitás és hálózati sávszélesség igénye. PC-kről ez nem megy (ha csak nem hoz létre magának az ember egy botnetet :-), szervereket venni és beüzemelni egyetlen megbízásra pedig kicsit drága mulatság lenne. Szerencsére már rendelkezésre állnak a felhőszolgáltatások, amiket mintha pont az ilyen feladatokra találtak volna ki.
A választásunk az Amazon Web Services-re (AWS), az Amazon Infrastructure-as-a-Service szolgáltatására esett: itt olcsón és egyszerűen lehet akár nagyszámú szervert is bérelni (csak regisztráció és bankkártya kell hozzá), miközben a számlázás alapvetően óra alapon megy, és műszakilag kevéssé van megkötve a kezünk. Az Amazon egy hypervisort futtat a fizikai szervereken: az efölött futó virtuális szerver image-et a felhasználó úgy alakítja, ahogy neki tetszik, használhat Windowst és Linuxot is.
Először csak egy virtuális szervert béreltünk, annak az image-ét alakítottuk a saját igényeinkre, arra telepítettük a Python-scriptet. Amikor készen voltunk, nem volt más tennivalónk, mint egyetlen mozdulattal ugyanezt felhúzni 15 másik virtuális gépre -- azért éppen ennyire, mert az előzetes számítások szerint ennyi kellett a megfelelő terhelés szimulálásához. A 16 szerver pillanatok alatt a rendelkezésünkre állt, kezdődhetett a tesztelés.
Ez már a megszokott forgatókönyvek szerint ment. Szépen, fokozatosan növeltük a terhelést, egyre több threadet kapcsoltunk be, és közben folyamatosan monitoroztuk a túloldali szerverek működését. Az első próbán a tervezett teljesítmény 5-10 százaléka környékén már szépen megfeküdt a rendszer, jól demonstrálva a terheléses tesztelés szükségességét. A következő körökben az ügyfél mindig igazított valamit (egyebek mellett lecserélték a webszervert és állítottak a cache-en is), míg aztán végül közel egy hónapos közös munka után jutottunk el a kívánt végeredményig.
Ez idő alatt az AWS végig remekül teljesített. Két dolog merült csak fel negatívumként. Egyrészt, nem találtunk egyértelmű utalást arra, hogy mennyi az egyes virtuális gépek névleges kimenő sávszélessége (ezt már csak a tervezés miatt is jó lett volna tudni, arról nem is beszélve, hogy a díjat a használati idő, illetve az adatforgalom alapján számolja az Amazon). A teszt során szembesültünk azzal, hogy az AWS és az ügyfél szerverei között húszegynéhány megabitnél nagyobb sávszélességet nem tudtunk kiépíteni -- valahol a két végpont között a hálózatban volt egy szűk keresztmetszet, amit nem tudtunk megkerülni.
Egy másik kellemetlenség az volt, hogy a virtuális gépeket nem csak a tényleges tesztek, hanem a teljes időszakra igénybe kellett vennünk. Ennek oka, hogy a virtuális gépek a létrehozáskor dinamikusan kapnak IP-címet -- az ügyfélnek viszont, éppen a teszt jellegéből adódóan, előre meg kellett mondanunk, milyen IP-címekről érkezik majd a "támadás". Így viszont nem tehettük meg, hogy leállítjuk és a következő tesztre újraindítjuk a szervereket, mert a folyamatos állítgatás az ügyfélre túlzott terheket rótt volna. Így aztán egy kicsit többe is került a szolgáltatás, mint feltétlenül szükséges lett volna, de még mindig összehasonlíthatatlanul olcsóbb volt, mintha saját szerverparkot kellett volna berendezni.
Az AWS-re ugyanúgy tudunk szolgáltatást alapozni, mint a saját szerverekre: ott van, ha szükség lesz rá, de feleslegesen nem viszi a pénzt.
Klock László
