Der Federated Compute (FC)-Server ist Teil des föderierten Lernens, das von der On-Device-Personalisierung (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 behandelt dann die einzelnen Komponenten im Detail. Außerdem wird erläutert, wie die Komponenten zusammen eine Umgebung für föderiertes Lernen bilden. Außerdem werden Strategien zur Skalierung und Fragmentierung 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 Android-Kernmodul, 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).
Das Training umfasst die folgenden Schritte:
- Der FC-Client auf dem Gerät lädt einen öffentlichen Verschlüsselungsschlüssel von den Key Services herunter.
- Der FC-Client meldet sich beim FC-Server an und erhält eine Trainingsaufgabe.
- Der FC-Client lädt einen Trainingsplan und die neueste Version des Modells, Version N, herunter.
- Der FC-Client nutzt die lokalen Daten und den Plan zum Trainieren.
- 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 bescheinigt sich selbst gegenüber den Koordinatoren gemäß der RATS-Architektur (Remote ATtestation Prozedur – RFC 9334) des NIST. 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 Model Updater lädt den aggregierten Beitrag und wendet ihn auf die Modellversion N an, um die Modellversion N+1 zu erstellen. Das neue Modell wird in den Modellspeicher gepusht.
Der FC-Server kann auf jedem Cloud-Dienst bereitgestellt werden, der TEEs und zugehörige Sicherheitsfunktionen unterstützt. Wir prüfen Anbieter öffentlicher Clouds und die zugrunde liegenden 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 abzusagen und alle Trainingsstatus abzurufen. |
| Aufgabenzuweisungsdienst | 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. Es muss gegenüber Koordinatoren attestiert werden, die den Zugriff auf die Entschlüsselungsschlüssel schützen. 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 Gradienten auf das Modell anwendet. |
Komponentendetails
In den folgenden Abschnitten wird die allgemeine Architektur genauer beschrieben:
Aufgabenverwaltungsdienst
Der Taskverwaltungsdienst besteht aus zwei Unterkomponenten: dem Task Management Web Service und dem Task Scheduler Service, die beide in GKE bereitgestellt werden.
Aufgabenverwaltung
Hierbei handelt es sich um eine Reihe von Front-End-Webdiensten, die HTTPS-Anfragen annehmen und Aufgaben aus der Aufgabendatenbank erstellen oder daraus abrufen.
Task Scheduler
Ein Hintergrunddienst, der die Aufgabendatenbank kontinuierlich scannt. Es verwaltet den Trainingsablauf und erstellt beispielsweise neue Trainingsrunden und Iterationen.
Aufgabendatenbank
Eine ANSI-SQL-kompatible Datenbank, in der die Informationen zu Aufgaben, Iterationen und Aufgaben gespeichert werden. In dieser Implementierung wird Google Cloud Spanner als zugrunde liegender Datenbankdienst verwendet.
Dienst zur Aufgabenzuweisung
Der Aufgabenzuweisungsdienst ist ein Front-End-Webdienst, der in GKE gehostet wird. Er nimmt Anfragen von den FC-Clients an 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 auf sichere Weise in Confidential Space verarbeiten. Die Kommunikation zwischen den Offlinejobs erfolgt über Pub/Sub.
Gradienten, aggregierte Gradienten, Modell und Plan
- Ein Speicher für (verschlüsselte) Farbverläufe, die vom Clientgerät hochgeladen wurden.
- Ein aggregierter Gradientenspeicher für aggregierte, abgeschnittene und verrauschte Gradienten.
- Ein Modell- und Planungsspeicher für die 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 verfügbar sind.
Diensthosts
Alle Dienste, die keinen Zugriff auf vertrauliche Daten haben, werden in GKE gehostet.
Alle Dienste, die auf vertrauliche Daten zugreifen können, werden in Confidential Space gehostet.
Alle sensiblen Daten werden mit Verschlüsselungsschlüsseln verschlüsselt, die von Key Services verwaltet werden, die mehreren Parteien 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 im vertraulichen Bereich oder im GKE-Cluster mithilfe von Standard-Skalierungsmechanismen skaliert. Die Verarbeitungskapazität kann effektiv durch Hinzufügen weiterer Instanzen von folgenden Elementen erhöht werden:
- 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 an der Notfallwiederherstellung interessiert sind, sollten Sie die regionsübergreifende Datenreplikation aktivieren. Dadurch wird sichergestellt, dass der Dienst im Falle einer Katastrophe (z. B. ein Wetterereignis mit Störungen in einem Rechenzentrum) nach der letzten Schulungsrunde fortgesetzt wird.
Spanner
Bei der Standardimplementierung des FC-Servers wird Google Cloud Spanner als Datenbank verwendet, um den Aufgabenstatus zu speichern, der zum Steuern des Trainingsflusses 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 die verfügbaren Funktionen zur Notfallwiederherstellung von Spanner nutzen.
Spanner zeichnet den Änderungsverlauf auf. Der Aggregator und der Model Updater speichern die Daten pro Trainingsrunde und das Ergebnis jeder Runde wird separat gespeichert, ohne sich gegenseitig zu überschreiben. Daher kann der Dienst im Katastrophenfall ab der letzten Trainingsrunde fortgesetzt werden.
Google Cloud Storage
Die Standardimplementierung des FC-Servers verwendet Google Cloud Storage, um Blob-Daten wie Modelle, Trainingspläne und verschlüsselte Gerätebeiträge zu speichern.
Im Design gibt es drei GCS-Instanzen:
- Gerätebeiträge: Verschlüsselte Gerätebeiträge, die von Geräten hochgeladen wurden.
- Modelle: Trainingspläne, Modelle und ihre Gewichtungen.
- 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 Vor- und Nachteile von Konsistenz und Verfügbarkeit prüfen und die passenden Features zur Verfügbarkeit und Langlebigkeit von GCS-Daten auswählen. Sie sollten Ihre eigenen Aufbewahrungsrichtlinien angeben.
Replikation und Sicherungen
Neben den Datenreplikationsmechanismen von Google Cloud können Sie die Daten auch regelmäßig in Spanner und GCS sichern. Sie können beispielsweise cloudübergreifende Replikationsdienste und -angebote verwenden. ODP liefert keine Stichproben, da diese Konfigurationen stark von den Geschäftsanforderungen abhängen. Das aktuelle Design berücksichtigt die potenziellen Anforderungen der Entwickler an solche Replikationen und Sicherungen. Daher ist es mit Replikations- und Sicherungsdiensten und ‑produkten von Drittanbietern kompatibel.