Apprendimento federato tra silos e dispositivi su Google Cloud

Last reviewed 2024-06-03 UTC

Questo documento descrive due architetture di riferimento che ti aiutano a creare una piattaforma di machine learning federato su Google Cloud utilizzando Google Kubernetes Engine (GKE). Le architetture di riferimento e le risorse associate descritte in questo documento supportano quanto segue:

  • Apprendimento federato tra silos
  • Apprendimento federato cross-device, basato sull'architettura cross-silo

Il pubblico di destinazione di questo documento è costituito da architetti cloud e ingegneri di AI e ML che vogliono implementare casi d'uso di apprendimento federato su Google Cloud. È inoltre rivolto ai responsabili delle decisioni che stanno valutando se implementare il learning federato su Google Cloud.

Architettura

I diagrammi in questa sezione mostrano un'architettura tra silos e un'architettura tra dispositivi per l'apprendimento federato. Per scoprire di più sulle diverse applicazioni per queste architetture, consulta la sezione Casi d'uso.

Architettura cross-silo

Il seguente diagramma mostra un'architettura che supporta l'apprendimento federato tra silos:

Architettura cross-silo, i cui componenti sono descritti nel testo che segue.

Il diagramma precedente mostra un esempio semplificato di un'architettura cross-silo. Nel diagramma, tutte le risorse si trovano nello stesso progetto di un'organizzazione Google Cloud. Queste risorse includono il modello client locale, il modello client globale e i relativi carichi di lavoro di apprendimento federato.

Questa architettura di riferimento può essere modificata per supportare diverse configurazioni per i silos di dati. I membri del consorzio possono ospitare i propri silos di dati nei seguenti modi:

  • Su Google Cloud, nella stessa organizzazione Google Cloud e nello stesso progetto Google Cloud.
  • In Google Cloud, nella stessa organizzazione Google Cloud, in diversi progetti Google Cloud.
  • Su Google Cloud, in organizzazioni Google Cloud diverse.
  • In ambienti privati on-premise o in altri cloud pubblici.

Per collaborare, i membri partecipanti devono stabilire canali di comunicazione sicuri tra i loro ambienti. Per saperne di più sul ruolo dei membri partecipanti nell'iniziativa di apprendimento federato, su come collaborano e su cosa condividono tra loro, consulta la sezione Casi d'uso.

L'architettura include i seguenti componenti:

  • Una rete Virtual Private Cloud (VPC) e una subnet.
  • Un cluster GKE privato che ti consente di svolgere le seguenti operazioni:
    • Isola i nodi del cluster da internet.
    • Limita l'esposizione a internet dei nodi e del piano di controllo del cluster creando un cluster GKE privato con reti autorizzate.
    • Utilizza nodi di cluster protetti che utilizzano un'immagine del sistema operativo protetta.
    • Abilita Dataplane V2 per il networking Kubernetes ottimizzato.
  • Pool di nodi GKE dedicati: crei un pool di nodi dedicato per ospitare esclusivamente le app e le risorse del tenant. I nodi hanno degli elementi dannosi per garantire che solo i carichi di lavoro del tenant vengano pianificati sui nodi del tenant. Le altre risorse del cluster sono ospitate nel pool di nodi principale.

  • Crittografia dei dati (abilitata per impostazione predefinita):

  • Crittografia dei dati in uso, attivando facoltativamente i nodi Google Kubernetes Engine riservati.

  • Regole firewall VPC che applicano quanto segue:

    • Regole di riferimento che si applicano a tutti i nodi del cluster.
    • Regole aggiuntive che si applicano solo ai nodi nel pool di nodi del tenant. Queste regole firewall limitano l'accesso in entrata e in uscita ai nodi del tenant.

  • Cloud NAT per consentire il traffico in uscita verso internet.

  • Record Cloud DNS per attivare l'accesso privato Google in modo che le app all'interno del cluster possano accedere alle API di Google senza passare per internet.

  • Account di servizio che sono i seguenti:

    • Un account di servizio dedicato per i nodi del pool di nodi del tenant.
    • Un account di servizio dedicato per le app del tenant da utilizzare con la federazione delle identità per i carichi di lavoro.

  • Supporto per l'utilizzo di Google Gruppi per controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes.

  • Un repository Git per archiviare i descrittori di configurazione.

  • Un repository Artifact Registry per archiviare le immagini container.

  • Config Sync e Policy Controller per eseguire il deployment della configurazione e dei criteri.

  • Gateway Cloud Service Mesh per consentire in modo selettivo il traffico in entrata e in uscita del cluster.

  • Bucket Cloud Storage per archiviare i pesi dei modelli globali e locali.

  • Accesso ad altre API Google e Google Cloud. Ad esempio, un workload di addestramento potrebbe dover accedere ai dati di addestramento archiviati in Cloud Storage, BigQuery o Cloud SQL.

Architettura cross-device

Il seguente diagramma mostra un'architettura che supporta l'apprendimento federato cross-device:

Architettura cross-device, i cui componenti sono descritti nel testo che segue.

L'architettura cross-device precedente si basa sull'architettura cross-silo con l'aggiunta dei seguenti componenti:

  • Un servizio Cloud Run che simula i dispositivi che si connettono al server
  • Un Certificate Authority Service che crea certificati privati per l'esecuzione del server e dei client
  • Un Vertex AI TensorBoard per visualizzare il risultato dell'addestramento
  • Un bucket Cloud Storage per archiviare il modello consolidato
  • Il cluster GKE privato che utilizza nodi riservati come pool principale per contribuire a proteggere i dati in uso

L'architettura cross-device utilizza componenti del progetto open source Federated Compute Platform (FCP). Questo progetto include quanto segue:

  • Codice client per la comunicazione con un server ed esecuzione di attività sui dispositivi
  • Un protocollo per la comunicazione client-server
  • Punti di connessione con TensorFlow Federated per semplificare la definizione dei calcoli federati

I componenti FCP mostrati nel diagramma precedente possono essere implementati come un insieme di microservizi. Questi componenti svolgono le seguenti attività:

  • Aggregatore: questo job legge i gradienti del dispositivo e calcola il risultato aggregato con la privacy differenziale.
  • Collector: questo job viene eseguito periodicamente per eseguire query sulle attività attive e su gradienti criptati. Queste informazioni determinano quando inizia l'aggregazione.
  • Model uploader: questo job ascolta gli eventi e pubblica i risultati in modo che i dispositivi possano scaricare i modelli aggiornati.
  • Assegnazione di attività: questo servizio frontend distribuisce le attività di addestramento ai dispositivi.
  • Gestione delle attività: questo job gestisce le attività.
  • Task Scheduler: questo job viene eseguito periodicamente o viene attivato da eventi specifici.

Prodotti utilizzati

Le architetture di riferimento per entrambi i casi d'uso dell'apprendimento federato utilizzano i seguenti componenti Google Cloud:

GKE fornisce inoltre le seguenti funzionalità alla tua piattaforma di machine learning federata:

  • Hosting del coordinatore dell'apprendimento federato: il coordinatore dell'apprendimento federato è responsabile della gestione del processo di apprendimento federato. Questa gestione include attività come la distribuzione del modello globale ai partecipanti, l'aggregazione degli aggiornamenti dei partecipanti e l'aggiornamento del modello globale. GKE può essere utilizzato per ospitare il coordinatore dell'apprendimento federato in modo altamente disponibile e scalabile.
  • Organizzazione di un'attività ospitante per i partecipanti all'apprendimento federato: i partecipanti all'apprendimento federato sono responsabili dell'addestramento del modello globale sui propri dati locali. GKE può essere utilizzato per ospitare i partecipanti all'apprendimento federato in modo sicuro e isolato. Questo approccio può contribuire ad assicurare che i dati dei partecipanti vengano conservati localmente.
  • Fornire un canale di comunicazione sicuro e scalabile: i partecipanti all'apprendimento federato devono essere in grado di comunicare con il coordinatore dell'apprendimento federato in modo sicuro e scalabile. GKE può essere utilizzato per fornire un canale di comunicazione sicuro e scalabile tra i partecipanti e il coordinatore.
  • Gestione del ciclo di vita dei deployment di apprendimento federato: GKE può essere utilizzato per gestire il ciclo di vita dei deployment di apprendimento federato. Questa gestione include attività come il provisioning delle risorse, il deployment della piattaforma di machine learning federato e il monitoraggio delle prestazioni della piattaforma di machine learning federato.

Oltre a questi vantaggi, GKE offre anche una serie di funzionalità che possono essere utili per gli implementazioni di apprendimento federato, ad esempio:

  • Cluster regionali: GKE ti consente di creare cluster regionali, aiutandoti a migliorare le prestazioni dei deployment di apprendimento federato riducendo la latenza tra i partecipanti e il coordinatore.
  • Norme di rete: GKE ti consente di creare norme di rete, contribuendo a migliorare la sicurezza degli implementazioni di apprendimento federato controllando il flusso di traffico tra i partecipanti e il coordinatore.
  • Bilanciamento del carico: GKE offre una serie di opzioni di bilanciamento del carico, contribuendo a migliorare la scalabilità dei deployment dell'apprendimento federato distribuendo il traffico tra i partecipanti e il coordinatore.

TFF fornisce le seguenti funzionalità per facilitare l'implementazione di casi d'uso di apprendimento federato:

  • La possibilità di esprimere in modo dichiarativo i calcoli federati, che sono un insieme di passaggi di elaborazione eseguiti su un server e un insieme di client. Queste operazioni possono essere implementate in diversi ambienti di runtime.
  • È possibile creare aggregatori personalizzati utilizzando TFF open source.
  • Supporto di una serie di algoritmi di apprendimento federato, tra cui i seguenti:
    • Media federata:un algoritmo che calcola la media dei parametri del modello dei clienti partecipanti. È particolarmente adatto per i casi d'uso in cui i dati sono relativamente omogenei e il modello non è troppo complesso. I casi d'uso tipici sono:
      • Consigli personalizzati: un'azienda può utilizzare la media federata per addestrare un modello che consiglia i prodotti agli utenti in base alla loro cronologia acquisti.
      • Rilevamento di attività fraudolente: un consorzio di banche può utilizzare la media federata per addestrare un modello che rileva le transazioni fraudolente.
      • Diagnosi medica: un gruppo di ospedali può utilizzare la media federata per addestrare un modello che diagnostica il cancro.
    • Discesa stocastica federata del gradiente (FedSGD): un algoritmo che utilizza la discesa stocastica del gradiente per aggiornare i parametri del modello. È adatto per i casi d'uso in cui i dati sono eterogenei e il modello è complesso. I casi d'uso tipici sono i seguenti:
      • Elaborazione del linguaggio naturale: un'azienda può utilizzare FedSGD per addestrare un modello che migliora l'accuratezza del riconoscimento vocale.
      • Riconoscimento delle immagini: un'azienda può utilizzare FedSGD per addestrare un modello in grado di identificare gli oggetti nelle immagini.
      • Manutenzione predittiva: un'azienda può utilizzare FedSGD per addestrare un modello che prevede quando è probabile che una macchina si guasti.
    • Adam federato: un algoritmo che utilizza l'ottimizzatore Adam per aggiornare i parametri del modello. I casi d'uso tipici sono i seguenti:
      • Sistemi di consigli: un'azienda può utilizzare Adam federato per addestrare un modello che consiglia prodotti agli utenti in base alla loro cronologia acquisti.
      • Classificazione: un'azienda può utilizzare Adam federato per addestrare un modello che classifica i risultati di ricerca.
      • Previsione della percentuale di clic: un'azienda può utilizzare Adam federato per addestrare un modello che preveda la probabilità che un utente faccia clic su un annuncio.

Casi d'uso

Questa sezione descrive i casi d'uso per i quali le architetture tra silos e tra dispositivi sono scelte appropriate per la tua piattaforma di apprendimento federato.

L'apprendimento federato è un'impostazione di machine learning in cui molti clienti addestrano un modello in collaborazione. Questo processo è guidato da un coordinatore centrale e i dati di addestramento rimangono decentralizzati.

Nel paradigma di apprendimento federato, i client scaricano un modello globale e lo migliorano addestrandolo localmente sui propri dati. Poi, ogni client invia nuovamente gli aggiornamenti del modello calcolati al server centrale, dove vengono aggregati e viene generata una nuova iterazione del modello globale. In queste architetture di riferimento, i carichi di lavoro di addestramento dei modelli vengono eseguiti su GKE.

L'apprendimento federato incarna il principio di privacy della minimizzazione dei dati, limitando i dati raccolti in ogni fase del calcolo, limita l'accesso ai dati e li elabora per poi ignorarli il prima possibile. Inoltre, l'impostazione del problema dell'apprendimento federato è compatibile con altre tecniche di tutela della privacy, come l'utilizzo della privacy differenziale (DP) per migliorare l'anonimizzazione del modello al fine di garantire che il modello finale non memorizzi i dati dei singoli utenti.

A seconda del caso d'uso, l'addestramento dei modelli con l'apprendimento federato può avere vantaggi aggiuntivi:

  • Conformità: in alcuni casi, le normative potrebbero limitare le modalità di utilizzo o condivisione dei dati. L'apprendimento federato potrebbe essere utilizzato per rispettare queste normative.
  • Efficienza della comunicazione: in alcuni casi, è più efficiente addestrare un modello su dati distribuiti rispetto a centralizzarli. Ad esempio, i set di dati su cui deve essere addestrato il modello sono troppo grandi per essere spostati in un'unica posizione.
  • Accessibilità dei dati: l'apprendimento federato consente alle organizzazioni di mantenere i dati di addestramento decentralizzati in silos di dati per utente o per organizzazione.
  • Maggiore accuratezza del modello: l'addestramento sui dati utente reali (garantendo al contempo la privacy) anziché su dati sintetici (a volte indicati come dati proxy) spesso comporta una maggiore accuratezza del modello.

Esistono diversi tipi di apprendimento federato, che si distinguono in base alla provenienza dei dati e al luogo in cui vengono eseguiti i calcoli locali. Le architetture descritte in questo documento si concentrano su due tipi di apprendimento federato: cross-silo e cross-device. Altri tipi di apprendimento federato non rientrano nell'ambito di questo documento.

L'apprendimento federato è ulteriormente classificato in base alla modalità di partizione dei set di dati, che può essere la seguente:

  • Apprendimento federato orizzontale (HFL): set di dati con le stesse caratteristiche (colonne), ma campioni (righe) diversi. Ad esempio, più ospedali potrebbero avere cartelle dei pazienti con gli stessi parametri medici, ma popolazioni di pazienti diverse.
  • Apprendimento federato verticale (VFL): set di dati con gli stessi esempi (righe) ma caratteristiche diverse (colonne). Ad esempio, una banca e un'azienda di e-commerce potrebbero avere dati dei clienti con persone sovrapposte, ma informazioni finanziarie e di acquisto diverse.
  • Apprendimento trasferito federato (FTL): sovrapposizione parziale sia dei campioni sia delle funzionalità tra i set di dati. Ad esempio, due ospedali potrebbero avere record dei pazienti con alcune persone sovrapposte e alcuni parametri medici condivisi, ma anche funzionalità uniche in ogni set di dati.

Il calcolo federato tra silos si verifica quando i membri partecipanti sono organizzazioni o aziende. In pratica, il numero di membri è solitamente ridotto (ad esempio, non supera i cento membri). Il calcolo tra silo viene solitamente utilizzato in scenari in cui le organizzazioni partecipanti hanno set di dati diversi, ma vogliono addestrare un modello condiviso o analizzare risultati aggregati senza condividere i dati non elaborati tra di loro. Ad esempio, i membri partecipanti possono avere i propri ambienti in organizzazioni Google Cloud diverse, ad esempio quando rappresentano persone giuridiche diverse, o nella stessa organizzazione Google Cloud, ad esempio quando rappresentano reparti diversi della stessa persona giuridica.

I membri partecipanti potrebbero non essere in grado di considerare i carichi di lavoro reciproci come entità attendibili. Ad esempio, un membro partecipante potrebbe non avere accesso al codice sorgente di un carico di lavoro di addestramento che riceve da terze parti, come il coordinatore. Poiché non può accedere a questo codice sorgente, il membro partecipante non può garantire che il carico di lavoro sia completamente attendibile.

Per aiutarti a impedire a un carico di lavoro non attendibile di accedere ai tuoi dati o alle tue risorse senza autorizzazione, ti consigliamo di procedere nel seguente modo:

  • Esegui il deployment di carichi di lavoro non attendibili in un ambiente isolato.
  • Concedi ai carichi di lavoro non attendibili solo i diritti di accesso e le autorizzazioni strettamente necessari per completare i round di addestramento assegnati al carico di lavoro.

Per aiutarti a isolare i workload potenzialmente non attendibili, queste architetture di riferimento implementano controlli di sicurezza, come la configurazione di spazi dei nomi Kubernetes isolati, in cui ogni spazio dei nomi ha un pool di nodi GKE dedicato. La comunicazione tra spazi dei nomi e il traffico in entrata e in uscita del cluster sono vietati per impostazione predefinita, a meno che non li ovveri esplicitamente.

Di seguito sono riportati alcuni casi d'uso di esempio per l'apprendimento federato tra silos:

  • Rilevamento delle frodi: l'apprendimento federato può essere utilizzato per addestrare un modello di rilevamento delle frodi su dati distribuiti in più organizzazioni. Ad esempio, un consorzio di banche potrebbe utilizzare l'apprendimento federato per addestrare un modello che rileva le transazioni fraudolente.
  • Diagnosi medica: l'apprendimento federato può essere utilizzato per addestrare un modello di diagnosi medica su dati distribuiti su più ospedali. Ad esempio, un gruppo di ospedali potrebbe utilizzare l'apprendimento federato per addestrare un modello che diagnostica il cancro.

L'apprendimento federato cross-device è un tipo di calcolo federato in cui i membri partecipanti sono dispositivi di utenti finali come cellulari, veicoli o dispositivi IoT. Il numero di abbonati può raggiungere una scala di milioni o addirittura decine di milioni.

Il processo di apprendimento federato cross-device è simile a quello dell'apprendimento federato cross-silo. Tuttavia, richiede anche di adattare l'architettura di riferimento per tenere conto di alcuni fattori aggiuntivi che devi considerare quando hai a che fare con migliaia o milioni di dispositivi. Devi implementare i carichi di lavoro amministrativi per gestire gli scenari riscontrati nei casi d'uso dell'apprendimento federato cross-device. Ad esempio, la necessità di coordinare un sottoinsieme di clienti che parteciperanno al ciclo di formazione. L'architettura cross-device offre questa possibilità consentendoti di eseguire il deployment dei servizi FCP. Questi servizi hanno carichi di lavoro con punti di connessione con TFF. TFF viene utilizzato per scrivere il codice che gestisce questa coordinazione.

Di seguito sono riportati alcuni casi d'uso di esempio per l'apprendimento federato cross-device:

  • Consigli personalizzati: puoi utilizzare il cross-device federated learning per addestrare un modello di consigli personalizzati sui dati distribuiti su più dispositivi. Ad esempio, un'azienda potrebbe utilizzare l'apprendimento federato per addestrare un modello che consiglia prodotti agli utenti in base alla loro cronologia acquisti.
  • Elaborazione del linguaggio naturale: l'apprendimento federato può essere utilizzato per addestrare un modello di elaborazione del linguaggio naturale su dati distribuiti su più dispositivi. Ad esempio, un'azienda potrebbe utilizzare l'apprendimento federato per formare un modello che migliori l'accuratezza del riconoscimento vocale.
  • Prevedendo le esigenze di manutenzione del veicolo: l'apprendimento federato può essere utilizzato per addestrare un modello che preveda quando è probabile che un veicolo abbia bisogno di manutenzione. Questo modello potrebbe essere addestrato con i dati raccolti da più veicoli. Questo approccio consente al modello di apprendere dalle esperienze di tutti i veicoli, senza compromettere la privacy di nessun singolo veicolo.

La tabella seguente riassume le funzionalità delle architetture cross-silo e cross-device e mostra come classificare il tipo di scenario di apprendimento federato applicabile al tuo caso d'uso.

Funzionalità Calcoli federati tra silos Calcoli federati cross-device
Dimensioni della popolazione In genere di piccole dimensioni (ad esempio, meno di cento dispositivi) Scalabile fino a migliaia, milioni o centinaia di milioni di dispositivi
Membri partecipanti Organizzazioni o aziende Dispositivi mobili, dispositivi edge, veicoli
Partizione dei dati più comune HFL, VFL, FTL HFL
Sensibilità dei dati Dati sensibili che i partecipanti non vogliono condividere tra loro in formato non elaborato Dati troppo sensibili per essere condivisi con un server centrale
Disponibilità dei dati I partecipanti sono quasi sempre disponibili In qualsiasi momento è disponibile solo una parte dei partecipanti
Esempi di casi d'uso Rilevamento di attività fraudolente, diagnosi mediche, previsioni finanziarie Monitoraggio dell'attività fisica, riconoscimento vocale, classificazione delle immagini

Note sul layout

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per sviluppare una o più architetture che soddisfino i tuoi requisiti specifici di sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Considerazioni sulla progettazione dell'architettura tra silos

Per implementare un'architettura di apprendimento federato tra silos in Google Cloud, devi implementare i seguenti prerequisiti minimi, illustrati in modo più dettagliato nelle sezioni seguenti:

  1. Stabilire un consorzio di apprendimento federato.
  2. Determina il modello di collaborazione da implementare per il consorzio di apprendimento federato.
  3. Determina le responsabilità delle organizzazioni partecipanti.

Oltre a questi prerequisiti, il proprietario della federazione deve eseguire altre azioni che non rientrano nell'ambito di questo documento, ad esempio:

  • Gestire il consorzio di apprendimento federato.
  • Progettare e implementare un modello di collaborazione.
  • Prepara, gestisci e utilizza i dati di addestramento del modello e il modello che il proprietario della federazione intende addestrare.
  • Crea, esegui il containerizzazione e orchestra i flussi di lavoro di apprendimento federato.
  • Esegui il deployment e gestisci i carichi di lavoro di apprendimento federato.
  • Configura i canali di comunicazione per consentire alle organizzazioni partecipanti di trasferire i dati in modo sicuro.

Creare un consorzio di apprendimento federato

Un consorzio di apprendimento federato è il gruppo di organizzazioni che partecipano a un progetto di apprendimento federato tra silos. Le organizzazioni del consorzio condividono solo i parametri dei modelli di ML e puoi criptarli per aumentare la privacy. Se il consorzio di apprendimento federato lo consente, le organizzazioni possono anche aggregare i dati che non contengono informazioni che consentono l'identificazione personale (PII).

Determina un modello di collaborazione per il consorzio di apprendimento federato

Il consorzio di apprendimento federato può implementare diversi modelli di collaborazione, come i seguenti:

  • Un modello centralizzato costituito da un'unica organizzazione di coordinamento, chiamata proprietario della federazione o orchestratore, e da un insieme di organizzazioni partecipanti o proprietari di dati.
  • Un modello decentralizzato costituito da organizzazioni che si coordinano come gruppo.
  • Un modello eterogeneo costituito da un consorzio di diverse organizzazioni partecipanti, che apportano tutte risorse diverse al consorzio.

In questo documento si presuppone che il modello di collaborazione sia centralizzato.

Determinare le responsabilità delle organizzazioni partecipanti

Dopo aver scelto un modello di collaborazione per il consorzio di apprendimento federato, il proprietario della federazione deve determinare le responsabilità delle organizzazioni partecipanti.

Quando inizia a creare un consorzio di apprendimento federato, il proprietario della federazione deve anche:

  • Coordinare l'impegno per l'apprendimento federato.
  • Progettare e implementare il modello ML globale e i modelli ML da condividere con le organizzazioni partecipanti.
  • Definisci i round di apprendimento federato, ovvero l'approccio per l'iterazione del processo di addestramento dell'ML.
  • Seleziona le organizzazioni partecipanti che contribuiscono a un determinato ciclo di apprendimento federato. Questa selezione è chiamata coorte.
  • Progettare e implementare una procedura di verifica dell'appartenenza al consorzio per le organizzazioni partecipanti.
  • Aggiorna il modello ML globale e i modelli ML da condividere con le organizzazioni partecipanti.
  • Fornire alle organizzazioni partecipanti gli strumenti per verificare che il consorzio di apprendimento federato soddisfi i loro requisiti di privacy, sicurezza e normativi.
  • Fornire alle organizzazioni partecipanti canali di comunicazione sicuri e criptati.
  • Fornire alle organizzazioni partecipanti tutti i dati aggregati non riservati necessari per completare ogni ciclo di apprendimento federato.

Le organizzazioni partecipanti hanno le seguenti responsabilità:

  • Fornisci e gestisci un ambiente sicuro e isolato (un silo). Il silo è il luogo in cui le organizzazioni partecipanti archiviano i propri dati e in cui viene implementato l'addestramento dei modelli di ML. Le organizzazioni partecipanti non condividono i propri dati con altre organizzazioni.
  • Addestra i modelli forniti dal proprietario della federazione utilizzando la propria infrastruttura di calcolo e i propri dati locali.
  • Condividi i risultati dell'addestramento del modello con il proprietario della federazione sotto forma di dati aggregati, dopo aver rimosso le PII.

Il proprietario della federazione e le organizzazioni partecipanti possono utilizzare Cloud Storage per condividere modelli e risultati di addestramento aggiornati.

Il proprietario della federazione e le organizzazioni partecipanti perfezionano l'addestramento del modello di ML finché il modello non soddisfa i loro requisiti.

Implementare l'apprendimento federato su Google Cloud

Dopo aver costituito il consorzio per l'apprendimento federato e aver stabilito le modalità di collaborazione, consigliamo alle organizzazioni partecipanti di:

  1. Esegui il provisioning e configura l'infrastruttura necessaria per il consorzio di apprendimento federato.
  2. Implementa il modello di collaborazione.
  3. Avvia l'iniziativa di apprendimento federato.

Esegui il provisioning e la configurazione dell'infrastruttura per il consorzio di apprendimento federato

Durante il provisioning e la configurazione dell'infrastruttura per il consorzio di apprendimento federato, è responsabilità del proprietario della federazione creare e distribuire i carichi di lavoro che addestrano i modelli ML federati alle organizzazioni partecipanti. Poiché una terza parte (il proprietario della federazione) ha creato e fornito i carichi di lavoro, le organizzazioni partecipanti devono adottare precauzioni durante il loro dispiegamento negli ambienti di runtime.

Le organizzazioni partecipanti devono configurare i propri ambienti in base alle proprie best practice di sicurezza individuali e applicare controlli che limitano l'ambito e le autorizzazioni concesse a ciascun workload. Oltre a seguire le proprie singole best practice per la sicurezza, consigliamo al proprietario della federazione e alle organizzazioni partecipanti di prendere in considerazione i vettori di minaccia specifici per l'apprendimento federato.

Implementare il modello di collaborazione

Dopo aver preparato l'infrastruttura del consorzio di apprendimento federato, il proprietario della federazione progetta e implementa i meccanismi che consentono alle organizzazioni partecipanti di interagire tra loro. L'approccio segue il modello di collaborazione scelto dal proprietario della federazione per il consorzio di apprendimento federato.

Avvia l'iniziativa di apprendimento federato

Dopo aver implementato il modello di collaborazione, il proprietario della federazione implementa il modello di ML globale da addestrare e i modelli di ML da condividere con l'organizzazione partecipante. Una volta pronti, il proprietario della federazione avvia il primo round dell'iniziativa di apprendimento federato.

Durante ogni ciclo dell'iniziativa di apprendimento federato, il proprietario della federazione svolge quanto segue:

  1. Distribuisce i modelli ML da condividere con le organizzazioni partecipanti.
  2. Attende che le organizzazioni partecipanti forniscano i risultati dell'addestramento dei modelli di ML condivisi dal proprietario della federazione.
  3. Raccoglie ed elabora i risultati della formazione prodotti dalle organizzazioni partecipanti.
  4. Aggiorna il modello ML globale quando riceve risultati di addestramento appropriati dalle organizzazioni partecipanti.
  5. Aggiorna i modelli ML da condividere con gli altri membri del consorzio, se applicabile.
  6. Prepara i dati di addestramento per il prossimo ciclo di apprendimento federato.
  7. Inizia il prossimo round di apprendimento federato.

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una piattaforma di machine learning federata su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

I carichi di lavoro di apprendimento federato che esegui nei tuoi ambienti potrebbero esporre te, i tuoi dati, i tuoi modelli di apprendimento federato e la tua infrastruttura a minacce che potrebbero influire sulla tua attività.

Per aiutarti ad aumentare la sicurezza dei tuoi ambienti di apprendimento federati, queste architetture di riferimento configurano i controlli di sicurezza di GKE incentrati sull'infrastruttura dei tuoi ambienti. Questi controlli potrebbero non essere sufficienti per proteggerti dalle minacce specifiche per i tuoi carichi di lavoro e casi d'uso di apprendimento federato. Data la specificità di ogni carico di lavoro e caso d'uso di apprendimento federato, i controlli di sicurezza volti a proteggere l'implementazione dell'apprendimento federato non rientrano nell'ambito di questo documento. Per ulteriori informazioni ed esempi su queste minacce, consulta Considerazioni sulla sicurezza del Federated Learning.

Controlli di sicurezza di GKE

Questa sezione illustra i controlli che puoi applicare con queste architetture per aiutarti a proteggere il tuo cluster GKE.

Sicurezza avanzata dei cluster GKE

Queste architetture di riferimento ti aiutano a creare un cluster GKE che implementa le seguenti impostazioni di sicurezza:

Per ulteriori informazioni sulle impostazioni di sicurezza di GKE, consulta Aumentare la sicurezza del cluster e Informazioni sulla dashboard della postura di sicurezza.

Regole firewall VPC

Le regole firewall VPC (Virtual Private Cloud) regolano il traffico consentito verso o da VM Compute Engine. Le regole ti consentono di filtrare il traffico a livello di granularità della VM, in base agli attributi del livello 4.

Creazione di un cluster GKE con le regole firewall predefinite del cluster GKE. Queste regole firewall consentono la comunicazione tra i nodi del cluster e il piano di controllo GKE, nonché tra i nodi e i pod nel cluster.

Applicano regole firewall aggiuntive ai nodi del pool di nodi del tenant. Queste regole firewall limitano il traffico in uscita dai nodi del tenant. Questo approccio può aumentare l'isolamento dei nodi tenant. Per impostazione predefinita, tutto il traffico in uscita dai node del tenant viene negato. Eventuali uscite richieste devono essere configurate esplicitamente. Ad esempio, puoi creare regole firewall per consentire il traffico in uscita dai nodi del tenant al piano di controllo GKE e alle API Google utilizzando Private Google Access. Le regole firewall hanno come target i nodi del tenant utilizzando l'account di servizio per il pool di nodi del tenant.

Spazi dei nomi

Gli spazi dei nomi ti consentono di fornire un ambito per le risorse correlate all'interno di un cluster, ad esempio pod, servizi e controller di replica. Utilizzando gli spazi dei nomi, puoi delegare la responsabilità di amministrazione delle risorse correlate come un'unità. Pertanto, gli spazi dei nomi sono parte integrante della maggior parte dei pattern di sicurezza.

Gli spazi dei nomi sono una funzionalità importante per l'isolamento del piano di controllo. Tuttavia, non forniscono isolamento dei nodi, isolamento del piano dati o isolamento della rete.

Un approccio comune è creare spazi dei nomi per le singole applicazioni. Ad esempio, potresti creare lo spazio dei nomi myapp-frontend per il componente dell'interfaccia utente di un'applicazione.

Queste architetture di riferimento ti aiutano a creare uno spazio dei nomi dedicato per ospitare le app di terze parti. Lo spazio dei nomi e le relative risorse vengono trattati come un tenant all'interno del tuo cluster. Applicano criteri e controlli allo spazio dei nomi per limitare l'ambito delle risorse al suo interno.

Criteri di rete

I criteri di rete applicano i flussi di traffico di rete di livello 4 utilizzando regole firewall a livello di pod. I criteri di rete sono limitati a uno spazio dei nomi.

Nelle architetture di riferimento descritte in questo documento, applichi le norme di rete allo spazio dei nomi del tenant che ospita le app di terze parti. Per impostazione predefinita, il criterio di rete nega tutto il traffico verso e da i pod nello spazio dei nomi. Qualsiasi trafico richiesto deve essere aggiunto esplicitamente a una lista consentita. Ad esempio, i criteri di rete in queste architetture di riferimento consentono esplicitamente il traffico verso i servizi del cluster richiesti, come il DNS interno del cluster e il piano di controllo di Cloud Service Mesh.

Config Sync

Config Sync mantiene sincronizzati i cluster GKE con le configurazioni archiviate in un repository Git. Il repository Git funge da unica fonte attendibile per la configurazione e i criteri del cluster. Config Sync è dichiarativo. Controlla continuamente lo stato del cluster e applica lo stato dichiarato nel file di configurazione per applicare i criteri, il che contribuisce a evitare la deriva della configurazione.

Installa Config Sync nel tuo cluster GKE. Configura Config Sync per sincronizzare le configurazioni e i criteri dei cluster da un repository Cloud Source. Le risorse sincronizzate includono:

  • Configurazione di Cloud Service Mesh a livello di cluster
  • Criteri di sicurezza a livello di cluster
  • Configurazione e criteri a livello di spazio dei nomi del tenant, inclusi criteri di rete, account di servizio, regole RBAC e configurazione di Cloud Service Mesh

Policy Controller

Il controller dei criteri della versione Enterprise di Google Kubernetes Engine (GKE) è un controller di ammissione dinamico per Kubernetes che applica i criteri basati su CustomResourceDefinition (CRD) eseguiti da Open Policy Agent (OPA).

I controller di ammissione sono plug-in Kubernetes che intercettano le richieste al server dell'API Kubernetes prima che un oggetto venga reso persistente, ma dopo che la richiesta è stata autenticata e autorizzata. Puoi utilizzare i controller di ammissione per limitare il modo in cui viene utilizzato un cluster.

Installa Policy Controller nel tuo cluster GKE. Queste architetture di riferimento includono criteri di esempio per aiutarti a proteggere il tuo cluster. Applicchi automaticamente i criteri al cluster utilizzando Config Sync. Applichi i seguenti criteri:

Cloud Service Mesh

Cloud Service Mesh è un mesh di servizi che ti aiuta a semplificare la gestione delle comunicazioni sicure tra i servizi. Queste architetture di riferimento configurano Cloud Service Mesh in modo che:

  • Inserisce automaticamente i proxy sidecar.
  • Applica la comunicazione mTLS tra i servizi nel mesh.
  • Limita il traffico mesh in uscita solo agli host noti.
  • Limita il traffico in entrata solo da determinati client.
  • Ti consente di configurare i criteri di sicurezza di rete in base all'identità del servizio piuttosto che in base all'indirizzo IP dei peer sulla rete.
  • Limita la comunicazione autorizzata tra i servizi nel mesh. Ad esempio, le app nello spazio dei nomi del tenant possono comunicare solo con le app nello stesso spazio dei nomi o con un insieme di host esterni noti.
  • Instrada tutto il traffico in entrata e in uscita tramite gateway mesh dove puoi applicare ulteriori controlli del traffico.
  • Supporta la comunicazione sicura tra i cluster.

Incompatibilità e affinità dei nodi

I contaminanti dei nodi e l'affinità dei nodi sono meccanismi Kubernetes che ti consentono di influenzare la pianificazione dei pod sui nodi del cluster.

I nodi con incompatibilità respingono i pod. Kubernetes non pianifica un pod su un nodo con incompatibilità a meno che il pod non abbia una tolleranza per l'incompatibilità. Puoi utilizzare le incompatibilità dei nodi per prenotare i nodi per l'utilizzo solo da parte di determinati carichi di lavoro o tenant. I taint e le tolleranze vengono spesso utilizzati nei cluster multi-tenant. Per ulteriori informazioni, consulta la documentazione relativa ai nodi dedicati con impurità e tolleranze.

L'affinità nodo ti consente di limitare i pod a nodi con etichette specifiche. Se un pod ha un requisito di affinità del nodo, Kubernetes non lo pianifica su un nodo a meno che il nodo non abbia un'etichetta che corrisponda al requisito di affinità. Puoi utilizzare l'affinità dei nodi per assicurarti che i pod vengano pianificati sui nodi appropriati.

Puoi utilizzare le incompatibilità dei nodi e l'affinità dei nodi insieme per garantire che i pod di carichi di lavoro del tenant vengano pianificati esclusivamente sui nodi riservati al tenant.

Queste architetture di riferimento ti consentono di controllare la pianificazione delle app del tenant nei seguenti modi:

  • Creazione di un pool di nodi GKE dedicato al tenant. Ogni nodo del pool ha un'alterazione correlata al nome del tenant.
  • Applicazione automatica della tolleranza e dell'affinità dei nodi appropriata a qualsiasi pod che ha come target lo spazio dei nomi del tenant. Applica la tolleranza e l'affinità utilizzando le mutazioni di PolicyController.

Principio del privilegio minimo

È una best practice di sicurezza adottare il principio del privilegio minimo per i progetti e le risorse Google Cloud, come i cluster GKE. Con questo approccio, le app in esecuzione all'interno del cluster e gli sviluppatori e gli operatori che lo utilizzano hanno solo l'insieme minimo di autorizzazioni richieste.

Queste architetture di riferimento ti aiutano a utilizzare gli account di servizio con privilegio minimo nel seguente modo:

  • Ogni pool di nodi GKE riceve il proprio account di servizio. Ad esempio, i nodi nel pool di nodi del tenant utilizzano un account di servizio dedicato a questi nodi. Gli account di servizio dei nodi sono configurati con le autorizzazioni minime richieste.
  • Il cluster utilizza la federazione delle identità per i carichi di lavoro per GKE per associare gli account di servizio Kubernetes agli account di servizio Google. In questo modo, alle app del tenant può essere concesso l'accesso limitato a qualsiasi API Google richiesta senza scaricare e memorizzare una chiave dell'account di servizio. Ad esempio, puoi concedere all'account di servizio le autorizzazioni per leggere i dati da un bucket Cloud Storage.

Queste architetture di riferimento ti aiutano a limitare l'accesso alle risorse del cluster nei seguenti modi:

  • Creerai un ruolo Kubernetes RBAC di esempio con autorizzazioni limitate per gestire le app. Puoi concedere questo ruolo agli utenti e ai gruppi che gestiscono le app nello spazio dei nomi del tenant. Se applichi questo ruolo limitato a utenti e gruppi, questi utenti avranno le autorizzazioni per modificare solo le risorse dell'app nello spazio dei nomi del tenant. Non hanno autorizzazioni per modificare le risorse a livello di cluster o le impostazioni di sicurezza sensibili come i criteri di Cloud Service Mesh.

Autorizzazione binaria

Autorizzazione binaria ti consente di applicare i criteri che definisci per le immagini container di cui viene eseguito il deployment nel tuo ambiente GKE. L'autorizzazione binaria consente di eseguire il deployment solo delle immagini container conformi ai criteri definiti. Vieta il deployment di altre immagini container.

In questa architettura di riferimento, l'autorizzazione binaria è attivata con la configurazione predefinita. Per esaminare la configurazione predefinita di Autorizzazione binaria, consulta Esportare il file YAML dei criteri.

Per ulteriori informazioni su come configurare i criteri, consulta le seguenti indicazioni specifiche:

Verifica dell'attestazione tra organizzazioni

Puoi utilizzare l'autorizzazione binaria per verificare le attestazioni generate da un firmatario di terze parti. Ad esempio, in un caso d'uso di apprendimento federato tra silos, puoi verificare le attestazioni create da un'altra organizzazione partecipante.

Per verificare le attestazioni create da terze parti:

  1. Ricevi le chiavi pubbliche utilizzate dalla terza parte per creare le attestazioni che devi verificare.
  2. Crea gli attestatori per verificare le attestazioni.
  3. Aggiungi le chiavi pubbliche che hai ricevuto dalla terza parte agli attestatori che hai creato.

Per ulteriori informazioni sulla creazione di attestatori, consulta le seguenti indicazioni specifiche:

Dashboard GKE Compliance

La dashboard GKE Compliance fornisce informazioni strategiche per rafforzare la tua postura di sicurezza e ti aiuta ad automatizzare i report sulla conformità per i benchmark e gli standard di settore. Puoi registrare i tuoi cluster GKE per attivare la generazione automatica di report sulla conformità.

Per ulteriori informazioni, consulta Informazioni sulla dashboard Conformità GKE.

Considerazioni sulla sicurezza dell'apprendimento federato

Nonostante il suo modello di condivisione dei dati rigoroso, l'apprendimento federato non è intrinsecamente sicuro contro tutti gli attacchi mirati e devi prendere in considerazione questi rischi quando implementi una delle architetture descritte in questo documento. Esiste anche il rischio di fughe di informazioni non intenzionali sui modelli di ML o sui dati di addestramento dei modelli. Ad esempio, un malintenzionato potrebbe compromettere intenzionalmente il modello di ML globale o i round dell'iniziativa di apprendimento federato oppure eseguire un attacco di temporizzazione (un tipo di attacco lato canale) per raccogliere informazioni sulle dimensioni dei set di dati di addestramento.

Le minacce più comuni a un'implementazione di apprendimento federato sono:

  • Memorizzazione intenzionale o non intenzionale dei dati di addestramento. L'implementazione dell'apprendimento federato o un malintenzionato potrebbe archiviare intenzionalmente o involontariamente i dati in modo che sia difficile utilizzarli. Un aggressore potrebbe essere in grado di raccogliere informazioni sul modello ML globale o sugli ultimi round dell'iniziativa di apprendimento federato mediante il reverse engineering dei dati archiviati.
  • Estrai informazioni dagli aggiornamenti del modello ML globale. Durante l'implementazione dell'apprendimento federato, un malintenzionato potrebbe eseguire il reverse engineering degli aggiornamenti al modello di ML globale che il proprietario della federazione raccoglie dalle organizzazioni e dai dispositivi partecipanti.
  • Il proprietario della federazione potrebbe compromettere i round. Un proprietario di una federazione compromesso potrebbe controllare un silo o un dispositivo non autorizzato e avviare un ciclo di apprendimento federato. Al termine del round, il proprietario della federazione compromessa potrebbe essere in grado di raccogliere informazioni sugli aggiornamenti che raccoglie dalle organizzazioni e dai dispositivi partecipanti legittimi confrontandoli con quelli prodotti dal silo malintenzionato.
  • Le organizzazioni e i dispositivi dei partecipanti potrebbero compromettere il modello di ML globale. Durante l'apprendimento federato, un malintenzionato potrebbe tentare di influire deliberatamente sul rendimento, sulla qualità o sull'integrità del modello di ML globale producendo aggiornamenti non validi o irrilevanti.

Per contribuire a mitigare l'impatto delle minacce descritte in questa sezione, consigliamo di seguire le seguenti best practice:

  • Ottimizza il modello per ridurre al minimo la memorizzazione dei dati di addestramento.
  • Implementare meccanismi incentrati sulla tutela della privacy.
  • Controlla regolarmente il modello ML globale, i modelli ML che intendi condividere, i dati di addestramento e l'infrastruttura che hai implementato per raggiungere i tuoi obiettivi di apprendimento federato.
  • Implementa un algoritmo di aggregazione sicura per elaborare i risultati della formazione prodotti dalle organizzazioni partecipanti.
  • Genera e distribuisci in modo sicuro le chiavi di crittografia dei dati utilizzando un'infrastruttura a chiave pubblica.
  • Esegui il deployment dell'infrastruttura su una piattaforma Confidential Computing.

I proprietari della federazione devono anche svolgere i seguenti passaggi aggiuntivi:

  • Verifica l'identità di ogni organizzazione partecipante e l'integrità di ogni silo in caso di architetture cross-silo, nonché l'identità e l'integrità di ogni dispositivo in caso di architetture cross-device.
  • Limitare l'ambito degli aggiornamenti al modello ML globale che possono produrre le organizzazioni e i dispositivi dei partecipanti.

Affidabilità

Questa sezione descrive i fattori di progettazione da tenere presenti quando utilizzi una delle architetture di riferimento in questo documento per progettare e creare una piattaforma di machine learning federato su Google Cloud.

Quando progetti l'architettura di machine learning federato su Google Cloud, ti consigliamo di seguire le indicazioni riportate in questa sezione per migliorare la disponibilità e la scalabilità del carico di lavoro e contribuire a rendere l'architettura resiliente a interruzioni e disastri.

GKE: GKE supporta diversi tipi di cluster che puoi personalizzare in base ai requisiti di disponibilità dei tuoi carichi di lavoro e al tuo budget. Ad esempio, puoi creare cluster a livello di regione che distribuiscono il piano di controllo e i nodi in più zone all'interno di una regione oppure cluster di zona che hanno il piano di controllo e i nodi in una singola zona. Entrambe le architetture di riferimento cross-silo e cross-device si basano su cluster GKE regionali. Per ulteriori informazioni sugli aspetti da considerare durante la creazione dei cluster GKE, consulta le scelte di configurazione del cluster.

A seconda del tipo di cluster e della modalità di distribuzione del piano di controllo e dei nodi del cluster tra regioni e zone, GKE offre diverse funzionalità di ripristino di emergenza per proteggere i tuoi workload da interruzioni a livello di zona e di regione. Per ulteriori informazioni sulle funzionalità di ripristino di emergenza di GKE, consulta Architecting disaster recovery for cloud infrastructure outages: Google Kubernetes Engine.

Google Cloud Load Balancing: GKE supporta diversi modi per bilanciare il carico del traffico verso i carichi di lavoro. Le implementazioni GKE delle API Kubernetes Gateway e Kubernetes Service ti consentono di eseguire il provisioning e la configurazione automatica di Cloud Load Balancing per esporre in modo sicuro e affidabile i carichi di lavoro in esecuzione nei tuoi cluster GKE.

In queste architetture di riferimento, tutto il traffico in entrata e in uscita passa attraverso i gateway Cloud Service Mesh. Questi gateway ti consentono di controllare in modo rigoroso il flusso di traffico all'interno e all'esterno dei tuoi cluster GKE.

Problemi di affidabilità per l'apprendimento federato cross-device

L'apprendimento federato cross-device presenta una serie di problemi di affidabilità che non si verificano negli scenari cross-silo. Di seguito sono elencati alcuni esempi:

  • Connettività del dispositivo inaffidabile o intermittente
  • Spazio di archiviazione del dispositivo limitato
  • Risorse di calcolo e memoria limitate

Una connettività inaffidabile può causare problemi come:

  • Aggiornamenti non aggiornati e divergenza del modello: quando i dispositivi presentano connettività intermittente, gli aggiornamenti del modello locale potrebbero non essere aggiornati e rappresentare informazioni obsolete rispetto allo stato attuale del modello globale. L'aggregazione di aggiornamenti obsoleti può portare a una divergenza del modello, in cui il modello globale si discosta dalla soluzione ottimale a causa di incoerenze nel processo di addestramento.
  • Contributi sbilanciati e modelli distorti: la comunicazione intermittente può comportare una distribuzione non uniforme dei contributi dei dispositivi partecipanti. I dispositivi con una connettività scadente potrebbero contribuire con meno aggiornamenti, inducendo a una rappresentazione sbilanciata della distribuzione degli dati sottostanti. Questo squilibrio può portare a un pregiudizio del modello globale nei confronti dei dati provenienti da dispositivi con connessioni più affidabili.
  • Aumento del sovraccarico di rete e del consumo energetico: la comunicazione intermittente può comportare un aumento del sovraccarico di rete, poiché i dispositivi potrebbero dover inviare nuovamente gli aggiornamenti persi o danneggiati. Questo problema può anche aumentare il consumo di energia sui dispositivi, in particolare su quelli con autonomia limitata della batteria, in quanto potrebbe essere necessario mantenere attive le connessioni per periodi più lunghi per garantire la trasmissione degli aggiornamenti.

Per contribuire ad attenuare alcuni degli effetti causati dalla comunicazione intermittente, le architetture di riferimento in questo documento possono essere utilizzate con il protocollo FCP.

Un'architettura di sistema che esegue il protocollo FCP può essere progettata per soddisfare i seguenti requisiti:

  • Gestisci i round a lunga esecuzione.
  • Attiva l'esecuzione speculativa (i round possono iniziare prima che il numero richiesto di client sia assemblato in previsione di un numero maggiore di check-in a breve).
  • Consenti ai dispositivi di scegliere a quali attività partecipare. Questo approccio può attivare funzionalità come il campionamento senza sostituzione, ovvero una strategia di campionamento in cui ogni unità campione di una popolazione ha una sola possibilità di essere selezionata. Questo approccio aiuta a mitigare i contributi sbilanciati e i modelli con pregiudizi.
  • Estensione per tecniche di anonimizzazione come la privacy differenziale (DP) e l'aggregazione attendibile (TAG).

Per contribuire a mitigare le limitate capacità di calcolo e di archiviazione dei dispositivi, possono essere utili le seguenti tecniche:

  • Scopri qual è la capacità massima disponibile per eseguire il calcolo dell'apprendimento federato
  • Scopri quanti dati possono essere memorizzati in un determinato momento
  • Progetta il codice di apprendimento federato lato client in modo che funzioni entro le risorse di calcolo e RAM disponibili sui client
  • Comprendere le implicazioni dell'esaurimento dello spazio di archiviazione e implementare un processo per gestirlo

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo della creazione e dell'esecuzione della piattaforma di machine learning federata su Google Cloud che stabilisci utilizzando questa architettura di riferimento. Queste indicazioni valgono per entrambe le architetture descritte in questo documento.

L'esecuzione di carichi di lavoro su GKE può aiutarti a ottimizzare i costi del tuo ambiente eseguendo il provisioning e la configurazione dei cluster in base ai requisiti delle risorse dei carichi di lavoro. Inoltre, abilita funzionalità che riconfigurano dinamicamente i cluster e i nodi del cluster, ad esempio la scalabilità automatica dei nodi e dei pod del cluster e la dimensione corretta dei cluster.

Per saperne di più sull'ottimizzazione dei costi degli ambienti GKE, consulta le best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE.

Efficienza operativa

Questa sezione descrive i fattori da considerare per ottimizzare l'efficienza quando utilizzi questa architettura di riferimento per creare ed eseguire una piattaforma di machine learning federata su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

Per aumentare l'automazione e il monitoraggio dell'architettura di apprendimento federato, ti consigliamo di adottare i principi MLOps, ovvero i principi DevOps nel contesto dei sistemi di machine learning. Praticare le MLOps significa promuovere l'automazione e il monitoraggio di tutte le fasi della creazione di un sistema ML, tra cui integrazione, test, rilascio, deployment e gestione dell'infrastruttura. Per saperne di più sulle MLOps, consulta MLOps: pipeline di distribuzione continua e automazione nel machine learning.

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da considerare per ottimizzare le prestazioni degli workloads quando utilizzi questa architettura di riferimento per creare ed eseguire una piattaforma di machine learning federata su Google Cloud. Queste indicazioni si applicano a entrambe le architetture descritte in questo documento.

GKE supporta diverse funzionalità per ridimensionare e scalare automaticamente e manualmente l'ambiente GKE in base alle esigenze dei tuoi carichi di lavoro ed evitare il provisioning eccessivo delle risorse. Ad esempio, puoi utilizzare Recommender per generare approfondimenti e consigli per ottimizzare l'utilizzo delle risorse GKE.

Quando pensi a come scalare il tuo ambiente GKE, ti consigliamo di progettare piani a breve, medio e lungo termine per come intendi scalare i tuoi ambienti e i tuoi carichi di lavoro. Ad esempio, come intendi far crescere il tuo impatto GKE in alcune settimane, mesi e anni? Avere un piano pronto ti consente di sfruttare al meglio le funzionalità di scalabilità offerte da GKE, ottimizzare i tuoi ambienti GKE e ridurre i costi. Per ulteriori informazioni sulla pianificazione della scalabilità dei cluster e dei carichi di lavoro, consulta Informazioni sulla scalabilità di GKE.

Per aumentare le prestazioni dei tuoi carichi di lavoro di ML, puoi adottare le Tensor Processing Unit (TPU) sul cloud (Cloud TPU), acceleratori di AI progettati da Google e ottimizzati per l'addestramento e l'inferenza di modelli AI di grandi dimensioni.

Deployment

Per eseguire il deployment delle architetture di riferimento cross-silo e cross-device descritte in questo documento, consulta il repository GitHub di Federated Learning su Google Cloud.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: