Ako v Innovatrics škálujeme výskum biometrie: od Google Sheet ku Kubernetes

Keď máte desiatky researcherov, obmedzený počet drahých GPU a všetko beží on-prem, problém už dávno nie je len v algoritmoch. Veľmi rýchlo sa ním stane infraštruktúra: kto dostane GPU, ako zabezpečiť férovosť medzi tímami, ako rýchlo onboardovať nového človeka a ako zabrániť tomu, aby drahý hardvér pol dňa zaháľal.

Toto je náš príbeh o tom, ako sme sa dostali zo spreadsheetu k MLOps platforme postavenej na Kubernetes — a čo nám to v praxi prinieslo.

 

Pred platformou: Google Sheet ako scheduler

Pred tromi rokmi sme si GPU rozdeľovali cez zdieľanú Google tabuľku. Fungovalo to približne tak, ako si viete predstaviť: tabuľka nebola vždy aktuálna, ľudia si rezervovali viac kariet „pre istotu“ a medzi tímami neexistoval žiadny mechanizmus férovosti.

Výsledok bol jednoduchý: priemerná utilizácia GPU sa pohybovala okolo 50 %. Polovicu času nám drahý hardvér v podstate len zahrieval miestnosť a researcher, ktorý GPU naozaj potreboval, čakal.

Bolo jasné, že potrebujeme:

• reálny scheduler,
• fronty a férové prideľovanie zdrojov,
• lepší feedback loop pre používateľov,
• a prostredie, ktoré nebude stáť na ručnej správe konkrétnych strojov.

Cloud u nás neprichádzal do úvahy — jednak kvôli veľkosti datasetov, jednak kvôli zmluvným a bezpečnostným obmedzeniam. Takže voľba padla na on-prem Kubernetes.

 

Základ platformy: bare-metal Kubernetes

Platformu prevádzkujeme na vlastných GPU serveroch. Provisioning a základnú konfiguráciu riešime automatizovane cez Ansible, takže konfigurácia strojov je verzovaná v Gite a reprodukovateľná.

Na orchestrace beží RKE2. Persistentné služby držíme na Longhorne, datasety sú dostupné z centrálneho all-flash NVMe úložiska a GPU stack spravuje Nvidia GPU Operator. Sieť, policy engine a ďalšie štandardné vrstvy riešime cez bežný Kubernetes ekosystém.

Dôležité však nie je to, z akých komponentov je platforma poskladaná, ale čo tým získal researcher: nemusí riešiť konkrétny server ani ručný setup infraštruktúrnej vrstvy. O GPU požiada v rámci platformy, zatiaľ čo vlastné runtime prostredie vrátane CUDA si naďalej definuje
cez svoj Docker image.

Kueue: férové queue namiesto „kto prvý príde“

Kľúčové problémy, ktoré sme v Innovatrics chceli vyriešiť, boli dva: scheduling aj férovosť. Nestačí mať cluster — treba vedieť nielen rozhodnúť, ktoré joby sa majú spustiť a kedy, ale aj zabezpečiť, aby jeden tím neobsadil všetky GPU len preto, že ich spustí viac skôr ako ostatní.

Na queueing a fair sharing používame Kueue. Vyhovovalo nám, že nenahrádza defaultný Kubernetes scheduler, ale pridáva nad neho admission vrstvu. Prevádzkovo je to jednoduchšie a zároveň to rieši presne ten problém, ktorý sme mali.

Kľúčovú úlohu u nás hrá najmä fair sharing score, ktoré vie uprednostniť tím, ktorý dlhodobo využíva menej zdrojov, a priebežne tak vyvažovať spotrebu naprieč clusterom. V praxi to znamená, že nejde len o to, kto pošle job skôr, ale aj o to, kto už zdroje čerpal a kto na ne ešte len čaká.

Z pohľadu používateľa je dôležité najmä toto: nestačí „dať prvý kubectl“. Job sa zaradí do systému, ktorý zohľadňuje históriu spotreby aj férovosť medzi tímami.

 

Coder: development prostredie bez ručného setupu

Jednou z vecí, ktoré sme pri prechode na Kubernetes nechceli stratiť, bola interaktivita. V minulosti researcherom stačilo prihlásiť sa cez SSH na bare-metal server a pracovať priamo tam. Nechceli sme, aby prechod na cluster znamenal, že tento spôsob práce zmizne a zostanú
len batch joby a YAMLy.

Preto sme interaktívnu prácu postavili na Coderi. Researcher si vie cez UI alebo CLI spustiť workspace, ktorý dostane persistentné úložisko, prístup k datasetom a podľa potreby aj GPU.

V praxi to znamená, že otvorí prehliadač a má k dispozícii code-server, terminál aj SSH endpoint. Vie sa pripojiť aj zo svojho obľúbeného IDE, takže si zachováva workflow, na ktorý bol zvyknutý aj predtým, len už nad infraštruktúrou, ktorú spravuje platforma. Autentifikácia ide cez
firemné SSO, prístup ku Git repozitárom cez GitLab OAuth.

 

Batch tréningy: Argo Workflows

Argo Workflows používame najmä na joby, ktoré sa dajú rozložiť na viac krokov a spustiť ako pipeline. Motivácia nie je v tom, že ide o „dlhé tréningy“, ale v tom, že vieme granularizovať workflow a lepšie prispôsobiť alokáciu zdrojov jednotlivým fázam.

V praxi to znamená, že GPU nealokujeme na celý beh automaticky, ale len tam, kde to naozaj dáva zmysel. Kroky ako príprava dát, validácie alebo iné CPU-bound fázy nemusia držať drahé akcelerátory zbytočne, zatiaľ čo samotný tréning alebo iné GPU-heavy časti ich dostanú vtedy,
keď ich reálne potrebujú.

Takýto prístup nám pomáha optimalizovať využitie shared resources v clustri a zároveň znižovať situácie, keď drahé GPU drží aj fáza, ktorá ich vôbec nepotrebuje. Výsledkom je efektívnejšie využitie kapacity a lepšie rozdelenie zdrojov medzi joby, ktoré o ne v danom
momente naozaj súťažia.

 

GitOps: ArgoCD a verzovaná infraštruktúra

Celú infraštruktúru držíme v Gite. Manifesty, Helm charty, Kustomize overlaye aj policy konfigurácia sú verzované a rozdelené medzi test a produkčné prostredie. ArgoCD ich kontinuálne synchronizuje do klastra.

Z pohľadu engineeringu to prinieslo niekoľko zásadných vecí:

• každá zmena má autora a review,
• upgrady vieme bezpečne overiť na test clustri,
• rollback je normálna operácia, nie improvizácia,
• a výrazne sa obmedzil config drift.

To, čo kedysi končilo víkendovým debuggingom typu „prečo to na tomto node vyzerá inak“, je dnes oveľa predvídateľnejšie.

 

Observabilita: bez nej by sme len hádali

Ak máte zdieľaný GPU cluster, bez observability veľmi rýchlo stratíte prehľad. Nestačí vedieť, že „niečo beží“. Potrebujete vedieť:

• kto využíva ktoré GPU,
• ako dlho bežia joby,
• kde vznikajú fronty,
• čo je bottleneck,
• a aký je rozdiel medzi požadovanými a reálne využitými zdrojmi.

Na to používame LGTM stack a Grafana Alloy. Máme dashboardy pre alokáciu GPU, queue depth, runtime jobov aj správanie jednotlivých nodov.

Vďaka tomu vieme povedať nielen to, že cluster je vyťažený, ale aj ako je vyťažený. Napríklad ktoré karty sú takmer permanentne obsadené, či sú kvóty nastavené rozumne, alebo či už máme dosť tvrdé dáta na nákup ďalšieho hardvéru.

Observabilita sa nám osvedčila aj pri incidentoch. Pri timeoutoch alebo pádoch distribuovaných behov vieme rýchlo zozbierať súvisiace logy a zistiť, kde problém vznikol.

 

inno-notify: feedback loop pre researcherov

Jedna z najpraktickejších vecí, ktoré sme si dopísali sami, je interná Python služba inno-notify. Konzumuje Kubernetes eventy a metriky a po skončení jobu pošle researcherovi správu so sumárom: GPU-minúty, peak memory, exit code, odkazy na logy a podobne.

Najdôležitejšia je však odporúčacia vrstva. Ak si niekto vypýta výrazne viac RAM alebo GPU, než reálne použije, dostane to späť ako explicitný feedback.

To sa ukázalo ako veľmi účinné. Over-provisioning je problém, ktorý v zdieľanom clustri škodí všetkým, ale bez spätnej väzby si ho ľudia často ani neuvedomia. Keď sa spotreba zdrojov stane viditeľnou, disciplína ide hore výrazne rýchlejšie než pri akejkoľvek formálnej policy.

 

Výsledok

Priemerná utilizácia GPU nám vyskočila z približne 50 % na približne 85 %.

To je asi najjednoduchšie číslo, ktoré vystihuje, prečo sa táto investícia oplatila. Nešlo však len o vyššie percento využitia hardvéru.

Získali sme aj:

• rýchlejší onboarding nových researcherov,
• konzistentné development prostredia,
• menej ručnej operatívy okolo tréningov,
• lepšiu odolnosť infraštruktúry,
• auditovateľné zmeny,
• a historické dáta, o ktoré sa dá oprieť pri kapacitnom plánovaní.

GPU nody máme v princípe stateless, dáta sú centralizované a výpadok konkrétneho servera už neznamená chaos. Onboarding nového človeka sa skrátil z dní na desiatky minút. A keď potrebujeme obhájiť nákup ďalších kariet, už to nie je pocitové „asi by sa zišlo viac“, ale rozhodnutie podložené metrikami.

 

Čo sme sa naučili

Najdôležitejšia lekcia bola, že platforma pre research tím sa nedá navrhovať z pohľadu infra tímu, ale z pohľadu používateľa.

Researcher nemá písať YAMLy, riešiť PVC ani vedieť, ako funguje scheduler. Ak je vstupná bariéra vysoká, ľudia si veľmi rýchlo nájdu vlastnú cestu bokom — typicky cez SSH na „svoj“ server — a celý koncept fair sharingu sa rozpadne.

Ďalšie dôležité poznatky:

• centralizované úložisko a vymeniteľné nody sú praktickejšie než workflow naviazané na
  stav konkrétnych strojov,
• GitOps výrazne znižuje prevádzkový chaos,
• observability treba riešiť od začiatku, nie až keď nastane problém,
• a spätná väzba o spotrebe zdrojov je nevyhnutná, ak chcete, aby fair-share model fungoval nielen technicky, ale aj kultúrne.

Helm sa nám osvedčil pri platformových aplikáciách, pri user workloadoch nám často stačí jednoduchší prístup. Oveľa dôležitejšie než konkrétny templating nástroj však je, aby používateľská vrstva zostala čo najjednoduchšia.

 

Biometria rastie rýchlo, modely sú väčšie a nároky na GPU tiež. Bez poriadneho MLOps by sme jednoducho nestíhali tempo vývoja.

Táto platforma nám nepriniesla len lepší scheduling. Umožnila nám škálovať research spôsobom, ktorý je férový, auditovateľný a prevádzkovo udržateľný — bez toho, aby sme sa vzdali on-prem prostredia, ktoré je pre náš typ dát a zákazníkov kľúčové.

Ak vás bavia podobné problémy — on-prem Kubernetes, GPU scheduling, MLOps pre research tímy — príďte za nami na CODECON. Radi si o tom podebatujeme.