Rakenna toistettavia, turvallisia ja laajennettavia päästä päähän koneoppimisen työnkulkuja Kubeflown avulla AWS:ssä

Tämä on vierasblogiviesti, jonka on kirjoittanut athenahealth.

ateenaterveys johtava verkkopohjaisten ohjelmistojen ja palvelujen toimittaja lääketieteellisille ryhmille ja terveydenhuoltojärjestelmille valtakunnallisesti. Sen sähköiset terveystiedot, tulosyklin hallinta ja potilaiden sitouttamistyökalut mahdollistavat pääsyn milloin tahansa ja missä tahansa, mikä parantaa asiakkailleen taloudellisia tuloksia ja mahdollistaa palveluntarjoajan asiakkailleen laadukkaamman hoidon.

Tekoälyavaruudessa athenahealth käyttää datatieteitä ja koneoppimista (ML) nopeuttaakseen liiketoimintaprosesseja ja tarjotakseen suosituksia, ennusteita ja oivalluksia useissa palveluissa. Athenahealth jatkaa tekoälyn soveltamista tehostaakseen tehokkuutta, palveluvalmiuksia ja parempia tuloksia palveluntarjoajien käyttöönotosta, joka käsittelee kosketuksetta miljoonia palveluntarjoajien ja potilaiden asiakirjoja, uudempiin töihinsä virtuaaliassistenttien parissa ja tulojakson suorituskyvyn parantamisessa. ja heidän potilailleen.

Tämä blogikirjoitus osoittaa, kuinka athenahealth käyttää Kubeflow AWS:ssä (AWS-spesifinen Kubeflow-jakelu) rakentaa ja virtaviivaistaa päästä päähän datatieteen työnkulkua, joka säilyttää olennaiset työkalut, optimoi toiminnan tehokkuuden, lisää datatieteilijöiden tuottavuutta ja luo pohjan heidän ML-ominaisuuksien laajentamiselle helpommin.

Kubeflow on avoimen lähdekoodin ML-alusta, joka on omistettu tekemään ML-työnkulkujen käyttöönotosta Kubernetesissa yksinkertaista, kannettavaa ja skaalautuvaa. Kubeflow saavuttaa tämän sisällyttämällä asiaankuuluvat avoimen lähdekoodin työkalut, jotka integroituvat hyvin Kubernetesiin. Joitakin näistä projekteista ovat muun muassa Argo pipeline-orkestrointiin, Istio palveluverkkoon, Jupyter kannettaviin kirjoihin, Spark, TensorBoard ja Katib. Kubeflow Pipelines auttaa rakentamaan ja ottamaan käyttöön kannettavia, skaalautuvia ML-työnkulkuja, jotka voivat sisältää vaiheita, kuten tietojen poiminta, esikäsittely, mallin koulutus ja mallin arviointi toistettavien liukuputkien muodossa.

AWS edistää avoimen lähdekoodin Kubeflow-yhteisöä tarjoamalla oman Kubeflow-jakelunsa (Kubeflow AWS:ssä), joka auttaa athenahealthin kaltaisia ​​organisaatioita rakentamaan erittäin luotettavia, turvallisia, kannettavia ja skaalautuvia ML-työnkulkuja alentuneilla käyttökustannuksilla integroimalla AWS:n hallinnoimiin palveluihin. AWS tarjoaa erilaisia ​​Kubeflow-käyttöönottovaihtoehtoja, kuten käyttöönotto Amazon Cognito, käyttöönotto kanssa Amazon Relational Database -palvelu (Amazon RDS) ja Amazonin yksinkertainen tallennuspalvelu (Amazon S3) ja vaniljakäyttöön. Katso lisätietoja palvelun integroinnista ja kullekin näistä vaihtoehdoista saatavilla olevista lisäosista käyttöönoton.

Nykyään Kubeflow AWS:ssä tarjoaa selkeän polun Kubeflown käyttöön, jota täydentävät seuraavat AWS-palvelut:

Monet AWS-asiakkaat hyödyntävät Kubeflowa AWS-jakelussa, mukaan lukien athenahealth.

Täällä athenahealth MLOps -tiimi keskustelee Kubeflow-matkallaan kohtaamistaan ​​haasteista ja ratkaisuista.

Haasteita edellisen ML-ympäristön kanssa

Ennen kuin otimme käyttöön Kubeflown AWS:ssä, datatutkijamme käyttivät standardoitua työkalusarjaa ja prosessia, joka mahdollisti joustavuuden tietyn mallin kouluttamiseen käytetyssä tekniikassa ja työnkulussa. Standardoidun työkalun esimerkkikomponentteja ovat tiedonkäsittely-API, suojausskannaustyökalut, toisen athenahealth-ryhmän rakentama ja ylläpitämä CI/CD-putki sekä MLOps-tiimin rakentama ja ylläpitämä yhteinen palvelualusta. Tekoälyn ja ML:n käyttömme kehittyessä kullekin mallille luotujen työkalujen ja infrastruktuurin valikoima kuitenkin kasvoi. Vaikka pystyimme edelleen tukemaan olemassa olevaa prosessia, näimme horisontissa seuraavat haasteet:

• Ylläpito ja kasvu – Mallin koulutusympäristöjen kopiointi ja ylläpito vaati enemmän vaivaa, kun käyttöön otettujen mallien määrä kasvoi. Kussakin projektissa oli yksityiskohtainen dokumentaatio, jossa kerrottiin, kuinka kutakin komentosarjaa käytettiin lopullisen mallin rakentamiseen. Monissa tapauksissa tämä oli monimutkainen prosessi, joka sisälsi 5–10 skriptiä, joissa kussakin oli useita lähtöjä. Näitä oli seurattava manuaalisesti yksityiskohtaisilla ohjeilla siitä, kuinka kutakin tulostetta käytetään myöhemmissä prosesseissa. Tämän ylläpitäminen muuttui ajan myötä hankalaksi. Lisäksi projektien monimutkaistuessa myös työkalujen määrä kasvoi. Esimerkiksi useimmat mallit käyttivät Sparkia ja TensorFlowia GPU:iden kanssa, mikä vaati suuremman valikoiman ympäristökonfiguraatioita. Ajan myötä käyttäjät vaihtoivat työkalujen uudempiin versioihin kehitysympäristöissään, mutta eivät voineet suorittaa vanhempia komentosarjoja, kun niistä tuli yhteensopimattomia. Näin ollen vanhempien projektien ylläpito ja laajentaminen vaati enemmän suunnitteluaikaa ja vaivaa. Lisäksi kun uusia datatieteilijöitä liittyi tiimiin, tiedon siirto ja käyttöönotto veivät enemmän aikaa, koska paikallisten ympäristöjen synkronointi sisälsi monia dokumentoimattomia riippuvuuksia. Projektien välillä vaihtaminen kohtasi samoja ongelmia, koska jokaisella mallilla oli omat työnkulkunsa.
• Turvallisuus – Suhtaudumme turvallisuuteen vakavasti, ja siksi asetamme etusijalle kaikkien ML- ja datatieteeseen liittyvien sopimus-, laki- ja säädösvelvoitteiden noudattamisen. Tietoja on käytettävä, tallennettava ja käytettävä tietyillä tavoilla, ja olemme sulauttaneet vankat prosessit varmistaaksemme, että käytäntömme ovat lakisääteisten velvoitteidemme mukaisia ​​ja alan parhaiden käytäntöjen mukaisia. Ennen Kubeflow-käyttöönottoa tietojen tallentamisen ja käytön varmistaminen tietyllä tavalla sisälsi säännöllisen todentamisen useissa eri työnkuluissa. Tiesimme, että voisimme parantaa tehokkuutta yhdistämällä nämä monipuoliset työnkulut yhdelle alustalle. Tämän alustan on kuitenkin oltava tarpeeksi joustava integroidakseen hyvin standardoitujen työkalujemme kanssa.
• Operations – Näimme myös mahdollisuuden lisätä toiminnan tehokkuutta ja hallintaa keskittämällä työnkulkujen kirjaaminen ja seuranta. Koska jokainen tiimi oli kehittänyt omat työkalunsa, keräsimme nämä tiedot kustakin työnkulusta erikseen ja kokosimme ne yhteen.

Datatieteen tiimi arvioi erilaisia ​​ratkaisuja työnkulkujen yhdistämiseen. Näiden vaatimusten lisäksi etsimme ratkaisua, joka integroituisi saumattomasti olemassa olevaan standardoituun infrastruktuuriin ja työkaluihin. Valitsimme työnkulkuratkaisuksemme Amazon EKS:n ja Kubeflow on AWS.

Tietotutkijan kehityssykli, joka sisältää Kubeflown

Datatiedeprojekti alkaa puhtaalta pöydältä: ei dataa, ei koodia, vain liiketoimintaongelma, joka voidaan ratkaista ML:llä. Ensimmäinen tehtävä on proof of concept (POC) sen selvittämiseksi, sisältääkö tiedoissa tarpeeksi signaalia, jotta ML-malli olisi tehokas ratkaisemaan liiketoimintaongelman. Aloitetaan käsittelemällä raakadatajoukko Snowflake-tietovarastosta. Tämä vaihe on iteratiivinen, ja datatieteilijät käyttävät Kubernetes-tyynyjä tai Kubeflow Jupyter -muistikirjoja tämän prosessin aikana.

Kubeflow-klusterimme käyttää Karpenter-klusterin automaattista skaalainta, joka tekee resurssien pyörittämisestä helppoa datatieteilijöille, koska heidän tarvitsee keskittyä vain haluttujen ilmentymien tyyppien määrittämiseen, kun taas provisiointityön tekee joukko ennalta määritettyjä Karpenter-provisioijia. Meillä on erilliset provisiotit prosessorin ja grafiikkasuorittimen ilmentymätyypeille, ja kaikki Amazon EKS:n tukemat ilmentymät kuuluvat johonkin näistä kahdesta luokasta palveluntarjoajan kokoonpanomme mukaan. Datatieteilijät valitsevat ilmentymätyypit solmuvalitsimien avulla, ja Karpenter huolehtii solmun elinkaaren hallinnasta.

Kun kysely on kehitetty, datatieteilijät poimivat raakadatan paikkaan Amazon S3:ssa ja käynnistävät sitten Jupyter-muistikirjan AWS Kubeflow -käyttöliittymästä tutkiakseen tietoja. Tavoitteena on luoda ominaisuusjoukko, jota käytetään ensimmäisen mallin kouluttamiseen. Näin datatutkijat voivat määrittää, onko tiedoissa tarpeeksi signaalia asiakkaan liiketoiminnan tarpeiden täyttämiseksi.

Kun tulokset ovat tyydyttäviä, datatieteilijät siirtyvät kehityssyklin seuraavaan vaiheeseen ja muuttavat löytönsä vankaksi putkilinjaksi. Ne muuntavat POC-koodin tuotantolaatuiseksi koodiksi, joka toimii mittakaavassa. Jotta varmistetaan noudattaminen käyttämällä hyväksyttyjä kirjastoja, luodaan säilö sopivalla Docker-peruskuvalla. Tietotieteilijöillemme olemme havainneet, että Python-, TensorFlow- ja Spark-peruskuvan tarjoaminen tarjoaa riittävän joustavuuden useimmille, ellei kaikille, työkuormille. He voivat sitten käyttää komponenttinsa Docker-tiedostoa kehitysympäristönsä mukauttamiseen. CI/CD-prosessi käyttää sitten tätä Docker-tiedostoa tuotannossa käytettävän komponenttikuvan rakentamiseen, mikä ylläpitää johdonmukaisuutta kehitys- ja tuotantoympäristöjen välillä.

Meillä on työkalu, joka antaa datatieteilijöille mahdollisuuden käynnistää kehitysympäristönsä Kubernetesissa toimivassa podissa. Kun tämä pod on käynnissä, datatutkijat voivat liittää Visual Studio Code IDE:n suoraan podiin ja korjata mallikoodinsa. Kun koodi on suoritettu onnistuneesti, he voivat työntää muutokset gitiin ja uusi kehitysympäristö luodaan uusimmilla muutoksilla.

Vakiotietotieteen putki koostuu vaiheista, jotka sisältävät poiminnan, esikäsittelyn, koulutuksen ja arvioinnin. Jokainen liukuhihnan vaihe näkyy Kubeflow-komponenttina, joka koostuu Kubernetes-podista, joka suorittaa komennon, jossa on joitain tietoja, jotka on siirretty parametreina. Nämä parametrit voivat olla joko staattisia arvoja tai viittauksia edellisen komponentin ulostuloon. Podissa käytetty Docker-kuva on rakennettu CI/CD-prosessista. Tämän prosessin yksityiskohdat näkyvät seuraavassa osiossa käsitellyssä CI/CD-työnkulussa.

Kehityssykli Kubeflowssa. Kehitystyönkulku alkaa vasemmalta POC:lla. Valmis malli otetaan käyttöön Amazon ECS:ssä toimivalle athenahealth-mallin palvelualustalle.

CI/CD-prosessi tukee automatisoituja työnkulkuja

Osana CI/CD-prosessiamme käytämme Jenkinsiä kaikkien Kubeflow-komponenttien kuvien rakentamiseen ja testaamiseen rinnakkain. Onnistuneen valmistumisen jälkeen liukuhihnakomponenttimalli sisältää viiteosoittimia kuviin, ja tuloksena oleva liukuhihna ladataan Kubeflow:hon. Jenkins-putkilinjan parametrien avulla käyttäjät voivat käynnistää putkistot ja suorittaa mallin koulutustestejä onnistuneiden koonnosten jälkeen.

Vaihtoehtoisesti lyhyen kehityssyklin ylläpitämiseksi datatieteilijät voivat myös käynnistää putkilinjan paikalliselta koneeltaan muuttamalla mahdollisesti kokeilemansa putkilinjan parametreja.

On olemassa työkaluja, joilla varmistetaan, että CI/CD-koontiversion viiteosoittimia käytetään oletusarvoisesti. Jos repossa on käyttöönotettavissa oleva artefakti, CI/CD-logiikka jatkaa artefaktin asentamista athenahealth-mallin palvelualustalle (Prediction Service), joka toimii Amazon ECS:ssä. AWS-veljeskunta. Kun kaikki nämä vaiheet on ohitettu, datatieteilijä yhdistää koodin ensisijaiseen haaraan. Putket ja käyttöön otettavat artefaktit työnnetään sitten tuotantoon.

CI/CD-käyttöönoton työnkulku. Tämä kaavio kuvaa Data Sciencen koonti- ja käyttöönottotyönkulkua. CI/CD-prosessia ohjaa Jenkins.

Turvallisuus

Tietotieteen työnkulkujamme yhdistäessämme pystyimme keskittämään lähestymistapamme koulutusputken turvaamiseen. Tässä osiossa käsittelemme lähestymistapaamme tieto- ja klusteriturvallisuuteen.

Tietoturva

Tietoturva on äärimmäisen tärkeää athenahealthille. Tästä syystä kehitämme ja ylläpidämme infrastruktuuria, joka on täysin näiden tietojen turvallisuutta ja eheyttä suojaavien määräysten ja standardien mukainen.

Varmistaaksemme tietojen vaatimustenmukaisuuden noudattamisen tarjoamme AWS-infrastruktuurimme athenahealth-yritysohjeidemme mukaisesti. Kaksi tärkeintä datavarastoa ovat Amazon RDS erittäin skaalautuvalle liukuhihnan metadatalle ja Amazon S3 putkisto- ja malliartefakteille. Amazon S3:ssa varmistamme, että säilöt on salattu, HTTPS-päätepisteet pakotetaan ja säilökäytännöt ja AWS-henkilöllisyyden ja käyttöoikeuksien hallinta (IAM) roolit noudattavat vähiten etuoikeusperiaatteita salliessaan pääsyn tietoihin. Tämä pätee myös Amazon RDS -tietoihin: salaus on aina käytössä, ja suojausryhmät ja tunnistetietojen käyttö noudattavat vähiten etuoikeuksien periaatetta. Tämä standardointi varmistaa, että vain valtuutetuilla osapuolilla on pääsy tietoihin, ja tätä pääsyä seurataan.

Näiden toimenpiteiden lisäksi alustalle tehdään myös turvallisuusuhkien arvioinnit ja jatkuvat turvallisuus- ja vaatimustenmukaisuustarkistukset.

Käsittelemme myös tietojen säilytysvaatimuksia kaikkien arkaluontoisia tietoja sisältävien S3-ryhmien tietojen elinkaarihallinnan avulla. Tämä käytäntö siirtää tiedot automaattisesti kohteeseen Amazon S3 -jäätikkö 30 päivän luomisen jälkeen. Poikkeuksia tästä hoidetaan tiedonhakupyyntöjen kautta ja ne hyväksytään tai evätään tapauskohtaisesti. Tämä varmistaa, että kaikki työnkulut ovat tietojen säilytyskäytännön mukaisia. Tämä ratkaisee myös ongelman tietojen palauttamisessa, jos malli toimii huonosti ja tarvitaan uudelleenkoulutusta tai kun uusi malli on arvioitava verrattuna vanhan mallin tietojoukon historialliseen iteraatioon.

Rajoitamme Amazon S3:n ja Amazon RDS:n pääsyä Kubeflow:sta AWS:ssä ja Amazon EKS:ssä käyttämällä IRSA:ta (IAM Roles for Service Accounts), joka tarjoaa IAM-pohjaisen käyttöoikeusvarauksen Kubernetesin resursseille. Jokaisella Kubeflow-vuokralaisella on ainutlaatuinen valmiiksi luotu palvelutili, jonka sitomme IAM-rooliin, joka on luotu nimenomaan täyttämään vuokralaisen käyttöoikeusvaatimukset. Käyttäjien pääsy vuokralaisiin on myös rajoitettu käyttämällä Amazon Cognito -käyttäjäpoolien ryhmäjäsenyyttä jokaiselle käyttäjälle. Kun käyttäjä on todennettu klusteriin, luotu merkki sisältää ryhmävaatimuksia, ja Kubernetes RBAC käyttää näitä tietoja salliakseen tai estääkseen pääsyn tiettyyn resurssiin klusterissa. Tämä asetus selitetään yksityiskohtaisemmin seuraavassa osassa.

Klusterin suojaus usean käyttäjän eristyksen avulla

Kuten edellisessä osiossa totesimme, datatieteilijät suorittavat tutkivia dataanalyysejä, suorittavat data-analytiikkaa ja kouluttavat ML-malleja. Kubeflow on AWS tarjoaa Kubernetes-nimitiloihin perustuvan eristyksen resurssien allokoimiseksi, tietojen järjestämiseksi ja työnkulkujen hallintaan projekteihin perustuen. Tämä eristys toimii vuorovaikutuksessa Kubeflow-käyttöliittymän kanssa; Se ei kuitenkaan tarjoa työkaluja Kubernetes API:n pääsyn hallitsemiseen Kubectlin avulla. Tämä tarkoittaa, että käyttäjien pääsyä voidaan hallita Kubeflow-käyttöliittymässä, mutta ei Kubernetes API:n kautta Kubectlin kautta.

Seuraavassa kaaviossa kuvattu arkkitehtuuri korjaa tämän ongelman yhdistämällä pääsyn projekteihin Kubeflowssa ryhmäjäsenyyksien perusteella. Tämän saavuttamiseksi hyödynsimme Kubeflow on AWS-luetteloita, jotka on integroitu Amazon Cogniton käyttäjäryhmiin. Lisäksi käytämme Kubernetes-roolipohjaista pääsynhallintaa (RBAC) valvoaksemme valtuutusta klusterin sisällä. Käyttäjän käyttöoikeudet määräytyvät Amazon Cognito -ryhmän jäsenyyden perusteella. Nämä tiedot välitetään klusteriin OIDC-asiakkaan luomalla tunnuksella. Tämä prosessi on yksinkertaistettu sisäänrakennetun Amazon EKS -toiminnon ansiosta, jonka avulla OIDC-identiteetin tarjoajat voivat todentaa klusterin kanssa.

Oletusarvoisesti Amazon EKS -todennuksen suorittaa IAM-todentaja, joka on työkalu, joka mahdollistaa todennuksen EKS-klusterilla IAM-tunnistetiedoilla. Tällä todennusmenetelmällä on puolensa; Se ei kuitenkaan sovellu käyttötapaukseemme, koska athenahealth käyttää Microsoft Azure Active Directorya identiteettipalveluun koko organisaatiossa.

Kubernetes-nimitilan eristäminen. Tietotieteilijät voivat saada jäsenyyden yhteen tai useampaan ryhmään työnsä tarpeen mukaan. Käyttöoikeudet tarkistetaan säännöllisesti ja poistetaan tarvittaessa.

Azure Active Directory, joka on koko yrityksen kattava identiteettipalvelu, on totuuden lähde käyttäjien pääsyn hallintaan Kubeflow-klusteriin. Tätä varten luodaan Azure Enterprise -sovellus, joka toimii palvelun päämiehenä, ja ryhmien lisääminen eri vuokralaisille, jotka vaativat pääsyn klusteriin. Tämä Azure-määritys näkyy Amazon Cognitossa määrittämällä hajautetun OIDC-identiteetin tarjoajan, joka ulkoistaa todennusvastuun Azurelle. Pääsyä Azure-ryhmiin hallitsee SailPoint IdentityIQ, joka lähettää käyttöoikeuspyynnöt projektin omistajalle salliakseen tai estääkseen tarpeen mukaan. Amazon Cogniton käyttäjäpankkiin luodaan kaksi sovellusasiakasta: toista käytetään Kubernetes-klusterin todennusmääritykseen OIDC-identiteetin tarjoajan avulla ja toista Kubeflow-todennuksen turvaamiseen Kubeflow-käyttöliittymään. Nämä asiakkaat on määritetty välittämään ryhmävaatimukset todennuksen yhteydessä klusterin kanssa, ja näitä ryhmävaatimuksia käytetään yhdessä RBAC:n kanssa valtuutuksen määrittämiseen klusterin sisällä.

Kubernetes RBAC -roolisidokset määritetään ryhmien ja klusterin roolin Kubeflow-edit välille, joka luodaan, kun Kubeflow asennetaan klusteriin. Tämä roolisidonta varmistaa, että kaikki käyttäjät, jotka ovat vuorovaikutuksessa klusterin kanssa OIDC:n kautta sisäänkirjautumisen jälkeen, voivat käyttää nimiavaruuksia, joihin heillä on ryhmävaatimuksissaan määritellyt oikeudet. Vaikka tämä toimii käyttäjille, jotka ovat vuorovaikutuksessa klusterin kanssa Kubectlin avulla, Kubeflow-käyttöliittymä ei tällä hetkellä tarjoa käyttäjille pääsyä ryhmäjäsenyyden perusteella, koska se ei käytä RBAC:tä. Sen sijaan se käyttää Istio Authorization Policy -resurssia käyttäjien pääsyn hallintaan. Tämän haasteen voittamiseksi kehitimme mukautetun ohjaimen, joka synkronoi käyttäjät kyselyillä Amazon Cognito -ryhmistä ja lisää tai poistaa vastaavat roolisidokset jokaiselle käyttäjälle ryhmien sijaan. Tämän asennuksen ansiosta käyttäjillä on sama käyttöoikeustaso, kun he ovat vuorovaikutuksessa sekä Kubeflow-käyttöliittymän että Kubectlin kanssa.

Toiminnallinen tehokkuus

Tässä osiossa keskustelemme siitä, kuinka hyödynsimme käytettävissämme olevia avoimen lähdekoodin ja AWS-työkaluja työnkulkujemme hallintaan ja virheenkorjaukseen sekä Kubeflow-päivityksen toiminnallisten vaikutusten minimoimiseen.

Kirjaaminen ja seuranta

Hakkuussa käytämme FluentD:tä kaikkien konttilokkiemme työntämiseen Amazon OpenSearch-palvelu ja järjestelmämittarit Prometheukselle. Käytämme sitten Kibanaa ja Grafana-käyttöliittymää lokien ja mittareiden etsimiseen ja suodattamiseen. Seuraavassa kaaviossa kuvataan, kuinka tämä asetetaan.

Kubeflow Logging. Käytämme sekä Grafana UI:ta että Kibanaa lokien katseluun ja seulomiseen

Seuraava kuvakaappaus on Kibana-käyttöliittymänäkymä putkistamme.

Esimerkki Kibana-käyttöliittymänäkymästä. Kibana mahdollistaa mukautetut näkymät.

Turvalliset Kubeflow-klusteripäivitykset

Kun liitämme käyttäjiä Kubeflow-palveluun AWS:ssä, ylläpidämme luotettavaa ja johdonmukaista käyttökokemusta samalla, kun MLOps-tiimi voi pysyä ketteränä uusien ominaisuuksien julkaisemisessa ja integroinnissa. Pinnalla Kustomize näyttää meille modulaariselta, jotta voimme työskennellä ja päivittää yhtä komponenttia kerrallaan vaikuttamatta muihin, mikä antaa meille mahdollisuuden lisätä uusia ominaisuuksia mahdollisimman vähän häiriötä käyttäjille. Käytännössä on kuitenkin skenaarioita, joissa paras tapa on luoda uusi Kubernetes-klusteri sen sijaan, että käyttäisit komponenttitason päivityksiä olemassa oleviin klustereihin. Löysimme kaksi käyttötapausta, joissa oli järkevämpää luoda täysin uusia klustereita:

• Päivitys Kubernetes-versioon, jossa AWS tarjoaa paikallisia klusteripäivityksiä. On kuitenkin vaikeaa testata, toimivatko Kubeflow- ja Kubernetes-resurssit tarkoitetulla tavalla ja luettelot säilyttävät yhteensopivuuden taaksepäin.
• Kubeflown päivittäminen uudempaan julkaisuun, johon on lisätty tai muokattu useita ominaisuuksia, ja lähes aina ei ole lupaava idea suorittaa paikan päällä olevia päivityksiä olemassa olevaan Kubernetes-klusteriin.

Tämän ongelman ratkaisemiseksi kehitimme strategian, joka mahdollistaa turvallisten klusterien korvaamisen vaikuttamatta olemassa oleviin työkuormiin. Tämän saavuttamiseksi meidän oli täytettävä seuraavat kriteerit:

• Erottele Kubeflow-tallennus- ja laskentaresurssit niin, että liukuhihnan metatiedot, liukuhihnan artefaktit ja käyttäjätiedot säilyvät, kun vanhemman klusterin hallinta poistetaan.
• Integroi AWS-luetteloiden Kubeflown kanssa, jotta Kubeflow-version päivityksen yhteydessä vaaditaan vain vähän muutoksia
• Saat vaivattoman tavan peruuttaa, jos asiat menevät pieleen klusterin päivityksen jälkeen
• Sinulla on yksinkertainen käyttöliittymä ehdokasklusterin edistämiseksi tuotantoon

Seuraava kaavio kuvaa tätä arkkitehtuuria.

Turvallinen Kubeflow-klusterin päivitys. Kun Kubeflow-kandidaatin testaus on onnistunut, se ylennetään Kubeflow Prod -versioon Route 53 -päivityksen kautta.

Kubeflow on AWS-luettelot toimitetaan valmiiksi Amazon RDS- ja Amazon S3 -integraatioilla. Kun nämä hallinnoidut palvelut toimivat yhteisinä tietovarastoina, voimme luoda sinivihreän käyttöönottostrategian. Tämän saavuttamiseksi varmistimme, että putkilinjan metatiedot säilyvät Amazon RDS:ssä, joka toimii EKS-klusterista riippumatta, ja putkilokit ja artefaktit säilyvät Amazon S3:ssa. Liukuhihnan metatietojen ja artefaktien lisäksi määritimme myös FluentD:n reitittämään pod-lokit Amazon OpenSearch Serviceen.

Tämä varmistaa, että tallennuskerros on täysin erotettu laskentakerroksesta ja mahdollistaa näin muutosten testaamisen Kubeflow-versiopäivitysten aikana täysin uudessa EKS-klusterissa. Kun kaikki testit ovat onnistuneet, voimme yksinkertaisesti muuttaa Amazon-reitti 53 DNS-tietue ehdokasklusteriin, joka isännöi Kubeflowa. Lisäksi pidämme vanhaa klusteria käynnissä varmuuskopiona muutaman päivän ajan siltä varalta, että joudumme palauttamaan sen.

Amazon EKS:n ja Kubeflown edut AWS:ssä ML-putkistollemme

Amazon EKS ja Kubeflow on AWS -paketti siirsivät kehitystyönkulkumme malliin, joka kannustaa voimakkaasti toistettavan mallin harjoittelua. Näiden työkalujen avulla voimme luoda täysin määritellyt klusterit täysin määritellyillä vuokralaisilla ja käyttää täysin määriteltyä koodia.

Monet tämän alustan rakentamisesta saadut voitot ovat vähemmän kvantitatiivisia, ja ne liittyvät enemmän siihen, kuinka työnkulut ovat parantuneet sekä alustan kehittäjien että käyttäjien kannalta. Esimerkiksi MinIO korvattiin suoralla pääsyllä Amazon S3:een, mikä vie meidät lähemmäksi alkuperäisiä työnkulkujamme ja vähentää ylläpidettävien palveluiden määrää. Pystymme myös hyödyntämään Amazon RDS:ää Kubeflow:n taustaohjelmana, mikä mahdollistaa helpomman siirtymisen klusterien välillä ja antaa meille mahdollisuuden varmuuskopioida putkistomme iltaisin.

Huomasimme myös parannukset Kubeflow-integraatiossa AWS-hallittujen palvelujen kanssa. Esimerkiksi kun Amazon RDS, Amazon S3 ja Amazon Cognito on esikonfiguroitu Kubeflow on AWS-luetteloissa, säästämme aikaa ja vaivaa päivittäessämme uudempiin Kubeflow-jakeluihin. Kun muokkasimme virallisia Kubeflow-luetteloita manuaalisesti, päivitys uuteen versioon kesti useita viikkoja suunnittelusta testaukseen.

Amazon EKS:ään siirtyminen antaa meille mahdollisuuden määritellä klusterimme Kustomizessa (nykyisin osa Kubectliä) ja Terraformissa. Osoittautuu, että alustatyössä Kubernetesin ja Terraformin kanssa on erittäin helppo työskennellä, kun oppimiseen on käytetty riittävästi aikaa. Monien iteraatioiden jälkeen käytettävissämme olevat työkalut tekevät standardien alustatoimintojen, kuten komponentin päivittämisen tai kokonaisen kehitysklusterin vaihtamisen, suorittamisesta erittäin helppoa. Verrattuna töiden suorittamiseen raakana Amazonin elastinen laskentapilvi (Amazon EC2) -tapauksissa on vaikea verrata, mitä valtavaa eroa on, kun on olemassa hyvin määriteltyjä podeja, joissa on sisäänrakennettu taattu resurssien puhdistus- ja uudelleenyritysmekanismi.

Kubernetes tarjoaa erinomaiset turvallisuusstandardit, ja olemme vain raapuneet pintaan siitä, mitä usean käyttäjän eristäminen antaa meille mahdollisuuden. Näemme monen käyttäjän eristäytymisen mallina, jolla on enemmän hyötyä tulevaisuudessa, kun koulutusalusta tuottaa tuotantotason dataa, ja tuomme mukaan kehittäjiä tiimimme ulkopuolelta.

Samaan aikaan Kubeflow mahdollistaa toistettavan mallikoulutuksen. Edes samoilla tiedoilla mikään koulutus ei tuota identtisiä malleja, mutta meillä on seuraavaksi paras asia. Kubeflown avulla tiedämme tarkalleen, mitä koodia ja dataa käytettiin mallin kouluttamiseen. Käyttöönotto on parantunut huomattavasti, koska jokainen prosessimme vaihe on selkeästi ja ohjelmallisesti määritelty. Kun uusien datatieteilijöiden tehtävänä on korjata virhe, he tarvitsevat paljon vähemmän kädensijaa, koska koodin tulosteiden käyttämiselle vaiheiden välillä on selkeä rakenne.

Kubeflow:n käyttäminen tuottaa myös paljon suorituskyvyn parannuksia verrattuna yksittäiseen EC2-esiintymään. Usein mallikoulutuksessa datatieteilijät tarvitsevat erilaisia ​​työkaluja ja optimointeja esikäsittelyyn ja koulutukseen. Esimerkiksi esikäsittelyä ajetaan usein käyttämällä hajautettuja tietojenkäsittelytyökaluja, kuten Spark, kun taas koulutus suoritetaan usein GPU-instanssien avulla. Kubeflow-putkistojen avulla he voivat määrittää eri ilmentymätyyppejä liukuhihnan eri vaiheille. Tämän ansiosta he voivat käyttää tehokkaita GPU-esiintymiä yhdessä vaiheessa ja pienempiä koneita hajautettuun käsittelyyn toisessa vaiheessa. Lisäksi, koska Kubeflow-liukuhihnat kuvaavat vaiheiden välisiä riippuvuuksia, liukuhihnat voivat ajaa vaiheita rinnakkain.

Lopuksi, koska loimme prosessin vuokralaisten lisäämiseksi klusteriin, on nyt muodollisempi tapa rekisteröidä tiimejä klusterin vuokralaiseksi. Koska käytämme Kubecostia kustannusten seuraamiseen EKS-klusterissamme, sen avulla voimme määrittää kustannukset yhdelle projektille sen sijaan, että kustannukset määritettäisiin tilitasolla, joka sisältää kaikki datatieteen projektit. Kubecost esittää raportin käytetyistä rahoista nimitilaa kohden, joka on tiiviisti kytketty vuokralaiseen tai tiimiin, joka on vastuussa putkilinjan pyörittämisestä.

Kaikista eduista huolimatta varoisimme tällaisen siirron suorittamisesta vain, jos käyttäjät ovat täysin sisäänoston. Käyttäjät, jotka käyttävät aikaa, saavat paljon hyötyä Amazon EKS:n ja Kubernetesin käytöstä, mutta oppimiskäyrä on merkittävä.

Yhteenveto

Ottamalla Kubeflow on AWS-putkilinjan käyttöön päästä päähän ML-infrastruktuurissamme pystyimme konsolidoimaan ja standardoimaan datatieteen työnkulkumme säilyttäen samalla keskeiset työkalumme (kuten CI/CD ja mallin hallinta). Tietotutkijamme voivat nyt siirtyä projekteista toiseen tämän työnkulun perusteella ilman, että sinun on opittava ylläpitämään täysin erilaista työkalusarjaa. Joidenkin malliemme kohdalla olimme myös iloisesti yllättyneitä uuden työnkulun nopeudesta (viisi kertaa nopeampi), mikä mahdollisti enemmän harjoitustoistoja ja siten parempien ennusteiden tuottamisen.

Olemme myös luoneet vankan perustan laajentaaksemme MLOps-kykyämme ja skaalataksemme projektiemme määrää ja kokoa. Kun esimerkiksi kovetamme hallintoasentoamme malliperinnössä ja seurannassa, olemme vähentäneet keskittymistämme yli 15 työnkulusta yhteen. Ja kun Log4shell-haavoittuvuus paljastui loppuvuodesta 2021, pystyimme keskittymään yhteen työnkulkuun ja korjaamaan sen tarvittaessa nopeasti (suorituskyky Amazonin elastisten säiliörekisteri (Amazon ECR) -skannaukset, Amazon OpenSearch -palvelun päivittäminen, työkalujen päivittäminen ja paljon muuta), joilla on minimaalinen vaikutus datatieteilijöiden meneillään olevaan työhön. Kun AWS- ja Kubeflow-parannuksia tulee saataville, voimme sisällyttää ne parhaaksi katsomallamme tavalla.

Tämä vie meidät tärkeän ja aliarvioituun AWS-käyttöönoton Kubeflow-näkökohtaan. Yksi tämän matkan kriittisistä tuloksista on kyky toteuttaa Kubeflow-päivitykset ja parannukset saumattomasti datatieteilijöillemme. Vaikka keskustelimme lähestymistavastamme tähän aiemmin, luotamme myös AWS:n tarjoamiin Kubeflow-luetteloihin. Aloitimme Kubeflow-matkamme konseptin todisteena vuonna 2019, ennen version 1.0.0 julkaisua. (Olemme tällä hetkellä 1.4.1:ssä, arvioimme 1.5:tä. AWS työskentelee jo 1.6-version parissa.) Kolmen kolmen vuoden aikana on ilmestynyt ainakin kuusi merkittävää sisältöä. Kubeflow-tiimi AWS:ssä on ollut kurinalainen lähestymistapa näiden päivitysten integroimiseen ja validointiin sekä manifestien julkaisuun ennakoitavissa olevassa, luotettavassa aikataulussa, ja se on ollut ratkaisevan tärkeä, jotta athenahealth MLOps -tiimi on pystynyt suunnittelemaan kehityssuunnitelmamme ja siten resurssien allokaatiomme ja painopistealueemme. , pidemmälle tulevaisuuteen suuremmalla luottamuksella.

Voit seurata AWS Labs GitHub -arkisto seurataksesi kaikkia Kubeflow:n AWS-panoksia. Löydät myös AWS-tiimit sivustolta Kubeflow #AWS Slack Channel; antamasi palautteesi auttaa AWS:a priorisoimaan seuraavat Kubeflow-projektin ominaisuudet.

---

Tietoja kirjoittajista

Kanwaljit Khurmi on vanhempi ratkaisuarkkitehti Amazon Web Servicesissä. Hän työskentelee AWS-asiakkaiden kanssa tarjotakseen ohjausta ja teknistä apua, joka auttaa heitä parantamaan ratkaisujensa arvoa AWS:n käytössä. Kanwaljit on erikoistunut auttamaan asiakkaita kontti- ja koneoppimissovelluksissa.

Tyler Kalbach on athenahealthin teknisen henkilöstön pääjäsen. Tylerillä on noin 7 vuoden kokemus analytiikka-, tietotieteistä, neuroverkoista ja koneoppimissovellusten kehittämisestä terveydenhuollon alalla. Hän on osallistunut useisiin koneoppimisratkaisuihin, jotka palvelevat tällä hetkellä tuotantoliikennettä. Tällä hetkellä athenahealthin suunnitteluorganisaation päätietotutkijana työskentelevä Tyler on ollut osa tiimiä, joka on rakentanut uuden koneoppimiskoulutusalustan athenahealthille tämän hankkeen alusta lähtien.

Viktor Krylov on athenahealthin teknisen henkilöstön pääjäsen. Victor on insinööri ja scrum-mestari, joka auttaa datatieteilijöitä rakentamaan turvallisia nopeita koneoppimisputkia. Athenahealthissa hän on työskennellyt käyttöliittymien, kliinisen tilauksen, lääkemääräysten, aikataulutuksen, analytiikan ja nyt koneoppimisen parissa. Hän arvostaa selkeästi kirjoitettua ja hyvin yksikkötestattua koodia, mutta hänellä on epäterveellinen pakkomielle koodin yksilinjaisiin. Vapaa-ajallaan hän kuuntelee mielellään podcasteja koiraansa ulkoiluttaessaan.

Sasank Vemuri on athenahealthin teknisen henkilöstön johtava jäsen. Hänellä on kokemusta tietopohjaisten ratkaisujen kehittämisestä muun muassa terveydenhuollon, vakuutusten ja bioinformatiikan aloilla. Sasank suunnittelee ja kehittää tällä hetkellä koneoppimiskoulutus- ja päättelyalustoja AWS:ssä ja Kubernetesissa, jotka auttavat koulutuksessa ja ML-ratkaisujen laajamittaisessa käyttöönotossa.

Anu Tumkur on arkkitehti athenahealthissa. Anulla on yli kahden vuosikymmenen kokemus arkkitehtuurista, suunnittelusta, kehitystyöstä erilaisten ohjelmistotuotteiden rakentamisesta koneoppimisen, pilvitoiminnan, big datan, reaaliaikaisten hajautettujen dataputkien, mainostekniikan, data-analytiikan ja sosiaalisen median analytiikan alalla. Anu työskentelee tällä hetkellä arkkitehtina athenahealthin tuotesuunnitteluorganisaatiossa Machine Learning Platform- ja Data Pipeline -tiimeissä.

William Tsen on vanhempi suunnittelupäällikkö athenahealthissa. Hänellä on yli 20 vuoden insinöörijohtajuuskokemus terveydenhuollon IT-ratkaisujen rakentamisesta, hajautetun suurdatan tietojenkäsittelystä, älykkäistä optisista verkoista, reaaliaikaisista videoeditointijärjestelmistä, yritysohjelmistoista ja ryhmäterveydenhuollon vakuutuksista. William johtaa tällä hetkellä kahta mahtavaa tiimiä athenahealthissa, Machine Learning Operations- ja DevOps-insinööritiimejä Product Engineering -organisaatiossa.