Erstellen Sie mit Kubeflow auf AWS wiederholbare, sichere und erweiterbare End-to-End-Workflows für maschinelles Lernen

Dies ist ein Gast-Blogbeitrag, der zusammen mit athenahealth verfasst wurde.

athenahealth ein führender Anbieter von netzwerkfähiger Software und Dienstleistungen für medizinische Gruppen und Gesundheitssysteme im ganzen Land. Seine elektronischen Patientenakten, das Ertragszyklusmanagement und die Tools zur Patientenbindung ermöglichen jederzeit und überall Zugriff, was zu besseren finanziellen Ergebnissen für seine Kunden führt und es seinen Anbieterkunden ermöglicht, eine qualitativ hochwertigere Versorgung zu bieten.

Im Bereich der künstlichen Intelligenz (KI) nutzt athenahealth Datenwissenschaft und maschinelles Lernen (ML), um Geschäftsprozesse zu beschleunigen und Empfehlungen, Vorhersagen und Erkenntnisse über mehrere Dienste hinweg bereitzustellen. Von seiner ersten Implementierung in automatisierten Dokumentendiensten, bei der Millionen von Anbieter-Patienten-Dokumenten berührungslos verarbeitet werden, bis hin zu seiner neueren Arbeit bei virtuellen Assistenten und der Verbesserung der Ertragszyklusleistung, setzt athenahealth weiterhin KI ein, um die Effizienz, die Servicefähigkeiten und bessere Ergebnisse für Anbieter zu steigern und ihre Patienten.

Dieser Blogbeitrag zeigt, wie athenahealth verwendet Kubeflow auf AWS (eine AWS-spezifische Distribution von Kubeflow), um einen End-to-End-Data-Science-Workflow aufzubauen und zu rationalisieren, der wichtige Tools bewahrt, die betriebliche Effizienz optimiert, die Produktivität von Data Scientists steigert und die Voraussetzungen für eine einfachere Erweiterung ihrer ML-Fähigkeiten schafft.

Kubeflow ist die Open-Source-ML-Plattform, die darauf ausgerichtet ist, die Bereitstellung von ML-Workflows auf Kubernetes einfach, portabel und skalierbar zu machen. Kubeflow erreicht dies durch die Einbindung relevanter Open-Source-Tools, die sich gut in Kubernetes integrieren lassen. Einige dieser Projekte umfassen Argo für die Pipeline-Orchestrierung, Istio für Service Mesh, Jupyter für Notebooks, Spark, TensorBoard und Katib. Kubeflow Pipelines hilft bei der Erstellung und Bereitstellung portabler, skalierbarer ML-Workflows, die Schritte wie Datenextraktion, Vorverarbeitung, Modelltraining und Modellbewertung in Form von wiederholbaren Pipelines umfassen können.

AWS leistet einen Beitrag zur Open-Source-Kubeflow-Community, indem es seine eigene Kubeflow-Distribution (auf AWS Kubeflow genannt) bereitstellt, die Organisationen wie athenahealth dabei unterstützt, hochzuverlässige, sichere, portable und skalierbare ML-Workflows mit reduziertem Betriebsaufwand durch Integration mit verwalteten AWS-Services zu erstellen. AWS bietet verschiedene Kubeflow-Bereitstellungsoptionen wie die Bereitstellung mit Amazon Cognito, Bereitstellung mit Relationaler Amazon-Datenbankdienst (Amazon RDS) und Amazon Simple Storage-Service (Amazon S3) und Vanilla-Bereitstellung. Einzelheiten zur Dienstintegration und verfügbaren Add-Ons für jede dieser Optionen finden Sie unter Einsatz.

Heute bietet Kubeflow auf AWS einen klaren Weg zur Nutzung von Kubeflow, ergänzt durch die folgenden AWS-Services:

Viele AWS-Kunden nutzen die Vorteile der Kubeflow-on-AWS-Distribution, einschließlich Athenahealth.

Hier bespricht das MLOps-Team von athenahealth die Herausforderungen, denen es begegnet ist, und die Lösungen, die es auf seiner Kubeflow-Reise entwickelt hat.

Herausforderungen mit der vorherigen ML-Umgebung

Vor unserer Einführung von Kubeflow auf AWS verwendeten unsere Data Scientists einen standardisierten Satz von Tools und einen Prozess, der Flexibilität in der Technologie und im Workflow zum Trainieren eines bestimmten Modells ermöglichte. Zu den Beispielkomponenten der standardisierten Tools gehören eine Datenerfassungs-API, Sicherheits-Scan-Tools, die CI/CD-Pipeline, die von einem anderen Team innerhalb von athenahealth erstellt und verwaltet wird, und eine gemeinsame Bereitstellungsplattform, die vom MLOps-Team erstellt und verwaltet wird. Mit zunehmender Reife unserer Nutzung von KI und ML wuchs jedoch die Vielfalt der Tools und Infrastrukturen, die für jedes Modell erstellt wurden. Obwohl wir den bestehenden Prozess noch unterstützen konnten, sahen wir die folgenden Herausforderungen am Horizont:

• Wartung und Wachstum – Das Reproduzieren und Warten von Modelltrainingsumgebungen erforderte mehr Aufwand, da die Anzahl der bereitgestellten Modelle zunahm. Jedes Projekt verwaltete eine detaillierte Dokumentation, die umriss, wie jedes Skript zum Erstellen des endgültigen Modells verwendet wurde. In vielen Fällen war dies ein aufwändiger Prozess mit 5 bis 10 Skripten mit jeweils mehreren Ausgaben. Diese mussten manuell mit detaillierten Anweisungen zur Verwendung der einzelnen Ergebnisse in nachfolgenden Prozessen nachverfolgt werden. Dies beizubehalten wurde im Laufe der Zeit umständlich. Zudem stieg mit der Komplexität der Projekte auch die Anzahl der Tools. Beispielsweise verwendeten die meisten Modelle Spark und TensorFlow mit GPUs, was eine größere Vielfalt an Umgebungskonfigurationen erforderte. Im Laufe der Zeit wechselten Benutzer in ihren Entwicklungsumgebungen zu neueren Versionen von Tools, konnten dann aber keine älteren Skripts mehr ausführen, wenn diese Versionen inkompatibel wurden. Folglich erforderte die Wartung und Erweiterung älterer Projekte mehr Engineering-Zeit und -Aufwand. Als neue Data Scientists dem Team beitraten, nahmen Wissenstransfer und Onboarding mehr Zeit in Anspruch, da die Synchronisierung lokaler Umgebungen viele undokumentierte Abhängigkeiten beinhaltete. Beim Wechseln zwischen Projekten traten die gleichen Probleme auf, da jedes Modell seine eigenen Arbeitsabläufe hatte.
• Sicherheit – Wir nehmen Sicherheit ernst und priorisieren daher die Einhaltung aller vertraglichen, gesetzlichen und regulatorischen Verpflichtungen im Zusammenhang mit ML und Data Science. Daten müssen auf bestimmte Weise verwendet, gespeichert und abgerufen werden, und wir haben robuste Prozesse eingebettet, um sicherzustellen, dass unsere Praktiken unseren gesetzlichen Verpflichtungen entsprechen und sich an den Best Practices der Branche orientieren. Vor der Einführung von Kubeflow erforderte die Sicherstellung, dass Daten auf eine bestimmte Weise gespeichert und abgerufen wurden, eine regelmäßige Überprüfung über mehrere, unterschiedliche Workflows hinweg. Wir wussten, dass wir die Effizienz verbessern konnten, indem wir diese unterschiedlichen Workflows auf einer einzigen Plattform konsolidieren. Diese Plattform müsste jedoch flexibel genug sein, um sich gut in unsere standardisierten Tools integrieren zu lassen.
• Einkauf & Prozesse – Wir sahen auch eine Möglichkeit, die betriebliche Effizienz und das Management zu steigern, indem wir die Protokollierung und Überwachung der Arbeitsabläufe zentralisierten. Da jedes Team seine eigenen Tools entwickelt hatte, sammelten wir diese Informationen aus jedem Workflow einzeln und aggregierten sie.

Das Data-Science-Team evaluierte verschiedene Lösungen zur Konsolidierung der Arbeitsabläufe. Neben der Erfüllung dieser Anforderungen suchten wir nach einer Lösung, die sich nahtlos in die vorhandene standardisierte Infrastruktur und Tools integrieren lässt. Wir haben Amazon EKS und Kubeflow auf AWS als unsere Workflow-Lösung ausgewählt.

Der Data Scientist-Entwicklungszyklus mit Kubeflow

Ein Data-Science-Projekt beginnt mit einer weißen Weste: keine Daten, kein Code, nur das Geschäftsproblem, das mit ML gelöst werden kann. Die erste Aufgabe ist ein Proof of Concept (POC), um festzustellen, ob die Daten genügend Signal enthalten, um ein ML-Modell zur effektiven Lösung des Geschäftsproblems zu machen, beginnend mit der Abfrage des Rohdatensatzes aus unserem Snowflake Data Warehouse. Diese Phase ist iterativ, und die Data Scientists verwenden während dieses Prozesses Kubernetes-Pods oder Kubeflow Jupyter-Notebooks.

Unser Kubeflow-Cluster verwendet den Karpenter-Cluster-Autoscaler, der Datenwissenschaftlern das Hochfahren von Ressourcen erleichtert, da sie sich nur auf die Definition der gewünschten Instance-Typen konzentrieren müssen, während die Bereitstellungsarbeit von einer Reihe vordefinierter Karpenter-Bereitsteller ausgeführt wird. Wir haben separate Provisioner für CPU- und GPU-Instance-Typen, und alle von Amazon EKS unterstützten Instances fallen gemäß unserer Provisioner-Konfiguration in eine dieser beiden Kategorien. Die Data Scientists wählen Instance-Typen mithilfe von Node-Selektoren aus, und Karpenter kümmert sich um das Node-Lifecycle-Management.

Nachdem die Abfrage entwickelt wurde, extrahieren die Data Scientists die Rohdaten an einen Speicherort auf Amazon S3 und starten dann ein Jupyter-Notebook über die AWS Kubeflow-Benutzeroberfläche, um die Daten zu untersuchen. Das Ziel besteht darin, den Funktionssatz zu erstellen, der zum Trainieren des ersten Modells verwendet wird. Auf diese Weise können die Datenwissenschaftler feststellen, ob die Daten genügend Signale enthalten, um die Geschäftsanforderungen des Kunden zu erfüllen.

Nachdem die Ergebnisse zufriedenstellend sind, gehen die Datenwissenschaftler zur nächsten Phase des Entwicklungszyklus über und verwandeln ihre Entdeckungen in eine robuste Pipeline. Sie wandeln den POC-Code in Code in Produktionsqualität um, der in großem Umfang ausgeführt werden kann. Um die Konformität durch die Verwendung genehmigter Bibliotheken sicherzustellen, wird ein Container mit dem entsprechenden Basis-Docker-Image erstellt. Für unsere Data Scientists haben wir festgestellt, dass die Bereitstellung eines Standard-Python-, TensorFlow- und Spark-Basisimages für die meisten, wenn nicht alle Workloads ausreichend Flexibilität bietet. Sie können dann das Dockerfile ihrer Komponente verwenden, um ihre Entwicklungsumgebung weiter anzupassen. Dieses Dockerfile wird dann vom CI/CD-Prozess verwendet, um das Komponenten-Image zu erstellen, das in der Produktion verwendet wird, wodurch die Konsistenz zwischen Entwicklungs- und Produktionsumgebungen aufrechterhalten wird.

Wir haben ein Tool, das Datenwissenschaftlern die Möglichkeit gibt, ihre Entwicklungsumgebung in einem Pod zu starten, der auf Kubernetes läuft. Wenn dieser Pod ausgeführt wird, können die Data Scientists die Visual Studio Code-IDE direkt an den Pod anfügen und ihren Modellcode debuggen. Nachdem sie den Code erfolgreich ausgeführt haben, können sie ihre Änderungen an git pushen und eine neue Entwicklungsumgebung wird mit den neuesten Änderungen erstellt.

Die Standard-Data-Science-Pipeline besteht aus Phasen, die Extraktion, Vorverarbeitung, Training und Bewertung umfassen. Jede Phase in der Pipeline wird als Komponente in Kubeflow angezeigt, das aus einem Kubernetes-Pod besteht, der einen Befehl mit einigen als Parameter übergebenen Informationen ausführt. Diese Parameter können entweder statische Werte oder Verweise auf die Ausgabe einer vorherigen Komponente sein. Das im Pod verwendete Docker-Image wird aus dem CI/CD-Prozess erstellt. Details zu diesem Prozess erscheinen im CI/CD-Workflow, der im nächsten Abschnitt besprochen wird.

Entwicklungszyklus auf Kubeflow. Der Entwicklungsworkflow beginnt links mit dem POC. Das fertige Modell wird auf der athenahealth-Plattform zur Bereitstellung von Modellen bereitgestellt, die auf Amazon ECS ausgeführt wird.

CI/CD-Prozess zur Unterstützung automatisierter Arbeitsabläufe

Als Teil unseres CI/CD-Prozesses verwenden wir Jenkins, um alle Kubeflow-Komponenten-Images parallel zu erstellen und zu testen. Nach erfolgreichem Abschluss enthält die Pipeline-Komponentenvorlage Referenzzeiger auf die Bilder, und die resultierende Pipeline wird in Kubeflow hochgeladen. Parameter in der Jenkins-Pipeline ermöglichen es Benutzern, die Pipelines zu starten und ihre Modelltrainingstests nach erfolgreichen Builds auszuführen.

Um einen kurzen Entwicklungszyklus aufrechtzuerhalten, können Data Scientists die Pipeline alternativ auch von ihrem lokalen Computer aus starten und alle Pipeline-Parameter ändern, mit denen sie möglicherweise experimentieren.

Es gibt Tools, um sicherzustellen, dass die Referenzzeiger aus dem CI/CD-Build standardmäßig verwendet werden. Wenn das Repository ein bereitstellbares Artefakt enthält, stellt die CI/CD-Logik das Artefakt weiterhin auf der athenahealth-Modellbereitstellungsplattform (dem Prediction Service) bereit, die auf Amazon ECS ausgeführt wird AWS Fargate. Nachdem alle diese Phasen durchlaufen sind, führt der Data Scientist den Code mit dem primären Zweig zusammen. Die Pipelines und bereitstellbaren Artefakte werden dann in die Produktion übertragen.

CI/CD-Bereitstellungsworkflow. Dieses Diagramm beschreibt den Build- und Bereitstellungsworkflow von Data Science. Der CI/CD-Prozess wird vorangetrieben von Jenkins.

Sicherheit

Durch die Konsolidierung unserer Data-Science-Workflows konnten wir unseren Ansatz zur Sicherung der Schulungspipeline zentralisieren. In diesem Abschnitt diskutieren wir unseren Ansatz zur Daten- und Clustersicherheit.

Datensicherheit

Datensicherheit wird bei athenahealth großgeschrieben. Aus diesem Grund entwickeln und unterhalten wir eine Infrastruktur, die vollständig den Vorschriften und Standards entspricht, die die Sicherheit und Integrität dieser Daten schützen.

Um sicherzustellen, dass wir die Datenkonformitätsstandards erfüllen, stellen wir unsere AWS-Infrastruktur in Übereinstimmung mit unseren athenahealth-Unternehmensrichtlinien bereit. Die beiden Hauptspeicher für Daten sind Amazon RDS für hochgradig skalierbare Pipeline-Metadaten und Amazon S3 für Pipeline- und Modellartefakte. Für Amazon S3 stellen wir sicher, dass die Buckets verschlüsselt sind, HTTPS-Endpunkte erzwungen werden und die Bucket-Richtlinien und AWS Identity and Access Management and (IAM)-Rollen folgen den Prinzipien der geringsten Rechte, wenn sie den Zugriff auf die Daten erlauben. Dies gilt auch für Amazon RDS-Daten: Die Verschlüsselung ist immer aktiviert, und die Sicherheitsgruppen und der Zugriff auf Anmeldeinformationen folgen dem Prinzip der geringsten Rechte. Diese Standardisierung stellt sicher, dass nur autorisierte Parteien Zugriff auf die Daten haben und dieser Zugriff nachverfolgt wird.

Zusätzlich zu diesen Maßnahmen wird die Plattform auch Sicherheitsbedrohungsbewertungen und kontinuierlichen Sicherheits- und Compliance-Scans unterzogen.

Wir erfüllen auch die Datenaufbewahrungsanforderungen über das Datenlebenszyklusmanagement für alle S3-Buckets, die sensible Daten enthalten. Diese Richtlinie verschiebt Daten automatisch nach Amazon S3 Gletscher nach 30 Tagen der Erstellung. Ausnahmen hiervon werden über Datenabrufanfragen verwaltet und von Fall zu Fall genehmigt oder abgelehnt. Dadurch wird sichergestellt, dass alle Workflows der Datenaufbewahrungsrichtlinie entsprechen. Dies löst auch das Problem mit der Wiederherstellung von Daten, wenn ein Modell schlecht funktioniert und ein erneutes Training erforderlich ist, oder wenn ein neues Modell anhand einer historischen Iteration des Datensatzes eines älteren Modells bewertet werden muss.

Um den Zugriff auf Amazon S3 und Amazon RDS innerhalb von Kubeflow auf AWS und Amazon EKS einzuschränken, verwenden wir IRSA (IAM Roles for Service Accounts), das eine IAM-basierte Berechtigungsbereitstellung für Ressourcen in Kubernetes bereitstellt. Jeder Mandant in Kubeflow verfügt über ein eindeutiges vorab erstelltes Dienstkonto, das wir an eine IAM-Rolle binden, die speziell zur Erfüllung der Mandantenzugriffsanforderungen erstellt wurde. Der Benutzerzugriff auf Mandanten wird auch durch die Gruppenmitgliedschaft der Amazon Cognito-Benutzerpools für jeden Benutzer eingeschränkt. Wenn ein Benutzer beim Cluster authentifiziert wird, enthält das generierte Token Gruppenansprüche, und Kubernetes RBAC verwendet diese Informationen, um den Zugriff auf eine bestimmte Ressource im Cluster zuzulassen oder zu verweigern. Diese Einrichtung wird im nächsten Abschnitt näher erläutert.

Cluster-Sicherheit mit Multi-User-Isolierung

Wie wir im vorherigen Abschnitt angemerkt haben, führen Data Scientists explorative Datenanalysen durch, führen Datenanalysen durch und trainieren ML-Modelle. Um Ressourcen zuzuweisen, Daten zu organisieren und Workflows basierend auf Projekten zu verwalten, bietet Kubeflow auf AWS eine Isolierung basierend auf Kubernetes-Namespaces. Diese Isolierung funktioniert für die Interaktion mit der Kubeflow-Benutzeroberfläche; Es bietet jedoch keine Tools zum Steuern des Zugriffs auf die Kubernetes-API mithilfe von Kubectl. Das bedeutet, dass der Benutzerzugriff auf der Kubeflow-Benutzeroberfläche, aber nicht über die Kubernetes-API über Kubectl gesteuert werden kann.

Die im folgenden Diagramm beschriebene Architektur behebt dieses Problem, indem der Zugriff auf Projekte in Kubeflow basierend auf Gruppenmitgliedschaften vereinheitlicht wird. Um dies zu erreichen, nutzten wir die Manifeste von Kubeflow auf AWS, die in Amazon Cognito-Benutzerpools integriert sind. Darüber hinaus verwenden wir die rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes, um die Autorisierung innerhalb des Clusters zu steuern. Die Benutzerberechtigungen werden basierend auf der Amazon Cognito-Gruppenmitgliedschaft bereitgestellt. Diese Informationen werden mit dem vom OIDC-Client generierten Token an den Cluster weitergegeben. Dieser Prozess wird dank der integrierten Amazon EKS-Funktion vereinfacht, die es verknüpften OIDC-Identitätsanbietern ermöglicht, sich beim Cluster zu authentifizieren.

Standardmäßig wird die Amazon EKS-Authentifizierung vom IAM-Authentifikator durchgeführt, einem Tool, das die Authentifizierung bei einem EKS-Cluster mithilfe von IAM-Anmeldeinformationen ermöglicht. Diese Authentifizierungsmethode hat ihre Vorzüge; Es ist jedoch nicht für unseren Anwendungsfall geeignet, da Athenahealth Microsoft Azure Active Directory für den Identitätsdienst im gesamten Unternehmen verwendet.

Kubernetes-Namespace-Isolierung. Data Scientists können je nach Bedarf für ihre Arbeit einer einzelnen oder mehreren Gruppen beitreten. Der Zugriff wird regelmäßig überprüft und gegebenenfalls entfernt.

Azure Active Directory ist als unternehmensweiter Identitätsdienst die Quelle der Wahrheit für die Kontrolle des Benutzerzugriffs auf den Kubeflow-Cluster. Die Einrichtung dafür umfasst das Erstellen einer Azure-Unternehmensanwendung, die als Dienstprinzipal fungiert, und das Hinzufügen von Gruppen für verschiedene Mandanten, die Zugriff auf den Cluster benötigen. Diese Einrichtung in Azure wird in Amazon Cognito gespiegelt, indem ein föderierter OIDC-Identitätsanbieter eingerichtet wird, der die Authentifizierungsverantwortung an Azure auslagert. Der Zugriff auf Azure-Gruppen wird von SailPoint IdentityIQ gesteuert, das Zugriffsanfragen an den Projekteigentümer sendet, um diese entsprechend zuzulassen oder zu verweigern. Im Amazon Cognito-Benutzerpool werden zwei Anwendungsclients erstellt: Einer wird verwendet, um die Authentifizierung für den Kubernetes-Cluster mithilfe des OIDC-Identitätsanbieters einzurichten, und der andere, um die Kubeflow-Authentifizierung in der Kubeflow-Benutzeroberfläche zu sichern. Diese Clients sind so konfiguriert, dass sie Gruppenansprüche bei der Authentifizierung beim Cluster weitergeben, und diese Gruppenansprüche werden zusammen mit RBAC verwendet, um die Autorisierung innerhalb des Clusters einzurichten.

Kubernetes RBAC-Rollenbindungen werden zwischen Gruppen und der Clusterrolle Kubeflow-edit eingerichtet, die bei der Installation von Kubeflow im Cluster erstellt wird. Diese Rollenbindung stellt sicher, dass jeder Benutzer, der mit dem Cluster interagiert, nachdem er sich über OIDC angemeldet hat, auf die Namespaces zugreifen kann, für die er Berechtigungen hat, wie in seinen Gruppenansprüchen definiert. Obwohl dies für Benutzer funktioniert, die mit Kubectl mit dem Cluster interagieren, stellt die Kubeflow-Benutzeroberfläche derzeit keinen Zugriff für Benutzer basierend auf der Gruppenmitgliedschaft bereit, da sie kein RBAC verwendet. Stattdessen verwendet es die Ressource der Istio-Autorisierungsrichtlinie, um den Zugriff für Benutzer zu steuern. Um diese Herausforderung zu bewältigen, haben wir einen benutzerdefinierten Controller entwickelt, der Benutzer synchronisiert, indem er Amazon Cognito-Gruppen abfragt und entsprechende Rollenbindungen für jeden Benutzer anstatt für jede Gruppe hinzufügt oder entfernt. Diese Einrichtung ermöglicht es Benutzern, bei der Interaktion mit der Kubeflow-Benutzeroberfläche und Kubectl über die gleiche Berechtigungsstufe zu verfügen.

Betriebseffizienz

In diesem Abschnitt erörtern wir, wie wir die uns zur Verfügung stehenden Open-Source- und AWS-Tools genutzt haben, um unsere Workflows zu verwalten und zu debuggen sowie die betrieblichen Auswirkungen eines Upgrades von Kubeflow zu minimieren.

Protokollierung und Überwachung

Für die Protokollierung verwenden wir FluentD, um alle unsere Containerprotokolle dorthin zu verschieben Amazon OpenSearch-Dienst und Systemmetriken an Prometheus. Anschließend verwenden wir Kibana und die Grafana-Benutzeroberfläche zum Suchen und Filtern von Protokollen und Metriken. Das folgende Diagramm beschreibt, wie wir dies einrichten.

Kubeflow-Protokollierung. Wir verwenden sowohl die Grafana-Benutzeroberfläche als auch Kibana, um die Protokolle anzuzeigen und zu durchsuchen

Der folgende Screenshot ist eine Ansicht der Kibana-Benutzeroberfläche aus unserer Pipeline.

Beispielansicht der Kibana-Benutzeroberfläche. Kibana ermöglicht benutzerdefinierte Ansichten.

Sichere Kubeflow-Cluster-Upgrades

Während wir Benutzer in Kubeflow auf AWS einbinden, sorgen wir für eine zuverlässige und konsistente Benutzererfahrung und ermöglichen es dem MLOps-Team, bei der Veröffentlichung und Integration neuer Funktionen agil zu bleiben. An der Oberfläche scheint Kustomize für uns modular zu sein, um das Arbeiten und Aktualisieren einer Komponente nach der anderen zu ermöglichen, ohne andere zu beeinträchtigen, wodurch wir neue Funktionen mit minimaler Unterbrechung für die Benutzer hinzufügen können. In der Praxis gibt es jedoch Szenarien, in denen der beste Ansatz darin besteht, einfach einen neuen Kubernetes-Cluster einzurichten, anstatt Upgrades auf Komponentenebene für vorhandene Cluster anzuwenden. Wir haben zwei Anwendungsfälle gefunden, bei denen es sinnvoller war, komplett neue Cluster zu erstellen:

• Upgrade auf eine Kubernetes-Version, bei der AWS direkte Cluster-Upgrades bereitstellt. Es wird jedoch schwierig zu testen, ob alle Kubeflow- und Kubernetes-Ressourcen wie beabsichtigt funktionieren und die Manifeste die Abwärtskompatibilität beibehalten.
• Upgrade von Kubeflow auf eine neuere Version, bei der mehrere Funktionen hinzugefügt oder geändert wurden und es fast immer keine vielversprechende Idee ist, In-Place-Upgrades auf einem vorhandenen Kubernetes-Cluster durchzuführen.

Um dieses Problem anzugehen, haben wir eine Strategie entwickelt, die es uns ermöglicht, Cluster sicher auszutauschen, ohne bestehende Workloads zu beeinträchtigen. Um dies zu erreichen, mussten wir folgende Kriterien erfüllen:

• Trennen Sie die Kubeflow-Speicher- und Rechenressourcen, sodass die Pipeline-Metadaten, Pipeline-Artefakte und Benutzerdaten bei der Deprovisionierung des älteren Clusters erhalten bleiben
• Integrieren Sie Kubeflow in AWS-Manifeste, sodass bei einem Upgrade der Kubeflow-Version nur minimale Änderungen erforderlich sind
• Haben Sie eine mühelose Möglichkeit, ein Rollback durchzuführen, wenn nach dem Cluster-Upgrade etwas schief geht
• Haben Sie eine einfache Schnittstelle, um einen Kandidatencluster in die Produktion zu befördern

Das folgende Diagramm veranschaulicht diese Architektur.

Sicheres Kubeflow-Cluster-Upgrade. Sobald der Test des Kubeflow Candidate erfolgreich war, wird er durch ein Update auf Route 53 zu Kubeflow Prod hochgestuft.

Kubeflow on AWS-Manifeste sind mit Amazon RDS- und Amazon S3-Integrationen vorkonfiguriert. Da diese Managed Services als gemeinsame Datenspeicher fungieren, können wir eine Blue-Green-Bereitstellungsstrategie einrichten. Um dies zu erreichen, haben wir sichergestellt, dass die Pipeline-Metadaten in Amazon RDS, das unabhängig vom EKS-Cluster funktioniert, und die Pipeline-Protokolle und -Artefakte in Amazon S3 gespeichert werden. Zusätzlich zu Pipeline-Metadaten und Artefakten haben wir FluentD auch so eingerichtet, dass Pod-Protokolle an Amazon OpenSearch Service weitergeleitet werden.

Dies stellt sicher, dass die Speicherschicht vollständig von der Compute-Schicht getrennt ist, und ermöglicht so das Testen von Änderungen während Kubeflow-Versionsupdates auf einem vollständig neuen EKS-Cluster. Nachdem alle Tests erfolgreich verlaufen sind, können wir die einfach ändern Amazon Route 53 DNS-Eintrag für den Kandidatencluster, der Kubeflow hostet. Außerdem lassen wir den alten Cluster einige Tage lang als Backup laufen, falls wir ein Rollback durchführen müssen.

Vorteile von Amazon EKS und Kubeflow auf AWS für unsere ML-Pipeline

Amazon EKS und das Kubeflow-on-AWS-Paket haben unseren Entwicklungsworkflow auf ein Muster umgestellt, das ein wiederholbares Modelltraining stark fördert. Diese Tools ermöglichen es uns, vollständig definierte Cluster mit vollständig definierten Mandanten zu haben und vollständig definierten Code auszuführen.

Viele Gewinne aus dem Aufbau dieser Plattform sind weniger quantitativ und haben mehr damit zu tun, wie sich die Arbeitsabläufe sowohl für Plattformentwickler als auch für Benutzer verbessert haben. Beispielsweise wurde MinIO durch direkten Zugriff auf Amazon S3 ersetzt, was uns unseren ursprünglichen Arbeitsabläufen näher bringt und die Anzahl der zu wartenden Dienste reduziert. Wir können Amazon RDS auch als Backend für Kubeflow nutzen, was einfachere Migrationen zwischen Clustern ermöglicht und uns die Möglichkeit gibt, unsere Pipelines jede Nacht zu sichern.

Als vorteilhaft empfanden wir auch die Verbesserungen bei der Kubeflow-Integration mit AWS Managed Services. Da beispielsweise Amazon RDS, Amazon S3 und Amazon Cognito in den Manifesten von Kubeflow auf AWS vorkonfiguriert sind, sparen wir Zeit und Mühe bei der Aktualisierung auf neuere Distributionen von Kubeflow. Als wir früher die offiziellen Kubeflow-Manifeste manuell geändert haben, dauerte die Aktualisierung auf eine neue Version mehrere Wochen, vom Design bis zum Testen.

Der Wechsel zu Amazon EKS gibt uns die Möglichkeit, unseren Cluster in Kustomize (jetzt Teil von Kubectl) und Terraform zu definieren. Es stellt sich heraus, dass Kubernetes und Terraform für die Plattformarbeit sehr einfach zu handhaben sind, nachdem man genügend Zeit zum Lernen investiert hat. Nach vielen Iterationen machen es die uns zur Verfügung stehenden Tools sehr einfach, Standardplattformoperationen wie das Upgrade einer Komponente oder den Austausch eines ganzen Entwicklungsclusters durchzuführen. Im Vergleich zum Ausführen von Jobs ohne Rohdaten Amazon Elastic Compute-Cloud (Amazon EC2)-Instances ist es schwer zu vergleichen, was für ein enormer Unterschied es macht, wenn gut definierte Pods mit garantierten eingebauten Ressourcenbereinigungs- und Wiederholungsmechanismen vorhanden sind.

Kubernetes bietet hervorragende Sicherheitsstandards, und wir haben nur an der Oberfläche dessen gekratzt, was uns die Mehrbenutzer-Isolierung ermöglicht. Wir sehen die Multi-User-Isolation als ein Muster, das sich in Zukunft mehr auszahlt, wenn die Trainingsplattform Daten auf Produktionsebene produziert und wir Entwickler von außerhalb unseres Teams hinzuziehen.

In der Zwischenzeit ermöglicht uns Kubeflow ein reproduzierbares Modelltraining. Selbst mit den gleichen Daten bringt kein Training identische Modelle hervor, aber wir haben das nächstbeste. Mit Kubeflow wissen wir genau, welcher Code und welche Daten zum Trainieren eines Modells verwendet wurden. Das Onboarding hat sich stark verbessert, da jeder Schritt in unserer Pipeline klar und programmatisch definiert ist. Wenn neue Data Scientists die Aufgabe haben, einen Fehler zu beheben, müssen sie viel weniger Hand anlegen, da es eine klare Struktur gibt, wie Codeausgaben zwischen den Phasen verwendet werden.

Die Verwendung von Kubeflow führt auch zu vielen Leistungsverbesserungen im Vergleich zur Ausführung auf einer einzelnen EC2-Instance. Beim Modelltraining benötigen Data Scientists häufig verschiedene Tools und Optimierungen für die Vorverarbeitung und das Training. Beispielsweise wird die Vorverarbeitung häufig mit verteilten Datenverarbeitungstools wie Spark ausgeführt, während das Training häufig mit GPU-Instanzen ausgeführt wird. Mit Kubeflow-Pipelines können sie verschiedene Instanztypen für verschiedene Phasen in der Pipeline angeben. Dadurch können sie die leistungsstarken GPU-Instanzen in einer Stufe und eine Flotte kleinerer Maschinen für die verteilte Verarbeitung in einer anderen Stufe verwenden. Da Kubeflow-Pipelines außerdem die Abhängigkeiten zwischen Phasen beschreiben, können die Pipelines Phasen parallel ausführen.

Da wir schließlich einen Prozess zum Hinzufügen von Mandanten zum Cluster erstellt haben, gibt es jetzt eine formellere Möglichkeit, Teams bei einem Mandanten im Cluster zu registrieren. Da wir Kubecost verwenden, um Kosten in unserem EKS-Cluster zu verfolgen, können wir Kosten einem einzelnen Projekt zuordnen, anstatt Kosten auf Kontoebene zuordnen zu lassen, was alle Data-Science-Projekte umfasst. Kubecost präsentiert einen Bericht über die Ausgaben pro Namespace, der eng mit dem Mandanten oder Team gekoppelt ist, das für den Betrieb der Pipeline verantwortlich ist.

Trotz aller Vorteile möchten wir davor warnen, diese Art der Migration nur durchzuführen, wenn die Benutzer uneingeschränkt einverstanden sind. Benutzer, die Zeit investieren, profitieren von der Verwendung von Amazon EKS und Kubernetes, aber es gibt eine erhebliche Lernkurve.

Zusammenfassung

Mit der Implementierung der Kubeflow-on-AWS-Pipeline in unsere End-to-End-ML-Infrastruktur konnten wir unsere Data-Science-Workflows konsolidieren und standardisieren, während wir unsere wesentlichen Tools (wie CI/CD und Modellbereitstellung) beibehalten. Unsere Data Scientists können jetzt auf der Grundlage dieses Workflows zwischen Projekten wechseln, ohne sich die Pflege eines völlig anderen Toolsets aneignen zu müssen. Bei einigen unserer Modelle waren wir auch angenehm überrascht von der Geschwindigkeit des neuen Workflows (fünfmal schneller), der mehr Trainingsiterationen und folglich die Erstellung von Modellen mit besseren Vorhersagen ermöglichte.

Wir haben auch eine solide Grundlage geschaffen, um unsere MLOps-Fähigkeiten zu erweitern und die Anzahl und Größe unserer Projekte zu skalieren. Während wir beispielsweise unsere Governance-Haltung in Bezug auf Modellherkunft und -verfolgung stärken, haben wir unseren Fokus von über 15 Workflows auf nur einen reduziert. Und als Ende 4 die Log2021shell-Schwachstelle bekannt wurde, konnten wir uns auf einen einzigen Workflow konzentrieren und bei Bedarf schnell Abhilfe schaffen (performing Amazon Elastic Container-Registrierung (Amazon ECR)-Scans, Upgrades von Amazon OpenSearch Service, Aktualisierung unserer Tools und mehr) mit minimalen Auswirkungen auf die laufende Arbeit der Datenwissenschaftler. Sobald AWS- und Kubeflow-Verbesserungen verfügbar werden, können wir sie nach eigenem Ermessen integrieren.

Dies bringt uns zu einem wichtigen und untertriebenen Aspekt unserer Einführung von Kubeflow auf AWS. Eines der entscheidenden Ergebnisse dieser Reise ist die Möglichkeit, Upgrades und Verbesserungen für Kubeflow nahtlos für unsere Data Scientists einzuführen. Obwohl wir unseren Ansatz dazu bereits besprochen haben, verlassen wir uns auch auf die von AWS bereitgestellten Kubeflow-Manifeste. Wir haben unsere Kubeflow-Reise als Proof of Concept im Jahr 2019 vor der Veröffentlichung von Version 1.0.0 begonnen. (Wir arbeiten derzeit an 1.4.1 und evaluieren 1.5. AWS arbeitet bereits an der Version 1.6.) In den dazwischenliegenden 3 Jahren gab es mindestens sechs Veröffentlichungen mit umfangreichem Inhalt. Durch ihren disziplinierten Ansatz zur Integration und Validierung dieser Upgrades und zur Veröffentlichung der Manifeste nach einem vorhersehbaren, zuverlässigen Zeitplan war das Kubeflow-Team bei AWS entscheidend dafür, dass das MLOps-Team von athenahealth unsere Entwicklungs-Roadmap und folglich unsere Ressourcenzuweisungen und Schwerpunkte planen konnte , weiter in die Zukunft mit größerer Zuversicht.

Sie können dem folgen AWS Labs GitHub-Repository um alle AWS-Beiträge zu Kubeflow zu verfolgen. Sie finden AWS-Teams auch auf der Kubeflow #AWS Slack-Channel; Ihr Feedback dort hilft AWS, die nächsten Funktionen zu priorisieren, um zum Kubeflow-Projekt beizutragen.

---

Über die Autoren

Kanwaljit Khurmi ist Senior Solutions Architect bei Amazon Web Services. Er arbeitet mit den AWS-Kunden zusammen, um Anleitungen und technische Unterstützung bereitzustellen, die ihnen helfen, den Wert ihrer Lösungen bei der Verwendung von AWS zu verbessern. Kanwaljit ist darauf spezialisiert, Kunden mit containerisierten und maschinellen Lernanwendungen zu unterstützen.

Tyler Kalbach ist Principal Member of Technical Staff bei athenahealth. Tyler verfügt über ungefähr 7 Jahre Erfahrung in den Bereichen Analytik, Datenwissenschaft, neuronale Netze und Entwicklung von Anwendungen für maschinelles Lernen im Gesundheitswesen. Er hat an mehreren Lösungen für maschinelles Lernen mitgewirkt, die derzeit den Produktionsdatenverkehr bedienen. Tyler arbeitet derzeit als Principal Data Scientist in der Engineering-Organisation von athenahealth und war von Anfang an Teil des Teams, das die neue Trainingsplattform für maschinelles Lernen für athenahealth aufgebaut hat.

Viktor Krylow ist Principal Member of Technical Staff bei athenahealth. Victor ist Ingenieur und Scrum Master und hilft Datenwissenschaftlern beim Aufbau sicherer, schneller Pipelines für maschinelles Lernen. Bei athenahealth hat er an Schnittstellen, klinischer Bestellung, Verschreibungen, Terminplanung, Analytik und jetzt maschinellem Lernen gearbeitet. Er schätzt sauber geschriebenen und gut getesteten Code, hat aber eine ungesunde Besessenheit von Code-Einzeilern. In seiner Freizeit hört er gerne Podcasts, während er mit seinem Hund Gassi geht.

Sasank Vemuri ist Lead Member of Technical Staff bei athenahealth. Er hat Erfahrung in der Entwicklung datengesteuerter Lösungen in Bereichen wie Gesundheitswesen, Versicherungen und Bioinformatik. Sasank arbeitet derzeit an der Konzeption und Entwicklung von Trainings- und Inferenzplattformen für maschinelles Lernen auf AWS und Kubernetes, die beim Training und der Bereitstellung von ML-Lösungen in großem Maßstab helfen.

Anu Tumkur ist Architekt bei athenahealth. Anu verfügt über mehr als zwei Jahrzehnte Erfahrung in den Bereichen Architektur, Design und Entwicklung beim Erstellen verschiedener Softwareprodukte in den Bereichen maschinelles Lernen, Cloud-Operationen, Big Data, verteilte Datenpipelines in Echtzeit, Ad-Tech, Datenanalyse und Social-Media-Analyse. Anu arbeitet derzeit als Architektin in der Product Engineering-Organisation von athenahealth in den Teams Machine Learning Platform und Data Pipeline.

William Tsen ist Senior Engineering Manager bei athenahealth. Er verfügt über mehr als 20 Jahre Führungserfahrung in der Entwicklung von Lösungen in den Bereichen IT im Gesundheitswesen, Big Data Distributed Computing, intelligente optische Netzwerke, Echtzeit-Videobearbeitungssysteme, Unternehmenssoftware und Gruppenversicherungen im Gesundheitswesen. William leitet derzeit zwei großartige Teams bei athenahealth, die Machine Learning Operations- und DevOps-Engineering-Teams in der Product Engineering-Organisation.