Betriebsmodell

Ein Betriebsmodell ist ein Framework, das Menschen, Prozesse und Technologien zusammenbringt, um ein Unternehmen dabei zu unterstützen, Geschäftswert auf skalierbare, konsistente und effiziente Weise zu erzielen. Das ML-Betriebsmodell bietet einen standardisierten Produktentwicklungsprozess für Teams im gesamten Unternehmen. Je nach Größe, Komplexität und Geschäftsfaktoren gibt es drei Modelle für die Implementierung des Betriebsmodells:

• Zentralisiertes Data-Science-Team — In diesem Modell sind alle datenwissenschaftlichen Aktivitäten innerhalb eines einzigen Teams oder einer Organisation zentralisiert. Dies ähnelt dem Modell des Center of Excellence (COE), bei dem alle Geschäftsbereiche für datenwissenschaftliche Projekte an dieses Team weitergeleitet werden.

• Dezentrale Data-Science-Teams — In diesem Modell sind die datenwissenschaftlichen Aktivitäten auf verschiedene Geschäftsfunktionen oder -abteilungen verteilt oder basieren auf unterschiedlichen Produktlinien.

• Föderierte Data-Science-Teams — In diesem Modell werden Shared-Services-Funktionen wie Code-Repositorys, CI/CD-Pipelines (Continuous Integration and Continuous Delivery) usw. vom zentralen Team verwaltet, und jede Funktion auf Geschäftseinheit oder Produktebene wird von dezentralen Teams verwaltet. Dies ähnelt dem Hub-and-Spoke-Modell, bei dem jede Geschäftseinheit ihre eigenen Data-Science-Teams hat. Diese Teams der Geschäftsbereiche koordinieren ihre Aktivitäten jedoch mit dem zentralisierten Team.

Bevor Sie sich entscheiden, Ihre erste Studio-Domain für Produktionsanwendungen zu starten, sollten Sie Ihr Betriebsmodell und AWS bewährte Methoden für die Organisation Ihrer Umgebung berücksichtigen. Weitere Informationen finden Sie unter Organizing Your AWS Environment Using Multiple Accounts.

Der nächste Abschnitt enthält Anleitungen zur Organisation Ihrer Kontostruktur für die einzelnen Betriebsmodelle.

Empfohlene Kontostruktur

In diesem Abschnitt stellen wir kurz eine Kontostruktur nach dem Betriebsmodell vor, mit der Sie beginnen und die Sie entsprechend den betrieblichen Anforderungen Ihres Unternehmens ändern können. Unabhängig davon, für welches Betriebsmodell Sie sich entscheiden, empfehlen wir die Implementierung der folgenden gängigen bewährten Methoden:

• Verwenden Sie es AWS Control Towerfür die Einrichtung, Verwaltung und Verwaltung Ihrer Konten.

• Zentralisieren Sie Ihre Identitäten mit Ihrem Identity Provider (IdP) und AWSIAM Identity Center mit einem delegierten Securitiy Tooling-Administratorkonto und ermöglichen Sie den sicheren Zugriff auf Workloads.

• Führen Sie ML-Workloads mit Isolierung auf Kontoebene für Entwicklungs-, Test- und Produktionsworkloads aus.

• Streamen Sie ML-Workload-Protokolle in ein Protokollarchivkonto und filtern Sie anschließend die Protokollanalyse in einem Observability-Konto und wenden Sie sie an.

• Führen Sie ein zentrales Governance-Konto für die Bereitstellung, Steuerung und Prüfung des Datenzugriffs ein.

• Integrieren Sie Sicherheits- und Governance-Dienste (SGS) mit entsprechenden präventiven und detektiven Schutzmaßnahmen in jedes Konto, um Sicherheit und Compliance gemäß Ihren Unternehmens- und Workload-Anforderungen zu gewährleisten.

Zentralisierte Modellkontenstruktur

In diesem Modell ist das ML-Plattformteam verantwortlich für die Bereitstellung von:

• Ein Shared-Services-Tooling-Konto, das die Anforderungen von Machine Learning Operations (MLOps) in allen Data-Science-Teams erfüllt.

• Konten für die Entwicklung, den Test und die Produktion von ML-Workloads, die von allen Data-Science-Teams gemeinsam genutzt werden.

• Governance-Richtlinien, um sicherzustellen, dass die Workloads jedes Data-Science-Teams isoliert ausgeführt werden.

• Allgemeine bewährte Verfahren.

Kontostruktur eines zentralisierten Betriebsmodells

Dezentrale Modellkontenstruktur

In diesem Modell arbeitet jedes ML-Team unabhängig bei der Bereitstellung, Verwaltung und Verwaltung von ML-Konten und -Ressourcen. Wir empfehlen ML-Teams jedoch, einen zentralisierten Ansatz für Beobachtbarkeit und Datenverwaltung zu verwenden, um die Datenverwaltung und das Auditmanagement zu vereinfachen.

Kontostruktur eines dezentralen Betriebsmodells

Kontostruktur nach föderiertem Modell

Dieses Modell ähnelt dem zentralisierten Modell. Der Hauptunterschied besteht jedoch darin, dass jedes Data-Science-/ML-Team seine eigenen Workload-Konten für Entwicklung/Test/Produktion erhält, die eine robuste physische Isolierung seiner ML-Ressourcen ermöglichen und es jedem Team ermöglichen, unabhängig zu skalieren, ohne andere Teams zu beeinträchtigen.

Kontostruktur eines föderierten Betriebsmodells

Mehrmandantenfähigkeit der ML-Plattform

Multitenancy ist eine Softwarearchitektur, bei der eine einzelne Softwareinstanz mehrere unterschiedliche Benutzergruppen bedienen kann. Ein Mandant ist eine Gruppe von Benutzern, die gemeinsamen Zugriff mit bestimmten Rechten auf die Softwareinstanz haben. Wenn Sie beispielsweise mehrere ML-Produkte entwickeln, kann jedes Produktteam mit ähnlichen Zugriffsanforderungen als Mandant oder Team betrachtet werden.

Es ist zwar möglich, mehrere Teams innerhalb einer SageMaker Studio-Instanz (z. B. SageMakerDomain) zu implementieren, aber wägen Sie diese Vorteile gegen Kompromisse wie Explosionsradius, Kostenzuweisung und Beschränkungen auf Kontoebene ab, wenn Sie mehrere Teams in einer einzigen Studio-Domain zusammenführen. SageMaker In den folgenden Abschnitten erfahren Sie mehr über diese Kompromisse und bewährte Methoden.

Wenn Sie absolute Ressourcenisolierung benötigen, sollten Sie erwägen, SageMaker Studio-Domänen für jeden Mandanten in einem anderen Konto zu implementieren. Abhängig von Ihren Isolationsanforderungen können Sie mehrere Geschäftsbereiche (LOBs) als mehrere Domänen innerhalb eines einzigen Kontos und einer Region implementieren. Verwenden Sie gemeinsam genutzte Bereiche für die Zusammenarbeit zwischen Mitgliedern desselben Teams/derselben LOB nahezu in Echtzeit. Bei mehreren Domänen verwenden Sie weiterhin Richtlinien und Berechtigungen für Identity Access Management (IAM), um die Isolierung der Ressourcen sicherzustellen.

SageMaker Ressourcen, die aus einer Domain erstellt wurden, werden automatisch mit dem Amazon Resource Name (ARN) der Domain und dem Benutzerprofil oder Space-ARN versehen, um Ressourcen einfach zu isolieren. Beispielrichtlinien finden Sie in der Dokumentation zur Isolierung von Domänenressourcen. Dort finden Sie die ausführliche Referenz, wann eine Strategie mit mehreren Konten oder mehreren Domänen verwendet werden sollte, sowie die Funktionsvergleiche in der Dokumentation. Außerdem können Sie sich Beispielskripts ansehen, um Tags für bestehende Domänen im Repository aufzufüllen. GitHub

Schließlich können Sie mithilfe von. eine Self-Service-Bereitstellung von SageMaker Studio-Ressourcen für mehrere Konten implementieren. AWS Service Catalog Weitere Informationen finden Sie unter AWS Service CatalogProdukte in mehreren AWS-Konten und AWS-Regionen verwalten.