A Nexogen és hazánk egyik legnagyobb logisztikai vállalkozása, a Waberer’s közös Azure projektje minden olyan informatikai beszállító számára fontos iránymutatást ad, akik gondolkodnak a Kubernetes többszintű bevezetésén. Az izgalmas munka hátteréről Kemény Attila, a Nexogen fejlesztési vezetője tartott előadást egyik webinárunkon, ahol részleteiben is körüljárta, hogy mit tapasztaltak az Azure és AKS alapon történt logisztikai alkalmazás fejlesztés során.

Fejlesztés egy rendkívül szabályozott környezetben

Egy olyan cégnél, amely több ezer kamionnal dolgozik és ahova naponta akár ezernél is több megbízás fut be, kell egy olyan informatikai rendszer, amely a feladatokat egészben kezeli. A rendszer kidolgozásánál olyan elemi szempontokkal is számolni kellett, mint az európai sofőrszabályozás, határátkelők megválasztása vagy éppen az olcsó parkolási lehetőség.

Mindezt figyelembe véve a logisztikai cégnek egy olyan tervet kell kiküldenie az adott sofőrnek, amely érthető, végrehajtható és nem sért meg semmilyen szabályt.

A Nexogen használja az AI-t, aminek a jelentése itt nem a szokványos értelemben vett mesterséges intelligencia, hanem Algorithmic Intelligence, tehát amikor egy cég olyan core operációt épít, amely manuálisan már nem ellátható, és ezért a folyamatok komolyabb algoritmusok, illetve heurisztikák támogatásával tudnak működni a logisztikai optimalizáció érdekében.

Tapasztalatok az AKS architektúra kialakításáról és annak előzményeiről

A hatalmas flották kiszolgálása jól optimalizált informatikai hátteret igényel a partnerek számától és méretétől függetlenül. A logisztikai cégek elvárásai ezért igen sokrétűek. A Waberersnek épített klaszternek teljesen más virtuális géptípus felel meg, mint azoknak az algoritmusoknak, amelyeket a Nexogen általában futtat. Az architektúra a következő szempontok alapján állt össze:

1. Skálázódás

  • Multitenant környezet (több nagy ügyfél teljes flottájának kiszolgálása)
  • PTV
  • AP: kevés, de hosszan futó
  • IP sok, de rövidebben futó

Az erre épített algoritmus működésének nagyon különböző a karakterisztikája: ügyfelenként, nagyjából óránként lefut. Ám akkor akár 10-20 percig fut jelentős CPU és memóriaigénnyel.  Az útvonaltervezés pedig kamiononként fut, és ezek a járművek mind-mind egy különálló egységet képeznek a szisztémában. Ezekből egyidejűleg több fut egyszerre különböző – többnyire rövid – ideig. Az útvonalakat le is követi, végül megkapja a GPS-koordinátákat és a metrikákat, amelyek alapján monitorozni lehet, hogy az adott kamion tartja-e az útvonalat, a tervezett helyen állt-e meg parkolni.

2. Könnyű fejlesztés

  • Matematikus csapat támogatása (a klasszikus szoftverfejlesztési feladatok átvállalásával)
  • Állapotmentes megoldók (solver) készüljenek, hogy könnyű legyen skálázni
  • Pipeline-ok kialakítása, pl. az egyes lépések párhozamossá tétele miatt

3. Később: UI és API integrációk kezelése

  • Sebesség minden tekintetben

Mennyire és milyen áron lehet gyors a rendszer?

A gyorsaság tekintetében a Nexogen már a kezdetektől fontosnak tartotta a metrikák gyűjtését és ezek kijelzését egy dashboard-on, illetve erre egy alerting rendszer kiépítését. Ugyancsak lényeges, hogy a mért KPI-k folyamatosan változnak, finomodnak és bővülnek. Fontos az Azure költségek kordában tartása, illetve a jó tag-elés és riportok elkészítése. A tervezési idők, a queue-hosszok, a VM és DB terheltségek, illetve a tervezések száma (tenant-onkéntis) is lényeges.

Fontos, hogy az erőforrások jól fel legyenek taggelve, hogy részletes havi kimutatásokat lehessen készíteni. A dashboardon nyomon követhető a kihasználtság, és ebből tudhatható, hogy hol érdemes új gépeket beállítani a sorba. Figyelni kell azt is, hogy van-e olyan hely, ahol esetleg túl nagy a klaszter, és lehet spórolni a lejjebb skálázással. A gépek rezervációja is alkalmazható a terheltségtől függően, amely akár befoglalható 1-3 évre előre, ezáltal jelentősen csökkentve a költségeket.

Tapasztalatok az indulásról:

  • Könnyű setup, gyors haladás, (már meglévő eszközök) docker-compose-ok használata
  • Kezdeti terhelésre és felhasználásra megfelelő volt
  • VMSS skálázás (Virtual Machine Scale Set)
  • A Rancher nem tolerálta a napi több 10.000 konténer leállítását-indítását
  • Sok container indítása és állítása megviselte a rendszert
  • A leállított konténerek sokáig nem kerültek eltakarításra
  • Kiestek teljes node-ok (gépek) a clusterből (újraindítási kényszer)
  • A UI is teljesen elérhetetlené vált esetenként
  • A támogatottsága is lejárt

Noha a folyamatok az elején gyorsan és jól mentek, az idő előrehaladtával egyre nagyobb lett a terhelés a klaszteren, és mind több computation-t kellett futtatni, emiatt egyre nagyobb hangsúlyt kapott, hogy ne akadjanak össze a folyamatok. Fontos volt, hogy ha két ügyfél tervezése ugyanakkor indul, az ne érintse a tervezési időket, ezért folyamatosan skálázni kellett.

Ezért és így álltak át a Kubernetes-re

Jelenleg a Rancher 2.0-ban már kizárólag Kubernetes-t támogatnak. A Wabererers úgy döntött, hogy nem a Rancher-rel folytatja tovább, mert nem akart még egy absztrakciós réteget a partner és a Kubernetes között tudni.

Az átállás kezdetben nagyobb befektetést igényelt, hiszen felhúztak egy AKS klasztert a Rancher klaszter mellé, össze peer-elték, és folyamatosan migrálták át a szolgáltatásokat.

A Rancher és az AKS különbségei – eszköztár meghatározás

  • Skálázázódás alapja
    Rancher-nél: VMSS (Virtual Machine Scale Set)
    AKS-nél: Node pool (ebből csak 1 géptípus hozható létre)
  • Skálázás:
    Rancher-nél: Azure autoscale
    AKS-nél: KEDA (Kubernetes Event-driven Autoscaling, ami rugalmasabb, több lehetőséget ad)
  • Konfigurációs eszközök:
    Rancher-nél: Docker-compose
    AKS-nél: customize

Ezt tapasztalta a fejlesztő csapat az AKS-re való átálláskor

  • Kiszámíthatóbb, jobb, hatékonyabban és könnyen üzemeltethető rendszer
  • Jó az AKS dokumentációja, érdemes megérteni a koncepciókat (RTFM)
    (Érdemes tudni, hogy mikor kell Scale set, Statefulset vagy Daemon set-et használni)
  • A Kubernetes nem támogatja a Swap-et (tiltva van az egyes node-okon a Swaping)
  • Megfelelő CPU és memorylimitek és requestek beállítása a szolgáltatásokhoz
  • Probe-ok használata (jobban szabályozhatóak ezáltal a folyamatok, ez hiányzott a Rancher-ből):
    – Readyness
    – Liveness
    – Startup

A 3. a Startup Probe, amelyet ott ajánlatos alkalmazni, ahol olyan szolgáltatások futnak, amelyek nagyon lassan inicializálódnak. Itt a Readiness probe-bal nem lehet túl jó megoldást adni. Erre viszont kiváló a Startup probe. Amíg a Startup Probe nem fut, addig a Liveness és a Readyness Probe-okat nem is futtatja a Kubernetes.

Az AKS nehézségei

  • Hibára futott node-ok takarítása (A napi 10-20.000 node 1%-a hibára fut)
  • Verzió frissítések kikényszerítése
  • Dokumentációból nehéz kihámozni a változásokat
  • Nem kaptak VM-t decemberben
  • Cluster subnet szabályok változtatása

Jövőbeli irányok – az AKS és Azure-ben lévő lehetőség kiaknázási lehetőségei

  • Virtual node-ok használata (node-ok gyorsabb beállítása a költségoptimalizációért)
  • Azure Functions (Cél, hogy saját serverless ökoszisztémán kívül is futtatatóak legyenek egyes lépéseket)
  • Rugalmasabb skálázódás

Ezzel a résszel véget ért a 2021 őszi nagy Azure Kubernetes sorozatunk. Ha kíváncsi vagy az előző részeinkre, itt éred el őket:

Amikor a örökölt „csontvázak”-ból is értéket teremt az IT: így működik a Legacy alkalmazás migráció és az AKS

Így építsd fel az ügyfeled Kubernetes hátterét: példák és megoldások szakértői szemmel

A teljes webinárt itt találod meg.

A 2009-ben alapított, 100%-ban magyar tulajdonú, budapesti vállalkozásunk, a Kvazar.cloud több száz viszonteladó partnerrel dolgozik együtt. Mi vagyunk az egyik legnagyobb Microsoft felhőszolgáltatás-közvetítő partner Magyarországon. Hogy mi köze van egy Microsoft disztribútor cégnek a cloud native technológiához? Elsősorban az, hogy a hagyományos disztribúciós szerepkörből felhőszolgáltatás-közvetítővé (közvetett CSP disztribútor) léptünk elő.

Lépj kapcsolatba velünk!