Kubernetes microservice-k az (e-)kereskedelemben

Hogyan épített a 4 milliárd dolláros kereskedelmi óriás Elkjøp enterprise-ready Kubernetes platformot?

Az Elkjøp, az északi országok legnagyobb elektronikai kiskereskedője, saját belső Kubernetes platformot épített, ami sikeresen ad otthont több mint 200 production-grade microservice-nek, így gyorsabbá téve a fejlesztést, biztonsági és áttekinthetőségi kompromisszumok nélkül.

Kereskedelmi forradalom microservice-k segítségével

Több mint 400 üzletével, és 12.000 alkalmazottjával az Elkjøp a legnagyobb elektronikai kiskereskedő az északi régióban. Mindezek mellett az Elkjøp az online kereskedelemben is jelentősnek tekinthető a régióban. A cég IT részlege inkább harmadik fél által fejlesztett szoftverek integrálásával foglalkozott, mintsem saját megoldások fejlesztésével. Öt éve azonban ez megváltozott, és a csapat microservice-ek fejlesztése felé fordította a figyelmét.
Eleinte az Elkjøp Azure Web Apps-ban futtata ezeket a microservice-eket, azonban ahogy a szoftverkörnyezet növekedésnek indult, egy új megoldás kellett. „Az Azure Web Apps egy remek platform egyszerű rendszereknek, de amikor akár 70-100 másolata fut egy adott microservice-nek, ezek menedzselése nehézzé és drágává válik” – mondta Henry Hagnäs, az Elkjøp Cloud Solution Architect fejlesztője.
Mindezek mellett, Elkjøp belevágott egy másik „Következő Generációs Kereskedelem” (KGK) névre keresztelt projektbe, ami még jobban microservice-ekre támaszkodik. A KGK hivatása lecserélni a cég 20 éves POS rendszerét, egy flexibilis, skálázható, a cég több osztályán átívelő közös rendszerre.

Az elkerülhetetlen service mesh

A csapat, dockerizálással kezdte meg a rendszer migrálását Kubernetes platformra, azonban hamar rájöttek, hogy nincsenek a megfelelő metrikák birtokában, ahhoz hogy valós képet kapjanak a rendszer tejlesítményéről. Továbbá mivel a TLS-t kikapcsolták az ingress controller-en a microservice-k között kommunikáció titkosítás nélkül zajlott. Mindkét problémát meg kellet oldaniuk, gyorsan.
Hagnäs és csapata technikai kutatás után a Linkerd service mesh-t választotta a problémák megoldására. A Linkerd egy ultrakönnyű, gyors, Cloud Native Computing Foundation (CNCF) service mesh.
A Linkerd egy „micro-proxy” sidecar konténert köt minden egyes microservice-hez. Ez a proxy felelős a kommunikáció titkosításáért, metrikák gyűjtésért, és a microservice-k közti kommunikációba is betekintést nyújt. Pontosan ezekkel a problémákkal állt szemben Hagnäs és csapata.
Az online kereskedelemben az egyik legfőbb szempont a megbízhatóság és a biztonság. A Linkerd által nyújtott biztonság volt az egyik fő érv,ami miatt az Elkjøp platformjának szerves részévé tudott válni.

Kubernetes, kereskedelem, microservice, csak a helyszín más

Fókuszban a Nordstrom történet

A Nordstrom amerikai kereskedelmi vállalat szerette volna felgyorsítani és hatékonyabbá az online kereskedelmi platformját. Ezzel párhuzamosan a technológiai leányvállalat is szerette volna szűkebbre szabni az operációs költségeket.

Minden előrelépés számít, főleg ha jelentős

A Nordstrom Dev és Ops csapata együttes erővel létrehozott egy CI/CD pipeline-t. Mindaddig napokat vett igénybe egy új VM-es fejlesztőkörnyezet létrehozása, a pipeline segítsével ez csupán egy órát vesz igénybe. Azonban még ez is meglehetősen lassúnak bizonyult, így a következő logikus lépés a felhőbe költözés volt.
„A felhő gyorsabb hozzáférést biztosított bizonyos erőforrásokhoz, azelőtt hetekbe telt egy VM létrehozása, ez a folyamat most 5 percbe telik” – mondta Dhawal Patel a Nordstrom senior mérnöke.
Habár a Kubernetes platformot a microservice-ekkel karöltve emlegetjük, azonban a Nordstrom első applikációja ami Kubernetesen futott a Jira volt.
„A csapatok akik a Kubernetes klaszter üzemeltetésével foglalkoztak egyből pozitívumokkal szembesültek, nem kellett számos problémával foglalkozniuk, hiszen a Kubernetes megoldotta ezeket. Nem kellett operációs rendszer telepítéssel bajlódniuk, a gyorsulás egyből szembetűnő volt” – mondta Marius Grigoriu a Kubernetes csapat senior menedzsere.
A Nordstrom számára a felhőbe költözés megkezdése azonnali pozitív következményekkel járt. „Kubernetes segítségével, a klaszter finomhangolása nélkül, már most 40% CPU kihasználtságnál járunk ami egy 10-szeres növekedés. Több mint 2600 ügyfél podot futtatunk, ami a régi rendszerben 2600+ VM-nek felelne meg, ezek a podok most körülbelül 40 VM-en futnak, ez egy hatalmas optimizáció”- mondta Grigoriu.
A Kubernetes automata skálázási képessége és rugalmassága rendkívül vonzóvá teszi a platformot a kereskedelmi iparágban Amerikától Európán át egészen Kínáig.

Több tízezer kasszát folyamatosan szemmel tartani!
Monitoring, Biztonság, Skálázhatóság a Tesconál

A Tesconál egyértelművé vált, hogy modernebb technológiákra kell áttérniük, ha szeretnének az iparág vezetőjévé válni.

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.
Ehhez egyértelműen egy Kubernetes rendszer szükséges a hozzáadott kiegészítésekkel, amivel a rendszer komplexé, és robusztussá válik.
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.

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 így egy mindent lefedő, és skálázható rendszert fejleszt a pontos nyomon követésre és automatizálásra koncentrálva. Ehhez a modern kor technológiáinak csúcsát kellett használniuk és egy mindset transzformációt. A vállalat ezáltal belépett a cloud-native megoldások korába.

Ajánlott Datatronic szolgáltatás a témához...

https://datatronic.hu/dmc/

Források: 

https://buoyant.io/case-studies/elkjop/

https://kubernetes.io/case-studies/nordstrom/

https://www.hwsw.hu/hirek/63568/tesco-technology-service-mesh-kontener-fejlesztes-fejleszto-devops.html?fbclid=IwAR0i6_EaAZw02MjjGTdZcb70gZ0cVVZRd5a8ZWIy_7_LqEsVXpOuHva4qEg

Elérhetőségeink

Szolgáltatások

© Datatronic Kft. 2023 | Minden jog fenntartva

Adatkezelési tájékoztató