A ShopRenter szerződésben garantálja, hogy a 0-24 órás szolgáltatási szintet évi 99,9%-os rendelkezésre állassal teljesíti a webáruház üzemeltetők számára.
Azonban a statisztikáink szerint ma már inkább a 99,99%-os rendelkezésre állás valósul meg, ami maximálisan évi 50 perc leállási lehetőséget biztosít a szolgáltatásunk számára, előre tervezett és bejelentett karbantartási időkkel és egyéb problémákkal együtt.
A szám mögött fejlesztőink kitartó munkája mellett egy olyan technológiai megvalósítás áll, amelyről eddig kevés szó esett.
Ugyanakkor az ünnepi időszak közeledtével szerettük volna, ha az ügyfeleink belátnak a színfalak mögé, és megértik, mi biztosítja számukra azt, hogy a webáruházuk a legnagyobb forgalmi időszakban is stabil és gyors marad.
Előzmények
2016-ban a ShopRentert használó webáruházak átkerültek az Amazon Web Services felhő alapú szervereire. Célunk az volt, a korábbiaktól nagyobb fokú stabilitást érjünk el.
Még ebben az évben nyilvánvalóvá vált számunkra, hogy az év bizonyos időszakaiban a megnövekedett forgalom miatt a szerverek leterheltsége olyan nagyra nő, hogy már a legnagyobb (legtöbb maggal rendelkező) szerverek bérlésével sem tudjuk megoldani maradéktalanul a problémát. Így ezekben az időszakokban fennállt a kisebb-nagyobb leállások veszélye.
Podosítás
Ezért döntöttünk úgy, hogy 2017-ben megkezdjük az adatbázis feldarabolását, amely lehetővé tette számunkra, hogy a korábbiaktól eltérő módon skálázzuk fel a szervereinket és akadálytalanul lekövethessük azt a nagymértékű, dinamikus fejlődést, amit a ShopRenter-es webáruházak évről évre véghez visznek.
Az adatbázisok feldarabolásával egyidejűleg az architektúrát is fejlesztettük, így egy olyan teljesen izolált környezetre is szert tettünk, amely probléma esetén minimalizálja a leállásokat.
Ezt hívjuk mi podosításnak, amely során létrehozunk egy podot, egy teljesen izolált környezetet saját erőforrásokkal, amelyen adott számú webáruház fut egyszerre.
Az izolált környezeten kívül persze vannak még megosztott erőforrásaink is, mint például az adat tárolók vagy a terhelés elosztók (load balancer). Fontos, hogy az összes megosztott erőforrás mindig csak egy poddal kommunikál egy időben – így elkerülhető, hogy bármilyen művelet a podokon keresztül terjedjen.
Ez számunkra teljes körű skálázhatóságot (kapacitásbővítést) ad és mivel nem függenek egymástól a környezetek (podok) és nincs közöttük kommunikáció, ezért egy új pod hozzáadása, nem okozhat váratlan hibát már meglévő podoknál (így az azokon futó webshopoknál sem).
Működés közben
Hogy kell ezt elképzelni a gyakorlatban? Honnan fogja tudni a rendszer, hogy hova küldje a kéréseket?
Amikor beérkezik egy kérés a terhelés elosztó felé, akkor egy általunk LUA szkriptbe megírt kóddal módosított NGINX szerver fogja a bolt domain alapján az adatbázisban tárolt adatok szerint összekapcsolni a hozzá párosított podot és továbbítani a terheléselosztó végpontjához.
Azokat az információkat, amelyek ahhoz szükségesek, hogy tudjuk a bolt melyik podon fut, (és az ezekhez szükséges erőforrásokat) adatbázisban tároljuk és ezt cache-eljük, hogy ezekkel a lekérésekkel se terheljük az adatbázis szervereket.
Összegzés
Leegyszerűsítve a fentieket, a pod nem más, mint egy teljesen különálló webáruház motor, ami sem fejlesztésben sem pedig erőforrásban nem szenved hátrányt. Amennyiben a pod eléri az általunk gondolt kapacitást, akkor a háttérben elindítunk egy új podot, hogy a meglévő webáruházak teljesítményére és stabilitására semmilyen hatást ne gyakoroljon a megnövekedett forgalom.
Ezért fordul elő néha, hogyha az egyik webshopban szerveres és fejlesztési problémát tapasztalunk, egy másikban boltban nem feltétlenül lesz jelen (csak ha ugyanazon a podon fut a két webáruház).
Természetesen a technológia háttér a fentebb leírtaknál sokkal bonyolultabb, de a cikk célja nem az volt, hogy belemenjünk a szakmai részletekbe.
Csak szerettük volna felhívni a figyelmet arra, hogy a podosítás pozitív következményei itt vannak velünk nap mint nap, csak eddig nem feltétlenül tudtunk róluk. Segítségével
- ellenállóbbá vált a rendszer a külső behatások ellen,
- probléma esetén gyorsabb lett a helyreállítási folyamat,
- könnyebbé vált az új funkciók tesztelése,
- egyszerűbb lett az új technológiák bevezetése, és
- skálázhatóbbá vált a növekedés.
Más szóval a rendszer részekre bontásával a problémák kezelhetőbbé váltak, így olyan módon építhetjük tovább a ShopRentert, amely azelőtt nem lett volna lehetséges.
