Webshop üzemeltetés

Hogyan biztosítjuk a webáruházak stabilitását? – Interjú a Shoprenter DevOps vezetőjével

7 perc olvasási idő DevOps Engineer - stabil webáruház rendszer

A Shoprenter Magyarország vezető bérelhető webáruház rendszere, több mint 5 500 ügyféllel dolgozunk együtt nap mint nap. Az ügyfeleinket folyamatosan támogatjuk abban, hogy a saját vállalkozásuk piacvezetővé váljon a Shoprenter ökoszisztéma segítségével.

Mindehhez az ügyféltámogatáson, a marketingen, az értékesítésen, és persze az elhivatott vállalkozókon túl szükség van egy biztonságos és stabil rendszerre. Mindezek együttesével valósulhatott meg az, hogy a webáruház tulajdonosok a legnagyobb biztonságban tudnak az üzletre fókuszálni.

Krajcsik Gáborral a Shoprenter infrastruktúrájáért, és rendelkezésre állásáért felelős munkatársunkkal beszélgettünk:

  • Hogyan védjük meg a webáruházakat az esetlegesen “hacker” támadásoktól? 
  • Hogyan tudjuk biztosítani a rendelkezésre állást, és hogy a webáruházak a legnagyobb forgalmak idején is zökkenőmentesen üzemeljenek? 
  • Hogyan is dolgozik a DevOps csapatunk a Shoprenternél? – Krajcsik Gáborral beszélgettünk, aki a Shoprenter infrastruktúrájáért, és rendelkezésre állásáért felelős.

Tech leadként dolgozol a Shoprenternél, mi a feladatod ebben a szerepben?

DevOps csapat vezetőként nekem az elsődleges munkámhoz tartozik, hogy olyan rendszert tervezek meg, ami biztonságosan ki tudja szolgálni a növekvő boltok számát és ezeknek a boltoknak folyamatosan növekvő forgalmát. Mindezt persze teszem úgy, hogy figyelemmel kísérem a folyamatos rendelkezésre állást, vagy az azonnali helyzetekre való reagálást, ha arra van szükség.

Mindemellett a feladatom közé tartozik persze a csapatom menedzselése is.

Hogyan, milyen eszközöket használtok arra, hogy leállás nélkül üzemeljenek a webáruházak? 

Modern technológiákkal dolgozunk, mint például az Ansible, MySQL, Docker, és így csak a legfontosabbakat említettem. Jelenleg nagyon sok eszközt használunk, hogy minimalizáljuk a lassulásokat és leállásokat. 

DevOps eszközök

Ennek feltétele hogy automatizáljunk mindent és arra törekedjünk, hogy csökkentsük az emberi beavatkozást és annak a hiba lehetőségét.

Minden szolgáltatásainkat monitoringozuk, és ha valamelyik a tűrésküszöböt eléri, akkor hiba vagy leállás mértékétől függően sms vagy azonnali hívást kapunk a rendszereinktől.

A csapatunk 0-24 órába figyeli a rendszert és beavatkozik egy probléma esetén. Minden problémánál hibajegyet hozzunk létre és priorizáljuk aszerint, hogy mennyire kritikus és mennyire időszerű lehet a gond.

Csapatnak milyen célkitűzés van az SLA elérésével szemben? (Service Level Agreement)

Az ÁFSZ-ben 99,9%-ot írunk, de nekünk a célunk a 99,99%-os rendelkezésre állás biztosítása, viszont olykor vannak nehezítő tényezők, mint például a kiberbűnözés. Évente többször megpróbálják lebénítani a mi rendszerünket is, és ezek valamikor előre jól átgondolt, megtervezett támadások, különböző országokból és bot hálózatok használatával. Néha az ilyen támadások akár több napig is szoktak tartani, de a kollégákkal azonnal a megoldásokon dolgozunk. Első lépésként kiderítjük, hogy hova érkezik a támadás, majd ezt követi, hogy kiderítjük, hogy honnan, kik támadhatnak minket.

Persze vannak amatőrebb módon próbálkozó “hackerek” is, akik egy IP címről mindenféle védelem nélkül próbálkoznak. 

A nagyobb támadásokból anyagi kár nem történt, ideiglenes megbénulás volt tapasztalható, ez akár többször is több percre, de semmiféle adatvesztés nem történt sem a Shoprenter számára, sem pedig a webáruház tulajdonosainak sem.

Meg vannak ehhez a védelmi szoftvereink, és folyamataink, praktikáink, hogy elhárítsuk ezeket a támadási kísérleteket.

Több olyan cégről is hallhattunk mostanság, akiket hasonlóan nagy támadás ért, és súlyos károkat okoztak a hackerek. Ilyen volt például tavaly a Magento webshopokat ért támadás, vagy idén a UNIX Autót ért hackertámadás. Mi folyamatosan úgy dolgozunk, hogy amennyire lehet felkészüljünk a lehetetlenre. 

Fel vagyunk készülve például akár egy teljes leállásra is, és helyre tudjuk hozni egy napon belül az adatokat, egy másik adatközpontban vagy esetleg egy másik szolgáltatónál. Az adatainkat több helyen is tároljuk, tehát tényleg mindent megteszünk azért, hogy biztonságban tudjuk a teljes Shoprenter rendszerét.

Melyik volt az eddigi legnagyobb kihívás, amivel találkoztál az üzemeltetéskor?

Úgy gondolom nagyon sok kihívás van egy SaaS termék üzemeltetésnél, de talán a legnagyobb ennek a rendszernek a horizontális és vertikális skálázása, amit megkövetel az ügyfeleinknek a forgalma, vagy a kiemelten fontos időszakokban, a karácsonyi és Black Friday napokon. Az új technológiák mint pl a docker bevezetése sokat segített a célunk elérésében. 

Ha egy konkrét példát kellene említenem, akkor legnagyobb kihívás és áttörés a “podosítást” említhetném, amelyben megoldottuk a vertikális skálázásnak a korlátait,ami az adatbázis rendszereknél volt jelen.

Az eredő problémánk ott kezdődött, hogy minden boltnak az adatbázisai egy darab adatbázis clusterbe volt, és már olyan mértékű volt a master-slave replikációban a master adatbázis szerverünk, hogy nem tudtunk vertikálisan tovább skálázódni, mert már AWS-ben nem volt lehetőségünk nagyobb típusú szervert bérelni.

Felmerült kérdésként, hogy hogyan tovább?

  • Hogy tudunk így 1 év múlva kezelni egy nagyobb karácsonyi időszakot?
  • Hogyan fogjuk tudni az üzleti növekedésnek megfelelni?
  • Hogyan tudjuk kezelni egy esetleges adatbázis lassulást, ha nem tudjuk skálázni? 

Több irányból meg lehet közelíteni ezeknek a problémák megoldását, ami további kérdéseket hozott magával:

  • Mennyi emberi erőforrás kell hozzá, hogy meg tudjuk oldani?
  • Milyen rétegbe kell, hogy tartozzon a megoldás?
  • Mennyivel fogja növelni vagy csökkenteni a komplexitást architekturális vagy alkalmazás oldalon?

Szóval nagy feladat előtt álltunk, tele kérdésekkel, de azt gondolom, hogy sikerült megoldást találnunk annak minden előnyével és hátrányával.

A választásunk az architekturális módosításra esett, amely a terheléselosztó szerverünkbe LUA script segítségével történik, amely minden egyes kéréskor lefutva megfelelő podra irányítja a kéréseket. Lua script egy adatbázisba tárolt táblából szedi ki egyszer, hogy melyik útvonalra kell küldeni az adott bolthoz a requestek. Ezek az útvonalak gyorsítótárba vannak elmentve és mindig a bolt mozgatáskor invalidáljuk ezt, hogy ezzel is csökkentsünk az adatbázis terhelését.

Hogy miért került az architektúrás rétegbe?

A Shoprenter egy komplex webáruház motor és nagyon sok funkciója van, alapból egy nagy monstrum és robosztikus kód van mögötte, nem szerettünk volna tovább növelni ennek a komplexitását, hogy még arról is gondoskodjon, hogy hogyan skálázzuk az adatbázis függőségét is. Illetve úgy gondoljuk hogy alkalmazásnak nem kell tudni róla, hogy valójában milyen környezetben van, legyen az cloud vagy fizikai szerverek (bare-metal) . Az alkalmazás a funkciók sokaságáról kell, hogy szóljon.

Az implementálást legjobban még az nehezítette, hogy vannak közös erőforrású több olyan php scriptek, amely használja az összes adatbázist, pl.: egy statisztikánál.

Erre a megoldásra a jól ismert proxysql alkalmazást használjuk. Az webáruház motor továbbra sem tud róla, hogy létezik olyan, hogy POD, csak egy új mysql kapcsolódási belépési pontot kap meg, ezzel tudja aggregálni az adatokat az összes adatbázis táblából.

Ezzel, hogy podosítást végeztünk a rendszeren, kapunk olyan pozitívumokat is, hogy csak a boltok egy részénél kapják meg az új fejlesztéseket, hogy ezzel csökkentsük a fejlesztők felé a rizikófaktort és növeljük ezzel az ügyfél elégedettséget. Néha vannak rizikós fejlesztések, amit így nyugodtan lehet feltenni..

Az új architekturális módosításnál nagy szerepet játszott a biztonság és a rendelkezésreállás is, az új úgynevezett podok teljes önálló üzembe tudnak lenni egymástól és így kár különböző adatcentrumba vagy akár különböző szolgáltatóknál is tudnak üzemelni a boltok, ezzel még jobban figyelve az adatbiztonságra.

Amit biztos, hogy elmondhatok: több podnál több probléma is előjön, de általában kisebb gondokkal találkozhattunk az elmúlt időben. Ezáltal hogy több podunk van, ez így emberi erőforrást is igényel ezeknek a podok karbantartása, tehát érdemes minél alacsonyabban tartanunk ezt a számot. 

Hogyan dolgozik a csapat? Hogyan osztjátok el a feladatokat?

A csapatunk agilis módszertan szerint dolgozik és ezenbelül is kanban rendszerben, hogy minél hamarabb tudjunk reagálni a problémákra. 

A csapatunknak van egy víziója amihez kapcsolódik egy roadmap, amit negyedévről-negyedévre felülvizsgálunk, hogy valóban ez kell, hogy megvalósítsuk a kitűzött céljainkat. 

A feladatok szétosztására vannak rendszeres tervező meetingjeink, valamint egyéb megbeszélések támogatják, hogy ezek meglegyen valósítva. 

Például napi standupot szoktunk tartani, ahol mindenki beszámol, hogy mit csinált az előző munkanap és hogy mit fog csinálni aznap. Illetve, ha elakadtunk egy feladattal,  akkor pár percben megbeszéljük, hogy mi lehet a megoldás. Persze, van hogy néha tovább kell boncolgatni, vagy más kolléga közreműködésére is szükség van, akkor egy másik alkalommal beszéljük át a probléma megoldását.

Mindezekre azért van szükség, hogy minden kolléga ismerje a rendszert kívülről belülről, hogy ha esetleg valamilyen probléma merül fel, arra azonnal tudjunk reagálni.

Erika: Nagyon izgalmas projektekkel foglalkoztok, és látszik, hogy hatalmas kihívásokkal álltok szemben, de az is látszik, hogy nagyon élvezed a feladatokat. 

Milyen terveitek vannak a jövőre nézve?

A rendszerünk folyamatosan változik. Mindig is vannak nagyobb projektek, ahol nagyon sok tervezés kell a megvalósítás előtt. Ezekből minden kolléga ki tudja venni a maga részét, ezzel hozzájárulva az adott projekthez,

A 0-24 órás rendelkezésre állás miatt, természetesen az ügyeletben is aktívan részt vesznek a csapat tagja és mindenkinek felelőssége, hogy olyan rendszert teremtsünk, amely megelőzi, hogy munkaidőn kívül a projekteken kelljen foglalkozni, inkább legyen idő mindenkinek  a szabadidős elfoglaltságával foglalkozni. 

A rendszer biztonságos üzemeltetését is szeretnénk folyamatosan finomhangolni és továbbra is  felkészülni egy esetleges nagy problémára, dolgozunk ezeknek a folyamatoknak az optimalizálásán és a rendszer további redundanciájának kialakításán. 

Mire van ehhez szükségetek?

Ahhoz, hogy ezeket az optimalizálásokat véghez tudjuk vinni szükségünk van alapos rendszerismeretre, megfelelő technikai háttértudásra, valamint tapasztalatra nagy  teherbírású rendszer kiépítésében. Nagyon sok eszközünk van, hogy ezt meg tudjuk teremteni. Ezeket mi üzemeltetjük vagy béreljük, hogy ezzel is fókuszba tudjuk tartani a céljainkat. Az IT világban és nálunk is folyamatos naprakész tudással kell rendelkeznünk az új technológiákkal és ennek folyamatos a bevezetése is. Ebben segítségünkre van a CI/CD módszertan, amivel folyamatosan tudjuk ezeket integrálni.

A technológiai háttér, tudáson túl szükségünk van még időre, amelyre a megoldásunk egy új kolléga lehet. 

Éppen ezért is beszélgetek szívesen olyan szakemberekkel, akik számára érdekes lehet ilyen kihívásokkal teli feladatkörben dolgozni.

DevOps

Ha a cikkben említett DevOps Engineer pozíció felkeltette az érdeklődésedet, jelentkezz hozzánk, vagy látogass el a karrier oldalunkra, és nézd meg, hogy jelenleg milyen nyitott pozíciónk vannak.

Fogalomtár:

SaaS termék: Software as a Service

Rendelkezésre állás: egy alkalmazás vagy erőforrás, mikor a működésének képes eleget tenni, képes feladatokat fogadni, működni. Értékét százalékban adják meg. Szerverek esetén ez az az idő, amikor képesek kiszolgálni a klienseket.

Bot hálózatok: A botnet szó a „roBOT NETwork” angol kifejezésbôl származik. Az elsô robotnak nevezett programok az Internet úgynevezett IRC (Internet Relay Chat), internetes beszélgetési szolgáltatásához kapcsolódóan jöttek létre, és olyan feladatokat láttak el, mint üzenetek átadása, üdvözlés, bizonyos jogosultságok biztosítása stb. Ezeket a távirányítható, illetve programozott robotokat kezdték el röviden „bot” néven említeni. Késôbb jelentek meg a rosszindulatú céllal létrehozott „botok”, sokszor továbbra is az IRC hálózaton át koordinált szoftverek, amelyek összehangolt támadásokat tudtak indítani. A „botok” elôre programozott feladatot hajtanak végre, például kéretlen reklámleveleket (spam) generálnak és továbbítanak, vírusokat terjesztenek vagy DoS (Denial-of-Service – szolgáltatásmegtagadásos) támadásokat visznek véghez.

Agilis módszertan: Az agilis szoftverfejlesztés a szoftverfejlesztési módszerek egy csoportja, ahol a szoftverkövetelmények és a megoldások együttműködésen keresztül együtt fejlődnek az önszerveződő és keresztfunkcionális csapatok között. Ez elősegíti az alkalmazkodó tervezést, az evolúciós fejlesztést, korai szállítást, folytonos továbbfejlesztést és bátorít a változásokra adható gyors és rugalmas válaszokra.

Kanban rendszer: A kanban jelentése kártya, jel, tábla, azaz vizuális megjelenítés. Rugalmasan lehet követni a megrendelői igényeket. A Lean szerint a Pull, azaz a húzóelv érvényesül, tehát akkor történik valami, ha bármiféle termékre, folyamatra igény áll fenn. Egyszerűen mondva ha el kell végezned egy feladatot, ezt vizuálisan láthatóvá teheted.

CI/CD módszertan

  • Continuous Integration (CI): folyamatos integráció
  • Continuous Delivery (CD): folyamatos szállítás.

Legfrissebb bejegyzések

Előző bejegyzés:
Jogi teendők webáruház indítás során
Jogi teendők webáruház indítás során

Ahogyan az elmúlt évek statisztikái is mutatják, az e-kereskedelem a virágkorát éli az Magyarországon, ...Elolvasom

Close