A Tesco nyolc évvel ezelőtt saját kezébe vette IT fejlesztéseit, miután egyértelművé vált, hogy a harmadik felektől származó, több mint ezerféle különböző rendszer és szolgáltatás nagyban korlátozza az áruházi és online vásárlási folyamatok fejlesztési lehetőségeit, az innovatív funkciók bevezetését. A fejlesztéseket a vállalat házon belül a Tesco Technology ágazatba szervezte át, amely mára világszerte több mint 4500 alkalmazottal, modern technológiákra húzza fel az áruházlánc IT infrastruktúráját. A fejlesztői gárda mintegy száz, magasan képzett szoftvermérnöke ráadásul Budapesten dolgozik, akiknek fejlesztései először Nagy-Britanniában élesednek, majd a tesztelést követően "hazaérnek" azaz Magyarország, illetve régiónk más országai, így például Szlovákia és Csehország Tesco áruházaiba is eljutnak.
A házon belül felépített infrastruktúra számos előnyt kínál, azzal a vásárlások nem csak kényelmesebbé tehetők – például az önkiszolgáló kasszáknak hála – de biztonságosabbá is. Ezt a célt szolgálják a budapesti Loss Prevention, illetve a Monitoring, Alerting fejlesztések, amelyeknek köszönhetően valós időben követhető valamennyi kassza állapota. A szakértők így azonnal közbe tudnak lépni az esetleges problémák, meghibásodások esetében, netán akkor, ha az önkiszolgáló kasszáknál a vásárló egy-egy terméket figyelmetlenségből, vagy épp szándékosan nem a hozzá tartozó vonalkóddal olvasna le.
AZ UTOLSÓ KASSZÁIG, ÉLŐBEN
Mindehhez a Tesco Technology rendkívül robusztus monitoring és alerting rendszert fejlesztett ki – a jól skálázható felépítésre pedig szükség is van, hiszen összesen több mint 70 ezer eszközt kell folyamatosan monitorozni, valós időben. A feladatot nem könnyíti meg, hogy eszközönként legalább 30 konténerizált szolgáltatás állapotát kell nyomon követni, amelyeknél 15 másodpercenként zajlik mintavétel és érkezik arról jelentés.
A metrikák begyűjtéséhez a projekt MVP státuszában a fejlesztőcsapat a nyílt forrású, Go nyelven íródott Prometheust használja, amely idősor alapú mértékekkel dolgozik - a logok böngészése a valós idejű adatok kinyeréséhez nem lenne ideális. Az ugyanakkor már látható, hogy hosszú távon a számos területen népszerű Prometheus sem lesz hatékonyan bevethető, annak memóriaéhsége miatt. A jelenlegi fejlesztési fázisban a szolgáltatás mintegy 13 ezer eszközön folytatja a scrapinget az adatok kinyeréséhez, ehhez pedig a szoftverstack bő 1 terabájt memóriát használ fel. Ennek feltöltéséhez pedig a rendszer felállási ideje akár fél órára is ki tud csúszni.
A vállalat ezért az adatokat a Prometheusból már most VictoriaMetricsbe vezeti át, a későbbiekben pedig előbbi eszköztől meg is válik - a VicotriaMetrics jóval hatékonyabb horizontális skálázódást ígér, akár hétszer alacsonyabb memóriafelhasználás mellett. A váltást ráadásul nagyban egyszerűsíti, hogy a VictoriaMetrics legalább olyan baráti viszonyt ápol az adatok vizualizációjához használt Grafanával, mint a Prometheus, így "drop in replacementként" fájdalmasan sok plusz konfigurációs feladat elvégzése nélkül munkába állítható.
HÁLÓ A HÁLÓBAN
A metrikák hatékony továbbításához persze megfelelő hálózattal is meg kell ágyazni, ez ugyanakkor nem mindenhol biztos, hogy adott – Skócia hegyei között például van, hogy kifejezetten gyenge sávszélesség áll az áruházak rendelkezésére. Ezért kiemelten fontos a különféle adatfolyamok megfelelő priorizálása, sőt adott esetben akár az offline működés biztosítása is.
Itt a Tesco Technology szoftvermérnökei és hálózati szakértői a nyílt forrású, C++-ban íródott Envoy proxyban találták meg a megoldást. Utóbbival a layer 7 (application layer) helyett layer 4-en (transport layer) oldották meg a priorizálást, a rate limitek beállítását, hogy egy esetleges szoftverfrissítésnél az adott áruház hálózatát ne terheljék le az egyenként akár 3-400 megabájtos konténerek eljuttatásával a kasszákra és különböző eszközökre. Így garantálható, hogy mindig a fizetési és autentikációs folyamatok élvezik a legmagasabb prioritást. Ennek megvalósítása a fejlesztő, üzemeltető és hálózati szakértő csapatok részéről rendkívül intenzív kooperációt igényelt.
Az adatkommunikáció persze nem csak az eszközök és a felhő, illetve az áruházak központi szerverei, azaz a store platform szerverek között zajlanak. A store device mesh hálózatban a különféle eszközök közvetlenül egymással is kommunikálnak. Erre az egyik leggyakoribb példa az önkiszolgáló kasszáknál történő alkoholvásárlás, mikor a pénztár közvetlenül értesíti az adott kasszasort felügyelő kollégát, hogy korhatáros terméket helyeztek a csomagolófelületre. Ő aztán eldöntheti, hogy szükség van-e személyi igazolványt kérni a vásárlótól, vagy annak deresedő halántéka is elég a megfelelő életkor igazolásához. De a kasszáknál leolvasott árukat figyelő, Nvidia Tegra GPU-kra támaszkodó, gépi látásos eszközök is hasonló módon kommunikálnak a pénztárgépekkel. A fejlesztés alatt álló eszközök azt ellenőrzik, hogy az ügyfél valóban két kiló banánnal igyekszik-e távozni, vagy épp egy megegyező tömegű játékkonzollal.
JOBB FÉLNI, MINT MEGIJEDNI
Az említett veszteségekhez hasonló esetek kiszűrése ugyancsak kulcsfontosságú funkciója az áruházlánc saját fejlesztésű rendszereinek, amiért a Loss Prevention csapat felel. A pénztárfigyelő gépi látásásos megoldás kifejlesztéséhez a vállalat dedikált computer vision csapatot állított össze. A fejlesztők először laboratóriumi környezetben, majd később élesben is tesztelik a saját maguk által betanított gépi látási algoritmusokat, amelyek több kockázatelemző algoritmussal karöltve döntik majd el, mikor érdemes közbelépni egy-egy potenciálisan gyanús fizetés esetén.
Ezzel párhuzamosan az önkiszolgáló kasszák mérlegei is okosodnak, azok mögé tanuló súlyadatbázisok kerülnek be. Ha egy helyesen leolvasott termék esetében a mérleg nem az adatbázisban rögzített tömeget méri, jelez a közeli kollégának, aki ellenőrzi a terméket. Ha az alkalmazott mindent rendben talál, megerősíti, hogy valóban a helyes terméket olvasták le, annak tömegén azonban a gyártó változtatott. Az adatbázis ezután az új információval dolgozik majd tovább. Persze az ehhez tartozó algoritmusok megírásában is bőven akad kihívás, hiszen előfordulhat, hogy az eltérések akár a kolléga hibájából vagy éppen a súlyt érzékelő mérlegcella meghibásodásából adódnak - ezeket a helyzeteket is fel kell tudni ismerni.
ROLLOUT!
Nem csak maguk a fejlesztések, de azok célba juttatása sem könnyű feladat, ehhez a vállalat saját rollout folyamatot épített ki, komplex pipeline-nal hogy a 30-40 csapat munkája szinkronizálható, folytonossá tehető legyen, az új szolgáltatásokat pedig fokozatosan tudják teríteni a különböző áruházak több tízezer kasszájára. Az új szoftververziók regisztrálását követően az azokhoz tartozó image-eket először az áruházak fentebb már említett központi szervereire töltik fel, jellemzően hajnalban, amelyek aztán fokozatosan osztják ki a frissítéseket az üzletek kasszáira. Mindez az adatfogalom megfelelő priorizálása mellett zajlik, hogy a vásárlás is zökkenőmentes maradhasson az adott áruházban.
A Tesco Technology fentebb sorolt fejlesztései, amelyek mögött a budapesti csapat áll, még idén élesednek az Egyesült Királyságban és Írországban, 2022 vége, 2023 eleje környékén pedig már a magyarországi Tesco áruházakban is találkozhatunk velük.
A Tesco Technology hazai csapata folyamatosan bővül, ehhez a vállalat főként "V-shaped" fejlesztőket keres: például egy Java fejlesztő esetében a "V" hegye jelöli a mély Java tudást, míg a kiterjedő szárak a különböző, horizontális kompetenciákat tartalmazzák. Ilyen lehet a DevOps vagy épp a prezentációs és üzleti kapcsolattartási képességek, amelyekkel hatékonyan be tudnak kapcsolódni Tesco Technology Magyarországon zajló, globálisan alkalmazott fejlesztéseibe – akár távmunkán keresztül, amit a vállalat maximálisan támogat.
[A Tesco Technology megbízásából készített, fizetett anyag.]
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
wow, ezt öröm volt végigolvasni. végre egy cég akinél "kézzel foghatóbbak" a konténerizációs megoldások, mint pl egy streaming szolgáltatónál.
- A hozzászóláshoz be kell jelentkezni
Jaja, Tescónál eléggé kézzelfoghatóak a konténerek, hiszen abban jön az áru...
- A hozzászóláshoz be kell jelentkezni
Arról lehetne egy cikk, hogy milyen infókat gyűjtenek ki az emberek vásárlásaiból, és aztán ezeket hogy használják fel a célzott reklámokban, szerintem érdekes lenne.
“Any book worth banning is a book worth reading.”
- A hozzászóláshoz be kell jelentkezni
En mar annak is orulnek, ha a raktarkeszletuk aktualis lenne es emiatt nem hianyozna a rendeles fele a kiszallitaskor. :]
- A hozzászóláshoz be kell jelentkezni
Na ja, kegyetlenül idegesítő, ezért szoktunk le róluk.
- A hozzászóláshoz be kell jelentkezni
Van sok cikk a Kiskegyed szintjetol (gondolom ott is volt valami kis szines) a BBC-n at rendes egyetemi es doktori kutatasi anyagokig...
"retail shop card information collection research"
https://www.bbc.com/news/technology-43483426
- A hozzászóláshoz be kell jelentkezni
Hát igen, ilyen az, amikor elszabadul a HR.
- A hozzászóláshoz be kell jelentkezni
" Utóbbival a layer 7 (application layer) helyett layer 4-en (transport layer) oldották meg a priorizálást, a rate limitek beállítását, hogy egy esetleges szoftverfrissítésnél az adott áruház hálózatát ne terheljék le az egyenként akár 3-400 megabájtos konténerek eljuttatásával a kasszákra és különböző eszközökre."
Wow.
- A hozzászóláshoz be kell jelentkezni
Micsoda lightweight technology ez a konténeresdi.
- A hozzászóláshoz be kell jelentkezni
Ha minden szart beleraknak a kontenerbe akkor persze hogy akkora. Mindig az user valasztasa amit rak bele, ez nem a kontenerizacio hibaja. De latom ennyire azert nem ertesz hozza :)
Cserebe viszont mindig az fut a gepen amit szeretnel, es nincs az hogy valaki megbuzeralt rajta valamit kezzel vagy valami update failelt, stb.
- A hozzászóláshoz be kell jelentkezni
Amit írsz, azzal egyetértek.
Ettől függetlenül szerintem érdekes kérdés, hogy miért 3-400 megás az a konténer. Tényleg annyi Tesco kód van benne, vagy csak FROM ubuntu:latest -tel kezdődik a Dockerfile, esetleg adatfájlok miatt lesz ekkora. Utóbbi esetben kérdés, hogy tényleg konténer image-ben a legjobb terjeszteni, vagy lenne rá más megoldás.
Nem azt állítom, hogy rossz a design, ehhez egyrészt nincs elég információm, másrészt nyilván megvizsgálták a Tesconál, hogy számukra mi a legjobb megoldás, de érdekelne, hogy miért pont ezt választották.
- A hozzászóláshoz be kell jelentkezni
ez a kontenermeret a java ill fuggosegei (VM) miatt ekkora. ez pont az egyik gyengesege a javanak, nagy kontenermeretet eredmenyez. ugyanez peldaul goban ket nagysagrenddel kisebb.
- A hozzászóláshoz be kell jelentkezni
Quarkus?
- A hozzászóláshoz be kell jelentkezni
ugy tudom micronaut
- A hozzászóláshoz be kell jelentkezni