A Black Friday kampány sikeres lebonyolítása több részterület egyéni teljesítményétől és sikeres együttműködésétől is függ. Nem elég a megfelelő ajánlatokat kidolgozni és meghirdetni, majd a hirtelen megnövekedett forgalom logisztikai kiszolgálását megszervezni, a webshopnak is felkészülten kell várnia az egy napra koncentrált, jelentős látogatótömeget.
Vannak általános optimalizálási lépések, amelyeknek egész évben hasznát vehetjük, de érdemes lehet őket erre a kiemelt időszakra időzíteni, mert a szerepük ilyenkor hatványozottan megnő. Ezeken felül vannak olyan megoldások, amelyeket kifejezetten az ilyen extrém igénybevételt jelentő napokon érdemes bevetni.
A gyakorlatban bevált tippek következnek mindkét kategóriából, kicsiknek és nagyoknak a túléléshez.
A triviálisnak tűnő alapok
Vannak dolgok, amelyeket annyira triviálisnak veszünk, hogy éppen ezért feledkezünk meg róluk. Az első szabály pont ilyen, fejlesztők és üzemeltetők számára kötelező:
Egyeztess a marketinggel! Milyen akciót terveznek, milyen terhelés várható?
Talán elsőre megmosolyogtató ezt így leírva látni, de találkoztunk a való életben olyan szituációval nem egyszer, amikor az üzemeltető este otthon a TV előtt ülve, az éppen futó reklámblokkból értesült arról a nagyszabású marketing kampányról, amely az általa működtetett rendszerre terelte a látogatókat.
A második szabály a kisebb rendszereket működtető kereskedők számára:
Ha shared hoston üzemel a webshop, egyeztess a szolgáltatóval!
Amikor egy fizikai gépen több, egymástól független szolgáltatás is üzemel az erőforrásokat megosztva felhasználva, könnyen előfordulhat hogy elérjük a rendszer határait. Ilyen esetekben nem biztos, hogy az erőforrások szabadon és gyorsan bővíthetőek, és késő akkor reagálni, amikor a probléma már előállt, egyeztessünk előre a várható igényekről.
Általános optimalizálási lépések
Egy webáruház teljesítéményének optimalizálásásra számos mód van, ezeknek a hatása nem csak kampányidőszakban, hanem a mindennapokban is érezhető. Ha eddig nem került sor ezeknek az ellenőrzésére, akkor egy ilyen koncentrált terhelés előtt mindenképpen érdemes ezekkel foglalkozni, mert akár a túlélést is jelenthetik a shop számára.
Frontend oldali lépések
Általános szabály, hogy érdemes a rendszer felé indított kérések számát, illetve a belső (rendszeren belüli) hálózati forgalmat a szükséges minimumra csökkenteni.
A CSS és JavaScript kódrészletek optimalizálása (minify, összefűzés, gzip tömörítés) elengedhetetlen lépés, valamint ajánlott a cache control header használatával a böngészők gyorsítótárazását is kihasználni. Ennél a megoldásnál érdemes arra figyelni, hogy az érintett URL-ek verziózva legyenek, így szükség esetén biztosítva legyen a megváltozott fájlok újratöltése.
A képek megfelelő formátumban történő tárolása és kiszolgálása csökkentheti a hálózati adatforgalmat, és gyorsíthatja az oldalak letöltését.
A böngésző és a szerver közti kommunikáció során ajánlott a gzip tömörítés használata, amelynek beállítása már részben üzemeltetési feladat.
A frontend oldali feladatok egyesével, manuálisan is elvégezhetőek, azonban vannak olyan megoldások, amelyek egyben igyekeznek levenni ezt a terhet a fejlesztők válláról, ilyen például a Google által publikált PageSpeed csomag, amely Apache és nginx kiszolgálórendszerek esetén nyújthat gyorssegélyt.
Backend oldali lépések
A frontend ellenőrzése után a kiszolgáló oldali megoldásokon, adatbázisokon és kódrészleteken is bőven akad teendő, a lehetséges optimalizálási irányok itt még szerteágazóbbak.
Az adatbázis lekérdezések szűk keresztmetszeteinek feltárása után (slow query logok, explain vizsgálatok) az indexek felülvizsgálata, szükség esetén módosítása, majd ellenőrző mérése stabil kiindulási pontot ad.
Amennyiben a rendszeren akkora lesz a várható terhelés, hogy az egyes táblákon egyidejűleg futtatott olvasási és írási műveletek akadályozzák egymást, érdemes lehet ezek különválasztása, és az adatbázis kapcsolatok újraszervezése. Az elsődleges (master) adatbázis mellé egy replikált slave adatbázist beállítva, valamint a kódot megfelelően hozzáillesztve megoldható az, hogy az adatbázison kizárólag olvasási műveleteket végrehajtó funkciók (pl. kereső) a slave adatbázis tábláit használják, míg az írási és olvasási műveleteket vegyesen alkalmazó funkciók (pl. regisztráció, kosár, vásárlás) továbbra is az így felszabadított master adatbázison dolgozzanak.
A programkód futási idejének optimalizálása állandó feladat, ilyenkor azonban még jobban előtérbe kerül. Az egyes funkciók, modulok, könyvtárak szűk keresztmetszeti pontjait érdemes erre a célra kialakított eszközökkel kimérni (pl. XHprof, Blackfire), majd az eredmények alapján módosítani. Fontos (bár nem teljesen kockázatmentes) részfeladat lehet ilyenkor a már nem használt kódrészletek eltávolítása, valamint a fejlesztés során szükséges, de az éles rendszer kiszolgálása szempontjából csak erőforrásokat pazarló modulok (pl. Xdebug) megfelelő konfigurációja (production környezetben való kikapcsolása).
Ha az adatbázis és a programkód optimalizálása önmagában nem hoz elegendő eredményt, a cache megoldások bevezetése (vagy felülvizsgálata) lehet a következő lépés. A fájl alapú cache használata erőforrás igényes, és sokszor jelent szűk keresztmetszetet, így ehelyett egyértelműen valamilyen key-value store, vagy NoSQL technológia alkalmazása javasolt (Memcached, Redis, MongoDB).
Az egyes lekérdezések eredményének ilyen módon történő átmeneti eltárolásán kívül az elsődleges landoló oldalak (nyitólap, kampány landoló oldal, kampányok során hirdetett cél URL-ek) cache-elése az alkalmazás view rétegében szintén jelentősen hozzájárulhat a látogatási csúcsok esetén a terhelés csökkentéséhez.
Üzemeltetési lépések
Az üzemeltetés felkészülése mindenképpen egy állapotfelméréssel kezdődik, amely tartalmazza az erőforrás tartalékok (CPU, memória, tárhely, hálózati sávszélesség) ellenőrzését, egy több lépcsős terheléses tesztelést (folyamatos mérés mellett, pl. Elastic Beats, Munin használatával), valamint a hálózati sávszélesség tesztelését (rendszeren belül, az egyes virtuális gépek között is).
A rendszer log állományainak ellenőrzése, vizsgálata, azokban a szűk keresztmetszetre, illetve limitek elérésére utaló bejegyzések keresése szintén jó támpontokat adhat.
A kiszolgáló alkalmazások frissítése, a kernel rendszert és szolgáltatásokat érintő beállításainak finomhangolása (pl. nyitott file-ok maximális száma), valamint a TCP kapcsolatok finomhangolása (hálózati áteresztő képesség növelése, keepalive beállítás) alapvetően üzemeltetői feladatok, azonban sok esetben magát az alkalmazást is érinthetik, így itt folyamatos együttműködésre van szükség a rendszergazdák és fejlesztők között – amennyiben ezek a szerepek elkülönülnek.
A kiszolgáló szerverek szerepkörökre bontása – amelynek célja, hogy egy szerver lehetőleg egy szolgáltatásért legyen felelős – könnyebbé teszi az erőforrások kiosztását, dedikálását, és csökkenti a szerveren belüli komplexitást, ugyanakkor növelheti a komplett a rendszerét. Egy ilyen lépés komolyabb tervezést és átállást igényel, így ezt az utolsó pillanatban szükségmegoldásként bevetni már kockázatos lépés – hosszabb távra előre gondolkodva viszont egy bizonyos méret felett már érdemes megfontolni.
Tippek az egynapos túléléshez
A fent felsorolt optimalizálási lépések mind olyan lehetséges megoldásokat adnak, amelyek a webáruház teljes, hosszú távú, funkcionális értelemben kompromisszumoktól mentes működését biztosítják. Extrém terhelés esetén azonban előfordulhat az, hogy ezek a trükkök már nem elégségesek, és vagy egyedi, adott időszakra célzott változtatásokat kell bevezetnünk, vagy valahol áldozatokat kell hoznunk a túlélés érdekében.
Ha a csúcsidőszakra a statikus tartalmainkat ki tudjuk szervezni valamilyen CDN szolgáltatóhoz, az jelentős terhelést vehet le a saját kiszolgáló környezetünkről, ami sok esetben már önmagában életmentő lehet.
Ennek a megközelítésnek egy további fokozata az, ha nem csak statikus elemeket, hanem akár komplett oldalakat szolgálunk ki CDN-ről, például az aktuális akcióban résztvevő termékeinket egy erre a célra kialakított külön oldalon listázzuk ki, amely akár egy subdomainre is kerülhet a könnyebb szétválasztás érdekében. A kampány során az oldalra érkező látogatók nagy részének kiszolgálása, a terméklisták megjelenítése ilyen esetben a CDN-ről történik, és csak azok a látogatók terhelik a saját rendszerünket, akik valóban meg is kezdik a vásárlási folyamatot.
Van, amikor fel kell készülnünk arra, hogy a túlélés és a folyamatos működés érdekében bizonyos – erőforrásigényes – funkciókról átmenetileg le kell mondanunk. Ha ezeket előre átgondoljuk és mérlegeljük, akkor úgynevezett „safe mode” kapcsolókat építhetünk a rendszerünkbe, amelyekkel a terhelés függvényében átmenetileg kikapcsolhatjuk például a termékajánlók megjelenítését, a kereső automatikus kulcsszó javaslatait, a terméklistákban bizonyos szűrési vagy rendezési opciók megjelenítését. Ezekkel az oldal funkcionalitása átmenetileg csökken, azonban mindez annak érdekében történik, hogy a teljes rendszer működőképes maradhasson – természetesen az ilyen beavatkozások csak időszakosan, adott kampány alatt elfogadhatóak, a mindennapos működés során nem.
Mindezt tovább fokozva, a fenti két megközelítést ötvözve akár az is megoldható, hogy az akcióban résztvevő termékeket kompletten egy külön, erre a célra dedikált, akár felhő alapú vagy bérelhető webáruházba szinkronizáljuk fel. Itt kiegészítő funkciók nélkül, a kampányra koncentrálva csak a termékeket és a legszükségesebb opciókat jelenítjük meg, az ezekre vonatkozó vásárlási műveleteket bonyolítjuk le, majd a beérkezett rendeléseket egy újabb szinkron folyamattal a saját rendszerünkbe emeljük át. Egy ilyen architektúra kialakítása és letesztelése már elég komplex feladat, azonban van az az üzemméret és kampány terhelés, amely indokolttá teszi – és láttunk is ilyen megvalósításra példát a közelmúltban a magyar piacon is.
Még nem késő!
A Black Friday napja vészesen közeleg, és a komplexebb átalakítások biztonságos és megfelelően tesztelt kivitelezésére vélhetően már nem mindenhol maradt elég idő és kapacitás. Az alapvető ellenőrzéseket és finomhangolásokat azonban mindenkinek érdemes elvégeznie, a jövő évi felkészüléshez pedig már jó előre sorvezetőt adhat a fenti gyűjtemény.
Kapcsolódó cikkek:
Black Friday: 5 fájdalmas fogyasztóvédelmi hiba, amit jobb elkerülni
