Creați fluxuri de lucru de învățare automată de la capăt la capăt repetabile, sigure și extensibile folosind Kubeflow pe AWS

Aceasta este o postare pe blog pentru invitați, scrisă împreună cu athenahealth.

atenahealth un furnizor de top de software și servicii activate în rețea pentru grupuri medicale și sisteme de sănătate la nivel național. Dosarele sale electronice de sănătate, managementul ciclului de venituri și instrumentele de implicare a pacienților permit accesul oricând și oriunde, generând rezultate financiare mai bune pentru clienții săi și permițând clienților săi furnizori să ofere îngrijiri de mai bună calitate.

În spațiul inteligenței artificiale (AI), athenahealth folosește știința datelor și învățarea automată (ML) pentru a accelera procesele de afaceri și pentru a oferi recomandări, predicții și perspective pentru mai multe servicii. De la prima sa implementare în serviciile de documente automatizate, procesând fără atingere milioane de documente furnizor-pacient, până la activitatea sa mai recentă în asistenții virtuali și îmbunătățirea performanței ciclului de venituri, athenahealth continuă să aplice AI pentru a ajuta la creșterea eficienței, a capabilităților de servicii și a rezultatelor mai bune pentru furnizori. si pacientii lor.

Această postare de blog demonstrează cum folosește athenahealth Kubeflow pe AWS (o distribuție Kubeflow specifică AWS) pentru a construi și a eficientiza un flux de lucru end-to-end pentru știința datelor care păstrează instrumentele esențiale, optimizează eficiența operațională, crește productivitatea cercetătorilor de date și pregătește scena pentru extinderea mai ușor a capabilităților ML.

Kubeflow este platforma ML open-source dedicată implementării fluxurilor de lucru ML pe Kubernetes simple, portabile și scalabile. Kubeflow realizează acest lucru prin încorporarea instrumentelor open-source relevante care se integrează bine cu Kubernetes. Unele dintre aceste proiecte includ Argo pentru orchestrare pipeline, Istio pentru rețea de serviciu, Jupyter pentru notebook-uri, Spark, TensorBoard și Katib. Kubeflow Pipelines ajută la construirea și implementarea fluxurilor de lucru ML portabile, scalabile, care pot include pași precum extragerea datelor, preprocesarea, instruirea modelului și evaluarea modelului sub formă de conducte repetabile.

AWS contribuie la comunitatea cu sursă deschisă Kubeflow prin furnizarea propriei distribuții Kubeflow (numită Kubeflow pe AWS), care ajută organizații precum athenahealth să construiască fluxuri de lucru ML extrem de fiabile, sigure, portabile și scalabile, cu o suprasolicitare operațională redusă prin integrarea cu serviciile gestionate AWS. AWS oferă diverse opțiuni de implementare Kubeflow, cum ar fi implementarea cu Amazon Cognito, implementare cu Serviciul de baze de date relaționale Amazon (Amazon RDS) și Serviciul Amazon de stocare simplă (Amazon S3) și implementare vanilla. Pentru detalii despre integrarea serviciului și suplimentele disponibile pentru fiecare dintre aceste opțiuni, consultați Implementare.

Astăzi, Kubeflow on AWS oferă o cale clară spre utilizarea Kubeflow, amplificată cu următoarele servicii AWS:

Mulți clienți AWS profită de distribuția Kubeflow on AWS, inclusiv athenahealth.

Aici, echipa athenahealth MLOps discută provocările pe care le-au întâlnit și soluțiile pe care le-au creat în călătoria lor Kubeflow.

Provocări cu mediul ML anterior

Înainte de adoptarea Kubeflow pe AWS, oamenii noștri de știință de date au folosit un set standardizat de instrumente și un proces care a permis flexibilitate în tehnologia și fluxul de lucru utilizat pentru a antrena un anumit model. Exemplele de componente ale instrumentelor standardizate includ un API de asimilare a datelor, instrumente de scanare de securitate, conducta CI/CD construită și întreținută de o altă echipă din cadrul athenahealth și o platformă comună de servire construită și întreținută de echipa MLOps. Cu toate acestea, pe măsură ce utilizarea AI și ML sa maturizat, varietatea de instrumente și infrastructură create pentru fiecare model a crescut. Deși am fost în continuare capabili să sprijinim procesul existent, am văzut următoarele provocări la orizont:

• Întreținere și creștere – Reproducerea și întreținerea mediilor de formare a modelelor a necesitat mai mult efort pe măsură ce numărul modelelor implementate a crescut. Fiecare proiect a menținut documentație detaliată care a subliniat modul în care fiecare script a fost utilizat pentru a construi modelul final. În multe cazuri, acesta a fost un proces elaborat care a implicat 5 până la 10 scripturi cu mai multe ieșiri fiecare. Acestea trebuiau urmărite manual cu instrucțiuni detaliate despre modul în care fiecare rezultat va fi utilizat în procesele ulterioare. Menținerea acestui lucru de-a lungul timpului a devenit greoaie. Mai mult, pe măsură ce proiectele au devenit mai complexe, a crescut și numărul de instrumente. De exemplu, majoritatea modelelor au folosit Spark și TensorFlow cu GPU-uri, ceea ce necesita o varietate mai mare de configurații de mediu. De-a lungul timpului, utilizatorii treceau la versiuni mai noi de instrumente în mediile lor de dezvoltare, dar apoi nu puteau rula scripturi mai vechi când acele versiuni deveneau incompatibile. În consecință, întreținerea și extinderea proiectelor mai vechi a necesitat mai mult timp și efort de inginerie. În plus, pe măsură ce noi oameni de știință de date s-au alăturat echipei, transferul de cunoștințe și integrarea a durat mai mult timp, deoarece sincronizarea mediilor locale includea multe dependențe nedocumentate. Comutarea între proiecte s-a confruntat cu aceleași probleme, deoarece fiecare model avea propriile fluxuri de lucru.
• Securitate – Luăm în serios securitatea și, prin urmare, acordăm prioritate respectării tuturor obligațiilor contractuale, legale și de reglementare asociate cu ML și știința datelor. Datele trebuie utilizate, stocate și accesate în moduri specifice, iar noi am încorporat procese solide pentru a ne asigura că practicile noastre respectă obligațiile legale, precum și cele mai bune practici din industrie. Înainte de adoptarea Kubeflow, asigurarea faptului că datele au fost stocate și accesate într-un mod specific implica o verificare regulată în fluxuri de lucru multiple și diverse. Știam că putem îmbunătăți eficiența prin consolidarea acestor fluxuri de lucru diverse pe o singură platformă. Cu toate acestea, platforma respectivă ar trebui să fie suficient de flexibilă pentru a se integra bine cu instrumentele noastre standardizate.
• Operațiuni – Am văzut, de asemenea, o oportunitate de a crește eficiența operațională și managementul prin centralizarea înregistrării și monitorizării fluxurilor de lucru. Deoarece fiecare echipă și-a dezvoltat propriile instrumente, am colectat aceste informații din fiecare flux de lucru individual și le-am agregat.

Echipa de știință a datelor a evaluat diverse soluții pentru consolidarea fluxurilor de lucru. Pe lângă abordarea acestor cerințe, am căutat o soluție care să se integreze perfect cu infrastructura și instrumentele standardizate existente. Am selectat Amazon EKS și Kubeflow pe AWS ca soluție de flux de lucru.

Ciclul de dezvoltare a cercetătorilor de date care încorporează Kubeflow

Un proiect de știință a datelor începe cu o soluție curată: fără date, fără cod, doar problema de business care poate fi rezolvată cu ML. Prima sarcină este o dovadă a conceptului (POC) pentru a descoperi dacă datele dețin suficient semnal pentru a face un model ML eficient în rezolvarea problemei de afaceri, începând cu interogarea setului de date brute din depozitul nostru de date Snowflake. Această etapă este iterativă, iar oamenii de știință de date folosesc podurile Kubernetes sau blocnotesurile Kubeflow Jupyter în timpul acestui proces.

Clusterul nostru Kubeflow folosește autoscaler-ul de cluster Karpenter, ceea ce facilitează exploatarea resurselor pentru oamenii de știință de date, deoarece aceștia trebuie să se concentreze doar pe definirea tipurilor de instanțe dorite, în timp ce munca de furnizare este realizată de un set de furnizori Karpenter predefiniti. Avem furnizori separati pentru tipurile de instanțe CPU și GPU, iar toate instanțele acceptate de Amazon EKS se încadrează într-una dintre aceste două categorii conform configurației noastre. Oamenii de știință de date aleg tipurile de instanțe folosind selectoare de noduri, iar Karpenter se ocupă de gestionarea ciclului de viață al nodurilor.

După ce interogarea este dezvoltată, oamenii de știință din date extrag datele brute într-o locație de pe Amazon S3, apoi lansează un notebook Jupyter din interfața de utilizare AWS Kubeflow pentru a explora datele. Scopul este de a crea setul de caracteristici care va fi folosit pentru a antrena primul model. Acest lucru permite cercetătorilor de date să determine dacă există suficient semnal în date pentru a satisface nevoia de afaceri a clientului.

După ce rezultatele sunt satisfăcătoare, oamenii de știință de date trec la următoarea etapă a ciclului de dezvoltare și își transformă descoperirile într-o conductă robustă. Ei convertesc codul POC în cod de calitate de producție care rulează la scară. Pentru a asigura conformitatea prin utilizarea bibliotecilor aprobate, este creat un container cu imaginea Docker de bază corespunzătoare. Pentru oamenii noștri de știință de date, am descoperit că furnizarea unei imagini de bază standard Python, TensorFlow și Spark oferă suficientă flexibilitate pentru majoritatea, dacă nu toate, sarcinile de lucru. Ei pot folosi apoi fișierul Dockerfile al componentei lor pentru a-și personaliza în continuare mediul de dezvoltare. Acest Dockerfile este apoi utilizat de procesul CI/CD pentru a construi imaginea componentelor care va fi folosită în producție, menținând astfel coerența între mediile de dezvoltare și de producție.

Avem un instrument care oferă cercetătorilor de date capacitatea de a-și lansa mediul de dezvoltare într-un pod care rulează pe Kubernetes. Când acest pod rulează, oamenii de știință de date pot atașa IDE-ul Visual Studio Code direct la pod și își pot depana codul modelului. După ce au codul să ruleze cu succes, își pot împinge modificările în git și este creat un nou mediu de dezvoltare cu cele mai recente modificări.

Conducta standard de știință a datelor constă din etape care includ extragerea, preprocesarea, instruirea și evaluarea. Fiecare etapă din conductă apare ca o componentă în Kubeflow, care constă dintr-un pod Kubernetes care rulează o comandă cu unele informații transmise ca parametri. Acești parametri pot fi fie valori statice, fie referințe la ieșirea de la o componentă anterioară. Imaginea Docker folosită în pod este construită din procesul CI/CD. Detaliile despre acest proces apar în fluxul de lucru CI/CD discutat în secțiunea următoare.

Ciclul de dezvoltare pe Kubeflow. Fluxul de lucru de dezvoltare începe din stânga cu POC. Modelul finalizat este implementat pe platforma de servire a modelului athenahealth care rulează pe Amazon ECS.

Proces CI/CD care suportă fluxuri de lucru automate

Ca parte a procesului nostru CI/CD, folosim Jenkins pentru a construi și a testa toate imaginile componente Kubeflow în paralel. La finalizarea cu succes, șablonul de componentă a conductei conține pointeri de referință către imagini, iar conducta rezultată este încărcată în Kubeflow. Parametrii din conducta Jenkins permit utilizatorilor să lanseze conductele și să își execute testele de antrenament al modelului după construirea de succes.

Alternativ, pentru a menține un ciclu scurt de dezvoltare, oamenii de știință de date pot lansa, de asemenea, conducta de pe mașina lor locală, modificând orice parametri ai conductei cu care ar putea experimenta.

Există instrumente pentru a se asigura că pointerii de referință din construcția CI/CD sunt utilizați în mod implicit. Dacă există un artefact implementabil în repo, atunci logica CI/CD va continua să implementeze artefactul pe platforma de servire a modelului athenahealth (Serviciul de predicție) care rulează pe Amazon ECS cu AWS Fargate. După ce au trecut toate aceste etape, cercetătorul unește codul cu ramura primară. Conductele și artefactele implementabile sunt apoi împinse în producție.

Flux de lucru de implementare CI/CD. Această diagramă descrie fluxul de lucru pentru construirea și implementarea Data Science. Procesul CI/CD este condus de Jenkins.

Securitate

În consolidarea fluxurilor noastre de lucru în domeniul științei datelor, am reușit să ne centralizăm abordarea pentru securizarea canalului de formare. În această secțiune, discutăm abordarea noastră privind securitatea datelor și a clusterelor.

Securitatea datelor

Securitatea datelor este de cea mai mare importanță la athenahealth. Din acest motiv, dezvoltăm și menținem o infrastructură care este pe deplin conformă cu reglementările și standardele care protejează securitatea și integritatea acestor date.

Pentru a ne asigura că îndeplinim standardele de conformitate cu datele, furnizăm infrastructura noastră AWS în conformitate cu liniile directoare ale întreprinderii athenahealth. Cele două magazine principale pentru date sunt Amazon RDS pentru metadatele pipeline foarte scalabile și Amazon S3 pentru pipeline și artefacte model. Pentru Amazon S3, ne asigurăm că compartimentele sunt criptate, punctele finale HTTPS sunt aplicate și politicile compartimentelor și Gestionarea identității și accesului AWS Rolurile (IAM) urmează principiile celui mai mic privilegiu atunci când permit accesul la date. Acest lucru este valabil și pentru datele Amazon RDS: criptarea este întotdeauna activată, iar grupurile de securitate și accesul la acreditări urmează principiul celui mai mic privilegiu. Această standardizare asigură că numai părțile autorizate au acces la date, iar acest acces este urmărit.

Pe lângă aceste măsuri, platforma este supusă și evaluărilor amenințărilor de securitate și scanărilor continue de securitate și conformitate.

De asemenea, abordăm cerințele de păstrare a datelor prin managementul ciclului de viață al datelor pentru toate compartimentele S3 care conțin date sensibile. Această politică mută automat datele în Ghețarul Amazon S3 după 30 de zile de la creare. Excepțiile de la aceasta sunt gestionate prin solicitări de preluare a datelor și sunt aprobate sau respinse de la caz la caz. Acest lucru asigură că toate fluxurile de lucru respectă politica de păstrare a datelor. Acest lucru rezolvă, de asemenea, problema cu recuperarea datelor dacă un model are performanțe slabe și este necesară reinstruirea sau când un model nou trebuie evaluat în raport cu o iterație istorică a setului de date al unui model mai vechi.

Pentru a restricționa accesul la Amazon S3 și Amazon RDS din Kubeflow pe AWS și Amazon EKS, folosim IRSA (IAM Roles for Service Accounts), care oferă permisiuni bazate pe IAM pentru resurse din Kubernetes. Fiecare chiriaș din Kubeflow are un cont de serviciu unic pre-creat, pe care îl legăm de un rol IAM creat special pentru a îndeplini cerințele de acces pentru chiriași. Accesul utilizatorilor la chiriași este, de asemenea, restricționat folosind apartenența la grupul de grupuri de utilizatori Amazon Cognito pentru fiecare utilizator. Când un utilizator este autentificat la cluster, simbolul generat conține revendicări de grup, iar Kubernetes RBAC utilizează aceste informații pentru a permite sau a refuza accesul la o anumită resursă din cluster. Această configurație este explicată mai detaliat în secțiunea următoare.

Securitatea clusterului folosind izolarea multi-utilizator

După cum am observat în secțiunea anterioară, oamenii de știință în date efectuează analize exploratorii ale datelor, execută analize de date și antrenează modele ML. Pentru a aloca resurse, a organiza datele și a gestiona fluxurile de lucru bazate pe proiecte, Kubeflow on AWS oferă izolarea pe baza spațiilor de nume Kubernetes. Această izolare funcționează pentru interacțiunea cu interfața de utilizare Kubeflow; cu toate acestea, nu oferă niciun instrument pentru a controla accesul la API-ul Kubernetes folosind Kubectl. Aceasta înseamnă că accesul utilizatorilor poate fi controlat prin interfața de utilizare Kubeflow, dar nu prin API-ul Kubernetes prin Kubectl.

Arhitectura descrisă în diagrama următoare abordează această problemă prin unificarea accesului la proiecte în Kubeflow pe baza apartenenței la grup. Pentru a realiza acest lucru, am profitat de manifestele Kubeflow on AWS, care au integrare cu pool-urile de utilizatori Amazon Cognito. În plus, folosim controlul accesului bazat pe roluri (RBAC) Kubernetes pentru a controla autorizarea în cluster. Permisiunile utilizatorului sunt furnizate pe baza apartenenței la grupul Amazon Cognito. Aceste informații sunt transmise cluster-ului cu jetonul generat de clientul OIDC. Acest proces este simplificat datorită funcționalității încorporate Amazon EKS care permite asocierea furnizorilor de identitate OIDC pentru a se autentifica cu clusterul.

În mod implicit, autentificarea Amazon EKS este efectuată de autentificatorul IAM, care este un instrument care permite autentificarea cu un cluster EKS folosind acreditările IAM. Această metodă de autentificare are meritele ei; cu toate acestea, nu este potrivit pentru cazul nostru de utilizare, deoarece athenahealth utilizează Microsoft Azure Active Directory pentru serviciul de identitate în întreaga organizație.

Izolarea spațiului de nume Kubernetes. Oamenii de știință de date pot obține calitatea de membru la unul sau mai multe grupuri, după cum este necesar pentru munca lor. Accesul este revizuit în mod regulat și eliminat după caz.

Azure Active Directory, fiind un serviciu de identitate la nivel de întreprindere, este sursa adevărului pentru controlul accesului utilizatorilor la clusterul Kubeflow. Configurarea pentru aceasta include crearea unei aplicații Azure Enterprise care acționează ca principal de serviciu și adăugarea de grupuri pentru diferiți chiriași care necesită acces la cluster. Această configurare pe Azure este reflectată în Amazon Cognito prin configurarea unui furnizor de identitate OIDC federal care externalizează responsabilitatea de autentificare către Azure. Accesul la grupurile Azure este controlat de SailPoint IdentityIQ, care trimite cereri de acces proprietarului proiectului pentru a permite sau a refuza, după caz. În pool-ul de utilizatori Amazon Cognito, sunt creați doi clienți de aplicație: unul este utilizat pentru a configura autentificarea pentru clusterul Kubernetes folosind furnizorul de identitate OIDC, iar celălalt pentru a securiza autentificarea Kubeflow în interfața de utilizare Kubeflow. Acești clienți sunt configurați să transmită revendicări de grup la autentificare cu clusterul, iar aceste revendicări de grup sunt utilizate împreună cu RBAC pentru a configura autorizarea în cluster.

Legăturile de rol Kubernetes RBAC sunt configurate între grupuri și rolul de cluster Kubeflow-edit, care este creat la instalarea Kubeflow în cluster. Această legare de rol asigură că orice utilizator care interacționează cu clusterul după ce se conectează prin OIDC poate accesa spațiile de nume pentru care au permisiuni, așa cum sunt definite în revendicările grupului. Deși acest lucru funcționează pentru utilizatorii care interacționează cu clusterul folosind Kubectl, interfața de utilizare Kubeflow nu oferă în prezent acces utilizatorilor pe baza apartenenței la grup, deoarece nu folosește RBAC. În schimb, folosește resursa Istio Authorization Policy pentru a controla accesul utilizatorilor. Pentru a depăși această provocare, am dezvoltat un controler personalizat care sincronizează utilizatorii interogând grupurile Amazon Cognito și adaugă sau elimină legăturile de rol corespunzătoare pentru fiecare utilizator, mai degrabă decât pe grup. Această configurare permite utilizatorilor să aibă același nivel de permisiuni atunci când interacționează atât cu interfața de utilizare Kubeflow, cât și cu Kubectl.

Eficienta operationala

În această secțiune, discutăm despre modul în care am profitat de instrumentele open source și AWS disponibile pentru a ne gestiona și depana fluxurile de lucru, precum și pentru a minimiza impactul operațional al modernizării Kubeflow.

Înregistrare și monitorizare

Pentru înregistrare, folosim FluentD pentru a împinge toate jurnalele de containere Serviciul Amazon OpenSearch și metrici de sistem pentru Prometheus. Apoi folosim Kibana și interfața de utilizare Grafana pentru căutarea și filtrarea jurnalelor și a valorilor. Următoarea diagramă descrie modul în care am configurat acest lucru.

Înregistrare Kubeflow. Folosim atât Grafana UI, cât și Kibana pentru a vizualiza și a verifica jurnalele

Următoarea captură de ecran este o vizualizare Kibana UI din conducta noastră.

Exemplu de vizualizare Kibana UI. Kibana permite vizualizari personalizate.

Actualizări sigure de cluster Kubeflow

Pe măsură ce integrăm utilizatorii la Kubeflow pe AWS, menținem o experiență de utilizator fiabilă și consecventă, permițând în același timp echipei MLOps să rămână agilă prin lansarea și integrarea de noi funcții. La suprafață, Kustomize pare modular pentru noi pentru a permite lucrul și actualizarea câte o componentă la un moment dat, fără a le afecta pe altele, permițându-ne astfel să adăugăm noi capabilități cu perturbări minime pentru utilizatori. Cu toate acestea, în practică, există scenarii în care cea mai bună abordare este pur și simplu să porniți un nou cluster Kubernetes, mai degrabă decât să aplicați upgrade la nivel de componente pentru clusterele existente. Am găsit două cazuri de utilizare în care era mai logic să creăm clustere complet noi:

• Actualizarea la o versiune Kubernetes în care AWS oferă upgrade-uri de cluster la loc. Cu toate acestea, devine dificil să testați dacă fiecare dintre resursele Kubeflow și Kubernetes funcționează conform intenției și dacă manifestele păstrează compatibilitatea cu versiunea inversă.
• Actualizarea Kubeflow la o versiune mai nouă în care sunt adăugate sau modificate mai multe funcții și aproape întotdeauna nu este o idee promițătoare să efectuați upgrade-uri la locul unui cluster Kubernetes existent.

În abordarea acestei probleme, am dezvoltat o strategie care ne permite să avem înlocuiri sigure de cluster, fără a afecta sarcinile de lucru existente. Pentru a realiza acest lucru, a trebuit să îndeplinim următoarele criterii:

• Separați resursele de stocare și de calcul Kubeflow, astfel încât metadatele conductei, artefactele conductei și datele utilizatorului să fie păstrate atunci când deprovisionați clusterul mai vechi
• Integrați cu Kubeflow pe manifestele AWS, astfel încât atunci când are loc o actualizare a versiunii Kubeflow, sunt necesare modificări minime
• Aveți o modalitate fără efort de a reveni dacă lucrurile merg prost după actualizarea clusterului
• Aveți o interfață simplă pentru a promova un cluster candidat la producție

Următoarea diagramă ilustrează această arhitectură.

Actualizare sigură a clusterului Kubeflow. Odată ce testarea Kubeflow Candidate are succes, acesta este promovat la Kubeflow Prod printr-o actualizare a Route 53.

Manifestele Kubeflow pe AWS sunt pre-ambalate cu integrări Amazon RDS și Amazon S3. Cu aceste servicii gestionate acționând ca depozite de date comune, putem configura o strategie de implementare albastru-verde. Pentru a realiza acest lucru, ne-am asigurat că metadatele conductei sunt persistente în Amazon RDS, care funcționează independent de clusterul EKS, iar jurnalele și artefactele conductei sunt persistente în Amazon S3. Pe lângă metadatele și artefactele pipeline, am configurat și FluentD pentru a direcționa jurnalele pod către Amazon OpenSearch Service.

Acest lucru asigură că stratul de stocare este complet separat de stratul de calcul și, prin urmare, permite testarea modificărilor în timpul actualizărilor versiunii Kubeflow pe un cluster EKS complet nou. După ce toate testele au succes, putem pur și simplu să schimbăm Ruta Amazonului 53 Înregistrare DNS către clusterul candidat care găzduiește Kubeflow. De asemenea, menținem vechiul cluster să funcționeze ca rezervă timp de câteva zile, în cazul în care trebuie să facem înapoi.

Beneficiile Amazon EKS și Kubeflow pe AWS pentru conducta noastră ML

Amazon EKS și pachetul Kubeflow on AWS ne-au mutat fluxul de lucru de dezvoltare la un model care încurajează puternic formarea modelului repetabil. Aceste instrumente ne permit să avem clustere complet definite cu chiriași complet definiți și să rulăm cod complet definit.

Multe câștiguri din construirea acestei platforme sunt mai puțin cantitative și au mai mult de-a face cu modul în care fluxurile de lucru s-au îmbunătățit atât pentru dezvoltatorii de platforme, cât și pentru utilizatori. De exemplu, MinIO a fost înlocuit cu acces direct la Amazon S3, ceea ce ne apropie de fluxurile noastre de lucru inițiale și reduce numărul de servicii pe care trebuie să le menținem. De asemenea, putem folosi Amazon RDS ca backend pentru Kubeflow, ceea ce permite migrari mai ușoare între clustere și ne oferă posibilitatea de a face copii de rezervă ale conductelor noastre seara.

De asemenea, am considerat că îmbunătățirile în integrarea Kubeflow cu serviciile gestionate AWS sunt benefice. De exemplu, cu Amazon RDS, Amazon S3 și Amazon Cognito preconfigurate în manifestele Kubeflow on AWS, economisim timp și efort la actualizarea la distribuțiile mai noi ale Kubeflow. Când obișnuiam să modificăm manual manifestele oficiale Kubeflow, actualizarea la o versiune nouă ar dura câteva săptămâni, de la proiectare până la testare.

Trecerea la Amazon EKS ne oferă posibilitatea de a ne defini clusterul în Kustomize (acum parte a Kubectl) și Terraform. Se dovedește că pentru lucrul pe platformă, Kubernetes și Terraform sunt foarte ușor de lucrat după ce au acordat suficient timp pentru a învăța. După multe iterații, instrumentele disponibile ne fac foarte ușor să efectuam operațiuni standard ale platformei, cum ar fi actualizarea unei componente sau schimbarea unui întreg cluster de dezvoltare. În comparație cu executarea joburilor în stare brută Cloud Elastic de calcul Amazon (Amazon EC2), este greu de comparat ce diferență enormă face să ai pod-uri bine definite cu mecanisme de curățare garantată a resurselor și reîncercare încorporate.

Kubernetes oferă standarde excelente de securitate și am zgâriat doar suprafața a ceea ce ne permite izolarea multi-utilizator. Vedem izolarea multi-utilizator ca un model care are mai multe beneficii în viitor, atunci când platforma de instruire produce date la nivel de producție și aducem dezvoltatori din afara echipei noastre.

Între timp, Kubeflow ne permite să avem antrenament de model reproductibil. Chiar și cu aceleași date, niciun antrenament nu produce modele identice, dar avem următorul lucru cel mai bun. Cu Kubeflow, știm exact ce cod și date au fost folosite pentru a antrena un model. Integrarea s-a îmbunătățit foarte mult, deoarece fiecare pas din pipeline este definit în mod clar și programatic. Atunci când noii oameni de știință de date au sarcina de a remedia o eroare, au nevoie de mult mai puțină menținere, deoarece există o structură clară a modului în care sunt utilizate rezultatele codului între etape.

Utilizarea Kubeflow aduce, de asemenea, o mulțime de îmbunătățiri ale performanței în comparație cu rularea pe o singură instanță EC2. Adesea, în formarea modelelor, oamenii de știință au nevoie de instrumente și optimizări diferite pentru preprocesare și instruire. De exemplu, preprocesarea se desfășoară adesea folosind instrumente distribuite de procesare a datelor, cum ar fi Spark, în timp ce antrenamentul se desfășoară adesea folosind instanțe GPU. Cu conductele Kubeflow, acestea pot specifica diferite tipuri de instanțe pentru diferite etape ale conductei. Acest lucru le permite să folosească instanțele GPU puternice într-o etapă și o flotă de mașini mai mici pentru procesare distribuită într-o altă etapă. De asemenea, deoarece conductele Kubeflow descriu dependențele dintre etape, conductele pot rula etape în paralel.

În cele din urmă, deoarece am creat un proces pentru adăugarea chiriașilor în cluster, există acum o modalitate mai formală de a înregistra echipele la un chiriaș din cluster. Deoarece folosim Kubecost pentru a urmări costurile în clusterul nostru EKS, ne permite să atribuim costurile unui singur proiect, mai degrabă decât să avem costuri atribuite la nivel de cont, care include toate proiectele de știință a datelor. Kubecost prezintă un raport al banilor cheltuiți pe spațiu de nume, care este strâns legat de chiriașul sau echipa care este responsabilă cu gestionarea conductei.

În ciuda tuturor beneficiilor, am avertiza să întreprindem acest tip de migrare numai dacă există o acceptare totală din partea utilizatorilor. Utilizatorii care pun timp obțin o mulțime de beneficii din utilizarea Amazon EKS și Kubernetes, dar există o curbă semnificativă de învățare.

Concluzie

Odată cu implementarea conductei Kubeflow pe AWS în infrastructura noastră de ML end-to-end, am putut să ne consolidăm și să standardizăm fluxurile de lucru din știința datelor, păstrând în același timp instrumentele noastre esențiale (cum ar fi CI/CD și servirea modelelor). Oamenii noștri de știință de date pot acum să se deplaseze între proiecte bazate pe acest flux de lucru, fără a învăța cum să mențină un set de instrumente complet diferit. Pentru unele dintre modelele noastre, am fost, de asemenea, plăcut surprinși de viteza noului flux de lucru (de cinci ori mai rapid), care a permis mai multe iterații de antrenament și, în consecință, producerea de modele cu predicții mai bune.

De asemenea, am stabilit o bază solidă pentru a ne spori capacitățile MLOps și a mări numărul și dimensiunea proiectelor noastre. De exemplu, pe măsură ce ne întărim poziția de guvernare în linia și urmărirea modelelor, ne-am redus concentrarea de la peste 15 fluxuri de lucru la doar unul. Și când vulnerabilitatea Log4shell a apărut la sfârșitul anului 2021, ne-am putut concentra pe un singur flux de lucru și am remediat rapid după cum este necesar (performanță Registrul Amazon de containere elastice (Amazon ECR), actualizarea serviciului Amazon OpenSearch, actualizarea instrumentelor noastre și multe altele) cu un impact minim asupra activității în desfășurare a cercetătorilor de date. Pe măsură ce îmbunătățirile AWS și Kubeflow devin disponibile, le putem încorpora după cum credem de cuviință.

Acest lucru ne aduce la un aspect important și subestimat al adoptării Kubeflow pe AWS. Unul dintre rezultatele esențiale ale acestei călătorii este capacitatea de a implementa upgrade și îmbunătățiri la Kubeflow fără probleme pentru oamenii noștri de știință de date. Deși am discutat mai devreme despre abordarea noastră, ne bazăm și pe manifestele Kubeflow furnizate de AWS. Am început călătoria noastră Kubeflow ca o dovadă a conceptului în 2019, înainte de lansarea versiunii 1.0.0. (Suntem în prezent pe 1.4.1, evaluând 1.5. AWS lucrează deja la versiunea 1.6.) În ultimii 3 ani, au existat cel puțin șase versiuni cu conținut substanțial. Prin abordarea lor disciplinată de integrare și validare a acestor upgrade-uri și de lansare a manifestelor într-un program previzibil și de încredere, echipa Kubeflow de la AWS a fost crucială pentru a permite echipei athenahealth MLOps să ne planifice foaia de parcurs de dezvoltare și, în consecință, alocările de resurse și domeniile noastre de interes. , mai departe în viitor cu mai multă încredere.

Puteți urma Depozitul GitHub AWS Labs pentru a urmări toate contribuțiile AWS la Kubeflow. De asemenea, puteți găsi echipe AWS pe site-ul Canalul Kubeflow #AWS Slack; feedbackul dvs. de acolo ajută AWS să prioritizeze următoarele caracteristici care să contribuie la proiectul Kubeflow.

---

Despre autori

Kanwaljit Khurmi este arhitect senior de soluții la Amazon Web Services. El lucrează cu clienții AWS pentru a oferi îndrumări și asistență tehnică, ajutându-i să-și îmbunătățească valoarea soluțiilor atunci când folosesc AWS. Kanwaljit este specializată în a ajuta clienții cu aplicații containerizate și de învățare automată.

Tyler Kalbach este membru principal al personalului tehnic la athenahealth. Tyler are aproximativ 7 ani de experiență în analiză, știința datelor, rețele neuronale și dezvoltarea de aplicații de învățare automată în spațiul medical. El a contribuit la mai multe soluții de învățare automată care deservesc în prezent traficul de producție. Lucrând în prezent ca cercetător principal de date în organizația de inginerie a athenahealth, Tyler a făcut parte din echipa care a construit noua platformă de instruire pentru învățare automată pentru athenahealth de la începutul acestui efort.

Victor Krylov este membru principal al personalului tehnic la athenahealth. Victor este inginer și scrum master, ajutând oamenii de știință în date să construiască conducte sigure și rapide de învățare automată. În athenahealth a lucrat la interfețe, comandă clinică, prescripții, programare, analiză și acum învățarea automată. Prețuiește codul scris curat și bine testat pe unități, dar are o obsesie nesănătoasă pentru codurile unice. În timpul liber, îi place să asculte podcasturi în timp ce își plimbă câinele.

Sasank Vemuri este membru principal al personalului tehnic la athenahealth. Are experiență de lucru în dezvoltarea de soluții bazate pe date în domenii precum asistența medicală, asigurările și bioinformatica. Sasank lucrează în prezent cu proiectarea și dezvoltarea platformelor de instruire și inferență de învățare automată pe AWS și Kubernetes care ajută la instruirea și implementarea soluțiilor ML la scară.

Anu Tumkur este arhitect la athenahealth. Anu are peste două decenii de arhitectură, design, experiență de dezvoltare în construirea diverselor produse software în învățarea automată, operațiuni cloud, date mari, conducte de date distribuite în timp real, tehnologie publicitară, analiză de date, analiză rețelelor sociale. În prezent, Anu lucrează ca arhitect în organizația de inginerie de produs a athenahealth pe echipele Platformei de învățare automată și a pipelinei de date.

William Tsen este Senior Engineering Manager la athenahealth. El are peste 20 de ani de experiență în conducerea ingineriei în construirea de soluții în IT pentru asistență medicală, calcule distribuite de date mari, rețele optice inteligente, sisteme de editare video în timp real, software pentru întreprinderi și subscriere de grup de asistență medicală. William conduce în prezent două echipe extraordinare la athenahealth, echipele de operațiuni de învățare automată și echipele de inginerie DevOps, în organizația de inginerie de produs.