AWS-is Kubeflow abil saate luua korduvaid, turvalisi ja laiendatavaid täismasinõppe töövooge

See on külaliste ajaveebi postitus, mille autoriks on athenahealth.

athenahealth juhtiv võrgutoega tarkvara ja teenuste pakkuja meditsiinirühmadele ja tervishoiusüsteemidele üleriigiliselt. Selle elektroonilised tervisekaardid, tulutsükli haldamine ja patsientide kaasamise tööriistad võimaldavad juurdepääsu igal ajal ja igal pool, pakkudes klientidele paremaid finantstulemusi ja võimaldades teenusepakkuja klientidel pakkuda kvaliteetsemat ravi.

Tehisintellekti (AI) ruumis kasutab athenahealth andmeteadust ja masinõpet (ML), et kiirendada äriprotsesse ning pakkuda soovitusi, prognoose ja teadmisi mitme teenuse kohta. Alates selle esmakordsest kasutuselevõtust automatiseeritud dokumenditeenustes, miljonite teenusepakkuja-patsiendi dokumentide puutevaba töötlemisest kuni hiljutise tööni virtuaalsete assistentidega ja tulutsükli jõudluse parandamiseni, jätkab athenahealth AI rakendamist, et aidata suurendada teenuseosutajate tõhusust, teenuseid ja paremaid tulemusi. ja nende patsiendid.

See ajaveebi postitus näitab, kuidas athenahealth kasutab Kubeflow AWS-is (Kubeflow AWS-spetsiifiline distributsioon), et luua ja täiustada täielikku andmeteaduse töövoogu, mis säilitab olulised tööriistad, optimeerib töötõhusust, suurendab andmeteadlaste tootlikkust ja loob aluse nende ML-i võimaluste hõlpsamaks laiendamiseks.

Kubeflow on avatud lähtekoodiga ML-platvorm, mis on mõeldud ML-i töövoogude juurutamise Kubernetesis lihtsaks, kaasaskantavaks ja skaleeritavaks muutmiseks. Kubeflow saavutab selle, lisades asjakohased avatud lähtekoodiga tööriistad, mis integreeruvad hästi Kubernetesiga. Mõned neist projektidest hõlmavad Argo torujuhtme orkestreerimiseks, Istio teenindusvõrgu jaoks, Jupyter sülearvutite jaoks, Spark, TensorBoard ja Katib. Kubeflow Pipelines aitab luua ja juurutada kaasaskantavaid skaleeritavaid ML-i töövooge, mis võivad hõlmata selliseid samme nagu andmete ekstraheerimine, eeltöötlus, mudelikoolitus ja mudeli hindamine korratavate torujuhtmete kujul.

AWS panustab avatud lähtekoodiga Kubeflow kogukonda, pakkudes oma Kubeflow distributsiooni (AWS-is nimetatakse Kubeflowks), mis aitab sellistel organisatsioonidel nagu athenahealth luua väga usaldusväärseid, turvalisi, kaasaskantavaid ja skaleeritavaid ML-i töövooge, mis on AWS-i hallatavate teenustega integreeritud väiksema töökuluga. AWS pakub erinevaid Kubeflow juurutamisvalikuid, nagu juurutamine koos Amazon Cognito, juurutamine koos Amazoni relatsioonide andmebaasiteenus (Amazon RDS) ja Amazoni lihtne salvestusteenus (Amazon S3) ja vanilje kasutuselevõtt. Lisateavet teenuse integreerimise ja kõigi nende valikute jaoks saadaolevate lisandmoodulite kohta leiate aadressilt Deployment.

Täna pakub Kubeflow AWS-is selget teed Kubeflow kasutamiseks, mida on täiendatud järgmiste AWS-teenustega:

Paljud AWS-i kliendid kasutavad AWS-i levitamise Kubeflow eeliseid, sealhulgas athenahealthi.

Siin arutab athenahealthi MLOpsi meeskond Kubeflow teekonnal tekkinud väljakutseid ja lahendusi.

Väljakutsed eelmise ML keskkonnaga

Enne Kubeflow kasutuselevõttu AWS-is kasutasid meie andmeteadlased standardiseeritud tööriistade komplekti ja protsessi, mis võimaldas antud mudeli koolitamiseks kasutatava tehnoloogia ja töövoo paindlikkust. Standardiseeritud tööriistade näideteks on andmete sisestamise API, turvaskannimise tööriistad, CI/CD torujuhe, mille on ehitanud ja hooldanud teine ​​athenahealthi meeskond ning ühine teenindusplatvorm, mille on ehitanud ja hooldanud MLOpsi meeskond. AI ja ML-i kasutuse arenedes kasvas aga iga mudeli jaoks loodud tööriistade ja infrastruktuuri valik. Kuigi saime endiselt olemasolevat protsessi toetada, nägime silmapiiril järgmisi väljakutseid:

• Hooldus ja kasv – Mudelite koolituskeskkondade reprodutseerimine ja hooldamine võttis kasutusele võetud mudelite arvu suurenedes rohkem vaeva. Iga projekt sisaldas üksikasjalikku dokumentatsiooni, mis kirjeldas, kuidas iga skripti lõpliku mudeli koostamiseks kasutati. Paljudel juhtudel oli see keerukas protsess, mis hõlmas 5–10 skripti, millest igaühel oli mitu väljundit. Neid tuli käsitsi jälgida koos üksikasjalike juhistega selle kohta, kuidas iga väljundit järgmistes protsessides kasutada. Selle säilitamine muutus aja jooksul tülikaks. Veelgi enam, kuna projektid muutusid keerukamaks, suurenes ka tööriistade arv. Näiteks kasutas enamik mudeleid Sparki ja TensorFlow koos GPU-dega, mis nõudis suuremat valikut keskkonnakonfiguratsioone. Aja jooksul lülitusid kasutajad oma arenduskeskkondades üle tööriistade uuematele versioonidele, kuid ei saanud seejärel käivitada vanemaid skripte, kui need versioonid ei ühildu. Järelikult nõudis vanemate projektide hooldamine ja täiendamine rohkem aega ja vaeva. Lisaks võttis uute andmeteadlaste meeskonnaga liitumisel teadmiste edasiandmine ja kasutuselevõtt rohkem aega, kuna kohalike keskkondade sünkroonimine hõlmas paljusid dokumenteerimata sõltuvusi. Projektide vahel vahetamisel tekkisid samad probleemid, kuna igal mudelil oli oma töövood.
• TURVALISUS – Suhtume turvalisusesse tõsiselt ja seetõttu peame esmatähtsaks kõigi rahapesu ja andmeteadusega seotud lepinguliste, juriidiliste ja regulatiivsete kohustuste täitmist. Andmeid tuleb kasutada, salvestada ja neile juurde pääseda kindlal viisil ning oleme manustanud tugevad protsessid, et tagada, et meie tavad vastaksid meie juriidilistele kohustustele ja oleksid vastavuses valdkonna parimate tavadega. Enne Kubeflow kasutuselevõttu hõlmas andmete kindlal viisil salvestamise ja juurdepääsu tagamine regulaarset kontrollimist mitmes erinevas töövoos. Teadsime, et saame tõhusust suurendada, koondades need erinevad töövood ühele platvormile. See platvorm peaks aga olema piisavalt paindlik, et integreeruda hästi meie standardiseeritud tööriistadega.
• Operations – Nägime ka võimalust suurendada tegevuse efektiivsust ja juhtimist läbi töövoogude logimise ja jälgimise tsentraliseerimise. Kuna iga meeskond oli välja töötanud oma tööriistad, kogusime selle teabe igast töövoost eraldi ja koondasime need kokku.

Andmeteaduse meeskond hindas erinevaid lahendusi töövoogude konsolideerimiseks. Lisaks nende nõuete täitmisele otsisime lahendust, mis oleks sujuvalt integreeritud olemasoleva standardiseeritud infrastruktuuri ja tööriistadega. Valisime oma töövoolahenduseks Amazon EKS ja Kubeflow AWS-is.

Andmeteadlase arendustsükkel, mis sisaldab Kubeflow'i

Andmeteaduse projekt algab puhtalt lehelt: pole andmeid, pole koodi, on ainult äriprobleem, mida saab ML-iga lahendada. Esimene ülesanne on kontseptsiooni tõend (POC), et teha kindlaks, kas andmetes on piisavalt signaali, et muuta ML-mudel äriprobleemi lahendamisel tõhusaks, alustades meie Snowflake'i andmelaost toorandmete kogumi päringutega. See etapp on iteratiivne ja andmeteadlased kasutavad selle protsessi käigus Kubernetese kaunasid või Kubeflow Jupyteri märkmikke.

Meie Kubeflow klaster kasutab Karpenteri klastri automaatset skaleerijat, mis muudab andmeteadlaste jaoks ressursside koondamise lihtsaks, kuna nad peavad keskenduma ainult soovitud eksemplaritüüpide määratlemisele, samal ajal kui ettevalmistamise töö teeb etteantud Karpenteri etteandjate komplekt. Meil on CPU ja GPU eksemplaritüüpide jaoks eraldi etteandjad ning kõik Amazon EKS-i toetatud eksemplarid kuuluvad meie varundaja konfiguratsiooni kohaselt ühte neist kahest kategooriast. Andmeteadlased valivad eksemplari tüübid sõlmede valijate abil ja Karpenter hoolitseb sõlme elutsükli haldamise eest.

Pärast päringu väljatöötamist eraldavad andmeteadlased toorandmed Amazon S3 asukohta ja käivitavad seejärel andmete uurimiseks AWS Kubeflow kasutajaliidesest Jupyteri sülearvuti. Eesmärk on luua funktsioonide komplekt, mida kasutatakse esimese mudeli koolitamiseks. See võimaldab andmeteadlastel kindlaks teha, kas andmetes on piisavalt signaali kliendi ärivajaduste täitmiseks.

Kui tulemused on rahuldavad, liiguvad andmeteadlased arendustsükli järgmisse etappi ja muudavad oma avastused tugevaks torujuhtmeks. Nad teisendavad POC-koodi tootmiskvaliteediga koodiks, mis töötab mastaapselt. Nõuetele vastavuse tagamiseks heakskiidetud teekide kasutamise kaudu luuakse sobiva Dockeri põhipildiga konteiner. Meie andmeteadlaste jaoks oleme leidnud, et standardse Pythoni, TensorFlow ja Sparki põhipildi pakkumine annab enamiku, kui mitte kõigi töökoormuste jaoks piisava paindlikkuse. Seejärel saavad nad kasutada oma komponendi Dockerfile'i oma arenduskeskkonna edasiseks kohandamiseks. Seejärel kasutab CI/CD protsess seda Dockeri faili tootmises kasutatavate komponentide kujutise loomiseks, säilitades seega arendus- ja tootmiskeskkondade vahelise kooskõla.

Meil on tööriist, mis annab andmeteadlastele võimaluse käivitada oma arenduskeskkond Kubernetes töötavas podis. Kui see pod töötab, saavad andmeteadlased Visual Studio Code IDE otse moodulisse lisada ja oma mudelikoodi siluda. Pärast koodi edukat käitamist saavad nad oma muudatused git-i edastada ja luuakse uus arenduskeskkond kõige värskemate muudatustega.

Standardne andmeteaduse torustik koosneb etappidest, mis hõlmavad ekstraheerimist, eeltöötlust, koolitust ja hindamist. Konveieri iga etapp kuvatakse Kubeflow komponendina, mis koosneb Kubernetese kaustast, mis käivitab käskluse, mille teave on parameetritena edastatud. Need parameetrid võivad olla staatilised väärtused või viited eelmise komponendi väljundile. Podis kasutatav Dockeri pilt on üles ehitatud CI/CD protsessist. Selle protsessi üksikasjad kuvatakse järgmises jaotises käsitletavas CI/CD töövoos.

Kubeflow arendustsükkel. Arendustöövoog algab vasakult POC-ga. Valmis mudel juurutatakse Amazon ECS-is töötavale athenahealthi mudeli teenindusplatvormile.

CI/CD protsess, mis toetab automatiseeritud töövooge

CI/CD protsessi osana kasutame Jenkinsi kõigi Kubeflow komponentide kujutiste paralleelseks ehitamiseks ja testimiseks. Eduka lõpetamise korral sisaldab konveieri komponendi mall piltidele viiteid ja saadud konveier laaditakse üles Kubeflowsse. Jenkinsi torujuhtme parameetrid võimaldavad kasutajatel torujuhtmeid käivitada ja pärast edukat ehitamist oma mudeli koolitusteste käivitada.

Teise võimalusena saavad andmeteadlased lühikese arendustsükli säilitamiseks torujuhtme käivitada ka oma kohalikust masinast, muutes mis tahes konveieri parameetreid, millega nad võivad katsetada.

On olemas tööriistad, mis tagavad, et vaikimisi kasutatakse CI/CD järgust pärinevaid viiteid. Kui repos on juurutav artefakt, jätkab CI/CD loogika artefakti juurutamist athenahealthi mudeli teenindusplatvormil (ennustusteenus), mis töötab Amazon ECS-is koos AWS Fargate. Pärast kõigi nende etappide möödumist ühendab andmeteadlane koodi esmase haruga. Seejärel suunatakse torujuhtmed ja kasutuselevõetavad artefaktid tootmisse.

CI/CD juurutamise töövoog. See diagramm kirjeldab Data Science'i koostamise ja juurutamise töövoogu. CI/CD protsessi juhib Jenkins.

TURVALISUS

Andmeteaduse töövoogude konsolideerimisel suutsime tsentraliseerida oma lähenemisviisi koolitustorustiku turvalisusele. Selles jaotises käsitleme oma lähenemisviisi andmete ja klastri turvalisusele.

Andmete turvalisus

Andmete turvalisus on athenahealthi jaoks ülimalt oluline. Sel põhjusel arendame ja hooldame infrastruktuuri, mis vastab täielikult nende andmete turvalisust ja terviklikkust kaitsvatele eeskirjadele ja standarditele.

Andmete vastavusstandarditele vastavuse tagamiseks pakume oma AWS-i infrastruktuuri vastavalt meie athenahealthi ettevõtte juhistele. Kaks peamist andmepoodi on Amazon RDS väga skaleeritavate torujuhtmete metaandmete jaoks ja Amazon S3 torujuhtmete ja mudelite artefaktide jaoks. Amazon S3 puhul tagame, et ämbrid on krüptitud, HTTPS-i lõpp-punktid on jõustatud ning ämbripoliitikad ja AWS-i identiteedi- ja juurdepääsuhaldus (IAM) rollid järgivad andmetele juurdepääsu lubamisel vähima privileegi põhimõtteid. See kehtib ka Amazon RDS-i andmete kohta: krüptimine on alati lubatud ning turvarühmad ja mandaatide juurdepääs järgivad vähima privileegide põhimõtet. See standardimine tagab, et andmetele on juurdepääs ainult volitatud osapooltel ja seda juurdepääsu jälgitakse.

Lisaks nendele meetmetele läbib platvorm ka turvaohu hinnanguid ning pidevaid turva- ja vastavuskontrolli.

Samuti käsitleme andmete säilitamise nõudeid kõigi tundlikke andmeid sisaldavate S3 ämbrite andmete elutsükli haldamise kaudu. See reegel teisaldab andmed automaatselt asukohta Amazon S3 liustik pärast 30 päeva loomist. Erandeid sellest hallatakse andmete otsimise taotluste kaudu ja need kinnitatakse või lükatakse tagasi igal üksikjuhul eraldi. See tagab, et kõik töövood järgivad andmete säilitamise poliitikat. See lahendab ka andmete taastamise probleemi, kui mudel töötab halvasti ja on vaja ümberõpet või kui uut mudelit tuleb hinnata vanema mudeli andmekogumi ajaloolise iteratsiooni alusel.

Amazon S3-le ja Amazon RDS-ile juurdepääsu piiramiseks Kubeflow'st AWS-is ja Amazon EKS-is kasutame IRSA-d (IAM Roles for Service Accounts), mis pakub Kubernetese ressursside jaoks IAM-põhist lubade pakkumist. Igal Kubeflow üürnikul on ainulaadne eelloodud teenusekonto, mille seome IAM-i rolliga, mis on loodud spetsiaalselt rentniku juurdepääsunõuete täitmiseks. Kasutajate juurdepääs rentnikele on samuti piiratud, kasutades iga kasutaja Amazon Cognito kasutajakogumi liikmelisust. Kui kasutaja on klastris autentitud, sisaldab loodud luba rühmanõudeid ja Kubernetes RBAC kasutab seda teavet klastri konkreetsele ressursile juurdepääsu lubamiseks või keelamiseks. Seda seadistust selgitatakse üksikasjalikumalt järgmises jaotises.

Klastri turvalisus mitme kasutaja isolatsiooni abil

Nagu eelmises jaotises märkisime, teevad andmeteadlased uurimuslikke andmeanalüüse, käitavad andmeanalüüsi ja koolitavad ML-mudeleid. Ressursside eraldamiseks, andmete korraldamiseks ja töövoogude haldamiseks projektide põhjal pakub Kubeflow AWS-is Kubernetese nimeruumidel põhinevat isolatsiooni. See isolatsioon töötab Kubeflow kasutajaliidesega suhtlemisel; aga see ei paku mingeid tööriistu Kubectli abil Kubernetes API-le juurdepääsu juhtimiseks. See tähendab, et kasutajate juurdepääsu saab juhtida Kubeflow kasutajaliideses, kuid mitte Kubectli kaudu Kubernetes API kaudu.

Järgmisel diagrammil kirjeldatud arhitektuur lahendab selle probleemi, ühendades juurdepääsu Kubeflow projektidele rühmaliikmete alusel. Selle saavutamiseks kasutasime ära AWS-i manifestide Kubeflow, mis on integreeritud Amazon Cognito kasutajakogumitega. Lisaks kasutame klastrisisese autoriseerimise kontrollimiseks Kubernetese rollipõhist juurdepääsukontrolli (RBAC). Kasutajaõigused on ette nähtud Amazon Cognito grupi liikmelisuse alusel. See teave edastatakse klastrile OIDC kliendi loodud märgiga. See protsess on lihtsustatud tänu sisseehitatud Amazon EKS-i funktsioonile, mis võimaldab siduda OIDC identiteedipakkujaid klastriga autentimiseks.

Vaikimisi teostab Amazon EKS-i autentimist IAM-i autentija, mis on tööriist, mis võimaldab autentida EKS-klastriga IAM-mandaatide abil. Sellel autentimismeetodil on oma eelised; aga see ei sobi meie kasutusjuhtumiks, kuna athenahealth kasutab identiteediteenuse jaoks kogu organisatsioonis Microsoft Azure Active Directoryt.

Kubernetese nimeruumi isoleerimine. Andmeteadlased saavad oma tööks vajaduse korral liikmeks saada ühte või mitmesse rühma. Juurdepääs vaadatakse regulaarselt üle ja vajaduse korral eemaldatakse.

Azure Active Directory, mis on kogu ettevõtet hõlmav identiteediteenus, on tõe allikas kasutajate juurdepääsu kontrollimiseks Kubeflow klastrile. Selle seadistus hõlmab Azure'i ettevõtterakenduse loomist, mis toimib teenuse pealinnana, ja rühmade lisamist erinevatele rentnikele, kes vajavad juurdepääsu klastrile. Seda Azure'i seadistust peegeldab Amazon Cognito, seadistades ühendatud OIDC identiteedi pakkuja, mis tellib autentimisvastutuse Azure'ilt. Juurdepääsu Azure'i rühmadele kontrollib SailPoint IdentityIQ, mis saadab projekti omanikule juurdepääsutaotlused lubamiseks või keelamiseks. Amazon Cognito kasutajate kogumis luuakse kaks rakendusklienti: ühte kasutatakse Kubernetese klastri autentimise seadistamiseks OIDC identiteedipakkuja abil ja teist Kubeflow autentimise tagamiseks Kubeflow kasutajaliideses. Need kliendid on konfigureeritud klastriga autentimisel grupinõudeid edastama ja neid rühmanõudeid kasutatakse koos RBAC-ga klastris autoriseerimise seadistamiseks.

Kubernetes RBAC rollide sidumised seadistatakse rühmade ja klastrirolli Kubeflow-edit vahel, mis luuakse Kubeflow installimisel klastris. See rolli sidumine tagab, et kõik kasutajad, kes suhtlevad klastriga pärast OIDC kaudu sisselogimist, pääsevad juurde nimeruumidele, mille jaoks neil on rühmanõuetes määratletud õigused. Kuigi see toimib kasutajate jaoks, kes suhtlevad klastriga Kubectli abil, ei paku Kubeflow kasutajaliides praegu kasutajatele juurdepääsu rühma liikmelisuse alusel, kuna see ei kasuta RBAC-i. Selle asemel kasutab see kasutajate juurdepääsu kontrollimiseks Istio autoriseerimispoliitika ressurssi. Selle väljakutse ületamiseks töötasime välja kohandatud kontrolleri, mis sünkroonib kasutajaid Amazon Cognito rühmade küsitlemise teel ja lisab või eemaldab vastavad rollide sidumised iga kasutaja jaoks, mitte rühmade kaupa. See seadistus võimaldab kasutajatel Kubeflow kasutajaliidese ja Kubectliga suhtlemisel omada sama taseme õigusi.

Tõhusus

Selles jaotises käsitleme seda, kuidas kasutasime meie käsutuses olevaid avatud lähtekoodiga ja AWS-i tööriistu oma töövoogude haldamiseks ja silumiseks ning Kubeflow täiendamise mõju minimeerimiseks.

Logimine ja jälgimine

Logimiseks kasutame FluentD-d, et suunata kõik meie konteineri logid Amazon OpenSearchi teenus ja süsteemimõõdikud Prometheusele. Seejärel kasutame logide ja mõõdikute otsimiseks ja filtreerimiseks Kibanat ja Grafana kasutajaliidest. Järgmine diagramm kirjeldab, kuidas me selle seadistame.

Kubeflow logimine. Logide vaatamiseks ja sõelumiseks kasutame nii Grafana kasutajaliidest kui ka Kibanat

Järgmine ekraanipilt on Kibana kasutajaliidese vaade meie torujuhtmest.

Kibana kasutajaliidese näidisvaade. Kibana võimaldab kohandatud vaateid.

Ohutu Kubeflow klastri uuendused

AWS-i Kubeflow kasutajate kaasamisel säilitame usaldusväärse ja järjepideva kasutuskogemuse, võimaldades samal ajal MLOpsi meeskonnal uute funktsioonide väljastamisel ja integreerimisel olla vilgas. Pealtnäha tundub Kustomize meie jaoks modulaarne, et võimaldada ühe komponendi korraga töötamist ja täiendamist ilma teisi mõjutamata, võimaldades seeläbi lisada uusi võimalusi kasutajaid minimaalselt häirides. Praktikas on aga stsenaariume, kus parim viis on lihtsalt luua uus Kubernetese klaster, selle asemel et rakendada olemasolevate klastrite komponenditaseme uuendusi. Leidsime kaks kasutusjuhtumit, mille puhul oli mõttekam luua täiesti uusi klastreid:

• Täiendamine Kubernetese versioonile, kus AWS pakub kohapealseid klastri värskendusi. Siiski muutub keeruliseks testida, kas Kubeflow ja Kubernetese ressursid töötavad ettenähtud viisil ja manifestid säilitavad tagasiühilduvuse.
• Kubeflow uuendamine uuemale versioonile, kuhu on lisatud või muudetud mitmeid funktsioone, ja peaaegu alati ei ole paljutõotav idee olemasolevas Kubernetese klastris kohapeal uuendada.

Selle probleemi lahendamiseks töötasime välja strateegia, mis võimaldab meil turvaliselt asendada klastreid, ilma et see mõjutaks olemasolevat töökoormust. Selle saavutamiseks pidime vastama järgmistele kriteeriumidele:

• Eraldage Kubeflow salvestus- ja arvutusressursid nii, et konveieri metaandmed, konveieri artefaktid ja kasutajaandmed säiliksid ka vanema klastri eraldamisel.
• Integreerige AWS-i manifestidega Kubeflow'ga, nii et Kubeflow versiooniuuenduse korral on vaja minimaalseid muudatusi
• Kui pärast klastri täiendamist läheb valesti, saate hõlpsasti tagasi pöörduda
• Kandidaadiklastri tootmisse viimiseks on lihtne liides

Järgmine diagramm illustreerib seda arhitektuuri.

Ohutu Kubeflow klastri uuendamine. Kui Kubeflow kandidaadi testimine on edukas, ülendatakse see marsruudi 53 värskenduse kaudu Kubeflow Prodi.

Kubeflow AWS-i manifestid on eelpakendatud Amazon RDS-i ja Amazon S3 integratsiooniga. Kuna need hallatavad teenused toimivad tavaliste andmehoidlatena, saame luua sinakasrohelise juurutusstrateegia. Selle saavutamiseks tagasime, et konveieri metaandmed säilitatakse Amazon RDS-is, mis töötab EKS-klastrist sõltumatult, ning konveieri logid ja artefaktid säilitatakse Amazon S3-s. Lisaks konveieri metaandmetele ja artefaktidele seadistasime ka FluentD, et suunata podlogid Amazon OpenSearch Service'i.

See tagab, et salvestuskiht on arvutuskihist täielikult eraldatud ja võimaldab seega testida muudatusi Kubeflow versiooniuuenduste ajal täiesti uues EKS-klastris. Kui kõik testid on edukad, saame lihtsalt muuta Amazoni tee 53 DNS-kirje Kubeflow'i hostiva kandidaatklastri jaoks. Lisaks hoiame vana klastri mõne päeva varukoopiana igaks juhuks, kui peaksime tagasi kerima.

Amazon EKS-i ja Kubeflow eelised AWS-is meie ML-i torujuhtme jaoks

Amazon EKS ja Kubeflow on AWS pakett viisid meie arendustöövoo mustrile, mis julgustab tugevalt korratavat mudelikoolitust. Need tööriistad võimaldavad meil täielikult määratletud klastreid koos täielikult määratletud rentnikega ja käitada täielikult määratletud koodi.

Paljud selle platvormi loomisest saadavad võidud on vähem kvantitatiivsed ja rohkem seotud sellega, kuidas töövood on nii platvormi arendajate kui ka kasutajate jaoks paranenud. Näiteks MinIO asendati otsese juurdepääsuga Amazon S3-le, mis viib meid lähemale meie algsetele töövoogudele ja vähendab teenuste arvu, mida peame säilitama. Samuti saame kasutada Amazon RDS-i Kubeflow taustaprogrammina, mis võimaldab hõlpsamat migratsiooni klastrite vahel ja annab meile võimaluse oma torujuhtmeid igal õhtul varundada.

Samuti leidsime, et Kubeflow integreerimise täiustused AWS-i hallatavate teenustega on kasulikud. Näiteks kui Amazon RDS, Amazon S3 ja Amazon Cognito on AWS-i manifestides Kubeflow eelkonfigureeritud, säästame aega ja vaeva Kubeflow uuematele distributsioonidele värskendamisel. Kui me muutsime ametlikke Kubeflow manifeste käsitsi, kulus uuele versioonile värskendamine projekteerimisest testimiseni mitu nädalat.

Amazon EKS-ile üleminek annab meile võimaluse määratleda oma klastri Kustomize'is (nüüd Kubectli osa) ja Terraformis. Selgub, et platvormitöö jaoks on Kubernetese ja Terraformiga väga lihtne töötada, kui õppimiseks on piisavalt aega panustatud. Pärast paljusid iteratsioone muudavad meie käsutuses olevad tööriistad väga lihtsaks standardsete platvormitoimingute tegemise, nagu komponendi täiendamine või terve arendusklastri väljavahetamine. Võrreldes toorelt töö tegemisega Amazon Elastic Compute Cloud (Amazon EC2) juhtumite puhul on raske võrrelda, kui tohutut vahet on see, kui on hästi määratletud taskud, millel on garanteeritud ressursside puhastamise ja uuesti proovimise mehhanismid.

Kubernetes pakub suurepäraseid turvastandardeid ja oleme vaid kriimustanud seda, mida mitme kasutaja isolatsioon võimaldab meil teha. Näeme mitme kasutaja isolatsiooni mustrina, millel on tulevikus rohkem kasu, kui koolitusplatvorm toodab tootmistaseme andmeid, ja kaasame arendajaid väljastpoolt meie meeskonda.

Samal ajal võimaldab Kubeflow meil saada reprodutseeritavat mudelikoolitust. Isegi samade andmete korral ei loo ükski koolitus identseid mudeleid, kuid meil on paremuselt järgmine asi. Kubeflow abil teame täpselt, millist koodi ja andmeid mudeli koolitamiseks kasutati. Sisselülitamine on oluliselt paranenud, kuna meie konveieri iga samm on selgelt ja programmiliselt määratletud. Kui uute andmeteadlaste ülesandeks on viga parandada, vajavad nad palju vähem käsihoidmist, kuna koodi väljundite kasutamise etappide vahel on selge struktuur.

Kubeflow kasutamine annab ka palju jõudluse täiustusi võrreldes ühe EC2 eksemplari töötamisega. Sageli vajavad andmeteadlased mudelikoolituses eeltöötluseks ja koolituseks erinevaid tööriistu ja optimeerimisi. Näiteks kasutatakse eeltöötlust sageli hajutatud andmetöötlustööriistade (nt Spark) abil, samas kui koolitust kasutatakse sageli GPU eksemplaride abil. Kubeflow konveieritega saavad nad konveieri eri etappide jaoks määrata erinevad eksemplaritüübid. See võimaldab neil kasutada ühes etapis võimsaid GPU eksemplare ja teises etapis hajutatud töötlemiseks väiksemaid masinaid. Kuna Kubeflow torujuhtmed kirjeldavad etappide vahelisi sõltuvusi, saavad torujuhtmed etappe paralleelselt käivitada.

Lõpuks, kuna lõime üürnike klastris lisamise protsessi, on nüüd ametlikum viis klastri rentnikuks meeskondade registreerimiseks. Kuna me kasutame Kubecosti oma EKS-i klastri kulude jälgimiseks, võimaldab see meil omistada kulud ühele projektile, selle asemel, et kulusid omistada konto tasemel, mis hõlmab kõiki andmeteaduse projekte. Kubecost esitab aruande kulutatud raha kohta nimeruumi kohta, mis on tihedalt seotud üürniku või meeskonnaga, kes vastutab torujuhtme juhtimise eest.

Hoolimata kõigist eelistest soovitame sellist migratsiooni teha ainult siis, kui kasutajad on täielikult sisseostnud. Kasutajad, kes kulutavad aega, saavad Amazon EKS-i ja Kubernetese kasutamisest palju kasu, kuid õppimiskõver on märkimisväärne.

Järeldus

Kubeflow on AWS torujuhtme juurutamine meie täielikus ML-i infrastruktuuris, suutsime konsolideerida ja standardida oma andmeteaduse töövooge, säilitades samas olulised tööriistad (nagu CI/CD ja mudelite teenindamine). Meie andmeteadlased saavad nüüd sellel töövool põhinevate projektide vahel liikuda, ilma et oleks vaja õppida, kuidas hooldada täiesti teistsugust tööriistakomplekti. Mõnede meie mudelite puhul olime meeldivalt üllatunud ka uue töövoo kiiruse üle (viis korda kiirem), mis võimaldas rohkem koolituste iteratsioone ja sellest tulenevalt paremate prognoosidega mudeleid.

Samuti oleme loonud tugeva aluse oma MLOps-i võimaluste suurendamiseks ning projektide arvu ja mahu suurendamiseks. Näiteks kui me karmistame oma juhtimisasendit mudeliliini ja jälgimise osas, oleme keskendunud enam kui 15 töövoo asemel ühele. Ja kui Log4shelli haavatavus 2021. aasta lõpus ilmsiks tuli, saime keskenduda ühele töövoole ja vajadusel kiiresti parandada (toimides Amazoni elastsete konteinerite register (Amazon ECR) skannib, uuendab Amazon OpenSearch Service, värskendab meie tööriistu ja palju muud), avaldades minimaalset mõju andmeteadlaste käimasolevale tööle. Kui AWS-i ja Kubeflow täiustused muutuvad kättesaadavaks, saame need lisada oma äranägemise järgi.

See viib meid meie Kubeflow AWS-i kasutuselevõtu olulise ja alahinnatud aspekti juurde. Üks selle teekonna kriitilisi tulemusi on võimalus Kubeflow versiooniuuendusi ja täiustusi meie andmeteadlaste jaoks sujuvalt kasutusele võtta. Kuigi arutasime oma lähenemisviisi sellele varem, tugineme ka AWS-i pakutavatele Kubeflow manifestidele. Alustasime oma Kubeflow teekonda kontseptsiooni tõestuseks 2019. aastal, enne versiooni 1.0.0 väljaandmist. (Praegu kasutame versiooni 1.4.1, hindame 1.5. AWS töötab juba versiooni 1.6 kallal.) Vahepealse 3 aasta jooksul on välja antud vähemalt kuus märkimisväärse sisuga väljaannet. Tänu oma distsiplineeritud lähenemisviisile nende uuenduste integreerimisele ja valideerimisele ning manifestide prognoositavale ja usaldusväärsele ajakavale avaldamisele on AWS-i Kubeflow meeskond olnud otsustava tähtsusega, võimaldades athenahealthi MLOpsi meeskonnal kavandada meie arendusplaani ja sellest tulenevalt ka meie ressursside jaotust ja fookusvaldkondi. , kaugemale tulevikku suurema enesekindlusega.

Saate jälgida AWS Labsi GitHubi hoidla et jälgida kõiki Kubeflow'i AWS-i kaastöid. AWS-i meeskonnad leiate ka saidilt Kubeflow #AWS Slack Channel; teie tagasiside aitab AWS-il seada prioriteediks järgmised funktsioonid, mis aitavad Kubeflow projekti kaasa aidata.

---

Autoritest

Kanwaljit Khurmi on Amazon Web Services'i lahenduste vanemarhitekt. Ta teeb koostööd AWS-i klientidega, et pakkuda juhiseid ja tehnilist abi, mis aitab neil AWS-i kasutamisel oma lahenduste väärtust tõsta. Kanwaljit on spetsialiseerunud klientide abistamisele konteiner- ja masinõpperakendustega.

Tyler Kalbach on athenahealthi tehnilise personali peamine liige. Tyleril on ligikaudu 7-aastane kogemus Analyticsi, andmeteaduse, närvivõrkude ja masinõpperakenduste arendamisel tervishoiuvaldkonnas. Ta on panustanud mitmesse masinõppelahendusse, mis praegu teenindavad tootmisliiklust. Praegu athenahealthi inseneriorganisatsioonis peaandmeteadlasena töötav Tyler on selle jõupingutuse algusest peale olnud osa meeskonnast, kes on loonud Athenahealthi jaoks uue masinõppe koolitusplatvormi.

Viktor Krylov on athenahealthi tehnilise personali peamine liige. Victor on insener ja scrum-meister, kes aitab andmeteadlastel luua turvalisi kiireid masinõppe torujuhtmeid. Ateenatervises on ta töötanud liideste, kliiniliste tellimiste, retseptide, ajakava, analüüsi ja nüüd masinõppe kallal. Ta hindab puhtalt kirjutatud ja hästi testitud koodi, kuid tal on ebatervislik kinnisidee ühe joonega koodide vastu. Vabal ajal meeldib talle koeraga jalutades podcaste kuulata.

Sasank Vemuri on athenahealthi tehnilise personali juhtiv liige. Tal on kogemusi andmepõhiste lahenduste väljatöötamisel sellistes valdkondades nagu tervishoid, kindlustus ja bioinformaatika. Sasank töötab praegu AWS-is ja Kubernetesis masinõppe koolitus- ja järeldusplatvormide kavandamise ja arendamisega, mis aitavad koolitada ja ML-lahendusi ulatuslikult juurutada.

Anu Tumkur on athenahealthi arhitekt. Anul on üle kahe aastakümne pikkune arhitektuuri-, disaini- ja arenduskogemus erinevate tarkvaratoodete loomisel masinõppes, pilveoperatsioonides, suurandmetes, reaalajas hajutatud andmekanalites, reklaamitehnoloogias, andmeanalüütikas, sotsiaalmeedia analüütikas. Anu töötab praegu arhitektina athenahealthi tootetehnoloogia organisatsioonis masinõppeplatvormi ja andmetorustiku meeskondades.

William Tsen on athenahealthi vaneminsenerijuht. Tal on üle 20-aastane insenerijuhtimise kogemus tervishoiu IT-lahenduste, suurandmete hajutatud andmetöötluse, intelligentsete optiliste võrkude, reaalajas videotöötlussüsteemide, ettevõttetarkvara ja tervishoiuteenuste grupikindlustuse vallas. William juhib praegu athenahealthi kahte vinget meeskonda, masinõppe operatsioonide ja DevOpsi insenerimeeskondi tootetehnoloogia organisatsioonis.