SageMaker AI Spaces prináša JupyterLab a Code Editor priamo do klastrov Amazon EKS

Vývojové prostredie sa presúva bližšie k výpočtom

AWS rozšíril praktické využitie doplnku SageMaker AI Spaces pre Amazon EKS o postup, ktorý umožňuje prevádzkovať JupyterLab a Code Editor priamo na existujúcom kubernetesovom klastri. Dátový vedec tak môže pracovať v rovnakom prostredí, kde bežia tréningové úlohy, inferenčné služby a dátové pipeline, namiesto presúvania kódu medzi lokálnym počítačom, samostatným JupyterHubom a produkčnou infraštruktúrou. Nejde však o jednoduchý notebook spustený jedným kliknutím. AWS dodáva spravovanú vrstvu pracovných priestorov, zatiaľ čo organizácia naďalej zodpovedá za klaster, sieť, uzly, identity, úložiská a väčšinu bezpečnostnej konfigurácie.

Hlavnou novinkou oproti stručnému predstaveniu produktu je konkrétny referenčný návrh pre celý prístupový reťazec. Webové rozhranie je v návode publikované cez Application Load Balancer, DNS v Route 53, certifikát z AWS Certificate Manager a smerovanie pomocou Traefiku. Pracovné kontajnery bežia na uzloch v privátnych podsieťach a perzistentné dáta môžu využívať EBS, EFS alebo FSx. Pre prístup z lokálneho VS Code sa používa tunel cez AWS Systems Manager. Ide teda skôr o stavebný blok podnikovej ML platformy než o náhradu lokálneho editora pre jednotlivca.

AWS uvádza, že samostatné notebookové prostredie s GPU, úložiskom a autentifikáciou môže platformový tím pripravovať tri až päť dní, kým nakonfigurovaný Space sa má používateľovi spustiť približne za päť minút. Toto porovnanie treba čítať opatrne: päť minút opisuje vytvorenie pracovného priestoru až po vybudovaní všetkých podporných komponentov. Prvé spustenie navyše zahŕňa stiahnutie veľkého kontajnerového obrazu a registráciu cez Systems Manager. Produkt skracuje opakované prideľovanie pripravených prostredí, nie úvodné navrhnutie a zabezpečenie celej platformy.

Jedna GPU infraštruktúra, dva odlišné režimy práce

Najsilnejším argumentom pre spoločný klaster je využitie drahých akcelerátorov. Interaktívny vývoj má nepravidelný profil: používateľ časť času píše alebo analyzuje výsledky a GPU môže zostať nevyužitá. Tréningové a inferenčné úlohy majú zase odlišné požiadavky na trvanie, prioritu a predvídateľnosť. Ak ich plánovač dokáže rozumne umiestniť na spoločné uzly, organizácia môže znížiť počet nečinných zariadení. Kubernetes podporuje stratégie zhusťovania úloh podľa požadovaných zdrojov, ale samotná prítomnosť viacerých typov workloadov ešte vyššie využitie nezaručuje.

Tvrdenie AWS o zvýšení využitia GPU až o 30 percent preto nemožno považovať za všeobecne platný výsledok. Dodávateľ nezverejnil nezávislý benchmark, metodiku ani profily záťaže, z ktorých číslo pochádza. Reálny efekt bude závisieť od veľkosti tímu, typov GPU, dĺžky tréningov, rezervácie kapacity a pravidiel plánovania. Interaktívny notebook môže blokovať celé zariadenie aj v čase, keď používateľ nič nepočíta. Platformový tím by mal pred nasadením sledovať čas skutočnej aktivity GPU, čakacie lehoty úloh a náklady na jeden projekt, nie iba priemerné vyťaženie klastra.

FinOps Foundation pri AI infraštruktúre odporúča kombinovať označovanie zdrojov, kvóty, meranie využitia a priraďovanie nákladov ku konkrétnym výsledkom. To je pri Spaces zvlášť dôležité, pretože účet netvorí iba samotná výpočtová kapacita. Platiť sa môže za EKS, EC2 uzly, blokové a zdieľané úložiská, load balancer, prenos dát, verejné IPv4 adresy a pokročilú úroveň Systems Manager. AWS v návode uvádza pri tejto úrovni približne 0,00695 dolára za hodinu na jeden registrovaný Space kontajner. Najväčšou položkou však spravidla zostane výpočtový uzol, najmä ak obsahuje GPU.

Izolácia používateľov je dôležitejšia než pohodlie notebooku

Pracovný priestor môže dostať obmedzenú rolu IAM prostredníctvom EKS Pod Identity a prístup sa dá viazať na kubernetesový namespace. AWS opisuje režim OwnerOnly pre vlastníka priestoru aj širšie zdieľanie s používateľmi autorizovanými v namespace. Pre väčšie tímy uvádza integráciu OpenID Connect cez Dex a Amazon Cognito, pri ktorej sa skupiny z poskytovateľa identity mapujú na pravidlá Kubernetes RBAC. Takéto mapovanie môže znížiť potrebu samostatných IAM účtov, ale chyba v názvoch atribútov alebo skupín môže používateľa buď zablokovať, alebo mu prideliť príliš široké oprávnenia.

Dokumentácia Kubernetes upozorňuje, že namespace je užitočná hranica pre politiky a kvóty, nie však úplná bezpečnostná izolácia. Tímy na spoločnom klastri stále zdieľajú riadiacu vrstvu a často aj fyzické uzly. Rizikom sú hluční susedia, nesprávne nastavené objekty s rozsahom celého klastra, priveľké oprávnenia či únik citlivých dát cez zdieľané úložisko. Pri notebookoch je plocha útoku väčšia aj preto, že používateľ môže spúšťať vlastný kód a inštalovať balíky. Organizácie by preto mali doplniť RBAC o sieťové politiky, limity zdrojov, kontrolu obrazov, auditné logy a pravidlá pre tajomstvá.

Prehliadačový prístup v referenčnej architektúre používa krátkodobú predpodpísanú URL. AWS uvádza päťminútovú platnosť tokenu, ktorú v opísanej verzii nemožno konfigurovať. Krátka životnosť znižuje čas na zneužitie uniknutého odkazu, nenahrádza však bezpečnú distribúciu ani ochranu logov. Pri prístupe z VS Code prechádza spojenie tunelom SSH cez Systems Manager. Bezpečnostný tím by mal pri oboch cestách overiť, kto môže vytvoriť reláciu, ako sa zaznamenáva aktivita a či používateľ nemôže obísť pravidlá určené pre webové rozhranie.

Čo to znamená pre slovenské a európske tímy

Pre slovenskú firmu alebo výskumnú organizáciu má riešenie najväčší význam vtedy, ak už prevádzkuje EKS a má platformový tím schopný spravovať Kubernetes. Zjednotenie notebookov a produkčných úloh môže obmedziť rozdiely medzi vývojovým a cieľovým prostredím, zjednodušiť prístup k interným dátam a urýchliť reprodukciu experimentov. Pred migráciou však treba preveriť umiestnenie dát, zvolený región AWS, prenosy medzi regiónmi, dobu uchovávania logov a zmluvné pravidlá pre osobné alebo citlivé údaje. Samotné nasadenie v európskom regióne nevyrieši riadenie prístupu ani internú zodpovednosť za dáta.

Technické požiadavky zároveň zužujú okruh vhodných používateľov. Referenčný postup počíta s Kubernetes 1.30 alebo novším, klasickými uzlami EC2, verejnými a privátnymi podsieťami najmenej v dvoch zónach dostupnosti, NAT gateway, certifikátom, KMS kľúčom a viacerými doplnkami klastra. EKS Auto Mode v tejto konfigurácii podporovaný nie je a doplnok Spaces musí mať verziu aspoň 0.1.4. Malý tím bez existujúcej kubernetesovej prevádzky môže za správu tejto vrstvy zaplatiť viac, než ušetrí konsolidáciou notebookov.

Otvorenou otázkou zostáva, ako sa služba osvedčí pri dlhodobej zmiešanej prevádzke. AWS ukazuje funkčný spôsob nasadenia, nie nezávislé porovnanie spoľahlivosti, nákladov a bezpečnosti s JupyterHubom, SageMaker Studio alebo oddelenými vývojovými klastrami. Rozumný pilot by mal merať čas vytvorenia priestoru, čakacie lehoty na GPU, počet incidentov, náklady podľa tímu a vplyv interaktívnej práce na produkčné služby. SageMaker AI Spaces môže odstrániť časť opakovanej platformovej práce, ale hodnotu prinesie iba tam, kde sú kvóty, priority, identity a nákladová zodpovednosť vyriešené rovnako dôsledne ako samotné notebooky.