Service mesh és konténerek a banán alatt (x)

Címkék

Több tízezer kasszát folyamatosan szemmel tartani nem gyerekjáték, a Tesco saját IT divíziója, a Tesco Technology ezért inkább saját kézbe vette a feladatot – méghozzá Budapesten. A hazai csapat kezei alól kerül ki többek között a hamarosan a teljes eszközparkot élőben figyelő monitoringrendszer, a flotta frissen tartásához szükséges technológiák, sőt a vásárlások biztonságáért felelős algoritmusok is.

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.]

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.

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.

“The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.”

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

https://journals.sagepub.com/home/mre

https://www.ccsenet.org/journal/index.php/ijms

V alakú fejlesztők.

GPLv3-as hozzászólás.

" 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.

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.

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.