Organiseren en instellen van Azure Machine Learning-omgevingen

Wanneer u een Azure Machine Learning-implementatie plant voor een bedrijfsomgeving, zijn er enkele veelvoorkomende beslissingspunten die van invloed zijn op de wijze waarop u de werkruimte maakt:

• Teamstructuur: de manier waarop u uw data science-teams ordent en samenwerkt aan projecten, gezien use-case en gegevensscheiding, of vereisten voor kostenbeheer
• Omgevingen: De omgevingen die u gebruikt als onderdeel van uw ontwikkel- en releasewerkstroom om de ontwikkeling van productie te scheiden
• Regio: De locatie van uw gegevens en de doelgroep waarvoor u uw machine learning-oplossing moet leveren

Teamstructuur en werkruimte-instelling

De werkruimte is de resource op het hoogste niveau in Azure Machine Learning. Het slaat de artefacten op die worden geproduceerd bij het werken met machine learning en de beheerde rekenkracht en de aanwijzers naar gekoppelde en gekoppelde resources. Vanuit het oogpunt van beheerbaarheid ondersteunt de werkruimte als Een Azure Resource Manager-resource op rollen gebaseerd toegangsbeheer (Azure RBAC), beheer per beleid en kunt u deze gebruiken als eenheid voor kostenrapportage.

Organisaties kiezen doorgaans een of een combinatie van de volgende oplossingspatronen om de vereisten voor beheerbaarheid te volgen.

Werkruimte per team: gebruik één werkruimte voor elk team wanneer alle leden van een team hetzelfde toegangsniveau tot gegevens en experimentele assets vereisen. Een organisatie met drie machine learning-teams kan bijvoorbeeld drie werkruimten maken, één voor elk team.

Het voordeel van het gebruik van één werkruimte per team is dat alle machine learning-artefacten voor de projecten van het team op één plaats worden opgeslagen. U kunt productiviteitsverhogingen zien omdat teamleden eenvoudig experimenten kunnen openen, verkennen en hergebruiken. Het organiseren van uw werkruimten per team vermindert uw Azure-footprint en vereenvoudigt kostenbeheer per team. Omdat het aantal experimentele assets snel kan groeien, kunt u uw artefacten georganiseerd houden door de naamgevings- en tagconventies te volgen. Zie Uw naamgevings- en tagstrategie voor Azure-resources ontwikkelen voor aanbevelingen over het benoemen van resources.

Met deze aanpak moet elk teamlid vergelijkbare machtigingen op gegevenstoegangsniveau hebben. Gedetailleerde op rollen gebaseerd toegangsbeheer (RBAC) en toegangsbeheerlijsten (ACL) voor gegevensbronnen en experimentenassets zijn beperkt binnen een werkruimte. U kunt geen gebruiksvereisten voor het scheiden van casegegevens hebben.

Werkruimte per project: gebruik één werkruimte voor elk project als u scheiding van gegevens en experimenteerassets per project nodig hebt, of kostenrapportage- en budgetvereisten op projectniveau hebt. U hebt bijvoorbeeld een organisatie met vier machine learning-teams die elk drie projecten uitvoeren voor in totaal 12 werkruimte-exemplaren.

Het voordeel van het gebruik van één werkruimte per project is dat u kosten op projectniveau beheert. Een team maakt doorgaans om vergelijkbare redenen een toegewezen resourcegroep voor Azure Machine Learning en gekoppelde resources. Wanneer u bijvoorbeeld met externe inzenders werkt, vereenvoudigt een gecentreerde werkruimte de samenwerking in een project omdat externe gebruikers alleen toegang hoeven te krijgen tot de projectbronnen, niet de teambronnen.

Iets om rekening mee te houden met deze benadering is de isolatie van experimentele resultaten en assets. Het detecteren en hergebruik van assets kan lastiger zijn omdat assets zijn verdeeld over meerdere werkruimte-exemplaren.

Eén werkruimte: gebruik één werkruimte voor niet-team- of niet-projectgerelateerd werk, of wanneer de kosten niet rechtstreeks aan een specifieke factureringseenheid kunnen worden gekoppeld, bijvoorbeeld met R&D.

Het voordeel van deze installatie is de kosten van afzonderlijke, niet-projectgerelateerde werkzaamheden kunnen worden losgekoppeld van projectgerelateerde kosten. Wanneer u één werkruimte instelt voor alle gebruikers om hun afzonderlijke werk te doen, vermindert u uw Azure-footprint.

Met deze benadering kan de werkruimte snel onoverzichtelijk worden wanneer veel machine learning-beoefenaars hetzelfde exemplaar delen. Gebruikers moeten mogelijk filteren op basis van de gebruikersinterface van assets om hun resources effectief te vinden. U kunt gedeelde machine learning-werkruimten maken voor elke bedrijfsafdeling om schaalproblemen te beperken of budgetten te segmenteren.

Omgevingen en werkruimte-instellingen

Een omgeving is een verzameling resources die gericht zijn op implementaties op basis van hun fase in de levenscyclus van de toepassing. Veelvoorkomende voorbeelden van omgevingsnamen zijn Dev, Test, QA, Staging en Production.

Het ontwikkelingsproces in uw organisatie is van invloed op de vereisten voor het gebruik van de omgeving. Uw omgeving is van invloed op de installatie van Azure Machine Learning en gekoppelde resources, zoals gekoppelde rekenkracht. Gegevensbeschikbaarheid kan bijvoorbeeld de beheerbaarheid beperken van een machine learning-exemplaar dat beschikbaar is voor elke omgeving. De volgende oplossingspatronen zijn gebruikelijk:

Implementatie van één omgevingswerkruimte: Wanneer u een implementatie van één omgevingswerkruimte kiest, wordt Azure Machine Learning geïmplementeerd in één omgeving. Deze installatie is gebruikelijk voor scenario's met onderzoekscentrum, waarbij machine learning-artefacten niet hoeven te worden vrijgegeven op basis van hun levenscyclusfase in verschillende omgevingen. Een ander scenario waarin deze installatie zinvol is, is wanneer alleen deductieservices en niet machine learning-pijplijnen worden geïmplementeerd in omgevingen.

Het voordeel van een onderzoeksgerichte installatie is een kleinere Azure-footprint en minimale beheeroverhead. Deze manier van werken impliceert dat er geen Azure Machine Learning-werkruimte in elke omgeving hoeft te worden geïmplementeerd.

Bij deze benadering is één omgevingsimplementatie onderhevig aan de beschikbaarheid van gegevens. Wees dus voorzichtig wanneer u uw gegevensarchief instelt. Als u uitgebreide toegang instelt, bijvoorbeeld schrijftoegang voor productiegegevensbronnen, kunt u onbedoeld de gegevenskwaliteit schaden. Als u werk naar productie brengt in dezelfde omgeving waar de ontwikkeling plaatsvindt, gelden dezelfde RBAC-beperkingen voor zowel het ontwikkelingswerk als het productiewerk. Deze instelling kan beide omgevingen te stijf of te flexibel maken.

Implementatie van meerdere omgevingswerkruimten: wanneer u een implementatie van meerdere omgevingswerkruimten kiest, wordt een werkruimte-exemplaar voor elke omgeving geïmplementeerd. Een veelvoorkomend scenario voor deze installatie is een gereguleerde werkplek met een duidelijke scheiding van taken tussen omgevingen en voor gebruikers die toegang hebben tot deze omgevingen.

De voordelen van deze installatie zijn:

• Gefaseerde implementatie van machine learning-werkstromen en artefacten. Bijvoorbeeld modellen in omgevingen, met het potentieel om de flexibiliteit te verbeteren en de implementatietijd te verminderen.
• Verbeterde beveiliging en controle van resources omdat u meer toegangsbeperkingen kunt toewijzen in downstreamomgevingen.
• Trainingsscenario's voor productiegegevens in niet-ontwikkelomgevingen, omdat u een bepaalde groep gebruikers toegang kunt geven.

Met deze aanpak loopt u risico op meer beheer- en procesoverhead. Voor deze installatie is een gedetailleerd ontwikkelings- en implementatieproces vereist voor machine learning-artefacten in werkruimte-exemplaren. Daarnaast is het mogelijk dat gegevensbeheer en technische inspanningen nodig zijn om productiegegevens beschikbaar te maken voor training in de ontwikkelomgeving. Voor toegangsbeheer moet u een team toegang geven om incidenten in productie op te lossen en te onderzoeken. En ten slotte heeft uw team kennis van Azure DevOps en machine learning-engineering nodig om automatiseringswerkstromen te implementeren.

Eén omgeving met beperkte gegevenstoegang, één met productiegegevenstoegang: Wanneer u deze installatie kiest, wordt Azure Machine Learning geïmplementeerd in twee omgevingen: één met beperkte gegevenstoegang en één met productiegegevenstoegang. Deze installatie is gebruikelijk als u ontwikkel- en productieomgevingen wilt scheiden. U werkt bijvoorbeeld onder organisatiebeperkingen om productiegegevens beschikbaar te maken in elke omgeving of u wilt ontwikkelingswerk scheiden van productiewerk zonder dat u gegevens meer dupliceert dan vereist vanwege de hoge onderhoudskosten.

Het voordeel van deze installatie is de duidelijke scheiding van taken en toegang tussen ontwikkel- en productieomgevingen. Een ander voordeel is lagere overhead voor resourcebeheer in vergelijking met een implementatiescenario met meerdere omgevingen.

Met deze aanpak hebt u een gedefinieerd ontwikkelings- en implementatieproces nodig voor machine learning-artefacten in werkruimten. Het kan ook nodig zijn om gegevensbeheer en technische inspanningen te leveren om productiegegevens beschikbaar te maken voor training in een ontwikkelomgeving. Maar deze benadering vereist mogelijk relatief minder inspanning dan een implementatie van een werkruimte met meerdere omgevingen.

Regio's en resources instellen

Voor de locatie van uw resources, gegevens of gebruikers is het mogelijk dat u azure Machine Learning-werkruimte-exemplaren en bijbehorende resources in meerdere Azure-regio's moet maken. Eén project kan bijvoorbeeld de resources omvatten in de Azure-regio's Europa - west en VS - oost om prestatie-, kosten- en nalevingsredenen. De volgende scenario's zijn gebruikelijk:

Regionale training: De machine learning-trainingstaken worden uitgevoerd in dezelfde Azure-regio als waar de gegevens zich bevinden. In deze installatie wordt een machine learning-werkruimte geïmplementeerd in elke Azure-regio waar de gegevens zich bevinden. Dit scenario is gebruikelijk wanneer u moet voldoen aan naleving of wanneer u beperkingen voor gegevensverplaatsing hebt in verschillende regio's.

Het voordeel van deze installatie is dat u kunt experimenteren in het datacenter waar de gegevens zich bevinden met de minste netwerklatentie. Wanneer een machine learning-pijplijn wordt uitgevoerd op meerdere werkruimte-exemplaren, wordt met deze methode meer beheercomplexiteit toegevoegd. Het wordt lastig om experimentele resultaten te vergelijken tussen exemplaren en overhead toe te brengen aan quotum- en rekenbeheer.

Als u opslag wilt koppelen tussen regio's, maar rekenkracht uit één regio wilt gebruiken, ondersteunt Azure Machine Learning het scenario van het koppelen van opslagaccounts in een regio in plaats van de werkruimte. Metagegevens, bijvoorbeeld metrische gegevens, worden opgeslagen in de werkruimteregio.

Regionale dienstverlening: Machine Learning-services implementeren dicht bij de locatie waar de doelgroep zich bevindt. Als doelgebruikers zich bijvoorbeeld in Australië bevinden en de belangrijkste opslag- en experimentenregio Europa - west is, implementeert u de machine learning-werkruimte voor experimenten in Europa - west. Vervolgens implementeert u een AKS-cluster voor deductie-eindpuntimplementatie in Australië.

De voordelen van deze installatie zijn de mogelijkheid voor deductie in het datacenter waar nieuwe gegevens worden opgenomen, waardoor latentie en gegevensverplaatsing worden geminimaliseerd en de lokale regelgeving wordt nageleefd.

Met deze aanpak biedt een installatie met meerdere regio's verschillende voordelen, maar voegt ook meer overhead toe aan quotum- en rekenbeheer. Wanneer u een vereiste voor batchdeductie hebt, is voor regionale bediening mogelijk een implementatie met meerdere werkruimten vereist. Gegevens die worden verzameld via deductie-eindpunten, moeten mogelijk worden overgedragen tussen regio's voor het opnieuw trainen van scenario's.

Regionale afstemming: Een basismodel traint op een eerste gegevensset, bijvoorbeeld openbare gegevens of gegevens uit alle regio's, en wordt later afgestemd op een regionale gegevensset. De regionale gegevensset bestaat mogelijk alleen in een bepaalde regio vanwege beperkingen voor naleving of gegevensverplaatsing. U moet bijvoorbeeld basismodeltraining uitvoeren in een werkruimte in regio A, terwijl het afstemmen plaatsvindt in een werkruimte in regio B.

Het voordeel van deze installatie is dat u compatibel kunt experimenteren in het datacenter waar de gegevens zich bevinden. U kunt ook nog steeds profiteren van basismodeltraining op een grotere gegevensset in een eerdere pijplijnfase.

Deze benadering ondersteunt complexe experimentenpijplijnen, maar er kunnen meer uitdagingen ontstaan. Wanneer u bijvoorbeeld experimentresultaten vergelijkt tussen regio's, kan dit meer overhead toevoegen aan het quotum- en rekenbeheer.

Referentie-implementatie

Als u de implementatie van Azure Machine Learning in een grotere instelling wilt illustreren, ziet u in deze sectie hoe de organisatie Contoso Azure Machine Learning instelt op basis van de vereisten voor organisatiebeperkingen, rapportage en budgettering:

• Contoso maakt resourcegroepen op basis van een oplossing om kostenbeheer en rapportageredenen.
• IT-beheerders maken alleen resourcegroepen en resources voor gefinancierde oplossingen om te voldoen aan budgetvereisten.
• Vanwege de verkennende en onzekere aard van Datawetenschap hebben gebruikers een plek nodig om te experimenteren en te werken voor gebruiksscenario's en gegevensverkenning. Vaak kan verkennend werk niet rechtstreeks worden gekoppeld aan een bepaalde use-case en kan deze alleen worden gekoppeld aan een R&D-budget. Contoso wil een aantal machine learning-resources centraal financieren die iedereen kan gebruiken voor verkenningsdoeleinden.
• Zodra een machine learning-use case succesvol blijkt te zijn in de verkennende omgeving, kunnen teams resourcegroepen aanvragen. Het bedrijf kan bijvoorbeeld Dev, QA en Production instellen voor iteratieve experimenten en toegang tot productiegegevensbronnen.
• Gegevensscheidings- en nalevingsvereisten staan niet toe dat liveproductiegegevens aanwezig zijn in ontwikkelomgevingen.
• Er bestaan verschillende RBAC-vereisten voor verschillende gebruikersgroepen per IT-beleid per omgeving. Zo is de toegang in productie beperkter.
• Alle gegevens, experimenten en deductie vindt plaats in één Azure-regio.

Om aan de bovenstaande vereisten te voldoen, stelt Contoso hun resources op de volgende manier in:

• Azure Machine Learning-werkruimten en resourcegroepen binnen het bereik per project om te voldoen aan budgetterings- en use-casescheidingsvereisten.
• Een installatie met meerdere omgevingen voor Azure Machine Learning en bijbehorende resources om te voldoen aan vereisten voor kostenbeheer, RBAC en gegevenstoegang.
• Eén resourcegroep en machine learning-werkruimte die speciaal zijn toegewezen voor verkenning.
• Microsoft Entra-groepen die per gebruikersrol en omgeving verschillen. Bewerkingen die een data scientist in een productieomgeving kan uitvoeren, zijn bijvoorbeeld anders dan in de ontwikkelomgeving en toegangsniveaus kunnen per oplossing verschillen.
• Alle resources die zijn gemaakt in één Azure-regio.

Volgende stappen

Meer informatie over aanbevolen procedures voor machine learning DevOps met Azure Machine Learning.

DevOps-handleiding voor Machine Learning

Meer informatie over overwegingen bij het beheren van budgetten, quota en kosten met Azure Machine Learning.

Budgetten, kosten en quota voor Azure Machine Learning op organisatieschaal beheren