Hova telepítsem a webáruházam?

Sokszor találkoztam olyan leendő vagy már meglévő webáruház tulajdonosokkal, akiknek a fejében megfordult a címben feltett kérdés. Mit csinálnak ők? Sok különböző szabadon elérhető webáruházat lehet letölteni az internetről. Amelyiket a legtöbben használják azt letöltik a saját gépükre és elkezdenek játszani vele. Ha sok tízezer embernek jó volt, akkor nekem is jó lesz, gondolják. Kattintanak ide, kattintanak oda, majd megtetszik nekik valamelyik funkció vagy esetleg egy menü színösszeállítása és máris beleszeretnek. Eljátszanak a gondolattal, hogy nekik is lehet saját webáruházuk. Vásárolnak egy domain nevet, majd feltöltik egy szolgáltatóhoz és elkezdik használni.

Maga az áruház áll egy forráskódból, ez tartalmazza az áruház funkcióit, a logikát, ami alapján működik, tartalmazza a kinézetet és a hozzá kapcsolódó fájlokat (stíluslapok,html,képek). Az áruházhoz tartozik egy adatbázis, amit a terheléstől függően és a biztonság miatt célszerű egy különálló gépen/környezetben elhelyezni. Az adatbázis tartalmazza a termékekhez kapcsolódó adatokat, leírásokat, hivatkozásokat. A termékekhez kapcsolódó képek mérete és mennyisége is jelentős lehet. A termékképek megfelelő helyről történő kiszolgálása (CDN) szintén meghatározó tényező lehet, ugyanis nem mindegy, hogy ezeknek a képeknek a felbontása és tömörítése milyen, mivel egy oldal betöltődési idejét is ez határozza meg. A keresőrobotok, amelyek folyamatosan feltérképezik a rendelkezésre álló oldalakat egy adott minőségi mutatóval osztályozza az elérhető oldalakat és nagyobb értéket ad annak, akinek az oldala ennek megfelel, mindezt azért teszi, hogy a felhasználóknak relevánsabb találatokat adjanak, rátaláljanak arra, amit keresnek. Egy webáruház elhelyezéséhez a következő lehetőségek adódnak:

1. Saját, otthoni helyi gép

Ide elsősorban a kipróbálás vagy a fejlesztés miatt telepítjük először az áruházat. A verziókezelő használata a fejlesztés során kulcsfontosságú, hiszen pontosan így tudjuk megmondani, mikor, mi, hol, illetve ki okozta a forráskódban a változtatásokat. A verziókezelő használatára számos lehetőségünk adódik, célszerű ezt is egy távoli és mindentől független gépen használni. Ez bizosítja továbbá, hogy bármi történhet az éles verzióval innen mindig visszaállítható a legutolsó működő állapot és beállításai is egyben. A staibilitás és a kontroll szempontjából ez kulcsfontosságú. A fejlesztés számára szintén jelentős, mert ennek segítségével párhuzamosan többen is dolgozhatnak és készíthetik az adott funkciók megvalósítását. Pusztán a kipróbáláshoz nem szükséges verziókezelőt alkalmazni, viszont fontos figyelembe venni, hogy a környezetek közötti különbségek is befolyásolhatják a működést. Tehát egy adott operációs rendszer alatt feltelepített áruház eltérően viselkedhet egy másik operációs rendszerben feltelepített verzióban. A cél egy olyan helyi környezet kialakítása, ami teljesen megegyezik a leendő szerverre telepített környezettel. Erre a legmegfelelőbb eszköz a konténerek használata. Egy adott konténer környzetet alakítunk ki és ebben mozgatjuk az adott alkalmazásunkat/áruházunkat. Így biztos, hogy mindehol ugyanúgy fog működni. Előnye, hogy bármit büntetlenül megtehetünk és megfigyelhetünk. Egy helyi gére feltelepített áruház és egy valós üzemben működő szerverre telepített áruház között azért van lényegi különbség. Az első esetben a célunk a funkciók kipróbálása, az utóbbiban pedig a zavartalan és folyamatos működés biztosítása.

2. Osztott tárhely

A tárhely megválasztásánál, mivel általában nem tudják a leendő tulajdonosok mi alapján válasszanak, ezért egy nagyon alacsony árfekvésűt fognak kiválasztani, hiszen nem tudják mi alapján tegyék ezt, akkor legalább ne kerüljön sokba. Ez nagyjából évi pár ezer forint körüli kategória. Ennek a tárhelynek a jellemzője, hogy rendelkezik egy fix kapacitású dinamikus mérettel, általában php jellegű oldalak kiszolgálására és tartalmazhat egy vagy több darab adatbázist, illetve levélkiszolgálót is. A másik jellemzője, hogy egy adott erőforráson (memória, cpu kapacitás, sávszélesség) osztozik több más hasonló oldal is és ugyanazok a beállítások lesznek érvényesek mindegyikre. Az ilyen tárhely jellemzője, hogy korlátozva van mondjuk a párhuzamos kapcsolatok száma. (lásd apróbetűs részben a szerződési feltételeknél) Ez azt jelenti, ha egyszerre több felhasználó szeretne kapcsolódni az oldalhoz és nem tud, akkor eldobja a szerver a kérést és egy hibaüzenet jelenik meg. Hasonlót tapasztalhatunk a szerver túlterhelése esetén is, mivel kifuthatunk az erőforrásból, főleg ha a termékszám és a látogatói szám növekszik. Minden erőforrás felhasználás növekedésének megvan a maga oka, és lehet, hogy ezt egy hiba vagy valamilyen rossz beállítás okozza. Ennek a kiderítése osztott környezetben nagyon nehéz vagy lehetetlen. Ilyenkor a tárhely üzemeltetője biztonsági okokból lekapcsolja az adott fiókot, hogy más oldalak rovására ne menjen az erőforrás felhasználása. Sajnos nem egyszer fordultak már hozzám hasonló problémával. Könnyen látható, hogy egy viszonylag alacsony regisztrációval rendelkező webáruház is tud meglepetéseket okozni, ha helytelenül van beállítva és egy email-es kampányt indítanak, aminek az eredménye pontosan az ellenkezője lesz, mint amit szeretnének. A vásárlók nem vásárolni fognak, hanem inkább messze elkerülik a megbízhatatlan oldalt. Az osztott környezetben nincs lehetőség külön konténer kialakítására, az adott szerver környezethez kell igazodni.

3. Dedikált fizikai szerver

Dedikált szerver esetén vásárolunk egy saját szervert és egy adott szolgáltató szervertermében helyezzük el. A szolgáltató gondoskodik az elektromos hálózatról és a sávszélességről. Itt a teljes felügyletet és az időközi karbantartási feladatokat mi biztosítjuk a szerverünk felett. Azt telepítünk, amit akarunk és úgy állítjuk be, ahogyan akarjuk. Ha ezt választjuk akkor pontosan tudjuk miért és mit fogunk tenni. Hátránya, hogy rendelkezik egy adott fizikai korláttal, egy előre megvásárolt fix beépített erőforrással rendelkezik, a szerver összes költségét előre ki kell fizetni. Lehet, hogy a döntő részét nem is fogjuk használni.

4. Virtuális szerver

A saját fizikai szerver vásárlásának és elhelyezésének egy alternatívája. Előnye, hogy maga a szerver egy adott szolgáltatónál van, így a felmerülő beszerzési és üzemeltetési költségek nem merülnek fel. Távolról hozzáférhető és menedzselhető akár a fizikai szerver. Előnye, hogy lényegesen egyszerűbben juthatunk olyan erőforráshoz, mint a fizikai szerver esetén. Legtöbbször nincs szükség nagy kapacitású szerverre, a szükséges erőforrások méretét menet közben lehet változtatni az igényeknek megfelelően, így rugalmasan kialakítható a szükséges infrastruktúra. Kívülről a felhasználó egy adott virtuális szervert lát, a valóságban viszont a tényleges fizikai erőforrások vannak megosztva több felhasználó között. A különbség az osztott tárhelyhez képest az, hogy itt a virtuális gépek teljesen különálló egységet alkonak, el vannak választva egymástól és a tulajdonos gazdálkodik és rendelkezik az adott szerver felett, teljes jogosultságot kap az erőforrások felett. Ilyen környezetben lehetőség van külön monitorozó megoldások létrehozására, továbbá finomhangolni lehet a webkiszolgáló beállításait az optimális működés érdekében.

5. Klaszter, több szerver használata egyszerre

Egy webáruház esetén számos kérést kell kiszolgálni. Ilyenek lehetnek a statikus tartalmak (képek, stíluslapok, javascript fájlok), dinamikusan előállított változó tartalmú kérések, adatbázis kapcsolatok, monitorozó megoldások kérései, logelemző és egyéb, akár nagyobb erőforrást is igénylő háttérfolymatokban futó kérések, amelyek befolyásolják és biztosítják a webáruház folyamatos működését. Például: adatmentések, árfolyamfrissítések, különböző feed-ek előállítása, árak, készletek dinamikus időközi rendszeres frissítése, egyéb szikronizációs folyamatok, keresőrobotok kiszolgálása és kiszűrése, esetleges rosszindulatú támadások elhárítása és kiszűrése stb… Napközben bizonyos kampányok alkalmával vagy egy adott időszakban a látogatói létszám a szokásosnál nagyobb lehet de előre nem tudjuk éppen mennyi. Ezekben a napi időszakos csúcsokban is teljes mértékben változatlanul kell működnie az áruháznak, zavartalanul és folyamatosan kell kiszolgálnia a látogatói kéréseket. A nagyobb csúcsokkal rendelkező vagy egy alultervezett virtuális szerverkörnyezet nem tudja optimálisan kiszolgálni a kéréseket. Több virtuális szervert összefűzhetünk egy saját klaszterbe. A saját klaszterünk pedig szolgáltatja azt, amire szükségünk van. Nagy előnye, hogy az erőforrások dinamikusan megoszthatóak. Az adott terheléshez igazíthatóak. Ilyenkor nekünk kell gondoskodni a terheléselosztó megoldásról. Általában egy klaszterben működő webáruházat is fel kell készíteni az ilyen működésre, mivel a kérés a klaszter bármelyik gépéről történhet. Elég ha csak a munkamenetek kezelésére gondolunk de számos egyéb kapcsolódó kérdés is felmerülhet még. Minden olyan kérés, ami egy adott állapottal rendelkezik, klaszter környezetben a kiszolgálására egy megoldást kell kidolgozni.

6. Felhő megoldás

A felhő megoldásoknak számos előnye van, ezek közé tartozik a skálázhatóság és a költséghatékonyság, amennyiben a tervezés és a konkrét kialakítás során figyelembe veszik az általa biztosított szolgáltatásokat. A felhőszolgáltatásokon belül lehetőség van egy külön környzet, platform bérlésére is, így nem kell törődnünk az alsóbb, ezt megvalósító rétegekkel. Az ilyen megoldást nevezzük Plaform as a Service (PaaS) modellnek, ahol az adott szolgáltató biztosítja a hálózatot, szervereket, tárhelyet és egyéb szolgáltatásokat. Segítségükkel az adott szolgáltatás skálázhatóvá és biztonságossá válik. Egy adott, már kész és szabadon letölthető áruház nem feltétlenül működtethető ilyen környezetben, mert elképzelhető, hogy specifikus kiegészítőkre lehet szükség, amit az alapszolgáltatás nem tartalmaz. Ha a teljes további alsó réteg felügyeletére van szükség akkor jöhet számításba az infrastuktúra, mint szolgáltatás (IaaS), amit az igényeink szerint állíthatunk össze és skálázhatjuk tetszőlegesen. Az IaaS használatával a teljes infrastuktúra megvásárlásának és felügyeletének teljes költsége alól mentesülhetünk, minden erőforrás szolgáltatásként vehető igénybe és az adott használat után fizetünk. Tehát célszerű egy jól kialkított és optimalizáltan működő alkalmazást készíteni. A felhőszolgáltató az infrastruktúrát felügyeli, mi pedig az adott rendszer működéséhez szükséges rendszer telepítéséért, adott konfigurációk összeállításáért vagyunk a felelősek. Lehetőség van a saját gépünkön kialakított konténerek telepítésére egy adott IaaS környezetbe is, így elérhetjük, hogy a fejlesztés és az éles működés során egyáltalán semmi különbség ne legyen, ez a hibakeresés és optimalizáció során jelenthet nagy segítséget.

Üzemeltetési szempontból a következő kérdések lehetnek hasznosak:

Mekkora a már regisztrált ügyfelek száma?
Mekkora a napi átlagos látogatói száma az áruháznak?
Mekkora a legnagyobb napon belüli látogatói szám és az ingadozás?
Mennyi termékkel rendelkezik az adott áruház?
Mennyire biztonságos az adott megoldás?

A fenti kérdésekre a válaszokat akkor tudjuk meg, ha az erőforrások pontos terhelését folyamatosan monitorozzuk. A teljesítmény folyamatos nyomon követésének számtalan előnye van, segítségével tudjuk finomhangolni és optimalizálni az áruházunkat. Az osztott tárhelyen erre nem sok lehetőségünk van, az adott szerver terhelési adatait fogjuk megkapni és olyan feltételek mellett, amit az adott szolgáltató biztosított. Egy adott konténerbe elkészített alkalmazásunkat tetszőlegesen adott időre, (mivel akár pár órára is létre tudunk hozni egy teljes infrastruktúrát) IaaS környezetbe telepíthetjük ahol különböző forgatókönyvekre elkészített terheléses teszteket tudunk végrehajtani, így a valós működéshez hasonló körülményeket tudunk előállítani. Ez azért fontos, mert egy bármilyen webes megoldás, így akár egy webáruház is, függetlenül, hogy saját vagy már szabadon letölthető megoldásról van szó tesztelhetünk, megismerhetjük a határait. A legtöbbször ilyenkor derülnek ki a rosszul megtervezett vagy lekódolt folyamatok, helytelen konfigurációs beállítások. Egy webáruház, benne egy darab termékkel a saját, lokális környezetben mindig jól fog működni és rácsodálkozunk ha terhelés alatt nem az elvárásaink szerint működik.

Ahhoz, hogy hatékony webáruházunk legyen, az üzemeltetés folyamatossága mellett másra is szükségünk van. Egy kicsit bővebben összefoglaltam már, hogy véleményem szerint mi szükséges ehhez, a cikket innen lehet elérni.