Silo- und geräteübergreifendes föderiertes Lernen in Google Cloud

Last reviewed 2024-06-03 UTC

In diesem Dokument werden zwei Referenzarchitekturen beschrieben, mit denen Sie mit Google Kubernetes Engine (GKE) eine Plattform für föderiertes Lernen in Google Cloud erstellen können. Die in diesem Dokument beschriebenen Referenzarchitekturen und die zugehörigen Ressourcen unterstützen Folgendes:

  • Siloübergreifendes föderiertes Lernen
  • Geräteübergreifendes föderiertes Lernen, das auf der siloübergreifenden Architektur aufbaut

Dieses Dokument richtet sich an Cloud-Architekten sowie KI- und ML-Entwickler, die Anwendungsfälle für föderiertes Lernen in Google Cloud implementieren möchten. Es richtet sich auch an Entscheidungsträger, die prüfen, ob föderiertes Lernen in Google Cloud implementiert werden soll.

Architektur

Die Diagramme in diesem Abschnitt zeigen eine siloübergreifende und eine geräteübergreifende Architektur für föderiertes Lernen. Weitere Informationen zu den verschiedenen Anwendungen für diese Architekturen finden Sie unter Anwendungsfälle.

Siloübergreifende Architektur

Das folgende Diagramm zeigt eine Architektur, die das siloübergreifende föderierte Lernen unterstützt:

Siloübergreifende Architektur, Komponenten im folgenden Text beschrieben.

Das obige Diagramm zeigt ein vereinfachtes Beispiel für eine siloübergreifende Architektur. Im Diagramm befinden sich alle Ressourcen im selben Projekt in einer Google Cloud-Organisation. Diese Ressourcen umfassen das lokale Clientmodell, das globale Clientmodell und die zugehörigen Arbeitslasten für föderiertes Lernen.

Diese Referenzarchitektur kann so geändert werden, dass sie mehrere Konfigurationen für Datensilos unterstützt. Mitglieder des Konsortiums können ihre Datensilos auf folgende Arten hosten:

  • In Google Cloud, in derselben Google Cloud-Organisation und im selben Google Cloud-Projekt.
  • In Google Cloud, in derselben Google Cloud-Organisation, in verschiedenen Google Cloud-Projekten.
  • In Google Cloud, in verschiedenen Google Cloud-Organisationen
  • In privaten, lokalen Umgebungen oder in anderen öffentlichen Clouds

Für die Zusammenarbeit müssen die teilnehmenden Mitglieder sichere Kommunikationskanäle zwischen ihren Umgebungen einrichten. Weitere Informationen über die Rolle der beteiligten Mitglieder im föderierten Lernen, ihre Zusammenarbeit und ihre Inhalte finden Sie unter Anwendungsfälle.

Die Architektur umfasst die folgenden Komponenten:

  • Ein VPC-Netzwerk (Virtual Private Cloud) und ein Subnetz.
  • Ein privater GKE-Cluster, der Sie bei Folgendem unterstützt:
    • Clusterknoten vom Internet isolieren
    • Die Sichtbarkeit Ihrer Clusterknoten und Steuerungsebene auf das Internet beschränken. Dazu erstellen Sie einen privaten GKE-Cluster mit autorisierten Netzwerken.
    • Shielded Clusterknoten verwenden, die ein gehärtetes Betriebssystem-Image nutzen.
    • Dataplane V2 für ein optimiertes Kubernetes-Netzwerk aktivieren.
  • Dedizierte GKE-Knotenpools: Sie erstellen einen dedizierten Knotenpool, um ausschließlich Mandantenanwendungen und -ressourcen zu hosten. Die Knoten haben Markierungen, damit nur Mandantenarbeitslasten auf den Mandantenknoten geplant werden. Andere Clusterressourcen werden im Hauptknotenpool gehostet.

  • Datenverschlüsselung (standardmäßig aktiviert):

  • Verschlüsselung von aktiven Daten, indem optional Confidential Google Kubernetes Engine-Knoten aktiviert werden.

  • VPC-Firewallregeln, die Folgendes anwenden:

    • Referenzregeln, die für alle Knoten im Cluster gelten.
    • Zusätzliche Regeln, die nur für Knoten im Mandantenknotenpool gelten. Diese Firewallregeln begrenzen den ein- und ausgehenden Traffic von Mandantenknoten.

  • Cloud NAT, um ausgehenden Traffic zum Internet zuzulassen.

  • Cloud DNS-Einträge zur Aktivierung des privaten Google-Zugriffs, sodass Anwendungen innerhalb des Clusters auf Google APIs zugreifen können, ohne das Internet zu durchlaufen.

  • Dienstkonten:

    • Ein dediziertes Dienstkonto für die Knoten im Mandantenknotenpool.
    • Ein dediziertes Dienstkonto für Mandantenanwendungen, die mit der Workload Identity-Föderation verwendet werden.

  • Unterstützung für die Verwendung von Rollenbasierter Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes in Google Groups

  • Ein Git-Repository zum Speichern von Konfigurationsdeskriptoren.

  • Ein Artifact Registry-Repository zum Speichern von Container-Images.

  • Config Sync und Policy Controller zum Bereitstellen der Konfiguration und von Richtlinien.

  • Cloud Service Mesh-Gateways, um selektiv eingehenden und ausgehenden Cluster-Traffic zuzulassen.

  • Cloud Storage-Buckets zum Speichern globaler und lokaler Modellgewichtungen.

  • Zugriff auf andere Google und Google Cloud APIs. Beispielsweise kann eine Trainingsarbeitslast auf Trainingsdaten zugreifen, die in Cloud Storage, BigQuery oder Cloud SQL gespeichert sind.

Geräteübergreifende Architektur

Das folgende Diagramm zeigt eine Architektur, die das geräteübergreifende föderierte Lernen unterstützt:

Geräteübergreifende Architektur, die im folgenden Text erläuterten Komponenten.

Die obige geräteübergreifende Architektur baut auf der siloübergreifenden Architektur mit den folgenden Komponenten auf:

  • Ein Cloud Run-Dienst, der Geräte simuliert, die eine Verbindung zum Server herstellen
  • Ein Certificate Authority Service, der private Zertifikate für den Server und die Clients erstellt, die ausgeführt werden sollen.
  • Ein Vertex AI TensorBoard zur Visualisierung des Ergebnisses des Trainings
  • Ein Cloud Storage-Bucket zum Speichern des konsolidierten Modells
  • Der private GKE-Cluster, der vertrauliche Knoten als primären Pool verwendet, um die verwendeten Daten zu schützen

Die geräteübergreifende Architektur verwendet Komponenten aus dem Open-Source-Projekt Federated Compute Platform (FCP). Dieses Projekt umfasst Folgendes:

  • Clientcode zur Kommunikation mit einem Server und zur Ausführung von Aufgaben auf den Geräten
  • Ein Protokoll für die Client-Server-Kommunikation
  • Verbindungspunkte mit TensorFlow Federated, um die Definition Ihrer föderierten Berechnungen zu vereinfachen

Die im vorherigen Diagramm gezeigten FCP-Komponenten können als eine Reihe von Mikrodiensten bereitgestellt werden. Diese Komponenten tun Folgendes:

  • Aggregator: Dieser Job liest Geräteverläufe und berechnet das aggregierte Ergebnis mit Differential Privacy.
  • Collector: Dieser Job wird regelmäßig ausgeführt, um aktive Aufgaben und verschlüsselte Gradienten abzufragen. Diese Informationen bestimmen, wann die Aggregation beginnt.
  • Modell-Uploader: Dieser Job überwacht Ereignisse und veröffentlicht Ergebnisse, damit Geräte aktualisierte Modelle herunterladen können.
  • Aufgabenzuweisung: Dieser Frontend-Dienst verteilt Trainingsaufgaben auf Geräte.
  • Aufgabenverwaltung: Dieser Job verwaltet Aufgaben.
  • Aufgabenplaner: Dieser Job wird entweder regelmäßig ausgeführt oder durch bestimmte Ereignisse ausgelöst.

Verwendete Produkte

Die Referenzarchitekturen für beide Anwendungsfälle für föderiertes Lernen verwenden die folgenden Google Cloud-Komponenten:

GKE bietet außerdem folgende Funktionen für Ihre föderierte Lernplattform:

  • Hosting des Koordinators für föderiertes Lernen: Der Koordinator für föderiertes Lernen ist für die Verwaltung des föderierten Lernprozesses verantwortlich. Diese Verwaltung umfasst Aufgaben wie die Verteilung des globalen Modells an die Teilnehmer, das Aggregieren von Aktualisierungen von den Teilnehmern und die Aktualisierung des globalen Modells. GKE kann verwendet werden, um den Koordinator für föderiertes Lernen auf hochverfügbare und skalierbare Weise zu hosten.
  • Hosting von Teilnehmern für föderiertes Lernen: Teilnehmer des föderierten Lernens sind dafür verantwortlich, das globale Modell mit ihren lokalen Daten zu trainieren. GKE kann verwendet werden, um Teilnehmer des föderierten Lernens auf sichere und isolierte Weise zu hosten. Dieser Ansatz kann dafür sorgen, dass die Daten der Teilnehmer lokal gespeichert werden.
  • Bereitstellung eines sicheren und skalierbaren Kommunikationskanals: Teilnehmer des föderierten Lernens müssen in der Lage sein, auf sichere und skalierbare Weise mit dem Koordinator für föderiertes Lernen zu kommunizieren. GKE kann verwendet werden, um einen sicheren und skalierbaren Kommunikationskanal zwischen Teilnehmern und dem Koordinator bereitzustellen.
  • Lebenszyklus von Bereitstellungen für föderiertes Lernen verwalten: Mit GKE kann der Lebenszyklus von Bereitstellungen für föderiertes Lernen verwaltet werden. Diese Verwaltung umfasst Aufgaben wie das Bereitstellen von Ressourcen, das Bereitstellen der föderierten Lernplattform und das Überwachen der Leistung der föderierten Lernplattform.

Zusätzlich zu diesen Vorteilen bietet GKE eine Reihe von Features, die für föderiertes Lernen nützlich sein können, z. B.:

  • Regionale Cluster: Mit GKE können Sie regionale Cluster erstellen und so die Leistung von Bereitstellungen für föderiertes Lernen verbessern, indem Sie die Latenz zwischen Teilnehmern und dem Koordinator reduzieren.
  • Netzwerkrichtlinien: Mit GKE können Sie Netzwerkrichtlinien erstellen und so die Sicherheit von Bereitstellungen für föderiertes Lernen verbessern. Dazu steuern Sie den Trafficfluss zwischen Teilnehmern und dem Koordinator.
  • Load-Balancing: GKE bietet eine Reihe von Load-Balancing-Optionen, mit denen die Skalierbarkeit von Bereitstellungen für föderiertes Lernen verbessert wird, indem der Traffic zwischen den Teilnehmern und dem Koordinator verteilt wird.

TFF bietet die folgenden Features, um die Implementierung von Anwendungsfällen für föderiertes Lernen zu erleichtern:

  • Die Möglichkeit, föderierte Berechnungen deklarativ auszudrücken, bei denen es sich um eine Reihe von Verarbeitungsschritten handelt, die auf einem Server und einer Reihe von Clients ausgeführt werden. Diese Berechnungen können in verschiedenen Laufzeitumgebungen bereitgestellt werden.
  • Benutzerdefinierte Aggregatoren können mit TFF Open Source erstellt werden.
  • Unterstützung einer Vielzahl von Algorithmen für föderiertes Lernen, einschließlich der folgenden Algorithmen:
    • Föderierte Mittelung: Ein Algorithmus, der den Durchschnitt der Modellparameter der teilnehmenden Clients ermittelt. Diese Architektur eignet sich besonders für Anwendungsfälle, bei denen die Daten relativ homogen sind und das Modell nicht zu komplex ist. Typische Einsatzbereiche sind:
      • Personalisierte Empfehlungen: Ein Unternehmen kann mit föderierten Mittelwerten ein Modell trainieren, das Nutzern Produkte basierend auf deren bisherigen Käufen empfiehlt.
      • Betrugserkennung: Ein Konsortium von Banken kann den föderierten Mittelwert verwenden, um ein Modell zu trainieren, das betrügerische Transaktionen erkennt.
      • Medizinische Diagnose: Eine Gruppe von Krankenhäusern kann den föderierten Durchschnitt verwenden, um ein Modell zu trainieren, das Krebs diagnostiziert.
    • Föderierter stochastischer Gradientenabfall (FedSGD): Ein Algorithmus, der den stochastischen Gradientenabstieg zur Aktualisierung der Modellparameter verwendet. Er eignet sich gut für Anwendungsfälle, bei denen die Daten heterogen sind und das Modell komplex ist. Typische Anwendungsfälle:
      • Natural Language Processing: Ein Unternehmen kann FedSGD zum Trainieren eines Modells verwenden, das die Genauigkeit der Spracherkennung verbessert.
      • Bilderkennung: Ein Unternehmen kann FedSGD verwenden, um ein Modell zu trainieren, das Objekte in Bildern identifizieren kann.
      • Vorausschauende Instandhaltung: Ein Unternehmen kann FedSGD verwenden, um ein Modell zu trainieren, das vorhersagt, wann eine Maschine wahrscheinlich ausfällt.
    • Föderierter Adam: Ein Algorithmus, der das Adam-Optimierungstool zum Aktualisieren der Modellparameter verwendet. Typische Anwendungsfälle:
      • Recommender-Systeme: Ein Unternehmen kann föderierten Adam verwenden, um ein Modell zu trainieren, das Nutzern Produkte basierend auf deren bisherigen Käufen empfiehlt.
      • Ranking: Ein Unternehmen kann föderierten Adam verwenden, um ein Modell zu trainieren, das das Ranking von Suchergebnissen bestimmt.
      • Vorhersage der Klickrate: Ein Unternehmen kann föderierten Adam verwenden, um ein Modell zu trainieren, das die Wahrscheinlichkeit vorhersagt, dass ein Nutzer auf eine Anzeige klickt.

Anwendungsfälle

In diesem Abschnitt werden Anwendungsfälle beschrieben, in denen die silo- und geräteübergreifenden Architekturen für Ihre Plattform für föderiertes Lernen geeignet sind.

Föderiertes Lernen ist eine Einstellung für maschinelles Lernen, bei der viele Clients ein Modell gemeinsam trainieren. Dieser Prozess wird von einem zentralen Koordinator geleitet und die Trainingsdaten bleiben dezentralisiert.

Beim föderierten Lernen laden Clients ein globales Modell herunter und verbessern das Modell, indem sie lokal mit ihren Daten trainieren. Anschließend sendet jeder Client seine berechneten Modellaktualisierungen zurück an den zentralen Server, auf dem die Modellaktualisierungen zusammengefasst und eine neue Iteration des globalen Modells generiert werden. In diesen Referenzarchitekturen werden die Arbeitslasten für das Modelltraining in GKE ausgeführt.

Föderiertes Lernen verbindet das Datenschutzprinzip der Datenminimierung. Dabei wird festgelegt, welche Daten in jeder Berechnungsphase erfasst werden, der Zugriff auf Daten beschränkt und die Daten werden verarbeitet und dann so früh wie möglich verworfen. Darüber hinaus ist die Problemeinstellung des föderierten Lernens mit zusätzlichen Datenschutztechniken kompatibel, z. B. der Verwendung von Differential Privacy (DP), um die Modellanonymisierung zu verbessern, damit das endgültige Modell nicht die Daten einzelner Nutzer speichert.

Je nach Anwendungsfall können Trainingsmodelle mit föderiertem Lernen zusätzliche Vorteile haben:

  • Compliance: In einigen Fällen können Vorschriften die Verwendung oder Freigabe von Daten einschränken. Föderiertes Lernen kann verwendet werden, um diese Vorschriften einzuhalten.
  • Kommunikationseffizienz: In einigen Fällen ist es effizienter, ein Modell mit verteilten Daten zu trainieren, als die Daten zu zentralisieren. Beispielsweise sind die Datasets, mit denen das Modell trainiert werden muss, zu groß, um zentral zu verschoben werden.
  • Bereitstellung von Daten: Föderiertes Lernen ermöglicht es Organisationen, die Trainingsdaten in Datensilos pro Nutzer oder Organisation zu dezentralisieren.
  • Höhere Modellgenauigkeit: Durch das Training mit realen Nutzerdaten (unter Sicherstellung des Datenschutzes) anstelle von synthetischen Daten (manchmal auch als Proxydaten bezeichnet) führt dies häufig zu einer höheren Modellgenauigkeit.

Es gibt verschiedene Arten des föderierten Lernens, die dadurch gekennzeichnet sind, woher die Daten stammen und wo die lokalen Berechnungen stattfinden. Die Architekturen in diesem Dokument konzentrieren sich auf zwei Arten des föderierten Lernens: silo- und geräteübergreifend. Andere Arten des föderierten Lernens werden in diesem Dokument nicht behandelt.

Föderiertes Lernen wird weiter danach kategorisiert, wie die Datasets partitioniert sind. Dies kann so aussehen:

  • Horizontales föderiertes Lernen (HFL): Datasets mit den gleichen Features (Spalten), aber unterschiedlichen Beispielen (Zeilen). So können beispielsweise mehrere Krankenhäuser Patientenakten mit denselben medizinischen Parametern, aber unterschiedliche Patientengruppen haben.
  • Vertikales föderiertes Lernen (VFL): Datasets mit den gleichen Beispielen (Zeilen), aber unterschiedlichen Features (Spalten). Beispielsweise können eine Bank und ein E-Commerce-Unternehmen Kundendaten mit sich überschneidenden Einzelpersonen, aber unterschiedlichen Finanz- und Kaufinformationen haben.
  • Föderiertes Transfer-Lernen (FTL): Teilweise Überschneidung sowohl bei den Beispielen als auch bei den Features der Datasets. Zwei Krankenhäuser können beispielsweise Patientendatensätze mit einigen überlappenden Personen und einigen gemeinsamen medizinischen Parametern haben, aber auch eindeutige Features in jedem Dataset.

Bei der siloübergreifenden föderierten Berechnung sind die beteiligten Mitglieder Organisationen oder Unternehmen. In der Praxis ist die Anzahl der Mitglieder normalerweise klein (z. B. bis zu 100 Mitglieder). Die siloübergreifende Berechnung wird in der Regel verwendet, wenn die beteiligten Organisationen verschiedene Datasets haben, aber ein gemeinsames Modell trainieren oder aggregierte Ergebnisse analysieren möchten, ohne ihre Rohdaten miteinander zu teilen. Teilnehmende Mitglieder können beispielsweise ihre Umgebungen in verschiedenen Google Cloud-Organisationen haben, z. B. wenn sie verschiedene Rechtspersönlichkeiten repräsentieren, oder in derselben Google Cloud-Organisation, z. B. wenn sie verschiedene Abteilungen derselben juristischen Person.

Teilnehmende Mitglieder können die Arbeitslasten des jeweils anderen möglicherweise nicht als vertrauenswürdige Entitäten betrachten. Beispielsweise hat ein teilnehmendes Mitglied möglicherweise keinen Zugriff auf den Quellcode einer Trainingsarbeitslast, den es von einem Drittanbieter wie dem Koordinator erhält. Da er nicht auf diesen Quellcode zugreifen kann, kann das teilnehmende Mitglied nicht gewährleisten, dass die Arbeitslast vollständig vertrauenswürdig ist.

So verhindern Sie, dass eine nicht vertrauenswürdige Arbeitslast ohne Autorisierung auf Ihre Daten oder Ressourcen zugreift:

  • Nicht vertrauenswürdige Arbeitslasten in einer isolierten Umgebung bereitstellen.
  • Gewähren Sie nicht vertrauenswürdigen Arbeitslasten nur die absolut erforderlichen Zugriffsrechte und Berechtigungen, um die der Arbeitslast zugewiesenen Trainingsrunden abzuschließen.

Damit Sie potenziell nicht vertrauenswürdige Arbeitslasten isolieren können, implementieren diese Referenzarchitekturen Sicherheitskontrollen, z. B. die Konfiguration isolierter Kubernetes-Namespaces, wobei jeder Namespace einen dedizierten GKE-Knotenpool hat. Die namespace-übergreifende Kommunikation sowie der eingehende und ausgehende Traffic des Clusters sind standardmäßig verboten, sofern Sie diese Einstellung nicht explizit überschreiben.

Beispielanwendungsfälle für das siloübergreifende föderierte Lernen:

  • Betrugserkennung: Föderiertes Lernen kann verwendet werden, um ein Betrugserkennungsmodell für Daten zu trainieren, die über mehrere Organisationen verteilt sind. So könnte ein Konsortium von Banken beispielsweise föderiertes Lernen verwenden, um ein Modell zu trainieren, das betrügerische Transaktionen erkennt.
  • Medizinische Diagnose: Mit föderiertem Lernen kann ein medizinisches Diagnosemodell für Daten trainiert werden, die über mehrere Krankenhäuser verteilt sind. Beispielsweise könnte eine Gruppe von Krankenhäusern föderiertes Lernen verwenden, um ein Modell zu trainieren, das Krebs diagnostiziert.

Geräteübergreifendes föderiertes Lernen ist eine Art der föderierten Berechnung, bei der die beteiligten Mitglieder Endnutzergeräte wie Smartphones, Fahrzeuge oder IoT-Geräte sind. Die Anzahl der Mitglieder kann eine Größenordnung von bis zu Millionen oder sogar mehreren zehn Millionen erreichen.

Der Vorgang für geräteübergreifendes föderiertes Lernen ähnelt dem Verfahren für siloübergreifendes föderiertes Lernen. Er erfordert jedoch auch die Anpassung der Referenzarchitektur, um einige der zusätzlichen Faktoren zu berücksichtigen, die Sie berücksichtigen müssen, wenn Sie mit Tausenden bis Millionen Geräten zu tun haben. Sie müssen administrative Arbeitslasten bereitstellen, um Szenarien zu verarbeiten, die in Anwendungsfällen für geräteübergreifendes föderiertes Lernen auftreten. Beispielsweise muss eine Teilmenge der Clients koordiniert werden, die in der Trainingsrunde stattfinden. Die geräteübergreifende Architektur bietet diese Möglichkeit, da Sie die FCP-Dienste bereitstellen können. Diese Dienste haben Arbeitslasten, die Verbindungspunkte mit TFF haben. TFF wird zum Schreiben des Codes verwendet, der diese Koordination verwaltet.

Beispielanwendungsfälle für das geräteübergreifende föderierte Lernen:

  • Personalisierte Empfehlungen: Sie können geräteübergreifendes föderiertes Lernen verwenden, um ein personalisiertes Empfehlungsmodell für Daten zu trainieren, die auf mehrere Geräte verteilt sind. So kann ein Unternehmen beispielsweise föderiertes Lernen verwenden, um ein Modell zu trainieren, das Nutzern Produkte basierend auf deren bisherigen Käufen empfiehlt.
  • Natural Language Processing: Föderiertes Lernen kann verwendet werden, um ein Natural Language Processing-Modell für Daten zu trainieren, die auf mehrere Geräte verteilt sind. So könnte ein Unternehmen beispielsweise föderiertes Lernen verwenden, um ein Modell zu trainieren, das die Genauigkeit der Spracherkennung verbessert.
  • Anforderungen an die Fahrzeugwartung vorhersagen: Mit föderiertem Lernen kann ein Modell trainiert werden, das vorhersagt, wann ein Fahrzeug voraussichtlich gewartet werden muss. Dieses Modell kann mit Daten trainiert werden, die von mehreren Fahrzeugen erfasst werden. So kann das Modell aus den Erfahrungen aller Fahrzeuge lernen, ohne die Privatsphäre der einzelnen Fahrzeuge zu beeinträchtigen.

In der folgenden Tabelle sind die Features der silo- und geräteübergreifenden Architekturen zusammengefasst und es wird gezeigt, wie Sie die Art des föderierten Lernen-Szenarios kategorisieren, das für Ihren Anwendungsfall geeignet ist.

Funktion Siloübergreifende föderierte Berechnungen Geräteübergreifende föderierte Berechnungen
Bestandsgröße In der Regel klein (z. B. bis zu 100 Geräte) Skalierbar auf Tausende, Millionen oder mehrere Hundert Millionen Geräte
Beteiligte Mitglieder Organisationen oder Unternehmen Mobilgeräte, Edge-Geräte, Fahrzeuge
Gängige Datenpartitionierung HFL, VFL, FTL HFL
Vertraulichkeit der Daten Vertrauliche Daten, die die Teilnehmer nicht im Rohformat miteinander teilen möchten. Daten, die zu vertraulich sind, um sie für einen zentralen Server freizugeben
Datenverfügbarkeit Die Teilnehmer sind fast immer verfügbar Nur ein Bruchteil der Teilnehmer ist jederzeit verfügbar.
Beispielanwendungsfälle Betrugserkennung, medizinische Diagnose, Finanzprognose Fitness-Tracking, Spracherkennung, Bildklassifizierung

Designaspekte

Dieser Abschnitt enthält eine Anleitung zur Verwendung dieser Referenzarchitektur, um eine oder mehrere Architekturen zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, operativer Effizienz, Kosten und Leistung entsprechen.

Überlegungen zum siloübergreifenden Architekturdesign

Wenn Sie eine siloübergreifende Architektur für föderiertes Lernen in Google Cloud implementieren möchten, müssen Sie die folgenden Mindestvoraussetzungen implementieren, die in den folgenden Abschnitten ausführlicher erläutert werden:

  1. Konsortium des föderierten Lernens einrichten
  2. Legen Sie das Zusammenarbeitsmodell fest, das für das Konsortium des föderierten Lernens implementiert werden soll.
  3. Die Verantwortlichkeiten der teilnehmenden Organisationen festlegen

Zusätzlich zu diesen Voraussetzungen gibt es weitere Aktionen, die der Föderationsinhaber ausführen muss, die in diesem Dokument nicht behandelt werden. Dazu gehören z. B.:

  • Konsortium des föderierten Lernens verwalten.
  • Modell zur Zusammenarbeit entwerfen und implementieren.
  • Modelltrainingsdaten sowie das Modell, das der Föderationsinhaber trainieren möchte, vorbereiten, verwalten und betreiben.
  • Workflows für föderiertes Lernen erstellen, containerisieren und orchestrieren
  • Workloads zum föderierten Lernen bereitstellen und verwalten.
  • Einrichten der Kommunikationskanäle für die Teilnehmerorganisationen, um Daten sicher zu übertragen.

Föderiertes Lernen-konsortium einrichten

Ein Konsortium für föderiertes Lernen ist die Gruppe von Organisationen, die an Bemühungen zum siloübergreifenden föderierten Lernen beteiligt sind. Organisationen im Konsortium teilen nur die Parameter der ML-Modelle und Sie können diese Parameter verschlüsseln, um den Datenschutz zu erhöhen. Wenn das Konsortium für föderiertes Lernen es zulässt, können Organisationen auch Daten zusammenfassen, die keine personenbezogenen Daten enthalten.

Zusammenarbeitsmodell für das föderierte Lernen-konsortium festlegen

Das Konsortium für föderiertes Lernen kann verschiedene Zusammenarbeitsmodelle implementieren, z. B.:

  • Ein zentralisiertes Modell, das aus einer einzelnen koordinierenden Organisation besteht, die als Föderationsinhaber oder Orchestrator bezeichnet wird, und eine Reihe von Teilnehmerorganisationen oder Dateninhaber.
  • Ein dezentralisiertes Modell, das aus Organisationen besteht, die als Gruppe koordinieren.
  • Ein heterogenes Modell, das aus einem Konsortium verschiedener beteiligter Organisationen besteht, die verschiedene Ressourcen in das Konsortium einbringen.

In diesem Dokument wird davon ausgegangen, dass das Zusammenarbeitsmodell ein zentralisiertes Modell ist.

Die Verantwortlichkeiten der Teilnehmenden Organisationen festlegen

Nachdem Sie ein Zusammenarbeitsmodell für das Konsortium für föderiertes Lernen ausgewählt haben, muss der Föderationsinhaber die Verantwortlichkeiten für die Teilnehmerorganisationen festlegen.

Der Föderationsinhaber muss außerdem Folgendes tun, wenn er mit der Erstellung eines Konsortiums für föderiertes Lernen beginnt:

  • Koordinieren der föderierten Lernbemühungen.
  • Entwerfen und implementieren Sie das globale ML-Modell und die ML-Modelle, die Sie mit den Teilnehmerorganisationen teilen werden.
  • Runden föderierten Lernens definieren – der Ansatz für die Iteration des ML-Trainingsprozesses.
  • Auswählen der Teilnehmerorganisationen, die an der jeweiligen Runde föderierten Lernens beteiligt sind. Diese Auswahl wird als Kohorte bezeichnet.
  • Entwerfen und Implementieren eines Überprüfungsverfahrens in Bezug auf die Konsortiumsmitgliedschaft für die Teilnehmerorganisationen.
  • Aktualisieren Sie das globale ML-Modell und die ML-Modelle, die sie mit den Teilnehmerorganisationen teilen werden.
  • Geben Sie den Teilnehmerorganisationen die Tools, um zu prüfen, ob das föderierte Lernkonsortium ihre Datenschutz-, Sicherheits- und behördlichen Anforderungen erfüllt.
  • Bereitstellen sicherer und verschlüsselter Kommunikationskanäle für die Teilnehmerorganisationen.
  • Bereitstellen aller erforderlichen nicht vertraulichen, aggregierten Daten, die die Teilnehmerorganisationen benötigen, um die einzelnen Runden föderierten Lernens durchzuführen.

Die Teilnehmerorganisationen sind für Folgendes verantwortlich:

  • Eine sichere, isolierte Umgebung (ein Silo) bereitstellen und pflegen. Der Silo ist der Ort, an dem Teilnehmerorganisationen ihre eigenen Daten speichern und wo das ML-Modelltraining implementiert wird.
  • Trainieren der vom Föderationsinhaber bereitgestellten Modelle mit ihrer eigenen Recheninfrastruktur und ihren eigenen lokalen Daten.
  • Freigeben der Ergebnisse des Modelltrainings für den Föderations-inhaber in Form von aggregierten Daten, nachdem die personenbezogene Daten entfernt wurden.

Der Föderationsinhaber und die Teilnehmerorganisationen optimieren das ML-Modelltraining, bis das Modell ihre Anforderungen erfüllt.

Föderiertes Lernen in Google Cloud implementieren

Nachdem Sie das Konsortium für föderiertes Lernen eingerichtet und festgelegt haben, wie das Konsortium für föderiertes Lernen zusammenarbeiten soll, sollten die Teilnehmerorganisationen Folgendes tun:

  1. Notwendige Infrastruktur für das Konsortium für föderiertes Lernen bereitstellen und konfigurieren
  2. Das Zusammenarbeitsmodell Implementieren
  3. Maßnahmen für föderiertes Lernen starten

Infrastruktur für das föderierte Lernen-konsortium bereitstellen und konfigurieren

Bei der Bereitstellung und Konfiguration der Infrastruktur für das föderierte Lernkonsortium ist es die Aufgabe des Föderationseigentümers, die Arbeitslasten zu erstellen und zu verteilen an die Teilnehmerorganisationen, die die föderierten ML-Modelle trainieren. Da ein Drittanbieter (der Föderationsinhaber) die Arbeitslasten erstellt und bereitgestellt hat, müssen die Teilnehmerorganisationen bei der Bereitstellung dieser Arbeitslasten in ihren Laufzeitumgebungen gewisse Vorkehrungen treffen.

Teilnehmerorganisationen müssen ihre Umgebungen entsprechend ihren individuellen Best Practices für die Sicherheit konfigurieren und Kontrollen anwenden, die den Umfang und die Berechtigungen der einzelnen Arbeitslasten einschränken. Neben dem Beachten der individuellen Best Practices für die Sicherheit empfehlen wir, dass der Föderationsinhaber und die Teilnehmerorganisationen Bedrohungsvektoren berücksichtigen, die für das föderierte Lernen spezifisch sind.

Zusammenarbeitsmodell Implementieren

Nachdem die Infrastruktur des Konsortiums für föderiertes Lernen erstellt wurde, entwickelt und implementiert der Föderationsinhaber die Mechanismen, die die Interaktion zwischen den Teilnehmerorganisationen ermöglichen. Der Ansatz folgt dem Zusammenarbeitsmodell, das der Föderationsinhaber für das Konsortium für föderiertes Lernen ausgewählt hat.

Föderiertes Lernen starten

Nach der Implementierung des Zusammenarbeitsmodells implementiert der Föderationsinhaber das globale ML-Modell zum Trainieren und die ML-Modelle zur Freigabe für die Teilnehmerorganisation. Sobald diese ML-Modelle bereit sind, startet der Föderationsinhaber die erste Runde des föderierten Lernens.

Der Föderationsinhaber tut in jeder Runde des föderierten Lernens Folgendes:

  1. Er verteilt die ML-Modelle, die mit den Teilnehmerorganisationen geteilt werden sollen.
  2. Er wartet, bis die Teilnehmerorganisationen die Ergebnisse des Trainings der ML-Modelle geliefert haben, die der Föderationsinhaber mit ihnen geteilt hat.
  3. Er erfasst und verarbeitet die Trainingsergebnisse, die die Teilnehmerorganisationen erstellt haben.
  4. Er aktualisiert das globale ML-Modell, wenn er angemessene Trainingsergebnisse von beteiligten Organisationen erhält.
  5. Er aktualisiert die ML-Modelle, die mit den anderen Mitglieder des Konsortiums geteilt werden sollen, falls zutreffend.
  6. Er bereitet die Trainingsdaten für die nächste föderierte Lernrunde vor.
  7. Er startet die nächste Runde des föderierten Lernens.

Sicherheit, Datenschutz und Compliance

In diesem Abschnitt werden Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Entwerfen und Erstellen einer Plattform für föderiertes Lernen in Google Cloud berücksichtigen sollten. Diese Anleitung gilt für beide Architekturen, die in diesem Dokument beschrieben werden.

Durch die Arbeitslasten für föderiertes Lernen, die Sie in Ihren Umgebungen bereitstellen, können Sie, Ihre Daten, Ihre Modelle für föderiertes Lernen und Ihre Infrastruktur Bedrohungen ausgesetzt sein, die sich auf Ihr Unternehmen auswirken könnten.

Damit Sie die Sicherheit Ihrer Umgebungen für föderiertes Lernen erhöhen können, konfigurieren diese Referenzarchitekturen GKE-Sicherheitskontrollen, die sich auf die Infrastruktur Ihrer Umgebungen konzentrieren. Diese Kontrollen sind möglicherweise nicht ausreichend, um Sie vor Bedrohungen zu schützen, die für Ihre Workloads und Anwendungsfälle für föderiertes Lernen spezifisch sind. Angesichts der Genauigkeit der einzelnen Arbeitslasten und Anwendungsfälle für föderiertes Lernen werden Sicherheitskontrollen, die zum Schutz Ihrer Implementierung für föderiertes Lernen dienen, in diesem Dokument nicht behandelt. Weitere Informationen und Beispiele zu diesen Bedrohungen finden Sie unter Sicherheitsaspekte des föderierten Lernens.

GKE-Sicherheitskontrollen

In diesem Abschnitt werden die Steuerelemente erläutert, die Sie mit diesen Architekturen anwenden, um Ihren GKE-Cluster zu sichern.

Verbesserte Sicherheit von GKE-Clustern

Diese Referenzarchitekturen unterstützen Sie beim Erstellen eines GKE-Clusters mit den folgenden Sicherheitseinstellungen:

Weitere Informationen zu GKE-Sicherheitseinstellungen finden Sie unter Sicherheit Ihres Clusters erhöhen und Informationen zum Sicherheitsstatus-Dashboard.

VPC-Firewallregeln

VPC-Firewallregeln steuern, welcher Traffic zu oder von Compute Engine-VMs zugelassen wird. Mit den Regeln können Sie Traffic auf VM-Ebene in Abhängigkeit von Layer-4-Attributen filtern.

Sie erstellen einen GKE-Cluster mit den Standard-Firewallregeln für GKE-Cluster. Diese Firewallregeln ermöglichen die Kommunikation zwischen den Clusterknoten und der GKE-Steuerungsebene sowie zwischen Knoten und Pods im Cluster.

Sie wenden zusätzliche Firewallregeln auf die Knoten im Mandantenknotenpool an. Diese Firewallregeln beschränken den ausgehenden Traffic von den Mandantenknoten. Dieser Ansatz kann die Isolation der Mandantenknoten erhöhen. Standardmäßig wird der gesamte ausgehende Traffic von den Mandantenknoten abgelehnt. Jeder erforderliche ausgehende Traffic muss explizit konfiguriert werden. Sie erstellen beispielsweise Firewallregeln, um ausgehenden Traffic von den Mandantenknoten zur GKE-Steuerungsebene und zu Google APIs mithilfe des privaten Google-Zugriffs zuzulassen. Die Firewallregeln werden mithilfe des Dienstkontos für den Mandantenknotenpool auf die Mandantenknoten ausgerichtet.

Namespaces

Mit Namespaces können Sie einen Bereich für zusammengehörige Ressourcen innerhalb eines Clusters angeben, z. B. Pods, Dienste und Replikationscontroller. Durch die Verwendung von Namespaces können Sie die Verwaltungsverantwortung für die zugehörigen Ressourcen als Einheit delegieren. Daher sind Namespaces ein wichtiger Bestandteil der meisten Sicherheitsmuster.

Namespaces sind ein wichtiges Feature zur Isolierung von Steuerungsebenen. Sie bieten jedoch keine Isolation von Knoten, Datenebenen oder Netzwerken.

Ein gängiger Ansatz besteht darin, Namespaces für einzelne Anwendungen zu erstellen. Sie können beispielsweise den Namespace myapp-frontend für die UI-Komponente einer Anwendung erstellen.

Diese Referenzarchitekturen unterstützen Sie beim Erstellen eines dedizierten Namespace zum Hosten der Drittanbieteranwendungen. Der Namespace und seine Ressourcen werden innerhalb Ihres Clusters als Mandanten behandelt. Sie wenden Richtlinien und Steuerelemente auf den Namespace an, um den Umfang der Ressourcen im Namespace einzuschränken.

Netzwerkrichtlinien

Netzwerkrichtlinien erzwingen Layer-4-Netzwerk-Trafficflüsse mithilfe von Firewallregeln auf Pod-Ebene. Netzwerkrichtlinien sind auf einen Namespace beschränkt.

In den in diesem Dokument beschriebenen Referenzarchitekturen wenden Sie Netzwerkrichtlinien auf den Mandanten-Namespace an, der die Anwendungen von Drittanbietern hostet. Standardmäßig lehnt die Netzwerkrichtlinie den gesamten Traffic zu und von Pods im Namespace ab. Jeder erforderliche Traffic muss explizit einer Zulassungsliste hinzugefügt werden. Beispielsweise lassen die Netzwerkrichtlinien in diesen Referenzarchitekturen explizit Traffic zu den erforderlichen Clusterdiensten wie dem internen Cluster-DNS und der Steuerungsebene von Cloud Service Mesh zu.

Config Sync

Config Sync synchronisiert Ihre GKE-Cluster mit Konfigurationen, die in einem Git-Repository gespeichert sind. Das Git-Repository fungiert als zentrale Informationsquelle für Ihre Clusterkonfiguration und -richtlinien. Config Sync ist deklarativ. Der Dienst prüft kontinuierlich den Clusterstatus und wendet den in der Konfigurationsdatei deklarierten Status zur Erzwingung von Richtlinien an. Dadurch werden Abweichungen von der Konfiguration verhindert.

Sie installieren Config Sync in Ihrem GKE-Cluster. Sie konfigurieren Config Sync so, dass Clusterkonfigurationen und -richtlinien aus einem Cloud Source Repository synchronisiert werden. Die synchronisierten Ressourcen umfassen Folgendes:

  • Cloud Service Mesh-Konfiguration auf Clusterebene
  • Sicherheitsrichtlinien auf Clusterebene
  • Konfiguration und Richtlinie auf Mandantenebene, darunter Netzwerkrichtlinien, Dienstkonten, RBAC-Regeln und die Cloud Service Mesh-Konfiguration

Policy Controller

Policy Controller von Google Kubernetes Engine (GKE) Enterprise ist ein dynamischer Admission-Controller für Kubernetes, der CRD-basierte Richtlinien (CustomResourceDefinition) erzwingt, die durch den Open Policy Agent (OPA) ausgeführt werden.

Zugangssteuerungen sind Kubernetes-Plug-ins, die Anfragen an den Kubernetes API-Server abfangen, bevor ein Objekt beibehalten wird, aber nachdem die Anfrage authentifiziert und autorisiert wurde. Sie können die Verwendung von Clustern mithilfe von Zugangssteuerungen einschränken.

Sie installieren Policy Controller in Ihrem GKE-Cluster. Diese Referenzarchitekturen enthalten Beispielrichtlinien zum Schutz Ihres Clusters. Sie wenden die Richtlinien automatisch mit Config Sync auf Ihren Cluster an. Sie wenden die folgenden Richtlinien an:

Cloud Service Mesh

Cloud Service Mesh ist ein Service Mesh, mit dem Sie die Verwaltung sicherer Kommunikation zwischen Diensten vereinfachen können. Mit diesen Referenzarchitekturen wird Cloud Service Mesh so konfiguriert, dass die Lösung Folgendes tut:

  • Sidecar-Proxys werden automatisch eingefügt.
  • mTLS-Kommunikation zwischen Diensten im Mesh-Netzwerk erzwingen.
  • Ausgehenden Mesh-Traffic auf bekannte Hosts beschränken.
  • Eingehenden Traffic auf bestimmte Clients beschränken.
  • Hiermit können Sie Netzwerksicherheitsrichtlinien konfigurieren, die auf der Dienstidentität basieren und nicht auf der IP-Adresse von Peers im Netzwerk.
  • Autorisierte Kommunikation zwischen Diensten im Mesh-Netzwerk beschränken. Anwendungen im Mandanten-Namespace können beispielsweise nur mit Anwendungen im selben Namespace oder mit einer Reihe bekannter externer Hosts kommunizieren.
  • Leitet den gesamten ein- und ausgehenden Traffic über Mesh-Gateways weiter, auf denen Sie weitere Trafficsteuerungen anwenden können.
  • Unterstützt die sichere Kommunikation zwischen Clustern.

Knotenmarkierungen und -affinitäten

Knotenmarkierungen und Knotenaffinität sind Kubernetes-Mechanismen, mit denen Sie die Planung von Pods auf Clusterknoten beeinflussen können.

Markierungsknoten verwerfen Pods. Kubernetes plant einen Pod nur dann auf einem markierten Knoten, wenn der Pod eine Toleranz für die Markierung hat. Sie können mit Knotenmarkierungen Knoten für bestimmte Arbeitslasten oder Mandanten reservieren. Markierungen und Toleranzen werden häufig in mehrmandantenfähigen Clustern verwendet. Weitere Informationen finden Sie in der Dokumentation zu dedizierten Knoten mit Markierungen und Toleranzen.

Mit der Knotenaffinität können Sie Pods auf Knoten mit bestimmten Labels beschränken. Wenn ein Pod eine Knotenaffinitätsanforderung hat, plant Kubernetes den Pod nur dann auf einem Knoten, wenn dieser ein der Affinitätsanforderung entsprechendes Label hat. Mit der Knotenaffinität können Sie dafür sorgen, dass Pods auf geeigneten Knoten geplant werden.

Sie können Knotenmarkierungen und Knotenaffinität zusammen verwenden, um dafür zu sorgen, dass Pods von Mandanten-Arbeitslasten ausschließlich auf Knoten geplant werden, die für den Mandanten reserviert sind.

Mit diesen Referenzarchitekturen können Sie die Planung der Mandantenanwendungen so steuern:

  • GKE-Knotenpool für den Mandanten erstellen. Jeder Knoten im Pool hat eine Markierung für den Mandantennamen.
  • Die entsprechende Toleranz und Knotenaffinität wird automatisch auf jeden Pod angewendet, der auf den Mandanten-Namespace ausgerichtet ist. Sie wenden Toleranz und Affinität mit PolicyController-Mutationen an.

Geringste Berechtigung

Es ist eine bewährte Sicherheitsmethode, das Prinzip der geringsten Berechtigung für Ihre Google Cloud-Projekte und -Ressourcen wie GKE-Cluster anzuwenden. Bei diesem Ansatz haben die Anwendungen, die in Ihrem Cluster ausgeführt werden, und die Entwickler und Operatoren, die den Cluster verwenden, nur die erforderlichen Mindestberechtigungen.

Diese Referenzarchitekturen unterstützen Sie auf folgende Weise bei der Verwendung von Dienstkonten mit minimalen Berechtigungen:

  • Jeder GKE-Knotenpool erhält ein eigenes Dienstkonto. Beispielsweise verwenden die Knoten im Mandantenknotenpool ein Dienstkonto, das diesen Knoten zugeordnet ist. Die Knoten-Dienstkonten werden mit den erforderlichen Mindestberechtigungen konfiguriert.
  • Der Cluster verwendet Workload Identity, um Kubernetes-Dienstkonten mit Google-Dienstkonten zu verknüpfen. Auf diese Weise können die Mandantenanwendungen eingeschränkten Zugriff auf alle erforderlichen Google APIs erhalten, ohne einen Dienstkontoschlüssel herunterladen und speichern zu müssen. Beispielsweise können Sie dem Dienstkonto Berechtigungen zum Lesen von Daten aus einem Cloud Storage-Bucket erteilen.

Mit diesen Referenzarchitekturen können Sie den Zugriff auf Clusterressourcen einschränken:

  • Sie erstellen eine Kubernetes-RBAC-Beispielrolle mit eingeschränkten Berechtigungen zum Verwalten von Anwendungen. Sie können diese Rolle den Nutzern und Gruppen zuweisen, die die Anwendungen im Mandanten-Namespace ausführen. Durch Anwenden dieser eingeschränkten Rolle von Nutzern und Gruppen sind diese Nutzer nur berechtigt, Anwendungsressourcen im Mandanten-Namespace zu ändern. Sie sind nicht berechtigt, Ressourcen auf Clusterebene oder sensible Sicherheitseinstellungen wie Cloud Service Mesh-Richtlinien zu ändern.

Binärautorisierung

Mit der Binärautorisierung können Sie Richtlinien erzwingen, die Sie für die Container-Images definieren, die in Ihrer GKE-Umgebung bereitgestellt werden. Mit der Binärautorisierung können nur Container-Images bereitgestellt werden, die Ihren definierten Richtlinien entsprechen. Die Bereitstellung anderer Container-Images wird nicht zugelassen.

In dieser Referenzarchitektur ist die Binärautorisierung mit der Standardkonfiguration aktiviert. Informationen zum Prüfen der Standardkonfiguration der Binärautorisierung finden Sie unter YAML-Richtliniendatei exportieren.

Weitere Informationen zum Konfigurieren von Richtlinien finden Sie in den folgenden spezifischen Anleitungen:

Organisationsübergreifende Attestierungsprüfung

Mit der Binärautorisierung können Sie Attestierungen prüfen, die von einem Drittanbieter-Signer generiert wurden. In einem Anwendungsfall für regionenübergreifendes föderiertes Lernen können Sie beispielsweise Attestierungen überprüfen, die von einer anderen Teilnehmerorganisation erstellt wurden.

So prüfen Sie die Attestierungen, die ein Drittanbieter erstellt hat:

  1. Sie erhalten die öffentlichen Schlüssel, die der Drittanbieter zum Erstellen der Attestierungen verwendet hat, die Sie prüfen müssen.
  2. Erstellen Sie die Attestierer, um die Attestierungen zu prüfen.
  3. Fügen Sie den von Ihnen erstellten Attestierern die öffentlichen Schlüssel hinzu, die Sie vom Drittanbieter erhalten haben.

Weitere Informationen zum Erstellen von Attestierern finden Sie in den folgenden spezifischen Anleitungen:

GKE-Compliance-Dashboard

Das GKE-Compliance-Dashboard bietet umsetzbare Informationen zur Verbesserung Ihres Sicherheitsstatus und hilft Ihnen, die Compliance-Berichterstellung für Branchenstandards und -standards zu automatisieren. Sie können GKE-Cluster registrieren, um automatisierte Compliance-Berichte zu aktivieren.

Weitere Informationen finden Sie unter GKE-Compliance-Dashboard.

Sicherheitsaspekte für föderiertes Lernen

Trotz des strengen Datenfreigabemodells ist das föderierte Lernen nicht von Natur aus sicher vor allen gezielten Angriffen. Sie sollten diese Risiken berücksichtigen, wenn Sie eine der in diesem Dokument beschriebenen Architekturen bereitstellen. Es besteht auch das Risiko unbeabsichtigter Informationslecks zu ML-Modellen oder Modelltrainingsdaten. Ein Angreifer könnte beispielsweise absichtlich das globale ML-Modell oder die Runden des föderierten Lernverfahrens manipulieren oder einen Zeitangriff (eine Art von Nebenkanalangriff) ausführen. um Informationen über die Größe der Trainings-Datasets zu sammeln.

Im Folgenden sind die häufigsten Bedrohungen für eine Implementierung föderierten Lernens aufgeführt:

  • Absichtliche oder unabsichtliche Speicherung von Trainingsdaten. Ihre Implementierung föderierten Lernens oder ein Angreifer speichert Daten möglicherweise absichtlich oder unabsichtlich auf eine Weise, die es schwierig macht, damit zu arbeiten. Ein Angreifer kann möglicherweise durch Reverse Engineering der gespeicherten Daten Informationen zum globalen ML-Modell oder zu früheren Runden des föderierten Lernens erfassen ermitteln.
  • Informationen aus Aktualisierungen des globalen ML-Modells extrahieren. Während des föderierten Lernens kann ein Angreifer Reverse Engineering auf die Aktualisierungen des globalen ML-Modells anwenden, die der Föderationsinhaber von Teilnehmerorganisationen und -geräten erfasst.
  • Der Föderationsinhaber kann Runden manipulieren. Ein manipulierter Föderationsinhaber kann einen böswilligen Silo steuern und eine föderierte Lernrunde starten. Am Ende der Runde kann der manipulierte Föderationsinhaber möglicherweise Informationen zu den Aktualisierungen erfassen, die er von legitimen Teilnehmerorganisationen und Geräten erfasst, indem er diese Aktualisierungen mit denen vergleicht, die der schädliche Silo erstellt hat.
  • Teilnehmerorganisationen und -geräte können das globale ML-Modell manipulieren. Während des föderierten Lernens kann ein Angreifer versuchen, die Leistung, die Qualität oder die Integrität des globalen ML-Modells böswillig zu beeinträchtigen, indem er schädliche oder nachteilige Aktualisierungen erzeugt.

Wir empfehlen die folgenden Best Practices, um die Auswirkungen der in diesem Abschnitt beschriebenen Bedrohungen zu mindern:

  • Stimmen Sie das Modell ab, um die Speicherung von Trainingsdaten auf ein Minimum zu reduzieren.
  • Implementieren von Datenschutzmechanismen.
  • Prüfen Sie regelmäßig das globale ML-Modell, die ML-Modelle, die Sie freigeben möchten, die Trainingsdaten und die Infrastruktur, die Sie implementiert haben, um Ihre föderierten Lernziele zu erreichen.
  • Implementieren eines sicheren Aggregationsalgorithmus, um die Trainingsergebnisse zu verarbeiten, die von den Teilnehmerorganisationen erstellt werden.
  • Datenverschlüsselungsschlüssel mit einer Public-Key-Infrastruktur sicher generieren und verteilen.
  • Infrastruktur auf einer Confidential Computing-Plattform bereitstellen.

Föderationsinhaber müssen außerdem die folgenden zusätzlichen Schritte ausführen:

  • Identität jeder Teilnehmerorganisation und die Integrität jedes Silos bei siloübergreifenden Architekturen sowie die Identität und Integrität jedes Geräts bei geräteübergreifenden Architekturen prüfen.
  • Umfang der Updates für das globale ML-Modell beschränken, die Teilnehmerorganisationen und Geräte erstellen können.

Zuverlässigkeit

In diesem Abschnitt werden Designfaktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie eine der Referenzarchitekturen in diesem Dokument verwenden, um eine Plattform zum föderierten Lernen in Google Cloud zu entwerfen und zu erstellen.

Beim Entwerfen Ihrer Architektur für föderiertes Lernen in Google Cloud empfehlen wir, dass Sie die Anleitung in diesem Abschnitt befolgen, um die Verfügbarkeit und Skalierbarkeit der Arbeitslast zu verbessern und Ihre Architektur widerstandsfähiger gegenüber Ausfällen und Notfällen zu machen.

GKE: GKE unterstützt verschiedene Clustertypen, die Sie an die Verfügbarkeitsanforderungen Ihrer Arbeitslasten und an Ihr Budget anpassen können. Sie können beispielsweise regionale Cluster erstellen, die die Steuerungsebene und die Knoten auf mehrere Zonen innerhalb einer Region verteilen, oder zonale Cluster, die die Steuerungsebene und die Knoten in einer einzigen Zone haben. Sowohl silo- als auch geräteübergreifende Referenzarchitekturen basieren auf regionalen GKE-Clustern. Weitere Informationen zu den Aspekten, die beim Erstellen von GKE-Clustern zu berücksichtigen sind, finden Sie unter Clusterkonfigurationsoptionen.

Je nach Clustertyp und Verteilung der Steuerungsebene und der Clusterknoten auf Regionen und Zonen bietet GKE verschiedene Funktionen zur Notfallwiederherstellung, um Ihre Arbeitslasten vor zonalen und regionalen Ausfällen zu schützen. Weitere Informationen zu den Funktionen zur Notfallwiederherstellung von GKE finden Sie unter Architektur der Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur: Google Kubernetes Engine.

Google Cloud Load Balancing: GKE unterstützt mehrere Möglichkeiten für das Load-Balancing von Traffic zu Ihren Arbeitslasten. Mit den GKE-Implementierungen der Kubernetes Gateway und Kubernetes Service APIs können Sie Cloud Load Balancing automatisch bereitstellen und konfigurieren, um die in Ihren GKE-Clustern ausgeführten Arbeitslasten sicher und zuverlässig verfügbar zu machen.

In diesen Referenzarchitekturen wird der gesamte eingehende und ausgehende Traffic über Cloud Service Mesh-Gateways geleitet. Mit diesen Gateways können Sie den Traffic innerhalb und außerhalb Ihrer GKE-Cluster genau steuern.

Zuverlässigkeitsherausforderungen für geräteübergreifendes föderiertes Lernen

Beim geräteübergreifenden föderierten Lernen gibt es eine Reihe von Zuverlässigkeitsherausforderungen, die bei siloübergreifenden Szenarien nicht auftreten. Dazu gehören die folgenden:

  • Unzuverlässige oder unregelmäßige Geräteverbindung
  • Begrenzter Gerätespeicher
  • Begrenzte Rechen- und Arbeitsspeicherressourcen

Eine unzuverlässige Verbindung kann zu Problemen wie den folgenden führen:

  • Veraltete Aktualisierungen und Modellabweichungen: Wenn Geräte mit unregelmäßigen Verbindungen auftreten, können ihre lokalen Modellaktualisierungen veraltet sein und veraltete Informationen im Vergleich zum aktuellen Status des globalen Modells darstellen. Das Zusammenfassen veralteter Aktualisierungen kann zu Modellabweichungen führen, bei denen das globale Modell aufgrund von Inkonsistenzen im Trainingsprozess von der optimalen Lösung abweicht.
  • Unausgeglichene Beiträge und verzerrte Modelle: Eine periodische Kommunikation kann zu einer ungleichmäßigen Verteilung der Beiträge der beteiligten Geräte führen. Geräte mit schlechter Verbindung können weniger Updates bereitstellen, was zu einer unausgeglichenen Darstellung der zugrunde liegenden Datenverteilung führt. Dieses Ungleichgewicht kann das globale Modell auf die Daten von Geräten mit zuverlässigeren Verbindungen ausrichten.
  • Höherer Kommunikationsaufwand und höherer Energieverbrauch: Eine zeitweilige Kommunikation kann zu einem höheren Kommunikationsaufwand führen, da Geräte verloren gegangene oder beschädigte Updates möglicherweise noch einmal senden müssen. Dieses Problem kann auch den Energieverbrauch auf Geräten erhöhen, insbesondere bei Geräten mit begrenzter Akkulaufzeit, da sie möglicherweise über längere Zeiträume aktive Verbindungen aufrechterhalten müssen, um eine erfolgreiche Übertragung von Updates zu gewährleisten.

Die Referenzarchitekturen in diesem Dokument können mit dem FCP verwendet werden, um einige der Auswirkungen einer vorübergehenden Kommunikation zu minimieren.

Eine Systemarchitektur, die das FCP-Protokoll ausführt, kann so konzipiert werden, dass sie die folgenden Anforderungen erfüllt:

  • Runden mit langer Ausführungszeit verarbeiten
  • Spekulative Ausführung aktivieren. Runden können gestartet werden, bevor die erforderliche Anzahl von Clients zusammengestellt wird, in der Erwartung, dass mehr Prüfungen bald eingehen.
  • Sie können den Geräten die Wahl ihrer Aufgaben ermöglichen. Auf diese Weise können Features wie die Probenahme ohne Ersatz ermöglicht werden. Dabei handelt es sich um eine Stichprobenstrategie, bei der jede Stichprobeneinheit einer Population nur eine einzige Wahrscheinlichkeit hat. Dieser Ansatz hilft, unausgeglichene Beiträge und verzerrte Modelle zu vermeiden
  • Erweiterbar für Anonymisierungstechniken wie Differential Privacy (DP) und Trusted Aggregation (TAG).

Die folgenden Methoden können helfen, die Beschränkung des Gerätespeichers und der Rechenkapazitäten zu verringern:

  • Maximale Kapazität für die Berechnung des föderierten Lernens ermitteln
  • Ermitteln, wie viele Daten zu einem bestimmten Zeitpunkt gespeichert werden können
  • Den clientseitigen Code für föderiertes Lernen so entwerfen, dass er mit dem verfügbaren Rechen- und RAM-Speicher ausgeführt wird, der auf den Clients verfügbar ist
  • Auswirkungen von Speicherplatzmangel verstehen und einen Prozess zur Verwaltung dieser Auswirkungen implementieren

Kostenoptimierung

In diesem Abschnitt finden Sie eine Anleitung zum Optimieren der Kosten für das Erstellen und Ausführen der Plattform für föderiertes Lernen in Google Cloud, die Sie mithilfe dieser Referenzarchitektur einrichten. Diese Anleitung gilt für beide Architekturen, die in diesem Dokument beschrieben werden.

Wenn Sie Arbeitslasten in GKE ausführen, können Sie Ihre Umgebung kosteneffizienter gestalten, indem Sie Ihre Cluster gemäß den Ressourcenanforderungen Ihrer Arbeitslasten bereitstellen und konfigurieren. Außerdem werden Funktionen aktiviert, die Ihre Cluster und Clusterknoten dynamisch neu konfigurieren, z. B. die automatische Skalierung von Clusterknoten und Pods sowie die Größenanpassung Ihrer Cluster.

Weitere Informationen zur Kostenoptimierung Ihrer GKE-Umgebungen finden Sie unter Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE.

Operative Effizienz

In diesem Abschnitt werden die Faktoren beschrieben, die Sie zur Optimierung der Effizienz berücksichtigen sollten, wenn Sie diese Referenzarchitektur zum Erstellen und Ausführen einer föderierten Lernplattform in Google Cloud verwenden. Diese Anleitung gilt für beide Architekturen, die in diesem Dokument beschrieben werden.

Um die Automatisierung und das Monitoring Ihrer Architektur für föderiertes Lernen zu verbessern, empfehlen wir Ihnen, MLOps-Prinzipien zu übernehmen. Dies sind DevOps-Prinzipien im Kontext von Systemen für maschinelles Lernen. MLOps zu praktizieren bedeutet, auf Automatisierung und Überwachung zu setzen, und zwar in allen Phasen der ML-Systemkonfiguration wie Integration, Testen, Freigabe, Bereitstellung und Infrastrukturverwaltung. Weitere Informationen zu MLOps finden Sie unter MLOps: Continuous Delivery und Pipelines zur Automatisierung im maschinellen Lernen.

Leistungsoptimierung

In diesem Abschnitt werden die Faktoren beschrieben, die Sie zur Optimierung der Leistung Ihrer Arbeitslasten berücksichtigen sollten, wenn Sie diese Referenzarchitektur zum Erstellen und Ausführen einer Plattform zum föderierten Lernen in Google Cloud verwenden. Diese Anleitung gilt für beide Architekturen, die in diesem Dokument beschrieben werden.

GKE unterstützt mehrere Features, mit denen Sie die Größe und Skalierung Ihrer GKE-Umgebung automatisch und manuell anpassen können, um die Anforderungen Ihrer Arbeitslasten zu erfüllen. Außerdem können Sie eine Überdimensionierung von Ressourcen vermeiden. Sie können beispielsweise Recommender verwenden, um Statistiken und Empfehlungen zur Optimierung Ihrer GKE-Ressourcennutzung zu generieren.

Wenn Sie über die Skalierung Ihrer GKE-Umgebung nachdenken, empfehlen wir Ihnen, kurze, mittelfristige und langfristige Pläne zu entwerfen, wie Sie Ihre Umgebungen und Arbeitslasten skalieren möchten. Wie möchten Sie beispielsweise Ihren GKE-Fußabdruck in einigen Wochen, Monaten und Jahren erweitern? Mit einem verfügbaren Plan können Sie die von GKE bereitgestellten Skalierbarkeitsfunktionen optimal nutzen, Ihre GKE-Umgebungen optimieren und Kosten senken. Weitere Informationen zur Planung der Skalierbarkeit von Clustern und Arbeitslasten finden Sie unter Skalierbarkeit von GKE.

Um die Leistung Ihrer ML-Arbeitslasten zu erhöhen, können Sie Cloud Tensor Processing Units (Cloud TPUs) verwenden. Dies sind von Google entwickelte KI-Beschleuniger, die für Training und Inferenz von großen KI-Modellen optimiert sind.

Bereitstellung

Informationen zum Bereitstellen der in diesem Dokument beschriebenen silo- und geräteübergreifenden Referenzarchitekturen finden Sie im GitHub-Repository Föderiertes Lernen in Google Cloud.

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: