Organizzare e configurare gli ambienti di Azure Machine Learning

Quando si pianifica una distribuzione di Azure Machine Learning per un ambiente aziendale, esistono alcuni punti decisionali comuni che influiscono sulla modalità di creazione dell'area di lavoro:

• Struttura del team: il modo in cui si organizzano i team di data science e si collabora a progetti, casi d'uso e separazione dei dati o requisiti di gestione dei costi
• Ambienti: gli ambienti usati come parte del flusso di lavoro di sviluppo e rilascio per separare lo sviluppo dall'ambiente di produzione
• Area: la posizione dei dati e il gruppo di destinatari a cui è necessario gestire la soluzione di Machine Learning

Struttura del team e configurazione dell'area di lavoro

L'area di lavoro è la risorsa di primo livello in Azure Machine Learning. Archivia gli artefatti generati quando si lavora con Machine Learning e i puntatori e le risorse di calcolo gestite alle risorse associate e collegate. Dal punto di vista della gestibilità, l'area di lavoro come risorsa di Azure Resource Manager supporta il controllo degli accessi in base al ruolo di Azure, la gestione in base al ruolo di Criteri ed è possibile usarla come unità per la creazione di report sui costi.

Le organizzazioni in genere scelgono un modello o una combinazione dei modelli di soluzione seguenti per soddisfare i requisiti di gestibilità.

Area di lavoro per team: usare un'area di lavoro per ogni team quando tutti i membri di un team richiedono lo stesso livello di accesso ai dati e agli asset di sperimentazione. Ad esempio, un'organizzazione con tre team di Machine Learning potrebbe creare tre aree di lavoro, una per ogni team.

Il vantaggio dell'uso di un'area di lavoro per ogni team è che tutti gli artefatti di Machine Learning per i progetti del team vengono archiviati in un'unica posizione. È possibile visualizzare un aumento della produttività perché i membri del team possono accedere, esplorare e riutilizzare facilmente i risultati della sperimentazione. L'organizzazione delle aree di lavoro in base al team riduce il footprint di Azure e semplifica la gestione dei costi per team. Poiché il numero di asset di sperimentazione può crescere rapidamente, è possibile mantenere gli artefatti organizzati seguendo le convenzioni di denominazione e assegnazione di tag. Per consigli su come assegnare un nome alle risorse, vedere Sviluppare la strategia di denominazione e assegnazione di tag per le risorse di Azure.

Con questo approccio, ogni membro del team deve disporre di autorizzazioni simili a livello di accesso ai dati. Gli elenchi di controllo degli accessi in base al ruolo e gli elenchi di controllo di accesso (ACL) granulari per le origini dati e gli asset di sperimentazione sono limitati all'interno di un'area di lavoro. Non è possibile avere requisiti di separazione dei dati dei casi d'uso.

Area di lavoro per progetto: usare un'area di lavoro per ogni progetto se è necessaria la separazione dei dati e degli asset di sperimentazione per progetto o i requisiti di creazione dei costi e budget a livello di progetto. Ad esempio, si potrebbe avere un'organizzazione con quattro team di Machine Learning che eseguono tre progetti ciascuno per un totale di 12 istanze dell'area di lavoro.

Il vantaggio dell'uso di un'area di lavoro per ogni progetto è la gestione dei costi a livello di progetto. Un team crea in genere un gruppo di risorse dedicato per Azure Machine Learning e le risorse associate per motivi simili. Quando si lavora con collaboratori esterni, ad esempio, un'area di lavoro basata sul progetto semplifica la collaborazione su un progetto perché agli utenti esterni deve essere concesso solo l'accesso alle risorse del progetto, non alle risorse del team.

Qualcosa da considerare con questo approccio è l'isolamento dei risultati e delle risorse della sperimentazione. L'individuazione e il riutilizzo degli asset potrebbero essere più difficili perché gli asset vengono distribuiti in più istanze dell'area di lavoro.

Area di lavoro singola: usare un'area di lavoro non team o non correlata al progetto o quando i costi non possono essere associati direttamente a un'unità di fatturazione specifica, ad esempio con R&D.

Il vantaggio di questa configurazione è il costo dell'attività individuale non correlata al progetto che può essere separato dai costi correlati al progetto. Quando si configura una singola area di lavoro per consentire a tutti gli utenti di eseguire la propria attività individuale, si riduce il footprint di Azure.

Con questo approccio, l'area di lavoro potrebbe diventare disordinata rapidamente quando molti professionisti di Machine Learning condividono la stessa istanza. Gli utenti potrebbero richiedere un filtro basato sull'interfaccia utente degli asset per trovare le risorse in modo efficace. È possibile creare aree di lavoro di Machine Learning condivise per ogni divisione aziendale per attenuare i problemi di scalabilità o segmentare i budget.

Ambienti e configurazione dell'area di lavoro

Un ambiente è una raccolta di risorse che le distribuzioni indirizzano in base alla fase del ciclo di vita dell'applicazione. Esempi comuni di nomi di ambiente sono sviluppo, test, controllo di qualità, gestione temporanea e produzione.

Il processo di sviluppo nell'organizzazione influisce sui requisiti per l'utilizzo dell'ambiente. L'ambiente influisce sulla configurazione di Azure Machine Learning e sulle risorse associate, ad esempio il calcolo collegato. Ad esempio, la disponibilità dei dati potrebbe limitare la gestibilità della disponibilità di un'istanza di Machine Learning per ogni ambiente. I modelli di soluzione seguenti sono comuni:

Distribuzione di un'area di lavoro con ambiente singolo: quando si sceglie una singola distribuzione dell'area di lavoro dell'ambiente, Azure Machine Learning viene distribuito in un unico ambiente. Questa configurazione è comune per gli scenari incentrati sulla ricerca, in cui non è necessario rilasciare artefatti di Machine Learning in base alla fase del ciclo di vita, in ambienti diversi. Un altro scenario in cui questa configurazione ha senso è quando vengono distribuiti solo i servizi di inferenza e non le pipeline di Machine Learning tra ambienti.

I vantaggi di una configurazione incentrata sulla ricerca sono un footprint di Azure ridotto e un sovraccarico di gestione minimo. Questa modalità non implica la necessità di disporre di un'area di lavoro di Azure Machine Learning distribuita in ogni ambiente.

Con questo approccio, una singola distribuzione dell'ambiente è soggetta alla disponibilità dei dati. Quindi, prestare attenzione quando si configura l'archivio dati. Se si configura un accesso esteso, ad esempio l'accesso in scrittura nelle origini dati di produzione, è possibile che la qualità dei dati venga involontariamente danneggiata. Se si lavora in produzione nello stesso ambiente in cui si verifica lo sviluppo, si applicano le stesse restrizioni di controllo degli accessi in base al ruolo sia per il lavoro di sviluppo che per il lavoro di produzione. Questa configurazione potrebbe rendere entrambi gli ambienti troppo rigidi o troppo flessibili.

Distribuzione di più aree di lavoro dell'ambiente: quando si sceglie una distribuzione di più aree di lavoro dell'ambiente, un'istanza dell'area di lavoro viene distribuita per ogni ambiente. Uno scenario comune per questa configurazione è un'area di lavoro regolamentata con una netta separazione dei compiti tra gli ambienti e per gli utenti che dispongono dell'accesso alle risorse di tali ambienti.

I vantaggi di questa configurazione sono:

• Implementazione a fasi di flussi di lavoro e artefatti di Machine Learning. Ad esempio, i modelli in ambienti diversi, con il potenziale per migliorare l'agilità e ridurre il tempo di distribuzione.
• Sicurezza avanzata e controllo delle risorse perché è possibile assegnare più restrizioni di accesso negli ambienti downstream.
• Scenari di training sui dati di produzione in ambienti non di sviluppo perché è possibile concedere l'accesso a un gruppo selezionato di utenti.

Con questo approccio, si rischia una maggiore gestione e un sovraccarico dei processi. Questa configurazione richiede un processo di sviluppo e implementazione granulare per gli artefatti di Machine Learning tra le istanze dell'area di lavoro. Inoltre, il lavoro di progettazione e gestione dei dati potrebbe essere necessario per rendere disponibili i dati di produzione per il training nell'ambiente di sviluppo. Per la gestione degli accessi è necessario concedere a un team l'accesso per risolvere e analizzare gli eventi imprevisti nell'ambiente di produzione. Infine, il team necessita di competenze di progettazione di Azure DevOps e machine learning per implementare flussi di lavoro di automazione.

Un ambiente con accesso limitato ai dati, uno con accesso ai dati di produzione: quando si sceglie questa configurazione, Azure Machine Learning viene distribuito in due ambienti: uno con accesso limitato ai dati e uno con accesso ai dati di produzione. Questa configurazione è tipica nei casi in cui è necessario separare gli ambienti di sviluppo e produzione. Ad esempio, è possibile che si lavori in base a vincoli organizzativi per rendere disponibili i dati di produzione in qualsiasi ambiente o che si voglia separare l'attività di sviluppo da quella di produzione senza duplicare i dati più del necessario a causa dei costi di manutenzione elevati.

Il vantaggio di questa configurazione è la netta separazione dei compiti e dell'accesso tra ambienti di sviluppo e produzione. Un altro vantaggio è la riduzione del sovraccarico di gestione delle risorse rispetto a uno scenario di distribuzione multi-ambiente.

Con questo approccio è necessario un processo di sviluppo e implementazione definito per gli artefatti di Machine Learning tra aree di lavoro. Inoltre, potrebbe richiedere la gestione dei dati e l'impegno tecnico per rendere disponibili i dati di produzione per il training in un ambiente di sviluppo. Questo approccio potrebbe tuttavia richiedere un impegno relativamente inferiore rispetto alla distribuzione di un'area di lavoro multi-ambiente.

Configurazione di risorse e aree

La posizione di risorse, dati o utenti potrebbe richiedere la creazione di istanze dell'area di lavoro di Azure Machine Learning e delle risorse associate in più aree di Azure. Ad esempio, un progetto potrebbe estendere le proprie risorse nelle aree di Azure Europa occidentale e Stati Uniti orientali per motivi di prestazioni, costi e conformità. Gli scenari seguenti sono comuni:

Training a livello di area: i processi di training di Machine Learning vengono eseguiti nella stessa area di Azure in cui si trovano i dati. In questa configurazione, un'area di lavoro di Machine Learning viene distribuita in ogni area di Azure in cui si trovano i dati. Questo scenario è comune quando è necessario soddisfare la conformità o quando sono presenti vincoli di spostamento dei dati tra aree.

Il vantaggio di questa configurazione è la sperimentazione nel data center in cui si trovano i dati con la latenza di rete minima. Con questo approccio, quando una pipeline di Machine Learning viene eseguita in più istanze dell'area di lavoro, aggiunge una maggiore complessità di gestione. Risulta difficile confrontare i risultati della sperimentazione tra le istanze e il sovraccarico alla gestione delle quote e delle risorse di calcolo.

Se si vuole collegare l'archiviazione tra aree, ma si usa il calcolo da un'area, Azure Machine Learning supporta lo scenario di collegamento degli account di archiviazione in un'area geografica anziché nell'area di lavoro. I metadati, ad esempio le metriche, vengono archiviati nell'area dell'area di lavoro.

Servizio a livello di area: i servizi di Machine Learning distribuiscono vicino a dove risiede il pubblico di destinazione. Ad esempio, se gli utenti di destinazione si trovano in Australia e l'area di archiviazione e sperimentazione principale è Europa occidentale, distribuire l'area di lavoro di Machine Learning per la sperimentazione in Europa occidentale. Si distribuisce quindi un cluster del servizio Azure Kubernetes per la distribuzione di endpoint di inferenza in Australia.

I vantaggi di questa configurazione sono la possibilità di generare inferenze nel data center in cui vengono inseriti nuovi dati, riducendo al minimo la latenza e lo spostamento dei dati, e la conformità alle normative locali.

Con questo approccio, una configurazione in più aree offre diversi vantaggi, ma comporta anche un sovraccarico maggiore sulla gestione delle quote e del calcolo. Quando si ha un requisito per l'inferenza batch, la gestione a livello di area potrebbe richiedere una distribuzione in più aree di lavoro. I dati raccolti tramite endpoint di inferenza potrebbero dover essere trasferiti tra aree per gli scenari di ripetizione del training.

Ottimizzazione a livello di area: un modello di base esegue il training su un set di dati iniziale, ad esempio dati pubblici o dati di tutte le aree e viene successivamente ottimizzato con un set di dati a livello di area. Il set di dati a livello di area potrebbe esistere solo in una determinata area a causa di vincoli di conformità o spostamento dei dati. Ad esempio, potrebbe essere necessario eseguire il training del modello di base in un'area di lavoro nell'area A, mentre l'ottimizzazione avviene in un'area di lavoro nell'area B.

Il vantaggio di questa configurazione è che è possibile sperimentare in modo conforme nel data center in cui risiedono i dati. È anche possibile sfruttare i vantaggi del training del modello di base in un set di dati più grande in una fase precedente della pipeline.

Questo approccio supporta pipeline di sperimentazione complesse, ma potrebbe creare più sfide. Ad esempio, quando si confrontano i risultati dell'esperimento tra aree, potrebbe comportare un sovraccarico maggiore per la gestione delle quote e del calcolo.

Implementazione di riferimento

Per illustrare la distribuzione di Azure Machine Learning in un'impostazione più ampia, questa sezione illustra come l'organizzazione "Contoso" configura Azure Machine Learning, in base ai vincoli organizzativi, ai report e ai requisiti di budget:

• Contoso crea gruppi di risorse in base alla soluzione per motivi di gestione dei costi e creazione di report.
• Gli amministratori IT creano solo gruppi di risorse e risorse per le soluzioni in grado di soddisfare i requisiti di budget.
• A causa della natura esplorativa e incerta della data science, gli utenti hanno bisogno di un luogo in cui sperimentare e lavorare per l'esplorazione dei casi d'uso e dei dati. Spesso, il lavoro esplorativo non può essere direttamente associato a un caso d'uso specifico e può essere associato solo a un budget R&D. Contoso vuole finanziare alcune risorse di Machine Learning centralmente che chiunque può usare per scopi di esplorazione.
• Quando un caso d'uso di Machine Learning dimostra di avere successo nell'ambiente esplorativo, i team possono richiedere gruppi di risorse. Ad esempio, l'azienda può configurare sviluppo, controllo di qualità e produzione per il lavoro del progetto di sperimentazione iterativa e accedere alle origini dati di produzione.
• I requisiti di conformità e separazione dei dati non consentono l'esistenza di dati di produzione in tempo reale negli ambienti di sviluppo.
• Esistono diversi requisiti di controllo degli accessi in base al ruolo per vari gruppi di utenti in base ai criteri IT per ogni ambiente, ad esempio l'accesso è più restrittivo nell'ambiente di produzione.
• Tutti i dati, la sperimentazione e l'inferenza si verificano in una singola area di Azure.

Per rispettare i requisiti indicati sopra, Contoso configura le risorse nel modo seguente:

• Aree di lavoro di Azure Machine Learning e gruppi di risorse con ambito per ogni progetto per seguire i requisiti di separazione dei casi d'uso e budget.
• Una configurazione in più ambienti per Azure Machine Learning e le risorse associate per soddisfare i requisiti di gestione dei costi, controllo degli accessi in base al ruolo e accesso ai dati.
• Un singolo gruppo di risorse e un'area di lavoro di Machine Learning dedicata per l'esplorazione.
• Gruppi di Microsoft Entra diversi per ogni ruolo utente e ambiente. Ad esempio, le operazioni che un data scientist può eseguire in un ambiente di produzione sono diverse rispetto all'ambiente di sviluppo e i livelli di accesso possono differire per soluzione.
• Tutte le risorse create in una singola area di Azure.

Passaggi successivi

Informazioni sulle procedure consigliate in Machine Learning DevOps con Azure Machine Learning.

Guida DevOps per apprendimento automatico

Informazioni sulle considerazioni relative alla gestione di budget, quote e costi con Azure Machine Learning.

Gestire budget, costi e quota per Azure Machine Learning su scala aziendale