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 dina datavetenskapsteam är organiserade och samarbetar i projekt med tanke på användningsfall och dataavgränsning eller kostnadshanteringskrav.

  • Miljöer: De miljöer som används som en del av ditt utvecklings- och versionsarbetsflöde för att särskilja utveckling från produktion.

  • Regionen: Platsen för dina data och målgruppen som du behöver hantera din Machine Learning lösning på.

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 Machine Learning och den hanterade beräkningen och pekare till anslutna och associerade resurser. Ur hanterbarhetssynpunkt möjliggör arbetsytan som en Azure-Resource Manager resurs rollbaserad åtkomstkontroll i Azure (Azure RBAC), hantering av principer och kan användas som en enhet för kostnadsrapportering.

Organisationer väljer vanligtvis ett eller en kombination av följande lösningsmönster för att följa kraven på hanterbarhet.

Arbetsyta per team: Välj att använda 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 Machine Learning artefakter för teamets projekt lagras på ett och samma ställe. Produktivitetsökningar kan realiseras 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 växa snabbt kan du hålla ordning på artefakterna genom att följa namngivnings- och taggningskonventionerna. Rekommendationer om hur du namnger resurser finns i Utveckla din strategi för namngivning och taggning för Azure-resurser.

Ett övervägande för den här metoden är att varje teammedlem måste ha liknande behörigheter på dataåtkomstnivå. Detaljerade RBAC- och åtkomstkontrollistor (ACL) för datakällor och experimenteringstillgångar är begränsade inom en arbetsyta. Du kan inte ha krav på dataavgränsning för användningsfall.

Arbetsyta per projekt: Välj att använda en arbetsyta för varje projekt om du behöver segregera data och experimenteringstillgångar efter projekt, eller ha kostnadsrapporterings- och budgeteringskrav på projektnivå. En organisation med fyra maskininlärningsteam som vart och ett kör tre projekt kan till exempel skapa 12 arbetsyteinstanser.

Fördelen med att använda en arbetsyta per projekt är att kostnaderna kan hanteras på projektnivå. Teams vanligtvis skapa 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.

Ett övervägande med den här metoden är isolering av experimentresultat och tillgångar. Identifieringen och återanvändningen av tillgångarna kan vara svårare på grund av att tillgångar sprids över flera arbetsyteinstanser.

Enskild arbetsyta: Välj att använda 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 RD&.

Fördelen med den här konfigurationen är att 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.

Ett övervägande för den här metoden är att arbetsytan kan bli rörig snabbt när många Machine Learning utövare delar samma instans. Användare kan kräva gränssnittsbaserad filtrering av tillgångar för att effektivt hitta sina resurser. Du kan skapa delade Machine Learning arbetsytor 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 distributionsmålet baseras 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 Machine Learning instans tillgänglig för varje miljö. Följande lösningsmönster är vanliga:

Distribution av arbetsyta för enskild miljö: När du väljer en distribution av en enskild miljöarbetsyta 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 Machine Learning artefakter baserat på livscykelsteget, mellan miljöer. Ett annat scenario där den här konfigurationen är meningsfull är när endast slutsatsdragning av tjänster, och inte Machine Learning pipelines, distribueras i olika miljöer.

Fördelen med en forskningscentrerad konfiguration är ett mindre Azure-fotavtryck och minimal hantering. Det här sättet att arbeta innebär att du inte behöver ha en Azure Machine Learning arbetsyta distribuerad i varje miljö.

Ett övervägande för den här metoden är att en enskild miljödistribution omfattas av datatillgänglighet. Du måste vara försiktig när datalagringen har konfigurerats. 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 är klar 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.

Single environment deployment

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 ansvarsfördelning 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 Machine Learning arbetsflöden och artefakter. Till exempel modeller i olika miljöer, med potential att öka flexibiliteten och minska tiden till distribution.

  • Förbättrad säkerhet och kontroll av resurser eftersom du har möjlighet att tilldela fler åtkomstbegränsningar i underordnade miljöer.

  • Träningsscenarier för produktionsdata i icke-utvecklingsmiljöer eftersom du kan ge en utvald grupp användare åtkomst.

Ett övervägande för den här metoden är att du riskerar mer hantering och processkostnader eftersom den här konfigurationen kräver en detaljerad utveckling och distributionsprocess för Machine Learning artefakter mellan arbetsyteinstanser. Dessutom kan datahantering och tekniska åtgärder krävas för att göra produktionsdata tillgängliga för utbildning i utvecklingsmiljön. Åtkomsthantering krävs för att du ska kunna ge ett team åtkomst för att lösa och undersöka incidenter i produktion. Och slutligen behövs Azure DevOps och Machine Learning tekniska kunskaper i ditt team för att implementera automatiseringsarbetsflöden.

Multiple environment deployment

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 särskilja utvecklings- och produktionsmiljöer. Du kanske till exempel arbetar med organisationsbegrä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 den höga underhållskostnaden.

Fördelen med den här konfigurationen ä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.

Ett övervägande för den här metoden är en definierad utveckling och distributionsprocess för Machine Learning artefakter mellan arbetsytor krävs. Ett annat övervägande är datahantering och tekniska åtgärder kan krävas för att göra produktionsdata tillgängliga för träning i en utvecklingsmiljö. Det kan dock kräva relativt mindre arbete än en distribution av arbetsytor med flera miljöer.

One environment with limited data access, one environment with production data access

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 distribueras en Machine Learning arbetsyta till varje Azure-region där data finns. Det är ett vanligt scenario när du agerar under efterlevnad eller när du har begränsningar för dataflytt mellan regioner.

Fördelen med den här konfigurationen är att experimentering kan göras i datacentret där data finns med minsta möjliga nätverksfördröjning. Ett övervägande för den här metoden är när en Machine Learning pipeline körs över flera arbetsyteinstanser, vilket ger mer hanteringskomplexitet. Det blir svårt att jämföra experimenteringsresultat mellan instanser och lägga 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 training

Regional tjänstgöring: Machine Learning tjä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 den Machine Learning arbetsytan för experimentering i Europa, västra och distribuerar ett AKS-kluster för slutsatsdragningsslutpunktsdistribution i Australien.

Fördelarna med den här konfigurationen är möjligheten till slutsatsdragning i datacentret där nya data matas in, vilket minimerar svarstid och dataflytt samt efterlevnad av lokala föreskrifter.

Ett övervägande för den här metoden är att en konfiguration i flera regioner ger flera fördelar. Den ger också mer omkostnader för kvot- och beräkningshantering. När det finns ett krav för batch-slutsatsdragning kan regional servering kräva en distribution med flera arbetsytor. Data som samlas in via slutsatsdragningsslutpunkter kan behöva överföras mellan regioner för omträningsscenarier.

Regional serving

Regional finjustering: En basmodell tränas på en inledande datauppsättning, till exempel offentliga data eller data från alla regioner, och finjusteras senare med en regional datauppsättning. Den regionala datauppsättningen kanske bara finns i en viss region på grund av efterlevnads- eller dataförflyttningsbegränsningar. Till exempel kan basmodellträning utföras i en arbetsyta i region A, medan finjustering kan göras på en arbetsyta i region B.

Fördelen med den här konfigurationen är att experimentering är tillgänglig i enlighet med datacentret där data finns och fortfarande drar nytta av basmodellträningen på en större datauppsättning i ett tidigare pipelinesteg.

Ett övervägande är att den här metoden ger möjlighet till komplexa experimenteringspipelines, men det kan skapa fler utmaningar. Du kan till exempel jämföra experimentresultat mellan regioner och lägga till mer omkostnader för kvot- och beräkningshantering.

Regional fine-tuning

Referensimplementering

För att illustrera distributionen av Azure Machine Learning i en större inställning beskriver det här avsnittet hur organisationen Contoso har konfigurerat 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 datavetenskapens undersökande och osäkra natur 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 RD-budget&. Contoso vill finansiera vissa Machine Learning resurser centralt som vem som helst kan använda i utforskningssyfte.
  • När ett Machine Learning användningsfall visar sig vara framgångsrikt i den undersökande miljön kan teamen begära resursgrupper. Till exempel kan Utveckling, QA och Prod för iterativt experimenteringsprojektarbete och åtkomst till produktionsdatakällor konfigureras.
  • 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 görs i en enda Azure-region.

För att uppfylla ovanstående krav har Contoso konfigurerat sina resurser på följande sätt:

  • Azure Machine Learning arbetsytor och resursgrupper är begränsade per projekt för att följa kraven för budgetering och användningsfallsfördelning.
  • 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 enskild resursgrupp och Machine Learning arbetsyta som är dedikerad för utforskning.
  • Azure Active Directory grupper som skiljer sig åt per användarroll och miljö, till exempel åtgärder som en dataexpert kan utföra i en produktionsmiljö skiljer sig från i utvecklingsmiljön, och åtkomstnivåerna kan skilja sig åt per lösning.
  • Alla resurser skapas i en enda Azure-region.

Contoso reference implementation

Nästa steg

Mer information om metodtips för Machine Learning DevOps med Azure Machine Learning finns i Guide för Machine learning DevOps.

Mer information om överväganden när du hanterar budgetar, kvoter och kostnader med Azure Machine Learning finns i Hantera budgetar, kostnader och kvoter för Azure Machine Learning i organisationsskala.