Verwaltung des ML-Lebenszyklus in großem Umfang, Teil 1: Ein Framework für die Architektur von ML-Workloads mit Amazon SageMaker

von Ram Vittal, Maira Ladeira Tanke, Ryan Lempka, Sriharsh Adari, and Sovik Nath übersetzt durch Julius Engler

Immer mehr Kunden integrieren maschinelles Lernen (ML) in ihre Produkte und Dienstleistungen mit der Hilfe von AWS. Die jüngsten Entwicklungen im Bereich generativer KI-Modellen haben zu einer weiteren Beschleunigung des Bedarfs an ML-Einführungen in sämtlichen Branchen geführt. Die Umsetzung von Sicherheits-, Datenschutz- und Governance-Kontrollen stellt für Kunden jedoch nach wie vor eine zentrale Herausforderung bei der Umsetzung von ML-Workloads in großem Umfang dar. Die Bewältigung dieser Herausforderungen bildet den Rahmen und die Grundlage für die Risikominderung und die verantwortungsvolle Nutzung von ML-gesteuerten Produkten. Bei generativer KI sind möglicherweise zusätzliche Kontrollen erforderlich, beispielsweise zur Beseitigung von Toxizität und zur Verhinderung von Jailbreaking und Halluzinationen. Die grundlegenden Komponenten für Sicherheit und Governance sind jedoch die selben wir bei traditionellem maschinellem Lernen.

Unsere Kunden berichten, dass sie spezialisiertes Wissen und Investitionen von bis zu 12 Monaten benötigen, um ihre maßgeschneiderte Amazon SageMaker ML-Plattform-Implementierung aufzubauen. Ihr Ziel ist es, skalierbare, zuverlässige, sichere und verwaltete ML-Umgebungen für die jeweiligen Geschäftsbereiche oder ML-Teams bereitzustellen.

Die Implementierung von ML-Lösungen in großem Umfang birgt diverse Herausforderungen, deren Bewältigung ohne ein Framework zur Steuerung des ML-Lebenszyklus erschwert wird. Dies umfasst das Operationalisieren von ML, die teambasierte Isolierung von Ressourcen, die Skalierung der Modell-Governance und der Experimentierressourcen, sowie die Verwaltung der Sicherheit und Compliance von ML-Workloads.

Das Framework zur Steuerung des ML-Lebenszyklus in großem Umfang unterstützt Sie dabei, eine ML-Plattform mit integrierten Sicherheits- und Governance-Kontrollen aufzubauen. Es basiert auf Branchenstandards und bewährten Methoden und bietet konkrete Anleitungen durch einen modularen Ansatz. Dabei erweitert es eine Multi-Account-Umgebung und baut auf dem Konzept auf, das wir in unserem Beitrag “ [EN]“ vorgestellt haben.

Das Framework umfasst Leitlinien für folgende Kernfunktionen:

1. Multi-Account, Sicherheits- und Netzwerkgrundlagen: Diese Funktion nutzt AWS Control Tower und die Entwurfsprinzipien nach AWS Well-Architected zur Erstellung einer Multi-Account-Umgebung sowie zur Bereitstellung von Sicherheits- und Netzwerkdiensten.
2. Daten- und Governance-Grundlagen: Diese Funktion nutzt eine Data-Mesh-Architektur [EN], die einen feingranularen Datenzugriff auf einen Data Lake, einen zentralen Feature-Store sowie auf Datenverwaltungsfunktionen ermöglicht.
3. Gemeinsame ML-Plattform- und Governance-Dienste: Diese Funktion ermöglicht die Erstellung und den Betrieb von Diensten wie CI/CD, dem AWS Service Catalog zur Bereitstellung von Umgebungen, und einem zentralen ML-Modell-Register.
4. ML-Team-Umgebungen: Diese Funktion ermöglicht den Aufbau und Betrieb von Betriebsumgebungen für ML-Teams zur Entwicklung, zum Testen sowie zur Bereitstellung ihrer ML-Modelle, zur Einbettung von Sicherheits- und Governance-Kontrollen.
5. ML-Plattform-Beobachtbarkeit: Diese Funktion unterstützt Sie bei der Fehlerbehebung und Ursachenanalyse von Problemen in ML-Modellen durch zentralisierte Protokollierung und Analysewerkzeuge. Außerdem stellt sie eine Anleitung zur Erstellung von Kosten- und Nutzungsberichten für ML-Anwendungsfälle bereit.

Obwohl dieses Framework für viele Unternehmen nützlich sein kann, richtet es sich besonders an große, etablierte oder regulierte Organisationen sowie globale Konzerne. Es unterstützt sie dabei, ihre ML-Strategien kontrolliert, konform und koordiniert unternehmensweit zu skalieren. So lassen sich die ML-Nutzung vorantreiben und gleichzeitig Risiken minimieren.

Besonders geeignet ist das Framework für:

• Großunternehmen mit vielen ML-interessierten Geschäftsbereichen, die unabhängig voneinander ML-Modelle entwickeln und einsetzen möchten, aber eine zentrale Steuerung benötigen.
• Unternehmen mit mittlerer bis hoher ML-Reife, die ihre bisherigen ML-Aktivitäten ausbauen und dabei Aspekte wie Zugriffskontrollen, Datennutzung, Modellleistung und Modell- Bias berücksichtigen wollen.
• Firmen in regulierten Branchen wie Finanzdienstleistungen, Gesundheitswesen, Chemie oder im privaten Sektor, die eine strenge Kontrolle und Rückverfolgbarkeit ihrer ML-Modelle sicherstellen müssen.
• Globale Organisationen, die zentrale Vorgaben mit lokaler Flexibilität in Einklang bringen müssen. Dieses Framework ermöglicht es dem zentralen Plattform-Engineering-Team einige hochrangige Richtlinien und Standards festzulegen und gibt gleichzeitig einzelnen Geschäftsbereichen die Flexibilität, sich an lokale Anforderungen anzupassen.

Im ersten Teil dieser Serie stellen wir die Referenz-Architektur für den Aufbau der ML-Plattform vor. In einem späteren Beitrag folgen dann detaillierte Anleitungen zur Umsetzung der verschiedenen Module in Ihrem Unternehmen.

Die Funktionalitäten der ML-Plattform lassen sich in vier Bereiche unterteilen. Diese Bereiche bilden das Fundament für die nachfolgend beschriebene Referenz-Architektur:

• ML-Grundlagen aufbauen
• ML-Operationen skalieren
• ML beobachtbar machen
• ML absichern

Lösungsübersicht

Das Framework zur Steuerung des ML-Lebenszyklus ermöglicht es Unternehmen, Sicherheits- und Governance-Kontrollen in allen Phasen der ML-Entwicklung zu verankern. Dadurch lassen sich Risiken minimieren und der Einsatz von ML in Produkten und Dienstleistungen beschleunigen. Das Framework optimiert den Aufbau und die Verwaltung sicherer, skalierbarer und zuverlässiger ML-Umgebungen, die mit einer wachsenden Zahl von Modellen und Projekten Schritt halten können. Das Framework bietet folgende Kernfunktionen:

• Bereitstellung von Konten und Infrastruktur unter Einhaltung der Unternehmensrichtlinien
• Self-Service-Bereitstellung von datenwissenschaftlichen Umgebungen und MLOps-Vorlagen für ML-Anwendungsfälle
• Ressourcenisolierung auf Geschäftsbereichs- oder Teamebene für mehr Sicherheit und Datenschutz
• Kontrollierter Zugriff auf produktionsreife Daten für Experimente und produktionsreife Workflows
• Verwaltung und Governance von Code-Repositories, Code-Pipelines, bereitgestellten Modellen und Datenfunktionen
• Modellregister und Feature-Store (lokal und zentral) zur Verbesserung der Governance
• Sicherheits- und Governance-Kontrollen für den gesamten Prozess der Modellentwicklung und -bereitstellung

Im Folgenden geben wir einen Überblick über konkrete Empfehlungen zum Aufbau einer solchen ML-Plattform auf AWS mit integrierten Sicherheits- und Governance-Kontrollen.

Die nachfolgende Abbildung zeigt die funktionale Architektur im Kontext der ML-Plattform. Die Architektur ordnet die verschiedenen Funktionen der ML-Plattform den AWS-Konten zu.

Die Umsetzung der funktionalen Architektur erfolgt mithilfe verschiedener AWS-Dienste, darunter AWS Organizations, Amazon SageMaker, AWS DevOps-Dienste sowie ein Data Lake. Die Referenz-Architektur der ML-Plattform mit den verschiedenen AWS-Diensten ist in der nachfolgenden Abbildung dargestellt.

Das Framework berücksichtigt verschiedene Rollen und Dienste zur Steuerung des ML-Lebenszyklus im großen Maßstab. Wir empfehlen folgende Schritte zur Organisation Ihrer Teams und Dienste:

1. Ihr Cloud-Administrator richtet mithilfe von AWS Control Tower und Automatisierungswerkzeugen die Multi-Account-Grundlagen ein, beispielsweise Organizations und AWS IAM Identity Center. Des weiteren werden Sicherheits- und Governance-Dienste wie AWS Key Management Service (AWS KMS) und AWS Service Catalog eingerichtet. Der Administrator erstellt zudem verschiedene Organisationseinheiten (OUs) und Konten zur Unterstützung Ihrer ML- und Analyse-Workflows.
2. Data-Lake-Administratoren richten den Data Lake und Datenkatalog ein und arbeiten mit dem ML-Plattform-Administrator zusammen, um den zentralen Feature-Store aufzubauen.
3. Der ML-Plattform-Administrator stellt gemeinsam genutzte ML-Dienste bereit, darunter AWS CodeCommit, AWS CodePipeline, Amazon Elastic Container Registry (ECR), eine zentrales Modellregister, SageMaker Model Cards [EN], SageMaker Model Dashboard [EN] sowie Service Catalog-Produkte für ML-Teams.
4. Der ML-Teamleiter meldet sich über AWS IAM Identity Center an, nutzt Service Catalog-Produkte und stellt Ressourcen in der Entwicklungsumgebung des ML-Teams bereit.
5. Datenwissenschaftler aus ML-Teams verschiedener Geschäftsbereiche greifen auf ihre Team-Entwicklungsumgebung zu, um die Modell-Pipeline aufzubauen.
6. Datenwissenschaftler suchen und nutzen Features aus dem zentralen Feature-Store-Katalog, entwickeln Modelle durch Experimente und wählen das beste Modell zur Weiterentwicklung aus.
7. Datenwissenschaftler erstellen neue Features und stellen diese im zentralen Feature-Store-Katalog zur Wiederverwendung bereit.
8. Ein ML-Ingenieur setzt die Modell-Pipeline in der Testumgebung des ML-Teams mithilfe eines gemeinsam genutzten CI/CD-Prozesses um.
9. Nach der Validierung durch die Stakeholder wird das ML-Modell in der Produktionsumgebung des Teams bereitgestellt.
10. Sicherheits- und Governance-Kontrollen sind in jeder Ebene dieser Architektur integriert. Dabei kommen Dienste wie AWS Security Hub, Amazon GuardDuty, Amazon Macie und weitere zum Einsatz.
11. Die Verwaltung der Sicherheitskontrollen erfolgt zentral über das Konto für Sicherheitstools mit Security Hub.
12. ML-Plattform-Governance-Funktionen wie SageMaker Model Cards und SageMaker Model Dashboard werden zentral vom Sicherheit und Governance Konto aus gesteuert.
13. Amazon CloudWatch– und AWS CloudTrail [EN]-Protokolle aus jedem Mitgliedskonto werden zentral in einem Beobachtbarkeitskonto mithilfe nativer AWS-Dienste zugänglich gemacht.

Im nächsten Abschnitt gehen wir näher auf die Module der Referenz-Architektur dieses Frameworks ein.

Module der Architektur

Die Referenz-Architektur besteht aus acht Modulen, die jeweils für spezifische Problemstellungen konzipiert sind. Zusammen decken diese Module verschiedene Governance-Aspekte ab, wie Infrastruktur, Daten, Modelle und Kosten. Jedes Modul bietet bestimmte Funktionen und arbeitet mit den anderen Modulen zusammen, um eine integrierte End-to-End-ML-Plattform mit integrierten Sicherheits- und Governance-Kontrollen zu schaffen. Im Folgenden stellen wir die Kernfunktionen jedes Moduls kurz vor.

Multi-Account-Grundlagen

Dieses Modul unterstützt Cloud-Administratoren beim Aufbau einer AWS Control Tower Landing Zone [EN] als Grundgerüst. Es umfasst die Erstellung einer Multi-Account-Struktur, Authentifizierung und Autorisierung via IAM Identity Center, ein Hub-and-Spoke-Netzwerkdesign, zentralisierte Logging-Dienste und neue AWS-Mitgliedskonten mit standardisierten Sicherheits- und Governance-Basislinien.

Zusätzlich bietet das Modul Empfehlungen für OU- und Kontostrukturen, die für ML- und Analyse-Workflows geeignet sind. Cloud-Administratoren erhalten Einblick in den Zweck der erforderlichen Konten und OUs, deren Bereitstellung sowie wichtige Sicherheits- und Compliance-Dienste zur zentralen Steuerung ihrer ML- und Analyse-Workloads.

Das Modul behandelt auch einen Rahmen für die Erstellung neuer Konten, der neue Konten mittels Automatisierungen bei ihrer Bereitstellung mit einer Basiskonfiguration zu versehen. Durch einen automatisierten Prozess zur Bereitstellung der Konten können Cloud-Administratoren ML- und Analyse-Teams schneller die benötigten Konten zur Verfügung stellen, ohne Abstriche bei einer soliden Governance-Grundlage zu machen.

Data-Lake-Grundlagen

Dieses Modul hilft Data-Lake-Administratoren bei der Implementierung eines Data Lakes zur Datenaufnahme, Datenkuration und Nutzung des AWS Lake Formation Governance-Modells. Dies ermöglicht die Verwaltung des feingranularen Datenzugriffs über Konten und Benutzer hinweg mittels eines zentralisierten Datenkatalogs, Datenzugriffsrichtlinien und Tag-basierter Zugriffskontrollen. Für einen Proof-of-Concept oder einige kleine Workloads können Sie mit einem Konto für die grundlegenden Elemente der Daten-Plattform beginnen. Zur Implementierung von mittelgroßen bis großen Produktions-Workloads empfehlen wir eine Multi-Account Strategie.
In einem solchen Szenario können Geschäftsbereiche die Rolle von Datenproduzenten und -konsumenten in verschiedenen AWS-Konten übernehmen, während die Data-Lake-Governance von einem zentralen gemeinsam genutzten AWS-Konto aus betrieben wird. Der Datenproduzent ist für die Sammlung, Verarbeitung und Speicherung von Daten aus seiner Datendomäne verantwortlich. Zudem obliegt ihm die Überwachung und Sicherung der Qualität seiner Datenbestände. Datenkonsumenten nutzen die Daten des Datenproduzenten, nachdem der zentralisierte Katalog sie mit Lake Formation freigegeben hat. Der zentralisierte Katalog dient der Speicherung und Verwaltung des gemeinsamen Datenkatalogs für die Datenproduzenten-Konten.

ML-Plattformdienste

Dieses Modul unterstützt das ML-Plattform-Engineering-Team bei der Einrichtung gemeinsam genutzter Dienste, die von den datenwissenschaftlichen Teams in ihren Team-Konten verwendet werden. Zu den Diensten gehören ein Service Catalog-Portfolio mit Produkten für die Bereitstellung von SageMaker-Domains [EN], die Bereitstellung von SageMaker-Domain-Benutzerprofilen [EN] und Datenwissenschaftliche Modellvorlagen für den Modellaufbau und die Bereitstellung. Das Modul bietet Funktionen für ein zentralisiertes Modell-Register, zentralisierte Modellkarten, ein Modell-Dashboard und die CI/CD-Pipelines zur Orchestrierung und Automatisierung von Modellentwicklungs- und Bereitstellungs-Workflows.

Darüber hinaus beschreibt dieses Modul, wie die erforderlichen Kontrollen und Governance-Mechanismen implementiert werden können, um rollenbasierte Self-Service-Funktionen zu ermöglichen. Dies erlaubt es datenwissenschaftlichen Teams, ihre benötigte Cloud-Infrastruktur und ML-Vorlagen selbstständig bereitzustellen.

ML-Anwendungsfallentwicklung

Dieses Modul ermöglicht Geschäftsbereichen und Datenwissenschaftlern den Zugriff auf die SageMaker-Domain ihres Teams in einer Entwicklungsumgebung sowie die Einrichtung einer Entwicklungsvorlage zur Erstellung ihrer Modelle.

In diesem Modul arbeiten Datenwissenschaftler an einer Entwicklungskonto-Instanz der Vorlage, um mit den im zentralen Data Lake verfügbaren Daten zu interagieren, Features aus einem zentralen Feature-Store wieder zu verwenden und zu teilen, ML-Experimente zu erstellen und durchzuführen, ihre ML-Workflows aufzubauen und zu testen sowie ihre Modelle im Modellregister ihrer Entwicklungsumgebungen zu registrieren.

Funktionen wie Verfolgung von Experimenten, Berichte über Erklärbarkeit von Modellen, Überwachung von Daten- und Modellverzerrungen sowie Modellregistrierung sind ebenfalls in den Vorlagen implementiert. Dies ermöglicht eine schnelle Anpassung der Lösungen an die von den Datenwissenschaftlern entwickelten Modelle.

ML-Operationen

Dieses Modul unterstützt Geschäftsbereiche und ML-Ingenieure bei der Arbeit an ihren Entwicklungsinstanzen der Modell-Bereitstellungsvorlage. Nachdem das Kandidatenmodell registriert und genehmigt wurde, richten sie CI/CD-Pipelines ein und führen ML-Workflows in der Testumgebung des Teams aus. Dabei wird das Modell im zentralen Modell-Register im Konto für gemeinsam genutzte Dienste der Plattform registriert. Sobald ein Modell in der zentralen Modellregistrierung genehmigt ist, löst dies eine CI/CD-Pipeline aus, um das Modell in der Produktionsumgebung des Teams bereitzustellen.

Zentralisierter Feature-Store

Sobald die ersten Modelle in Produktion sind und mehrere Anwendungsfälle beginnen, Features aus denselben Daten zu teilen, wird ein Feature-Store unerlässlich. Er gewährleistet die Zusammenarbeit über Anwendungsfälle hinweg und reduziert Doppelarbeit. Dieses Modul unterstützt das Team für ML-Plattformentwicklung bei der Einrichtung eines zentralisierten Feature-Stores. Dieser bietet Speicherung und Governance für ML-Features, die von den ML-Anwendungsfällen erstellt wurden, und ermöglicht die Wiederverwendung von Features über Projekte hinweg.

Logging und Beobachtbarkeit

Dieses Modul hilft Geschäftsbereichen und ML-Praktikern, Einblick in den Zustand von ML-Workloads über verschiedene ML-Umgebungen hinweg zu erhalten. Dies geschieht durch Zentralisierung von Protokollaktivitäten wie CloudTrail, CloudWatch, VPC Flow Logs und ML-Workload-Logs. Teams können Protokolle filtern, abfragen und visualisieren, was zur Verbesserung des Sicherheitsstatus beitragen kann.

Kosten und Berichterstattung

Dieses Modul unterstützt verschiedene Interessengruppen (Cloud-Administrator, Plattform-Administrator, Cloud-Business-Office) bei der Erstellung von Berichten und Dashboards. Diese schlüsseln Kosten auf ML-Benutzer-, ML-Team- und ML-Produktebene auf und verfolgen die Nutzung, wie beispielsweise die Anzahl der Benutzer, Instanztypen und Endpunkte.

Kunden haben uns um Rat gebeten, wie viele Konten sie erstellen sollten und wie diese zu strukturieren sind. Im nächsten Abschnitt geben wir Empfehlungen für eine Kontostruktur als Referenz, die Sie entsprechend Ihren Anforderungen an die Unternehmensführung anpassen können.

Referenz-Kontostruktur

In diesem Abschnitt diskutieren wir unsere Empfehlungen für die Organisation Ihrer Kontostruktur. Obwohl wir eine Grundstruktur empfehlen, raten wir ML- und Datenadministratoren, eng mit ihrem Cloud-Administrator zusammenzuarbeiten, um diese Kontostruktur entsprechend den Kontrollen ihrer Organisation anzupassen.

Wir empfehlen, Konten nach Organisationseinheiten (OUs) für Sicherheit, Infrastruktur, Workloads und Bereitstellungen zu organisieren. Darüber hinaus sollten innerhalb jeder OU Konten für Nicht-Produktion und Produktion getrennt werden, da die dort bereitgestellten Konten und Workloads unterschiedliche Kontrollen erfordern. Im Folgenden besprechen wir diese OUs kurz.

Sicherheits-OU

Die Konten in dieser OU werden vom Cloud-Admin oder Sicherheitsteam der Organisation verwaltet, um Sicherheitsereignisse zu überwachen, zu identifizieren, zu schützen, zu erkennen und darauf zu reagieren.

Infrastruktur-OU

Die Konten in dieser OU werden vom Cloud-Admin oder Netzwerkteam der Organisation verwaltet, um unternehmensweite, gemeinsam genutzte Infrastruktur-Ressourcen und Netzwerke zu verwalten.

Wir empfehlen folgende Konten unter der Infrastruktur-OU:

• Netzwerk – Einrichtung einer zentralisierten Netzwerkinfrastruktur wie AWS Transit Gateway
• Gemeinsame Dienste – Einrichtung zentralisierter AD-Dienste und VPC-Endpunkte

Workloads-OU

Die Konten in dieser OU werden von den Plattformteam-Administratoren der Organisation verwaltet. Falls für jedes Plattformteam unterschiedliche Kontrollen implementiert werden müssen, können Sie weitere OU-Ebenen für diesen Zweck verschachteln, wie beispielsweise eine ML-Workloads-OU, eine Daten-Workloads-OU usw.

Wir empfehlen folgende Konten unter der Workloads-OU:

• ML-Entwicklungs-, Test- und Produktionskonten auf Teamebene – Einrichtung basierend auf den Isolationsanforderungen des Workloads
• Data-Lake-Konten – Aufteilung der Konten nach Ihren Datenbereichen
• Zentrales Data-Governance-Konto – Zentralisierung Ihrer Richtlinien für Datenzugriffe
• Zentrales Feature-Store-Konto – Zentralisierung von Features zur gemeinsamen Nutzung über Teams hinweg

Bereitstellungs-OU

Die Konten in dieser OU werden von den Administratoren des Plattformteams des Unternehmens für die Bereitstellung von Workloads und Beobachtbarkeit verwaltet.

Wir empfehlen folgende Konten unter der Bereitstellungs-OU, da das ML-Plattformteam auf dieser OU-Ebene verschiedene Kontrollen zur Verwaltung und Steuerung von Bereitstellungen einrichten kann:

• Konten für gemeinsam genutzte Dienste der Plattform für Test und Produktion – Hostet plattformweite gemeinsame Dienste für CI/CD und Modellregistrierung
• Konto für ML-Beobachtbarkeit für Test und Produktion – Hostet CloudWatch-Logs, CloudTrail-Logs und andere benötigte Protokolle

Als Nächstes besprechen wir kurz die Organisationskontrollen, die in Mitgliedskonten zur Überwachung der Infrastrukturressourcen eingebettet werden müssen.

AWS Umgebungskontrollen

Eine Kontrolle ist eine übergeordnete Regel, die eine kontinuierliche Steuerung Ihrer gesamten AWS-Umgebung gewährleistet. Sie wird in einfacher Sprache ausgedrückt. In diesem Framework verwenden wir AWS Control Tower, um folgende Kontrollen zu implementieren, die Ihnen helfen, Ihre Ressourcen zu steuern und die Einhaltung von Vorschriften über Gruppen von AWS-Konten hinweg zu überwachen:

1. Präventive Kontrollen: Eine präventive Kontrolle stellt sicher, dass Ihre Konten konform bleiben, indem sie Aktionen verhindert, die zu Richtlinienverletzungen führen. Sie wird mithilfe einer Service Control Policy (SCP) implementiert. Beispielsweise können Sie eine präventive Kontrolle einrichten, die sicherstellt, dass CloudTrail in AWS-Konten oder -Regionen nicht gelöscht oder gestoppt wird.
2. Detektive Kontrollen: Eine detektive Kontrolle erkennt Nicht-Konformität von Ressourcen innerhalb Ihrer Konten, wie beispielsweise Richtlinienverletzungen, liefert Warnungen über das Dashboard und wird mithilfe von AWS Config-Regeln implementiert. Beispielsweise können Sie eine detektive Kontrolle erstellen, die erkennt, ob der öffentliche Lesezugriff auf die Amazon Simple Storage Service (Amazon S3) Buckets im gemeinsam genutzten Log-Archiv-Konto aktiviert ist.
3. Proaktive Kontrollen: Eine proaktive Kontrolle überprüft Ihre Ressourcen, bevor sie bereitgestellt werden, und stellt sicher, dass die Ressourcen mit dieser Kontrolle konform sind und mithilfe von AWS CloudFormation Hooks implementiert werden. Ressourcen, die nicht konform sind, werden nicht bereitgestellt. Beispielsweise können Sie eine proaktive Kontrolle einrichten, die prüft, ob für eine SageMaker-Notebook-Instanz kein direkter Internetzugang erlaubt ist.

Interaktionen zwischen ML-Plattformdiensten, ML-Anwendungsfällen und ML-Operationen

Verschiedene Rollen wie der Leiter der Datenwissenschafts-Abteilung (leitender Datenwissenschaftler), Datenwissenschaftler und ML-Ingenieur betreiben die Module 2-6, wie in der folgenden Abbildung für verschiedene Phasen der ML-Plattformdienste, ML-Anwendungsfallentwicklung und ML-Operationen zusammen mit Data-Lake-Grundlagen und dem zentralen Feature-Store dargestellt.

Die folgende Tabelle fasst die Ops-Flow-Aktivität und die Setup-Flow-Schritte für verschiedene Rollen zusammen. Sobald eine Rolle eine ML-Aktivität als Teil des Ops-Flows initiiert, laufen die Dienste wie in den Setup-Flow-Schritten beschrieben ab.

Rollen und Interaktionen mit verschiedenen Modulen der ML-Plattform

Die Zuweisung der Module erfolgt anhand spezifischer Kriterien. Dabei werden die Module jeweils an die Zielgruppe innerhalb einer bestimmten Abteilung mit dem höchsten Nutzungsaufkommen vergeben. Der sekundäre Zugriff wird an andere Abteilungen mit gelegentlichem Zugriff auf die Module weitergegeben. Die Module sind auf die Bedürfnisse bestimmter Jobfunktionen oder Rollen zugeschnitten, um eine optimale Funktionalität zu gewährleisten.

Wir betrachten die folgenden Teams:

1. Zentrale Cloud-Entwicklung: Dieses Team arbeitet auf Unternehmenscloud-Ebene über alle Workloads hinweg, um gemeinsame Cloud-Infrastrukturdienste einzurichten, wie beispielsweise unternehmensweite Netzwerke, Identitäten, Berechtigungen und Kontoverwaltung.
2. Datenplattform-Entwicklung: Dieses Team verwaltet unternehmensweite Data Lakes, Datenerfassung, Datenkuration und Data Governance.
3. ML-Plattform-Entwicklung Dieses Team arbeitet auf ML-Plattformebene über Geschäftsbereiche hinweg, um gemeinsam genutzte ML-Infrastrukturdienste bereitzustellen, wie ML-Infrastrukturbereitstellung, Experimentverfolgung, Modell-Governance, Bereitstellung und Beobachtbarkeit.

Die folgende Tabelle zeigt im Detail, welche Abteilungen primären und sekundären Zugriff auf jedes Modul haben, entsprechend den Zielrollen des Moduls.

Fazit

In diesem Beitrag haben wir ein Framework zur Steuerung des ML-Lebenszyklus im großen Maßstab vorgestellt, das Ihnen hilft, gut strukturierte ML-Workloads mit eingebetteten Sicherheits- und Governance-Kontrollen zu implementieren. Wir haben erläutert, wie dieses Framework einen ganzheitlichen Ansatz für den Aufbau einer ML-Plattform verfolgt, unter Berücksichtigung von Data Governance, Modell-Governance und unternehmensweiten Kontrollen. Wir ermutigen Sie, mit dem Framework und den in diesem Beitrag vorgestellten Konzepten zu experimentieren und uns Ihr Feedback mitzuteilen.

Über die Autoren:

	Ram Vittal ist ein Principal ML Solutions Architect bei AWS. Er kann auf mehr als 30 Jahre Erfahrung im Entwurf und in der Entwicklung verteilter, hybrider und cloud-basierter Anwendungen zurückblicken. Sein Leidenschaft gilt der Entwicklung sicherer, skalierbarer und zuverlässiger KI/ML und Big-Data-Lösungen mit dem Ziel, Großkunden bei der Cloud-Einführung und -Optimierung zu unterstützen und dadurch eine Verbesserung ihrer Geschäftsergebnisse zu erreichen. In seiner Freizeit fährt er gerne Motorrad und geht mit seinem dreijährigen Sheep-A-Doodle spazieren.
	Sovik Kumar Nath ist ein KI/ML Solutions Architect bei AWS. Er verfügt über umfangreiche Erfahrungen bei der Entwicklung von End-to-End-Lösungen für maschinelles Lernen und Geschäftsanalysen in den Bereichen Finanzen, Betrieb, Marketing, Gesundheitswesen, Lieferkettenmanagement und IoT. Des Weiteren hat Sovik Artikel veröffentlicht und hält ein Patent für die Überwachung von ML-Modellen. Er verfügt über einen doppelten Masterabschluss von der University of South Florida und der Universität Fribourg, Schweiz, sowie einen Bachelorabschluss des Indian Institute of Technology, Kharagpur. In seiner Freizeit unternimmt Sovik gerne Reisen, nutzt gerne Fährverbindungen und interessiert sich für Filme.
	Maira Ladeira Tanke ist ein Senior Data Specialist bei AWS. Als technische Leiterin unterstützt sie Kunden dabei, ihren geschäftlichen Mehrwert durch neue Technologien und innovative Lösungen zu steigern. Maira ist seit Januar 2020 bei AWS tätig. Davor arbeitete sie als Datenwissenschaftlerin in verschiedenen Branchen und konzentrierte sich auf die Erzielung von Geschäftswerten durch Daten. In ihrer Freizeit reist Maira gerne und verbringt gerne Zeit mit ihrer Familie an warmen Orten.
	Ryan Lempka ist als Senior Solutions Architect bei Amazon Web Services tätig. In dieser Funktion unterstützt er seine Kunden bei der Entwicklung von Lösungen auf AWS, die auf ihre Geschäftsziele ausgerichtet sind. Er verfügt über umfassende Erfahrungen in den Bereichen Geschäftsstrategie IT-Systemmanagement und Datenwissenschaft. Ryan hat sich dem lebenslangen Lernen verschrieben und genießt es, sich täglich neuen Herausforderungen zu stellen und dabei sein Wissen zu erweitern.
	Sriharsh Adari ist als Senior Solutions Architect bei Amazon Web Services (AWS) tätig. In dieser Funktion unterstützt er seine Kunden bei der Entwicklung von Lösungen auf AWS, die auf ihre Geschäftsziele ausgerichtet sind. Im Laufe der Jahre hat er mehrere Kunden bei der Transformation von Datenplattformen in verschiedenen Branchen unterstützt. Zu seinen Kernkompetenzen gehören Technologiestrategie, Datenanalyse und Datenwissenschaft. In seiner Freizeit treibt er gerne Sport, sieht sich Fernsehsendungen an und spielt Tabla.