Der Federated Compute (FC)-Server ist Teil des föderierten Lernens, das von Personalisierung auf dem Gerät (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 detailliert auf jede Komponente ein. Außerdem wird erläutert, wie die Komponenten zusammenarbeiten, um eine Umgebung für föderiertes Lernen zu schaffen, und es werden Strategien für die Skalierung und das Sharding von Arbeitslasten vorgestellt.
Trainingsablauf
Das Training besteht aus Datenflüssen zwischen dem FC-Client und dem FC-Server. Der FC-Client ist ein wichtiges 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 vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE).
Das Training 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 und erhält eine Trainingsaufgabe.
- Der FC-Client lädt einen Trainingsplan sowie die aktuelle Version des Modells (Version N) herunter.
- Der FC-Client wird mit den lokalen Daten und dem Plan trainiert.
- Der FC-Client verschlüsselt die Beiträge dieses Geräts mit dem in Schritt 0 abgerufenen öffentlichen Schlüssel 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 authentifiziert sich gemäß der RATS-Architektur (Remote ATtestation procedureS) von NIST (RFC 9334) bei den Koordinatoren. Nach erfolgreicher Attestierung gewähren die Key Services 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 geräteübergreifende Aggregationen durch, schneidet und fügt Rauschen gemäß den entsprechenden Differential Privacy-Mechanismen (DP) ein und gibt die verrauschten Ergebnisse aus.
- Der Aggregator löst den Model Updater aus.
- Der Model 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 übertragen.
Der FC-Server kann auf jedem Cloud-Dienst bereitgestellt werden, der TEEs und zugehörige Sicherheitsfunktionen unterstützt. Wir prüfen derzeit Anbieter von öffentlichen Clouds und zugrunde liegende Technologien. Im folgenden Abschnitt wird jedoch eine Google Cloud-Beispielimplementierung 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 abzubrechen und alle Trainingsstatus abzurufen. |
| Dienst zur Aufgabenzuweisung | Ein HTTPS-basierter Webdienst, bei dem sich die Clientgeräte regelmäßig melden, um Trainingsaufgaben zu erhalten und den Trainingsstatus zu melden. |
| Dienstleister | Ein Hintergrunddienst, der in Confidential Space ausgeführt wird. Es führt von ODP erstellte Arbeitslasten aus. Sie muss Koordinatoren bestätigen, die den Zugriff auf die Entschlüsselungsschlüssel schützen. Nur erfolgreich bestätigte Aggregatoren können von Clientgeräten eingereichte Beiträge entschlüsseln und geräteübergreifende Aggregationen durchführen. |
| Model Updater | Ein Hintergrunddienst, der in Confidential Space ausgeführt wird und die aggregierten Gradienten auf das Modell anwendet. |
Komponentendetails
In den folgenden Abschnitten wird die allgemeine Architektur genauer beschrieben:
Aufgabenverwaltungsdienst
Der Task Management Service enthält zwei Unterkomponenten: den Task Management Web Service und den 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 Aufgaben-Datenbank kontinuierlich scannt. Sie verwaltet den Trainingsablauf, z. B. durch Erstellen neuer Trainingsrunden und ‑iterationen.
Aufgabendatenbank
Eine ANSI-SQL-kompatible Datenbank, in der die Informationen zu Aufgaben, Iterationen und Zuweisungen 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. Sie nimmt Anfragen von FC-Clients entgegen und verteilt bei Bedarf Trainingsaufgaben.
Die Aufgaben-Datenbank ist dieselbe Datenbankinstanz wie die Aufgaben-Datenbank im Task Management Service.
Aggregationsdienst
Aggregator und Model Updater
Aggregator und Model Updater sind ähnlich. Es handelt sich um Hintergrunddienste, die Daten sicher in Confidential Space verarbeiten. Die Kommunikation zwischen den Offline-Jobs erfolgt über PubSub.
Gradienten, aggregierte Gradienten, Modell und Plan
- Ein Gradientenspeicher für auf Clientgeräten hochgeladene (verschlüsselte) Gradienten.
- Ein aggregierter Gradientenspeicher für aggregierte, gekürzte und mit Rauschen versehene Gradienten.
- Ein Modell und ein Plan zum Speichern der Trainingspläne, Modelle und Gewichte.
Collector
Der Collector ist ein Hintergrunddienst, der die Clientgeräteeinsendungen während einer Trainingsrunde regelmäßig zählt. Sie benachrichtigt den Aggregator, die Aggregation zu starten, sobald genügend Einsendungen verfügbar sind.
Dienst-Hosts
Alle Dienste, die keinen Zugriff auf vertrauliche Informationen haben, werden auf GKE gehostet.
Alle Dienste, die sensible Informationen verarbeiten, werden in Confidential Space gehostet.
Alle vertraulichen Daten werden mit Verschlüsselungsschlüsseln verschlüsselt, die von Key Services verwaltet werden, die mehreren Parteien gehören. Nur erfolgreich bestätigter, von ODP erstellter Open-Source-Code, der in legitimen Versionen von Confidential Space mit aktivierter vertraulichen Datenverarbeitung ausgeführt wird, kann auf die Entschlüsselungsschlüssel zugreifen.
In einer Serviceeinheit sieht die Computeressource so aus:
Skalierbarkeit
Die zuvor beschriebene Infrastruktur konzentriert sich auf eine Serviceeinheit.
Eine Serviceeinheit verwendet eine Cloud Spanner-Instanz. Kontingente und Limits von Cloud Spanner
Jede Komponente dieser Architektur kann unabhängig skaliert werden. Dazu wird die Kapazität entweder im Confidential Space oder im GKE-Cluster mit Standard-Skalierungsmechanismen skaliert. Die Verarbeitungskapazität kann durch Hinzufügen weiterer Instanzen von Folgendem erhöht werden:
- Webdienst für die Aufgabenzuweisung
- Webdienst für die Aufgabenverwaltung
- Aggregator-Instanzen
- Model Updater-Instanzen
Robustheit
Die Ausfallsicherheit eines FC-Servers wird durch die Notfallwiederherstellung mit repliziertem Speicher gewährleistet. Wenn Sie an der Notfallwiederherstellung interessiert sind, sollten Sie die regionenübergreifende Datenreplikation aktivieren. So wird sichergestellt, dass der Dienst nach einer Katastrophe (z. B. einem Wetterereignis, das ein Rechenzentrum unterbricht) mit der letzten Trainingsrunde fortgesetzt wird.
Spanner
In der Standardimplementierung des FC-Servers wird Google Cloud Spanner als Datenbank zum Speichern des Aufgabenstatus verwendet, mit dem der Trainingsablauf gesteuert wird. Sie sollten die Vor- und Nachteile von Konsistenz und Verfügbarkeit entsprechend Ihren geschäftlichen Anforderungen abwägen, bevor Sie eine Konfiguration mit mehreren Regionen auswählen.
In keiner Spanner-Instanz werden Nutzerdaten oder ihre Derivate, weder im Rohformat noch verschlüsselt, gespeichert. Sie können alle von Spanner angebotenen Funktionen zur Notfallwiederherstellung verwenden.
Spanner zeichnet den Änderungsverlauf auf. Im Aggregator und Model Updater werden die Daten pro Trainingsrunde gespeichert. Das Ergebnis jeder Runde wird separat gespeichert, ohne dass die Ergebnisse überschrieben werden. Daher kann der Dienst im Katastrophenfall ab der letzten Trainingsrunde fortgesetzt werden.
Google Cloud Storage
In der Standardimplementierung des FC-Servers wird Google Cloud Storage verwendet, um Blob-Daten wie Modelle, Trainingspläne und verschlüsselte Gerätebeiträge zu speichern.
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 erstellten aggregierten Gradienten.
Die in GCS gespeicherten Daten sind entweder:
- Vom Entwickler bereitgestellte Daten, z. B. ein Trainingsplan ODER
- Potenziell vertrauliche Daten, da sie aus Nutzersignalen abgeleitet werden, die durch die Verschlüsselung mit mehreren Koordinatoren geschützt sind, z. B. auf das Gerät hochgeladene und aggregierte Gradienten. ODER
- Nicht private Daten, die aus Nutzersignalen abgeleitet werden, aber nach der Anwendung von Differential Privacy, z. B. Modellgewichte.
Sie sollten die Kompromisse zwischen Konsistenz und Verfügbarkeit abwägen und die richtigen Funktionen für Datenverfügbarkeit und ‑beständigkeit von GCS auswählen. Sie sollten Ihre eigenen Richtlinien zur Datenaufbewahrung festlegen.
Replikation und Sicherungen
Neben den von Google Cloud bereitgestellten Datenreplikationsmechanismen können Sie die Daten in Spanner und GCS auch regelmäßig 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 Replikationen und Sicherungen. Daher ist sie mit Replikations- und Sicherungsdiensten und ‑produkten von Drittanbietern kompatibel.