Organisera och konfigurera Azure Machine Learning-miljöer
När du planerar en Azure Machine Learning-distribution för en företagsmiljö finns det några vanliga beslutspunkter som påverkar hur du skapar arbetsytan:
- Teamstruktur: Hur du organiserar dina datavetenskapsteam och samarbetar i projekt, beroende på användningsfall och datasegregering eller krav på kostnadshantering
- Miljöer: De miljöer som du använder som en del av ditt arbetsflöde för utveckling och lansering för att skilja utveckling från produktion
- Region: Platsen för dina data och den målgrupp som du behöver för att hantera din maskininlärningslösning
Konfiguration av teamstruktur och arbetsyta
Arbetsytan är resursen på den översta nivån i Azure Machine Learning. Den lagrar artefakterna som skapas när du arbetar med maskininlärning och hanterad beräkning och pekare till anslutna och associerade resurser. Från en hanterbarhetssynpunkt stöder arbetsytan som en Azure Resource Manager-resurs rollbaserad åtkomstkontroll (Azure RBAC), hantering efter princip, och du kan använda den som en enhet för kostnadsrapportering.
Organisationer väljer vanligtvis en eller en kombination av följande lösningsmönster för att följa kraven på hanterbarhet.
Arbetsyta per team: Använd en arbetsyta för varje team när alla medlemmar i ett team behöver samma åtkomstnivå till data- och experimenteringstillgångar. En organisation med tre maskininlärningsteam kan till exempel skapa tre arbetsytor, en för varje team.
Fördelen med att använda en arbetsyta per team är att alla maskininlärningsartefakter för teamets projekt lagras på ett och samma ställe. Du kan se produktivitetsökningar eftersom teammedlemmar enkelt kan komma åt, utforska och återanvända experimenteringsresultat. Att organisera dina arbetsytor efter team minskar ditt Azure-fotavtryck och förenklar kostnadshanteringen per team. Eftersom antalet experimenteringstillgångar kan öka snabbt kan du ordna artefakterna genom att följa namngivnings- och taggningskonventionerna. Rekommendationer om hur du namnger resurser finns i Utveckla din namngivnings- och taggningsstrategi för Azure-resurser.
Med den här metoden måste varje teammedlem ha liknande behörigheter på dataåtkomstnivå. Detaljerad rollbaserad åtkomstkontroll (RBAC) och åtkomstkontrollistor (ACL) för datakällor och experimenteringstillgångar är begränsade på en arbetsyta. Du kan inte ha krav på datasegregering för användningsfall.
Arbetsyta per projekt: Använd en arbetsyta för varje projekt om du behöver segregering av data och experimenteringstillgångar efter projekt eller har kostnadsrapporterings- och budgeteringskrav på projektnivå. Du kan till exempel ha en organisation med fyra maskininlärningsteam som kör tre projekt var för totalt 12 arbetsyteinstanser.
Fördelen med att använda en arbetsyta per projekt är att du hanterar kostnader på projektnivå. Ett team skapar vanligtvis en dedikerad resursgrupp för Azure Machine Learning och associerade resurser av liknande skäl. När du arbetar med externa deltagare, till exempel, förenklar en projektcentrerad arbetsyta samarbetet i ett projekt eftersom externa användare bara behöver beviljas åtkomst till projektresurserna, inte gruppresurserna.
Något att tänka på med den här metoden är isoleringen av experimentresultat och tillgångar. Det kan vara svårare att identifiera och återanvända tillgångar eftersom tillgångarna är spridda över flera arbetsyteinstanser.
Enskild arbetsyta: Använd en arbetsyta för icke-team- eller icke-projektrelaterat arbete, eller när kostnader inte kan kopplas direkt till en specifik faktureringsenhet, till exempel med R&D.
Fördelen med den här konfigurationen är kostnaden för enskilt, icke-projektrelaterat arbete kan frikopplas från projektrelaterade kostnader. När du konfigurerar en enda arbetsyta för alla användare att utföra sitt enskilda arbete minskar du ditt Azure-fotavtryck.
Med den här metoden kan arbetsytan bli rörig snabbt när många maskininlärningsutövare delar samma instans. Användare kan kräva användargränssnittsbaserad filtrering av tillgångar för att effektivt hitta sina resurser. Du kan skapa delade maskininlärningsarbetsytor för varje affärsdivision för att minska skalningsproblem eller segmentbudgetar.
Inställningar för miljöer och arbetsytor
En miljö är en samling resurser som distribuerar mål baserat på deras fas i programmets livscykel. Vanliga exempel på miljönamn är Dev, Test, QA, Staging och Production.
Utvecklingsprocessen i din organisation påverkar kraven för miljöanvändning. Din miljö påverkar konfigurationen av Azure Machine Learning och associerade resurser, till exempel ansluten beräkning. Till exempel kan datatillgänglighet begränsa hanterbarheten för att ha en maskininstans tillgänglig för varje miljö. Följande lösningsmönster är vanliga:
Distribution av en enskild miljöarbetsyta: När du väljer en enda miljödistribution av arbetsytor distribueras Azure Machine Learning till en miljö. Den här konfigurationen är vanlig för forskningscentrerade scenarier, där det inte finns något behov av att släppa maskininlärningsartefakter baserat på livscykelfasen i olika miljöer. Ett annat scenario där den här konfigurationen är meningsfull är när endast slutsatsdragningstjänster, och inte maskininlärningspipelines, distribueras i olika miljöer.
Fördelen med en forskningscentrerad konfiguration är ett mindre Azure-fotavtryck och minimala hanteringskostnader. Det här sättet att arbeta innebär att du inte behöver ha en Azure Machine Learning-arbetsyta distribuerad i varje miljö.
Med den här metoden omfattas en enskild miljödistribution av datatillgänglighet. Var därför försiktig när du konfigurerar ditt datalager. Om du konfigurerar omfattande åtkomst, till exempel skrivåtkomst till produktionsdatakällor, kan du oavsiktligt skada datakvaliteten. Om du tar arbete till produktion i samma miljö där utvecklingen sker gäller samma RBAC-begränsningar för både utvecklingsarbetet och produktionsarbetet. Den här konfigurationen kan göra båda miljöerna för stela eller för flexibla.
Distribution av flera miljöarbetsytor: När du väljer en distribution av flera miljöarbetsytor distribueras en arbetsyteinstans för varje miljö. Ett vanligt scenario för den här konfigurationen är en reglerad arbetsplats med en tydlig uppdelning av uppgifter mellan miljöer och för användare som har resursåtkomst till dessa miljöer.
Fördelarna med den här konfigurationen är:
- Stegvis distribution av arbetsflöden och artefakter för maskininlärning. Till exempel modeller i olika miljöer, med potential att förbättra flexibiliteten och minska tiden till distribution.
- Förbättrad säkerhet och kontroll av resurser eftersom du kan tilldela fler åtkomstbegränsningar i underordnade miljöer.
- Träningsscenarier för produktionsdata i miljöer som inte är utvecklingsmiljöer eftersom du kan ge en utvald grupp användare åtkomst.
Med den här metoden riskerar du mer hantering och processkostnader. Den här konfigurationen kräver en detaljerad utveckling och distributionsprocess för maskininlärningsartefakter i arbetsyteinstanser. Datahantering och tekniska åtgärder kan också krävas för att göra produktionsdata tillgängliga för utbildning i utvecklingsmiljön. Åtkomsthantering kräver att du ger ett team åtkomst för att lösa och undersöka incidenter i produktion. Slutligen behöver ditt team kunskaper om Azure DevOps och maskininlärningsteknik för att implementera automatiseringsarbetsflöden.
En miljö med begränsad dataåtkomst, en med åtkomst till produktionsdata: När du väljer den här konfigurationen distribueras Azure Machine Learning till två miljöer: en med begränsad dataåtkomst och en med åtkomst till produktionsdata. Den här konfigurationen är vanlig om du behöver separera utvecklings- och produktionsmiljöer. Du kanske till exempel arbetar under organisatoriska begränsningar för att göra produktionsdata tillgängliga i alla miljöer, eller så kanske du vill skilja utvecklingsarbete från produktionsarbete utan att duplicera data mer än vad som krävs på grund av de höga underhållskostnaderna.
Fördelen med den här installationen är en tydlig uppdelning av uppgifter och åtkomst mellan utvecklings- och produktionsmiljöer. En annan fördel är lägre resurshanteringskostnader jämfört med ett distributionsscenario med flera miljöer.
Med den här metoden behöver du en definierad utveckling och distributionsprocess för maskininlärningsartefakter på arbetsytor. Det kan också kräva datahantering och tekniska insatser för att göra produktionsdata tillgängliga för utbildning i en utvecklingsmiljö. Men den här metoden kan kräva relativt mindre arbete än en distribution av arbetsytor i flera miljöer.
Regions- och resurskonfiguration
Platsen för dina resurser, data eller användare kan kräva att du skapar Azure Machine Learning-arbetsyteinstanser och associerade resurser i flera Azure-regioner. Ett projekt kan till exempel sträcka sig över sina resurser i Azure-regionerna Europa, västra och USA, östra av prestanda-, kostnads- och efterlevnadsskäl. Följande scenarier är vanliga:
Regional utbildning: Maskininlärningsträningsjobben körs i samma Azure-region som där data finns. I den här konfigurationen distribuerar en arbetsyta för maskininlärning till varje Azure-region där data finns. Det här scenariot är vanligt när du behöver uppfylla efterlevnaden eller när du har begränsningar för dataflytt mellan regioner.
Fördelen med den här konfigurationen är att du kan experimentera i datacentret där data finns med minst nätverksfördröjning. Med den här metoden ger en maskininlärningspipeline mer hanteringskomplexitet när en maskininlärningspipeline körs över flera arbetsyteinstanser. Det blir svårt att jämföra experimenteringsresultat mellan instanser och lägger till omkostnader för kvot- och beräkningshantering.
Om du vill koppla lagring mellan regioner, men använda beräkning från en region, stöder Azure Machine Learning scenariot att koppla lagringskonton i en region i stället för arbetsytan. Metadata, till exempel mått, lagras i arbetsyteregionen.
Regional servering: Maskininlärningstjänster distribueras nära där målgruppen bor. Om målanvändare till exempel finns i Australien och den huvudsakliga lagrings- och experimenteringsregionen är Europa, västra, distribuerar du arbetsytan för maskininlärning för experimentering i Europa, västra. Sedan distribuerar du ett AKS-kluster för slutpunktsdistribution av slutsatsdragning i Australien.
Fördelarna med den här konfigurationen är möjligheten till slutsatsdragning i datacentret där nya data matas in, vilket minimerar svarstiden och dataförflyttningen och efterlevnaden av lokala regler.
Med den här metoden ger en konfiguration med flera regioner flera fördelar, men lägger även till mer omkostnader för kvot- och beräkningshantering. När du har ett krav för batch-slutsatsdragning kan regional servering kräva en distribution av flera arbetsytor. Data som samlas in via slutsatsdragningsslutpunkter kan behöva överföras mellan regioner för omträningsscenarier.
Regional finjustering: En basmodell tränar på en inledande datamängd, till exempel offentliga data eller data från alla regioner, och finjusteras senare med en regional datauppsättning. Den regionala datamängden kanske bara finns i en viss region på grund av efterlevnads- eller dataförflyttningsbegränsningar. Du kan till exempel behöva grundmodellträning på en arbetsyta i region A, medan finjustering sker på en arbetsyta i region B.
Fördelen med den här konfigurationen är att du kan experimentera kompatibelt i det datacenter där data finns. Du kan också fortfarande dra nytta av basmodellträning på en större datamängd i ett tidigare pipelinesteg.
Den här metoden stöder komplexa experimenteringspipelines, men det kan skapa fler utmaningar. När du till exempel jämför experimentresultat mellan regioner kan det lägga till mer omkostnader för kvoten och beräkningshanteringen.
Referensimplementering
För att illustrera distributionen av Azure Machine Learning i en större inställning visar det här avsnittet hur organisationen "Contoso" konfigurerar Azure Machine Learning med tanke på organisationens krav på begränsningar, rapportering och budgetering:
- Contoso skapar resursgrupper på lösningsbasis av kostnadshanterings- och rapporteringsskäl.
- IT-administratörer skapar bara resursgrupper och resurser för finansierade lösningar för att uppfylla budgetkraven.
- På grund av den undersökande och osäkra karaktären hos Datavetenskap behöver användarna en plats för att experimentera och arbeta för användningsfall och datautforskning. Ofta kan undersökande arbete inte kopplas direkt till ett visst användningsfall och kan endast associeras till en R&D-budget. Contoso vill finansiera vissa maskininlärningsresurser centralt som vem som helst kan använda i utforskningssyfte.
- När ett användningsfall för maskininlärning visar sig vara framgångsrikt i den undersökande miljön kan team begära resursgrupper. Företaget kan till exempel konfigurera Dev, QA och Production för iterativt experimenteringsprojekt och åtkomst till produktionsdatakällor.
- Krav på datasegregering och efterlevnad tillåter inte att liveproduktionsdata finns i utvecklingsmiljöer.
- Olika RBAC-krav finns för olika användargrupper efter IT-princip per miljö, till exempel är åtkomsten mer restriktiv i produktionen.
- Alla data, experimentering och slutsatsdragning sker i en enda Azure-region.
För att uppfylla ovanstående krav konfigurerar Contoso sina resurser på följande sätt:
- Azure Machine Learning-arbetsytor och resursgrupper som är begränsade per projekt för att följa budgeterings- och användningsfallsavgränsningskrav.
- En konfiguration med flera miljöer för Azure Machine Learning och associerade resurser för att hantera krav på kostnadshantering, RBAC och dataåtkomst.
- En enda resursgrupp och en maskininlärningsarbetsyta som är dedikerad för utforskning.
- Microsoft Entra-grupper som skiljer sig mellan användarroller och miljöer. Åtgärder som en dataexpert kan utföra i en produktionsmiljö skiljer sig till exempel från utvecklingsmiljön, och åtkomstnivåerna kan skilja sig åt per lösning.
- Alla resurser som skapats i en enda Azure-region.
Nästa steg
Lär dig mer om metodtips för machine learning DevOps med Azure Machine Learning.
Lär dig mer om överväganden när du hanterar budgetar, kvoter och kostnader med Azure Machine Learning.