Byg gentagelige, sikre og udvidelige end-to-end maskinlærings-workflows ved hjælp af Kubeflow på AWS

Dette er et gæsteblogindlæg, der er skrevet sammen med athenahealth.

athenesundhed en førende udbyder af netværksaktiveret software og tjenester til medicinske grupper og sundhedssystemer landsdækkende. Dens elektroniske sygejournaler, indtægtscyklusstyring og patientinddragelsesværktøjer giver adgang når som helst og hvor som helst, hvilket giver bedre økonomiske resultater for sine kunder og gør det muligt for sine udbyderkunder at levere pleje af bedre kvalitet.

I området med kunstig intelligens (AI) bruger athenahealth datavidenskab og maskinlæring (ML) til at accelerere forretningsprocesser og give anbefalinger, forudsigelser og indsigt på tværs af flere tjenester. Fra den første implementering i automatiserede dokumenttjenester, berøringsfri behandling af millioner af udbyder-patientdokumenter, til dets nyere arbejde med virtuelle assistenter og forbedring af indtjeningscyklusydelsen, fortsætter athenahealth med at anvende AI for at hjælpe med at fremme effektivitet, servicemuligheder og bedre resultater for udbydere og deres patienter.

Dette blogindlæg demonstrerer, hvordan athenahealth bruger Kubeflow på AWS (en AWS-specifik distribution af Kubeflow) for at opbygge og strømline en end-to-end data science workflow, der bevarer væsentlige værktøjer, optimerer operationel effektivitet, øger data scientists produktivitet og sætter scenen for at udvide deres ML-kapacitet lettere.

Kubeflow er open source ML-platformen dedikeret til at gøre implementeringer af ML-arbejdsgange på Kubernetes enkle, bærbare og skalerbare. Kubeflow opnår dette ved at inkorporere relevante open source-værktøjer, der integreres godt med Kubernetes. Nogle af disse projekter inkluderer Argo til pipeline orkestrering, Istio til service mesh, Jupyter til notebooks, Spark, TensorBoard og Katib. Kubeflow Pipelines hjælper med at opbygge og implementere bærbare, skalerbare ML-arbejdsgange, der kan omfatte trin som dataudtræk, forbehandling, modeltræning og modelevaluering i form af repeterbare pipelines.

AWS bidrager til open source Kubeflow-fællesskabet ved at levere sin egen Kubeflow-distribution (kaldet Kubeflow på AWS), der hjælper organisationer som athenahealth med at opbygge yderst pålidelige, sikre, bærbare og skalerbare ML-workflows med reduceret driftsomkostninger gennem integration med AWS-administrerede tjenester. AWS giver forskellige Kubeflow-implementeringsmuligheder som implementering med Amazon Cognito, indsættelse med Amazon Relationel Database Service (Amazon RDS) og Amazon Simple Storage Service (Amazon S3) og vaniljeimplementering. For detaljer om serviceintegration og tilgængelige tilføjelser for hver af disse muligheder, se Deployment.

I dag giver Kubeflow på AWS en klar vej til at bruge Kubeflow, udvidet med følgende AWS-tjenester:

Mange AWS-kunder drager fordel af Kubeflow på AWS-distribution, inklusive athenahealth.

Her diskuterer athenahealth MLOps-teamet de udfordringer, de stødte på, og de løsninger, de skabte i deres Kubeflow-rejse.

Udfordringer med det tidligere ML-miljø

Inden vores adoption af Kubeflow på AWS brugte vores dataforskere et standardiseret sæt værktøjer og en proces, der tillod fleksibilitet i teknologien og arbejdsgangen, der blev brugt til at træne en given model. Eksempler på komponenter i det standardiserede værktøj omfatter en dataindtagelses-API, sikkerhedsscanningsværktøjer, CI/CD-pipeline bygget og vedligeholdt af et andet team inden for athenahealth og en fælles serveringsplatform bygget og vedligeholdt af MLOps-teamet. Men efterhånden som vores brug af AI og ML modnes, voksede mangfoldigheden af ​​værktøjer og infrastruktur, der blev skabt for hver model. Selvom vi stadig var i stand til at understøtte den eksisterende proces, så vi følgende udfordringer i horisonten:

• Vedligeholdelse og vækst – Reproduktion og vedligeholdelse af modeltræningsmiljøer krævede mere indsats, efterhånden som antallet af installerede modeller steg. Hvert projekt vedligeholdt detaljeret dokumentation, der skitserede, hvordan hvert script blev brugt til at bygge den endelige model. I mange tilfælde var dette en kompliceret proces, der involverede 5 til 10 scripts med flere output hver. Disse skulle spores manuelt med detaljerede instruktioner om, hvordan hvert output ville blive brugt i efterfølgende processer. At vedligeholde dette med tiden blev besværligt. Efterhånden som projekterne blev mere komplekse, steg antallet af værktøjer også. For eksempel brugte de fleste modeller Spark og TensorFlow med GPU'er, hvilket krævede et større udvalg af miljøkonfigurationer. Med tiden ville brugerne skifte til nyere versioner af værktøjer i deres udviklingsmiljøer, men kunne derefter ikke køre ældre scripts, når disse versioner blev inkompatible. Som følge heraf krævede vedligeholdelse og udbygning af ældre projekter mere ingeniørtid og kræfter. Efterhånden som nye dataforskere kom til holdet, tog videnoverførsel og onboarding desuden mere tid, fordi synkronisering af lokale miljøer indeholdt mange udokumenterede afhængigheder. Skift mellem projekter stod over for de samme problemer, fordi hver model havde sine egne arbejdsgange.
• Sikkerhed – Vi tager sikkerhed seriøst og prioriterer derfor overholdelse af alle kontraktlige, juridiske og regulatoriske forpligtelser forbundet med ML og data science. Data skal bruges, opbevares og tilgås på bestemte måder, og vi har indlejret robuste processer for at sikre, at vores praksis overholder vores juridiske forpligtelser samt er i overensstemmelse med industriens bedste praksis. Før Kubeflow blev vedtaget, indebar sikring af, at data blev lagret og tilgået på en bestemt måde, regelmæssig verifikation på tværs af flere forskellige arbejdsgange. Vi vidste, at vi kunne forbedre effektiviteten ved at konsolidere disse forskellige arbejdsgange på en enkelt platform. Denne platform skal dog være fleksibel nok til at kunne integreres godt med vores standardiserede værktøj.
• Produktion – Vi så også en mulighed for at øge den operationelle effektivitet og styring gennem centralisering af logningen og overvågningen af ​​arbejdsgangene. Fordi hvert team havde udviklet deres egne værktøjer, indsamlede vi disse oplysninger fra hver arbejdsgang individuelt og aggregerede dem.

Data science-teamet evaluerede forskellige løsninger til konsolidering af arbejdsgangene. Ud over at imødekomme disse krav ledte vi efter en løsning, der kunne integreres problemfrit med den eksisterende standardiserede infrastruktur og værktøjer. Vi valgte Amazon EKS og Kubeflow på AWS som vores workflow-løsning.

Data scientists udviklingscyklus, der inkorporerer Kubeflow

Et datavidenskabsprojekt begynder med en ren tavle: ingen data, ingen kode, kun forretningsproblemet, der kan løses med ML. Den første opgave er et proof of concept (POC) for at finde ud af, om dataene rummer nok signal til at gøre en ML-model effektiv til at løse forretningsproblemet, begyndende med at forespørge efter det rå datasæt fra vores Snowflake-datavarehus. Denne fase er iterativ, og dataforskerne bruger Kubernetes-pods eller Kubeflow Jupyter-notebooks under denne proces.

Vores Kubeflow-klynge bruger Karpenter-klynge-autoscaler, som gør det nemt for datavidenskabsfolk at samle ressourcer op, fordi de kun skal fokusere på at definere de ønskede instanstyper, mens klargøringsarbejdet udføres af et sæt foruddefinerede Karpenter-providerere. Vi har separate provisioner for CPU- og GPU-forekomsttyper, og alle de forekomster, der understøttes af Amazon EKS, falder i en af ​​disse to kategorier i henhold til vores provisioner-konfiguration. Dataforskerne vælger instanstyper ved hjælp af nodevælgere, og Karpenter tager sig af nodelivscyklusstyring.

Efter at forespørgslen er udviklet, udtrækker dataforskerne rådataene til en placering på Amazon S3 og starter derefter en Jupyter-notesbog fra AWS Kubeflow-brugergrænsefladen for at udforske dataene. Målet er at skabe det funktionssæt, der skal bruges til at træne den første model. Dette giver dataforskerne mulighed for at afgøre, om der er nok signal i dataene til at opfylde kundens forretningsbehov.

Efter at resultaterne er tilfredsstillende, går dataforskerne til næste fase af udviklingscyklussen og gør deres opdagelser til en robust pipeline. De konverterer POC-koden til produktionskvalitetskode, der kører i skala. For at sikre overholdelse ved at bruge godkendte biblioteker, oprettes en container med det passende basis Docker-billede. For vores dataforskere har vi fundet ud af, at levering af et standard Python-, TensorFlow- og Spark-basebillede giver tilstrækkelig fleksibilitet til de fleste, hvis ikke alle, arbejdsbelastninger. De kan derefter bruge Dockerfilen for deres komponent til yderligere at tilpasse deres udviklingsmiljø. Denne Dockerfile bruges derefter af CI/CD-processen til at opbygge det komponentbillede, der vil blive brugt i produktionen, og bibeholder derfor sammenhæng mellem udviklings- og produktionsmiljøer.

Vi har et værktøj, der giver datavidenskabsfolk mulighed for at starte deres udviklingsmiljø i en pod, der kører på Kubernetes. Når denne pod kører, kan dataforskerne derefter vedhæfte Visual Studio Code IDE direkte til poden og fejlsøge deres modelkode. Efter at de har kørt koden med succes, kan de skubbe deres ændringer til git, og et nyt udviklingsmiljø oprettes med de seneste ændringer.

Standard data science pipeline består af stadier, der inkluderer ekstraktion, forbehandling, træning og evaluering. Hvert trin i pipelinen vises som en komponent i Kubeflow, som består af en Kubernetes-pod, der kører en kommando med nogle oplysninger indsendt som parametre. Disse parametre kan enten være statiske værdier eller referencer til output fra en tidligere komponent. Docker-billedet, der bruges i poden, er bygget fra CI/CD-processen. Detaljer om denne proces vises i CI/CD-arbejdsgangen, der diskuteres i næste afsnit.

Udviklingscyklus på Kubeflow. Udviklingsarbejdsgangen starter til venstre med POC. Den færdige model er implementeret til athenahealth-modelserveringsplatformen, der kører på Amazon ECS.

CI/CD-proces, der understøtter automatiserede arbejdsgange

Som en del af vores CI/CD-proces bruger vi Jenkins til at bygge og teste alle Kubeflow-komponentbilleder parallelt. Ved vellykket afslutning indeholder pipeline-komponentskabelonen referencepointere til billederne, og den resulterende pipeline uploades til Kubeflow. Parametre i Jenkins pipeline giver brugerne mulighed for at starte pipelines og køre deres modeltræningstest efter vellykkede builds.

Alternativt, for at opretholde en kort udviklingscyklus, kan dataforskere også starte pipelinen fra deres lokale maskine og ændre eventuelle pipeline-parametre, de måtte eksperimentere med.

Der findes værktøjer til at sikre, at referencepointerne fra CI/CD-bygningen bruges som standard. Hvis der er en deployerbar artefakt i repoen, vil CI/CD-logikken fortsætte med at implementere artefakten til athenahealth-modelserveringsplatformen (Prediction Service), der kører på Amazon ECS med AWS Fargate. Efter at alle disse stadier er gået, fusionerer dataforskeren koden til den primære gren. Rørledningerne og deployerbare artefakter skubbes derefter til produktion.

Workflow for CI/CD-implementering. Dette diagram beskriver Data Science bygge- og implementeringsworkflow. CI/CD processen er drevet af Jenkins.

Sikkerhed

Ved at konsolidere vores datavidenskabelige arbejdsgange var vi i stand til at centralisere vores tilgang til at sikre uddannelsespipeline. I dette afsnit diskuterer vi vores tilgang til data- og klyngesikkerhed.

Datasikkerhed

Datasikkerhed er af allerstørste betydning for athenahealth. Af denne grund udvikler og vedligeholder vi infrastruktur, der er fuldt ud i overensstemmelse med de regler og standarder, der beskytter sikkerheden og integriteten af ​​disse data.

For at sikre, at vi opfylder dataoverholdelsesstandarder, leverer vi vores AWS-infrastruktur i overensstemmelse med vores retningslinjer for athenahealth-virksomheder. De to vigtigste lagre for data er Amazon RDS til meget skalerbare pipeline-metadata og Amazon S3 til pipeline- og modelartefakter. For Amazon S3 sikrer vi, at buckets er krypteret, HTTPS-endepunkter håndhæves, og bucket-politikkerne og AWS identitets- og adgangsstyring (IAM)-roller følger principperne om mindste privilegium, når de tillader adgang til dataene. Dette gælder også for Amazon RDS-data: kryptering er altid aktiveret, og sikkerhedsgrupperne og legitimationsadgang følger princippet om mindste privilegium. Denne standardisering sikrer, at kun autoriserede parter har adgang til dataene, og denne adgang spores.

Udover disse tiltag gennemgår platformen også sikkerhedstrusselsvurderinger og løbende sikkerheds- og compliance-scanninger.

Vi adresserer også dataopbevaringskrav via datalivscyklusstyring for alle S3-buckets, der indeholder følsomme data. Denne politik flytter automatisk data til Amazon S3 Glacier efter 30 dages oprettelse. Undtagelser fra dette styres gennem anmodninger om datahentning og godkendes eller afvises fra sag til sag. Dette sikrer, at alle arbejdsgange overholder dataopbevaringspolitikken. Dette løser også problemet med at gendanne data, hvis en model fungerer dårligt, og der er behov for genoptræning, eller når en ny model skal evalueres i forhold til en historisk iteration af en ældre models datasæt.

For at begrænse adgangen til Amazon S3 og Amazon RDS inde fra Kubeflow på AWS og Amazon EKS bruger vi IRSA (IAM Roles for Service Accounts), som giver IAM-baseret tilladelsesforsyning til ressourcer i Kubernetes. Hver lejer i Kubeflow har en unik præ-oprettet servicekonto, som vi binder til en IAM-rolle, der er oprettet specifikt for at opfylde lejerens adgangskrav. Brugeradgang til lejere er også begrænset ved at bruge Amazon Cognito-brugerpools gruppemedlemskab for hver bruger. Når en bruger er autentificeret til klyngen, indeholder det genererede token gruppekrav, og Kubernetes RBAC bruger disse oplysninger til at tillade eller nægte adgang til en bestemt ressource i klyngen. Denne opsætning forklares mere detaljeret i næste afsnit.

Klyngesikkerhed ved hjælp af multi-user isolation

Som vi bemærkede i det foregående afsnit, udfører datavidenskabsmænd undersøgende dataanalyser, kører dataanalyse og træner ML-modeller. For at allokere ressourcer, organisere data og administrere arbejdsgange baseret på projekter, giver Kubeflow på AWS isolation baseret på Kubernetes navnerum. Denne isolation fungerer til at interagere med Kubeflow UI; det giver dog ikke noget værktøj til at kontrollere adgangen til Kubernetes API ved hjælp af Kubectl. Dette betyder, at brugeradgang kan kontrolleres på Kubeflow-brugergrænsefladen, men ikke over Kubernetes API via Kubectl.

Arkitekturen beskrevet i det følgende diagram løser dette problem ved at forene adgangen til projekter i Kubeflow baseret på gruppemedlemskaber. For at opnå dette benyttede vi os af Kubeflow på AWS-manifesterne, som har integration med Amazon Cognito-brugerpuljer. Derudover bruger vi Kubernetes rollebaseret adgangskontrol (RBAC) til at kontrollere autorisation inden for klyngen. Brugertilladelserne leveres baseret på Amazon Cognito-gruppemedlemskab. Disse oplysninger videregives til klyngen med det token, der er genereret af OIDC-klienten. Denne proces er forenklet takket være den indbyggede Amazon EKS-funktionalitet, der gør det muligt for associerede OIDC-identitetsudbydere at autentificere med klyngen.

Som standard udføres Amazon EKS-godkendelse af IAM-autentificeringen, som er et værktøj, der muliggør godkendelse med en EKS-klynge ved hjælp af IAM-legitimationsoplysninger. Denne autentificeringsmetode har sine fordele; det er dog ikke egnet til vores use case, fordi athenahealth bruger Microsoft Azure Active Directory til identitetsservice på tværs af organisationen.

Kubernetes navneområde isolation. Data Scientists kan opnå medlemskab af en enkelt eller flere grupper efter behov for deres arbejde. Adgangen gennemgås regelmæssigt og fjernes efter behov.

Azure Active Directory, som er en virksomhedsdækkende identitetstjeneste, er kilden til sandhed til at kontrollere brugeradgang til Kubeflow-klyngen. Opsætningen til dette omfatter oprettelse af en Azure Enterprise Application, der fungerer som serviceprincipal, og tilføjelse af grupper for forskellige lejere, der kræver adgang til klyngen. Denne opsætning på Azure spejles i Amazon Cognito ved at konfigurere en fødereret OIDC-identitetsudbyder, der outsourcer godkendelsesansvaret til Azure. Adgangen til Azure-grupper styres af SailPoint IdentityIQ, som sender adgangsanmodninger til projektejeren for at tillade eller afvise alt efter behov. I Amazon Cognito-brugerpuljen oprettes to applikationsklienter: Den ene bruges til at konfigurere godkendelsen for Kubernetes-klyngen ved hjælp af OIDC-identitetsudbyderen, og den anden til at sikre Kubeflow-godkendelse i Kubeflow-brugergrænsefladen. Disse klienter er konfigureret til at videregive gruppekrav ved godkendelse med klyngen, og disse gruppekrav bruges sammen med RBAC til at opsætte autorisation i klyngen.

Kubernetes RBAC-rollebindinger er sat op mellem grupper og klyngerollen Kubeflow-edit, som oprettes ved installation af Kubeflow i klyngen. Denne rollebinding sikrer, at enhver bruger, der interagerer med klyngen efter at have logget ind via OIDC, kan få adgang til de navneområder, de har tilladelser til som defineret i deres gruppekrav. Selvom dette virker for brugere, der interagerer med klyngen ved hjælp af Kubectl, giver Kubeflow-brugergrænsefladen i øjeblikket ikke adgang til brugere baseret på gruppemedlemskab, fordi den ikke bruger RBAC. I stedet bruger den Istio Authorization Policy-ressourcen til at kontrollere adgangen for brugere. For at overvinde denne udfordring udviklede vi en brugerdefineret controller, der synkroniserer brugere ved at polle Amazon Cognito-grupper og tilføjer eller fjerner tilsvarende rollebindinger for hver bruger i stedet for efter gruppe. Denne opsætning gør det muligt for brugere at have det samme niveau af tilladelser, når de interagerer med både Kubeflow UI og Kubectl.

Driftseffektivitet

I dette afsnit diskuterer vi, hvordan vi udnyttede de open source- og AWS-værktøjer, der er tilgængelige for os, til at administrere og fejlrette vores arbejdsgange samt for at minimere den operationelle virkning af opgradering af Kubeflow.

Logning og overvågning

Til logning bruger vi FluentD til at skubbe alle vores containerlogfiler til Amazon OpenSearch Service og systemmetrikker til Prometheus. Vi bruger derefter Kibana og Grafana UI til at søge og filtrere logfiler og metrics. Følgende diagram beskriver, hvordan vi sætter dette op.

Kubeflow-logning. Vi bruger både Grafana UI og Kibana til at se og gennemse logfilerne

Følgende skærmbillede er en Kibana UI-visning fra vores pipeline.

Eksempel på Kibana UI View. Kibana giver mulighed for tilpassede visninger.

Safe Kubeflow-klyngeopgraderinger

Når vi ombord brugere til Kubeflow på AWS, opretholder vi en pålidelig og ensartet brugeroplevelse, samtidig med at vi tillader MLOps-teamet at forblive agile med at frigive og integrere nye funktioner. På overfladen virker Kustomize modulopbygget for os, så vi kan arbejde og opgradere én komponent ad gangen uden at påvirke andre, hvilket giver os mulighed for at tilføje nye muligheder med minimal forstyrrelse for brugerne. Men i praksis er der scenarier, hvor den bedste tilgang er blot at oprette en ny Kubernetes-klynge i stedet for at anvende opgraderinger på komponentniveau til eksisterende klynger. Vi fandt to use cases, hvor det gav mere mening at skabe helt nye klynger:

• Opgradering til en Kubernetes-version, hvor AWS tilbyder klyngeopgraderinger på stedet. Det bliver dog vanskeligt at teste, om hver af Kubeflow- og Kubernetes-ressourcerne fungerer efter hensigten, og manifesterne bevarer bagudkompatibilitet.
• Opgradering af Kubeflow til en nyere udgivelse, hvor der er tilføjet eller ændret flere funktioner, og det er næsten altid ikke en lovende idé at udføre in-place opgraderinger på en eksisterende Kubernetes-klynge.

For at løse dette problem udviklede vi en strategi, der gør os i stand til at have sikre klyngeudskiftninger uden at påvirke eksisterende arbejdsbelastninger. For at opnå dette skulle vi opfylde følgende kriterier:

• Adskil Kubeflow-lager- og computerressourcerne, så pipeline-metadata, pipeline-artefakter og brugerdata bevares, når den ældre klynge deprovisioneres
• Integrer med Kubeflow på AWS-manifester, så der kræves minimale ændringer, når en Kubeflow-versionsopgradering sker
• Få en ubesværet måde at rulle tilbage, hvis tingene går galt efter klyngeopgradering
• Har en enkel grænseflade til at fremme en kandidatklynge til produktion

Følgende diagram illustrerer denne arkitektur.

Sikker Kubeflow-klyngeopgradering. Når testen af ​​Kubeflow-kandidaten er vellykket, forfremmes den til Kubeflow Prod gennem en opdatering til Route 53.

Kubeflow på AWS-manifester kommer færdigpakkede med Amazon RDS og Amazon S3 integrationer. Med disse administrerede tjenester, der fungerer som almindelige datalagre, kan vi opsætte en blå-grøn implementeringsstrategi. For at opnå dette sikrede vi, at pipeline-metadataene bevares i Amazon RDS, som fungerer uafhængigt af EKS-klyngen, og at pipeline-logfilerne og artefakterne bevares i Amazon S3. Ud over pipeline-metadata og artefakter konfigurerede vi også FluentD til at dirigere pod-logfiler til Amazon OpenSearch Service.

Dette sikrer, at lagerlaget er fuldstændig adskilt fra beregningslaget og muliggør derved testændringer under Kubeflow-versionsopdateringer på en helt ny EKS-klynge. Når alle testene er vellykkede, er vi i stand til blot at ændre Amazonrute 53 DNS-post til kandidatklyngen, der hoster Kubeflow. Vi holder også den gamle klynge kørende som backup i et par dage, bare hvis vi skal rulle tilbage.

Fordele ved Amazon EKS og Kubeflow på AWS til vores ML-pipeline

Amazon EKS og Kubeflow on AWS-pakken flyttede vores udviklingsarbejdsgang til et mønster, der kraftigt opfordrer til gentagelig modeltræning. Disse værktøjer giver os mulighed for at have fuldt definerede klynger med fuldt definerede lejere og køre fuldt defineret kode.

Mange gevinster ved at bygge denne platform er mindre kvantitative og har mere at gøre med, hvordan arbejdsgangene er blevet forbedret for både platformsudviklere og brugere. For eksempel blev MinIO erstattet med direkte adgang til Amazon S3, hvilket flytter os tættere på vores oprindelige arbejdsgange og reducerer antallet af tjenester, vi skal vedligeholde. Vi er også i stand til at bruge Amazon RDS som backend for Kubeflow, hvilket muliggør lettere migreringer mellem klynger og giver os mulighed for at sikkerhedskopiere vores pipelines hver nat.

Vi fandt også forbedringerne i Kubeflow-integrationen med AWS-administrerede tjenester gavnlige. For eksempel, med Amazon RDS, Amazon S3 og Amazon Cognito forudkonfigureret i Kubeflow på AWS-manifesterne, sparer vi tid og kræfter på at opdatere til nyere distributioner af Kubeflow. Da vi plejede at ændre de officielle Kubeflow-manifester manuelt, ville opdatering til en ny version tage flere uger, fra design til test.

Skift til Amazon EKS giver os mulighed for at definere vores klynge i Kustomize (nu en del af Kubectl) og Terraform. Det viser sig, at til platformsarbejde er Kubernetes og Terraform meget nemme at arbejde med efter at have brugt nok tid på at lære. Efter mange gentagelser gør de tilgængelige værktøjer det meget nemt at udføre standardplatformsoperationer som at opgradere en komponent eller udskifte en hel udviklingsklynge. Sammenlignet med at køre job off raw Amazon Elastic Compute Cloud (Amazon EC2) tilfælde, er det svært at sammenligne, hvilken enorm forskel det gør at have veldefinerede pods med garanteret ressourceoprydning og genforsøgsmekanismer indbygget.

Kubernetes leverer fremragende sikkerhedsstandarder, og vi har kun ridset overfladen af, hvad multi-user isolationen tillader os at gøre. Vi ser multi-user isolation som et mønster, der har mere udbytte i fremtiden, når træningsplatformen producerer data på produktionsniveau, og vi ansætter udviklere uden for vores team.

I mellemtiden giver Kubeflow os mulighed for at have reproducerbar modeltræning. Selv med de samme data giver ingen træning identiske modeller, men vi har det næstbedste. Med Kubeflow ved vi præcis, hvilken kode og data der blev brugt til at træne en model. Onboarding er blevet væsentligt forbedret, fordi hvert trin i vores pipeline er klart og programmatisk defineret. Når nye datavidenskabsmænd har til opgave at rette en fejl, har de brug for meget mindre håndholdt, fordi der er en klar struktur for, hvordan output af kode bruges mellem stadier.

Brug af Kubeflow giver også en masse præstationsforbedringer sammenlignet med at køre på en enkelt EC2-instans. Ofte i modeltræning har dataforskere brug for forskellige værktøjer og optimeringer til forbehandling og træning. For eksempel køres forbehandling ofte ved hjælp af distribuerede databehandlingsværktøjer, som Spark, hvorimod træning ofte køres ved hjælp af GPU-instanser. Med Kubeflow-pipelines kan de angive forskellige instanstyper for forskellige stadier i pipelinen. Dette giver dem mulighed for at bruge de kraftfulde GPU-instanser i én fase og en flåde af mindre maskiner til distribueret behandling i en anden fase. Fordi Kubeflow-pipelines beskriver afhængighederne mellem faser, kan pipelines også køre etaper parallelt.

Endelig, fordi vi har oprettet en proces til at tilføje lejere til klyngen, er der nu en mere formel måde at registrere hold til en lejer i klyngen. Fordi vi bruger Kubecost til at spore omkostninger i vores EKS-klynge, giver det os mulighed for at tilskrive omkostninger til et enkelt projekt i stedet for at få omkostninger tilskrevet på kontoniveau, som omfatter alle datavidenskabelige projekter. Kubecost præsenterer en rapport over de penge, der er brugt pr. navneområde, som er tæt koblet til lejeren eller teamet, der er ansvarlig for at køre pipelinen.

På trods af alle fordelene vil vi advare mod kun at foretage denne form for migrering, hvis der er totalt buy-in fra brugerne. Brugere, der bruger tiden, får mange fordele ved at bruge Amazon EKS og Kubernetes, men der er en betydelig indlæringskurve.

Konklusion

Med implementeringen af ​​Kubeflow på AWS-pipelinen i vores end-to-end ML-infrastruktur var vi i stand til at konsolidere og standardisere vores datavidenskabelige arbejdsgange, samtidig med at vi bibeholdt vores væsentlige værktøjer (såsom CI/CD og modelservering). Vores data scientists kan nu flytte mellem projekter baseret på denne arbejdsgang uden at skulle lære at vedligeholde et helt andet værktøjssæt. For nogle af vores modellers vedkommende var vi også positivt overrasket over hastigheden af ​​den nye arbejdsgang (fem gange hurtigere), som muliggjorde flere træningsgentagelser og som følge heraf producerede modeller med bedre forudsigelser.

Vi har også etableret et solidt grundlag for at øge vores MLOps-kapaciteter og skalere antallet og størrelsen af ​​vores projekter. For eksempel har vi reduceret vores fokus fra over 15 arbejdsgange til kun én, efterhånden som vi skærper vores ledelsesposition i modellinje og sporing. Og da Log4shell-sårbarheden kom frem i slutningen af ​​2021, var vi i stand til at fokusere på en enkelt arbejdsgang og hurtigt afhjælpe efter behov (ved at udføre Amazon Elastic Container Registry (Amazon ECR) scanninger, opgradering af Amazon OpenSearch Service, opdatering af vores værktøjer og mere) med minimal indvirkning på dataforskernes igangværende arbejde. Efterhånden som AWS- og Kubeflow-forbedringer bliver tilgængelige, kan vi inkorporere dem, som vi finder passende.

Dette bringer os til et vigtigt og underspillet aspekt af vores Kubeflow om AWS-adoption. Et af de kritiske resultater af denne rejse er evnen til at udrulle opgraderinger og forbedringer til Kubeflow problemfrit for vores dataforskere. Selvom vi diskuterede vores tilgang til dette tidligere, stoler vi også på Kubeflow-manifesterne leveret af AWS. Vi startede vores Kubeflow-rejse som et proof of concept i 2019, før udgivelsen af ​​version 1.0.0. (Vi er i øjeblikket på 1.4.1 og evaluerer 1.5. AWS arbejder allerede på 1.6-versionen.) I de mellemliggende 3 år har der været mindst seks udgivelser med væsentligt indhold. Gennem deres disciplinerede tilgang til at integrere og validere disse opgraderinger og frigive manifesterne på en forudsigelig, pålidelig tidsplan, har Kubeflow-teamet hos AWS været afgørende for at sætte athenahealth MLOps-teamet i stand til at planlægge vores udviklingsplan og dermed vores ressourceallokeringer og fokusområder , længere ud i fremtiden med større tillid.

Du kan følge AWS Labs GitHub-lager at spore alle AWS-bidrag til Kubeflow. Du kan også finde AWS-hold på Kubeflow #AWS Slack Channel; din feedback der hjælper AWS med at prioritere de næste funktioner, der skal bidrage til Kubeflow-projektet.

---

Om forfatterne

Kanwaljit Khurmi er Senior Solutions Architect hos Amazon Web Services. Han arbejder sammen med AWS-kunderne for at yde vejledning og teknisk assistance, der hjælper dem med at forbedre værdien af ​​deres løsninger, når de bruger AWS. Kanwaljit har specialiseret sig i at hjælpe kunder med container- og maskinlæringsapplikationer.

Tyler Kalbach er hovedmedlem af teknisk personale hos athenahealth. Tyler har cirka 7 års erfaring i Analytics, Data Science, Neurale netværk og udvikling af Machine Learning-applikationer i sundhedsområdet. Han har bidraget til flere Machine Learning-løsninger, der i øjeblikket betjener produktionstrafikken. Tyler, der i øjeblikket arbejder som Principal Data Scientist i athenahealths ingeniørorganisation, har været en del af det team, der har bygget den nye Machine Learning Training Platform for athenahealth fra begyndelsen af ​​denne indsats.

Victor Krylov er hovedmedlem af teknisk personale hos athenahealth. Victor er ingeniør og scrum master, der hjælper datavidenskabsfolk med at bygge sikre hurtige maskinlæringspipelines. I athenahealth har han arbejdet med grænseflader, klinisk bestilling, recepter, planlægning, analyser og nu maskinlæring. Han værdsætter rent skrevet og velafprøvet kode, men har en usund besættelse af kode-one-liners. I sin fritid nyder han at lytte til podcasts, mens han går tur med sin hund.

Sasank Vemuri er Lead Member of Technical Staff hos athenahealth. Han har erfaring med at udvikle datadrevne løsninger på tværs af domæner som sundhedspleje, forsikring og bioinformatik. Sasank arbejder i øjeblikket med at designe og udvikle maskinlærings- og inferensplatforme på AWS og Kubernetes, der hjælper med træning og implementering af ML-løsninger i stor skala.

Anu Tumkur er arkitekt hos athenahealth. Anu har over to årtier med arkitektur, design, udviklingserfaring med at bygge forskellige softwareprodukter inden for maskinlæring, cloud-operationer, big data, distribuerede datapipelines i realtid, annonceteknologi, dataanalyse, sociale medier-analyse. Anu arbejder i øjeblikket som arkitekt i athenahealth's Product Engineering organisation på Machine Learning Platform og Data Pipeline teams.

William Tsen er Senior Engineering Manager hos athenahealth. Han har over 20 års erfaring med ingeniørlederskab med at bygge løsninger inden for IT i sundhedssektoren, distribueret databehandling med big data, intelligente optiske netværk, videoredigeringssystemer i realtid, virksomhedssoftware og underwriting af gruppesundhedstjenester. William leder i øjeblikket to fantastiske teams hos athenahealth, Machine Learning Operations og DevOps ingeniørteams, i Product Engineering-organisationen.