Service mesh és konténerek a banán alatt

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