Architecture TrueFoundry : apprentissage automatique sur Kubernetes !

TrueFoundry permet de déployer très facilement des applications sur des clusters Kubernetes depuis votre propre compte de fournisseur de cloud. Pour ce faire, il extrait les composants de l'infrastructure pour les data scientists et les développeurs tout en appliquant les meilleures pratiques du point de vue de la sécurité, de l'infrastructure et de l'optimisation des coûts.

Les principales motivations qui sous-tendent l'architecture actuelle de TrueFoundry sont les suivantes :

1. Les données ne doivent pas quitter votre compte cloud ou sur site: L'apprentissage automatique implique généralement l'interaction avec un grand nombre de données. Si des données sortent de votre compte cloud (VPC), la sécurité des données risque d'être compromise et nous finissons également par encourir des coûts de sortie/entrée de données. C'est pourquoi TrueFoundry a été conçu dès le départ pour conserver les données et les calculer dans votre propre environnement.
2. Le ML hérite des principes SRE au sein de votre organisation : Les entreprises mettent généralement en œuvre l'ensemble des piles de déploiement, de surveillance et d'alerte pour déployer leurs microservices logiciels. Nous voulions que le machine learning hérite des mêmes pratiques et ne suive pas une procédure de configuration d'infrastructure parallèle. Les équipes chargées de l'infrastructure et du SRE peuvent ainsi appliquer facilement les meilleures pratiques en matière de sécurité et d'optimisation des coûts dans l'ensemble de l'organisation.
3. Cloud natif : TrueFoundry repose sur Kubernetes et est donc conçu de manière native pour le cloud. Cependant, même si Kubernetes est natif du cloud, il existe de nombreuses différences complexes entre les distributions Kubernetes d'AWS (EKS), GCP (GKE) et Azure (AKS). Voici quelques exemples de ces différences :

GKE Autopilot impose d'avoir les mêmes valeurs pour les demandes et les limites de ressources, contrairement à AKS, EKS et GKE Standard.

EKS et GKE proposent une option pour le provisionnement automatique des nœuds, alors qu'AKS ne propose pas de moyen pour cela.

Le temps de provisionnement des nœuds est assez élevé pour AKS, ce qui entraîne un comportement de dimensionnement automatique très lent.

Le fait d'être natif du cloud nous permet d'avoir accès aux différents matériels fournis par les différents fournisseurs de cloud, en particulier dans le cas des GPU.

4. Intégrer plutôt que réinventer : TrueFoundry s'intègre à la plupart des systèmes couramment utilisés au lieu de réinventer la roue. Cette philosophie sous-tend bon nombre de nos décisions en matière d'architecture. Cela nous complique parfois la tâche, car il n'est pas toujours facile de créer des intégrations là où des API fiables ne sont pas disponibles. Mais nous nous efforçons de créer ces API et interfaces afin que nos utilisateurs n'aient pas besoin d'apprendre un autre outil.

ML Stack pour une itération et un impact rapides

L'apprentissage automatique nécessite la configuration d'une pile complexe pour permettre aux data cientists d'expérimenter et de livrer rapidement.

Idéalement, les développeurs devraient dépenser davantage dans la couche verte supérieure, tandis que les couches inférieures devraient être complètement éloignées d'elles. TrueFoundry fournit une pile ouverte et personnalisable qui fonctionne avec ce que vous utilisez actuellement et aide les data cientists à itérer sur les applications sans se concentrer sur les couches d'infrastructure sous-jacentes.

Dans le schéma ci-dessous, TrueFoundry fournit la formation des modèles, la diffusion et le registre des modèles afin de permettre aux data cientists de créer, de suivre et de déployer plus facilement des modèles.

Les principaux ensembles d'intégrations fournis par TrueFoundryCurently sont les suivants :

1. CI/CD: Github Actions, Bitbucket Pipelines, Jenkins. Nous ajoutons des intégrations supplémentaires en fonction de la demande des clients.
2. Maillage de services: Nous travaillons actuellement avec Istio. Nous prévoyons de prendre en charge d'autres contrôleurs d'entrée et fournisseurs de services maillés tels que Linkerd et Nginx.
3. Surveillance : Les applications déployées par TrueFoundry peuvent être surveillées à l'aide de n'importe lequel de vos systèmes de surveillance existants tels que Prometheus, Cloudwatch, DataDog, NewRelic, ELK stack, etc.
4. Gestion des coûts : Nous fournissons une attribution précise des coûts au niveau du service et de l'espace de noms à l'aide d'OpenCost. TrueFoundry fournit également des informations directement aux développeurs afin de réduire le coût de leurs services.
5. Contrôle d'accès : TrueFoundry s'intègre à la plupart des IdP tels qu'Okta, Auth0, AzureAD, Keycloak en utilisant les protocoles OIDC ou SAML pour l'authentification. L'autorisation pour les différents espaces de travail est intégrée au produit pour décider des autorisations à un niveau granulaire.
6. Gestion des secrets : TrueFoundry s'intègre à Hashcorp Vault, à GCP Secrets Manager et à AWS Parameter Store pour la gestion des secrets. Nous prévoyons également d'ajouter l'intégration avec Azure Vault et AWS Secrets Manager.
7. Moteur de flux de travail : TrueFoundry s'intègre à ArgoWorkflows pour fournir un moteur de flux de travail aux data cientists.

Architecture TrueFoundry

TrueFoundry fournit une architecture à plan divisé qui comprend les principaux composants suivants :

1. Plan de contrôle: Il s'agit du cerveau du système TrueFoundry qui orchestre les déploiements sur les différents plans de calcul. Nous fournissons un plan de contrôle hébergé dans notre plan habituel. Pour les entreprises clientes, le plan de contrôle peut également être déployé sur le cloud des clients.
2. Plan de calcul: Il s'agit du cluster Kubernetes sur lequel s'exécute le code de l'utilisateur. Il existe un agent sur le plan de calcul (agent d'entraînement) qui communique avec le plan de commande et exécute les commandes reçues du plan de contrôle. Le code de l'utilisateur accédant aux données s'exécute sur le plan de calcul. Par conséquent, le cluster du plan de calcul doit se trouver à proximité des données.

3. Interfaces client : Les développeurs et les spécialistes des données peuvent communiquer avec l'interface utilisateur à l'aide d'un SDK python, de notre interface utilisateur Web ou des CLI TrueFoundry (servicefoundry et mlfoundry). TrueFoundry expose également des API permettant aux clients de créer des flux de travail d'automatisation, qui sont documentés ici : https://docs.truefoundry.com/reference

4. Serveur d'authentification : Il existe un serveur central d'authentification et de licences qui assure le suivi de toutes les organisations et de leurs membres. Ce serveur est hébergé par TrueFoundry et peut également s'intégrer à des IdP externes pour fournir une expérience d'authentification unique à tous nos utilisateurs.

Les avantages de cette architecture

Réseau sécurisé

Le composant tfy-agent n'a aucune entrée et est chargé d'initier la connexion au plan de contrôle. Il établit une connexion cryptée persistante avec le plan de contrôle sur lequel la communication s'effectue. Cela permet au système de fonctionner même si les clusters du plan de calcul sont privés ou se trouvent dans des VPC différents. La seule contrainte est que l'URL du plan de contrôle doit être accessible à tous les clusters de plans de calcul. Vous pouvez également contrôler les autorisations accordées à tfy-agent à l'aide de Kubernetes RBAC pour accéder à certains espaces de noms.

Dépendance douce à l'égard du plan de contrôle Truefoundry

Le plan de contrôle Truefoundry est uniquement chargé d'orchestrer les déploiements vers le plan de calcul. Il ne se trouve pas dans le chemin critique du flux de demandes vers les services déployés. Ainsi, même si vous supprimez le plan Truefoundry Control, tous les services déployés continuent de fonctionner correctement. Ce découplage entre la fiabilité du service et Truefoundry permet de garantir que Truefoundry ne se situe pas dans la voie critique de la fiabilité du service.

Gestion efficace de plusieurs clusters

Truefoundry Control Plane fournit un écran unique permettant de visualiser tous les clusters Kubernetes des fournisseurs de cloud et des sites locaux de l'entreprise. Cela permet également de déplacer très facilement des charges de travail d'un cluster à un autre à l'aide de notre fonctionnalité de clonage et de promotion.

Réduction des coûts et de la maintenance

L'agent Truefoundry est un composant très léger qui se trouve sur chaque cluster, alors qu'il n'a besoin que d'une seule copie du plan de contrôle. Le plan de contrôle nécessite plus de ressources (3 processeurs, 6 Go de RAM) alors que l'agent n'a besoin que de 0,2 processeur et 400 Mo de RAM. À mesure que l'ampleur du trafic et des équipes augmente, nous devons généralement ajouter d'autres clusters en fonction des régions ou des équipes. Mais le plan de contrôle n'a pas besoin d'être répliqué, ce qui permet de réduire les coûts et la maintenance.

Un aperçu du plan de contrôle de Truefoundry

Le plan de contrôle Truefoundry comprend plusieurs microservices qui orchestrent les déploiements, le stockage des métadonnées du modèle, etc. Les principaux composants du plan de contrôle Truefoundry sont les suivants :

1. Interface utilisateur Web

2. Microservices pour orchestrer les déploiements : le plan de contrôle comprend quelques microservices pour orchestrer les déploiements sur les clusters et met également en cache les mises à jour en direct de tous les clusters connectés dans le plan de calcul.

3. Base de données Postgres : elle est utilisée pour stocker toutes les informations sur les équipes, les services déployés et leurs métadonnées.

Cluster Compute-Plane

Nous devons installer quelques composants sur le cluster Compute-Plane pour tirer pleinement parti de Truefoundry. La liste est la suivante :

1. tfy-agent (obligatoire) : il s'agit de l'agent truefoundry-agent qui initie la connexion au plan de contrôle et aide à coordonner les instructions depuis le plan de contrôle.
2. Argo CD (Obligatoire) : ArgoCD est utilisé pour appliquer tous les manifestes au cluster Kubernetes. C'est mieux que de faire l'installation de helm, car le contrôleur ArgoCD s'assure que l'état interne est synchronisé avec l'état souhaité dans les manifestes et n'est pas sujet à des échecs d'installation de helm.
3. Istio (Obligatoire actuellement, ce sera facultatif à l'avenir) : nous utilisons actuellement Istio comme contrôleur d'entrée pour le cluster. Nous n'exigeons pas l'exécution de sidecars istio et ils peuvent être activés en option si nécessaire pour des cas d'utilisation tels que le TLS mutuel. Nous prévoyons également d'utiliser les API Gateway de Kubernetes qui nous permettront de travailler avec plusieurs contrôleurs d'entrée tels que Nginx, Linkerd, Traefik, etc.
4. Flux de travail Argo (Obligatoire uniquement pour l'exécution des tâches) : nous utilisons ArgoWorkflows pour exécuter toutes les tâches au sein du cluster en raison des options plus avancées qu'il propose par rapport aux tâches Kubernetes.
5. Déploiements d'Argo (Obligatoire) : Nous utilisons ArgoRollouts pour prendre en charge les déploiements de Canary et BlueGreen sur Kubernetes. Il s'agit actuellement d'une condition préalable obligatoire, mais elle sera facultative à l'avenir.
6. Prométhée (Facultatif) : il s'agit d'une dépendance facultative nécessaire pour afficher des mesures telles que le processeur, la mémoire, le nombre de demandes pour les services.
7. Keda (facultatif): cette dépendance est facultative et est nécessaire si vous souhaitez activer la mise à l'échelle automatique pour vos charges de travail.
8. Loki (Facultatif) : Cela facilite l'agrégation des journaux et constitue une dépendance facultative. Vous pouvez toujours utiliser n'importe quel autre agrégateur de journaux avec lequel vous êtes à l'aise, comme ELK Stack, Cloudwatch, Datadog, etc.
9. Pilotes (EFS, EBS, GPU) : ils sont nécessaires si vous avez besoin d'une prise en charge du GPU ou des volumes dans votre cluster.
10. Notebook Controller (facultatif) : cela est nécessaire si vous souhaitez fournir des blocs-notes sur le cluster Kubernetes.

Contraintes pesant sur l'AMI du cluster Kubernetes

Truefoundry peut fonctionner avec toutes les AMI sous-jacentes, y compris Bottlerocket sur AWS. Étant donné que l'agent est comme n'importe quel autre organigramme exécuté sur Kubernetes, nous n'avons aucune contrainte ni exigence de la part des AMI sous-jacentes et pouvons fonctionner sur toutes les AMI, y compris les machines bare metal.

Autorisations pour tfy-agent

Le tfy-agent effectue toutes les actions sur l'utilisateur Kubernetes pour le compte des utilisateurs connectés à la plateforme truefoundry. Par conséquent, il nécessite un accès administrateur à un certain ensemble d'espaces de noms sur lesquels les utilisateurs sont autorisés à déployer les applications. Nous disposons de fonctionnalités permettant de mettre sur liste noire ou blanche un certain ensemble d'espaces de noms et l'agent ne peut effectuer des actions que sur ces espaces de noms.

Authentification dans Truefoundry

Truefoundry s'appuie sur un serveur d'authentification installé sur nos serveurs pour les licences et l'authentification.

Autorisation dans Truefoundry

Truefoundry fournit un contrôle RBAC précis au niveau du locataire, du cluster, de l'espace de travail et du référentiel ML. Pour comprendre les mécanismes RBAC de Truefoundry, vous pouvez consulter notre documentation ici : https://docs.truefoundry.com/docs/collaboration-and-access-control

Toutes les règles d'autorisation se trouvent dans la table Postgres du plan de contrôle et chaque appel d'API est vérifié pour voir si l'utilisateur est autorisé à effectuer cette connexion.

Image Build Pipeline dans le plan de contrôle

Truefoundry fournit un pipeline de création d'images de base optimisé pour créer des images très rapidement sur Kubernetes. Si vous souhaitez personnaliser le pipeline d'images de création pour inclure des contrôles statiques ou d'autres outils d'analyse des vulnérabilités, il existe deux approches :

1. Vous pouvez continuer à utiliser votre propre pipeline CI pour créer des images, puis fournir l'URI de l'image créée comme entrée pour les déploiements Truefoundry.
2. Vous pouvez personnaliser le pipeline de génération Truefoundry pour inclure les composants de votre choix. Il s'agit essentiellement d'un ArgoworFlow et puisque vous possédez le plan de contrôle dans le plan Enterprise, vous êtes libre de le personnaliser comme vous le souhaitez.

Gestion des secrets dans Truefoundry

Véritable fonderie s'intègre aux magasins de gestion de secrets les plus populaires. Il ne stocke pas les valeurs secrètes avec lui et ne stocke que le chemin d'accès à ces secrets.