Skapa repeterbara, säkra och utbyggbara end-to-end maskininlärningsarbetsflöden med Kubeflow på AWS

Detta är ett gästblogginlägg skrivet tillsammans med athenahealth.

athenahälsa en ledande leverantör av nätverksaktiverad programvara och tjänster för medicinska grupper och hälsosystem i hela landet. Dess elektroniska journaler, intäktscykelhantering och patientengagemang ger åtkomst när som helst och var som helst, vilket leder till bättre ekonomiska resultat för sina kunder och gör det möjligt för sina leverantörskunder att leverera vård av bättre kvalitet.

I utrymmet för artificiell intelligens (AI) använder athenahealth datavetenskap och maskininlärning (ML) för att påskynda affärsprocesser och ge rekommendationer, förutsägelser och insikter över flera tjänster. Från den första implementeringen i automatiserade dokumenttjänster, beröringsfri bearbetning av miljontals leverantör-patientdokument, till dess nyare arbete med virtuella assistenter och förbättring av intäktscykelprestanda, fortsätter athenahealth att tillämpa AI för att hjälpa till att driva effektivitet, tjänstekapacitet och bättre resultat för leverantörer och deras patienter.

Det här blogginlägget visar hur athenahealth använder Kubeflow på AWS (en AWS-specifik distribution av Kubeflow) för att bygga och effektivisera ett datavetenskapligt arbetsflöde från slut till slut som bevarar viktiga verktyg, optimerar operativ effektivitet, ökar dataforskares produktivitet och sätter scenen för att utöka deras ML-kapacitet lättare.

Kubeflow är ML-plattformen med öppen källkod dedikerad till att göra implementeringar av ML-arbetsflöden på Kubernetes enkla, bärbara och skalbara. Kubeflow uppnår detta genom att integrera relevanta verktyg med öppen källkod som integreras väl med Kubernetes. Några av dessa projekt inkluderar Argo för pipeline-orkestrering, Istio för servicenät, Jupyter för bärbara datorer, Spark, TensorBoard och Katib. Kubeflow Pipelines hjälper till att bygga och distribuera bärbara, skalbara ML-arbetsflöden som kan inkludera steg som dataextraktion, förbearbetning, modellträning och modellutvärdering i form av repeterbara pipelines.

AWS bidrar till Kubeflow-communityt med öppen källkod genom att tillhandahålla sin egen Kubeflow-distribution (kallad Kubeflow på AWS) som hjälper organisationer som athenahealth att bygga mycket tillförlitliga, säkra, portabla och skalbara ML-arbetsflöden med minskade driftskostnader genom integration med AWS-hanterade tjänster. AWS tillhandahåller olika Kubeflow-distributionsalternativ som distribution med Amazon Cognito, utplacering med Amazon Relational Databas Service (Amazon RDS) och Amazon enkel lagringstjänst (Amazon S3) och vaniljinstallation. Mer information om tjänstintegrering och tillgängliga tillägg för vart och ett av dessa alternativ finns i konfiguration.

Idag ger Kubeflow på AWS en tydlig väg till att använda Kubeflow, utökad med följande AWS-tjänster:

Många AWS-kunder utnyttjar Kubeflow på AWS-distribution, inklusive athenahealth.

Här diskuterar athenahealth MLOps-teamet de utmaningar de stött på och de lösningar de skapade under sin Kubeflow-resa.

Utmaningar med den tidigare ML-miljön

Innan vi antog Kubeflow på AWS använde våra datavetare en standardiserad uppsättning verktyg och en process som möjliggjorde flexibilitet i tekniken och arbetsflödet som användes för att träna en given modell. Exempel på komponenter i det standardiserade verktyget inkluderar ett dataintags-API, säkerhetsskanningsverktyg, CI/CD-pipeline byggd och underhållen av ett annat team inom athenahealth, och en gemensam serveringsplattform byggd och underhållen av MLOps-teamet. Men allt eftersom vår användning av AI och ML mognade, växte mängden verktyg och infrastruktur som skapades för varje modell. Även om vi fortfarande kunde stödja den befintliga processen, såg vi följande utmaningar vid horisonten:

• Underhåll och tillväxt – Att återskapa och underhålla modellutbildningsmiljöer tog mer ansträngning när antalet utplacerade modeller ökade. Varje projekt hade detaljerad dokumentation som beskrev hur varje manus användes för att bygga den slutliga modellen. I många fall var detta en komplicerad process som involverade 5 till 10 skript med flera utgångar vardera. Dessa måste spåras manuellt med detaljerade instruktioner om hur varje utgång skulle användas i efterföljande processer. Att upprätthålla detta med tiden blev krångligt. När projekten blev mer komplexa ökade dessutom antalet verktyg. Till exempel använde de flesta modellerna Spark och TensorFlow med GPU:er, vilket krävde ett större utbud av miljökonfigurationer. Med tiden skulle användare byta till nyare versioner av verktyg i sina utvecklingsmiljöer men kunde sedan inte köra äldre skript när dessa versioner blev inkompatibla. Följaktligen krävde att underhålla och utöka äldre projekt mer tid och ansträngning. Dessutom, när nya datavetare anslöt sig till teamet, tog kunskapsöverföring och introduktion mer tid, eftersom synkronisering av lokala miljöer innefattade många odokumenterade beroenden. Att byta mellan projekt stötte på samma problem eftersom varje modell hade sina egna arbetsflöden.
• Säkerhet – Vi tar säkerheten på allvar och prioriterar därför efterlevnad av alla avtalsenliga, juridiska och regulatoriska skyldigheter kopplade till ML och datavetenskap. Data måste användas, lagras och nås på specifika sätt, och vi har inbäddade robusta processer för att säkerställa att vår praxis överensstämmer med våra juridiska skyldigheter samt är i linje med branschens bästa praxis. Innan Kubeflow togs i bruk, att säkerställa att data lagrades och åtkoms på ett specifikt sätt innebar regelbunden verifiering över flera olika arbetsflöden. Vi visste att vi kunde förbättra effektiviteten genom att konsolidera dessa olika arbetsflöden på en enda plattform. Den plattformen skulle dock behöva vara tillräckligt flexibel för att integreras väl med våra standardiserade verktyg.
• Verksamhet – Vi såg också en möjlighet att öka den operativa effektiviteten och förvaltningen genom att centralisera loggningen och övervakningen av arbetsflödena. Eftersom varje team hade utvecklat sina egna verktyg, samlade vi in ​​denna information från varje arbetsflöde individuellt och aggregerade dem.

Datavetenskapsteamet utvärderade olika lösningar för att konsolidera arbetsflödena. Förutom att möta dessa krav, letade vi efter en lösning som skulle integreras sömlöst med den befintliga standardiserade infrastrukturen och verktygen. Vi valde Amazon EKS och Kubeflow på AWS som vår arbetsflödeslösning.

Data scientists utvecklingscykel som innehåller Kubeflow

Ett datavetenskapligt projekt börjar med ett rent blad: ingen data, ingen kod, bara affärsproblemet som kan lösas med ML. Den första uppgiften är ett proof of concept (POC) för att upptäcka om data innehåller tillräckligt med signaler för att göra en ML-modell effektiv för att lösa affärsproblemet, och börja med att söka efter rådatauppsättningen från vårt Snowflake-datalager. Detta steg är iterativt och dataforskarna använder Kubernetes-poddar eller Kubeflow Jupyter-anteckningsböcker under denna process.

Vårt Kubeflow-kluster använder Karpenter-kluster autoscaler, vilket gör det enkelt för datavetare att samla upp resurser eftersom de bara behöver fokusera på att definiera de önskade instanstyperna, medan provisioneringsarbetet görs av en uppsättning fördefinierade Karpenter-provisionerare. Vi har separata provisioner för CPU- och GPU-instanstyper, och alla instanser som stöds av Amazon EKS faller i en av dessa två kategorier enligt vår provisionerkonfiguration. Dataforskarna väljer instanstyper med hjälp av nodväljare, och Karpenter tar hand om nodlivscykelhantering.

Efter att frågan har utvecklats extraherar dataforskarna rådata till en plats på Amazon S3 och startar sedan en Jupyter-anteckningsbok från AWS Kubeflow UI för att utforska data. Målet är att skapa funktionsuppsättningen som kommer att användas för att träna den första modellen. Detta gör det möjligt för dataforskarna att avgöra om det finns tillräckligt med signaler i datan för att uppfylla kundens affärsbehov.

Efter att resultaten är tillfredsställande går dataforskarna till nästa steg i utvecklingscykeln och förvandlar sina upptäckter till en robust pipeline. De omvandlar POC-koden till produktionskvalitetskod som körs i skala. För att säkerställa efterlevnad genom att använda godkända bibliotek skapas en behållare med lämplig bas Docker-bild. För våra dataforskare har vi funnit att tillhandahållandet av en standard Python-, TensorFlow- och Spark-basbild ger tillräcklig flexibilitet för de flesta, om inte alla, arbetsbelastningar. De kan sedan använda Dockerfilen för sin komponent för att ytterligare anpassa sin utvecklingsmiljö. Denna Dockerfil används sedan av CI/CD-processen för att bygga komponentbilden som kommer att användas i produktionen, och bibehåller därför överensstämmelse mellan utvecklings- och produktionsmiljöer.

Vi har ett verktyg som ger datavetare möjligheten att lansera sin utvecklingsmiljö i en pod som körs på Kubernetes. När denna pod körs kan dataforskarna sedan koppla Visual Studio Code IDE direkt till podden och felsöka sin modellkod. Efter att de har kört koden framgångsrikt kan de sedan överföra sina ändringar till git och en ny utvecklingsmiljö skapas med de senaste ändringarna.

Standardpipelinen för datavetenskap består av steg som inkluderar extraktion, förbearbetning, utbildning och utvärdering. Varje steg i pipelinen visas som en komponent i Kubeflow, som består av en Kubernetes-pod som kör ett kommando med viss information som skickas in som parametrar. Dessa parametrar kan antingen vara statiska värden eller referenser till utdata från en tidigare komponent. Docker-bilden som används i podden är byggd från CI/CD-processen. Detaljer om denna process visas i CI/CD-arbetsflödet som diskuteras i nästa avsnitt.

Utvecklingscykel på Kubeflow. Utvecklingsarbetsflödet börjar till vänster med POC. Den färdiga modellen distribueras till serviceplattformen för athenahealth-modellen som körs på Amazon ECS.

CI/CD-process som stöder automatiserade arbetsflöden

Som en del av vår CI/CD-process använder vi Jenkins för att bygga och testa alla Kubeflow-komponentbilder parallellt. Efter framgångsrikt slutförande innehåller pipelinekomponentmallen referenspekare till bilderna, och den resulterande pipelinen laddas upp till Kubeflow. Parametrar i Jenkins pipeline tillåter användare att starta pipelines och köra sina modellträningstester efter framgångsrika konstruktioner.

Alternativt, för att upprätthålla en kort utvecklingscykel, kan datavetare också starta pipelinen från sin lokala maskin, och ändra eventuella pipelineparametrar de experimenterar med.

Det finns verktyg för att säkerställa att referenspekarna från CI/CD-bygget används som standard. Om det finns en utplacerbar artefakt i repet kommer CI/CD-logiken att fortsätta att distribuera artefakten till athenahealth-modellens betjäningsplattform (Prediction Service) som körs på Amazon ECS med AWS Fargate. Efter att alla dessa stadier har passerat slår dataforskaren samman koden till den primära grenen. Rörledningarna och de utplacerbara artefakterna skjuts sedan till produktion.

Arbetsflöde för CI/CD-distribution. Det här diagrammet beskriver arbetsflödet för uppbyggnad och distribution av Data Science. CI/CD-processen drivs av Jenkins.

Säkerhet

Genom att konsolidera våra datavetenskapliga arbetsflöden kunde vi centralisera vår strategi för att säkra utbildningspipelinen. I det här avsnittet diskuterar vi vår strategi för data- och klustersäkerhet.

Datasäkerhet

Datasäkerhet är av yttersta vikt inom athenahealth. Av denna anledning utvecklar och underhåller vi en infrastruktur som är helt kompatibel med de regler och standarder som skyddar dessa datas säkerhet och integritet.

För att säkerställa att vi uppfyller datakompatibilitetsstandarder tillhandahåller vi vår AWS-infrastruktur i enlighet med våra riktlinjer för athenahealth-företag. De två huvudlagringarna för data är Amazon RDS för mycket skalbar pipeline-metadata och Amazon S3 för pipeline- och modellartefakter. För Amazon S3 ser vi till att hinkarna är krypterade, HTTPS-ändpunkter upprätthålls och att bucketpolicyerna och AWS identitets- och åtkomsthantering (IAM)-roller följer principerna för minsta privilegium när de tillåter åtkomst till data. Detta gäller även för Amazon RDS-data: kryptering är alltid aktiverad, och säkerhetsgrupperna och autentiseringsåtkomsten följer principen om minsta privilegium. Denna standardisering säkerställer att endast auktoriserade parter har tillgång till data, och denna åtkomst spåras.

Utöver dessa åtgärder genomgår plattformen även säkerhetshotsbedömningar och kontinuerliga säkerhets- och efterlevnadsskanningar.

Vi tar också upp krav på datalagring via datalivscykelhantering för alla S3-buckets som innehåller känslig data. Denna policy flyttar automatiskt data till Amazon S3-glaciären efter 30 dagars skapande. Undantag från detta hanteras genom förfrågningar om datahämtning och godkänns eller nekas från fall till fall. Detta säkerställer att alla arbetsflöden följer policyn för datalagring. Detta löser också problemet med att återställa data om en modell presterar dåligt, och omskolning krävs, eller när en ny modell måste utvärderas mot en historisk iteration av en äldre modells dataset.

För att begränsa åtkomsten till Amazon S3 och Amazon RDS från Kubeflow på AWS och Amazon EKS använder vi IRSA (IAM Roles for Service Accounts), som tillhandahåller IAM-baserad behörighetsförsörjning för resurser inom Kubernetes. Varje hyresgäst i Kubeflow har ett unikt förskapat tjänstekonto som vi binder till en IAM-roll skapad specifikt för att uppfylla kraven på åtkomst för hyresgäster. Användaråtkomst till hyresgäster är också begränsad genom att använda Amazon Cognito-användarpooler gruppmedlemskap för varje användare. När en användare autentiseras till klustret innehåller den genererade token gruppanspråk, och Kubernetes RBAC använder denna information för att tillåta eller neka åtkomst till en viss resurs i klustret. Denna inställning förklaras mer i detalj i nästa avsnitt.

Klustersäkerhet med fleranvändarisolering

Som vi noterade i föregående avsnitt utför datavetare utforskande dataanalyser, kör dataanalyser och tränar ML-modeller. För att allokera resurser, organisera data och hantera arbetsflöden baserat på projekt, tillhandahåller Kubeflow på AWS isolering baserad på Kubernetes namnrymder. Denna isolering fungerar för att interagera med Kubeflow UI; den tillhandahåller dock inga verktyg för att kontrollera åtkomst till Kubernetes API med Kubectl. Detta innebär att användaråtkomst kan styras på Kubeflow-gränssnittet men inte över Kubernetes API via Kubectl.

Arkitekturen som beskrivs i följande diagram löser detta problem genom att förena åtkomst till projekt i Kubeflow baserat på gruppmedlemskap. För att uppnå detta utnyttjade vi Kubeflow på AWS-manifesterna, som har integration med Amazon Cognito-användarpooler. Dessutom använder vi Kubernetes rollbaserad åtkomstkontroll (RBAC) för att kontrollera auktorisering inom klustret. Användarbehörigheterna tillhandahålls baserat på Amazon Cognito-gruppmedlemskap. Denna information skickas till klustret med token som genereras av OIDC-klienten. Denna process förenklas tack vare den inbyggda Amazon EKS-funktionaliteten som gör att associerande OIDC-identitetsleverantörer kan autentisera sig med klustret.

Som standard utförs Amazon EKS-autentisering av IAM-autentisering, som är ett verktyg som möjliggör autentisering med ett EKS-kluster med IAM-referenser. Denna autentiseringsmetod har sina fördelar; det är dock inte lämpligt för vårt användningsfall eftersom athenahealth använder Microsoft Azure Active Directory för identitetstjänst i hela organisationen.

Kubernetes namnområdesisolering. Dataforskare kan få medlemskap i en enstaka eller flera grupper efter behov för deras arbete. Åtkomsten granskas regelbundet och tas bort vid behov.

Azure Active Directory, som är en företagsomfattande identitetstjänst, är källan till sanning för att kontrollera användaråtkomst till Kubeflow-klustret. Inställningen för detta inkluderar att skapa en Azure Enterprise Application som fungerar som tjänstehuvud och lägga till grupper för olika klienter som kräver åtkomst till klustret. Denna inställning på Azure speglas i Amazon Cognito genom att konfigurera en federerad OIDC-identitetsleverantör som lägger ut autentiseringsansvaret till Azure. Åtkomsten till Azure-grupper styrs av SailPoint IdentityIQ, som skickar åtkomstförfrågningar till projektägaren för att tillåta eller neka efter behov. I Amazon Cognito-användarpoolen skapas två applikationsklienter: en används för att ställa in autentiseringen för Kubernetes-klustret med hjälp av OIDC-identitetsleverantören, och den andra för att säkra Kubeflow-autentisering i Kubeflow-gränssnittet. Dessa klienter är konfigurerade att skicka gruppanspråk vid autentisering med klustret, och dessa gruppanspråk används tillsammans med RBAC för att ställa in auktorisering inom klustret.

Kubernetes RBAC-rollbindningar ställs in mellan grupper och klusterrollen Kubeflow-edit, som skapas när Kubeflow installeras i klustret. Denna rollbindning säkerställer att alla användare som interagerar med klustret efter att ha loggat in via OIDC kan komma åt namnområdena de har behörighet för enligt definitionen i deras gruppanspråk. Även om detta fungerar för användare som interagerar med klustret med Kubectl, tillhandahåller Kubeflow-gränssnittet för närvarande inte åtkomst till användare baserat på gruppmedlemskap eftersom det inte använder RBAC. Istället använder den Istio Authorization Policy-resursen för att kontrollera åtkomst för användare. För att övervinna denna utmaning utvecklade vi en anpassad kontroller som synkroniserar användare genom att polla Amazon Cognito-grupper och lägger till eller tar bort motsvarande rollbindningar för varje användare snarare än per grupp. Denna inställning gör det möjligt för användare att ha samma behörighetsnivå när de interagerar med både Kubeflow UI och Kubectl.

Operativ effektivitet

I det här avsnittet diskuterar vi hur vi utnyttjade den öppna källkod och AWS-verktygen tillgängliga för oss för att hantera och felsöka våra arbetsflöden samt för att minimera den operativa effekten av att uppgradera Kubeflow.

Loggning och övervakning

För loggning använder vi FluentD för att skicka alla våra containerloggar till Amazon OpenSearch Service och systemmått till Prometheus. Vi använder sedan Kibana och Grafana UI för att söka och filtrera loggar och mätvärden. Följande diagram beskriver hur vi ställer upp detta.

Kubeflow-loggning. Vi använder både Grafana UI och Kibana för att se och sålla igenom loggarna

Följande skärmdump är en Kibana UI-vy från vår pipeline.

Exempel på Kibana UI View. Kibana möjliggör anpassade vyer.

Safe Kubeflow-klusteruppgraderingar

När vi går ombord på användare i Kubeflow på AWS bibehåller vi en pålitlig och konsekvent användarupplevelse samtidigt som vi tillåter MLOps-teamet att hålla sig smidigt med att släppa och integrera nya funktioner. På ytan verkar Kustomize modulärt för oss för att möjliggöra arbete och uppgradering av en komponent i taget utan att påverka andra, vilket gör att vi kan lägga till nya funktioner med minimala störningar för användarna. Men i praktiken finns det scenarier där det bästa tillvägagångssättet är att helt enkelt snurra upp ett nytt Kubernetes-kluster istället för att tillämpa uppgraderingar på komponentnivå för befintliga kluster. Vi hittade två användningsfall där det var mer meningsfullt att skapa helt nya kluster:

• Uppgradering till en Kubernetes-version där AWS tillhandahåller klusteruppgraderingar på plats. Det blir dock svårt att testa om var och en av Kubeflow- och Kubernetes-resurserna fungerar som avsett och manifesten behåller bakåtkompatibilitet.
• Att uppgradera Kubeflow till en nyare version där det finns flera funktioner som läggs till eller ändras och det nästan alltid inte är en lovande idé att utföra på plats uppgraderingar på ett befintligt Kubernetes-kluster.

För att ta itu med det här problemet utvecklade vi en strategi som gör det möjligt för oss att ha säkra klusterersättningar utan att påverka befintliga arbetsbelastningar. För att uppnå detta var vi tvungna att uppfylla följande kriterier:

• Separera Kubeflow-lagrings- och beräkningsresurserna så att pipeline-metadata, pipeline-artefakter och användardata behålls när det äldre klustret tas bort
• Integrera med Kubeflow på AWS-manifest så att när en Kubeflow-versionsuppgradering sker krävs minimala ändringar
• Har ett enkelt sätt att rulla tillbaka om saker går fel efter klusteruppgraderingen
• Ha ett enkelt gränssnitt för att främja ett kandidatkluster till produktion

Följande diagram illustrerar denna arkitektur.

Säker Kubeflow-klusteruppgradering. När testet av Kubeflow-kandidaten är framgångsrikt uppflyttas den till Kubeflow Prod genom en uppdatering till Route 53.

Kubeflow på AWS-manifester kommer färdigförpackade med Amazon RDS- och Amazon S3-integrationer. Med dessa hanterade tjänster som fungerar som vanliga datalager kan vi skapa en blågrön implementeringsstrategi. För att uppnå detta säkerställde vi att pipelinemetadata finns kvar i Amazon RDS, som fungerar oberoende av EKS-klustret, och att pipelineloggarna och artefakterna finns kvar i Amazon S3. Förutom pipeline-metadata och artefakter har vi också ställt in FluentD för att dirigera podloggar till Amazon OpenSearch Service.

Detta säkerställer att lagringsskiktet är helt separerat från beräkningsskiktet och gör det därigenom möjligt att testa ändringar under Kubeflow-versionsuppdateringar på ett helt nytt EKS-kluster. När alla tester har lyckats kan vi helt enkelt ändra Amazon väg 53 DNS-post till kandidatklustret som är värd för Kubeflow. Dessutom håller vi det gamla klustret igång som backup i några dagar ifall vi skulle behöva rulla tillbaka.

Fördelar med Amazon EKS och Kubeflow på AWS för vår ML-pipeline

Amazon EKS och Kubeflow on AWS-paketet flyttade vårt utvecklingsarbetsflöde till ett mönster som starkt uppmuntrar repeterbar modellträning. Dessa verktyg tillåter oss att ha fullt definierade kluster med fullt definierade hyresgäster och köra helt definierad kod.

Många vinster från att bygga den här plattformen är mindre kvantitativa och har mer att göra med hur arbetsflödena har förbättrats för både plattformsutvecklare och användare. Till exempel ersattes MinIO med direktåtkomst till Amazon S3, vilket flyttar oss närmare våra ursprungliga arbetsflöden och minskar antalet tjänster vi måste underhålla. Vi kan också använda Amazon RDS som backend för Kubeflow, vilket möjliggör enklare migrering mellan kluster och ger oss möjlighet att säkerhetskopiera våra pipelines varje natt.

Vi tyckte också att förbättringarna i Kubeflow-integrationen med AWS-hanterade tjänster var fördelaktiga. Till exempel, med Amazon RDS, Amazon S3 och Amazon Cognito förkonfigurerade i Kubeflow på AWS-manifesterna sparar vi tid och ansträngning på att uppdatera till nyare distributioner av Kubeflow. När vi brukade ändra de officiella Kubeflow-manifesterna manuellt, skulle uppdateringen till en ny version ta flera veckor, från design till testning.

Att byta till Amazon EKS ger oss möjlighet att definiera vårt kluster i Kustomize (nu en del av Kubectl) och Terraform. Det visar sig att för plattformsarbete är Kubernetes och Terraform mycket lätta att arbeta med efter att ha lagt ner tillräckligt med tid för att lära sig. Efter många iterationer gör de tillgängliga verktygen det mycket enkelt att utföra standardplattformsoperationer som att uppgradera en komponent eller byta ut ett helt utvecklingskluster. Jämfört med att köra jobb utan råa Amazon Elastic Compute Cloud (Amazon EC2) är det svårt att jämföra vilken enorm skillnad det gör att ha väldefinierade pods med garanterad resursrensning och mekanismer för återförsök inbyggda.

Kubernetes tillhandahåller utmärkta säkerhetsstandarder, och vi har bara skrapat på ytan av vad fleranvändarisoleringen tillåter oss att göra. Vi ser isolering av flera användare som ett mönster som ger mer utdelning i framtiden när utbildningsplattformen producerar data på produktionsnivå och vi tar in utvecklare utanför vårt team.

Samtidigt tillåter Kubeflow oss att ha reproducerbar modellträning. Även med samma data ger ingen utbildning identiska modeller, men vi har det näst bästa. Med Kubeflow vet vi exakt vilken kod och data som användes för att träna en modell. Onboarding har förbättrats avsevärt eftersom varje steg i vår pipeline är tydligt och programmatiskt definierat. När nya dataforskare har till uppgift att fixa en bugg behöver de mycket mindre handhavande eftersom det finns en tydlig struktur för hur utdata av kod används mellan stegen.

Att använda Kubeflow ger också många prestandaförbättringar jämfört med att köra på en enda EC2-instans. Ofta i modellträning behöver datavetare olika verktyg och optimeringar för förbearbetning och utbildning. Till exempel körs förbearbetning ofta med hjälp av distribuerade databearbetningsverktyg, som Spark, medan utbildning ofta körs med GPU-instanser. Med Kubeflow-pipelines kan de ange olika instanstyper för olika stadier i pipelinen. Detta gör att de kan använda de kraftfulla GPU-instanserna i ett steg och en flotta av mindre maskiner för distribuerad bearbetning i ett annat steg. Eftersom Kubeflow-pipelines beskriver beroenden mellan steg, kan pipelines köra steg parallellt.

Slutligen, eftersom vi skapade en process för att lägga till hyresgäster i klustret, finns det nu ett mer formellt sätt att registrera team till en hyresgäst i klustret. Eftersom vi använder Kubecost för att spåra kostnader i vårt EKS-kluster, tillåter det oss att hänföra kostnaden till ett enstaka projekt snarare än att ha kostnaden tillskriven på kontonivå, som inkluderar alla datavetenskapliga projekt. Kubecost presenterar en rapport över pengarna som spenderas per namnutrymme, som är tätt kopplad till hyresgästen eller teamet som ansvarar för att driva pipelinen.

Trots alla fördelar vill vi varna för att endast genomföra den här typen av migrering om det finns totalt inköp från användare. Användare som lägger ner tid får många fördelar av att använda Amazon EKS och Kubernetes, men det finns en betydande inlärningskurva.

Slutsats

Med implementeringen av Kubeflow på AWS-pipelinen i vår ML-infrastruktur helt till slut kunde vi konsolidera och standardisera våra datavetenskapliga arbetsflöden samtidigt som vi behöll våra viktiga verktyg (som CI/CD och modellservering). Våra dataforskare kan nu flytta mellan projekt baserat på detta arbetsflöde utan att behöva lära sig hur man underhåller en helt annan verktygsuppsättning. För några av våra modeller blev vi också positivt överraskade över hastigheten på det nya arbetsflödet (fem gånger snabbare), vilket möjliggjorde fler träningsupprepningar och följaktligen producera modeller med bättre förutsägelser.

Vi har också etablerat en solid grund för att utöka våra MLOps-kapaciteter och skala antalet och storleken på våra projekt. Till exempel, när vi skärper vår ledningsställning i modelllinje och spårning, har vi minskat vårt fokus från över 15 arbetsflöden till bara ett. Och när Log4shell-sårbarheten kom i dagen i slutet av 2021 kunde vi fokusera på ett enda arbetsflöde och snabbt åtgärda vid behov (utföra Amazon Elastic Container Registry (Amazon ECR) skanningar, uppgradering av Amazon OpenSearch Service, uppdatering av våra verktyg och mer) med minimal påverkan på det pågående arbetet av dataforskarna. När förbättringar av AWS och Kubeflow blir tillgängliga kan vi införliva dem som vi tycker är lämpliga.

Detta för oss till en viktig och diskret aspekt av vårt Kubeflow om AWS-antagande. Ett av de kritiska resultaten av denna resa är möjligheten att sömlöst lansera uppgraderingar och förbättringar av Kubeflow för våra datavetare. Även om vi diskuterade vår inställning till detta tidigare, förlitar vi oss också på Kubeflow-manifesterna från AWS. Vi startade vår Kubeflow-resa som ett proof of concept 2019, innan släppet av version 1.0.0. (Vi är för närvarande på 1.4.1 och utvärderar 1.5. AWS arbetar redan på version 1.6.) Under de mellanliggande 3 åren har det funnits minst sex utgåvor med betydande innehåll. Genom sitt disciplinerade tillvägagångssätt för att integrera och validera dessa uppgraderingar och släppa manifesten på ett förutsägbart, tillförlitligt schema, har Kubeflow-teamet på AWS varit avgörande för att göra det möjligt för athenahealth MLOps-teamet att planera vår utvecklingsfärdplan, och följaktligen våra resursallokeringar och fokusområden , längre in i framtiden med större självförtroende.

Du kan följa AWS Labs GitHub-förråd för att spåra alla AWS-bidrag till Kubeflow. Du kan också hitta AWS-team på Kubeflow #AWS Slack Channel; din feedback där hjälper AWS att prioritera nästa funktioner för att bidra till Kubeflow-projektet.

---

Om författarna

Kanwaljit Khurmi är Senior Solutions Architect på Amazon Web Services. Han arbetar med AWS-kunderna för att ge vägledning och teknisk assistans som hjälper dem att förbättra värdet av sina lösningar när de använder AWS. Kanwaljit är specialiserat på att hjälpa kunder med container- och maskininlärningsapplikationer.

Tyler Kalbach är en huvudmedlem i teknisk personal på athenahealth. Tyler har cirka 7 års erfarenhet av analys, datavetenskap, neurala nätverk och utveckling av applikationer för maskininlärning inom hälsovårdsområdet. Han har bidragit till flera Machine Learning-lösningar som för närvarande servar produktionstrafiken. Tyler arbetar för närvarande som huvuddataforskare i athenahealths ingenjörsorganisation och har varit en del av teamet som har byggt den nya utbildningsplattformen för maskininlärning för athenahealth från starten av det arbetet.

Victor Krylov är en huvudmedlem i teknisk personal på athenahealth. Victor är ingenjör och scrummaster som hjälper datavetare att bygga säkra snabba maskininlärningspipelines. Inom athenahealth har han arbetat med gränssnitt, klinisk beställning, recept, schemaläggning, analys och nu maskininlärning. Han värdesätter renskriven och väl enhetstestad kod, men har en ohälsosam besatthet av kod-one-liners. På fritiden lyssnar han gärna på poddar medan han går ut med sin hund.

Sasank Vemuri är en ledande medlem av teknisk personal på athenahealth. Han har erfarenhet av att arbeta med att utveckla datadrivna lösningar över domäner som sjukvård, försäkring och bioinformatik. Sasank arbetar för närvarande med att designa och utveckla utbildnings- och slutledningsplattformar för maskininlärning på AWS och Kubernetes som hjälper till med utbildning och implementering av ML-lösningar i stor skala.

Anu Tumkur är arkitekt på athenahealth. Anu har över två decennier av arkitektur, design, utvecklingserfarenhet av att bygga olika mjukvaruprodukter inom maskininlärning, molndrift, big data, realtidsdistribuerade datapipelines, annonsteknik, dataanalys, sociala medier-analyser. Anu arbetar för närvarande som arkitekt i athenahealths produktteknikorganisation på Machine Learning Platform och Data Pipeline-teamen.

William Tsen är Senior Engineering Manager på athenahealth. Han har över 20 års erfarenhet av ingenjörsledarskap i att bygga lösningar inom IT inom hälso- och sjukvård, distribuerad databehandling med stora data, intelligenta optiska nätverk, videoredigeringssystem i realtid, företagsprogramvara och försäkring för gruppsjukvård. William leder för närvarande två fantastiska team på athenahealth, Machine Learning Operations och DevOps ingenjörsteam, i Product Engineering-organisationen.