Le serveur Federated Compute (FC) 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 Federated Compute (FC Server), ses composants et la technologie utilisée. Ce document fournit une vue d'ensemble de l'architecture, puis examine chaque composant en détail. Il explique également comment les composants fonctionnent ensemble pour fournir un environnement d'apprentissage fédéré et propose des stratégies pour mettre à l'échelle et partitionner les charges de travail.
Flux d'entraînement
L'entraînement consiste en des flux de données entre le client et le serveur FC. Le client FC est un module Android essentiel qui entraîne des modèles de ML sur l'appareil et interagit avec le serveur FC. Le serveur FC traite et agrège les résultats du client FC de manière sécurisée dans un environnement d'exécution sécurisé (TEE, Trusted Execution Environment).
L'entraînement comprend les étapes suivantes :
- Le client FC sur l'appareil télécharge une clé de chiffrement publique à partir des services de clés.
- Le client FC s'enregistre auprès du serveur FC et reçoit une tâche d'entraînement.
- Le client FC télécharge un programme 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 et du plan locaux.
- 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.
- Un cycle d'agrégation est déclenché.
- 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 lui-même auprès des coordinateurs, conformément à l'architecture RATS (Remote ATtestation procedureS) de la RFC 9334 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 secrets Shamir.
- L'agrégateur effectue l'agrégation inter-appareils, le clipping et le bruitage selon les mécanismes de confidentialité différentielle (DP) appropriés, et génère les résultats bruités.
- L'agrégateur déclenche le programme de mise à jour du modèle.
- Le Model Updater 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 le stockage de modèles.
Le serveur FC peut être déployé sur n'importe quel service cloud compatible 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 comporte les composants suivants déployés 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 des tâches | Service Web basé sur HTTPS où les appareils clients s'enregistrent périodiquement pour obtenir des tâches d'entraînement et signaler l'état de l'entraînement. |
| Agrégateur | Service d'arrière-plan exécuté dans Confidential Space. Il exécute les charges de travail créées par ODP. Il doit attester auprès des coordinateurs, qui protègent l'accès aux clés de déchiffrement. Seuls les agrégateurs ayant réussi l'attestation peuvent déchiffrer les contributions envoyées par les appareils clients et effectuer l'agrégation multi-appareils. |
| Gestionnaire de mise à jour du modèle | Service d'arrière-plan exécuté dans Confidential Space et qui applique les gradients agrégés au modèle. |
Détails du composant
Les sections suivantes détaillent 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 d'interface qui acceptent les requêtes HTTPS et créent ou obtiennent des tâches à partir de la base de données des 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 de nouvelles itérations et de nouveaux cycles d'entraînement.
Base de données des tâches
Base de données conforme à la norme ANSI SQL qui stocke les informations sur les tâches, les itérations et les devoirs. Dans cette implémentation, Google Cloud Spanner est utilisé comme service de base de données sous-jacent.
Service d'attribution des tâches
Le service d'attribution des tâches est un service Web de 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 des tâches est la même instance de base de données que celle du service de gestion des tâches.
Service d'agrégation
Agrégateur et outil de mise à jour des modèles
L'agrégateur et le programme de mise à jour du modèle sont similaires. Il s'agit de services d'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 des gradients pour les gradients (chiffrés) importés par l'appareil client.
- Stockage de gradients agrégés pour les gradients agrégés, écrêtés et bruités.
- Un stockage de modèles et de plans pour les plans d'entraînement, les modèles et les poids.
Collecteur
Le collecteur est un service d'arrière-plan qui comptabilise périodiquement les envois des appareils clients au cours d'un cycle d'entraînement. Il avertit l'agrégateur de lancer l'agrégation une fois qu'il y a suffisamment d'envois.
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 rédigé par ODP et attesté avec succès, exécuté dans des versions légitimes de Confidential Space compatibles avec l'informatique confidentielle, 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 unité de service.
Une unité de service utilise un Cloud Spanner. Pour connaître les principales limites, consultez Quotas et limites de Spanner.
Chaque composant de cette architecture peut être mis à l'échelle indépendamment. Pour ce faire, vous devez adapter la capacité dans Confidential Space ou dans le cluster GKE à l'aide de mécanismes de scaling standards. En pratique, la capacité de traitement peut être augmentée en ajoutant des instances de :
- Service Web d'attribution des tâches
- Service Web de gestion des tâches
- Instances d'agrégateur
- Instances 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 du stockage répliqué. Si la reprise après sinistre vous intéresse, vous devez activer la réplication des données entre régions. Ainsi, en cas de catastrophe (comme 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. Avant de sélectionner une configuration multirégionale, vous devez évaluer les compromis entre cohérence et disponibilité en fonction de vos besoins commerciaux.
Aucune donnée utilisateur ni aucun dérivé de ces données, bruts ou chiffrés, n'est stocké dans une instance Spanner. N'hésitez pas à utiliser l'une des fonctionnalités de reprise après sinistre disponibles dans Spanner.
Spanner enregistre l'historique des modifications. L'agrégateur et le programme de mise à jour du modèle stockent les données par cycle d'entraînement. Le résultat de chaque cycle est stocké séparément, sans écraser les autres. Grâce à cela, 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 les données blob telles que les modèles, les plans d'entraînement et les contributions chiffrées des appareils.
La conception comporte trois instances GCS :
- Contributions des appareils : contributions chiffrées des appareils importées depuis les appareils.
- Modèles : plans d'entraînement, modèles et leurs pondérations.
- Gradients agrégés : gradients agrégés produits par l'agrégateur.
Les données stockées dans GCS sont les suivantes :
- Données fournies par le développeur, comme un programme d'entraînement
- Données potentiellement privées, car elles sont dérivées de signaux utilisateur (protégés par un chiffrement soutenu par plusieurs coordinateurs), tels que les gradients importés sur 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 pondérations 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 des 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 matière de réplication et de sauvegarde. Par conséquent, il est compatible avec les produits et services de réplication et de sauvegarde fournis par des tiers.