Bouw herhaalbare, veilige en uitbreidbare end-to-end machine learning-workflows met Kubeflow op AWS

Dit is een gastblogbericht geschreven in samenwerking met athenahealth.

athenahealth een toonaangevende leverancier van netwerkgebaseerde software en diensten voor medische groepen en gezondheidssystemen in het hele land. De elektronische medische dossiers, het inkomstencyclusbeheer en de tools voor patiëntbetrokkenheid bieden altijd en overal toegang, wat leidt tot betere financiële resultaten voor haar klanten en haar leveranciers in staat stelt zorg van betere kwaliteit te leveren.

Op het gebied van kunstmatige intelligentie (AI) gebruikt athenahealth datawetenschap en machine learning (ML) om bedrijfsprocessen te versnellen en aanbevelingen, voorspellingen en inzichten te bieden voor meerdere services. Vanaf de eerste implementatie in geautomatiseerde documentservices, het contactloos verwerken van miljoenen zorgverlener-patiëntdocumenten, tot het meer recente werk in virtuele assistenten en het verbeteren van de prestaties van de inkomstencyclus, blijft athenahealth AI toepassen om de efficiëntie, servicemogelijkheden en betere resultaten voor providers te stimuleren. en hun patiënten.

Deze blogpost laat zien hoe athenahealth gebruikt Kubeflow op AWS (een AWS-specifieke distributie van Kubeflow) om een ​​end-to-end data science-workflow te bouwen en te stroomlijnen die essentiële tooling behoudt, de operationele efficiëntie optimaliseert, de productiviteit van datawetenschappers verhoogt en de weg vrijmaakt om hun ML-mogelijkheden gemakkelijker uit te breiden.

Kubeflow is het open-source ML-platform dat is bedoeld om implementaties van ML-workflows op Kubernetes eenvoudig, draagbaar en schaalbaar te maken. Kubeflow bereikt dit door relevante open source-tools op te nemen die goed integreren met Kubernetes. Sommige van deze projecten omvatten Argo voor pijplijnorkestratie, Istio voor servicemesh, Jupyter voor notebooks, Spark, TensorBoard en Katib. Kubeflow Pipelines helpt bij het bouwen en implementeren van draagbare, schaalbare ML-workflows die stappen kunnen omvatten zoals gegevensextractie, voorverwerking, modeltraining en modelevaluatie in de vorm van herhaalbare pijplijnen.

AWS draagt ​​bij aan de open-source Kubeflow-gemeenschap door zijn eigen Kubeflow-distributie (genaamd Kubeflow op AWS) te bieden die organisaties zoals athenahealth helpt bij het bouwen van zeer betrouwbare, veilige, draagbare en schaalbare ML-workflows met verminderde operationele overhead door integratie met door AWS beheerde services. AWS biedt verschillende Kubeflow-implementatie-opties, zoals implementatie met Amazon Cognito, implementatie met Amazon relationele databaseservice (Amazon RDS) en Amazon eenvoudige opslagservice (Amazon S3) en vanille-implementatie. Voor details over service-integratie en beschikbare add-ons voor elk van deze opties, zie: Deployment.

Tegenwoordig biedt Kubeflow op AWS een duidelijk pad naar het gebruik van Kubeflow, aangevuld met de volgende AWS-services:

Veel AWS-klanten profiteren van de Kubeflow op AWS-distributie, waaronder athenahealth.

Hier bespreekt het athenahealth MLOps-team de uitdagingen die ze tegenkwamen en de oplossingen die ze tijdens hun Kubeflow-reis hebben gecreëerd.

Uitdagingen met de vorige ML-omgeving

Voorafgaand aan onze adoptie van Kubeflow op AWS, gebruikten onze datawetenschappers een gestandaardiseerde set tools en een proces dat flexibiliteit mogelijk maakte in de technologie en workflow die werden gebruikt om een ​​bepaald model te trainen. Voorbeelden van componenten van de gestandaardiseerde tooling zijn een API voor gegevensopname, tools voor het scannen van beveiliging, de CI/CD-pijplijn die is gebouwd en onderhouden door een ander team binnen athenahealth, en een gemeenschappelijk serviceplatform dat is gebouwd en onderhouden door het MLOps-team. Naarmate ons gebruik van AI en ML echter volwassener werd, groeide de verscheidenheid aan tools en infrastructuur die voor elk model werd gecreëerd. Hoewel we het bestaande proces nog konden ondersteunen, zagen we de volgende uitdagingen aan de horizon:

• Onderhoud en groei – Het reproduceren en onderhouden van modeltrainingsomgevingen kostte meer moeite naarmate het aantal ingezette modellen toenam. Elk project hield gedetailleerde documentatie bij waarin werd beschreven hoe elk script werd gebruikt om het uiteindelijke model te bouwen. In veel gevallen was dit een uitgebreid proces met 5 tot 10 scripts met elk verschillende outputs. Deze moesten handmatig worden bijgehouden met gedetailleerde instructies over hoe elke output in volgende processen zou worden gebruikt. Dit na verloop van tijd handhaven werd omslachtig. Bovendien, naarmate de projecten complexer werden, nam ook het aantal tools toe. De meeste modellen maakten bijvoorbeeld gebruik van Spark en TensorFlow met GPU's, wat een grotere verscheidenheid aan omgevingsconfiguraties vereiste. Na verloop van tijd schakelden gebruikers over naar nieuwere versies van tools in hun ontwikkelomgevingen, maar konden ze geen oudere scripts uitvoeren wanneer die versies incompatibel werden. Bijgevolg vergde het onderhouden en uitbreiden van oudere projecten meer engineeringtijd en -inspanning. Omdat nieuwe datawetenschappers zich bij het team voegden, namen kennisoverdracht en onboarding bovendien meer tijd in beslag, omdat het synchroniseren van lokale omgevingen veel ongedocumenteerde afhankelijkheden omvatte. Schakelen tussen projecten stuitte op dezelfde problemen omdat elk model zijn eigen workflows had.
• Security – We nemen beveiliging serieus en geven daarom prioriteit aan naleving van alle contractuele, wettelijke en regelgevende verplichtingen die verband houden met ML en datawetenschap. Gegevens moeten op specifieke manieren worden gebruikt, opgeslagen en geopend, en we hebben robuuste processen ingebouwd om ervoor te zorgen dat onze praktijken voldoen aan onze wettelijke verplichtingen en aansluiten bij de beste praktijken in de branche. Voordat Kubeflow werd geadopteerd, moest ervoor worden gezorgd dat gegevens op een specifieke manier werden opgeslagen en geopend. Dit betekende regelmatige verificatie in meerdere, diverse workflows. We wisten dat we de efficiëntie konden verbeteren door deze diverse workflows op één platform te consolideren. Dat platform zou echter flexibel genoeg moeten zijn om goed te integreren met onze gestandaardiseerde tooling.
• Operations – We zagen ook een kans om de operationele efficiëntie en het beheer te verhogen door de logging en monitoring van de workflows te centraliseren. Omdat elk team zijn eigen tools had ontwikkeld, hebben we deze informatie van elke workflow afzonderlijk verzameld en samengevoegd.

Het data science-team evalueerde verschillende oplossingen voor het consolideren van de workflows. Naast het aanpakken van deze vereisten, zochten we naar een oplossing die naadloos zou integreren met de bestaande gestandaardiseerde infrastructuur en tools. We hebben Amazon EKS en Kubeflow op AWS geselecteerd als onze workflowoplossing.

De ontwikkelingscyclus van datawetenschappers met Kubeflow

Een data science-project begint met een schone lei: geen data, geen code, alleen het zakelijke probleem dat met ML kan worden opgelost. De eerste taak is een proof of concept (POC) om te ontdekken of de gegevens voldoende signaal bevatten om een ​​ML-model effectief te maken bij het oplossen van het bedrijfsprobleem, te beginnen met het opvragen van de onbewerkte dataset uit ons Snowflake-datawarehouse. Deze fase is iteratief en de datawetenschappers gebruiken tijdens dit proces Kubernetes-pods of Kubeflow Jupyter-notebooks.

Ons Kubeflow-cluster maakt gebruik van de Karpenter-cluster-autoscaler, waardoor het voor datawetenschappers gemakkelijk wordt om resources te gebruiken, omdat ze zich alleen hoeven te concentreren op het definiëren van de gewenste instantietypen, terwijl het provisioningwerk wordt gedaan door een set vooraf gedefinieerde Karpenter-provisioners. We hebben afzonderlijke voorzieningen voor CPU- en GPU-instantietypen en alle instanties die worden ondersteund door Amazon EKS vallen in een van deze twee categorieën volgens onze voorzieningenconfiguratie. De datawetenschappers kiezen instantietypen met behulp van knooppuntselectors en Karpenter zorgt voor het levenscyclusbeheer van knooppunten.

Nadat de query is ontwikkeld, extraheren de datawetenschappers de onbewerkte gegevens naar een locatie op Amazon S3 en starten vervolgens een Jupyter-notebook vanuit de AWS Kubeflow-gebruikersinterface om de gegevens te verkennen. Het doel is om de functieset te maken die zal worden gebruikt om het eerste model te trainen. Hierdoor kunnen de datawetenschappers bepalen of er voldoende signaal in de data zit om aan de zakelijke behoefte van de klant te voldoen.

Nadat de resultaten bevredigend zijn, gaan de datawetenschappers naar de volgende fase van de ontwikkelingscyclus en zetten hun ontdekkingen om in een robuuste pijplijn. Ze zetten de POC-code om in code van productiekwaliteit die op grote schaal wordt uitgevoerd. Om naleving te garanderen door het gebruik van goedgekeurde bibliotheken, wordt een container gemaakt met de juiste basis Docker-image. Voor onze datawetenschappers hebben we geconstateerd dat het bieden van een standaard Python-, TensorFlow- en Spark-basisimage voldoende flexibiliteit biedt voor de meeste, zo niet alle, workloads. Vervolgens kunnen ze de Dockerfile van hun component gebruiken om hun ontwikkelomgeving verder aan te passen. Dit Dockerfile wordt vervolgens gebruikt door het CI/CD-proces om de image van de componenten te bouwen die in productie zal worden gebruikt, waardoor de consistentie tussen ontwikkelings- en productieomgevingen behouden blijft.

We hebben een tool waarmee datawetenschappers hun ontwikkelomgeving kunnen lanceren in een pod die op Kubernetes draait. Wanneer deze pod actief is, kunnen de gegevenswetenschappers de Visual Studio Code IDE rechtstreeks aan de pod koppelen en fouten opsporen in hun modelcode. Nadat ze de code succesvol hebben uitgevoerd, kunnen ze hun wijzigingen naar git pushen en wordt er een nieuwe ontwikkelomgeving gemaakt met de meest recente wijzigingen.

De standaard data science-pijplijn bestaat uit fasen die extractie, voorverwerking, training en evaluatie omvatten. Elke fase in de pijplijn wordt weergegeven als een onderdeel in Kubeflow, dat bestaat uit een Kubernetes-pod die een opdracht uitvoert met wat informatie die als parameters wordt doorgegeven. Deze parameters kunnen statische waarden zijn of verwijzingen naar uitvoer van een vorige component. De Docker-image die in de pod wordt gebruikt, is opgebouwd uit het CI/CD-proces. Details over dit proces worden weergegeven in de CI/CD-workflow die in de volgende sectie wordt besproken.

Ontwikkelingscyclus op Kubeflow. De ontwikkelworkflow begint aan de linkerkant met de POC. Het voltooide model wordt geïmplementeerd op het athenahealth-modelserviceplatform dat draait op Amazon ECS.

CI/CD-proces dat geautomatiseerde workflows ondersteunt

Als onderdeel van ons CI/CD-proces gebruiken we Jenkins om alle Kubeflow-componentafbeeldingen parallel te bouwen en te testen. Na succesvolle voltooiing bevat de sjabloon voor het pijplijnonderdeel referentieverwijzingen naar de afbeeldingen en wordt de resulterende pijplijn geüpload naar Kubeflow. Met parameters in de Jenkins-pijplijn kunnen gebruikers de pijplijnen starten en hun modeltrainingstests uitvoeren na succesvolle builds.

Als alternatief kunnen datawetenschappers, om een ​​korte ontwikkelingscyclus te behouden, de pijplijn ook lanceren vanaf hun lokale machine, waarbij ze de pijplijnparameters wijzigen waarmee ze experimenteren.

Er bestaat tooling om ervoor te zorgen dat de referentie-pointers van de CI/CD-build standaard worden gebruikt. Als er zich een inzetbaar artefact in de repo bevindt, zal de CI/CD-logica het artefact blijven implementeren op het athenahealth-modelserviceplatform (de Prediction Service) dat draait op Amazon ECS met AWS Fargate. Nadat al deze fasen zijn doorlopen, voegt de datawetenschapper de code samen met de primaire vertakking. De pijplijnen en inzetbare artefacten worden vervolgens naar productie gepusht.

Workflow voor CI/CD-implementatie. Dit diagram beschrijft de werkstroom voor het bouwen en implementeren van Data Science. Het CI/CD-proces wordt aangestuurd door: Jenkins.

Security

Door onze datawetenschap-workflows te consolideren, konden we onze aanpak voor het beveiligen van de trainingspijplijn centraliseren. In deze sectie bespreken we onze benadering van data- en clusterbeveiliging.

Gegevensbeveiliging

Gegevensbeveiliging is van het grootste belang bij athenahealth. Daarom ontwikkelen en onderhouden we een infrastructuur die volledig voldoet aan de regelgeving en standaarden die de veiligheid en integriteit van deze gegevens beschermen.

Om ervoor te zorgen dat we voldoen aan de normen voor gegevenscompliance, leveren we onze AWS-infrastructuur in overeenstemming met onze athenahealth-richtlijnen voor ondernemingen. De twee belangrijkste winkels voor gegevens zijn Amazon RDS voor zeer schaalbare pijplijnmetadata en Amazon S3 voor pijplijn- en modelartefacten. Voor Amazon S3 zorgen we ervoor dat de buckets worden versleuteld, HTTPS-eindpunten worden afgedwongen en dat het bucketbeleid en AWS Identiteits- en toegangsbeheer (IAM)-rollen volgen de principes van de minste bevoegdheden bij het verlenen van toegang tot de gegevens. Dit geldt ook voor Amazon RDS-gegevens: codering is altijd ingeschakeld en de beveiligingsgroepen en referentietoegang volgen het principe van de minste bevoegdheden. Deze standaardisatie zorgt ervoor dat alleen geautoriseerde partijen toegang hebben tot de gegevens en deze toegang wordt bijgehouden.

Naast deze maatregelen ondergaat het platform ook security threat assessments en continue security en compliance scans.

We pakken ook de vereisten voor het bewaren van gegevens aan via gegevenslevenscyclusbeheer voor alle S3-buckets die gevoelige gegevens bevatten. Dit beleid verplaatst gegevens automatisch naar: Amazon S3-gletsjer na 30 dagen van creatie. Uitzonderingen hierop worden beheerd via verzoeken om gegevens op te halen en worden per geval goedgekeurd of geweigerd. Dit zorgt ervoor dat alle workflows voldoen aan het beleid voor het bewaren van gegevens. Dit lost ook het probleem op met het herstellen van gegevens als een model slecht presteert en omscholing vereist is, of wanneer een nieuw model moet worden geëvalueerd aan de hand van een historische iteratie van de dataset van een ouder model.

Voor het beperken van toegang tot Amazon S3 en Amazon RDS vanuit Kubeflow op AWS en Amazon EKS, gebruiken we IRSA (IAM Roles for Service Accounts), dat op IAM gebaseerde machtigingsverlening biedt voor bronnen binnen Kubernetes. Elke tenant in Kubeflow heeft een uniek vooraf gemaakt serviceaccount dat we binden aan een IAM-rol die speciaal is gemaakt om te voldoen aan de toegangsvereisten voor tenants. Gebruikerstoegang tot tenants is ook beperkt met het Amazon Cognito-groepslidmaatschap voor gebruikerspools voor elke gebruiker. Wanneer een gebruiker is geverifieerd bij het cluster, bevat het gegenereerde token groepsclaims en Kubernetes RBAC gebruikt deze informatie om toegang tot een bepaalde resource in het cluster toe te staan ​​of te weigeren. Deze opstelling wordt in de volgende sectie in meer detail uitgelegd.

Clusterbeveiliging met isolatie voor meerdere gebruikers

Zoals we in de vorige sectie hebben opgemerkt, voeren datawetenschappers verkennende data-analyses uit, voeren ze data-analyses uit en trainen ze ML-modellen. Om resources toe te wijzen, gegevens te organiseren en workflows te beheren op basis van projecten, biedt Kubeflow op AWS isolatie op basis van Kubernetes-naamruimten. Deze isolatie werkt voor interactie met de Kubeflow-gebruikersinterface; het biedt echter geen hulpprogramma's om de toegang tot de Kubernetes-API te beheren met Kubectl. Dit betekent dat gebruikerstoegang kan worden beheerd in de Kubeflow-gebruikersinterface, maar niet via de Kubernetes-API via Kubectl.

De architectuur die in het volgende diagram wordt beschreven, lost dit probleem op door de toegang tot projecten in Kubeflow te verenigen op basis van groepslidmaatschappen. Om dit te bereiken, hebben we gebruik gemaakt van de Kubeflow op AWS-manifesten, die zijn geïntegreerd met Amazon Cognito-gebruikerspools. Daarnaast gebruiken we Kubernetes role-based access control (RBAC) om autorisatie binnen het cluster te beheren. De gebruikersrechten worden geleverd op basis van het Amazon Cognito-groepslidmaatschap. Deze informatie wordt doorgegeven aan het cluster met het token dat is gegenereerd door de OIDC-client. Dit proces is vereenvoudigd dankzij de ingebouwde Amazon EKS-functionaliteit waarmee geassocieerde OIDC-identiteitsproviders zich kunnen verifiëren bij het cluster.

Amazon EKS-authenticatie wordt standaard uitgevoerd door de IAM-authenticator, een tool die authenticatie met een EKS-cluster mogelijk maakt met behulp van IAM-referenties. Deze authenticatiemethode heeft zijn voordelen; het is echter niet geschikt voor onze use case, omdat athenahealth Microsoft Azure Active Directory gebruikt voor identiteitsservice in de hele organisatie.

Kubernetes-naamruimte-isolatie. Data Scientists kunnen lid worden van een enkele of meerdere groepen als dat nodig is voor hun werk. De toegang wordt regelmatig beoordeeld en indien nodig verwijderd.

Azure Active Directory, een bedrijfsbrede identiteitsservice, is de bron van waarheid voor het beheren van gebruikerstoegang tot het Kubeflow-cluster. De setup hiervoor omvat het maken van een Azure Enterprise-toepassing die fungeert als service-principal en het toevoegen van groepen voor verschillende tenants die toegang tot het cluster nodig hebben. Deze configuratie op Azure wordt gespiegeld in Amazon Cognito door een federatieve OIDC-identiteitsprovider in te stellen die de verificatieverantwoordelijkheid uitbesteedt aan Azure. De toegang tot Azure-groepen wordt beheerd door SailPoint IdentityIQ, dat toegangsaanvragen naar de projecteigenaar verzendt om deze toe te staan ​​of te weigeren. In de Amazon Cognito-gebruikerspool worden twee toepassingsclients gemaakt: de ene wordt gebruikt om de verificatie voor het Kubernetes-cluster in te stellen met behulp van de OIDC-identiteitsprovider en de andere om Kubeflow-verificatie in de Kubeflow-gebruikersinterface te beveiligen. Deze clients zijn geconfigureerd om groepsclaims door te geven bij verificatie met het cluster, en deze groepsclaims worden naast RBAC gebruikt om autorisatie binnen het cluster in te stellen.

Kubernetes RBAC-rolbindingen worden ingesteld tussen groepen en de clusterrol Kubeflow-edit, die wordt gemaakt bij het installeren van Kubeflow in het cluster. Deze rolbinding zorgt ervoor dat elke gebruiker die interactie heeft met het cluster nadat hij zich heeft aangemeld via OIDC, toegang heeft tot de naamruimten waarvoor ze machtigingen hebben, zoals gedefinieerd in hun groepsclaims. Hoewel dit werkt voor gebruikers die interactie hebben met het cluster met behulp van Kubectl, biedt de Kubeflow-gebruikersinterface momenteel geen toegang aan gebruikers op basis van groepslidmaatschap omdat er geen RBAC wordt gebruikt. In plaats daarvan gebruikt het de Istio Authorization Policy-bron om de toegang voor gebruikers te regelen. Om deze uitdaging te overwinnen, hebben we een aangepaste controller ontwikkeld die gebruikers synchroniseert door Amazon Cognito-groepen te pollen en overeenkomstige rolbindingen voor elke gebruiker toe te voegen of te verwijderen in plaats van per groep. Met deze configuratie kunnen gebruikers hetzelfde machtigingsniveau hebben bij interactie met zowel de Kubeflow-gebruikersinterface als Kubectl.

Operationele efficiëntie

In deze sectie bespreken we hoe we gebruik hebben gemaakt van de open source- en AWS-tools die voor ons beschikbaar zijn om onze workflows te beheren en te debuggen en om de operationele impact van het upgraden van Kubeflow te minimaliseren.

Logboekregistratie en monitoring

Voor logboekregistratie gebruiken we FluentD om al onze containerlogboeken te pushen naar: Amazon OpenSearch-service en systeemstatistieken naar Prometheus. Vervolgens gebruiken we Kibana en de Grafana UI voor het zoeken en filteren van logs en metrics. In het volgende schema wordt beschreven hoe we dit hebben opgezet.

Kubeflow-logboekregistratie. We gebruiken zowel Grafana UI als Kibana om de logs te bekijken en te doorzoeken

De volgende schermafbeelding is een Kibana UI-weergave uit onze pijplijn.

Voorbeeld Kibana UI-weergave. Kibana maakt aangepaste weergaven mogelijk.

Veilige upgrades van Kubeflow-clusters

Terwijl we gebruikers aan Kubeflow on AWS toelaten, behouden we een betrouwbare en consistente gebruikerservaring, terwijl het MLOps-team flexibel kan blijven met het vrijgeven en integreren van nieuwe functies. Op het eerste gezicht lijkt Kustomize voor ons modulair om het werken en upgraden van één component tegelijk mogelijk te maken zonder anderen te beïnvloeden, waardoor we nieuwe mogelijkheden kunnen toevoegen met minimale verstoring voor de gebruikers. In de praktijk zijn er echter scenario's waarbij de beste aanpak is om gewoon een nieuw Kubernetes-cluster op te starten in plaats van upgrades op componentniveau toe te passen voor bestaande clusters. We hebben twee use-cases gevonden waarin het logischer was om volledig nieuwe clusters te maken:

• Upgraden naar een Kubernetes-versie waarbij AWS wel in-place clusterupgrades biedt. Het wordt echter moeilijk om te testen of alle Kubeflow- en Kubernetes-resources werken zoals bedoeld en of de manifesten achterwaartse compatibiliteit behouden.
• Kubeflow upgraden naar een nieuwere release waar verschillende functies zijn toegevoegd of gewijzigd en het is bijna altijd geen veelbelovend idee om in-place upgrades uit te voeren op een bestaand Kubernetes-cluster.

Om dit probleem aan te pakken, hebben we een strategie ontwikkeld waarmee we veilige clustervervangingen kunnen uitvoeren zonder bestaande workloads te beïnvloeden. Om dit te bereiken moesten we aan de volgende criteria voldoen:

• Scheid de Kubeflow-opslag en rekenresources zodat de pijplijnmetagegevens, pijplijnartefacten en gebruikersgegevens behouden blijven bij het uitschrijven van het oudere cluster
• Integreer met Kubeflow op AWS-manifesten, zodat bij een upgrade van de Kubeflow-versie minimale wijzigingen nodig zijn
• Een moeiteloze manier om terug te draaien als er iets misgaat na een clusterupgrade
• Een eenvoudige interface hebben om een ​​kandidaatcluster naar productie te promoveren

Het volgende diagram illustreert deze architectuur.

Veilige upgrade van Kubeflow-cluster. Zodra het testen van de Kubeflow Candidate succesvol is, wordt deze gepromoveerd naar Kubeflow Prod via een update naar Route 53.

Kubeflow op AWS-manifesten zijn voorverpakt met Amazon RDS- en Amazon S3-integraties. Met deze beheerde services die fungeren als gemeenschappelijke gegevensopslag, kunnen we een blauwgroene implementatiestrategie opzetten. Om dit te bereiken, hebben we ervoor gezorgd dat de metagegevens van de pijplijn worden bewaard in Amazon RDS, dat onafhankelijk van het EKS-cluster werkt, en dat de pijplijnlogboeken en artefacten worden bewaard in Amazon S3. Naast metadata en artefacten van pijplijnen, hebben we FluentD ook ingesteld om pod-logboeken naar Amazon OpenSearch Service te routeren.

Dit zorgt ervoor dat de opslaglaag volledig is gescheiden van de rekenlaag en maakt het mogelijk om wijzigingen te testen tijdens Kubeflow-versie-updates op een volledig nieuw EKS-cluster. Nadat alle tests zijn geslaagd, kunnen we eenvoudig de Amazon Route 53 DNS-record naar het kandidaatcluster dat Kubeflow host. We laten het oude cluster ook een paar dagen draaien als back-up voor het geval we het moeten terugdraaien.

Voordelen van Amazon EKS en Kubeflow op AWS voor onze ML-pijplijn

Amazon EKS en het Kubeflow on AWS-pakket hebben onze ontwikkelingsworkflow verplaatst naar een patroon dat herhaalbare modeltraining sterk aanmoedigt. Met deze tools kunnen we volledig gedefinieerde clusters hebben met volledig gedefinieerde tenants en volledig gedefinieerde code uitvoeren.

Veel overwinningen van het bouwen van dit platform zijn minder kwantitatief en hebben meer te maken met hoe de workflows zijn verbeterd voor zowel platformontwikkelaars als gebruikers. Zo werd MinIO vervangen door directe toegang tot Amazon S3, waardoor we dichter bij onze oorspronkelijke workflows komen en het aantal services dat we moeten onderhouden, verminderen. We kunnen Amazon RDS ook gebruiken als backend voor Kubeflow, wat gemakkelijkere migraties tussen clusters mogelijk maakt en ons de mogelijkheid geeft om elke nacht een back-up van onze pijplijnen te maken.

We vonden ook de verbeteringen in de Kubeflow-integratie met AWS-beheerde services nuttig. Als Amazon RDS, Amazon S3 en Amazon Cognito bijvoorbeeld vooraf zijn geconfigureerd in de Kubeflow op AWS-manifesten, besparen we tijd en moeite bij het updaten naar nieuwere distributies van Kubeflow. Toen we de officiële Kubeflow-manifesten handmatig aanpasten, duurde het updaten naar een nieuwe versie enkele weken, van ontwerp tot testen.

Overstappen naar Amazon EKS geeft ons de mogelijkheid om ons cluster in Kustomize (nu onderdeel van Kubectl) en Terraform te definiëren. Het blijkt dat Kubernetes en Terraform voor platformwerk heel gemakkelijk zijn om mee te werken nadat ze voldoende tijd hebben gestoken om te leren. Na vele iteraties maken de tools die ons ter beschikking staan ​​het zeer eenvoudig om standaard platformbewerkingen uit te voeren, zoals het upgraden van een component of het omwisselen van een volledig ontwikkelingscluster. Vergeleken met het uitvoeren van onbewerkte banen Amazon Elastic Compute-cloud (Amazon EC2), is het moeilijk te vergelijken wat een enorm verschil het maakt om goed gedefinieerde pods te hebben met gegarandeerde mechanismen voor het opschonen van bronnen en het opnieuw proberen.

Kubernetes biedt uitstekende beveiligingsstandaarden en we hebben nog maar het oppervlak bekrast van wat de multi-user isolatie ons in staat stelt te doen. We zien isolatie van meerdere gebruikers als een patroon dat in de toekomst meer vruchten afwerpt wanneer het trainingsplatform gegevens op productieniveau produceert, en we brengen ontwikkelaars van buiten ons team aan.

Ondertussen stelt Kubeflow ons in staat om reproduceerbare modeltraining te hebben. Zelfs met dezelfde gegevens levert geen enkele training identieke modellen op, maar we hebben het op één na beste. Met Kubeflow weten we precies met welke code en data een model is getraind. De onboarding is enorm verbeterd omdat elke stap in onze pijplijn duidelijk en programmatisch is gedefinieerd. Wanneer nieuwe datawetenschappers de taak hebben om een ​​bug te repareren, hebben ze veel minder handholding nodig omdat er een duidelijke structuur is voor hoe de output van code tussen fasen wordt gebruikt.

Het gebruik van Kubeflow levert ook veel prestatieverbeteringen op in vergelijking met het draaien op een enkele EC2-instantie. Vaak hebben datawetenschappers bij modeltraining verschillende tools en optimalisaties nodig voor preprocessing en training. Voorverwerking wordt bijvoorbeeld vaak uitgevoerd met behulp van gedistribueerde gegevensverwerkingstools, zoals Spark, terwijl training vaak wordt uitgevoerd met GPU-instanties. Met Kubeflow-pijplijnen kunnen ze verschillende instantietypen opgeven voor verschillende fasen in de pijplijn. Hierdoor kunnen ze de krachtige GPU-instanties in één fase gebruiken en een vloot van kleinere machines voor gedistribueerde verwerking in een andere fase. Omdat Kubeflow-pijplijnen de afhankelijkheden tussen fasen beschrijven, kunnen de pijplijnen bovendien fasen parallel uitvoeren.

Omdat we ten slotte een proces hebben gemaakt voor het toevoegen van tenants aan het cluster, is er nu een meer formele manier om teams te registreren bij een tenant op het cluster. Omdat we Kubecost gebruiken om de kosten in ons EKS-cluster bij te houden, kunnen we kosten toewijzen aan een enkel project in plaats van dat kosten worden toegeschreven op accountniveau, dat alle datawetenschapsprojecten omvat. Kubecost presenteert een rapport van het uitgegeven geld per naamruimte, dat nauw is gekoppeld aan de huurder of het team dat verantwoordelijk is voor het runnen van de pijplijn.

Ondanks alle voordelen, raden we aan om dit soort migratie alleen uit te voeren als gebruikers er volledig achter staan. Gebruikers die er tijd in steken, halen veel voordelen uit het gebruik van Amazon EKS en Kubernetes, maar er is een aanzienlijke leercurve.

Conclusie

Met de implementatie van de Kubeflow op AWS-pijplijn in onze end-to-end ML-infrastructuur, konden we onze datawetenschapsworkflows consolideren en standaardiseren met behoud van onze essentiële tooling (zoals CI/CD en modelserving). Onze datawetenschappers kunnen nu schakelen tussen projecten op basis van deze workflow zonder de overhead van het leren onderhouden van een compleet andere toolset. Voor sommige van onze modellen waren we ook aangenaam verrast door de snelheid van de nieuwe workflow (vijf keer sneller), waardoor meer trainingsiteraties mogelijk waren en bijgevolg modellen met betere voorspellingen konden worden geproduceerd.

We hebben ook een solide basis gelegd om onze MLOps-mogelijkheden te vergroten en het aantal en de omvang van onze projecten te schalen. Omdat we bijvoorbeeld onze bestuurshouding in modelafstamming en -tracking aanscherpen, hebben we onze focus teruggebracht van meer dan 15 workflows naar slechts één. En toen de Log4shell-kwetsbaarheid eind 2021 aan het licht kwam, konden we ons concentreren op een enkele workflow en snel corrigeren waar nodig (het uitvoeren van Amazon Elastic Container-register (Amazon ECR) scans, het upgraden van Amazon OpenSearch Service, het updaten van onze tooling en meer) met minimale impact op het lopende werk van de datawetenschappers. Naarmate AWS- en Kubeflow-verbeteringen beschikbaar komen, kunnen we deze naar eigen goeddunken opnemen.

Dit brengt ons bij een belangrijk en ingetogen aspect van onze Kubeflow op AWS-adoptie. Een van de cruciale resultaten van deze reis is de mogelijkheid om upgrades en verbeteringen aan Kubeflow naadloos uit te rollen voor onze datawetenschappers. Hoewel we onze aanpak hiervoor eerder hebben besproken, vertrouwen we ook op de Kubeflow-manifesten die door AWS worden geleverd. We begonnen onze Kubeflow-reis als een proof of concept in 2019, voorafgaand aan de release van versie 1.0.0. (We zijn momenteel bezig met 1.4.1 en evalueren 1.5. AWS werkt al aan versie 1.6.) In de tussenliggende 3 jaar zijn er minstens zes releases geweest met substantiële inhoud. Door hun gedisciplineerde aanpak bij het integreren en valideren van deze upgrades en het vrijgeven van de manifesten volgens een voorspelbaar, betrouwbaar schema, is het Kubeflow-team van AWS van cruciaal belang geweest om het athenahealth MLOps-team in staat te stellen onze ontwikkelingsroutekaart te plannen, en bijgevolg onze toewijzing van middelen en aandachtsgebieden , verder in de toekomst met meer vertrouwen.

Je kunt het volgen AWS Labs GitHub-repository om alle AWS-bijdragen aan Kubeflow bij te houden. U kunt AWS-teams ook vinden op de Kubeflow #AWS Slack-kanaal; uw feedback daar helpt AWS bij het prioriteren van de volgende functies om bij te dragen aan het Kubeflow-project.

---

Over de auteurs

Kanwaljit Khurmi is Senior Solutions Architect bij Amazon Web Services. Hij werkt samen met de AWS-klanten om begeleiding en technische assistentie te bieden om hen te helpen de waarde van hun oplossingen te verbeteren bij het gebruik van AWS. Kanwaljit is gespecialiseerd in het helpen van klanten met toepassingen in containers en machine learning.

Tyler Kalbach is een hoofdlid van de technische staf bij athenahealth. Tyler heeft ongeveer 7 jaar ervaring in Analytics, Data Science, Neural Networks en de ontwikkeling van Machine Learning-toepassingen in de gezondheidszorg. Hij heeft bijgedragen aan verschillende Machine Learning-oplossingen die momenteel het productieverkeer bedienen. Tyler werkt momenteel als Principal Data Scientist bij de Engineering-organisatie van athenahealth en maakt vanaf het begin deel uit van het team dat het nieuwe Machine Learning Training Platform voor athenahealth heeft gebouwd.

Victor Krilov is een hoofdlid van de technische staf bij athenahealth. Victor is een ingenieur en scrummaster die datawetenschappers helpt bij het bouwen van veilige, snelle machine learning-pijplijnen. In athenahealth heeft hij gewerkt aan interfaces, klinische ordening, voorschriften, planning, analyse en nu machine learning. Hij hecht waarde aan netjes geschreven en goed geteste code, maar heeft een ongezonde obsessie met code-oneliners. In zijn vrije tijd luistert hij graag naar podcasts tijdens het uitlaten van zijn hond.

Sasank Vemuri is een hoofdlid van de technische staf bij athenahealth. Hij heeft ervaring met het ontwikkelen van datagedreven oplossingen in domeinen zoals gezondheidszorg, verzekeringen en bio-informatica. Sasank werkt momenteel aan het ontwerpen en ontwikkelen van machine learning-trainingen en inferentieplatforms op AWS en Kubernetes die helpen bij het trainen en implementeren van ML-oplossingen op grote schaal.

Anu Tumkuro is architect bij athenahealth. Anu heeft meer dan twee decennia ervaring op het gebied van architectuur, ontwerp en ontwikkeling met het bouwen van verschillende softwareproducten op het gebied van machine learning, cloudbewerkingen, big data, realtime gedistribueerde gegevenspijplijnen, advertentietechnologie, gegevensanalyse en sociale media-analyse. Anu werkt momenteel als architect in de Product Engineering-organisatie van athenahealth in de Machine Learning Platform- en Data Pipeline-teams.

Willem Tsen is Senior Engineering Manager bij athenahealth. Hij heeft meer dan 20 jaar ervaring als technisch leider in het bouwen van oplossingen in IT voor de gezondheidszorg, big data gedistribueerde computing, intelligente optische netwerken, realtime videobewerkingssystemen, bedrijfssoftware en groepsverzekeringen. William leidt momenteel twee geweldige teams bij athenahealth, de Machine Learning Operations- en DevOps-engineeringteams, in de Product Engineering-organisatie.