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.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.