Organisieren und Einrichten von Azure Machine Learning-Umgebungen

Beim Planen einer Azure Machine Learning-Bereitstellung für eine Unternehmensumgebung gibt es einige gängige Entscheidungspunkte, die sich auf die Erstellung des Arbeitsbereichs auswirken:

  • Teamstruktur: Die Art, wie Sie Ihre Data Science-Teams strukturieren und wie Sie bei Projekten zusammenarbeiten, unter Berücksichtigung von Anwendungsfall und Datentrennung oder Anforderungen der Kostenverwaltung.
  • Umgebungen: Die Umgebungen, die Sie als Teil Ihres Entwicklungs- und Freigabeworkflows verwenden, um die Entwicklung von der Produktion zu trennen.
  • Region: Der Standort Ihrer Daten und die Zielgruppe, für die Sie Ihre Machine Learning-Lösung bereitstellen müssen.

Teamstruktur und Einrichtung des Arbeitsbereichs

Der Arbeitsbereich ist die Ressource der obersten Ebene für Azure Machine Learning. Dort werden die Artefakte gespeichert, die bei der Arbeit mit Machine Learning generiert werden, und die verwalteten Computeressourcen sowie Zeiger auf angefügte und zugehörige Ressourcen. In puncto Verwaltbarkeit unterstützt der Arbeitsbereich als Azure Resource Manager-Ressource die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) sowie die Verwaltung per Richtlinie und die Verwendung als Einheit für die Kostenberichterstattung.

Organisationen wählen in der Regel eines der folgenden Lösungsmuster oder eine Kombination davon aus, um die Anforderungen an die Verwaltbarkeit zu erfüllen.

Arbeitsbereich pro Team: Verwenden Sie einen einzelnen Arbeitsbereich für jedes Team, wenn alle Mitglieder eines Teams die gleiche Zugriffsebene für Daten- und Experimentressourcen benötigen. Beispielsweise könnte eine Organisation mit drei Machine Learning-Teams drei Arbeitsbereiche erstellen, eines für jedes Team.

Die Verwendung eines einzelnen Arbeitsbereichs pro Team hat den Vorteil, dass alle Machine Learning-Artefakte für die Projekte des Teams an einem zentralen Ort gespeichert werden. Dies ermöglicht Produktivitätssteigerungen, da Teammitglieder problemlos auf Experimentergebnisse zugreifen und diese untersuchen und wiederverwenden können. Das Organisieren Ihrer Arbeitsbereiche nach Teams reduziert den Azure-Speicherbedarf und vereinfacht die Kostenverwaltung nach Teams. Da die Anzahl der Experimentressourcen schnell zunehmen kann, können Sie Ihre Artefakte organisiert halten, indem Sie Benennungs- und Taggingkonventionen befolgen. Empfehlungen zum Benennen von Ressourcen finden Sie unter Entwickeln Ihrer Benennungs- und Kennzeichnungsstrategie für Azure-Ressourcen.

Bei diesem Ansatz muss jedes Teammitglied über ähnliche Berechtigungen auf Datenzugriffsebene verfügen. Differenzierte rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und Zugriffssteuerungslisten (Access Control Lists, ACL) für Datenquellen und Experimentressourcen sind innerhalb eines Arbeitsbereichs eingeschränkt. Datentrennungsanforderungen nach Anwendungsfall sind nicht möglich.

Arbeitsbereich pro Projekt: Verwenden Sie einen einzelnen Arbeitsbereich für jedes Projekt, wenn die Trennung von Daten- und Experimentressourcen nach Projekt erforderlich ist oder wenn Sie Kostenberichterstattung und Budgetierung auf Projektebene benötigen. Angenommen, Sie verfügen über eine Organisation mit vier Machine Learning-Teams, die jeweils drei Projekte ausführen, sodass sich insgesamt 12 Arbeitsbereichsinstanzen ergeben.

Der Vorteil der Verwendung eines einzelnen Arbeitsbereichs pro Projekt ist, dass die Kosten auf Projektebene verwaltet werden. Ein Team erstellt in der Regel eine dedizierte Ressourcengruppe für Azure Machine Learning und zugehörige Ressourcen aus ähnlichen Gründen. Wenn Sie z. B. mit externen Mitwirkenden arbeiten, vereinfacht ein projektorientierter Arbeitsbereich die Zusammenarbeit an einem Projekt, da externen Benutzern nur Zugriff auf die Projektressourcen gewährt werden muss, nicht auf die Teamressourcen.

Bei diesem Ansatz ist die Isolation von Experimentergebnissen und Ressourcen zu berücksichtigen. Die Ermittlung und Wiederverwendung der Ressourcen ist möglicherweise schwieriger, da Ressourcen auf mehrere Arbeitsbereichsinstanzen verteilt werden.

Einzelner Arbeitsbereich: Verwenden Sie einen einzelnen Arbeitsbereich für nicht team- oder nicht projektbezogene Aufgaben oder für Kosten, die nicht direkt einer bestimmten Abrechnungseinheit (z. B. Forschung und Entwicklung) zugeordnet werden können.

Der Vorteil dieses Setups besteht darin, dass die Kosten einzelner, nicht projektbezogener Aufgaben von projektbezogenen Kosten entkoppelt werden können. Wenn Sie einen einzelnen Arbeitsbereich einrichten, in dem alle Benutzer ihre Arbeit erledigen können, verringern Sie den Azure-Speicherbedarf.

Bei diesem Ansatz kann der Arbeitsbereich schnell überladen werden, wenn viele Machine Learning-Fachleute die gleiche Instanz gemeinsam nutzen. Benutzer benötigen möglicherweise eine Filterung von Ressourcen auf Benutzeroberflächenbasis, um ihre Ressourcen effektiv zu finden. Sie können gemeinsam genutzte Machine Learning-Arbeitsbereiche für die einzelnen Geschäftsbereiche erstellen, um Skalierungsprobleme zu vermeiden oder Budgets zu segmentieren.

Einrichtung von Umgebungen und Arbeitsbereichen

Eine Umgebung ist eine Sammlung von Ressourcen, auf die Bereitstellungen basierend auf ihrer Phase im Anwendungslebenszyklus ausgerichtet sind. Gängige Beispiele für Umgebungsnamen sind Dev, Test, QA, Staging und Production.

Der Entwicklungsprozess in Ihrer Organisation wirkt sich auf die Anforderungen für die Verwendung der Umgebung aus. Ihre Umgebung wirkt sich auf das Setup von Azure Machine Learning und zugeordneten Ressourcen (wie etwa angefügte Computeressourcen) aus. Beispielsweise kann die Datenverfügbarkeit Einschränkungen bei der Verwaltbarkeit einer Machine Learning-Instanz für jede Umgebung mit sich bringen. Die folgenden Lösungsmuster sind üblich:

Bereitstellung eines einzelnen Umgebungsarbeitsbereichs: Wenn Sie sich für die Bereitstellung eines einzelnen Umgebungsarbeitsbereichs entscheiden, erfolgt die Bereitstellung von Azure Machine Learning in einer einzelnen Umgebung. Dieses Setup ist für forschungszentrierte Szenarien üblich, bei denen Machine Learning-Artefakte nicht auf der Grundlage ihrer Lebenszyklusphase umgebungsübergreifend freigegeben werden müssen. Dieses Setup ist auch sinnvoll, wenn nur Rückschlussdienste und keine Machine Learning-Pipelines in verschiedenen Umgebungen bereitgestellt werden.

Der Vorteil eines forschungszentrierten Setups ist ein kleinerer Azure-Speicherbedarf und minimaler Verwaltungsaufwand. Diese Vorgehensweise bedeutet, dass nicht in jeder Umgebung ein Azure Machine Learning-Arbeitsbereich bereitgestellt werden muss.

Bei diesem Ansatz ist die Bereitstellung einer einzelnen Umgebung von der Datenverfügbarkeit abhängig. Gehen Sie also mit Bedacht vor, wenn Sie Ihren Datenspeicher einrichten. Wenn Sie einen umfangreichen Zugriff einrichten, z. B. den Schreibzugriff auf Produktionsdatenquellen, könnten Sie die Datenqualität versehentlich beeinträchtigen. Wenn Sie für Produktion und Entwicklung die gleiche Umgebung nutzen, gelten für Entwicklung und Produktion die gleichen RBAC-Einschränkungen. Mit diesem Setup könnten beide Umgebungen zu starr oder zu flexibel werden.

Diagram of a single environment workspace deployment in Azure Machine Learning.

Bereitstellung mehrerer Umgebungsarbeitsbereiche: Wenn Sie sich für die Bereitstellung mehrerer Umgebungsarbeitsbereiche entscheiden, wird für jede Umgebung eine Arbeitsbereichsinstanz bereitgestellt. Ein häufiges Szenario für diese Einrichtung ist ein regulierter Arbeitsbereich mit einer klaren Trennung der Aufgaben zwischen den Umgebungen und für Benutzer, die über Ressourcenzugriff auf diese Umgebungen verfügen.

Die Vorteile dieses Setups sind:

  • Gestaffelter Rollout von Machine Learning-Workflows und Artefakten. Beispielsweise verschiedene umgebungsübergreifende Modelle, mit der Möglichkeit, die Flexibilität zu verbessern und die Zeit bis zur Bereitstellung zu verkürzen.
  • Höhere Sicherheit und bessere Steuerung von Ressourcen, da Sie in nachgelagerten Umgebungen mehr Zugriffsbeschränkungen zuweisen können.
  • Trainingsszenarios für Produktionsdaten in Nicht-Entwicklungsumgebungen, da Sie einer ausgewählten Gruppe von Benutzern Zugriff einräumen können.

Dieser Ansatz geht möglicherweise mit einem höheren Verwaltungs- und Verarbeitungsaufwand einher. Dieses Setup erfordert einen differenzierten, arbeitsbereichsinstanzenübergreifenden Entwicklungs- und Rolloutprozess für Machine Learning-Artefakte. Außerdem sind ggf. Datenverwaltungs- und Datentechnikschritte erforderlich, um Produktionsdaten für das Training in der Entwicklungsumgebung verfügbar zu machen. Über die Zugriffsverwaltung müssen Sie einem Team Zugriff gewähren, um Vorfälle in der Produktion untersuchen und auflösen zu können. Und schließlich muss Ihr Team über technisches Azure DevOps- und Machine Learning-Fachwissen verfügen, um Automatisierungsworkflows implementieren zu können.

Diagram of a multiple environment workspace deployment in Azure Machine Learning.

Eine Umgebung mit eingeschränktem Datenzugriff, eine mit Zugriff auf Produktionsdaten: Wenn Sie sich für dieses Setup entscheiden, wird Azure Machine Learning in zwei Umgebungen bereitgestellt – einer mit eingeschränktem Datenzugriff und einer mit Zugriff auf die Produktionsdaten. Dieses Setup ist üblich, wenn Entwicklungs- und Produktionsumgebungen getrennt werden müssen. Vielleicht gelten z. B. organisatorische Einschränkungen für das Verfügbarmachen von Produktionsdaten in einer Umgebung, oder Sie möchten Entwicklungs- von Produktionsaufgaben trennen, ohne Daten mehr als nötig zu duplizieren, weil die Wartungskosten hoch sind.

Der Vorteil dieses Setups ist die klare Trennung von Aufgaben und Zugriff zwischen Entwicklungs- und Produktionsumgebungen. Ein weiterer Vorteil ist der geringere Ressourcenverwaltungsaufwand im Vergleich zu einem Bereitstellungsszenario mit mehreren Umgebungen.

Bei diesem Ansatz ist ein definierter Entwicklungs- und Rolloutprozess für Machine Learning-Artefakte in mehreren Arbeitsbereichen erforderlich. Außerdem sind ggf. Datenverwaltungs- und Datentechnikschritte erforderlich, um Produktionsdaten für das Training in einer Entwicklungsumgebung verfügbar zu machen. Aber der Aufwand ist unter Umständen geringer als bei einer Bereitstellung mehrerer Umgebungsarbeitsbereiche.

Diagram of an environment with limited data access, and an environment with production data access.

Einrichtung von Regionen und Ressourcen

Der Standort Ihrer Ressourcen, Daten oder Benutzer erfordert möglicherweise, dass Sie Azure Machine Learning-Arbeitsbereichsinstanzen und zugehörige Ressourcen in mehreren Azure-Regionen erstellen. Beispielsweise können sich die Ressourcen eines Projekts aus Leistungs-, Kosten- und Kompatibilitätsgründen über die Azure-Regionen „Europa, Westen“ und „USA, Osten“ erstrecken. Die folgenden Szenarien sind üblich:

Regionales Training: Die Machine Learning-Trainingsaufträge werden in derselben Azure-Region ausgeführt, in der sich die Daten befinden. In diesem Setup wird ein Machine Learning-Arbeitsbereich für jede Azure-Region bereitgestellt, in der sich Daten befinden. Dies ist ein gängiges Szenario, wenn Sie Konformitätsvorschriften einhalten müssen oder Einschränkungen bei der Datenverschiebung zwischen Regionen unterliegen.

Der Vorteil dieses Setups besteht darin, dass Experimente in dem Rechenzentrum, in dem sich die Daten befinden (und somit mit der geringstmöglichen Netzwerklatenz) durchgeführt werden können. Bei diesem Ansatz erhöht sich die Verwaltungskomplexität, wenn eine Machine Learning-Pipeline über mehrere Arbeitsbereichsinstanzen hinweg ausgeführt wird. Es wird zur Herausforderung, Experimentergebnisse Instanzen übergreifend zu vergleichen, und steigert den Kontingent- und Computeverwaltungsaufwand.

Wenn Sie Speicher Regionen übergreifend anfügen, aber Compute aus einer Region verwenden möchten, unterstützt Azure Machine Learning das Szenario, in einer Region Speicherkonten anstatt des Arbeitsbereichs anzufügen. Metadaten (z. B. Metriken) werden in der Arbeitsbereichsregion gespeichert.

Diagram of training jobs operating in the same Azure region as the data.

Regionale Bereitstellung: Die Bereitstellung von Machine Learning-Diensten erfolgt in der Nähe der Zielgruppe. Wenn sich die Zielbenutzer beispielsweise in Australien befinden und die Hauptspeicher- und Experimentierregion „Europa, Westen“ ist, stellen Sie den Machine Learning-Arbeitsbereich für Experimente in „Europa, Westen“ bereit. Anschließend stellen Sie einen AKS-Cluster für die Bereitstellung des Rückschlussendpunkts in Australien bereit.

Die Vorteile dieser Einrichtung sind die Möglichkeit, Rückschlüsse in dem Rechenzentrum durchzuführen, in dem neue Daten erfasst werden, wodurch Latenz und Datenverschiebungen minimiert werden, und die Einhaltung lokaler Vorschriften.

Bei diesem Ansatz bietet ein Setup mit mehreren Regionen zwar einige Vorteile, gleichzeitig erhöht sich aber auch der Verwaltungsaufwand für Kontingente und Computeressourcen. Wenn Batchrückschlüsse notwendig sind, erfordert die regionale Bereitstellung ggf. die Bereitstellung mehrerer Arbeitsbereiche. Mithilfe von Rückschlussendpunkten gesammelte Daten müssen möglicherweise für Szenarien mit erneutem Training über mehrere Regionen hinweg übertragen werden.

Diagram of Azure Machine Learning services deployed near where the target audience lives.

Regionale Feinabstimmung: Ein Basismodell wird mit einem anfänglichen Dataset trainiert, etwa mit öffentlichen Daten oder mit Daten aus allen Regionen. Später erfolgt dann die Feinabstimmung mit einem regionalen Dataset. Das regionale Dataset ist möglicherweise aufgrund von Konformitäts- oder Datenverschiebungseinschränkungen nur in einer bestimmten Region vorhanden. Das Basismodelltraining kann beispielsweise in einem Arbeitsbereich in Region A erfolgen und die Feinabstimmung findet in einem Arbeitsbereich in Region B statt.

Der Vorteil dieses Setups besteht darin, dass Sie konforme Experimente in dem Rechenzentrum durchführen können, in dem sich die Daten befinden. Außerdem können Sie trotzdem von dem Basismodelltraining für ein größeres Dataset in einer früheren Pipelinephase profitieren.

Dieser Ansatz unterstützt komplexe Experimentierpipelines, führt aber unter Umständen zu weiteren Herausforderungen. Wenn Sie beispielsweise Experimentergebnisse regionsübergreifend vergleichen, erhöht sich möglicherweise der Verwaltungsaufwand für Kontingente und Computeressourcen.

Diagram of an initial dataset deployed using public data or data from all regions, and fine-tuned later with a regional dataset.

Referenzimplementierung

Um die Bereitstellung von Azure Machine Learning in einem größeren Rahmen zu veranschaulichen, wird in diesem Abschnitt erläutert, wie die Organisation „Contoso“ unter Berücksichtigung ihrer Organisationseinschränkungen und der Anforderungen an Berichterstattung und Budgetierung Azure Machine Learning einrichtet:

  • Contoso erstellt Ressourcengruppen auf einer Lösungsgrundlage aus Kostenverwaltungs- und Berichterstattungsgründen.
  • IT-Administratoren erstellen nur Ressourcengruppen und Ressourcen für finanzierte Lösungen, um die Budgetanforderungen zu erfüllen.
  • Aufgrund des explorativen und unsicheren Wesens von Data Science benötigen Benutzer einen Ort, an dem sie experimentieren, an Anwendungsfällen arbeiten und Daten untersuchen können. Explorative Arbeit kann oft nicht direkt einem bestimmten Anwendungsfall zugeordnet werden, sondern nur einem Budget für Forschung und Entwicklung. Contoso möchte einige Machine Learning-Ressourcen, die jeder zu Untersuchungszwecken verwenden kann, zentral finanzieren.
  • Wenn sich ein Machine Learning-Anwendungsfall in der explorativen Umgebung als erfolgreich erweist, können Teams Ressourcengruppen anfordern. Das Unternehmen kann beispielsweise „Dev“, „QA“ und „Prod“ für iterative experimentelle Projektarbeit sowie Zugriff auf Produktionsdatenquellen einrichten.
  • Die Anforderungen an Datentrennung und Konformität lassen nicht zu, dass Liveproduktionsdaten in Entwicklungsumgebungen vorhanden sind.
  • Für verschiedene Benutzergruppen gelten je nach IT-Richtlinie pro Umgebung verschiedene RBAC-Anforderungen (beispielweise restriktiverer Zugriff in der Produktion).
  • Alle Daten, Experimente und Rückschlüsse werden in einer einzelnen Azure-Region gespeichert bzw. durchgeführt.

Um den oben genannten Anforderungen gerecht zu werden, richtet Contoso seine Ressourcen wie folgt ein:

  • Projektspezifische Azure Machine Learning-Arbeitsbereiche und -Ressourcengruppen, um die Anforderungen von Budgetplanung und Anwendungsfalltrennung zu erfüllen.
  • Eine Einrichtung mit mehreren Umgebungen für Azure Machine Learning und zugehörige Ressourcen, um Kostenverwaltung, RBAC und Datenzugriffsanforderungen zu berücksichtigen.
  • Eine einzelne Ressourcengruppe und ein dedizierter Machine Learning-Arbeitsbereich für die Untersuchung.
  • Microsoft Entra-Gruppen, die je nach Benutzerrolle und Umgebung unterschiedlich sind. Beispielsweise unterscheiden sich Vorgänge, die eine wissenschaftliche Fachkraft für Daten in einer Produktionsumgebung ausführen kann, von denen, die in der Entwicklungsumgebung möglich sind, und Zugriffsebenen können je nach Lösung verschieden sein.
  • Alle Ressourcen werden in einer einzelnen Azure-Region erstellt.

Diagram of a sample Azure Machine Learning multiple-environment setup for the Contoso organization.

Nächste Schritte

Informieren Sie sich über bewährte Methoden für DevOps für maschinelles Lernen mit Azure Machine Learning:

Informieren Sie sich über Überlegungen im Zusammenhang mit der Verwaltung von Budgets, Kontingenten und Kosten mit Azure Machine Learning: