Hozzon létre megismételhető, biztonságos és bővíthető végpontok közötti gépi tanulási munkafolyamatokat a Kubeflow segítségével az AWS-en

Ez egy vendég blogbejegyzés, amelyet az athenahealth írt.

athénegészség a hálózatalapú szoftverek és szolgáltatások vezető szolgáltatója egészségügyi csoportok és egészségügyi rendszerek számára országszerte. Elektronikus egészségügyi nyilvántartásai, bevételciklus-kezelése és betegelköteleződési eszközei lehetővé teszik a hozzáférést bármikor, bárhol, jobb pénzügyi eredményeket biztosítva ügyfelei számára, és lehetővé teszik a szolgáltató ügyfelei számára, hogy jobb minőségű ellátást nyújtsanak.

A mesterséges intelligencia (AI) terén az athenahealth adattudományt és gépi tanulást (ML) használ az üzleti folyamatok felgyorsítására, valamint több szolgáltatásra vonatkozó ajánlások, előrejelzések és betekintések biztosítására. Az automatizált dokumentumszolgáltatásokban való első bevezetésétől, a szolgáltatók és a betegek közötti dokumentumok millióinak érintésmentes feldolgozásával, a virtuális asszisztensekkel kapcsolatos újabb munkákig és a bevételi ciklus teljesítményének javításáig az athenahealth továbbra is alkalmazza az AI-t a hatékonyság, a szolgáltatási képességek és a szolgáltatók jobb eredményének növelése érdekében. és betegeik.

Ez a blogbejegyzés bemutatja, hogyan használja az athenahealth Kubeflow az AWS-en (a Kubeflow AWS-specifikus disztribúciója) egy olyan végpontok közötti adattudományi munkafolyamat felépítéséhez és egyszerűsítéséhez, amely megőrzi az alapvető eszközöket, optimalizálja a működési hatékonyságot, növeli az adattudósok termelékenységét, és előkészíti az ML-képességeik egyszerűbb bővítését.

A Kubeflow egy nyílt forráskódú ML-platform, amely az ML-munkafolyamatok telepítését a Kubernetes rendszeren egyszerűvé, hordozhatóvá és méretezhetővé teszi. A Kubeflow ezt a releváns nyílt forráskódú eszközök beépítésével éri el, amelyek jól illeszkednek a Kuberneteshez. E projektek némelyike ​​közé tartozik az Argo a pipeline hangszereléshez, az Istio a szervizhálóhoz, a Jupyter a notebookokhoz, a Spark, a TensorBoard és a Katib. A Kubeflow Pipelines segít a hordozható, méretezhető ML munkafolyamatok felépítésében és üzembe helyezésében, amelyek tartalmazhatnak olyan lépéseket, mint az adatkinyerés, az előfeldolgozás, a modell betanítás és a modellértékelés megismételhető folyamatok formájában.

Az AWS saját Kubeflow disztribúciójával járul hozzá a nyílt forráskódú Kubeflow közösséghez (az AWS-en Kubeflow néven), amely segít az olyan szervezeteknek, mint az athenahealth rendkívül megbízható, biztonságos, hordozható és méretezhető ML munkafolyamatok létrehozásában, csökkentett működési többletköltséggel az AWS által felügyelt szolgáltatásokkal való integráció révén. Az AWS különféle Kubeflow-telepítési lehetőségeket kínál, például a telepítést Amazon Cognito, telepítés a Amazon Relációs adatbázis-szolgáltatás (Amazon RDS) és Amazon egyszerű tárolási szolgáltatás (Amazon S3), és vanília bevetés. A szolgáltatások integrációjával és az egyes opciókhoz elérhető kiegészítőkkel kapcsolatos részletekért lásd: bevetés.

Ma az AWS-en futó Kubeflow egyértelmű utat biztosít a Kubeflow használatához, a következő AWS-szolgáltatásokkal kiegészítve:

Sok AWS-ügyfél használja a Kubeflow-t az AWS-elosztáson, beleértve az athenahealth-et is.

Itt az athenahealth MLOps csapata megvitatja azokat a kihívásokat, amelyekkel szembesültek, és azokat a megoldásokat, amelyeket Kubeflow útjuk során hoztak létre.

Kihívások a korábbi ML környezettel

A Kubeflow AWS-en való elfogadása előtt adattudósaink szabványos eszközkészletet és olyan folyamatot használtak, amely rugalmasságot tett lehetővé az adott modell betanításához használt technológia és munkafolyamat terén. A szabványosított eszközök példakénti összetevői közé tartozik az adatfeldolgozási API, a biztonsági ellenőrző eszközök, az athenahealth egy másik csapata által épített és karbantartott CI/CD folyamat, valamint az MLOps csapat által épített és karbantartott közös kiszolgálóplatform. A mesterséges intelligencia és az ML használatának előrehaladtával azonban az egyes modellekhez létrehozott eszközök és infrastruktúra sokfélesége nőtt. Bár a meglévő folyamatot továbbra is támogatni tudtuk, a következő kihívásokat láttuk a láthatáron:

• Karbantartás és növekedés – A modell-oktatókörnyezetek reprodukálása és karbantartása több erőfeszítést igényelt a telepített modellek számának növekedésével. Minden projekt részletes dokumentációt tartott fenn, amely felvázolta, hogyan használták fel az egyes szkripteket a végső modell felépítéséhez. Sok esetben ez egy bonyolult folyamat volt, amely 5-10 szkriptet tartalmazott, egyenként több kimenettel. Ezeket manuálisan kellett nyomon követni, részletes utasításokkal arra vonatkozóan, hogy az egyes kimeneteket hogyan használják fel a következő folyamatokban. Ennek fenntartása idővel nehézkessé vált. Ráadásul a projektek összetettebbé válásával az eszközök száma is növekedett. Például a legtöbb modell a Sparkot és a TensorFlow-t használta GPU-kkal, amihez több környezeti konfigurációra volt szükség. Idővel a felhasználók az eszközök újabb verzióira váltottak fejlesztői környezetükben, de nem tudtak régebbi szkripteket futtatni, amikor ezek a verziók összeférhetetlenné váltak. Következésképpen a régebbi projektek karbantartása és bővítése több mérnöki időt és erőfeszítést igényelt. Ráadásul, ahogy új adattudósok csatlakoztak a csapathoz, a tudásátadás és a beépítés több időt vett igénybe, mivel a helyi környezetek szinkronizálása számos dokumentálatlan függőséget tartalmazott. A projektek közötti váltás ugyanazokkal a problémákkal szembesült, mert minden modellnek megvoltak a saját munkafolyamatai.
• Biztonság – Komolyan vesszük a biztonságot, ezért kiemelten kezeljük az ML-hez és az adattudományhoz kapcsolódó szerződéses, jogi és szabályozási kötelezettségek betartását. Az adatokat meghatározott módokon kell felhasználni, tárolni és elérni, és robusztus folyamatokat építünk be annak biztosítására, hogy gyakorlataink megfeleljenek jogi kötelezettségeinknek, valamint megfeleljenek az iparág legjobb gyakorlatainak. A Kubeflow bevezetése előtt az adatok meghatározott módon történő tárolásának és elérésének biztosítása magában foglalta a rendszeres ellenőrzést több, különböző munkafolyamatban. Tudtuk, hogy növelhetjük a hatékonyságot, ha ezeket a sokféle munkafolyamatot egyetlen platformon egyesítjük. Ennek a platformnak azonban elég rugalmasnak kell lennie ahhoz, hogy jól integrálódjon szabványosított eszközeinkkel.
• Művelet – A munkafolyamatok naplózásának és nyomon követésének központosításával lehetőséget láttunk a működési hatékonyság és irányítás növelésére is. Mivel minden csapat kifejlesztette saját eszközeit, ezeket az információkat minden munkafolyamatból külön-külön gyűjtöttük, és összesítettük.

Az adattudományi csapat különféle megoldásokat értékelt a munkafolyamatok konszolidálására. Ezen követelmények teljesítése mellett olyan megoldást kerestünk, amely zökkenőmentesen illeszkedik a meglévő szabványosított infrastruktúrához és eszközökhöz. Munkafolyamat-megoldásunkként az Amazon EKS-t és az AWS-en futó Kubeflow-t választottuk.

Az adattudós fejlesztési ciklus a Kubeflow-val

Egy adattudományi projekt tiszta lappal kezdődik: nincs adat, nincs kód, csak az ML-lel megoldható üzleti probléma. Az első feladat egy proof of concept (POC) annak felderítése, hogy az adatok elegendő jelet tartalmaznak-e ahhoz, hogy egy ML-modell hatékonyan megoldja az üzleti problémát, kezdve a nyers adatkészlet lekérdezésével a Snowflake adattárházunkból. Ez a szakasz iteratív, és az adatkutatók Kubernetes podokat vagy Kubeflow Jupyter notebookokat használnak a folyamat során.

Kubeflow-fürtünk a Karpenter-fürt automatikus skálázóját használja, amely megkönnyíti az erőforrások felpörgetését az adatkutatók számára, mivel csak a kívánt példánytípusok meghatározására kell összpontosítaniuk, míg a kiépítési munkát előre meghatározott Karpenter-szolgáltatók végzik. Külön szolgáltatóink vannak a CPU- és GPU-példánytípusokhoz, és az Amazon EKS által támogatott összes példány e két kategória valamelyikébe tartozik a szolgáltató konfigurációja szerint. Az adatkutatók csomópontválasztók segítségével választják ki a példánytípusokat, a Karpenter pedig gondoskodik a csomópont-életciklus kezeléséről.

A lekérdezés kidolgozása után az adattudósok kivonják a nyers adatokat az Amazon S3 egyik helyére, majd elindítanak egy Jupyter notebookot az AWS Kubeflow UI-ról az adatok felfedezéséhez. A cél az első modell betanításához használt jellemzőkészlet létrehozása. Ez lehetővé teszi az adatkutatók számára, hogy megállapítsák, van-e elegendő jel az adatokban az ügyfél üzleti igényeinek kielégítéséhez.

Miután az eredmények kielégítőek, az adatkutatók a fejlesztési ciklus következő szakaszába lépnek, és felfedezéseiket robusztus folyamattá alakítják. A POC-kódot termelési minőségű kóddá alakítják, amely méretben fut. A jóváhagyott könyvtárak használatával történő megfelelőség biztosítása érdekében létrejön egy tároló a megfelelő alap Docker lemezképpel. Adattudósaink számára azt találtuk, hogy egy szabványos Python, TensorFlow és Spark alapkép biztosítása elegendő rugalmasságot biztosít a legtöbb, ha nem az összes munkaterheléshez. Ezután az összetevő Docker-fájlját használhatják a fejlesztői környezet további testreszabásához. Ezt a Docker-fájlt azután a CI/CD-folyamat felhasználja a termelésben használt összetevők képének felépítésére, így megőrzi a konzisztenciát a fejlesztési és a termelési környezet között.

Van egy eszközünk, amely lehetővé teszi az adattudósok számára, hogy fejlesztői környezetüket Kubernetesen futó podban indítsák el. Amikor ez a pod fut, az adatkutatók közvetlenül csatolhatják a Visual Studio Code IDE-t a podhoz, és hibakeresést végezhetnek a modellkódjukon. Miután sikeresen lefutott a kód, átküldhetik a módosításaikat a git-nek, és egy új fejlesztői környezet jön létre a legújabb változtatásokkal.

A szabványos adattudományi folyamat szakaszokból áll, amelyek magukban foglalják a kinyerést, az előfeldolgozást, a betanítást és az értékelést. A folyamat minden szakasza összetevőként jelenik meg a Kubeflow-ban, amely egy Kubernetes podból áll, amely egy parancsot futtat néhány paraméterként átadott információval. Ezek a paraméterek lehetnek statikus értékek vagy hivatkozások egy korábbi komponens kimenetére. A podban használt Docker-kép a CI/CD folyamatból épül fel. A folyamat részletei a következő részben tárgyalt CI/CD munkafolyamatban találhatók.

Fejlesztési ciklus a Kubeflow-n. A fejlesztési munkafolyamat bal oldalon kezdődik a POC-val. Az elkészült modellt az Amazon ECS-en futó athenahealth modellkiszolgáló platformra telepítik.

Az automatizált munkafolyamatokat támogató CI/CD folyamat

A CI/CD folyamatunk részeként a Jenkins segítségével párhuzamosan készítjük el és teszteljük az összes Kubeflow komponensképet. Sikeres befejezés esetén a folyamatösszetevő-sablon referenciamutatókat tartalmaz a képekre, és az eredményül kapott folyamat feltöltődik a Kubeflow-ba. A Jenkins-folyamat paraméterei lehetővé teszik a felhasználók számára, hogy elindítsák a folyamatokat, és lefuttathassák a modell betanítási tesztjeit a sikeres buildek után.

Alternatív megoldásként a rövid fejlesztési ciklus fenntartása érdekében az adattudósok a folyamatot a helyi gépükről is elindíthatják, módosítva az esetlegesen kísérletezett folyamatparamétereket.

Létezik olyan eszköz, amely biztosítja, hogy a CI/CD build referenciamutatóit alapértelmezés szerint használják. Ha van telepíthető melléktermék a repóban, akkor a CI/CD logika továbbra is telepíti a mellékterméket az Amazon ECS-en futó athenahealth modell kiszolgáló platformra (a Prediction Service). AWS Fargate. Miután ezek a szakaszok lejártak, az adattudós egyesíti a kódot az elsődleges ágba. Ezután a folyamatok és a telepíthető műtermékek élesre kerülnek.

CI/CD telepítési munkafolyamat. Ez a diagram a Data Science felépítési és üzembe helyezési munkafolyamatát írja le. A CI/CD folyamatot a Jenkins.

Biztonság

Adattudományi munkafolyamataink megszilárdítása során centralizálni tudtuk a képzési folyamat biztosításának megközelítését. Ebben a részben az adat- és fürtbiztonsággal kapcsolatos megközelítésünket tárgyaljuk.

Adatbiztonság

Az adatbiztonság rendkívül fontos az athenahealthnél. Emiatt olyan infrastruktúrát fejlesztünk és tartunk fenn, amely teljes mértékben megfelel az ezen adatok biztonságát és integritását védő előírásoknak és szabványoknak.

Annak érdekében, hogy megfeleljünk az adatmegfelelőségi szabványoknak, az AWS-infrastruktúránkat az athenahealth vállalati irányelveinknek megfelelően biztosítjuk. A két fő adattár az Amazon RDS a nagymértékben méretezhető csővezeték-metaadatokhoz, valamint az Amazon S3 a folyamat- és modelltermékekhez. Az Amazon S3 esetében biztosítjuk a tárolók titkosítását, a HTTPS-végpontok kényszerítését, valamint a gyűjtőkör-házirendek és AWS Identity and Access Management Az (IAM) szerepkörök a legkisebb jogosultság elvét követik az adatokhoz való hozzáférés engedélyezése során. Ez igaz az Amazon RDS-adatokra is: a titkosítás mindig engedélyezve van, a biztonsági csoportok és a hitelesítő adatok elérése pedig a legkisebb jogosultság elvét követi. Ez a szabványosítás biztosítja, hogy csak az arra jogosult felek férhessenek hozzá az adatokhoz, és ezt a hozzáférést nyomon követik.

Ezen intézkedések mellett a platform biztonsági fenyegetésértékeléseken, valamint folyamatos biztonsági és megfelelőségi vizsgálaton is átesik.

Az adatmegőrzési követelményeket az adatéletciklus-kezelésen keresztül is kezeljük minden érzékeny adatokat tartalmazó S3 gyűjtőcsoport esetében. Ez a házirend automatikusan áthelyezi az adatokat ide Amazon S3 gleccser 30 napos létrehozás után. Az ez alóli kivételeket adatlekéréssel kezelik, és eseti alapon jóváhagyják vagy elutasítják. Ez biztosítja, hogy minden munkafolyamat megfeleljen az adatmegőrzési szabályzatnak. Ez megoldja az adatok helyreállításával kapcsolatos problémát is, ha egy modell rosszul teljesít, és újraképzésre van szükség, vagy ha egy új modellt egy régebbi modell adatkészletének korábbi iterációjához képest kell kiértékelni.

Az Amazon S3-hoz és az Amazon RDS-hez való hozzáférés korlátozására a Kubeflow-n belül az AWS-en és az Amazon EKS-en az IRSA-t (IAM Roles for Service Accounts) használjuk, amely IAM-alapú engedélykiépítést biztosít a Kubernetes-en belüli erőforrásokhoz. A Kubeflow minden bérlőjének egyedi, előre létrehozott szolgáltatási fiókja van, amelyet egy kifejezetten a bérlői hozzáférési követelmények teljesítésére létrehozott IAM-szerepkörhöz kötünk. A bérlőkhöz való felhasználói hozzáférés az Amazon Cognito felhasználói csoportok tagságával is korlátozott minden egyes felhasználó számára. Amikor egy felhasználó hitelesítve van a fürtben, a generált token csoportjogosultságot tartalmaz, és a Kubernetes RBAC ezen információk alapján engedélyezi vagy megtagadja a hozzáférést a fürt egy adott erőforrásához. Ezt a beállítást a következő részben ismertetjük részletesebben.

Fürtbiztonság többfelhasználós elkülönítéssel

Amint azt az előző részben megjegyeztük, az adatkutatók feltáró adatelemzést végeznek, adatelemzést futtatnak, és ML modelleket képeznek. Az erőforrások kiosztásához, az adatok rendszerezéséhez és a munkafolyamatok projektek alapján történő kezeléséhez a Kubeflow on AWS Kubernetes névtereken alapuló elkülönítést biztosít. Ez az elkülönítés a Kubeflow felhasználói felülettel való interakcióhoz működik; azonban nem biztosít semmilyen eszközt a Kubernetes API-hoz való hozzáférés szabályozásához a Kubectl használatával. Ez azt jelenti, hogy a felhasználói hozzáférés a Kubeflow felhasználói felületén szabályozható, de a Kubernetes API-n keresztül nem a Kubectl-en keresztül.

Az alábbi ábrán bemutatott architektúra a Kubeflow projektekhez való hozzáférésének egységesítése révén kezeli ezt a problémát a csoporttagságok alapján. Ennek eléréséhez kihasználtuk a Kubeflow on AWS jegyzékeit, amelyek integrálva vannak az Amazon Cognito felhasználói csoportjaival. Ezenkívül Kubernetes szerepkör-alapú hozzáférés-vezérlést (RBAC) használunk a fürtön belüli jogosultság vezérlésére. A felhasználói engedélyek az Amazon Cognito csoporttagságon alapulnak. Ezt az információt az OIDC-ügyfél által generált tokennel továbbítják a fürtnek. Ez a folyamat leegyszerűsödik a beépített Amazon EKS funkciónak köszönhetően, amely lehetővé teszi az OIDC identitásszolgáltatók társítását a fürthöz való hitelesítéshez.

Alapértelmezés szerint az Amazon EKS hitelesítést az IAM hitelesítő végzi, amely egy olyan eszköz, amely lehetővé teszi az EKS-fürttel történő hitelesítést az IAM hitelesítő adatok használatával. Ennek a hitelesítési módszernek megvannak a maga előnyei; azonban nem alkalmas a mi használati esetünkre, mert az athenahealth a Microsoft Azure Active Directoryt használja az identitásszolgáltatáshoz a szervezeten belül.

Kubernetes névtér elkülönítése. Az adatkutatók tagságot szerezhetnek egyetlen vagy több csoportban is, ha munkájukhoz szükséges. A hozzáférést rendszeresen felülvizsgálják, és szükség szerint eltávolítják.

Az Azure Active Directory, amely egy vállalati szintű identitásszolgáltatás, az igazság forrása a felhasználók Kubeflow-fürthöz való hozzáférésének szabályozásához. Ennek beállítása magában foglalja egy Azure Enterprise Application létrehozását, amely egyszerű szolgáltatásként működik, és csoportokat ad hozzá a különböző bérlőkhöz, amelyek hozzáférést igényelnek a fürthöz. Ez a beállítás az Azure-ban tükröződik az Amazon Cognitoban egy összevont OIDC identitásszolgáltató beállításával, amely kiszervezi a hitelesítési felelősséget az Azure-nak. Az Azure-csoportokhoz való hozzáférést a SailPoint IdentityIQ vezérli, amely hozzáférési kérelmeket küld a projekt tulajdonosának, hogy engedélyezze vagy tiltsa meg. Az Amazon Cognito felhasználói csoportjában két alkalmazáskliens jön létre: az egyik a Kubernetes-fürt hitelesítésének beállítására szolgál az OIDC identitásszolgáltató segítségével, a másik pedig a Kubeflow hitelesítés biztosítására szolgál a Kubeflow felhasználói felületen. Ezek az ügyfelek úgy vannak beállítva, hogy a fürttel történő hitelesítéskor csoportjogosultságokat adjanak át, és ezek a csoportjogcímek az RBAC mellett használatosak a fürtön belüli jogosultság beállítására.

A Kubernetes RBAC szerepkör-összerendelések be vannak állítva a csoportok és a Kubeflow-edit fürtszerep között, amely a Kubeflow fürtbe történő telepítése után jön létre. Ez a szerepkör-összerendelés biztosítja, hogy az OIDC-n keresztüli bejelentkezést követően a fürttel interakcióba lépő felhasználók hozzáférjenek azokhoz a névterekhez, amelyekhez a csoportjogosultságukban meghatározott engedélyekkel rendelkeznek. Bár ez működik a fürttel Kubectl használatával interakcióba lépő felhasználók számára, a Kubeflow felhasználói felület jelenleg nem biztosít hozzáférést a felhasználók számára a csoporttagság alapján, mivel nem használja az RBAC-t. Ehelyett az Istio engedélyezési házirend-erőforrást használja a felhasználók hozzáférésének szabályozására. Ennek a kihívásnak a leküzdése érdekében kifejlesztettünk egy egyéni vezérlőt, amely az Amazon Cognito csoportok lekérdezésével szinkronizálja a felhasználókat, és nem csoportonként, hanem minden felhasználóhoz ad hozzá vagy távolítja el a megfelelő szerep-összerendeléseket. Ez a beállítás lehetővé teszi a felhasználók számára, hogy azonos szintű jogosultságokkal rendelkezzenek a Kubeflow felhasználói felülettel és a Kubectl-lel való interakció során.

Működési hatékonyság

Ebben a részben azt tárgyaljuk, hogyan használtuk ki a rendelkezésünkre álló nyílt forráskódú és AWS-eszközöket munkafolyamataink kezeléséhez és hibakereséséhez, valamint a Kubeflow frissítésének működési hatásának minimalizálásához.

Naplózás és megfigyelés

A naplózáshoz a FluentD-t használjuk, hogy az összes konténernaplónkat továbbítsa Amazon OpenSearch szolgáltatás és rendszermérők a Prometheus számára. Ezután a Kibanát és a Grafana UI-t használjuk a naplók és metrikák keresésére és szűrésére. Az alábbi diagram leírja, hogyan állítjuk be ezt.

Kubeflow naplózás. A Grafana felhasználói felületet és a Kibanát egyaránt használjuk a naplók megtekintéséhez és átvizsgálásához

A következő képernyőkép egy Kibana UI nézet a folyamatunkból.

Minta Kibana UI nézet. A Kibana testreszabott nézeteket tesz lehetővé.

Biztonságos Kubeflow-fürtfrissítések

Miközben a felhasználókat bevonjuk a Kubeflowba az AWS rendszeren, megbízható és következetes felhasználói élményt tartunk fenn, miközben lehetővé tesszük az MLOps csapata számára, hogy agilis maradjon az új funkciók kiadásával és integrálásával. A Kustomize látszólag modulárisnak tűnik számunkra, hogy lehetővé tegye egy-egy összetevő működését és frissítését anélkül, hogy ez másokat befolyásolna, ezáltal lehetővé téve új képességek hozzáadását a felhasználók minimális megzavarása mellett. A gyakorlatban azonban vannak olyan forgatókönyvek, amikor a legjobb megoldás egy új Kubernetes-fürt létrehozása, ahelyett, hogy komponensszintű frissítéseket alkalmaznának a meglévő fürtökhöz. Két olyan felhasználási esetet találtunk, ahol ésszerűbb volt teljesen új klasztereket létrehozni:

• Frissítés Kubernetes-verzióra, ahol az AWS helyben biztosítja a fürtfrissítéseket. Nehézsé válik azonban annak tesztelése, hogy a Kubeflow és a Kubernetes erőforrások mindegyike a tervezett módon működik-e, és a jegyzékek megőrzik-e a visszamenőleges kompatibilitást.
• A Kubeflow frissítése egy újabb kiadásra, amelyhez számos funkció került hozzáadásra vagy módosításra, és szinte mindig nem kecsegtető ötlet egy meglévő Kubernetes-fürtön a helyben történő frissítések végrehajtása.

A probléma megoldása során olyan stratégiát dolgoztunk ki, amely lehetővé teszi számunkra a fürtök biztonságos cseréjét a meglévő munkaterhelések befolyásolása nélkül. Ennek eléréséhez a következő kritériumoknak kellett megfelelnünk:

• Különítse el a Kubeflow tároló- és számítási erőforrásait úgy, hogy a folyamat metaadatai, melléktermékei és felhasználói adatai megmaradjanak a régebbi fürt leválasztásakor.
• Integrálja a Kubeflow-val az AWS-jegyzékekben, így a Kubeflow verziófrissítéskor minimális változtatásokra van szükség
• Könnyedén visszaállíthatja, ha a fürt frissítése után a dolgok rosszul mennének
• Rendelkezik egy egyszerű kezelőfelülettel a jelölt fürt éles szintre emeléséhez

A következő diagram ezt az architektúrát szemlélteti.

Biztonságos Kubeflow-fürtfrissítés. Amint a Kubeflow Candidate tesztelése sikeres, a Route 53 frissítése révén a Kubeflow Prod-ba kerül.

A Kubeflow on AWS jegyzékei előre csomagolva az Amazon RDS és az Amazon S3 integrációjával. Ha ezekkel a felügyelt szolgáltatásokkal közös adattárként működnek, kék-zöld telepítési stratégiát tudunk felállítani. Ennek elérése érdekében gondoskodtunk arról, hogy a folyamatban lévő metaadatok megmaradjanak az Amazon RDS-ben, amely az EKS-fürttől függetlenül működik, és a folyamatnaplók és műtermékek megmaradnak az Amazon S3-ban. A folyamatban lévő metaadatok és műtermékek mellett a FluentD-t is beállítottuk, hogy a pod-naplókat az Amazon OpenSearch szolgáltatásba irányítsa.

Ez biztosítja, hogy a tárolóréteg teljesen el legyen különítve a számítási rétegtől, és ezáltal lehetővé válik a változások tesztelése a Kubeflow-verziófrissítések során egy teljesen új EKS-fürtön. Miután az összes teszt sikeres volt, egyszerűen megváltoztathatjuk a Amazon út 53 DNS-rekord a Kubeflow-t üzemeltető jelölt fürthöz. Ezenkívül a régi fürtöt néhány napig tartalékként futtatjuk, arra az esetre, ha vissza kell állítani.

Az Amazon EKS és a Kubeflow előnyei az AWS-en ML-folyamatunk számára

Az Amazon EKS és a Kubeflow on AWS csomag a fejlesztési munkafolyamatunkat olyan mintára helyezte át, amely erőteljesen ösztönzi az ismételhető modellképzést. Ezek az eszközök lehetővé teszik számunkra, hogy teljesen definiált fürtöket teljesen meghatározott bérlőkkel rendelkezzünk, és teljesen definiált kódot futtassunk.

A platform létrehozásából származó előnyök nagy része kevésbé kvantitatív, és inkább ahhoz kapcsolódik, hogy a munkafolyamatok hogyan fejlődtek a platformfejlesztők és a felhasználók számára egyaránt. Például a MinIO-t az Amazon S3 közvetlen elérése váltotta fel, ami közelebb visz minket az eredeti munkafolyamatokhoz, és csökkenti a fenntartandó szolgáltatások számát. Az Amazon RDS-t a Kubeflow háttérprogramjaként is használhatjuk, ami megkönnyíti a fürtök közötti migrációt, és lehetővé teszi számunkra, hogy éjjelenként biztonsági mentést készítsünk a csővezetékeinkről.

Hasznosnak találtuk a Kubeflow-integráció és az AWS által felügyelt szolgáltatások fejlesztését is. Például az Amazon RDS, Amazon S3 és Amazon Cognito előre konfigurált Kubeflow-ban az AWS-jegyzékekben, időt és energiát takarítunk meg a Kubeflow újabb disztribúcióira való frissítéssel. Amikor a hivatalos Kubeflow-jegyzékeket kézzel módosítottuk, az új verzióra való frissítés több hetet vett igénybe, a tervezéstől a tesztelésig.

Az Amazon EKS-re való váltás lehetőséget ad számunkra, hogy meghatározzuk a klaszterünket Kustomize-ban (jelenleg a Kubectl része) és a Terraformban. Kiderült, hogy platformmunkához a Kubernetes és a Terraform nagyon könnyen használható, miután elegendő időt szán a tanulásra. Sok iteráció után a rendelkezésünkre álló eszközök nagyon egyszerűvé teszik az olyan szabványos platformműveletek végrehajtását, mint egy összetevő frissítése vagy egy teljes fejlesztési fürt cseréje. Ahhoz képest, hogy a munkákat nyersen futtatjuk Amazon rugalmas számítási felhő (Amazon EC2) példányok esetében nehéz összehasonlítani, milyen óriási különbséget jelent, ha jól definiált podok vannak beépített garantált erőforrás-tisztítási és újrapróbálkozási mechanizmusokkal.

A Kubernetes nagyszerű biztonsági szabványokat kínál, és csak a felszínt karcoltuk meg annak, amit a többfelhasználós elkülönítés lehetővé tesz. A többfelhasználós elszigeteltséget olyan mintának tekintjük, amely a jövőben nagyobb kifizetődőséggel jár, amikor a képzési platform termelési szintű adatokat állít elő, és csapatunkon kívüli fejlesztőket is bevonunk.

Eközben a Kubeflow lehetővé teszi számunkra, hogy reprodukálható modellképzést végezzünk. Még ugyanazokkal az adatokkal sem hoz létre egyetlen képzés sem azonos modelleket, de megvan a következő legjobb dolog. A Kubeflow segítségével pontosan tudjuk, hogy milyen kódot és adatokat használtak a modell betanításához. A bevezetés nagymértékben javult, mivel folyamatunk minden lépése egyértelműen és programozottan meghatározott. Amikor az új adattudósok feladata egy hiba kijavítása, sokkal kevesebb kézfogásra van szükségük, mivel világos struktúra van a kód kimeneteinek felhasználására a szakaszok között.

A Kubeflow használata sok teljesítménynövekedést is eredményez az egyetlen EC2 példányon való futtatáshoz képest. A modellképzés során az adattudósoknak gyakran különböző eszközökre és optimalizálásra van szükségük az előfeldolgozáshoz és a képzéshez. Például az előfeldolgozást gyakran elosztott adatfeldolgozó eszközökkel, például a Sparkkal futtatják, míg a betanítást gyakran GPU-példányok segítségével. A Kubeflow-folyamatokkal különböző példánytípusokat adhatnak meg a folyamat különböző szakaszaihoz. Ez lehetővé teszi számukra, hogy az egyik szakaszban a nagy teljesítményű GPU-példányokat, egy másik szakaszban pedig kisebb gépekből álló flottát használhassanak elosztott feldolgozáshoz. Továbbá, mivel a Kubeflow folyamatok leírják a szakaszok közötti függőséget, a folyamatok párhuzamosan is futhatnak szakaszokat.

Végül, mivel létrehoztunk egy folyamatot a bérlők fürthöz való hozzáadására, mostantól formálisabb módja is van a csapatok bérlőinek regisztrálására a fürtben. Mivel a Kubecost segítségével követjük nyomon a költségeket EKS-fürtünkben, lehetővé teszi, hogy a költségeket egyetlen projekthez rendeljük hozzá ahelyett, hogy a fiók szintjén hozzárendelnénk a költségeket, amely magában foglalja az összes adattudományi projektet. A Kubecost névtérenként jelentést készít az elköltött pénzről, amely szorosan kapcsolódik a bérlőhöz vagy csapathoz, aki felelős a folyamat működtetéséért.

Minden előny ellenére felhívjuk a figyelmet arra, hogy csak akkor végezzünk ilyen típusú migrációt, ha a felhasználók teljes vételárat vállalnak. Azok a felhasználók, akik időt szánnak rá, sok előnyhöz jutnak az Amazon EKS és a Kubernetes használatából, de jelentős tanulási görbe van.

Következtetés

A Kubeflow on AWS folyamat megvalósításával a végpontok közötti ML infrastruktúránkban konszolidálni és szabványosítani tudtuk adattudományi munkafolyamatainkat, miközben megőriztük alapvető eszközeinket (például CI/CD és modellszolgáltatás). Adattudósaink mostantól ezen a munkafolyamaton alapuló projektek között mozoghatnak anélkül, hogy meg kellene tanulniuk egy teljesen más eszközkészletet. Néhány modellünk esetében kellemes meglepetés volt az új munkafolyamat (ötször gyorsabb) sebessége is, amely több oktatási iterációt tett lehetővé, és ennek következtében jobb előrejelzésű modelleket állított elő.

Szilárd alapot teremtettünk MLOps képességeink bővítésére, valamint projektjeink számának és méretének bővítésére. Például, ahogy megszilárdítjuk irányítási pozíciónkat a modellvonal és a nyomon követés terén, a fókuszt a több mint 15 munkafolyamatról egyetlenegyre csökkentettük. Amikor pedig 4 végén napvilágra került a Log2021shell sebezhetősége, egyetlen munkafolyamatra összpontosíthattunk, és szükség szerint gyorsan kijavíthattuk (teljesítve Amazon Elastic Container Registry (Amazon ECR) szkennel, frissíti az Amazon OpenSearch szolgáltatást, frissíti eszközeinket és még sok más), minimális hatással az adatkutatók folyamatban lévő munkájára. Amint elérhetővé válnak az AWS és a Kubeflow fejlesztések, tetszés szerint beépíthetjük őket.

Ezzel elérkeztünk az AWS bevezetésével kapcsolatos Kubeflow-nk egyik fontos és alábecsült aspektusához. Ennek az útnak az egyik kritikus eredménye az a képesség, hogy a Kubeflow frissítéseit és továbbfejlesztéseit zökkenőmentesen telepíthetjük adattudósaink számára. Bár korábban tárgyaltuk az ezzel kapcsolatos megközelítésünket, az AWS által biztosított Kubeflow manifesztekre is támaszkodunk. 2019-ben, az 1.0.0-s verzió megjelenése előtt kezdtük meg Kubeflow-útunkat a koncepció bizonyítékaként. (Jelenleg az 1.4.1-nél tartunk, az 1.5-ös értékelés alatt. Az AWS már dolgozik az 1.6-os verzión.) A közbeeső 3 évben legalább hat jelentős tartalommal bíró kiadás jelent meg. Az AWS Kubeflow csapata a frissítések integrálására és érvényesítésére, valamint a manifesztek kiszámítható, megbízható ütemterv szerinti kiadására irányuló fegyelmezett megközelítése révén kulcsfontosságú volt abban, hogy az athenahealth MLOps csapata megtervezhesse fejlesztési ütemtervét, következésképpen az erőforrások elosztását és a fókuszterületeket. , nagyobb bizalommal a jövőbe.

Követheted a AWS Labs GitHub adattár hogy nyomon kövesse az összes AWS-hozzájárulást a Kubeflow-hoz. Az AWS csapatokat is megtalálja a Kubeflow #AWS Slack Channel; az Ön visszajelzése segít az AWS-nek abban, hogy prioritást állítson elő a következő funkcióknak, amelyek hozzájárulnak a Kubeflow projekthez.

---

A szerzőkről

Kanwaljit Khurmi az Amazon Web Services vezető megoldási építésze. Együttműködik az AWS-ügyfelekkel, hogy útmutatást és technikai segítséget nyújtson, segítve őket megoldásaik értékének növelésében az AWS használata során. A Kanwaljit arra specializálódott, hogy segítse az ügyfeleket konténeres és gépi tanulási alkalmazásokkal.

Tyler Kalbach az athenahealth műszaki személyzetének vezető tagja. Tyler hozzávetőlegesen 7 éves tapasztalattal rendelkezik az Analytics, az adattudomány, a neurális hálózatok és a gépi tanulási alkalmazások fejlesztése terén az egészségügyi területen. Hozzájárult több gépi tanulási megoldáshoz, amelyek jelenleg a termelési forgalmat szolgálják ki. Tyler jelenleg az athenahealth mérnöki szervezetének vezető adattudósaként dolgozik annak a csapatnak, amely az athenahealth új gépi tanulási képzési platformját építette fel az erőfeszítés kezdetétől.

Viktor Krilov az athenahealth műszaki személyzetének vezető tagja. Victor mérnök és scrum-mester, aki segít az adattudósoknak biztonságos, gyors gépi tanulási folyamatok kialakításában. Az athenahealth területén interfészeken, klinikai rendeléseken, recepteken, ütemezésen, elemzéseken és most már gépi tanuláson is dolgozott. Nagyra értékeli a tisztán megírt és jól egységtesztelt kódot, de egészségtelen rögeszméje van az egysoros kóddal. Szabadidejében szívesen hallgat podcastokat, miközben kutyáját sétáltatja.

Sasank Vemuri az athenahealth műszaki személyzetének vezető tagja. Tapasztalattal rendelkezik adatvezérelt megoldások fejlesztésében olyan területeken, mint az egészségügy, a biztosítás és a bioinformatika. A Sasank jelenleg gépi tanulási képzési és következtetési platformok tervezésével és fejlesztésével foglalkozik az AWS-en és a Kubernetes-en, amelyek elősegítik a képzést és az ML-megoldások széles körű bevezetését.

Anu Tumkur az athenahealth építésze. Anu több mint két évtizedes építészeti, tervezési és fejlesztési tapasztalattal rendelkezik különféle szoftvertermékek gyártásában a gépi tanulás, felhőműveletek, big data, valós idejű elosztott adatfolyamok, hirdetéstechnológia, adatelemzés és közösségimédia-elemzés terén. Anu jelenleg építészként dolgozik az athenahealth termékmérnöki szervezetében a Machine Learning Platform és Data Pipeline csapatoknál.

William Tsen az athenahealth vezető mérnöki menedzsere. Több mint 20 éves mérnöki vezetői tapasztalattal rendelkezik az egészségügyi informatikai megoldások kiépítésében, a big data elosztott számítástechnikában, az intelligens optikai hálózatokban, a valós idejű videószerkesztő rendszerekben, a vállalati szoftverekben és a csoportos egészségügyi biztosítási szerződésekben. William jelenleg két nagyszerű csapatot vezet az athenahealthnél, a Machine Learning Operations és a DevOps mérnöki csapatokat a Product Engineering szervezetben.