Zgradite ponovljive, varne in razširljive poteke dela strojnega učenja od konca do konca z uporabo Kubeflow na AWS

To je gostujoča objava v spletnem dnevniku, napisana skupaj z athenahealth.

atensko zdravje vodilni ponudnik omrežne programske opreme in storitev za medicinske skupine in zdravstvene sisteme po vsej državi. Njegovi elektronski zdravstveni zapisi, upravljanje prihodkovnega cikla in orodja za vključevanje pacientov omogočajo dostop kadarkoli in kjerkoli, spodbujanje boljših finančnih rezultatov za stranke in omogočanje strankam ponudnikov zagotavljanja boljše kakovosti oskrbe.

V prostoru umetne inteligence (AI) athenahealth uporablja znanost o podatkih in strojno učenje (ML) za pospešitev poslovnih procesov in zagotavljanje priporočil, napovedi in vpogledov v več storitvah. Od svoje prve implementacije v avtomatiziranih dokumentnih storitvah, brez dotika obdelave milijonov dokumentov med ponudnikom in pacientom, do svojega novejšega dela na področju virtualnih pomočnikov in izboljšanja uspešnosti prihodkovnega cikla, athenaealth še naprej uporablja AI za pomoč pri spodbujanju učinkovitosti, zmogljivosti storitev in boljših rezultatov za ponudnike in njihovi pacienti.

Ta objava v spletnem dnevniku prikazuje, kako athenahealth uporablja Kubeflow na AWS (specifična distribucija Kubeflow za AWS) za izgradnjo in racionalizacijo celovitega delovnega toka podatkovne znanosti, ki ohranja bistvena orodja, optimizira operativno učinkovitost, povečuje produktivnost podatkovnih znanstvenikov in postavlja temelje za lažjo razširitev njihovih zmogljivosti ML.

Kubeflow je odprtokodna platforma ML, namenjena preprostemu, prenosljivemu in razširljivemu uvajanju delovnih tokov ML na Kubernetes. Kubeflow to doseže z vključitvijo ustreznih odprtokodnih orodij, ki se dobro integrirajo s Kubernetesom. Nekateri od teh projektov vključujejo Argo za orkestracijo cevovodov, Istio za servisno mrežo, Jupyter za prenosne računalnike, Spark, TensorBoard in Katib. Kubeflow Pipelines pomaga zgraditi in uvesti prenosljive, razširljive delovne tokove ML, ki lahko vključujejo korake, kot so ekstrakcija podatkov, predprocesiranje, usposabljanje modela in vrednotenje modela v obliki ponovljivih cevovodov.

AWS prispeva k odprtokodni skupnosti Kubeflow z zagotavljanjem lastne distribucije Kubeflow (imenovane Kubeflow na AWS), ki pomaga organizacijam, kot je athenahealth, zgraditi zelo zanesljive, varne, prenosljive in razširljive poteke dela ML z zmanjšanimi operativnimi stroški prek integracije s storitvami, ki jih upravlja AWS. AWS ponuja različne možnosti uvajanja Kubeflow, kot je uvajanje s Amazon Cognito, uvajanje z Služba za relacijske baze podatkov Amazon (Amazon RDS) in Preprosta storitev shranjevanja Amazon (Amazon S3) in uvedba vanilla. Za podrobnosti o integraciji storitve in razpoložljivih dodatkih za vsako od teh možnosti glejte Deployment.

Danes Kubeflow na AWS ponuja jasno pot do uporabe Kubeflowa, dopolnjenega z naslednjimi storitvami AWS:

Številne stranke AWS izkoriščajo prednosti distribucije Kubeflow na AWS, vključno z athenahealthom.

Tukaj ekipa athenahealth MLOps razpravlja o izzivih, s katerimi so se srečali, in rešitvah, ki so jih ustvarili na svojem potovanju Kubeflow.

Izzivi s prejšnjim okoljem ML

Preden smo sprejeli Kubeflow na AWS, so naši podatkovni znanstveniki uporabljali standardiziran nabor orodij in proces, ki je omogočal prilagodljivost v tehnologiji in delovnem toku, uporabljenem za usposabljanje danega modela. Primeri komponent standardiziranega orodja vključujejo API za vnos podatkov, orodja za varnostno skeniranje, cevovod CI/CD, ki ga je zgradila in vzdržuje druga ekipa v athenahealthu, ter skupno strežno platformo, ki jo je zgradila in vzdržuje ekipa MLOps. Ko pa je naša uporaba AI in ML dozorela, se je povečala tudi raznolikost orodij in infrastrukture, ustvarjenih za vsak model. Čeprav smo še vedno lahko podpirali obstoječi proces, smo na obzorju videli naslednje izzive:

• Vzdrževanje in rast – Reprodukcija in vzdrževanje okolij za usposabljanje modelov je zahtevala več truda, ko se je povečalo število razporejenih modelov. Vsak projekt je ohranil podrobno dokumentacijo, ki je orisala, kako je bil vsak skript uporabljen za izdelavo končnega modela. V mnogih primerih je bil to zapleten postopek, ki je vključeval 5 do 10 skriptov z več rezultati. Tem je bilo treba ročno slediti s podrobnimi navodili o tem, kako bo vsak rezultat uporabljen v nadaljnjih procesih. Vzdrževanje tega je sčasoma postalo okorno. Poleg tega, ko so projekti postali kompleksnejši, se je povečalo tudi število orodij. Na primer, večina modelov je uporabljala Spark in TensorFlow z grafičnimi procesorji, kar je zahtevalo več različnih konfiguracij okolja. Sčasoma so uporabniki preklopili na novejše različice orodij v svojih razvojnih okoljih, vendar potem niso mogli izvajati starejših skriptov, ko so te različice postale nezdružljive. Posledično je vzdrževanje in dopolnjevanje starejših projektov zahtevalo več inženirskega časa in truda. Poleg tega, ko so se ekipi pridružili novi podatkovni znanstveniki, so prenosi znanja in uvajanje zahtevali več časa, ker je sinhronizacija lokalnih okolij vključevala veliko nedokumentiranih odvisnosti. Preklapljanje med projekti je imelo enake težave, ker je imel vsak model svoje delovne tokove.
• Varnost – Varnost jemljemo resno in zato dajemo prednost skladnosti z vsemi pogodbenimi, pravnimi in regulativnimi obveznostmi, povezanimi z pranjem denarja in znanostjo o podatkih. Podatke je treba uporabljati, shranjevati in do njih dostopati na posebne načine, zato smo vdelali robustne postopke, da zagotovimo, da so naše prakse v skladu z našimi pravnimi obveznostmi in tudi v skladu z najboljšimi praksami v industriji. Pred sprejetjem Kubeflow je zagotavljanje, da so podatki shranjeni in dostopni na določen način, vključevalo redno preverjanje v več različnih delovnih tokovih. Vedeli smo, da lahko izboljšamo učinkovitost s konsolidacijo teh različnih delovnih tokov na eni platformi. Vendar bi morala biti ta platforma dovolj prilagodljiva, da bi se dobro integrirala z našim standardiziranim orodjem.
• operacije – Videli smo tudi priložnost za povečanje operativne učinkovitosti in upravljanja s centralizacijo beleženja in spremljanja delovnih tokov. Ker je vsaka ekipa razvila lastna orodja, smo te podatke zbrali iz vsakega poteka dela posebej in jih združili.

Ekipa podatkovne znanosti je ocenila različne rešitve za konsolidacijo delovnih tokov. Poleg obravnavanja teh zahtev smo iskali rešitev, ki bi se brezhibno integrirala z obstoječo standardizirano infrastrukturo in orodji. Za našo rešitev poteka dela smo izbrali Amazon EKS in Kubeflow na AWS.

Razvojni cikel podatkovnega znanstvenika, ki vključuje Kubeflow

Projekt podatkovne znanosti se začne s čistim listom: brez podatkov, brez kode, samo poslovni problem, ki ga je mogoče rešiti z ML. Prva naloga je dokaz koncepta (POC), da odkrijemo, ali podatki vsebujejo dovolj signala, da bo model ML učinkovit pri reševanju poslovnega problema, začenši s poizvedovanjem po neobdelanem naboru podatkov iz našega podatkovnega skladišča Snowflake. Ta stopnja je iterativna in podatkovni znanstveniki med tem postopkom uporabljajo Kubernetes pods ali prenosnike Kubeflow Jupyter.

Naša gruča Kubeflow uporablja orodje za samodejno skaliranje gruče Karpenter, ki podatkovnim znanstvenikom olajša vrtenje virov, saj se morajo osredotočiti le na definiranje želenih tipov instanc, medtem ko oskrbovanje opravlja nabor vnaprej določenih oskrbovalcev Karpenter. Imamo ločene ponudnike za vrste primerkov CPE in GPE in vsi primerki, ki jih podpira Amazon EKS, spadajo v eno od teh dveh kategorij glede na našo konfiguracijo ponudnika. Podatkovni znanstveniki izberejo vrste instanc z uporabo izbirnikov vozlišč, Karpenter pa poskrbi za upravljanje življenjskega cikla vozlišč.

Ko je poizvedba razvita, podatkovni znanstveniki ekstrahirajo neobdelane podatke na lokacijo na Amazon S3, nato pa zaženejo prenosni računalnik Jupyter iz uporabniškega vmesnika AWS Kubeflow, da raziščejo podatke. Cilj je ustvariti nabor funkcij, ki se bo uporabljal za usposabljanje prvega modela. To podatkovnim znanstvenikom omogoča, da ugotovijo, ali je v podatkih dovolj signala za izpolnitev strankinih poslovnih potreb.

Ko so rezultati zadovoljivi, se podatkovni znanstveniki premaknejo na naslednjo stopnjo razvojnega cikla in svoja odkritja spremenijo v robusten cevovod. Kodo POC pretvorijo v kodo proizvodne kakovosti, ki deluje v velikem obsegu. Da bi zagotovili skladnost z uporabo odobrenih knjižnic, se ustvari vsebnik z ustrezno osnovno sliko Docker. Za naše podatkovne znanstvenike smo ugotovili, da zagotavljanje standardne osnovne slike Python, TensorFlow in Spark zagotavlja zadostno prilagodljivost za večino, če ne za vse delovne obremenitve. Nato lahko uporabijo Dockerfile svoje komponente za nadaljnjo prilagoditev svojega razvojnega okolja. To datoteko Docker nato uporabi proces CI/CD za izdelavo slike komponent, ki se bodo uporabljale v proizvodnji, s čimer se ohranja skladnost med razvojnim in proizvodnim okoljem.

Imamo orodje, ki podatkovnim znanstvenikom omogoča, da zaženejo svoje razvojno okolje v sklopu, ki teče na Kubernetesu. Ko ta pod deluje, lahko podatkovni znanstveniki nato priključijo Visual Studio Code IDE neposredno na pod in odpravijo napake v kodi svojega modela. Ko se koda uspešno izvaja, lahko svoje spremembe potisnejo v git in ustvari se novo razvojno okolje z najnovejšimi spremembami.

Standardni cevovod podatkovne znanosti je sestavljen iz stopenj, ki vključujejo ekstrakcijo, predprocesiranje, usposabljanje in vrednotenje. Vsaka stopnja v cevovodu se pojavi kot komponenta v Kubeflowu, ki je sestavljen iz Kubernetes pod, ki izvaja ukaz z nekaterimi informacijami, posredovanimi kot parametri. Ti parametri so lahko statične vrednosti ali reference na izhod prejšnje komponente. Slika Docker, uporabljena v sklopu, je zgrajena iz procesa CI/CD. Podrobnosti o tem postopku so prikazane v delovnem toku CI/CD, ki je obravnavan v naslednjem razdelku.

Razvojni cikel na Kubeflow. Razvojni potek dela se začne na levi strani s POC. Dokončani model je nameščen na strežni platformi modela athenaealth, ki deluje na Amazon ECS.

Proces CI/CD, ki podpira avtomatizirane poteke dela

Kot del našega procesa CI/CD uporabljamo Jenkins za vzporedno izdelavo in preizkušanje vseh slik komponent Kubeflow. Po uspešnem zaključku vsebuje predloga komponente cevovoda referenčne kazalce na slike in nastali cevovod se naloži v Kubeflow. Parametri v Jenkinsovem cevovodu omogočajo uporabnikom, da zaženejo cevovode in zaženejo teste usposabljanja modelov po uspešni gradnji.

Za ohranitev kratkega razvojnega cikla pa lahko podatkovni znanstveniki tudi zaženejo cevovod iz svojega lokalnega računalnika in spremenijo vse parametre cevovoda, s katerimi morda eksperimentirajo.

Obstajajo orodja, ki zagotavljajo, da se referenčni kazalci iz gradnje CI/CD privzeto uporabljajo. Če je v repoju artefakt, ki ga je mogoče uvesti, potem bo logika CI/CD še naprej uvajala artefakt v platformo za streženje modela athenahealth (storitev napovedi), ki se izvaja na Amazon ECS z AWS Fargate. Ko minejo vse te stopnje, podatkovni znanstvenik združi kodo s primarno vejo. Cevovodi in namestitveni artefakti so nato potisnjeni v proizvodnjo.

Delovni tok uvajanja CI/CD. Ta diagram opisuje delovni tok gradnje in uvajanja Data Science. Postopek CI/CD poganja Jenkins.

Varnost

Pri konsolidaciji naših delovnih tokov podatkovne znanosti smo lahko centralizirali naš pristop k zagotavljanju cevovoda za usposabljanje. V tem razdelku razpravljamo o našem pristopu k varnosti podatkov in gruč.

Varnost podatkov

Varnost podatkov je v athenahealthu izjemnega pomena. Zaradi tega razvijamo in vzdržujemo infrastrukturo, ki je v celoti skladna s predpisi in standardi, ki varujejo varnost in celovitost teh podatkov.

Da bi zagotovili izpolnjevanje standardov skladnosti podatkov, zagotavljamo našo infrastrukturo AWS v skladu z našimi smernicami za podjetja athenahealth. Dve glavni shrambi za podatke sta Amazon RDS za visoko razširljive metapodatke o cevovodih in Amazon S3 za artefakte cevovodov in modelov. Za Amazon S3 zagotavljamo, da so vedra šifrirana, da so uveljavljene končne točke HTTPS in da so pravilniki o vedrih in AWS upravljanje identitete in dostopa (IAM) vloge sledijo načelom najmanjših privilegijev pri dovoljevanju dostopa do podatkov. To velja tudi za podatke Amazon RDS: šifriranje je vedno omogočeno, varnostne skupine in dostop do poverilnic pa sledijo načelu najmanjših privilegijev. Ta standardizacija zagotavlja, da imajo samo pooblaščene osebe dostop do podatkov, ta dostop pa se sledi.

Poleg teh ukrepov je platforma podvržena tudi ocenam varnostnih groženj ter neprekinjenim pregledom varnosti in skladnosti.

Obravnavamo tudi zahteve glede hrambe podatkov prek upravljanja življenjskega cikla podatkov za vsa vedra S3, ki vsebujejo občutljive podatke. Ta pravilnik samodejno premakne podatke v Ledenik Amazon S3 po 30 dneh od nastanka. Izjeme od tega se upravljajo z zahtevami za pridobivanje podatkov in se odobrijo ali zavrnejo za vsak primer posebej. To zagotavlja, da so vsi poteki dela v skladu s politiko hrambe podatkov. To tudi reši težavo z obnovitvijo podatkov, če model deluje slabo in je potrebno ponovno usposabljanje ali ko je treba nov model ovrednotiti glede na zgodovinsko ponovitev nabora podatkov starejšega modela.

Za omejevanje dostopa do Amazon S3 in Amazon RDS znotraj Kubeflow na AWS in Amazon EKS uporabljamo IRSA (IAM Roles for Service Accounts), ki zagotavlja zagotavljanje dovoljenj na podlagi IAM za vire znotraj Kubernetesa. Vsak najemnik v Kubeflow ima edinstven vnaprej ustvarjen storitveni račun, ki ga povežemo z vlogo IAM, ustvarjeno posebej za izpolnitev zahtev za dostop najemnika. Uporabniški dostop do najemnikov je prav tako omejen z uporabo članstva v skupini uporabnikov Amazon Cognito za vsakega uporabnika. Ko je uporabnik overjen v gruči, ustvarjeni žeton vsebuje zahtevke skupine, Kubernetes RBAC pa te informacije uporabi za dovoljenje ali zavrnitev dostopa do določenega vira v gruči. Ta nastavitev je podrobneje razložena v naslednjem razdelku.

Varnost gruče z izolacijo več uporabnikov

Kot smo omenili v prejšnjem razdelku, podatkovni znanstveniki izvajajo raziskovalne analize podatkov, izvajajo analizo podatkov in usposabljajo modele ML. Za dodeljevanje virov, organiziranje podatkov in upravljanje potekov dela na podlagi projektov Kubeflow na AWS zagotavlja izolacijo na podlagi imenskih prostorov Kubernetes. Ta izolacija deluje za interakcijo z uporabniškim vmesnikom Kubeflow; vendar ne nudi nobenega orodja za nadzor dostopa do Kubernetes API z uporabo Kubectl. To pomeni, da je uporabniški dostop mogoče nadzorovati v uporabniškem vmesniku Kubeflow, ne pa prek Kubernetes API prek Kubectl.

Arhitektura, opisana v naslednjem diagramu, obravnava to težavo s poenotenjem dostopa do projektov v Kubeflow na podlagi članstva v skupinah. Da bi to dosegli, smo izkoristili manifeste Kubeflow on AWS, ki imajo integracijo z uporabniškimi skupinami Amazon Cognito. Poleg tega uporabljamo nadzor dostopa na podlagi vlog Kubernetes (RBAC) za nadzor avtorizacije znotraj gruče. Uporabniška dovoljenja so omogočena na podlagi članstva v skupini Amazon Cognito. Te informacije se prenesejo v gručo z žetonom, ki ga ustvari odjemalec OIDC. Ta postopek je poenostavljen zahvaljujoč vgrajeni funkcionalnosti Amazon EKS, ki omogoča povezovanje ponudnikov identitete OIDC za preverjanje pristnosti z gručo.

Preverjanje pristnosti Amazon EKS privzeto izvaja avtentikator IAM, ki je orodje, ki omogoča preverjanje pristnosti z gručo EKS z uporabo poverilnic IAM. Ta metoda preverjanja pristnosti ima svoje prednosti; vendar ni primeren za naš primer uporabe, ker athenahealth uporablja Microsoft Azure Active Directory za storitev identitete v celotni organizaciji.

Izolacija imenskega prostora Kubernetes. Podatkovni znanstveniki lahko pridobijo članstvo v eni ali več skupinah, kot je potrebno za njihovo delo. Dostop se redno pregleduje in po potrebi odstrani.

Azure Active Directory, ki je storitev identitete za celotno podjetje, je vir resnice za nadzor uporabniškega dostopa do gruče Kubeflow. Nastavitev za to vključuje ustvarjanje aplikacije Azure Enterprise, ki deluje kot principal storitve, in dodajanje skupin za različne najemnike, ki potrebujejo dostop do gruče. Ta nastavitev v storitvi Azure se odraža v storitvi Amazon Cognito z nastavitvijo zveznega ponudnika identitete OIDC, ki odgovornost za preverjanje pristnosti prenese na Azure. Dostop do skupin Azure nadzira SailPoint IdentityIQ, ki pošlje zahteve za dostop lastniku projekta, da dovoli ali zavrne, kot je primerno. V skupini uporabnikov Amazon Cognito sta ustvarjena dva odjemalca aplikacij: eden se uporablja za nastavitev avtentikacije za gručo Kubernetes z uporabo ponudnika identitete OIDC, drugi pa za zaščito avtentikacije Kubeflow v uporabniškem vmesniku Kubeflow. Ti odjemalci so konfigurirani za posredovanje skupinskih zahtevkov po preverjanju pristnosti z gručo, ti skupinski zahtevki pa se uporabljajo skupaj z RBAC za nastavitev avtorizacije znotraj gruče.

Vezave vlog Kubernetes RBAC so nastavljene med skupinami in vlogo gruče Kubeflow-edit, ki se ustvari ob namestitvi Kubeflow v gručo. Ta vezava vlog zagotavlja, da lahko kateri koli uporabnik, ki komunicira z gručo po prijavi prek OIDC, dostopa do imenskih prostorov, za katere ima dovoljenja, kot je določeno v njihovih skupinskih zahtevkih. Čeprav to deluje za uporabnike, ki komunicirajo z gručo z uporabo Kubectl, uporabniški vmesnik Kubeflow trenutno ne omogoča dostopa uporabnikom na podlagi članstva v skupini, ker ne uporablja RBAC. Namesto tega uporablja vir Istio Authorization Policy za nadzor dostopa za uporabnike. Da bi premagali ta izziv, smo razvili krmilnik po meri, ki sinhronizira uporabnike z anketiranjem skupin Amazon Cognito in doda ali odstrani ustrezne vezave vlog za vsakega uporabnika in ne za skupino. Ta nastavitev omogoča uporabnikom, da imajo enako raven dovoljenj pri interakciji z uporabniškim vmesnikom Kubeflow in Kubectl.

Operativna učinkovitost

V tem razdelku razpravljamo o tem, kako smo izkoristili prednosti odprtokodnih orodij in orodij AWS, ki so nam na voljo za upravljanje in odpravljanje napak v naših delovnih tokovih ter za zmanjšanje operativnega vpliva nadgradnje Kubeflow.

Beleženje in spremljanje

Za beleženje uporabljamo FluentD, da potisnemo vse naše dnevnike vsebnikov Storitev Amazon OpenSearch in sistemske metrike za Prometheus. Nato uporabimo Kibano in uporabniški vmesnik Grafana za iskanje in filtriranje dnevnikov in meritev. Naslednji diagram opisuje, kako to nastavimo.

Kubeflow beleženje. Za ogled in prebiranje dnevnikov uporabljamo uporabniški vmesnik Grafana in Kibana

Naslednji posnetek zaslona je pogled uporabniškega vmesnika Kibana iz našega cevovoda.

Vzorec pogleda uporabniškega vmesnika Kibana. Kibana omogoča prilagojene poglede.

Varne nadgradnje gruče Kubeflow

Ko uporabnike vključujemo v Kubeflow na AWS, vzdržujemo zanesljivo in dosledno uporabniško izkušnjo, hkrati pa ekipi MLOps omogočamo, da ostane agilna pri izdajanju in integraciji novih funkcij. Na prvi pogled se nam Kustomize zdi modularen, da omogoča delo in nadgradnjo ene komponente naenkrat, ne da bi vplival na druge, kar nam omogoča dodajanje novih zmogljivosti z minimalnimi motnjami za uporabnike. Vendar pa v praksi obstajajo scenariji, kjer je najboljši pristop preprosto vrtenje nove gruče Kubernetes namesto uporabe nadgradenj na ravni komponent za obstoječe gruče. Našli smo dva primera uporabe, kjer je bilo bolj smiselno ustvariti popolnoma nove gruče:

• Nadgradnja na različico Kubernetes, kjer AWS zagotavlja nadgradnje gruče na mestu. Vendar pa postane težko preizkusiti, ali vsak od virov Kubeflow in Kubernetes deluje, kot je predvideno, in ali manifesti ohranjajo združljivost za nazaj.
• Nadgradnja Kubeflowa na novejšo izdajo, kjer je dodanih ali spremenjenih več funkcij in skoraj vedno ni obetavna ideja za izvajanje nadgradenj na mestu v obstoječi gruči Kubernetes.

Pri reševanju te težave smo razvili strategijo, ki nam omogoča varne zamenjave gruč brez vpliva na obstoječe delovne obremenitve. Da bi to dosegli, smo morali izpolniti naslednje kriterije:

• Ločite shrambo Kubeflow in računalniške vire, tako da se metapodatki cevovoda, artefakti cevovoda in uporabniški podatki ohranijo, ko onemogočite uporabo starejše gruče
• Integrirajte s Kubeflow na manifestih AWS, tako da so ob nadgradnji različice Kubeflow potrebne minimalne spremembe
• Če gre po nadgradnji gruče kaj narobe, se lahko preprosto vrnete nazaj
• Imejte preprost vmesnik za promocijo gruče kandidatov v proizvodnjo

Naslednji diagram prikazuje to arhitekturo.

Varna nadgradnja gruče Kubeflow. Ko je testiranje Kubeflow Candidate uspešno, se prek posodobitve Route 53 napreduje v Kubeflow Prod.

Manifesti Kubeflow na AWS so predpakirani z integracijama Amazon RDS in Amazon S3. S temi upravljanimi storitvami, ki delujejo kot običajne shrambe podatkov, lahko vzpostavimo modro-zeleno strategijo uvajanja. Da bi to dosegli, smo zagotovili, da se metapodatki o cevovodu ohranijo v Amazon RDS, ki deluje neodvisno od gruče EKS, dnevniki in artefakti cevovoda pa se ohranijo v Amazon S3. Poleg metapodatkov in artefaktov cevovoda smo nastavili tudi FluentD za usmerjanje dnevnikov pod v Amazon OpenSearch Service.

To zagotavlja, da je plast za shranjevanje popolnoma ločena od računalniške plasti in s tem omogoča testiranje sprememb med posodobitvami različice Kubeflow na popolnoma novi gruči EKS. Ko so vsi testi uspešni, lahko preprosto spremenimo Amazonska pot 53 Zapis DNS v gruč kandidatov, ki gosti Kubeflow. Prav tako ohranjamo staro gručo, ki teče kot rezervna kopija za nekaj dni, za primer, če se moramo vrniti nazaj.

Prednosti Amazon EKS in Kubeflow na AWS za naš cevovod ML

Amazon EKS in Kubeflow na paketu AWS sta naš razvojni tok dela premaknila na vzorec, ki močno spodbuja ponovljivo usposabljanje modelov. Ta orodja nam omogočajo, da imamo popolnoma definirane gruče s popolnoma definiranimi najemniki in izvajamo popolnoma definirano kodo.

Veliko zmag pri gradnji te platforme je manj kvantitativnih in je bolj povezanih s tem, kako so se delovni tokovi izboljšali za razvijalce platforme in uporabnike. Na primer, MinIO je bil nadomeščen z neposrednim dostopom do Amazon S3, kar nas približa prvotnim potekom dela in zmanjša število storitev, ki jih moramo vzdrževati. Prav tako lahko uporabimo Amazon RDS kot zaledje za Kubeflow, kar omogoča lažje selitve med gručami in nam daje možnost, da vsako noč varnostno kopiramo naše cevovode.

Ugotovili smo tudi, da so izboljšave integracije Kubeflow s storitvami, ki jih upravlja AWS, koristne. Na primer, z Amazon RDS, Amazon S3 in Amazon Cognito, vnaprej konfiguriranimi v manifestih Kubeflow on AWS, prihranimo čas in trud pri posodabljanju na novejše distribucije Kubeflow. Ko smo uradne manifeste Kubeflow spreminjali ročno, je posodabljanje na novo različico trajalo več tednov, od zasnove do testiranja.

Prehod na Amazon EKS nam daje priložnost, da definiramo svojo gručo v Kustomize (zdaj del Kubectl) in Terraform. Izkazalo se je, da je za delo na platformi s Kubernetes in Terraform zelo enostavno delati, potem ko vložite dovolj časa za učenje. Po številnih ponovitvah orodja, ki so nam na voljo, zelo olajšajo izvajanje standardnih operacij platforme, kot je nadgradnja komponente ali zamenjava celotne razvojne gruče. V primerjavi z vodenjem poslov v surovem stanju Amazonski elastični računalniški oblak Primeri (Amazon EC2) je težko primerjati, kakšna velika razlika je, če imamo dobro definirane sklope z vgrajenimi zajamčenimi mehanizmi za čiščenje virov in ponovnega poskusa.

Kubernetes zagotavlja odlične varnostne standarde in le opraskali smo površje tega, kar nam omogoča izolacija za več uporabnikov. Izolacijo več uporabnikov vidimo kot vzorec, ki se bo bolj izplačal v prihodnosti, ko bo platforma za usposabljanje proizvedla podatke na produkcijski ravni, in bomo vključili razvijalce zunaj naše ekipe.

Medtem nam Kubeflow omogoča ponovljivo usposabljanje modelov. Tudi z enakimi podatki nobeno usposabljanje ne ustvari enakih modelov, vendar imamo naslednjo najboljšo stvar. S Kubeflowom natančno vemo, katera koda in podatki so bili uporabljeni za usposabljanje modela. Vključevanje se je močno izboljšalo, ker je vsak korak v našem načrtu jasno in programsko opredeljen. Ko imajo novi podatkovni znanstveniki nalogo popraviti napako, potrebujejo veliko manj rokovanja, ker obstaja jasna struktura, kako se izhodi kode uporabljajo med stopnjami.

Uporaba Kubeflow prinaša tudi veliko izboljšav zmogljivosti v primerjavi z izvajanjem na enem primerku EC2. Podatkovni znanstveniki pri usposabljanju za modele pogosto potrebujejo različna orodja in optimizacije za predhodno obdelavo in usposabljanje. Na primer, predprocesiranje se pogosto izvaja z orodji za porazdeljeno obdelavo podatkov, kot je Spark, medtem ko se usposabljanje pogosto izvaja z uporabo primerkov GPE. S cevovodi Kubeflow lahko določijo različne vrste primerkov za različne stopnje v cevovodu. To jim omogoča uporabo zmogljivih instanc GPE v eni fazi in flote manjših strojev za porazdeljeno obdelavo v drugi fazi. Ker cevovodi Kubeflow opisujejo odvisnosti med stopnjami, lahko cevovodi izvajajo stopnje vzporedno.

Nazadnje, ker smo ustvarili postopek za dodajanje najemnikov v gručo, zdaj obstaja bolj formalen način za registracijo ekip najemniku v gruči. Ker uporabljamo Kubecost za sledenje stroškom v naši gruči EKS, nam omogoča, da stroške pripišemo posameznemu projektu, namesto da bi imeli stroške pripisane na ravni računa, kar vključuje vse projekte podatkovne znanosti. Kubecost predstavlja poročilo o porabljenem denarju na imenski prostor, ki je tesno povezan z najemnikom ali ekipo, ki je odgovorna za vodenje plinovoda.

Kljub vsem prednostim bi opozorili, da se tovrstne selitve lotite samo, če uporabniki popolnoma pristanejo. Uporabniki, ki vložijo čas, dobijo veliko koristi od uporabe Amazon EKS in Kubernetes, vendar obstaja precejšnja krivulja učenja.

zaključek

Z uvedbo cevovoda Kubeflow on AWS v našo celovito infrastrukturo ML smo lahko konsolidirali in standardizirali naše delovne tokove podatkovne znanosti, hkrati pa ohranili naša osnovna orodja (kot je CI/CD in strežba modelov). Naši podatkovni znanstveniki se lahko zdaj premikajo med projekti, ki temeljijo na tem poteku dela, ne da bi se morali učiti, kako vzdrževati popolnoma drugačen nabor orodij. Pri nekaterih naših modelih smo bili prijetno presenečeni tudi nad hitrostjo novega poteka dela (petkrat hitrejši), ki je omogočil več iteracij usposabljanja in posledično izdelavo modelov z boljšimi napovedmi.

Vzpostavili smo tudi trdne temelje za povečanje naših zmogljivosti MLOps ter povečanje števila in velikosti naših projektov. Na primer, ko utrjujemo našo držo upravljanja na področju linije in sledenja modelov, smo zmanjšali svojo osredotočenost z več kot 15 delovnih tokov na samo enega. In ko je konec leta 4 prišla na dan ranljivost Log2021shell, smo se lahko osredotočili na en sam potek dela in ga po potrebi hitro odpravili (izvajanje Registar elastičnih zabojnikov Amazon (Amazon ECR) skeniranje, nadgradnja storitve Amazon OpenSearch, posodabljanje naših orodij in več) z minimalnim vplivom na tekoče delo podatkovnih znanstvenikov. Ko postanejo na voljo izboljšave AWS in Kubeflow, jih lahko vključimo, kot se nam zdi primerno.

To nas pripelje do pomembnega in podcenjenega vidika našega Kubeflowa o sprejetju AWS. Eden od kritičnih rezultatov tega potovanja je zmožnost nemotenega uvajanja nadgradenj in izboljšav za Kubeflow za naše podatkovne znanstvenike. Čeprav smo o našem pristopu k temu razpravljali prej, se zanašamo tudi na manifeste Kubeflow, ki jih zagotavlja AWS. Svojo pot Kubeflow smo začeli kot dokaz koncepta leta 2019, pred izdajo različice 1.0.0. (Trenutno smo na 1.4.1 in ocenjujemo 1.5. AWS že dela na različici 1.6.) V vmesnih 3 letih je bilo izdanih vsaj šest izdaj z veliko vsebine. S svojim discipliniranim pristopom k vključevanju in potrjevanju teh nadgradenj ter objavljanju manifestov po predvidljivem in zanesljivem urniku je bila ekipa Kubeflow pri AWS ključnega pomena pri omogočanju ekipe athenahealth MLOps pri načrtovanju našega razvojnega načrta ter posledično dodeljevanja virov in področij osredotočanja. , še bolj samozavestno v prihodnost.

Lahko sledite Repozitorij AWS Labs GitHub za sledenje vsem prispevkom AWS v Kubeflow. Ekipe AWS najdete tudi na Kubeflow #AWS Slack Channel; vaše povratne informacije tam pomagajo AWS, da določi prednost naslednjim funkcijam za prispevanje k projektu Kubeflow.

---

O avtorjih

Kanwaljit Khurmi je višji arhitekt rešitev pri Amazon Web Services. Sodeluje s strankami AWS pri zagotavljanju smernic in tehnične pomoči, ki jim pomaga izboljšati vrednost njihovih rešitev pri uporabi AWS. Kanwaljit je specializiran za pomoč strankam z aplikacijami za vsebnike in strojnim učenjem.

Tyler Kalbach je glavni član tehničnega osebja pri athenahealth. Tyler ima približno 7 let izkušenj z analitiko, podatkovno znanostjo, nevronskimi mrežami in razvojem aplikacij strojnega učenja v zdravstvu. Prispeval je k več rešitvam strojnega učenja, ki trenutno služijo proizvodnemu prometu. Tyler, ki trenutno dela kot glavni podatkovni znanstvenik v inženirski organizaciji athenahealth, je bil del ekipe, ki je zgradila novo platformo za usposabljanje strojnega učenja za athenahealth od samega začetka tega prizadevanja.

Victor Krylov je glavni član tehničnega osebja pri athenahealth. Victor je inženir in mojster Scrum-a, ki znanstvenikom pomaga graditi varne napeljave za hitro strojno učenje. V athenahealthu je delal na vmesnikih, kliničnem naročanju, receptih, razporejanju, analitiki in zdaj strojnem učenju. Ceni čisto napisano in dobro enotno preizkušeno kodo, vendar je nezdravo obseden z enovrstičnimi kodami. V prostem času rad posluša poddaje, medtem ko sprehaja svojega psa.

Sasank Vemuri je vodilni član tehničnega osebja pri athenahealth. Ima izkušnje pri razvoju podatkovno usmerjenih rešitev na področjih, kot so zdravstvo, zavarovalništvo in bioinformatika. Sasank trenutno sodeluje pri oblikovanju in razvoju platform za usposabljanje in sklepanje strojnega učenja na AWS in Kubernetes, ki pomagajo pri usposabljanju in uvajanju rešitev ML v velikem obsegu.

Anu Tumkur je arhitekt pri athenaealth. Anu ima več kot dve desetletji izkušenj na področju arhitekture, oblikovanja in razvoja različnih izdelkov programske opreme na področju strojnega učenja, operacij v oblaku, velikih podatkov, cevovodov porazdeljenih podatkov v realnem času, oglasne tehnologije, analitike podatkov, analitike družbenih medijev. Anu trenutno dela kot arhitekt v organizaciji produktnega inženiringa athenahealth v ekipah platforme strojnega učenja in podatkovnega cevovoda.

William Tsen je višji vodja inženiringa pri athenahealth. Ima več kot 20 let inženirskih vodstvenih izkušenj pri gradnji rešitev na področju informacijske tehnologije v zdravstvu, porazdeljenega računalništva z velikimi podatki, inteligentnih optičnih omrežij, sistemov za urejanje videa v realnem času, programske opreme za podjetja in sklepanja skupinskih zdravstvenih zavarovanj. William trenutno vodi dve izjemni ekipi pri athenahealth, inženirski ekipi Machine Learning Operations in DevOps v organizaciji Product Engineering.