Serwer Federated Compute (FC) jest częścią sfederowanego uczenia się oferowanego w ramach personalizacji na urządzeniu (ODP). Celem tego dokumentu jest przedstawienie serwera Federated Compute Server (FC Server), jego komponentów i zastosowanej technologii. Dokument zawiera ogólne omówienie architektury, a potem szczegółowo omawiamy każdy z nich. Omawiamy również, jak komponenty współdziałają, aby zapewnić sfederowane środowisko edukacyjne, oraz przedstawiamy strategie skalowania i fragmentacji zadań.
Przebieg trenowania
Trening składa się z przepływów danych między klientem FC a serwerem FC. Klient FC to podstawowy moduł Androida, który trenuje modele ML na urządzeniu i wchodzi w interakcje z serwerem FC. Serwer FC przetwarza i zbiera wyniki z klienta FC w bezpiecznym zaufanym środowisku wykonawczym (TEE).
Trenowanie obejmuje te etapy:
- Klient FC na urządzeniu pobiera klucz publiczny szyfrowania z usług kluczy.
- Klient FC kontaktuje się z serwerem FC i otrzymuje zadanie trenowania.
- Klient FC pobiera plan treningowy oraz najnowszą wersję modelu (N.
- Klient FC trenuje, korzystając z danych lokalnych i planu.
- Klient FC szyfruje dane przesyłane z tego urządzenia za pomocą klucza publicznego uzyskanego w kroku 0 i przesyła go na serwer FC.
- Klient FC powiadamia serwer FC o ukończeniu trenowania.
- Serwer FC czeka, aż odpowiednia liczba klientów prześle swoje dane.
- Uruchomi się runda agregacji.
- Zaszyfrowane treści są wczytywane przez pośrednika do zaufanego środowiska wykonawczego TEE (Trusted Execution Environment).
- Agregator potwierdza siebie przed koordynatorami zgodnie z architekturą RFC 9334 procedury zdalnego atestu (RATS) określoną przez NIST. Po udanym atestowaniu usługi kluczy przyznają mu klucze odszyfrowywania. Klucze te mogą być rozdzielane między wielu dostawców kluczy w ramach schematu dzielenia tajemnicy Shamira.
- Agregator przeprowadza agregację danych z różnych urządzeń oraz rejestruje klipy i szumy zgodnie z odpowiednimi mechanizmami prywatności różnicowej (DP), a następnie generuje zaszumione wyniki.
- Właściciel witryny uruchamia aktualizator modelu.
- Aktualizator modelu wczytuje zbiorczą wartość i stosuje ją do wersji modelu N, aby utworzyć wersję modelu N + 1. Nowy model jest przesyłany do magazynu modeli.
Serwer FC można wdrożyć w dowolnej usłudze w chmurze, która obsługuje TEE i powiązane funkcje zabezpieczeń. Oceniamy dostawców chmury publicznej i podlegające im technologie, ale na razie w tej sekcji przedstawiamy przykładową implementację Google Cloud z wykorzystaniem Poufnej przestrzeni.
Architektura ogólna
Serwer FC ma te komponenty wdrożone w Google Cloud:
| Składnik | Opis |
| Usługa zarządzania zadaniami | Usługa internetowa służąca do zarządzania zadaniem treningowym. Partnerzy powinni używać interfejsu Task Management API, aby tworzyć zadania szkoleniowe, wyświetlać listę wszystkich istniejących zadań szkoleniowych, anulować zadanie i pobierać stany wszystkich szkoleń. |
| Usługa przypisywania zadań | Usługa internetowa oparta na protokole HTTPS, w której urządzenia klienckie okresowo rejestrują się w celu uzyskania zadań treningowych i zgłaszania stanu trenowania. |
| Właściciel witryny | Usługa działająca w tle w Pokoju poufnym. Działa na nim zadania utworzone przez ODP. Musi ona potwierdzać tożsamość koordynatorów, którzy mają dostęp do kluczy odszyfrowywania. Tylko pośrednicy, którzy przeszli weryfikację, mogą odszyfrowywać dane przesłane przez urządzenia klienta i przeprowadzać agregację danych z różnych urządzeń. |
| Aktualizator modelu | Usługa w tle działająca w Poufnej przestrzeni, która stosuje do modelu zagregowane gradienty. |
Szczegóły komponentu
Tematy w sekcjach poniżej rozszerzają ogólną architekturę o bardziej szczegółowe informacje:
Usługa zarządzania zadaniami
Usługa zarządzania zadaniami zawiera 2 podelementy: usługę internetową zarządzania zadaniami i usługę harmonogramowania zadań, które są wdrażane w GKE.
Zarządzanie zadaniami
To jest zestaw usług internetowych frontendu, które odbierają żądania HTTPS i tworzą zadania w bazie danych zadań lub pobierają z nich zadania.
Harmonogram zadań
Usługa działająca w tle, która stale skanuje bazę danych zadań. Odpowiada on za przebieg szkolenia, na przykład tworzy nowe rundy treningowe i iteracja.
Baza danych zadań
Baza danych zgodna z ANSI SQL, która przechowuje informacje o zadaniach, iteracjach i przypisaniach. W tej implementacji jako bazowa usługa bazy danych używana jest Google Cloud Spanner.
Usługa przypisywania zadań
Usługa Task Assignment to frontendowa usługa internetowa hostowana w GKE. Przyjmuje żądania od klientów FC i w stosownych przypadkach rozdziela zadania szkoleniowe.
Baza danych zadań jest tą samą instancją bazy danych co baza danych zadań w usłudze zarządzania zadaniami.
Usługa agregatora
Agregator i aktualizator modelu
Agregator i Aktualizator modeli są podobne. Są to usługi działające w tle, które bezpiecznie przetwarzają dane w poufnej przestrzeni. Komunikacja między zadaniami offline odbywa się za pomocą Pub/Sub.
Gradienty, zagregowane gradienty, model i plan
- Miejsce na dane gradientów dla przesłanych (zaszyfrowanych) gradientów na urządzeniu klienta.
- Zagregowana pamięć masowa gradientu na potrzeby zagregowanych, przyciętych i zaszumionych gradientów.
- Model i plan miejsca na dane na potrzeby planów trenowania, modeli i wag.
Kolektor
Kolektor to usługa działająca w tle, która okresowo zlicza zgłoszenia urządzeń klienckich podczas rundy szkoleniowej. Powiadomi ona agregatora o rozpoczęciu agregacji, gdy będzie dostępnych wystarczająco dużo zgłoszeń.
Hosty usług
Wszystkie usługi, które nie mają dostępu do informacji poufnych, są hostowane w GKE.
Wszystkie usługi, które mogą dotyczyć informacji poufnych, są hostowane w poufnym miejscu.
Wszystkie dane wrażliwe są szyfrowane przy użyciu kluczy szyfrowania zarządzanych przez usługi kluczy należące do wielu osób. Do kluczy odszyfrowywania mają dostęp tylko autoryzowane, napisane przez ODP wersje open source kodu działające w legalnych wersjach Confidential Space z włączoną obsługą prywatnego przetwarzania danych.
W jednej jednostce usługi zasób obliczeniowy wygląda tak:
Skalowalność
Opisana wcześniej infrastruktura koncentruje się na 1 jednostce usług.
Jedna jednostka usługi korzysta z jednej usługi Cloud Spanner. Więcej informacji o ważnych ograniczeniach znajdziesz w artykule Limity i kwoty dotyczące Spannera.
Każdy element tej architektury można skalować niezależnie. Jest to realizowane przez skalowanie pojemności w przestrzeni poufnej lub w klastrze GKE za pomocą standardowych mechanizmów skalowania. Moc obliczeniową można zwiększyć, dodając więcej instancji:
- Usługa internetowa przypisywania zadań
- Usługa sieciowa Zarządzanie zadaniami
- Instancje agregatorów
- Instancje aktualizatora modelu
Odporność
Odporność serwera FC jest obsługiwana przez odtwarzanie awaryjne przy użyciu replikowanej pamięci masowej. Jeśli interesuje Cię odtwarzanie awaryjne, włącz replikację danych między regionami. Dzięki temu w przypadku katastrofy (np. zdarzenia pogodowego zakłócającego działanie centrum danych) usługa wznowi działanie od ostatniej rundy trenowania.
Spanner
Domyślna implementacja serwera FC korzysta z Google Cloud Spanner jako bazy danych do przechowywania stanu zadania służącego do sterowania przepływem trenowania. Zanim wybierzesz konfigurację na wiele regionów, uwzględnij wady i zalety spójności i dostępności zgodnie ze swoimi potrzebami biznesowymi.
W żadnej instancji Spannera nie są przechowywane żadne dane użytkownika ani jego pochodne (nieprzetworzone ani zaszyfrowane). Możesz korzystać z dostępnych funkcji odtwarzania awaryjnego oferowanych przez Spanner.
Spanner rejestruje historię zmian. Agregator i aktualizator modelu przechowują dane według rundy treningu, a każdy wynik jest przechowywany osobno bez możliwości zastąpienia go innym. Dzięki temu w przypadku katastrofy usługa może wznowić działanie od ostatniej rundy trenowania.
Google Cloud Storage
Domyślna implementacja serwera FC używa Google Cloud Storage do przechowywania danych blob, takich jak modele, plany treningowe i zaszyfrowane dane urządzenia.
W projekcie są 3 instancje GCS:
- Przesłane dane dotyczące urządzeń: zaszyfrowane dane przesłane z urządzeń.
- Modele: plany treningowe, modele i ich wagi.
- Zbiorcze gradienty: zbiorcze gradienty utworzone przez agregator.
Dane przechowywane w GCS są:
- dane dostarczone przez dewelopera, np. plan szkoleniowy LUB
- dane potencjalnie prywatne, ponieważ pochodzą z sygnałów użytkownika (chronionych przez szyfrowanie obsługiwane przez wiele koordynatorów), takich jak gradienty przesłane na urządzenie i zagregowane gradienty;
- Dane nieprywatne, które pochodzą z sygnałów użytkownika, ale zostały opublikowane po zastosowaniu aplikacji związanej z prywatnością różnicową, np. wagi modelu.
Przeanalizuj kompromisy między spójność a dostępnością i wybierz odpowiednie funkcje dostępności i trwałości danych GCS. Należy określić własne zasady przechowywania danych.
replikacji i kopii zapasowych;
Oprócz mechanizmów replikacji danych udostępnianych przez Google Cloud możesz też okresowo tworzyć kopie zapasowe danych w Spanner i GCS. Możesz na przykład korzystać z usług i ofert replikacji w wielu chmurach. ODP nie udostępnia przykładu, ponieważ te konfiguracje są w dużym stopniu zależne od potrzeb biznesowych. Obecna wersja uwzględnia potencjalne potrzeby deweloperów związane z takimi replikacjami i kopiami zapasowymi. Dzięki temu jest zgodny z usługami i produktami do tworzenia kopii zapasowych i replikacji innych firm.