Skálázható, felhő alapú webkiszolgálás

Az eddigi, klasszikus megoldásban az internetről érkező HTTP kérések kiszolgálását egyetlen folyamat biztosította, amely minden bejövő kérést önállóan válaszolt meg. Az internet felé néző webkiszolgálónk (belsős szlenggel: Front-szerver) 80-as portján futó Apache kiszolgáló-folyamat mellett a háttérben futottak még egyéb, hagyományos processzek is: ütemezett scriptek (Cron) kezelése, levelezés biztosítása, stb. Ez a megoldás egy sokat bizonyított, a mindennapokban jól beváló módszer, de skálázni egy idő után már csak memóriabővítéssel lehet, aminek mennyisége a végtelenségig nem növelhető.

Nem maradt más választásunk, minthogy a webkiszolgálásunkat felhő alapúvá alakítva a front szerverünk terhelését csökkentsük. A frontról leválasztottuk az összes hagyományos webes forgalmat és csupán egy terheléselosztást végző proxy réteget hagytunk meg szeptember 1-től kezdődően. A beérkező kéréseket a proxy átadja egy háttérben futó 3 webkiszolgáló egyikének, amelyek mind-mind teljesen megegyező, önálló kiszolgálásra alkalmas szerverek. Így minden hagyományos HTTP kérés átirányítódik a háttér-szerverekhez és azok szolgálják ki őket, tehermentesítve a front szervert.

Az új megoldás legnagyobb előnye a skálázhatóság és emellett a hibatűrés is nagymértékben növekedett. A proxy a háttérszervereket folyamatosan monitorozza, így az új rendszerrel képesek vagyunk az egyik kiszolgáló kiesése esetén a forgalmat a megmaradt kiszolgálók felé irányítani és a későbbiekben a meghibásodott szerver helyett egy új példányt készíteni és csatasorba állítani. Az automatikus újrakonfigurálás technológiája segítségével a rendszer későbbiekben majd öngyógyítóvá válik és kiesés esetén képes lesz magától egy új szervert létrehozni, konfigurálni és elindítani. Így, ha megnő a terhelés, vagy valamelyik szerver csődöt mondana, azonnal, emberi beavatkozás nélkül beáll majd egy új példány.

Mint mindennek, az új rendszernek is vannak hátulütői. Az egyik ilyen, hogy egyetlen adatbázis van, amit minden szervernek ugyanúgy el kell érnie bármikor. Hasonlóan, a weboldalakat kiszolgáló tárhelyhez is mindig, minden node-nak hozzá kell tudnia férni. Ennek megoldásához különböző változtatásokat kellett eszközölni a belső hálózatunkon.

A nagyobb problémát a session-kezelés megvalósítása, valamint a hálózati kialakítás miatti rosszul detektált kliens IP-címek jelentették. Az előbbi feladatra a proxyn futó elosztó alkalmazás nyújt megoldást, mely letárol minden, a kliensekkel újonnan létesített kapcsolatot és onnantól a kommunikáció lezárásáig ugyanazon a háttér kiszolgálószerverrel folyik az adatcsere. Utolsó problémaként felmerült, hogy a belső hálós IP címek összezavarják azokat a szerver oldalon futó alkalmazásokat, amelyek lekérdezték a kliensek címeit. Ennek oka az, hogy az Apache szempontjából a kérések olyanok, mintha a proxy géptől jönnének, azaz minden kliens a proxy belső IP-jével látszik.

A megoldás az, hogy a proxy a továbbítás során elhelyez egy HTTP headert a HTTP kérésbe, amibe beleteszi az eredeti kliens IP-jét, és van egy Apache modul, ami a kiszolgálón ezt értelmezi és kicseréli a kliens IP-jét (proxy szerver belső IP-je) a tényleges kliens (böngésző gép) IP-jére.

A rendszer éles üzembehelyezése előtt a proxy a front szerver 80-as helyett egy másik portjára volt beállítva, így ezen keresztül folyt a tesztelés. Miután bebizonyosodott, hogy minden papírforma szerint működik, egyszerűen átirányítottuk a 80-as portra érkező forgalmat. A változás minden szempontból sikeres volt. Felhasználói oldalról szubjektíven is érezhetően gyorsabban töltődnek be a weboldalak. A mérési eredmények pedig szintén megerősítették ezt. A webszerver terhelése nagyjából a harmadára csökkent, nem véletlenül: Ezentúl 3 szerver szolgál ki ugyanannyi kérést, amit eddig 1 tett meg.