Twórz powtarzalne, bezpieczne i rozszerzalne kompleksowe przepływy pracy uczenia maszynowego za pomocą Kubeflow na AWS

To jest gościnny wpis na blogu napisany wspólnie z athenahealth.

athenazdrowie wiodący dostawca oprogramowania i usług sieciowych dla grup medycznych i systemów opieki zdrowotnej w całym kraju. Elektroniczna dokumentacja medyczna, zarządzanie cyklem przychodów i narzędzia do angażowania pacjentów umożliwiają dostęp w dowolnym miejscu i czasie, zapewniając klientom lepsze wyniki finansowe i umożliwiając klientom usługodawców zapewnianie lepszej jakości opieki.

W przestrzeni sztucznej inteligencji (AI) athenahealth wykorzystuje naukę o danych i uczenie maszynowe (ML) do przyspieszenia procesów biznesowych i dostarczania rekomendacji, prognoz i wglądu w wiele usług. Od pierwszego wdrożenia w zautomatyzowanych usługach związanych z dokumentami, bezdotykowego przetwarzania milionów dokumentów dostawcy-pacjent, po nowszą pracę w wirtualnych asystentach i poprawę wydajności cyklu przychodów, athenahealth nadal stosuje sztuczną inteligencję, aby pomóc zwiększyć wydajność, możliwości usług i lepsze wyniki dla dostawców i ich pacjentów.

Ten wpis na blogu pokazuje, jak wykorzystuje athenahealth Kubeflow w AWS (dystrybucja Kubeflow specyficzna dla AWS) w celu zbudowania i usprawnienia kompleksowego przepływu pracy do nauki o danych, który zachowuje niezbędne narzędzia, optymalizuje wydajność operacyjną, zwiększa produktywność naukowców zajmujących się danymi i przygotowuje grunt pod łatwiejsze rozszerzanie ich możliwości ML.

Kubeflow to platforma ML typu open source przeznaczona do tworzenia prostych, przenośnych i skalowalnych wdrożeń przepływów pracy ML na Kubernetes. Kubeflow osiąga to poprzez włączenie odpowiednich narzędzi open source, które dobrze integrują się z Kubernetes. Niektóre z tych projektów obejmują Argo do aranżacji potoków, Istio do sieci usług, Jupyter do notebooków, Spark, TensorBoard i Katib. Kubeflow Pipelines pomaga tworzyć i wdrażać przenośne, skalowalne przepływy pracy ML, które mogą obejmować takie kroki, jak ekstrakcja danych, wstępne przetwarzanie, uczenie modeli i ocena modeli w formie powtarzalnych potoków.

AWS przyczynia się do społeczności Kubeflow typu open source, zapewniając własną dystrybucję Kubeflow (zwaną Kubeflow w AWS), która pomaga organizacjom takim jak athenahealth w tworzeniu wysoce niezawodnych, bezpiecznych, przenośnych i skalowalnych przepływów pracy ML przy zmniejszonym obciążeniu operacyjnym dzięki integracji z usługami zarządzanymi AWS. AWS zapewnia różne opcje wdrażania Kubeflow, takie jak wdrożenie z Amazon Cognito, wdrożenie z Usługa relacyjnych baz danych Amazon (Amazon RDS) i Usługa Amazon Simple Storage (Amazon S3) i wdrożenie waniliowe. Aby uzyskać szczegółowe informacje na temat integracji usług i dostępnych dodatków dla każdej z tych opcji, zobacz Rozlokowanie.

Dzisiaj Kubeflow w AWS zapewnia jasną ścieżkę do korzystania z Kubeflow, rozszerzoną o następujące usługi AWS:

Wielu klientów AWS korzysta z Kubeflow w dystrybucji AWS, w tym athenahealth.

W tym miejscu zespół athenahealth MLOps omawia wyzwania, które napotkali, oraz rozwiązania, które stworzyli podczas swojej podróży do Kubeflow.

Wyzwania z poprzednim środowiskiem ML

Przed przyjęciem Kubeflow na AWS nasi analitycy danych używali ustandaryzowanego zestawu narzędzi i procesu, który pozwalał na elastyczność w technologii i przepływie pracy używanym do trenowania danego modelu. Przykładowe składniki znormalizowanego oprzyrządowania obejmują interfejs API pozyskiwania danych, narzędzia do skanowania zabezpieczeń, potok CI/CD zbudowany i utrzymywany przez inny zespół w ramach athenahealth oraz wspólną platformę obsługującą zbudowaną i utrzymywaną przez zespół MLOps. Jednak wraz z dojrzewaniem naszego wykorzystania AI i ML, wzrosła różnorodność narzędzi i infrastruktury stworzonej dla każdego modelu. Chociaż nadal byliśmy w stanie wesprzeć istniejący proces, na horyzoncie widzieliśmy następujące wyzwania:

• Utrzymanie i wzrost – Odtwarzanie i utrzymywanie środowisk szkoleniowych modeli wymagało większego wysiłku wraz ze wzrostem liczby wdrożonych modeli. Każdy projekt zawierał szczegółową dokumentację, która przedstawiała, w jaki sposób każdy skrypt został wykorzystany do zbudowania ostatecznego modelu. W wielu przypadkach był to skomplikowany proces obejmujący od 5 do 10 skryptów, każdy z kilkoma wynikami. Musiało to być ręcznie śledzone wraz ze szczegółowymi instrukcjami, w jaki sposób każdy wynik zostanie wykorzystany w kolejnych procesach. Utrzymanie tego z biegiem czasu stało się kłopotliwe. Co więcej, w miarę jak projekty stawały się coraz bardziej złożone, zwiększała się również liczba narzędzi. Na przykład większość modeli wykorzystywała Spark i TensorFlow z procesorami graficznymi, co wymagało większej różnorodności konfiguracji środowiska. Z biegiem czasu użytkownicy przestawiali się na nowsze wersje narzędzi w swoich środowiskach programistycznych, ale potem nie mogli uruchamiać starszych skryptów, gdy te wersje stały się niekompatybilne. W związku z tym utrzymanie i rozszerzanie starszych projektów wymagało więcej czasu i wysiłku inżynieryjnego. Ponadto, gdy do zespołu dołączyli nowi analitycy danych, transfer wiedzy i onboarding zajęły więcej czasu, ponieważ synchronizacja środowisk lokalnych obejmowała wiele nieudokumentowanych zależności. Przełączanie między projektami napotykało te same problemy, ponieważ każdy model miał swoje własne przepływy pracy.
• Bezpieczeństwo – Poważnie traktujemy bezpieczeństwo, dlatego priorytetowo traktujemy zgodność ze wszystkimi zobowiązaniami umownymi, prawnymi i regulacyjnymi związanymi z ML i nauką o danych. Dane muszą być wykorzystywane, przechowywane i dostępne w określony sposób. Wprowadziliśmy solidne procesy, aby zapewnić, że nasze praktyki są zgodne z naszymi zobowiązaniami prawnymi, a także z najlepszymi praktykami w branży. Przed wdrożeniem Kubeflow zapewnienie, że dane były przechowywane i dostępne w określony sposób, wymagało regularnej weryfikacji w wielu różnych przepływach pracy. Wiedzieliśmy, że możemy poprawić wydajność, konsolidując te różnorodne przepływy pracy na jednej platformie. Jednak ta platforma musiałaby być wystarczająco elastyczna, aby dobrze zintegrować się z naszymi standardowymi narzędziami.
• operacje – Dostrzegliśmy również szansę na zwiększenie wydajności operacyjnej i zarządzania poprzez centralizację rejestrowania i monitorowania przepływów pracy. Ponieważ każdy zespół opracował własne narzędzia, zebraliśmy te informacje z każdego przepływu pracy indywidualnie i zagregowaliśmy je.

Zespół zajmujący się analizą danych ocenił różne rozwiązania w zakresie konsolidacji przepływów pracy. Oprócz spełnienia tych wymagań szukaliśmy rozwiązania, które bezproblemowo zintegrowałoby się z istniejącą ustandaryzowaną infrastrukturą i narzędziami. Wybraliśmy Amazon EKS i Kubeflow na AWS jako nasze rozwiązanie przepływu pracy.

Cykl rozwojowy data scientist z wykorzystaniem Kubeflow

Projekt data science zaczyna się od czystej karty: bez danych, bez kodu, tylko z problemem biznesowym, który można rozwiązać za pomocą ML. Pierwszym zadaniem jest weryfikacja koncepcji (POC), aby odkryć, czy dane zawierają wystarczający sygnał, aby model ML był skuteczny w rozwiązywaniu problemu biznesowego, zaczynając od zapytania o surowy zestaw danych z naszej hurtowni danych Snowflake. Ten etap jest iteracyjny, a analitycy danych używają podczas tego procesu Kubernetes pods lub notesów Kubeflow Jupyter.

Nasz klaster Kubeflow korzysta z automatycznego skalowania klastra Karpenter, co ułatwia analitykom danych rozkręcanie zasobów, ponieważ muszą oni skoncentrować się tylko na zdefiniowaniu żądanych typów instancji, podczas gdy praca administracyjnej jest wykonywana przez zestaw predefiniowanych dostawców Karpenter. Mamy oddzielnych dostawców dla typów instancji CPU i GPU, a wszystkie instancje obsługiwane przez Amazon EKS należą do jednej z tych dwóch kategorii zgodnie z naszą konfiguracją dostawcy. Analitycy danych wybierają typy instancji za pomocą selektorów węzłów, a Karpenter zajmuje się zarządzaniem cyklem życia węzła.

Po opracowaniu zapytania analitycy danych wyodrębniają surowe dane do lokalizacji w Amazon S3, a następnie uruchamiają notatnik Jupyter z interfejsu użytkownika AWS Kubeflow, aby eksplorować dane. Celem jest stworzenie zestawu funkcji, który będzie używany do trenowania pierwszego modelu. Pozwala to analitykom danych określić, czy w danych jest wystarczająco dużo sygnału, aby zaspokoić potrzeby biznesowe klienta.

Gdy wyniki są zadowalające, naukowcy zajmujący się danymi przechodzą do następnego etapu cyklu rozwojowego i przekształcają swoje odkrycia w solidny potok. Konwertują kod POC na kod o jakości produkcyjnej, który działa na dużą skalę. Aby zapewnić zgodność dzięki użyciu zatwierdzonych bibliotek, tworzony jest kontener z odpowiednim podstawowym obrazem platformy Docker. Dla naszych naukowców zajmujących się danymi stwierdziliśmy, że udostępnienie standardowego obrazu podstawowego języka Python, TensorFlow i Spark zapewnia wystarczającą elastyczność w przypadku większości, jeśli nie wszystkich, obciążeń. Następnie mogą użyć pliku Dockerfile swojego komponentu, aby jeszcze bardziej dostosować swoje środowisko programistyczne. Ten plik Dockerfile jest następnie wykorzystywany przez proces CI/CD do tworzenia obrazu komponentów, który będzie używany w środowisku produkcyjnym, zapewniając w ten sposób spójność między środowiskami programistycznymi i produkcyjnymi.

Mamy narzędzie, które daje analitykom danych możliwość uruchomienia środowiska programistycznego w podacie działającym na Kubernetes. Gdy ten zasobnik jest uruchomiony, analitycy danych mogą następnie dołączyć środowisko IDE programu Visual Studio Code bezpośrednio do zasobnika i debugować kod modelu. Po pomyślnym uruchomieniu kodu mogą następnie przekazać swoje zmiany do git i tworzone jest nowe środowisko programistyczne z najnowszymi zmianami.

Standardowy potok analizy danych składa się z etapów, które obejmują wyodrębnianie, wstępne przetwarzanie, szkolenie i ocenę. Każdy etap potoku pojawia się jako komponent w Kubeflow, który składa się z modułu Kubernetes, który uruchamia polecenie z pewnymi informacjami przekazanymi jako parametry. Te parametry mogą być wartościami statycznymi lub odwołaniami do danych wyjściowych z poprzedniego składnika. Obraz platformy Docker używany w zasobniku jest zbudowany z procesu CI/CD. Szczegóły tego procesu pojawiają się w przepływie pracy CI/CD omówionym w następnej sekcji.

Cykl rozwoju na Kubeflow. Obieg pracy deweloperskiej zaczyna się po lewej stronie od POC. Ukończony model jest wdrażany na platformie obsługującej model athenahealth działającej na Amazon ECS.

Proces CI/CD wspierający zautomatyzowane przepływy pracy

W ramach naszego procesu CI/CD używamy Jenkins do równoległego tworzenia i testowania wszystkich obrazów komponentów Kubeflow. Po pomyślnym zakończeniu szablon składnika potoku zawiera wskaźniki referencyjne do obrazów, a wynikowy potok jest przekazywany do Kubeflow. Parametry w potoku Jenkins umożliwiają użytkownikom uruchamianie potoków i uruchamianie testów uczenia modelu po pomyślnych kompilacjach.

Alternatywnie, aby utrzymać krótki cykl rozwoju, analitycy danych mogą również uruchomić potok ze swojej lokalnej maszyny, modyfikując dowolne parametry potoku, z którymi mogą eksperymentować.

Istnieją narzędzia, które zapewniają domyślne używanie wskaźników referencyjnych z kompilacji CI/CD. Jeśli w repozytorium znajduje się artefakt możliwy do wdrożenia, logika CI/CD będzie nadal wdrażać artefakt na platformie obsługującej model athenahealth (usługa przewidywania) działającej w Amazon ECS z AWS-Fargate. Po przejściu wszystkich tych etapów analityk danych łączy kod z główną gałęzią. Potoki i możliwe do rozmieszczenia artefakty są następnie wprowadzane do produkcji.

Przepływ pracy wdrażania CI/CD. Ten diagram opisuje przepływ pracy kompilacji i wdrażania Data Science. Proces CI/CD jest napędzany przez Jenkins.

Bezpieczeństwo

Konsolidując nasze przepływy pracy związane z analizą danych, byliśmy w stanie scentralizować nasze podejście do zabezpieczania potoku szkoleniowego. W tej sekcji omówimy nasze podejście do bezpieczeństwa danych i klastrów.

Bezpieczeństwo danych

Bezpieczeństwo danych ma ogromne znaczenie w athenahealth. Z tego powodu rozwijamy i utrzymujemy infrastrukturę w pełni zgodną z przepisami i standardami, które chronią bezpieczeństwo i integralność tych danych.

Aby upewnić się, że spełniamy standardy zgodności danych, udostępniamy naszą infrastrukturę AWS zgodnie z naszymi wytycznymi dla przedsiębiorstw athenahealth. Dwa główne magazyny danych to Amazon RDS dla wysoce skalowalnych metadanych potoku oraz Amazon S3 dla artefaktów potoku i modeli. W przypadku Amazon S3 zapewniamy, że zasobniki są szyfrowane, punkty końcowe HTTPS są egzekwowane, a zasady zasobników i AWS Zarządzanie tożsamością i dostępem Przy zezwalaniu na dostęp do danych role (IAM) przestrzegają zasad najmniejszych uprawnień. Dotyczy to również danych Amazon RDS: szyfrowanie jest zawsze włączone, a grupy bezpieczeństwa i dostęp do poświadczeń działają zgodnie z zasadą najmniejszych uprawnień. Ta standaryzacja zapewnia, że ​​tylko upoważnione strony mają dostęp do danych, a dostęp ten jest śledzony.

Oprócz tych środków platforma jest również poddawana ocenie zagrożeń bezpieczeństwa oraz ciągłym skanom bezpieczeństwa i zgodności.

Zajmujemy się również wymaganiami dotyczącymi przechowywania danych poprzez zarządzanie cyklem życia danych dla wszystkich zasobników S3, które zawierają dane wrażliwe. Ta zasada automatycznie przenosi dane do Lodowiec Amazon S3 po 30 dniach tworzenia. Wyjątki od tej reguły są zarządzane poprzez żądania pobierania danych i są zatwierdzane lub odrzucane indywidualnie dla każdego przypadku. Gwarantuje to, że wszystkie przepływy pracy są zgodne z zasadami przechowywania danych. Rozwiązuje to również problem z odzyskiwaniem danych, jeśli model działa słabo i wymagane jest ponowne uczenie lub gdy nowy model musi być oceniany na podstawie historycznej iteracji zestawu danych starszego modelu.

Do ograniczania dostępu do Amazon S3 i Amazon RDS z poziomu Kubeflow na AWS i Amazon EKS używamy IRSA (IAM Roles for Service Accounts), która zapewnia przydzielanie uprawnień w oparciu o IAM dla zasobów w Kubernetes. Każdy najemca w Kubeflow ma unikatowe, wstępnie utworzone konto usługi, które łączymy z rolą uprawnień utworzoną specjalnie w celu spełnienia wymagań dostępu najemcy. Dostęp użytkowników do najemców jest również ograniczony przy użyciu członkostwa grupowego użytkowników puli Amazon Cognito dla każdego użytkownika. Gdy użytkownik jest uwierzytelniany w klastrze, wygenerowany token zawiera oświadczenia grupy, a Kubernetes RBAC używa tych informacji, aby zezwolić lub odmówić dostępu do określonego zasobu w klastrze. Ta konfiguracja jest wyjaśniona bardziej szczegółowo w następnej sekcji.

Bezpieczeństwo klastra przy użyciu izolacji wielu użytkowników

Jak zauważyliśmy w poprzedniej sekcji, analitycy danych przeprowadzają eksploracyjne analizy danych, uruchamiają analizę danych i trenują modele ML. Aby alokować zasoby, organizować dane i zarządzać przepływami pracy w oparciu o projekty, Kubeflow w AWS zapewnia izolację opartą na przestrzeniach nazw Kubernetes. Ta izolacja działa w przypadku interakcji z interfejsem użytkownika Kubeflow; jednak nie zapewnia żadnych narzędzi do kontrolowania dostępu do interfejsu API Kubernetes za pomocą Kubectl. Oznacza to, że dostęp użytkownika można kontrolować w interfejsie użytkownika Kubeflow, ale nie za pośrednictwem interfejsu Kubernetes API za pośrednictwem Kubectl.

Architektura opisana na poniższym diagramie rozwiązuje ten problem, ujednolicając dostęp do projektów w Kubeflow na podstawie członkostwa w grupach. Aby to osiągnąć, skorzystaliśmy z manifestów Kubeflow on AWS, które są zintegrowane z pulami użytkowników Amazon Cognito. Ponadto używamy kontroli dostępu opartej na rolach (RBAC) Kubernetes do kontrolowania autoryzacji w klastrze. Uprawnienia użytkownika są przydzielane na podstawie członkostwa w grupie Amazon Cognito. Informacje te są przekazywane do klastra z tokenem wygenerowanym przez klienta OIDC. Proces ten jest uproszczony dzięki wbudowanej funkcjonalności Amazon EKS, która umożliwia kojarzenie dostawców tożsamości OIDC w celu uwierzytelniania w klastrze.

Domyślnie uwierzytelnianie Amazon EKS jest wykonywane przez uwierzytelnianie IAM, które jest narzędziem umożliwiającym uwierzytelnianie za pomocą klastra EKS przy użyciu poświadczeń IAM. Ta metoda uwierzytelniania ma swoje zalety; jednak nie jest to odpowiednie dla naszego przypadku użycia, ponieważ athenahealth używa usługi Microsoft Azure Active Directory do obsługi tożsamości w całej organizacji.

Izolacja przestrzeni nazw Kubernetes. Naukowcy zajmujący się danymi mogą uzyskać członkostwo w jednej lub wielu grupach w zależności od potrzeb ich pracy. Dostęp jest regularnie sprawdzany i usuwany w razie potrzeby.

Azure Active Directory, będąca usługą tożsamości dla całego przedsiębiorstwa, jest źródłem prawdy do kontrolowania dostępu użytkowników do klastra Kubeflow. Konfiguracja obejmuje tworzenie aplikacji Azure Enterprise Application, która działa jako jednostka usługi i dodawanie grup dla różnych dzierżawców, które wymagają dostępu do klastra. Ta konfiguracja na platformie Azure jest dublowana w Amazon Cognito przez skonfigurowanie federacyjnego dostawcy tożsamości OIDC, który zleca odpowiedzialność za uwierzytelnianie na platformę Azure. Dostęp do grup platformy Azure jest kontrolowany przez SailPoint IdentityIQ, który wysyła żądania dostępu do właściciela projektu, aby odpowiednio zezwolić lub odmówić. W puli użytkowników Amazon Cognito tworzone są dwa klienty aplikacji: jeden służy do konfigurowania uwierzytelniania dla klastra Kubernetes przy użyciu dostawcy tożsamości OIDC, a drugi do zabezpieczania uwierzytelniania Kubeflow w interfejsie Kubeflow. Ci klienci są skonfigurowani do przekazywania oświadczeń grup po uwierzytelnieniu w klastrze, a te oświadczenia grup są używane wraz z kontrolą RBAC do konfigurowania autoryzacji w klastrze.

Powiązania ról Kubernetes RBAC są konfigurowane między grupami i rolą klastra Kubeflow-edit, która jest tworzona po zainstalowaniu Kubeflow w klastrze. To powiązanie ról gwarantuje, że każdy użytkownik, który wchodzi w interakcję z klastrem po zalogowaniu się za pośrednictwem OIDC, może uzyskać dostęp do przestrzeni nazw, do których mają uprawnienia zdefiniowane w oświadczeniach grupy. Chociaż działa to w przypadku użytkowników wchodzących w interakcje z klastrem przy użyciu Kubectl, interfejs użytkownika Kubeflow obecnie nie zapewnia dostępu użytkownikom na podstawie członkostwa w grupie, ponieważ nie używa RBAC. Zamiast tego używa zasobu zasad autoryzacji Istio do kontrolowania dostępu dla użytkowników. Aby sprostać temu wyzwaniu, opracowaliśmy niestandardowy kontroler, który synchronizuje użytkowników poprzez odpytywanie grup Amazon Cognito i dodaje lub usuwa odpowiednie powiązania ról dla każdego użytkownika, a nie dla grup. Ta konfiguracja umożliwia użytkownikom korzystanie z tego samego poziomu uprawnień podczas interakcji z interfejsem Kubeflow i Kubectl.

Efektywność operacyjna

W tej sekcji omówimy, w jaki sposób wykorzystaliśmy dostępne nam narzędzia open source i AWS do zarządzania i debugowania naszych przepływów pracy, a także do minimalizowania wpływu operacyjnego aktualizacji Kubeflow.

Rejestrowanie i monitorowanie

Do rejestrowania używamy FluentD, aby przekazać wszystkie nasze dzienniki kontenerów do Usługa Amazon OpenSearch oraz metryki systemowe do Prometheusa. Następnie używamy Kibana i Grafana UI do wyszukiwania i filtrowania logów i metryk. Poniższy diagram opisuje, jak to skonfigurować.

Rejestrowanie Kubeflow. Używamy zarówno Grafana UI, jak i Kibana do przeglądania i przesiewania dzienników

Poniższy zrzut ekranu to widok interfejsu użytkownika Kibana z naszego potoku.

Przykładowy widok interfejsu użytkownika Kibana. Kibana pozwala na niestandardowe widoki.

Bezpieczne aktualizacje klastra Kubeflow

Wprowadzając użytkowników do Kubeflow w AWS, utrzymujemy niezawodne i spójne środowisko użytkownika, jednocześnie pozwalając zespołowi MLOps na zachowanie elastyczności przy wydawaniu i integrowaniu nowych funkcji. Z pozoru Kustomize wydaje się nam modułowy, aby umożliwić pracę i ulepszanie jednego komponentu na raz bez wpływu na inne, co pozwala nam dodawać nowe możliwości przy minimalnych zakłóceniach dla użytkowników. Jednak w praktyce istnieją scenariusze, w których najlepszym podejściem jest po prostu rozkręcenie nowego klastra Kubernetes zamiast stosowania uaktualnień na poziomie komponentów dla istniejących klastrów. Znaleźliśmy dwa przypadki użycia, w których bardziej sensowne było tworzenie zupełnie nowych klastrów:

• Uaktualnianie do wersji Kubernetes, w której AWS zapewnia uaktualnienia klastra w miejscu. Jednak trudno jest przetestować, czy każdy z zasobów Kubeflow i Kubernetes działa zgodnie z przeznaczeniem, a manifesty zachowują zgodność wsteczną.
• Uaktualnianie Kubeflow do nowszej wersji, w której dodano lub zmodyfikowano kilka funkcji i prawie zawsze nie jest obiecującym pomysłem przeprowadzanie uaktualnień w miejscu w istniejącym klastrze Kubernetes.

Rozwiązując ten problem, opracowaliśmy strategię, która umożliwia nam bezpieczne zastępowanie klastrów bez wpływu na istniejące obciążenia. Aby to osiągnąć, musieliśmy spełnić następujące kryteria:

• Oddziel zasoby pamięci masowej i obliczeniowe Kubeflow, aby metadane potoku, artefakty potoku i dane użytkowników były zachowywane podczas wyrejestrowywania starszego klastra
• Zintegruj z Kubeflow w manifestach AWS, aby w przypadku aktualizacji wersji Kubeflow wymagane były minimalne zmiany
• Bezproblemowy sposób na wycofanie, jeśli coś pójdzie nie tak po uaktualnieniu klastra
• Mieć prosty interfejs do promowania klastra kandydującego do produkcji

Poniższy diagram ilustruje tę architekturę.

Bezpieczna aktualizacja klastra Kubeflow. Po pomyślnym przetestowaniu Kubeflow Candidate jest on promowany do Kubeflow Prod poprzez aktualizację Route 53.

Kubeflow w manifestach AWS jest fabrycznie wyposażony w integracje Amazon RDS i Amazon S3. Dzięki tym usługom zarządzanym działającym jako wspólne magazyny danych możemy opracować niebiesko-zieloną strategię wdrażania. Aby to osiągnąć, upewniliśmy się, że metadane potoku są utrwalane w Amazon RDS, który działa niezależnie od klastra EKS, a logi i artefakty potoku są utrwalane w Amazon S3. Oprócz metadanych i artefaktów potoku skonfigurowaliśmy również FluentD do kierowania dzienników podów do usługi Amazon OpenSearch Service.

Gwarantuje to, że warstwa magazynu jest całkowicie oddzielona od warstwy obliczeniowej, a tym samym umożliwia testowanie zmian podczas aktualizacji wersji Kubeflow w zupełnie nowym klastrze EKS. Po pomyślnym zakończeniu wszystkich testów możemy po prostu zmienić Amazon trasy 53 Rekord DNS do kandydującego klastra hostującego Kubeflow. Ponadto utrzymujemy stary klaster działający jako kopia zapasowa przez kilka dni na wypadek, gdybyśmy musieli wycofać.

Korzyści z Amazon EKS i Kubeflow na AWS dla naszego potoku ML

Amazon EKS i pakiet Kubeflow on AWS przeniosły nasz przepływ pracy programistycznej do wzorca, który silnie zachęca do uczenia się modeli powtarzalnych. Narzędzia te pozwalają nam mieć w pełni zdefiniowane klastry z w pełni zdefiniowanymi najemcami i uruchamiać w pełni zdefiniowany kod.

Wiele wygranych z budowania tej platformy jest mniej ilościowych i ma więcej wspólnego z tym, jak poprawiły się przepływy pracy zarówno dla deweloperów platformy, jak i użytkowników. Na przykład MinIO zostało zastąpione bezpośrednim dostępem do Amazon S3, co przybliża nas do naszych pierwotnych przepływów pracy i zmniejsza liczbę usług, które musimy utrzymywać. Jesteśmy również w stanie wykorzystać Amazon RDS jako zaplecze dla Kubeflow, co umożliwia łatwiejsze migracje między klastrami i daje nam możliwość tworzenia kopii zapasowych naszych potoków w nocy.

Uznaliśmy również, że ulepszenia integracji Kubeflow z usługami zarządzanymi AWS są korzystne. Na przykład dzięki wstępnie skonfigurowanym usługom Amazon RDS, Amazon S3 i Amazon Cognito w manifestach Kubeflow w AWS oszczędzamy czas i wysiłek przy aktualizacji do nowszych dystrybucji Kubeflow. Kiedy zwykliśmy ręcznie modyfikować oficjalne manifesty Kubeflow, aktualizacja do nowej wersji zajęła kilka tygodni, od projektu do testowania.

Przejście na Amazon EKS daje nam możliwość zdefiniowania naszego klastra w Kustomize (obecnie część Kubectl) i Terraform. Okazuje się, że w przypadku pracy na platformie Kubernetes i Terraform są bardzo łatwe w obsłudze po poświęceniu wystarczającej ilości czasu na naukę. Po wielu iteracjach dostępne dla nas narzędzia bardzo ułatwiają wykonywanie standardowych operacji na platformie, takich jak aktualizacja komponentu lub wymiana całego klastra programistycznego. W porównaniu do wykonywania zadań w trybie off-surowym Elastyczna chmura obliczeniowa Amazon (Amazon EC2), trudno jest porównać ogromną różnicę, jaką daje posiadanie dobrze zdefiniowanych podów z wbudowanymi mechanizmami czyszczenia zasobów i ponawiania prób.

Kubernetes zapewnia świetne standardy bezpieczeństwa, a my tylko zarysowaliśmy powierzchnię tego, na co pozwala nam izolacja wielu użytkowników. Postrzegamy izolację wielu użytkowników jako wzorzec, który przyniesie więcej korzyści w przyszłości, gdy platforma szkoleniowa generuje dane na poziomie produkcyjnym, a my zatrudniamy programistów spoza naszego zespołu.

Tymczasem Kubeflow pozwala nam na trenowanie powtarzalnych modeli. Nawet przy tych samych danych żadne szkolenie nie tworzy identycznych modeli, ale mamy kolejną najlepszą rzecz. Dzięki Kubeflow wiemy dokładnie, jaki kod i dane zostały użyte do trenowania modelu. Onboarding znacznie się poprawił, ponieważ każdy krok w naszym potoku jest jasno i programowo zdefiniowany. Gdy nowi analitycy danych mają za zadanie naprawić błąd, potrzebują znacznie mniej trzymania się za rękę, ponieważ istnieje jasna struktura wykorzystania danych wyjściowych kodu między etapami.

Korzystanie z Kubeflow zapewnia również wiele ulepszeń wydajności w porównaniu do uruchamiania na pojedynczej instancji EC2. Często w uczeniu modeli naukowcy zajmujący się danymi potrzebują różnych narzędzi i optymalizacji do wstępnego przetwarzania i uczenia. Na przykład przetwarzanie wstępne jest często uruchamiane przy użyciu narzędzi do przetwarzania danych rozproszonych, takich jak Spark, podczas gdy szkolenie jest często uruchamiane przy użyciu wystąpień GPU. Dzięki potokom Kubeflow mogą określać różne typy wystąpień dla różnych etapów potoku. Dzięki temu mogą korzystać z potężnych instancji GPU w jednym etapie, a floty mniejszych maszyn do przetwarzania rozproszonego w innym etapie. Ponadto, ponieważ potoki Kubeflow opisują zależności między etapami, potoki mogą uruchamiać etapy równolegle.

Wreszcie, ponieważ stworzyliśmy proces dodawania dzierżawców do klastra, istnieje teraz bardziej formalny sposób rejestrowania zespołów w dzierżawie w klastrze. Ponieważ używamy Kubecost do śledzenia kosztów w naszym klastrze EKS, umożliwia nam to przypisanie kosztów do jednego projektu zamiast przypisywania kosztów na poziomie konta, który obejmuje wszystkie projekty dotyczące analizy danych. Kubecost przedstawia raport dotyczący pieniędzy wydanych na przestrzeń nazw, która jest ściśle powiązana z najemcą lub zespołem odpowiedzialnym za uruchomienie potoku.

Pomimo wszystkich korzyści, ostrzegamy, aby przeprowadzać tego rodzaju migrację tylko w przypadku całkowitego poparcia użytkowników. Użytkownicy, którzy poświęcili czas, czerpią wiele korzyści z korzystania z Amazon EKS i Kubernetes, ale istnieje znaczna krzywa uczenia się.

Wnioski

Dzięki wdrożeniu potoku Kubeflow on AWS w naszej kompleksowej infrastrukturze ML, byliśmy w stanie skonsolidować i ujednolicić nasze przepływy pracy związane z analizą danych przy jednoczesnym zachowaniu naszych podstawowych narzędzi (takich jak CI/CD i obsługa modeli). Nasi analitycy danych mogą teraz przechodzić między projektami opartymi na tym przepływie pracy bez konieczności uczenia się, jak utrzymywać zupełnie inny zestaw narzędzi. W przypadku niektórych naszych modeli byliśmy również mile zaskoczeni szybkością nowego przepływu pracy (pięciokrotnie szybszą), co pozwoliło na większą liczbę iteracji szkoleniowych, a w konsekwencji na tworzenie modeli z lepszymi przewidywaniami.

Stworzyliśmy również solidne podstawy, aby zwiększyć nasze możliwości MLOps oraz skalować liczbę i rozmiar naszych projektów. Na przykład, gdy zaostrzamy naszą postawę zarządzania w zakresie pochodzenia modeli i śledzenia, zmniejszyliśmy naszą uwagę z ponad 15 przepływów pracy do tylko jednego. A kiedy luka Log4shell wyszła na jaw pod koniec 2021 roku, byliśmy w stanie skupić się na jednym przepływie pracy i szybko naprawić w razie potrzeby (wykonywanie Rejestr elastycznego pojemnika Amazon (Amazon ECR), uaktualnianie usługi Amazon OpenSearch, aktualizowanie naszych narzędzi i nie tylko) przy minimalnym wpływie na bieżącą pracę analityków danych. Gdy ulepszenia AWS i Kubeflow staną się dostępne, możemy je włączyć według własnego uznania.

To prowadzi nas do ważnego i niedocenianego aspektu naszego Kubeflow w adopcji AWS. Jednym z kluczowych wyników tej podróży jest możliwość bezproblemowego wdrażania uaktualnień i ulepszeń Kubeflow dla naszych analityków danych. Chociaż omówiliśmy nasze podejście do tego wcześniej, opieramy się również na manifestach Kubeflow dostarczanych przez AWS. Naszą przygodę z Kubeflow rozpoczęliśmy jako weryfikacja koncepcji w 2019 roku, przed wydaniem wersji 1.0.0. (Obecnie jesteśmy na 1.4.1, oceniamy 1.5. AWS już pracuje nad wersją 1.6.) W ciągu minionych 3 lat pojawiło się co najmniej sześć wydań z pokaźną zawartością. Dzięki swojemu zdyscyplinowanemu podejściu do integracji i walidacji tych uaktualnień oraz publikowania manifestów zgodnie z przewidywalnym, niezawodnym harmonogramem, zespół Kubeflow w AWS odegrał kluczową rolę w umożliwieniu zespołowi athenahealth MLOps zaplanowania naszego planu rozwoju, a w konsekwencji alokacji zasobów i obszarów zainteresowania , dalej w przyszłość z większą pewnością.

Możesz podążać za Repozytorium GitHub AWS Labs do śledzenia wszystkich wkładów AWS do Kubeflow. Możesz również znaleźć zespoły AWS na Kanał Kubeflow #AWS Slack; Twoja opinia pomaga AWS ustalać priorytety dla kolejnych funkcji, które mają przyczynić się do projektu Kubeflow.

---

O autorach

Kanwaljit Khurmi jest starszym architektem rozwiązań w Amazon Web Services. Współpracuje z klientami AWS, zapewniając wskazówki i pomoc techniczną, pomagając im podnieść wartość ich rozwiązań podczas korzystania z AWS. Kanwaljit specjalizuje się w pomaganiu klientom w aplikacjach konteneryzowanych i uczących się maszynowo.

Tylera Kalbacha jest głównym członkiem personelu technicznego w athenahealth. Tyler ma około 7 lat doświadczenia w dziedzinie analityki, nauki o danych, sieci neuronowych i rozwoju aplikacji uczenia maszynowego w obszarze opieki zdrowotnej. Był współtwórcą kilku rozwiązań Machine Learning, które obecnie obsługują ruch produkcyjny. Obecnie pracuje jako główny naukowiec ds. danych w organizacji inżynieryjnej athenahealth, Tyler był częścią zespołu, który zbudował nową platformę szkoleniową uczenia maszynowego dla athenahealth od samego początku tego wysiłku.

Wiktor Kryłow jest głównym członkiem personelu technicznego w athenahealth. Victor jest inżynierem i mistrzem scrum, pomagającym analitykom danych w tworzeniu bezpiecznych, szybkich potoków uczenia maszynowego. W athenahealth pracował nad interfejsami, zamówieniami klinicznymi, receptami, planowaniem, analityką, a teraz uczeniem maszynowym. Ceni czysto napisany i dobrze przetestowany kod, ale ma niezdrową obsesję na punkcie jednolinijek kodu. W wolnym czasie lubi słuchać podcastów podczas spaceru z psem.

Sasanka Vemuriego jest głównym członkiem personelu technicznego w athenahealth. Ma doświadczenie w opracowywaniu rozwiązań opartych na danych w takich dziedzinach, jak opieka zdrowotna, ubezpieczenia i bioinformatyka. Sasank obecnie zajmuje się projektowaniem i rozwijaniem platform szkoleniowych i wnioskowania uczenia maszynowego na AWS i Kubernetes, które pomagają w szkoleniu i wdrażaniu rozwiązań ML na dużą skalę.

Anu Tumkura jest architektem w athenahealth. Anu ma ponad dwie dekady doświadczenia w architekturze, projektowaniu, programowaniu i budowaniu różnych produktów oprogramowania w uczeniu maszynowym, operacjach w chmurze, dużych zbiorach danych, potokach danych rozproszonych w czasie rzeczywistym, technologiach reklamowych, analizie danych, analityce mediów społecznościowych. Anu pracuje obecnie jako architekt w organizacji Product Engineering w athenahealth w zespołach Machine Learning Platform i Data Pipeline.

Williama Tsena jest starszym kierownikiem ds. inżynierii w athenahealth. Ma ponad 20-letnie doświadczenie inżynierskie w zakresie budowania rozwiązań w zakresie IT w służbie zdrowia, przetwarzania rozproszonego Big Data, inteligentnych sieci optycznych, systemów edycji wideo w czasie rzeczywistym, oprogramowania dla przedsiębiorstw i grupowego ubezpieczenia opieki zdrowotnej. William obecnie kieruje dwoma niesamowitymi zespołami w athenahealth, zespołami inżynierskimi Machine Learning Operations i DevOps, w organizacji Product Engineering.