Crea flussi di lavoro di machine learning end-to-end ripetibili, sicuri ed estensibili utilizzando Kubeflow su AWS

Questo è un post sul blog degli ospiti scritto in collaborazione con athenahealth.

athenahealth un fornitore leader di software e servizi abilitati alla rete per gruppi medici e sistemi sanitari a livello nazionale. Le sue cartelle cliniche elettroniche, la gestione del ciclo delle entrate e gli strumenti di coinvolgimento dei pazienti consentono l'accesso in qualsiasi momento e ovunque, portando risultati finanziari migliori per i propri clienti e consentendo ai clienti fornitori di fornire cure di qualità migliore.

Nello spazio dell'intelligenza artificiale (AI), athenahealth utilizza la scienza dei dati e l'apprendimento automatico (ML) per accelerare i processi aziendali e fornire consigli, previsioni e approfondimenti su più servizi. Dalla sua prima implementazione nei servizi documentali automatizzati, all'elaborazione touchless di milioni di documenti fornitore-paziente, al suo lavoro più recente negli assistenti virtuali e al miglioramento delle prestazioni del ciclo delle entrate, athenahealth continua ad applicare l'IA per favorire l'efficienza, le capacità del servizio e risultati migliori per i fornitori e i loro pazienti.

Questo post sul blog mostra come utilizza athenahealth Kubeflow su AWS (una distribuzione di Kubeflow specifica per AWS) per creare e ottimizzare un flusso di lavoro di data science end-to-end che preserva gli strumenti essenziali, ottimizza l'efficienza operativa, aumenta la produttività dei data scientist e pone le basi per estendere più facilmente le loro capacità di ML.

Kubeflow è la piattaforma ML open source dedicata alla distribuzione di flussi di lavoro ML su Kubernetes in modo semplice, portatile e scalabile. Kubeflow raggiunge questo obiettivo incorporando strumenti open source pertinenti che si integrano bene con Kubernetes. Alcuni di questi progetti includono Argo per l'orchestrazione della pipeline, Istio per service mesh, Jupyter per notebook, Spark, TensorBoard e Katib. Kubeflow Pipelines aiuta a creare e distribuire flussi di lavoro ML scalabili e portatili che possono includere passaggi come l'estrazione dei dati, la preelaborazione, l'addestramento del modello e la valutazione del modello sotto forma di pipeline ripetibili.

AWS sta contribuendo alla comunità Kubeflow open source fornendo la propria distribuzione Kubeflow (denominata Kubeflow su AWS) che aiuta organizzazioni come athenahealth a creare flussi di lavoro ML altamente affidabili, sicuri, portatili e scalabili con un sovraccarico operativo ridotto grazie all'integrazione con i servizi gestiti da AWS. AWS fornisce varie opzioni di distribuzione Kubeflow come la distribuzione con Amazzonia Cognito, distribuzione con Servizio di database relazionale Amazon (Amazon RDS) e Servizio di archiviazione semplice Amazon (Amazon S3) e distribuzione vanilla. Per i dettagli sull'integrazione del servizio e sui componenti aggiuntivi disponibili per ciascuna di queste opzioni, fare riferimento a Distribuzione.

Oggi, Kubeflow su AWS offre un percorso chiaro per l'utilizzo di Kubeflow, ampliato con i seguenti servizi AWS:

Molti clienti AWS stanno sfruttando la distribuzione Kubeflow su AWS, incluso athenahealth.

Qui, il team di athenahealth MLOps discute le sfide incontrate e le soluzioni che hanno creato nel loro percorso Kubeflow.

Sfide con il precedente ambiente ML

Prima dell'adozione di Kubeflow su AWS, i nostri data scientist utilizzavano un set standardizzato di strumenti e un processo che consentiva flessibilità nella tecnologia e nel flusso di lavoro utilizzati per addestrare un determinato modello. I componenti di esempio degli strumenti standardizzati includono un'API di importazione dei dati, strumenti di scansione della sicurezza, la pipeline CI/CD creata e gestita da un altro team all'interno di athenahealth e una piattaforma di servizio comune creata e gestita dal team MLOps. Tuttavia, con la maturazione del nostro uso di IA e ML, la varietà di strumenti e infrastrutture creati per ciascun modello è cresciuta. Sebbene fossimo ancora in grado di supportare il processo esistente, vedevamo all'orizzonte le seguenti sfide:

• Manutenzione e crescita – La riproduzione e la manutenzione degli ambienti di addestramento dei modelli ha richiesto uno sforzo maggiore con l'aumento del numero di modelli distribuiti. Ogni progetto ha mantenuto una documentazione dettagliata che ha delineato come ogni script è stato utilizzato per costruire il modello finale. In molti casi, si trattava di un processo elaborato che coinvolgeva da 5 a 10 script con diversi output ciascuno. Questi dovevano essere tracciati manualmente con istruzioni dettagliate su come ciascun output sarebbe stato utilizzato nei processi successivi. Mantenerlo nel tempo è diventato ingombrante. Inoltre, man mano che i progetti diventavano più complessi, aumentava anche il numero di strumenti. Ad esempio, la maggior parte dei modelli utilizzava Spark e TensorFlow con GPU, che richiedevano una più ampia varietà di configurazioni dell'ambiente. Nel corso del tempo, gli utenti passavano a versioni più recenti degli strumenti nei loro ambienti di sviluppo, ma non potevano eseguire script precedenti quando tali versioni diventavano incompatibili. Di conseguenza, il mantenimento e l'aumento dei progetti più vecchi richiedeva più tempo e impegno di progettazione. Inoltre, quando nuovi data scientist si sono uniti al team, il trasferimento delle conoscenze e l'onboarding hanno richiesto più tempo, perché la sincronizzazione degli ambienti locali includeva molte dipendenze non documentate. Il passaggio da un progetto all'altro presentava gli stessi problemi perché ogni modello aveva i propri flussi di lavoro.
• Sicurezza – Prendiamo sul serio la sicurezza e pertanto diamo la priorità al rispetto di tutti gli obblighi contrattuali, legali e normativi associati al ML e alla scienza dei dati. I dati devono essere utilizzati, archiviati e accessibili in modi specifici e abbiamo integrato solidi processi per garantire che le nostre pratiche rispettino i nostri obblighi legali e si allineino con le migliori pratiche del settore. Prima dell'adozione di Kubeflow, garantire che i dati fossero archiviati e accessibili in un modo specifico prevedeva una verifica regolare su flussi di lavoro multipli e diversificati. Sapevamo che avremmo potuto migliorare l'efficienza consolidando questi diversi flussi di lavoro su un'unica piattaforma. Tuttavia, tale piattaforma dovrebbe essere sufficientemente flessibile da integrarsi bene con i nostri strumenti standardizzati.
• Operazioni – Abbiamo anche visto un'opportunità per aumentare l'efficienza operativa e la gestione attraverso la centralizzazione della registrazione e del monitoraggio dei flussi di lavoro. Poiché ogni team ha sviluppato i propri strumenti, abbiamo raccolto queste informazioni da ciascun flusso di lavoro individualmente e le abbiamo aggregate.

Il team di data science ha valutato varie soluzioni per consolidare i flussi di lavoro. Oltre a soddisfare questi requisiti, abbiamo cercato una soluzione che si integrasse perfettamente con l'infrastruttura e gli strumenti standardizzati esistenti. Abbiamo selezionato Amazon EKS e Kubeflow su AWS come nostra soluzione per il flusso di lavoro.

Il ciclo di sviluppo del data scientist che incorpora Kubeflow

Un progetto di data science inizia con una tabula rasa: nessun dato, nessun codice, solo il problema aziendale che può essere risolto con ML. La prima attività è una prova di concetto (POC) per scoprire se i dati contengono un segnale sufficiente per rendere un modello ML efficace nella risoluzione del problema aziendale, a partire dall'interrogazione del set di dati non elaborato dal nostro data warehouse di Snowflake. Questa fase è iterativa e i data scientist utilizzano i pod Kubernetes o i notebook Kubeflow Jupyter durante questo processo.

Il nostro cluster Kubeflow utilizza l'autoscaler del cluster Karpenter, che semplifica la creazione di risorse per i data scientist perché devono concentrarsi solo sulla definizione dei tipi di istanza desiderati, mentre il lavoro di provisioning viene svolto da una serie di provisioner Karpenter predefiniti. Disponiamo di provisioner separati per i tipi di istanza CPU e GPU e tutte le istanze supportate da Amazon EKS rientrano in una di queste due categorie secondo la nostra configurazione del provisioner. I data scientist scelgono i tipi di istanza utilizzando i selettori di nodi e Karpenter si occupa della gestione del ciclo di vita dei nodi.

Dopo lo sviluppo della query, i data scientist estraggono i dati grezzi in una posizione su Amazon S3, quindi avviano un notebook Jupyter dall'interfaccia utente di AWS Kubeflow per esplorare i dati. L'obiettivo è creare il set di funzionalità che verrà utilizzato per addestrare il primo modello. Ciò consente ai data scientist di determinare se nei dati è presente un segnale sufficiente per soddisfare le esigenze aziendali del cliente.

Dopo che i risultati sono soddisfacenti, i data scientist passano alla fase successiva del ciclo di sviluppo e trasformano le loro scoperte in una solida pipeline. Convertono il codice POC in codice di qualità di produzione che viene eseguito su larga scala. Per garantire la conformità tramite l'utilizzo di librerie approvate, viene creato un contenitore con l'immagine Docker di base appropriata. Per i nostri data scientist, abbiamo scoperto che la fornitura di un'immagine di base Python, TensorFlow e Spark standard offre una flessibilità sufficiente per la maggior parte, se non per tutti, i carichi di lavoro. Possono quindi utilizzare il Dockerfile del loro componente per personalizzare ulteriormente il loro ambiente di sviluppo. Questo Dockerfile viene quindi utilizzato dal processo CI/CD per creare l'immagine dei componenti che verrà utilizzata nella produzione, mantenendo quindi la coerenza tra gli ambienti di sviluppo e produzione.

Abbiamo uno strumento che offre ai data scientist la possibilità di avviare il proprio ambiente di sviluppo in un pod in esecuzione su Kubernetes. Quando questo pod è in esecuzione, i data scientist possono quindi collegare l'IDE del codice di Visual Studio direttamente al pod ed eseguire il debug del codice del modello. Dopo aver eseguito correttamente il codice, possono quindi inviare le modifiche a git e viene creato un nuovo ambiente di sviluppo con le modifiche più recenti.

La pipeline standard di data science è composta da fasi che includono estrazione, preelaborazione, formazione e valutazione. Ogni fase della pipeline viene visualizzata come componente in Kubeflow, che consiste in un pod Kubernetes che esegue un comando con alcune informazioni passate come parametri. Questi parametri possono essere valori statici o riferimenti all'output di un componente precedente. L'immagine Docker utilizzata nel pod è creata dal processo CI/CD. I dettagli su questo processo vengono visualizzati nel flusso di lavoro CI/CD discusso nella sezione successiva.

Ciclo di sviluppo su Kubeflow. Il flusso di lavoro di sviluppo inizia a sinistra con il POC. Il modello completato viene distribuito sulla piattaforma di servizio del modello athenahealth in esecuzione su Amazon ECS.

Processo CI/CD che supporta flussi di lavoro automatizzati

Come parte del nostro processo CI/CD, utilizziamo Jenkins per creare e testare tutte le immagini dei componenti Kubeflow in parallelo. In caso di completamento, il modello del componente della pipeline contiene i puntatori di riferimento alle immagini e la pipeline risultante viene caricata su Kubeflow. I parametri nella pipeline Jenkins consentono agli utenti di avviare le pipeline ed eseguire i test di addestramento del modello dopo le build riuscite.

In alternativa, per mantenere un breve ciclo di sviluppo, i data scientist possono anche avviare la pipeline dalla propria macchina locale, modificando eventuali parametri della pipeline con cui potrebbero essere sperimentati.

Esistono strumenti per garantire che i puntatori di riferimento dalla build CI/CD vengano utilizzati per impostazione predefinita. Se è presente un artefatto distribuibile nel repository, la logica CI/CD continuerà a distribuire l'elemento sulla piattaforma di servizio del modello athenahealth (il servizio di previsione) in esecuzione su Amazon ECS con AWS Fargate. Dopo che tutte queste fasi sono trascorse, il data scientist unisce il codice al ramo primario. Le pipeline e gli artefatti distribuibili vengono quindi inviati alla produzione.

Flusso di lavoro di distribuzione CI/CD. Questo diagramma descrive il flusso di lavoro di compilazione e distribuzione di Data Science. Il processo CI/CD è guidato da Jenkins.

Sicurezza

Consolidando i nostri flussi di lavoro di data science, siamo stati in grado di centralizzare il nostro approccio alla protezione della pipeline di formazione. In questa sezione, discutiamo il nostro approccio alla sicurezza dei dati e dei cluster.

La sicurezza dei dati

La sicurezza dei dati è della massima importanza in athenahealth. Per questo motivo, sviluppiamo e manteniamo un'infrastruttura pienamente conforme alle normative e agli standard che proteggono la sicurezza e l'integrità di questi dati.

Per assicurarci di soddisfare gli standard di conformità dei dati, eseguiamo il provisioning della nostra infrastruttura AWS in conformità con le nostre linee guida aziendali di athenahealth. I due archivi principali per i dati sono Amazon RDS per metadati di pipeline altamente scalabili e Amazon S3 per artefatti di pipeline e modelli. Per Amazon S3, assicuriamo che i bucket siano crittografati, che gli endpoint HTTPS vengano applicati e che le policy del bucket e Gestione dell'identità e dell'accesso di AWS I ruoli (IAM) seguono i principi del privilegio minimo quando consentono l'accesso ai dati. Questo vale anche per i dati Amazon RDS: la crittografia è sempre abilitata e i gruppi di sicurezza e l'accesso alle credenziali seguono il principio del privilegio minimo. Questa standardizzazione garantisce che solo le parti autorizzate abbiano accesso ai dati e questo accesso viene tracciato.

Oltre a queste misure, la piattaforma viene sottoposta anche a valutazioni delle minacce alla sicurezza e scansioni continue di sicurezza e conformità.

Rispondiamo anche ai requisiti di conservazione dei dati tramite la gestione del ciclo di vita dei dati per tutti i bucket S3 che contengono dati sensibili. Questa politica sposta automaticamente i dati in Ghiacciaio Amazon S3 dopo 30 giorni dalla creazione. Le eccezioni a ciò vengono gestite tramite richieste di recupero dei dati e vengono approvate o negate caso per caso. Ciò garantisce che tutti i flussi di lavoro siano conformi alla politica di conservazione dei dati. Ciò risolve anche il problema del recupero dei dati se un modello funziona male ed è necessaria una nuova formazione o quando un nuovo modello deve essere valutato rispetto a un'iterazione storica del set di dati di un modello precedente.

Per limitare l'accesso ad Amazon S3 e Amazon RDS dall'interno di Kubeflow su AWS e Amazon EKS, utilizziamo IRSA (IAM Roles for Service Accounts), che fornisce il provisioning delle autorizzazioni basato su IAM per le risorse all'interno di Kubernetes. Ogni tenant in Kubeflow dispone di un account di servizio pre-creato univoco che colleghiamo a un ruolo IAM creato appositamente per soddisfare i requisiti di accesso del tenant. L'accesso degli utenti ai tenant è limitato anche utilizzando l'appartenenza al gruppo dei pool di utenti Amazon Cognito per ciascun utente. Quando un utente viene autenticato nel cluster, il token generato contiene attestazioni di gruppo e Kubernetes RBAC utilizza queste informazioni per consentire o negare l'accesso a una determinata risorsa nel cluster. Questa configurazione è spiegata più dettagliatamente nella sezione successiva.

Sicurezza del cluster tramite isolamento multiutente

Come notato nella sezione precedente, i data scientist eseguono analisi esplorative dei dati, eseguono analisi dei dati e addestrano modelli ML. Per allocare risorse, organizzare i dati e gestire i flussi di lavoro in base ai progetti, Kubeflow su AWS fornisce l'isolamento basato sugli spazi dei nomi Kubernetes. Questo isolamento funziona per interagire con l'interfaccia utente di Kubeflow; tuttavia, non fornisce alcuno strumento per controllare l'accesso all'API Kubernetes utilizzando Kubectl. Ciò significa che l'accesso degli utenti può essere controllato sull'interfaccia utente di Kubeflow ma non sull'API Kubernetes tramite Kubectl.

L'architettura descritta nel diagramma seguente risolve questo problema unificando l'accesso ai progetti in Kubeflow in base alle appartenenze ai gruppi. Per raggiungere questo obiettivo, abbiamo sfruttato i manifesti Kubeflow su AWS, che hanno l'integrazione con i pool di utenti Amazon Cognito. Inoltre, utilizziamo il controllo di accesso basato sui ruoli (RBAC) Kubernetes per controllare l'autorizzazione all'interno del cluster. Le autorizzazioni utente vengono fornite in base all'appartenenza al gruppo Amazon Cognito. Queste informazioni vengono passate al cluster con il token generato dal client OIDC. Questo processo è semplificato grazie alla funzionalità Amazon EKS integrata che consente di associare i provider di identità OIDC per l'autenticazione con il cluster.

Per impostazione predefinita, l'autenticazione Amazon EKS viene eseguita dall'autenticatore IAM, uno strumento che consente l'autenticazione con un cluster EKS utilizzando le credenziali IAM. Questo metodo di autenticazione ha i suoi meriti; tuttavia, non è adatto al nostro caso d'uso perché athenahealth usa Microsoft Azure Active Directory per il servizio di identità in tutta l'organizzazione.

Isolamento dello spazio dei nomi Kubernetes. I data scientist possono ottenere l'appartenenza a uno o più gruppi in base alle esigenze del loro lavoro. L'accesso viene rivisto regolarmente e rimosso a seconda dei casi.

Azure Active Directory, essendo un servizio di identità a livello aziendale, è la fonte di verità per il controllo dell'accesso degli utenti al cluster Kubeflow. La configurazione per questo include la creazione di un'applicazione Azure Enterprise che funge da entità servizio e l'aggiunta di gruppi per vari tenant che richiedono l'accesso al cluster. Questa configurazione in Azure viene rispecchiata in Amazon Cognito configurando un provider di identità OIDC federato che esternalizza la responsabilità di autenticazione ad Azure. L'accesso ai gruppi di Azure è controllato da SailPoint IdentityIQ, che invia richieste di accesso al proprietario del progetto per consentire o negare a seconda dei casi. Nel pool di utenti Amazon Cognito vengono creati due client dell'applicazione: uno viene utilizzato per configurare l'autenticazione per il cluster Kubernetes utilizzando il provider di identità OIDC e l'altro per proteggere l'autenticazione Kubeflow nell'interfaccia utente di Kubeflow. Questi client sono configurati per passare le attestazioni di gruppo al momento dell'autenticazione con il cluster e queste attestazioni di gruppo vengono utilizzate insieme a RBAC per configurare l'autorizzazione all'interno del cluster.

Le associazioni del ruolo RBAC di Kubernetes vengono impostate tra i gruppi e il ruolo del cluster Kubeflow-edit, che viene creato durante l'installazione di Kubeflow nel cluster. Questa associazione del ruolo garantisce che qualsiasi utente che interagisce con il cluster dopo l'accesso tramite OIDC può accedere agli spazi dei nomi per cui dispone delle autorizzazioni, come definito nelle proprie attestazioni di gruppo. Sebbene funzioni per gli utenti che interagiscono con il cluster utilizzando Kubectl, l'interfaccia utente di Kubeflow attualmente non fornisce l'accesso agli utenti in base all'appartenenza al gruppo perché non utilizza RBAC. Al contrario, utilizza la risorsa Criterio di autorizzazione Istio per controllare l'accesso per gli utenti. Per superare questa sfida, abbiamo sviluppato un controller personalizzato che sincronizza gli utenti eseguendo il polling dei gruppi Amazon Cognito e aggiunge o rimuove le associazioni di ruolo corrispondenti per ciascun utente anziché per gruppo. Questa configurazione consente agli utenti di avere lo stesso livello di autorizzazioni quando interagiscono sia con l'interfaccia utente di Kubeflow che con Kubectl.

Efficienza operativa

In questa sezione, discutiamo di come abbiamo sfruttato gli strumenti open source e AWS a nostra disposizione per gestire ed eseguire il debug dei nostri flussi di lavoro, nonché per ridurre al minimo l'impatto operativo dell'aggiornamento di Kubeflow.

Registrazione e monitoraggio

Per la registrazione, utilizziamo FluentD per eseguire il push di tutti i registri dei nostri container Servizio Amazon OpenSearch e le metriche di sistema a Prometeo. Utilizziamo quindi Kibana e l'interfaccia utente di Grafana per la ricerca e il filtraggio di registri e metriche. Il diagramma seguente descrive come lo abbiamo impostato.

Registrazione Kubeflow. Usiamo sia l'interfaccia utente Grafana che Kibana per visualizzare e setacciare i registri

Lo screenshot seguente è una vista dell'interfaccia utente di Kibana dalla nostra pipeline.

Esempio di visualizzazione dell'interfaccia utente di Kibana. Kibana consente visualizzazioni personalizzate.

Aggiornamenti sicuri del cluster Kubeflow

Mentre eseguiamo l'onboarding degli utenti su Kubeflow su AWS, manteniamo un'esperienza utente affidabile e coerente consentendo al team MLOps di rimanere agile con il rilascio e l'integrazione di nuove funzionalità. In superficie, Kustomize sembra modulare per noi per consentire di lavorare e aggiornare un componente alla volta senza influire sugli altri, consentendoci così di aggiungere nuove funzionalità con interruzioni minime per gli utenti. Tuttavia, in pratica esistono scenari in cui l'approccio migliore è semplicemente creare un nuovo cluster Kubernetes anziché applicare aggiornamenti a livello di componente per i cluster esistenti. Abbiamo trovato due casi d'uso in cui aveva più senso creare cluster completamente nuovi:

• Aggiornamento a una versione Kubernetes in cui AWS fornisce aggiornamenti del cluster sul posto. Tuttavia, diventa difficile verificare se ciascuna delle risorse Kubeflow e Kubernetes funziona come previsto e se i manifest mantengono la compatibilità con le versioni precedenti.
• Aggiornare Kubeflow a una versione più recente in cui sono presenti diverse funzionalità aggiunte o modificate e quasi sempre non è un'idea promettente eseguire aggiornamenti sul posto su un cluster Kubernetes esistente.

Nell'affrontare questo problema, abbiamo sviluppato una strategia che ci consente di avere sostituzioni di cluster sicure senza influire sui carichi di lavoro esistenti. Per raggiungere questo obiettivo, dovevamo soddisfare i seguenti criteri:

• Separare lo storage Kubeflow e le risorse di calcolo in modo che i metadati della pipeline, gli artefatti della pipeline e i dati dell'utente vengano conservati durante il deprovisioning del cluster precedente
• Integra con Kubeflow sui manifesti AWS in modo che quando si verifica un aggiornamento della versione di Kubeflow, siano necessarie modifiche minime
• Disponi di un modo semplice per eseguire il rollback se le cose vanno storte dopo l'aggiornamento del cluster
• Avere un'interfaccia semplice per promuovere un cluster candidato alla produzione

Il diagramma seguente illustra questa architettura.

Aggiornamento sicuro del cluster Kubeflow. Una volta che il test di Kubeflow Candidate ha esito positivo, viene promosso a Kubeflow Prod tramite un aggiornamento a Route 53.

I manifest Kubeflow su AWS sono preconfezionati con le integrazioni Amazon RDS e Amazon S3. Con questi servizi gestiti che fungono da archivi dati comuni, possiamo impostare una strategia di distribuzione blu-verde. A tal fine, ci siamo assicurati che i metadati della pipeline siano mantenuti in Amazon RDS, che funziona indipendentemente dal cluster EKS, e che i log e gli artefatti della pipeline siano mantenuti in Amazon S3. Oltre ai metadati e agli artefatti della pipeline, abbiamo anche configurato FluentD per instradare i log dei pod ad Amazon OpenSearch Service.

Ciò garantisce che il livello di archiviazione sia completamente separato dal livello di calcolo e quindi consente di testare le modifiche durante gli aggiornamenti della versione di Kubeflow su un cluster EKS completamente nuovo. Dopo che tutti i test hanno avuto esito positivo, siamo in grado di modificare semplicemente il Amazon percorso 53 Record DNS al cluster candidato che ospita Kubeflow. Inoltre, manteniamo il vecchio cluster in esecuzione come backup per alcuni giorni nel caso in cui sia necessario eseguire il rollback.

Vantaggi di Amazon EKS e Kubeflow su AWS per la nostra pipeline ML

Amazon EKS e il pacchetto Kubeflow su AWS hanno spostato il nostro flusso di lavoro di sviluppo in un modello che incoraggia fortemente la formazione di modelli ripetibili. Questi strumenti ci consentono di avere cluster completamente definiti con tenant completamente definiti ed eseguire codice completamente definito.

Molte vittorie derivanti dalla creazione di questa piattaforma sono meno quantitative e hanno più a che fare con il modo in cui i flussi di lavoro sono migliorati sia per gli sviluppatori della piattaforma che per gli utenti. Ad esempio, MinIO è stato sostituito con l'accesso diretto ad Amazon S3, che ci avvicina ai nostri flussi di lavoro originali e riduce il numero di servizi che dobbiamo mantenere. Siamo anche in grado di utilizzare Amazon RDS come back-end per Kubeflow, che consente migrazioni più semplici tra cluster e ci dà la possibilità di eseguire il backup delle nostre pipeline di notte.

Abbiamo anche riscontrato vantaggi nell'integrazione di Kubeflow con i servizi gestiti da AWS. Ad esempio, con Amazon RDS, Amazon S3 e Amazon Cognito preconfigurati nei manifesti di Kubeflow su AWS, risparmiamo tempo e fatica nell'aggiornamento alle nuove distribuzioni di Kubeflow. Quando modificavamo manualmente i manifesti ufficiali di Kubeflow, l'aggiornamento a una nuova versione richiedeva diverse settimane, dalla progettazione al test.

Il passaggio ad Amazon EKS ci offre l'opportunità di definire il nostro cluster in Kustomize (ora parte di Kubectl) e Terraform. Si scopre che per il lavoro su piattaforma, Kubernetes e Terraform sono molto facili da lavorare dopo aver dedicato abbastanza tempo all'apprendimento. Dopo molte iterazioni, gli strumenti a nostra disposizione semplificano l'esecuzione di operazioni standard della piattaforma come l'aggiornamento di un componente o la sostituzione di un intero cluster di sviluppo. Rispetto all'esecuzione di lavori non elaborati Cloud di calcolo elastico di Amazon (Amazon EC2), è difficile confrontare l'enorme differenza che fa avere pod ben definiti con pulizia delle risorse garantita e meccanismi di ripetizione integrati.

Kubernetes offre ottimi standard di sicurezza e abbiamo solo scalfito la superficie di ciò che l'isolamento multiutente ci consente di fare. Consideriamo l'isolamento multiutente come un modello che avrà più vantaggi in futuro quando la piattaforma di formazione produrrà dati a livello di produzione e coinvolgiamo sviluppatori esterni al nostro team.

Nel frattempo, Kubeflow ci consente di avere un addestramento del modello riproducibile. Anche con gli stessi dati, nessun addestramento produce modelli identici, ma abbiamo la cosa migliore successiva. Con Kubeflow, sappiamo esattamente quale codice e dati sono stati utilizzati per addestrare un modello. L'onboarding è notevolmente migliorato perché ogni fase della nostra pipeline è definita in modo chiaro e programmatico. Quando i nuovi data scientist hanno il compito di correggere un bug, hanno bisogno di molto meno controllo perché esiste una struttura chiara su come vengono utilizzati gli output del codice tra le fasi.

L'uso di Kubeflow offre anche molti miglioramenti delle prestazioni rispetto all'esecuzione su una singola istanza EC2. Spesso nell'addestramento dei modelli, i data scientist necessitano di strumenti e ottimizzazioni diversi per la preelaborazione e l'addestramento. Ad esempio, la preelaborazione viene spesso eseguita utilizzando strumenti di elaborazione dati distribuiti, come Spark, mentre l'addestramento viene spesso eseguito utilizzando istanze GPU. Con le pipeline Kubeflow, possono specificare diversi tipi di istanza per le diverse fasi della pipeline. Ciò consente loro di utilizzare le potenti istanze GPU in una fase e una flotta di macchine più piccole per l'elaborazione distribuita in un'altra fase. Inoltre, poiché le pipeline Kubeflow descrivono le dipendenze tra le fasi, le pipeline possono eseguire fasi in parallelo.

Infine, poiché abbiamo creato un processo per aggiungere tenant al cluster, ora esiste un modo più formale per registrare i team in un tenant nel cluster. Poiché utilizziamo Kubecost per tenere traccia dei costi nel nostro cluster EKS, ci consente di attribuire i costi a un singolo progetto anziché avere costi attribuiti a livello di account, che include tutti i progetti di scienza dei dati. Kubecost presenta un rapporto sul denaro speso per spazio dei nomi, strettamente collegato al tenant o al team responsabile dell'esecuzione della pipeline.

Nonostante tutti i vantaggi, vorremmo fare attenzione a intraprendere questo tipo di migrazione solo se c'è un'adesione totale da parte degli utenti. Gli utenti che impiegano tempo ottengono molti vantaggi dall'utilizzo di Amazon EKS e Kubernetes, ma c'è una curva di apprendimento significativa.

Conclusione

Con l'implementazione della pipeline Kubeflow su AWS nella nostra infrastruttura ML end-to-end, siamo stati in grado di consolidare e standardizzare i nostri flussi di lavoro di data science mantenendo i nostri strumenti essenziali (come CI/CD e model serving). I nostri data scientist possono ora passare da un progetto all'altro in base a questo flusso di lavoro senza il sovraccarico di imparare a mantenere un set di strumenti completamente diverso. Per alcuni dei nostri modelli, siamo rimasti piacevolmente sorpresi anche dalla velocità del nuovo flusso di lavoro (cinque volte più veloce), che ha consentito più iterazioni di addestramento e, di conseguenza, la produzione di modelli con previsioni migliori.

Abbiamo anche stabilito una solida base per aumentare le nostre capacità MLOps e scalare il numero e le dimensioni dei nostri progetti. Ad esempio, rafforzando la nostra posizione di governance nel lignaggio e nel monitoraggio del modello, abbiamo ridotto la nostra attenzione da oltre 15 flussi di lavoro a uno solo. E quando la vulnerabilità di Log4shell è emersa alla fine del 2021, siamo stati in grado di concentrarci su un unico flusso di lavoro e di rimediare rapidamente secondo necessità (eseguendo Registro dei contenitori Amazon Elastic (Amazon ECR), l'aggiornamento di Amazon OpenSearch Service, l'aggiornamento dei nostri strumenti e altro ancora) con un impatto minimo sul lavoro in corso dei data scientist. Man mano che i miglioramenti di AWS e Kubeflow diventano disponibili, possiamo incorporarli come meglio credi.

Questo ci porta a un aspetto importante e sottovalutato della nostra adozione di Kubeflow su AWS. Uno dei risultati critici di questo viaggio è la capacità di implementare senza problemi aggiornamenti e miglioramenti a Kubeflow per i nostri data scientist. Anche se abbiamo discusso in precedenza del nostro approccio, ci affidiamo anche ai manifest Kubeflow forniti da AWS. Abbiamo iniziato il nostro viaggio con Kubeflow come proof of concept nel 2019, prima del rilascio della versione 1.0.0. (Attualmente siamo sulla 1.4.1, stiamo valutando la 1.5. AWS sta già lavorando alla versione 1.6.) Negli ultimi 3 anni, ci sono state almeno sei versioni con contenuti sostanziali. Attraverso il loro approccio disciplinato all'integrazione e alla convalida di questi aggiornamenti e al rilascio dei manifest in una pianificazione prevedibile e affidabile, il team Kubeflow di AWS è stato fondamentale nel consentire al team di athenahealth MLOps di pianificare la nostra roadmap di sviluppo e, di conseguenza, le nostre allocazioni di risorse e aree di interesse , più avanti nel futuro con maggiore fiducia.

Puoi seguire il Repository GitHub di AWS Labs per tenere traccia di tutti i contributi AWS a Kubeflow. Puoi anche trovare i team AWS su Canale Kubeflow #AWS Slack; il tuo feedback aiuta AWS a stabilire la priorità delle funzionalità successive per contribuire al progetto Kubeflow.

---

Circa gli autori

Kanwaljit Khurmi è Senior Solutions Architect presso Amazon Web Services. Collabora con i clienti AWS per fornire guida e assistenza tecnica aiutandoli a migliorare il valore delle loro soluzioni quando utilizzano AWS. Kanwaljit è specializzato nell'aiutare i clienti con applicazioni containerizzate e di apprendimento automatico.

Tyler Kalbach è un membro principale dello staff tecnico di athenahealth. Tyler ha circa 7 anni di esperienza in analisi, scienza dei dati, reti neurali e sviluppo di applicazioni di machine learning nel settore sanitario. Ha contribuito a diverse soluzioni di Machine Learning che attualmente servono il traffico di produzione. Attualmente lavorando come Principal Data Scientist nell'organizzazione di ingegneria di athenahealth, Tyler ha fatto parte del team che ha costruito la nuova piattaforma di formazione sull'apprendimento automatico per athenahealth dall'inizio di tale sforzo.

Victor Krylov è un membro principale dello staff tecnico di athenahealth. Victor è un ingegnere e Scrum Master, che aiuta i data scientist a creare pipeline di apprendimento automatico veloci e sicure. In athenahealth ha lavorato su interfacce, ordini clinici, prescrizioni, programmazione, analisi e ora machine learning. Apprezza il codice scritto in modo pulito e ben testato, ma ha un'ossessione malsana per le battute di codice. Nel tempo libero si diverte ad ascoltare i podcast mentre porta a spasso il suo cane.

Sasanke Vemuri è un membro capo dello staff tecnico di athenahealth. Ha esperienza di lavoro con lo sviluppo di soluzioni basate sui dati in domini quali assistenza sanitaria, assicurazioni e bioinformatica. Sasank attualmente lavora con la progettazione e lo sviluppo di piattaforme di formazione e inferenza di machine learning su AWS e Kubernetes che aiutano con la formazione e la distribuzione di soluzioni ML su larga scala.

Anu Tumkur è un architetto presso athenahealth. Anu ha oltre due decenni di esperienza nell'architettura, nella progettazione e nello sviluppo nella creazione di vari prodotti software in machine learning, operazioni cloud, big data, pipeline di dati distribuiti in tempo reale, tecnologia pubblicitaria, analisi dei dati, analisi dei social media. Anu attualmente lavora come architetto nell'organizzazione Product Engineering di athenahealth nei team Machine Learning Platform e Data Pipeline.

William Zen è Senior Engineering Manager presso athenahealth. Vanta oltre 20 anni di esperienza di leadership ingegneristica nella creazione di soluzioni nell'informatica sanitaria, nell'informatica distribuita di big data, nelle reti ottiche intelligenti, nei sistemi di editing video in tempo reale, nel software aziendale e nella sottoscrizione di servizi sanitari di gruppo. William attualmente guida due fantastici team di athenahealth, i team di ingegneria delle operazioni di apprendimento automatico e di DevOps, nell'organizzazione di ingegneria del prodotto.