Der FC-Server (Federated Compute) ist Teil des föderierten Lernens, das von der On-Device-Personalisierung (On-Device Personalization, ODP) angeboten wird. In diesem Dokument werden der Federated Compute Server (FC-Server), seine Komponenten und die verwendete Technologie vorgestellt. Das Dokument bietet einen allgemeinen Überblick über die Architektur und geht dann auf die einzelnen Komponenten ein. Außerdem wird erläutert, wie die Komponenten zusammenarbeiten, um eine föderierte Lernumgebung bereitzustellen, und es werden Strategien für die Skalierung und das Sharding von Arbeitslasten vorgestellt.
Ablauf des Trainings
Das Training besteht aus Datenflüssen zwischen dem FC-Client und dem FC-Server. Der FC-Client ist ein zentrales Android-Modul, das ML-Modelle auf dem Gerät trainiert und mit dem FC-Server interagiert. Der FC-Server verarbeitet und aggregiert die Ergebnisse des FC-Clients sicher in einer Trusted Execution Environment (TEE).
Die Schulung besteht aus den folgenden Schritten:
- Der FC-Client auf dem Gerät lädt einen öffentlichen Verschlüsselungsschlüssel von den Schlüsseldiensten herunter.
- Der FC-Client meldet sich beim FC-Server an und erhält eine Trainingsaufgabe.
- Der FC-Client lädt einen Trainingsplan sowie die neueste Version des Modells (Version N) herunter.
- Der FC-Client trainiert anhand der lokalen Daten und des Plans.
- Der FC-Client verschlüsselt die Beiträge dieses Geräts mit dem öffentlichen Schlüssel, der in Schritt 0 abgerufen wurde, und lädt sie auf den FC-Server hoch.
- Der FC-Client benachrichtigt den FC-Server, dass das Training abgeschlossen ist.
- Der FC-Server wartet, bis genügend Clients ihre Beiträge gesendet haben.
- Eine Aggregationsrunde wird ausgelöst.
- Verschlüsselte Beiträge werden vom Aggregator in eine vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) geladen.
- Der Aggregator attestiert sich gemäß der RFC 9334 Remote ATtestation procedureS (RATS) Architecture des NIST gegenüber den Koordinatoren. Nach erfolgreicher Attestierung gewähren die Schlüsseldienste ihm die Entschlüsselungsschlüssel. Diese Schlüssel können in einem Shamir-Secret-Sharing-Schema auf mehrere Schlüsselanbieter aufgeteilt werden.
- Der Aggregator führt eine geräteübergreifende Aggregation durch, schneidet und fügt Rauschen gemäß den entsprechenden Differential Privacy-Mechanismen (DP) hinzu und gibt die Ergebnisse mit Rauschen aus.
- Der Aggregator löst den Modell-Updater aus.
- Der Modell-Updater lädt den aggregierten Beitrag und wendet ihn auf Modellversion N an, um Modellversion N + 1 zu erstellen. Das neue Modell wird in den Modellspeicher geschoben.
Der FC-Server kann auf allen Cloud-Diensten bereitgestellt werden, die TEEs und zugehörige Sicherheitsfunktionen unterstützen. Wir prüfen derzeit Anbieter öffentlicher Clouds und die zugrunde liegenden Technologien. Im folgenden Abschnitt wird jedoch eine Beispielimplementierung in Google Cloud mit Confidential Space vorgestellt.
Gesamtarchitektur
Auf dem FC-Server sind die folgenden Komponenten in Google Cloud bereitgestellt:
| Komponente | Beschreibung |
| Aufgabenverwaltungsdienst | Ein Webdienst zum Verwalten der Trainingsaufgabe. Partner sollten die Task Management API verwenden, um eine Trainingsaufgabe zu erstellen, alle vorhandenen Trainingsaufgaben aufzulisten, eine Aufgabe abzusagen und alle Trainingsstatus abzurufen. |
| Dienst zur Aufgabenzuweisung | Ein HTTPS-basierter Webdienst, bei dem sich die Clientgeräte regelmäßig anmelden, um Trainingsaufgaben abzurufen und den Trainingsstatus zu melden. |
| Dienstleister | Ein Hintergrunddienst, der in Confidential Space ausgeführt wird. Es werden von ODP erstellte Arbeitslasten ausgeführt. Sie muss für Koordinatoren attestiert werden, die den Zugriff auf die Entschlüsselungsschlüssel steuern. Nur erfolgreich attestierte Dienstleister können von Clientgeräten eingereichte Beiträge entschlüsseln und geräteübergreifend zusammenführen. |
| Model Updater | Ein Hintergrunddienst, der in Confidential Space ausgeführt wird und die aggregierten Farbverläufe auf das Modell anwendet. |
Komponentendetails
In den folgenden Abschnitten wird die allgemeine Architektur genauer beschrieben:
Aufgabenverwaltungsdienst
Der Task Management Service besteht aus zwei Unterkomponenten: dem Task Management Web Service und dem Task Scheduler Service, die beide in GKE bereitgestellt werden.
Aufgabenverwaltung
Dies ist eine Reihe von Frontend-Webdiensten, die HTTPS-Anfragen entgegennehmen und Aufgaben in der Aufgabendatenbank erstellen oder abrufen.
Task Scheduler
Ein Hintergrunddienst, der die Aufgabendatenbank kontinuierlich scannt. Sie verwaltet den Trainingsablauf, z. B. das Erstellen neuer Trainingsrunden und ‑iterationen.
Aufgabendatenbank
Eine ANSI-SQL-kompatible Datenbank, in der die Informationen zu Aufgabe, Iteration und Zuweisung gespeichert werden. In dieser Implementierung wird Google Cloud Spanner als zugrunde liegender Datenbankdienst verwendet.
Dienst zur Aufgabenzuweisung
Der Task Assignment Service ist ein Frontend-Webdienst, der in GKE gehostet wird. Er nimmt Anfragen von FC-Clients entgegen und verteilt gegebenenfalls Trainingsaufgaben.
Die Aufgabendatenbank hier ist dieselbe Datenbankinstanz wie die Aufgabendatenbank im Task Management Service.
Aggregator-Dienst
Aggregator und Modellaktualisierer
Der Aggregator und der Modell-Updater sind ähnlich. Das sind Hintergrunddienste, die Daten sicher in Confidential Space verarbeiten. Die Kommunikation zwischen den Offlinejobs erfolgt über PubSub.
Gradienten, aggregierte Gradienten, Modell und Plan
- Ein Gradientenspeicher für (verschlüsselte) Gradienten, die vom Clientgerät hochgeladen wurden.
- Ein aggregierter Gradientenspeicher für aggregierte, zugeschnittene und verrauschte Gradienten.
- Speicherort für Modelle und Pläne für Trainingspläne, Modelle und Gewichte.
Collector
Der Collector ist ein Hintergrunddienst, der die Einreichungen von Clientgeräten während einer Trainingsrunde regelmäßig zählt. Er benachrichtigt den Aggregator, die Aggregation zu starten, sobald genügend Einreichungen vorliegen.
Diensthosts
Alle Dienste, die keinen Zugriff auf vertrauliche Daten haben, werden in GKE gehostet.
Alle Dienste, die sensible Daten enthalten können, werden in Confidential Space gehostet.
Alle vertraulichen Daten werden mit Verschlüsselungsschlüsseln verschlüsselt, die von mehreren Parteien verwalteten Schlüsseldiensten gehören. Nur erfolgreich attestierter, von ODP verfasster Open-Source-Code, der in legitimen, für vertrauliches Computing aktivierten Versionen von Confidential Space ausgeführt wird, kann auf die Entschlüsselungsschlüssel zugreifen.
In einer Diensteinheit sieht die Rechenressource so aus:
Skalierbarkeit
Bei der zuvor beschriebenen Infrastruktur liegt der Schwerpunkt auf einer Serviceeinheit.
Eine Serviceeinheit verwendet eine Cloud Spanner-Instanz. Weitere Informationen zu wichtigen Einschränkungen finden Sie unter Spanner-Kontingente und ‑Limits.
Jede Komponente dieser Architektur kann unabhängig skaliert werden. Dazu wird die Kapazität entweder innerhalb des vertraulichen Bereichs oder innerhalb des GKE-Clusters mithilfe von Standard-Skalierungsmechanismen skaliert. Die Verarbeitungskapazität lässt sich effektiv durch Hinzufügen weiterer Instanzen von folgenden Elementen erhöhen:
- Webdienst für die Aufgabenzuweisung
- Webdienst zur Aufgabenverwaltung
- Aggregatorinstanzen
- Model Updater-Instanzen
Robustheit
Die Ausfallsicherheit eines FC-Servers wird durch die Notfallwiederherstellung mit repliziertem Speicher verwaltet. Wenn Sie die Notfallwiederherstellung nutzen möchten, sollten Sie die regionenübergreifende Datenreplikation aktivieren. So wird sichergestellt, dass der Dienst bei einer Katastrophe (z. B. einem Wetterereignis, das ein Rechenzentrum beeinträchtigt) an der letzten Trainingsrunde anknüpft.
Spanner
Bei der Standardimplementierung des FC-Servers wird Google Cloud Spanner als Datenbank verwendet, um den Aufgabenstatus zu speichern, der zum Steuern des Trainingsablaufs verwendet wird. Sie sollten die Vor- und Nachteile von Konsistenz und Verfügbarkeit anhand Ihrer Geschäftsanforderungen bewerten, bevor Sie eine Konfiguration mit mehreren Regionen auswählen.
In keiner Spanner-Instanz werden Nutzerdaten oder ihre Ableitungen, weder roh noch verschlüsselt, gespeichert. Sie können eine der von Spanner angebotenen Funktionen für die Notfallwiederherstellung verwenden.
Spanner zeichnet den Änderungsverlauf auf. Der Aggregator und der Modell-Updater speichern die Daten pro Trainingsrunde. Das Ergebnis jeder Runde wird separat gespeichert, ohne dass sich die Daten überschreiben. Daher kann der Dienst im Katastrophenfall ab der letzten Trainingsrunde fortgesetzt werden.
Google Cloud Storage
Bei der Standardimplementierung des FC-Servers werden Blob-Daten wie Modelle, Trainingspläne und verschlüsselte Gerätebeiträge in Google Cloud Storage gespeichert.
Das Design umfasst drei GCS-Instanzen:
- Gerätebeiträge: Verschlüsselte Gerätebeiträge, die von Geräten hochgeladen wurden.
- Modelle: Trainingspläne, Modelle und ihre Gewichte.
- Aggregierte Gradienten: Die vom Aggregator generierten aggregierten Gradienten.
Die in GCS gespeicherten Daten sind entweder:
- Vom Entwickler bereitgestellte Daten, z. B. ein Trainingsplan ODER
- Potenziell personenbezogene Daten, da sie aus Nutzersignalen abgeleitet werden (geschützt durch eine Verschlüsselung mit mehreren Koordinatoren), z. B. von Geräten hochgeladene und aggregierte Gradienten ODER
- Nicht personenbezogene Daten, die aus Nutzersignalen abgeleitet wurden, aber nach Anwendung der Differential Privacy-Technologie, z. B. Modellgewichte.
Sie sollten die Kompromisse zwischen Konsistenz und Verfügbarkeit bewerten und die richtigen Funktionen für die Verfügbarkeit und Langlebigkeit von GCS-Daten auswählen. Sie sollten Ihre eigenen Aufbewahrungsrichtlinien angeben.
Replikation und Sicherungen
Neben den von Google Cloud bereitgestellten Datenreplizierungsmechanismen können Sie die Daten auch regelmäßig in Spanner und GCS sichern. Sie können beispielsweise cloudübergreifende Replikationsdienste und ‑angebote verwenden. ODP stellt kein Beispiel bereit, da diese Konfigurationen stark von den Geschäftsanforderungen abhängen. Das aktuelle Design berücksichtigt die potenziellen Anforderungen von Entwicklern an solche Replizierungen und Sicherungen. Daher ist es mit Replikations- und Sicherungsdiensten und ‑produkten von Drittanbietern kompatibel.