Le serveur de calcul fédéré fait partie de l'apprentissage fédéré proposé par la personnalisation sur l'appareil (ODP). L'objectif de ce document est de présenter le serveur de calcul fédéré (FC Server), ses composants et la technologie utilisée. Le document fournit une vue d'ensemble de l'architecture, puis décrit en détail chaque composant. Elle explique également comment les composants fonctionnent ensemble pour fournir un environnement d'apprentissage fédéré, et propose des stratégies de scaling et de partitionnement des charges de travail.
Flux d'entraînement
L'entraînement consiste en des flux de données entre le client FC et le serveur FC. Le client FC est un module Android de base qui entraîne des modèles de ML sur l'appareil et interagit avec le serveur FC. Le serveur FC traite et agrège de manière sécurisée les résultats du client FC dans un environnement d'exécution sécurisé (TEE).
L'entraînement comprend les étapes suivantes:
- Le client FC de l'appareil télécharge une clé de chiffrement publique à partir des services de clés.
- Le client FC se connecte au serveur FC et reçoit une tâche d'entraînement.
- Le client FC télécharge un plan d'entraînement, ainsi que la dernière version du modèle, la version N.
- Le client FC s'entraîne à l'aide des données locales et du plan.
- Le client FC chiffre les contributions de cet appareil avec la clé publique obtenue à l'étape 0 et les importe sur le serveur FC.
- Le client FC informe le serveur FC que son entraînement est terminé.
- Le serveur FC attend que suffisamment de clients aient envoyé leurs contributions.
- Une agrégation est déclenchée.
- Les contributions chiffrées sont chargées dans un environnement d'exécution sécurisé (TEE) par l'agrégateur.
- L'agrégateur s'atteste auprès des coordinateurs, conformément à l'architecture de la RFC 9334 sur les procédures d'attestation à distance (RATS) du NIST. Une fois l'attestation réussie, les services de clés lui accordent les clés de déchiffrement. Ces clés peuvent être réparties entre plusieurs fournisseurs de clés dans un schéma de partage de secret Shamir.
- L'agrégateur effectue une agrégation inter-appareil, des coupures et des bruits en fonction des mécanismes de confidentialité différentielle (DP) appropriés, et génère les résultats avec bruit.
- L'agrégateur déclenche l'outil de mise à jour du modèle.
- L'outil de mise à jour du modèle charge la contribution agrégée et l'applique à la version N du modèle pour créer la version N+1. Le nouveau modèle est transféré vers l'espace de stockage des modèles.
Le serveur FC peut être déployé sur n'importe quel ou plusieurs services cloud compatibles avec les TEE et les fonctionnalités de sécurité associées. Nous évaluons les fournisseurs de cloud public et les technologies sous-jacentes, mais pour l'instant, la section suivante présente un exemple d'implémentation Google Cloud à l'aide de Confidential Space.
Architecture de haut niveau
Le serveur FC a déployé les composants suivants dans Google Cloud:
| Composant | Description |
| Service de gestion des tâches | Service Web permettant de gérer la tâche d'entraînement. Les partenaires doivent utiliser l'API Task Management pour créer une tâche d'entraînement, lister toutes les tâches d'entraînement existantes, annuler une tâche et récupérer tous les états d'entraînement. |
| Service d'attribution de tâches | Service Web basé sur HTTPS où les appareils clients se connectent régulièrement pour obtenir des tâches d'entraînement et signaler l'état de l'entraînement. |
| Agrégateur | Un service en arrière-plan exécuté dans Confidential Space. Il exécute les charges de travail créées par l'ODP. Il doit attester aux coordinateurs, qui contrôlent l'accès aux clés de déchiffrement. Seuls les agrégateurs attestés peuvent déchiffrer les contributions envoyées par les appareils clients et effectuer une agrégation inter-appareils. |
| Gestionnaire de mise à jour du modèle | Service en arrière-plan exécuté dans Confidential Space qui applique les gradients agrégés au modèle. |
Détails du composant
Les sections suivantes développent l'architecture de haut niveau:
Service de gestion des tâches
Le service de gestion des tâches contient deux sous-composants: le service Web de gestion des tâches et le service de planification des tâches, tous deux déployés sur GKE.
Gestion de tâches
Il s'agit d'un ensemble de services Web frontaux qui reçoivent des requêtes HTTPS et créent ou obtiennent des tâches à partir de la base de données de tâches.
Planificateur de tâches
Service en arrière-plan qui analyse en continu la base de données des tâches. Il gère le flux d'entraînement, par exemple en créant des séries et des itérations d'entraînement.
Base de données des tâches
Base de données conforme à la norme ANSI SQL qui stocke les informations sur la tâche, l'itération et l'attribution. Dans cette implémentation, Google Cloud Spanner est utilisé comme service de base de données sous-jacent.
Service d'attribution de tâches
Le service d'attribution de tâches est un service Web frontend hébergé sur GKE. Il reçoit les requêtes des clients FC et distribue les tâches d'entraînement, le cas échéant.
La base de données de tâches ici est la même instance de base de données que celle de Task Management Service.
Service d'agrégation
Agrégateur et outil de mise à jour du modèle
L'agrégateur et l'outil de mise à jour du modèle sont similaires. Il s'agit de services en arrière-plan qui traitent les données de manière sécurisée dans Confidential Space. La communication entre les jobs hors connexion s'effectue via PubSub.
Gradients, gradients agrégés, modèle et plan
- Stockage de gradients pour les gradients importés (chiffrés) par l'appareil client.
- Stockage de dégradés agrégés pour les dégradés agrégés, coupés et bruités.
- Un espace de stockage pour les modèles et les plans d'entraînement, les modèles et les poids.
Collecteur
Le collecteur est un service en arrière-plan qui compte régulièrement les envois de l'appareil client pendant un cycle d'entraînement. Il avertit l'agrégateur de lancer l'agrégation une fois que suffisamment d'envois sont disponibles.
Hôtes de service
Tous les services qui n'ont pas accès à des informations sensibles sont hébergés sur GKE.
Tous les services susceptibles de traiter des informations sensibles sont hébergés dans Confidential Space.
Toutes les données sensibles sont chiffrées à l'aide de clés de chiffrement gérées par des services de clés appartenant à plusieurs parties. Seul le code Open Source écrit par l'ODP et attesté, exécuté dans des versions légitimes de l'Espace confidentiel compatibles avec le calcul confidentiel, peut accéder aux clés de déchiffrement.
Dans une unité de service, la ressource de calcul se présente comme suit:
Évolutivité
L'infrastructure décrite précédemment se concentre sur une seule unité de service.
Une unité de service utilise un Cloud Spanner. Pour connaître les limites importantes, consultez Quotas et limites Spanner.
Chaque composant de cette architecture peut être mis à l'échelle indépendamment. Pour ce faire, vous devez faire évoluer la capacité dans l'espace confidentiel ou dans le cluster GKE à l'aide de mécanismes d'ajustement standard. Pour augmenter la capacité de traitement, vous pouvez ajouter des instances de:
- Service Web d'attribution de tâches
- Service Web de gestion des tâches
- Instances de l'agrégateur
- Instances de l'outil de mise à jour du modèle
Résilience
La résilience d'un serveur FC est gérée par la reprise après sinistre à l'aide d'un stockage répliqué. Si vous souhaitez mettre en place une reprise après sinistre, vous devez activer la réplication des données interrégionale. Cela garantit que si un sinistre se produit (par exemple, un événement météorologique perturbant un centre de données), le service reprendra à partir de la dernière série d'entraînement.
Spanner
L'implémentation par défaut du serveur FC utilise Google Cloud Spanner comme base de données pour stocker l'état des tâches utilisé pour contrôler le flux d'entraînement. Vous devez évaluer les compromis entre cohérence et disponibilité en fonction de vos besoins métier avant de sélectionner une configuration multirégionale.
Aucune donnée utilisateur ni dérivée, brute ou chiffrée, n'est stockée dans une instance Spanner. N'hésitez pas à utiliser l'une des fonctionnalités de reprise après sinistre proposées par Spanner.
Spanner enregistre l'historique des modifications. L'agrégateur et le moteur de mise à jour du modèle stockent les données par cycle d'entraînement, et le résultat de chaque cycle est stocké séparément sans s'écraser les uns sur les autres. Par conséquent, le service peut reprendre à partir de la dernière série d'entraînement en cas de sinistre.
Google Cloud Storage
L'implémentation par défaut du serveur FC utilise Google Cloud Storage pour stocker des données blob telles que des modèles, des plans d'entraînement et des contributions d'appareils chiffrées.
La conception comprend trois instances GCS:
- Contributions de l'appareil: contributions chiffrées de l'appareil importées depuis l'appareil.
- Modèles: plans d'entraînement, modèles et pondérations.
- Gradients agrégés: gradients agrégés générés par l'agrégateur.
Les données stockées dans GCS sont:
- Données fournies par le développeur, telles qu'un plan de formation OU
- Données potentiellement privées, car elles sont dérivées de signaux utilisateur (protégés par un chiffrement basé sur plusieurs coordinateurs), tels que les gradients importés par l'appareil et les gradients agrégés
- Données non privées dérivées des signaux utilisateur, mais après l'application de la confidentialité différentielle, comme les poids du modèle.
Vous devez évaluer les compromis entre cohérence et disponibilité, et sélectionner les fonctionnalités de disponibilité et de durabilité des données GCS appropriées. Vous devez spécifier vos propres règles de conservation des données.
Réplication et sauvegardes
En plus des mécanismes de réplication de données fournis par Google Cloud, vous pouvez également choisir de sauvegarder périodiquement les données dans Spanner et GCS. Par exemple, vous pouvez utiliser des services et des offres de réplication multicloud. ODP ne fournit pas d'exemple, car ces configurations dépendent fortement des besoins de l'entreprise. La conception actuelle tient compte des besoins potentiels des développeurs en termes de réplications et de sauvegardes. Il est donc compatible avec les services et produits de réplication et de sauvegarde fournis par des tiers.