Bygg repeterbare, sikre og utvidbare ende-til-ende maskinlæringsarbeidsflyter med Kubeflow på AWS

Dette er et gjesteblogginnlegg skrevet sammen med athenahealth.

athenahealth en ledende leverandør av nettverksaktivert programvare og tjenester for medisinske grupper og helsesystemer over hele landet. Dens elektroniske helsejournaler, inntektssyklusstyring og verktøy for pasientengasjement gir tilgang når som helst og hvor som helst, noe som gir bedre økonomiske resultater for kundene og gjør det mulig for leverandørkundene å levere behandling av bedre kvalitet.

I området for kunstig intelligens (AI) bruker athenahealth datavitenskap og maskinlæring (ML) for å akselerere forretningsprosesser og gi anbefalinger, spådommer og innsikt på tvers av flere tjenester. Fra den første implementeringen i automatiserte dokumenttjenester, berøringsfri behandling av millioner av leverandør-pasientdokumenter, til det nyere arbeidet med virtuelle assistenter og forbedring av inntektssyklusytelsen, fortsetter athenahealth å bruke AI for å bidra til effektivitet, tjenesteegenskaper og bedre resultater for leverandørene og deres pasienter.

Dette blogginnlegget demonstrerer hvordan athenahealth bruker Kubeflow på AWS (en AWS-spesifikk distribusjon av Kubeflow) for å bygge og strømlinjeforme en ende-til-ende datavitenskapelig arbeidsflyt som bevarer essensielle verktøy, optimerer operasjonell effektivitet, øker dataforskers produktivitet og legger grunnlaget for å utvide ML-evnene deres lettere.

Kubeflow er ML-plattformen med åpen kildekode dedikert til å gjøre distribusjoner av ML-arbeidsflyter på Kubernetes enkle, bærbare og skalerbare. Kubeflow oppnår dette ved å inkorporere relevante åpen kildekode-verktøy som integreres godt med Kubernetes. Noen av disse prosjektene inkluderer Argo for pipeline orkestrering, Istio for service mesh, Jupyter for bærbare datamaskiner, Spark, TensorBoard og Katib. Kubeflow Pipelines hjelper med å bygge og distribuere bærbare, skalerbare ML-arbeidsflyter som kan inkludere trinn som datautvinning, forbehandling, modellopplæring og modellevaluering i form av repeterbare rørledninger.

AWS bidrar til Kubeflow-fellesskapet med åpen kildekode ved å tilby sin egen Kubeflow-distribusjon (kalt Kubeflow på AWS) som hjelper organisasjoner som athenahealth med å bygge svært pålitelige, sikre, bærbare og skalerbare ML-arbeidsflyter med reduserte driftskostnader gjennom integrasjon med AWS-administrerte tjenester. AWS tilbyr ulike Kubeflow-distribusjonsalternativer som distribusjon med Amazon Cognito, utplassering med Amazon Relational Database Service (Amazon RDS) og Amazon enkel lagringstjeneste (Amazon S3), og vaniljeutplassering. For detaljer om tjenesteintegrasjon og tilgjengelige tillegg for hvert av disse alternativene, se Utplassering.

I dag gir Kubeflow på AWS en klar vei til bruk av Kubeflow, utvidet med følgende AWS-tjenester:

Mange AWS-kunder drar nytte av Kubeflow på AWS-distribusjon, inkludert athenahealth.

Her diskuterer athenahealth MLOps-teamet utfordringene de møtte og løsningene de skapte i deres Kubeflow-reise.

Utfordringer med tidligere ML-miljø

Før vi tok i bruk Kubeflow på AWS, brukte dataforskerne våre et standardisert sett med verktøy og en prosess som tillot fleksibilitet i teknologien og arbeidsflyten som ble brukt for å trene en gitt modell. Eksempelkomponenter i det standardiserte verktøyet inkluderer en datainntaks-API, sikkerhetsskanneverktøy, CI/CD-pipeline bygget og vedlikeholdt av et annet team innen athenahealth, og en felles serveringsplattform bygget og vedlikeholdt av MLOps-teamet. Men etter hvert som vår bruk av AI og ML ble modnet, vokste variasjonen av verktøy og infrastruktur som ble opprettet for hver modell. Selv om vi fortsatt var i stand til å støtte den eksisterende prosessen, så vi følgende utfordringer i horisonten:

• Vedlikehold og vekst – Å reprodusere og vedlikeholde modelltreningsmiljøer tok mer innsats ettersom antallet utplasserte modeller økte. Hvert prosjekt opprettholdt detaljert dokumentasjon som skisserte hvordan hvert skript ble brukt til å bygge den endelige modellen. I mange tilfeller var dette en forseggjort prosess som involverte 5 til 10 skript med flere utganger hver. Disse måtte spores manuelt med detaljerte instruksjoner om hvordan hver utgang ville bli brukt i påfølgende prosesser. Å opprettholde dette over tid ble tungvint. Etter hvert som prosjektene ble mer komplekse, økte også antallet verktøy. For eksempel brukte de fleste modellene Spark og TensorFlow med GPUer, som krevde et større utvalg av miljøkonfigurasjoner. Over tid ville brukere bytte til nyere versjoner av verktøy i utviklingsmiljøene sine, men kunne ikke kjøre eldre skript når disse versjonene ble inkompatible. Følgelig krevde vedlikehold og utvidelse av eldre prosjekter mer ingeniørtid og krefter. I tillegg, etter hvert som nye dataforskere ble med i teamet, tok kunnskapsoverføring og onboarding mer tid, fordi synkronisering av lokale miljøer inkluderte mange udokumenterte avhengigheter. Bytte mellom prosjekter møtte de samme problemene fordi hver modell hadde sine egne arbeidsflyter.
• Sikkerhet – Vi tar sikkerhet på alvor, og prioriterer derfor overholdelse av alle kontraktsmessige, juridiske og regulatoriske forpliktelser knyttet til ML og datavitenskap. Data må brukes, lagres og få tilgang til på spesifikke måter, og vi har innebygd robuste prosesser for å sikre at praksisen vår er i samsvar med våre juridiske forpliktelser, samt samsvarer med bransjens beste praksis. Før Kubeflow ble tatt i bruk, innebar det å sikre at data ble lagret og få tilgang til på en bestemt måte regelmessig verifisering på tvers av flere, forskjellige arbeidsflyter. Vi visste at vi kunne forbedre effektiviteten ved å konsolidere disse mangfoldige arbeidsflytene på én enkelt plattform. Denne plattformen må imidlertid være fleksibel nok til å integreres godt med vårt standardiserte verktøy.
• Drift – Vi så også en mulighet til å øke operasjonell effektivitet og styring gjennom sentralisering av logging og overvåking av arbeidsflytene. Fordi hvert team hadde utviklet sine egne verktøy, samlet vi denne informasjonen fra hver arbeidsflyt individuelt og samlet dem.

Datavitenskapsteamet evaluerte ulike løsninger for å konsolidere arbeidsflytene. I tillegg til å møte disse kravene, så vi etter en løsning som kunne integreres sømløst med den eksisterende standardiserte infrastrukturen og verktøyene. Vi valgte Amazon EKS og Kubeflow på AWS som vår arbeidsflytløsning.

Dataforskerens utviklingssyklus som inkluderer Kubeflow

Et datavitenskapelig prosjekt begynner med et rent ark: ingen data, ingen kode, bare forretningsproblemet som kan løses med ML. Den første oppgaven er et proof of concept (POC) for å finne ut om dataene inneholder nok signal til å gjøre en ML-modell effektiv til å løse forretningsproblemet, og starter med å spørre etter det rå datasettet fra vårt Snowflake-datavarehus. Dette stadiet er iterativt, og dataforskerne bruker Kubernetes-pods eller Kubeflow Jupyter-notatbøker under denne prosessen.

Vår Kubeflow-klynge bruker Karpenter cluster autoscaler, som gjør det enkelt å spinne opp ressurser for dataforskere fordi de bare trenger å fokusere på å definere de ønskede forekomsttypene, mens klargjøringsarbeidet gjøres av et sett med forhåndsdefinerte Karpenter-provisjonere. Vi har separate provisjonere for CPU- og GPU-forekomsttyper, og alle forekomstene som støttes av Amazon EKS faller i en av disse to kategoriene i henhold til vår provisjonskonfigurasjon. Dataforskerne velger instanstyper ved hjelp av nodevelgere, og Karpenter tar seg av nodelivssyklusadministrasjonen.

Etter at spørringen er utviklet, trekker dataforskerne ut rådataene til et sted på Amazon S3, og starter deretter en Jupyter-notisbok fra AWS Kubeflow-grensesnittet for å utforske dataene. Målet er å lage funksjonssettet som skal brukes til å trene opp den første modellen. Dette lar dataforskerne finne ut om det er nok signal i dataene til å oppfylle kundens forretningsbehov.

Etter at resultatene er tilfredsstillende, går dataforskerne til neste trinn i utviklingssyklusen og gjør funnene deres til en robust rørledning. De konverterer POC-koden til produksjonskvalitetskode som kjører i skala. For å sikre samsvar ved å bruke godkjente biblioteker, opprettes det en beholder med riktig base Docker-bilde. For dataforskerne våre har vi funnet ut at å tilby et standard Python-, TensorFlow- og Spark-basebilde gir tilstrekkelig fleksibilitet for de fleste, om ikke alle, arbeidsbelastninger. De kan deretter bruke Dockerfilen til komponenten deres for å tilpasse utviklingsmiljøet ytterligere. Denne Dockerfilen blir deretter brukt av CI/CD-prosessen for å bygge komponentbildet som skal brukes i produksjonen, og opprettholder derfor konsistens mellom utviklings- og produksjonsmiljøer.

Vi har et verktøy som gir dataforskere muligheten til å lansere utviklingsmiljøet sitt i en pod som kjører på Kubernetes. Når denne poden kjører, kan dataforskerne koble Visual Studio Code IDE direkte til poden og feilsøke modellkoden deres. Etter at de har kjørt koden vellykket, kan de overføre endringene til git og et nytt utviklingsmiljø opprettes med de siste endringene.

Standard datavitenskapspipeline består av stadier som inkluderer utvinning, forbehandling, opplæring og evaluering. Hvert trinn i pipelinen vises som en komponent i Kubeflow, som består av en Kubernetes-pod som kjører en kommando med noe informasjon sendt inn som parametere. Disse parameterne kan enten være statiske verdier eller referanser til utdata fra en tidligere komponent. Docker-bildet som brukes i poden er bygget fra CI/CD-prosessen. Detaljer om denne prosessen vises i CI/CD-arbeidsflyten som diskuteres i neste avsnitt.

Utviklingssyklus på Kubeflow. Utviklingsarbeidsflyten starter til venstre med POC. Den ferdige modellen er distribuert til athenahealth-modellserveringsplattformen som kjører på Amazon ECS.

CI/CD-prosess som støtter automatiserte arbeidsflyter

Som en del av CI/CD-prosessen vår bruker vi Jenkins til å bygge og teste alle Kubeflow-komponentbilder parallelt. Ved vellykket gjennomføring inneholder malen for rørledningskomponenten referansepekere til bildene, og den resulterende rørledningen lastes opp til Kubeflow. Parametere i Jenkins-rørledningen lar brukere lansere rørledningene og kjøre modelltreningstestene sine etter vellykkede bygg.

Alternativt, for å opprettholde en kort utviklingssyklus, kan dataforskere også starte rørledningen fra sin lokale maskin, og endre eventuelle rørledningsparametere de eksperimenterer med.

Det finnes verktøy for å sikre at referansepekerne fra CI/CD-bygget brukes som standard. Hvis det er en distribuerbar artefakt i repoen, vil CI/CD-logikken fortsette å distribuere artefakten til athenahealth-modellserveringsplattformen (Prediction Service) som kjører på Amazon ECS med AWS Fargate. Etter at alle disse stadiene har gått, slår dataforskeren sammen koden til primærgrenen. Rørledningene og utplasserbare gjenstander blir deretter skjøvet til produksjon.

Arbeidsflyt for distribusjon av CI/CD. Dette diagrammet beskriver arbeidsflyten for bygging og distribusjon av Data Science. CI/CD-prosessen er drevet av Jenkins.

Sikkerhet

Ved å konsolidere våre datavitenskapelige arbeidsflyter var vi i stand til å sentralisere vår tilnærming til å sikre opplæringspipeline. I denne delen diskuterer vi vår tilnærming til data- og klyngesikkerhet.

Datasikkerhet

Datasikkerhet er av største betydning for athenahealth. Av denne grunn utvikler og vedlikeholder vi infrastruktur som er fullstendig i samsvar med regelverket og standardene som beskytter sikkerheten og integriteten til disse dataene.

For å sikre at vi oppfyller dataoverholdelsesstandarder, sørger vi for AWS-infrastrukturen vår i samsvar med retningslinjene våre for athenahealth-bedrifter. De to hovedlagerene for data er Amazon RDS for svært skalerbare pipeline-metadata og Amazon S3 for pipeline- og modellartefakter. For Amazon S3 sikrer vi at bøttene er kryptert, HTTPS-endepunkter håndheves, og at bøttepolicyene og AWS identitets- og tilgangsadministrasjon (IAM)-roller følger prinsippene om minste privilegium når de tillater tilgang til dataene. Dette gjelder også for Amazon RDS-data: kryptering er alltid aktivert, og sikkerhetsgruppene og legitimasjonstilgangen følger prinsippet om minste privilegium. Denne standardiseringen sikrer at kun autoriserte parter har tilgang til dataene, og denne tilgangen spores.

I tillegg til disse tiltakene gjennomgår plattformen også sikkerhetstrusselsvurderinger og kontinuerlige sikkerhets- og samsvarsskanninger.

Vi tar også opp krav til datalagring via datalivssyklusadministrasjon for alle S3-bøtter som inneholder sensitive data. Denne policyen flytter automatisk data til Amazon S3-breen etter 30 dagers opprettelse. Unntak fra dette håndteres gjennom forespørsler om datainnhenting og godkjennes eller avvises fra sak til sak. Dette sikrer at alle arbeidsflyter overholder retningslinjene for dataoppbevaring. Dette løser også problemet med å gjenopprette data hvis en modell gir dårlig ytelse, og omskolering er nødvendig, eller når en ny modell må evalueres mot en historisk iterasjon av en eldre modells datasett.

For å begrense tilgangen til Amazon S3 og Amazon RDS fra Kubeflow på AWS og Amazon EKS, bruker vi IRSA (IAM Roles for Service Accounts), som gir IAM-basert tillatelsestillatelse for ressurser i Kubernetes. Hver leietaker i Kubeflow har en unik forhåndsopprettet tjenestekonto som vi binder til en IAM-rolle opprettet spesifikt for å oppfylle kravene til leietakertilgang. Brukertilgang til leietakere er også begrenset ved å bruke Amazon Cognito-brukerpools gruppemedlemskap for hver bruker. Når en bruker er autentisert til klyngen, inneholder det genererte tokenet gruppekrav, og Kubernetes RBAC bruker denne informasjonen til å tillate eller nekte tilgang til en bestemt ressurs i klyngen. Dette oppsettet er forklart mer detaljert i neste avsnitt.

Klyngesikkerhet ved bruk av flerbrukerisolasjon

Som vi bemerket i forrige seksjon, utfører dataforskere utforskende dataanalyser, kjører dataanalyse og trener ML-modeller. For å allokere ressurser, organisere data og administrere arbeidsflyter basert på prosjekter, gir Kubeflow på AWS isolasjon basert på Kubernetes navnerom. Denne isolasjonen fungerer for samhandling med Kubeflow-grensesnittet; den gir imidlertid ikke noe verktøy for å kontrollere tilgangen til Kubernetes API ved å bruke Kubectl. Dette betyr at brukertilgang kan kontrolleres på Kubeflow-grensesnittet, men ikke over Kubernetes API via Kubectl.

Arkitekturen beskrevet i følgende diagram løser dette problemet ved å forene tilgang til prosjekter i Kubeflow basert på gruppemedlemskap. For å oppnå dette benyttet vi oss av Kubeflow på AWS-manifestene, som har integrasjon med Amazon Cognito-brukerpooler. I tillegg bruker vi Kubernetes rollebasert tilgangskontroll (RBAC) for å kontrollere autorisasjon innenfor klyngen. Brukertillatelsene leveres basert på Amazon Cognito-gruppemedlemskap. Denne informasjonen sendes til klyngen med tokenet generert av OIDC-klienten. Denne prosessen er forenklet takket være den innebygde Amazon EKS-funksjonaliteten som lar assosiere OIDC-identitetsleverandører autentisere seg med klyngen.

Som standard utføres Amazon EKS-autentisering av IAM-autentisering, som er et verktøy som muliggjør autentisering med en EKS-klynge ved hjelp av IAM-legitimasjon. Denne autentiseringsmetoden har sine fordeler; den er imidlertid ikke egnet for vår brukstilfelle fordi athenahealth bruker Microsoft Azure Active Directory for identitetstjeneste på tvers av organisasjonen.

Kubernetes navneområdeisolasjon. Dataforskere kan få medlemskap i en enkelt eller flere grupper etter behov for deres arbeid. Tilgang vurderes regelmessig og fjernes etter behov.

Azure Active Directory, som er en bedriftsomfattende identitetstjeneste, er kilden til sannhet for å kontrollere brukertilgang til Kubeflow-klyngen. Oppsettet for dette inkluderer å opprette en Azure Enterprise Application som fungerer som tjenesteoppdragsgiver og legge til grupper for ulike leietakere som krever tilgang til klyngen. Dette oppsettet på Azure speiles i Amazon Cognito ved å sette opp en forent OIDC-identitetsleverandør som outsourcer autentiseringsansvaret til Azure. Tilgangen til Azure-grupper kontrolleres av SailPoint IdentityIQ, som sender tilgangsforespørsler til prosjekteieren for å tillate eller avslå etter behov. I Amazon Cognito-brukerpoolen opprettes to applikasjonsklienter: en brukes til å sette opp autentiseringen for Kubernetes-klyngen ved å bruke OIDC-identitetsleverandøren, og den andre for å sikre Kubeflow-autentisering i Kubeflow-grensesnittet. Disse klientene er konfigurert til å sende gruppekrav ved autentisering med klyngen, og disse gruppekravene brukes sammen med RBAC for å sette opp autorisasjon i klyngen.

Kubernetes RBAC-rollebindinger settes opp mellom grupper og klyngerollen Kubeflow-edit, som opprettes ved installasjon av Kubeflow i klyngen. Denne rollebindingen sikrer at enhver bruker som samhandler med klyngen etter å ha logget på via OIDC kan få tilgang til navneområdene de har tillatelser for som definert i gruppekravene deres. Selv om dette fungerer for brukere som samhandler med klyngen ved hjelp av Kubectl, gir Kubeflow-grensesnittet for øyeblikket ikke tilgang til brukere basert på gruppemedlemskap fordi det ikke bruker RBAC. I stedet bruker den Istio Authorization Policy-ressursen for å kontrollere tilgang for brukere. For å overkomme denne utfordringen utviklet vi en tilpasset kontroller som synkroniserer brukere ved å polle Amazon Cognito-grupper og legger til eller fjerner tilsvarende rollebindinger for hver bruker i stedet for etter gruppe. Dette oppsettet gjør det mulig for brukere å ha samme nivå av tillatelser når de samhandler med både Kubeflow UI og Kubectl.

Operasjonell effektivitet

I denne delen diskuterer vi hvordan vi utnyttet åpen kildekode og AWS-verktøyene som er tilgjengelige for oss for å administrere og feilsøke arbeidsflytene våre, samt for å minimere den operasjonelle effekten av å oppgradere Kubeflow.

Logging og overvåking

For logging bruker vi FluentD for å skyve alle våre containerlogger til Amazon OpenSearch-tjeneste og systemmålinger til Prometheus. Vi bruker deretter Kibana og Grafana-grensesnittet for å søke og filtrere logger og beregninger. Følgende diagram beskriver hvordan vi setter opp dette.

Kubeflow-logging. Vi bruker både Grafana UI og Kibana for å se og sile gjennom loggene

Følgende skjermbilde er en Kibana UI-visning fra vår pipeline.

Eksempel på Kibana UI View. Kibana gir mulighet for tilpassede visninger.

Safe Kubeflow-klyngeoppgraderinger

Når vi bruker brukere til Kubeflow på AWS, opprettholder vi en pålitelig og konsistent brukeropplevelse samtidig som vi lar MLOps-teamet holde seg smidig med å frigjøre og integrere nye funksjoner. På overflaten virker Kustomize modulær for oss for å muliggjøre arbeid og oppgradering av én komponent om gangen uten å påvirke andre, og dermed tillate oss å legge til nye funksjoner med minimal forstyrrelse for brukerne. Imidlertid er det i praksis scenarier der den beste tilnærmingen er å ganske enkelt spinne opp en ny Kubernetes-klynge i stedet for å bruke oppgraderinger på komponentnivå for eksisterende klynger. Vi fant to brukstilfeller der det var mer fornuftig å lage helt nye klynger:

• Oppgradering til en Kubernetes-versjon der AWS tilbyr klyngeoppgraderinger på stedet. Det blir imidlertid vanskelig å teste om hver av Kubeflow- og Kubernetes-ressursene fungerer etter hensikten, og manifestene beholder bakoverkompatibilitet.
• Oppgradering av Kubeflow til en nyere utgivelse der det er flere funksjoner lagt til eller endret, og det nesten alltid ikke er en lovende idé å utføre på plass oppgraderinger på en eksisterende Kubernetes-klynge.

For å løse dette problemet utviklet vi en strategi som gjør det mulig for oss å ha sikre klyngeerstatninger uten å påvirke eksisterende arbeidsbelastninger. For å oppnå dette måtte vi oppfylle følgende kriterier:

• Separer Kubeflow-lagrings- og dataressursene slik at pipeline-metadata, pipeline-artefakter og brukerdata beholdes når den eldre klyngen deaktiveres
• Integrer med Kubeflow på AWS-manifester slik at når en Kubeflow-versjonsoppgradering skjer, kreves det minimale endringer
• Ha en enkel måte å rulle tilbake hvis ting går galt etter klyngeoppgradering
• Ha et enkelt grensesnitt for å fremme en kandidatklynge til produksjon

Følgende diagram illustrerer denne arkitekturen.

Sikker Kubeflow-klyngeoppgradering. Når testingen av Kubeflow-kandidaten er vellykket, forfremmes den til Kubeflow Prod gjennom en oppdatering til Route 53.

Kubeflow på AWS-manifester kommer ferdigpakket med Amazon RDS- og Amazon S3-integrasjoner. Med disse administrerte tjenestene som fungerer som vanlige datalagre, kan vi sette opp en blågrønn distribusjonsstrategi. For å oppnå dette har vi sørget for at rørledningsmetadataene er bevart i Amazon RDS, som fungerer uavhengig av EKS-klyngen, og at rørledningsloggene og artefaktene er bevart i Amazon S3. I tillegg til pipeline-metadata og artefakter, har vi også satt opp FluentD for å rute pod-logger til Amazon OpenSearch Service.

Dette sikrer at lagringslaget er fullstendig atskilt fra datalaget og muliggjør dermed testing av endringer under Kubeflow-versjonsoppdateringer på en helt ny EKS-klynge. Etter at alle testene er vellykkede, kan vi ganske enkelt endre Amazon Route 53 DNS-post til kandidatklyngen som er vert for Kubeflow. Dessuten holder vi den gamle klyngen kjørende som backup i noen dager i tilfelle vi må rulle tilbake.

Fordeler med Amazon EKS og Kubeflow på AWS for vår ML-pipeline

Amazon EKS og Kubeflow on AWS-pakken flyttet utviklingsarbeidsflyten vår til et mønster som sterkt oppfordrer til repeterbar modelltrening. Disse verktøyene lar oss ha fullt definerte klynger med fullt definerte leietakere og kjøre fullt definert kode.

Mange gevinster fra å bygge denne plattformen er mindre kvantitative og har mer å gjøre med hvordan arbeidsflytene har blitt bedre for både plattformutviklere og brukere. For eksempel ble MinIO erstattet med direkte tilgang til Amazon S3, noe som flytter oss nærmere våre opprinnelige arbeidsflyter og reduserer antall tjenester vi må vedlikeholde. Vi er også i stand til å bruke Amazon RDS som backend for Kubeflow, som muliggjør enklere migreringer mellom klynger og gir oss muligheten til å sikkerhetskopiere rørledningene våre hver natt.

Vi fant også forbedringene i Kubeflow-integrasjonen med AWS-administrerte tjenester fordelaktige. For eksempel, med Amazon RDS, Amazon S3 og Amazon Cognito forhåndskonfigurert i Kubeflow på AWS-manifestene, sparer vi tid og krefter på å oppdatere til nyere distribusjoner av Kubeflow. Da vi pleide å endre de offisielle Kubeflow-manifestene manuelt, ville oppdatering til en ny versjon ta flere uker, fra design til testing.

Å bytte til Amazon EKS gir oss muligheten til å definere klyngen vår i Kustomize (nå en del av Kubectl) og Terraform. Det viser seg at for plattformarbeid er Kubernetes og Terraform veldig enkle å jobbe med etter å ha lagt ned nok tid til å lære. Etter mange gjentakelser gjør verktøyene som er tilgjengelige for oss det veldig enkelt å utføre standard plattformoperasjoner som å oppgradere en komponent eller bytte ut en hel utviklingsklynge. Sammenlignet med å kjøre jobber uten rå Amazon Elastic Compute Cloud (Amazon EC2), er det vanskelig å sammenligne hvilken enorm forskjell det gjør å ha veldefinerte pods med garantert ressursopprydding og gjenforsøksmekanismer innebygd.

Kubernetes tilbyr gode sikkerhetsstandarder, og vi har bare skrapet i overflaten av det flerbrukerisolasjonen lar oss gjøre. Vi ser på isolasjon av flere brukere som et mønster som gir mer uttelling i fremtiden når opplæringsplattformen produserer data på produksjonsnivå, og vi henter utviklere utenfor teamet vårt.

I mellomtiden lar Kubeflow oss ha reproduserbar modelltrening. Selv med de samme dataene gir ingen trening identiske modeller, men vi har det nest beste. Med Kubeflow vet vi nøyaktig hvilken kode og data som ble brukt for å trene en modell. Onboarding har blitt betraktelig forbedret fordi hvert trinn i pipeline vår er klart og programmatisk definert. Når nye dataforskere har i oppgave å fikse en feil, trenger de mye mindre håndtak fordi det er en klar struktur for hvordan utdata av kode brukes mellom trinnene.

Bruk av Kubeflow gir også mange ytelsesforbedringer sammenlignet med å kjøre på en enkelt EC2-instans. Ofte i modelltrening trenger dataforskere forskjellige verktøy og optimaliseringer for forbehandling og opplæring. For eksempel kjøres forbehandling ofte ved hjelp av distribuerte databehandlingsverktøy, som Spark, mens trening ofte kjøres med GPU-forekomster. Med Kubeflow-rørledninger kan de spesifisere forskjellige instanstyper for forskjellige stadier i rørledningen. Dette lar dem bruke de kraftige GPU-forekomstene i ett trinn og en flåte av mindre maskiner for distribuert prosessering i et annet trinn. Dessuten, fordi Kubeflow-rørledninger beskriver avhengighetene mellom trinn, kan rørledningene kjøre trinn parallelt.

Til slutt, fordi vi opprettet en prosess for å legge til leietakere i klyngen, er det nå en mer formell måte å registrere lag til en leietaker i klyngen. Fordi vi bruker Kubecost til å spore kostnader i EKS-klyngen vår, lar det oss tilskrive kostnader til et enkelt prosjekt i stedet for å få kostnadene tilskrevet på kontonivå, som inkluderer alle datavitenskapelige prosjekter. Kubecost presenterer en rapport over pengene brukt per navneområde, som er tett koblet til leietakeren eller teamet som er ansvarlig for å drive rørledningen.

Til tross for alle fordelene, vil vi advare mot å bare foreta denne typen migrering hvis det er total buy-in fra brukere. Brukere som legger ned tid får mange fordeler av å bruke Amazon EKS og Kubernetes, men det er en betydelig læringskurve.

konklusjonen

Med implementeringen av Kubeflow på AWS-pipeline i vår ende-til-ende ML-infrastruktur, var vi i stand til å konsolidere og standardisere datavitenskapelige arbeidsflyter samtidig som vi beholdt vårt essensielle verktøy (som CI/CD og modellservering). Dataforskerne våre kan nå flytte mellom prosjekter basert på denne arbeidsflyten uten å måtte lære å vedlikeholde et helt annet verktøysett. For noen av modellene våre ble vi også positivt overrasket over hastigheten på den nye arbeidsflyten (fem ganger raskere), som muliggjorde flere treningsgjentakelser og følgelig produsere modeller med bedre spådommer.

Vi har også etablert et solid grunnlag for å utvide MLOps-evnene våre og skalere antall og størrelse på prosjektene våre. For eksempel, ettersom vi skjerper vår styringsposisjon i modellavstamning og sporing, har vi redusert fokus fra over 15 arbeidsflyter til bare én. Og da Log4shell-sårbarheten kom frem på slutten av 2021, var vi i stand til å fokusere på én enkelt arbeidsflyt og raskt utbedre etter behov (utføre Amazon Elastic Container Registry (Amazon ECR) skanninger, oppgradering av Amazon OpenSearch Service, oppdatering av verktøyene våre og mer) med minimal innvirkning på det pågående arbeidet til dataforskerne. Etter hvert som AWS- og Kubeflow-forbedringer blir tilgjengelige, kan vi inkorporere dem etter eget ønske.

Dette bringer oss til et viktig og undervurdert aspekt av vår Kubeflow på AWS-adopsjon. Et av de kritiske resultatene av denne reisen er muligheten til å rulle ut oppgraderinger og forbedringer til Kubeflow sømløst for våre dataforskere. Selv om vi diskuterte vår tilnærming til dette tidligere, stoler vi også på Kubeflow-manifestene levert av AWS. Vi startet vår Kubeflow-reise som et proof of concept i 2019, før utgivelsen av versjon 1.0.0. (Vi er for tiden på 1.4.1 og evaluerer 1.5. AWS jobber allerede med 1.6-versjonen.) I løpet av de mellomliggende 3 årene har det vært minst seks utgivelser med betydelig innhold. Gjennom sin disiplinerte tilnærming til å integrere og validere disse oppgraderingene og frigjøre manifestene på en forutsigbar, pålitelig tidsplan, har Kubeflow-teamet hos AWS vært avgjørende for å gjøre athenahealth MLOps-teamet i stand til å planlegge utviklingsveikartet vårt, og følgelig ressursallokeringene og fokusområdene våre. , lenger inn i fremtiden med større selvtillit.

Du kan følge AWS Labs GitHub-depot for å spore alle AWS-bidrag til Kubeflow. Du kan også finne AWS-team på Kubeflow #AWS Slack Channel; tilbakemeldingen din der hjelper AWS med å prioritere de neste funksjonene for å bidra til Kubeflow-prosjektet.

---

Om forfatterne

Kanwaljit Khurmi er senior løsningsarkitekt hos Amazon Web Services. Han samarbeider med AWS-kundene for å gi veiledning og teknisk assistanse som hjelper dem med å forbedre verdien av løsningene deres når de bruker AWS. Kanwaljit spesialiserer seg på å hjelpe kunder med containeriserte og maskinlæringsapplikasjoner.

Tyler Kalbach er hovedmedlem i teknisk stab ved athenahealth. Tyler har omtrent 7 års erfaring innen analyse, datavitenskap, nevrale nettverk og utvikling av maskinlæringsapplikasjoner i helsesektoren. Han har bidratt til flere Machine Learning-løsninger som for tiden betjener produksjonstrafikk. Tyler jobber for tiden som hoveddataforsker i athenahealths ingeniørorganisasjon, og har vært en del av teamet som har bygget den nye maskinlæringsplattformen for athenahealth fra starten av denne innsatsen.

Victor Krylov er hovedmedlem i teknisk stab ved athenahealth. Victor er ingeniør og scrum-mester, og hjelper dataforskere med å bygge sikre raske maskinlæringspipelines. I athenahealth har han jobbet med grensesnitt, klinisk bestilling, resepter, planlegging, analyser og nå maskinlæring. Han verdsetter ren skrevet og godt enhetstestet kode, men har en usunn besettelse av kode-one-liners. På fritiden liker han å høre på podcaster mens han går tur med hunden.

Sasank Vemuri er ledende medlem av teknisk stab hos athenahealth. Han har erfaring med å utvikle datadrevne løsninger på tvers av domener som helsevesen, forsikring og bioinformatikk. Sasank jobber for tiden med å designe og utvikle maskinlærings- og inferensplattformer på AWS og Kubernetes som hjelper til med opplæring og distribusjon av ML-løsninger i stor skala.

Anu Tumkur er arkitekt ved athenahealth. Anu har over to tiår med arkitektur, design, utviklingserfaring med å bygge ulike programvareprodukter innen maskinlæring, skyoperasjoner, big data, sanntidsdistribuerte datapipelines, annonseteknologi, dataanalyse, sosiale medier-analyse. Anu jobber for tiden som arkitekt i athenahealths produktingeniørorganisasjon på Machine Learning Platform og Data Pipeline-teamene.

William Tsen er Senior Engineering Manager hos athenahealth. Han har over 20 års erfaring med ingeniørlederskap med å bygge løsninger innen helse-IT, distribuert databehandling med store data, intelligente optiske nettverk, sanntids videoredigeringssystemer, bedriftsprogramvare og gruppehelsetjenester. William leder for tiden to fantastiske team hos athenahealth, Machine Learning Operations og DevOps ingeniørteam, i Product Engineering-organisasjonen.