Comment TrueFoundry s'intègre à AWS : l'architecture d'un plan de contrôle

Pour les architectes cloud et les ingénieurs DevOps, le principal défi en matière de mise à l'échelle de l'IA générative n'est souvent pas la disponibilité des ressources de calcul, mais l'orchestration de ces ressources. AWS fournit de puissantes primitives : Amazon EKS, Instances ponctuelles, Rôles IAM, et Substrat rocheux d'Amazon. Cependant, les combiner au sein d'une plateforme de développement interne cohérente implique souvent une configuration complexe et une maintenance continue.

TrueFoundry fait office de couche d'orchestration, superposée à l'infrastructure directement dans votre compte AWS. Ci-dessous, nous expliquerons exactement comment la plateforme s'intègre à AWS, notamment en ce qui concerne les limites de sécurité, la fédération des identités, la mise en réseau et l'optimisation des calculs.

Le modèle de déploiement : plan de contrôle ou plan de calcul

Nous utilisons une architecture à plans divisés pour dissocier la gestion de l'exécution.

• Le plan de contrôle : Il s'agit de la couche de gestion (API et tableau de bord). Il gère les métadonnées, l'authentification utilisateur (RBAC) et la planification des tâches.
• Le plan de calcul : C'est là que se déroule le véritable travail. Il se compose d'agents et de contrôleurs s'exécutant sur votre Cluster Amazon EKS, gérant les pondérations des modèles, les données clients et le traitement par GPU.

La connectivité repose sur un flux WebSocket ou gRPC sécurisé et sortant uniquement. L'agent qui s'exécute dans votre cluster initie la connexion au plan de contrôle pour récupérer les nouveaux manifestes de déploiement et envoyer des mises à jour de statut (comme l'état des pods). Comme le trafic est uniquement sortant, vous n'avez pas besoin d'ouvrir de ports entrants sur les groupes de sécurité de votre VPC, ce qui permet de préserver la confidentialité de votre VPC.

‍

Schéma d'architecture : sécurité sur deux plans

‍

Figure 1 : L'architecture Split-Plane garantit que la résidence des données reste au sein du VPC du client.

Topologie du réseau et flux de trafic

Lors du déploiement de TrueFoundry dans un environnement AWS, la configuration réseau s'appuie sur PIÈCE EN PVC AWS plugin pour Kubernetes. Les ressources informatiques fonctionnent au sein de sous-réseaux privés, ce qui garantit que les points de terminaison d'inférence ne sont pas exposés à l'Internet public par défaut.

Schémas d'entrée et de sortie

• Trafic entrant (demandes d'inférence) : Le trafic des applications entre dans le VPC via un Équilibreur de charge des applications AWS (ALB), géré par le contrôleur AWS Load Balancer. L'ALB met fin aux connexions TLS et transmet les demandes à la passerelle d'entrée Istio exécutée au sein du cluster EKS.
• Trafic sortant (registre et API) : Les nœuds de travail EKS nécessitent un accès réseau sortant pour extraire des images de conteneurs depuis Amazon ECR et communiquez avec l'API Control Plane. Ce trafic est acheminé via une passerelle NAT associée aux sous-réseaux privés.

Intégration de Service Mesh

TrueFoundry se déploie Istio pour gérer le trafic est-ouest entre les microservices. Par exemple, dans un pipeline RAG où un service d'intégration communique avec une base de données vectorielles, Istio gère le routage et applique le protocole TLS mutuel (mTLS). Cela garantit que le trafic interne du cluster est chiffré en transit sans nécessiter de modifications au niveau de l'application.

Figure 2 : Flux de trafic réseau démontrant l'entrée pour l'inférence et la sortie pour les dépendances.

Fédération et sécurité des identités

L'un des principaux objectifs de sécurité des environnements AWS d'entreprise est la suppression des informations d'identification statiques. TrueFoundry résout ce problème en implémentant Rôles IAM pour les comptes de service (IRSA).

Le flux d'authentification

Lorsqu'un utilisateur déploie une charge de travail, telle qu'une tâche de réglage ou un service d'inférence, la plateforme exécute le flux de travail suivant :

1. Création d'un compte de service : TrueFoundry crée un compte de service Kubernetes dans l'espace de noms de la charge de travail.
2. Association de rôles : Le compte de service est annoté avec l'ARN d'un rôle AWS IAM préconfiguré.
3. Échange de jetons : Le fournisseur EKS OIDC valide le jeton Web JSON (JWT) émis par le cluster vers le pod.
4. Délivrance des titres de compétences : Le pod échange ce jeton OIDC avec AWS STS (Security Token Service) pour recevoir des informations d'identification AWS temporaires et rotatives.

Ce mécanisme garantit que le code de l'application utilise des kits SDK AWS standard (par exemple, boto3) sans secrets codés en dur. Si un pod est compromis, l'impact potentiel est limité aux autorisations spécifiques accordées à ce rôle IAM, et les informations d'identification expirent automatiquement.

Figure 3 : Le flux d'authentification IRSA utilisé par les charges de travail TrueFoundry.

Moteur de calcul : EKS, Karpenter et Spot Optimization

L'exécution de grands modèles de langage (LLM) sur des instances à la demande présente des défis financiers importants. TrueFoundry orchestre Charpentier, le système open source de provisionnement de nœuds Kubernetes, pour optimiser l'utilisation des ressources informatiques.

Orchestration des instances Spot

TrueFoundry fournit une logique spécialisée pour la gestion Instances ponctuelles EC2:

• Approvisionnement des capacités : Lorsqu'un déploiement demande des ressources (par exemple, 24 Go de VRAM), la plateforme demande à Karpenter de fournir le type d'instance le plus rentable répondant aux contraintes. Cela peut se traduire par un g5.2xlarge, g5.4xlarge ou p3.2xlarge en fonction de la disponibilité actuelle dans la région AWS.
• Gestion des interruptions : Le système surveille Avis de résiliation de l'instance EC2 Spot, qui fournit un avertissement de deux minutes avant la remise en état de l'instance.
• Remplacement proactif : Lors de la détection d'un signal de terminaison via l'AWS Node Termination Handler, la plateforme met en circuit le nœud concerné, vide les connexions et demande à Karpenter de fournir immédiatement un remplacement.

Cette orchestration permet une utilisation fiable des instances ponctuelles pour les charges de travail d'inférence de production, ce qui permet généralement de réaliser des économies de jusqu'à 70 % par rapport à la tarification à la demande pour les charges de travail tolérantes aux taches.

La passerelle IA : unifier Bedrock et SageMaker

Pour les organisations utilisant des modèles propriétaires, TrueFoundry sert d'interface API unifiée pour Substrat rocheux d'Amazon et Amazon SageMaker.

Modèles d'intégration fondamentaux

Plutôt que d'intégrer des appels directs au SDK AWS dans le code de l'application, les développeurs acheminent les demandes via la passerelle TrueFoundry. Le Gateway exécute les tâches suivantes :

• Authentification : Vérifie la clé API interne par rapport au registre Control Plane.
• Télémétrie : Enregistre le nombre de jetons d'entrée et de sortie pour une attribution granulaire des coûts et des pistes d'audit.
• Proxy : Signe les demandes à l'aide du rôle IAM propre à la passerelle et les transmet au point de terminaison Bedrock InvokeModel.

Cette centralisation permet aux administrateurs de gérer les politiques d'accès au niveau de la passerelle sans modifier constamment les politiques IAM ou modifier les informations d'identification AWS.

Modèles d'intégration de SageMaker

TrueFoundry prend en charge le déploiement de modèles sur les terminaux SageMaker. Cependant, la plateforme permet également de déployer des modèles directement sur EC2/EKS. Cette alternative permet aux entreprises de contourner les avantages généralement associés aux points de terminaison d'inférence entièrement gérés tout en garantissant une expérience de déploiement cohérente pour le développeur.

Compatibilité avec l'infrastructure en tant que code (IaC)

TrueFoundry est conçu pour s'intégrer aux flux de travail Infrastructure as Code existants. La plateforme fournit des informations vérifiées Modules Terraform pour fournir l'infrastructure sous-jacente requise :

• VPC et réseaux : Configure les sous-réseaux privés, les passerelles NAT et les groupes de sécurité conformément aux meilleures pratiques d'AWS.
• Cluster EKS : Propose le plan de contrôle Kubernetes, les groupes de nœuds gérés et les modules complémentaires essentiels tels que le VPC CNI et le pilote EBS CSI.
• Bases de données : Provisions Amazon RDS instances pour le stockage des métadonnées si le plan de contrôle est auto-hébergé.

Cela garantit que l'environnement se compose de ressources AWS standard définies dans le fichier d'état Terraform du client, tout en restant entièrement auditable.

Comparaison : AWS Native et AWS + TrueFoundry

Le tableau suivant décrit les différences opérationnelles entre la création d'une plateforme à l'aide de primitives AWS brutes et l'utilisation de la superposition TrueFoundry.

Conclusion : alignement architectural

L'intégration de TrueFoundry à AWS s'inscrit dans le modèle architectural qui consiste à utiliser l'hyperscaler pour la fiabilité de l'infrastructure tout en mettant en œuvre un plan de contrôle spécialisé pour la gestion spécifique des applications.

Pour les organisations qui investissent dans AWS, ce modèle fournit un mécanisme permettant de moderniser les opérations d'IA tout en maintenant les périmètres de résidence et de sécurité des données existants. Le client conserve le contrôle du VPC et des limites de sécurité, en utilisant TrueFoundry pour rationaliser la complexité du cycle de vie des applications d'IA.

‍