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.
Ez a weboldal sütiket használ az Ön élményének javítása érdekében. Feltételezzük, hogy ez Önt nem zavarja, de ha szeretné, lemondhat róla. Cookie beállításokELFOGAD
Adatvédelmi és sütikre vonatkozó szabályzat
Adatvédelmi áttekintés
Ez a weboldal cookie-kat használ, hogy javítsa a felhasználói élményt, miközben a weboldalon navigál. Ezek közül a sütik közül a szükségesnek minősített sütiket tárolja az Ön böngészője, mivel ezek elengedhetetlenek a weboldal alapvető funkcióinak működéséhez. Emellett harmadik féltől származó sütiket is használunk, amelyek segítenek elemezni és megérteni, hogyan használja ezt a weboldalt. Ezeket a cookie-kat csak az Ön hozzájárulásával tároljuk az Ön böngészőjében. Önnek lehetősége van arra is, hogy lemondjon ezekről a cookie-król. De néhány ilyen cookie lemondása hatással lehet a böngészési élményére.
A szükséges sütik elengedhetetlenek a weboldal megfelelő működéséhez. Ebbe a kategóriába csak olyan sütik tartoznak, amelyek biztosítják a weboldal alapvető funkcióit és biztonsági tulajdonságait. Ezek a sütik nem tárolnak személyes adatokat.
Nem szükséges sütiknek nevezzük azokat a sütiket, amelyek nem feltétlenül szükségesek a weboldal működéséhez, és amelyeket kifejezetten a felhasználók személyes adatainak gyűjtésére használnak elemzések, hirdetések és egyéb beágyazott tartalmak segítségével. Ezen sütik weboldalon történő futtatása előtt kötelező a felhasználó beleegyezését beszerezni.
