Cómo se integra TrueFoundry con AWS: la arquitectura de un plano de control

Para los arquitectos de nube y los ingenieros de DevOps, el principal desafío a la hora de escalar la IA generativa no suele ser la disponibilidad de los recursos informáticos, sino la orquestación de esos recursos. AWS proporciona potentes primitivas: Amazon EKS, Instancias puntuales, Funciones de IAM, y lecho rocoso amazónico. Sin embargo, combinarlos en una plataforma de desarrollo interna cohesiva a menudo implica una configuración compleja y un mantenimiento continuo.

TrueFoundry actúa como esa capa de orquestación y actúa como una superposición de infraestructura directamente dentro de su cuenta de AWS. A continuación, analizaremos exactamente cómo se integra la plataforma con AWS, lo que abarca los límites de seguridad, la federación de identidades, las redes y la optimización informática.

El modelo de implementación: plano de control frente a plano de computación

Usamos una arquitectura de plano dividido para desvincular la administración de la ejecución.

• El plano de control: Esta es la capa de administración (API y panel de control). Gestiona los metadatos, la autenticación de usuarios (RBAC) y la programación de trabajos.
• El plano de cálculo: Aquí es donde se lleva a cabo el trabajo real. Consiste en agentes y controladores que se ejecutan en vuestro Clúster Amazon EKS, que gestiona los pesos de los modelos, los datos de los clientes y el procesamiento de GPU.

La conectividad se basa en una transmisión WebSocket o gRPC segura y solo de salida. El agente que se ejecuta en el clúster inicia la conexión al plano de control para obtener nuevos manifiestos de implementación e insertar actualizaciones de estado (como el estado del pod). Como el tráfico es solo saliente, no es necesario que abras ningún puerto de entrada en los grupos de seguridad de la VPC, lo que permite mantener la VPC completamente privada.

‍

Diagrama de arquitectura: seguridad de plano dividido

‍

Figura 1: La arquitectura de plano dividido garantiza que la residencia de los datos permanezca dentro de la VPC del cliente.

Topología de redes y flujo de tráfico

Al implementar TrueFoundry en un entorno de AWS, la configuración de red aprovecha la COMO PVC CNI complemento para Kubernetes. Los recursos informáticos funcionan dentro de subredes privadas, lo que garantiza que los puntos finales de inferencia no estén expuestos a la Internet pública de forma predeterminada.

Patrones de entrada y salida

• Tráfico entrante (solicitudes de inferencia): El tráfico de aplicaciones entra en la VPC a través de un Balanceador de carga de aplicaciones (ALB) de AWS, administrado por el AWS Load Balancer Controller. El ALB termina las conexiones TLS y reenvía las solicitudes al Istio Ingress Gateway que se ejecuta en el clúster de EKS.
• Tráfico saliente (registro y API): Los nodos de trabajo de EKS requieren acceso a la red saliente para extraer las imágenes del contenedor desde Amazon ECR y comuníquese con la API del plano de control. Este tráfico se enruta a través de una puerta de enlace NAT asociada a las subredes privadas.

Integración de Service Mesh

TrueFoundry implementa Istio para gestionar el tráfico este-oeste entre microservicios. Por ejemplo, en una canalización de RAG en la que un servicio integrado se comunica con una base de datos vectorial, Istio administra el enrutamiento y aplica el TLS mutuo (mTLS). Esto garantiza que el tráfico interno del clúster se cifre en tránsito sin necesidad de realizar cambios en el nivel de la aplicación.

Figura 2: Flujo de tráfico de red que muestra la entrada para inferencia y la salida para dependencias.

Federación de identidades y seguridad

Un objetivo de seguridad principal en los entornos empresariales de AWS es la eliminación de las credenciales estáticas. TrueFoundry aborda este problema mediante la implementación Funciones de IAM para cuentas de servicio (IRSA).

El flujo de autenticación

Cuando un usuario implementa una carga de trabajo, como un trabajo de ajuste o un servicio de inferencia, la plataforma ejecuta el siguiente flujo de trabajo:

1. Creación de cuentas de servicio: TrueFoundry crea una cuenta de servicio de Kubernetes en el espacio de nombres de la carga de trabajo.
2. Asociación de roles: La cuenta de servicio se anota con el ARN de un rol de AWS IAM previamente aprovisionado.
3. Intercambio de fichas: El Proveedor OIDC de EKS valida el token web JSON (JWT) emitido por el clúster para el pod.
4. Emisión de credenciales: El pod intercambia este token de OIDC con AWS STS (Security Token Service) para recibir credenciales de AWS temporales y rotativas.

Este mecanismo garantiza que el código de la aplicación utilice los SDK de AWS estándar (por ejemplo, boto3) sin secretos codificados. Si un pod se ve comprometido, el posible impacto se limita a los permisos específicos concedidos a esa función de IAM, y las credenciales caducan automáticamente.

Figura 3: El flujo de autenticación IRSA utilizado por las cargas de trabajo de TrueFoundry.

Compute Engine: EKS, Karpenter y Spot Optimization

La ejecución de modelos de lenguaje grande (LLM) en instancias bajo demanda presenta importantes desafíos de costos. TrueFoundry organiza Carpintero, el sistema de aprovisionamiento de nodos de Kubernetes de código abierto, para optimizar la utilización de la computación.

Orquestación de instancias puntuales

TrueFoundry proporciona una lógica especializada para administrar Instancias puntuales de EC2:

• Aprovisionamiento de capacidad: Cuando una implementación solicita recursos (por ejemplo, 24 GB de VRAM), la plataforma indica a Karpenter que aprovisione el tipo de instancia más rentable que cumpla con las restricciones. Esto puede resultar en una versión g5.2xlarge, g5.4xlarge o p3.2xlarge, según la disponibilidad actual en la región de AWS.
• Gestión de interrupciones: El sistema monitorea la Aviso de finalización de la instancia puntual de EC2, que proporciona una advertencia de dos minutos antes de la recuperación de la instancia.
• Sustitución proactiva: Al detectar una señal de terminación a través del controlador de terminación de nodos de AWS, la plataforma acordona el nodo afectado, agota las conexiones y hace que Karpenter aprovisione un reemplazo de inmediato.

Esta orquestación permite el uso confiable de las instancias puntuales para las cargas de trabajo de inferencia de producción, lo que generalmente genera ahorros de hasta un 70% en comparación con los precios bajo demanda para cargas de trabajo con tolerancia puntual.

La puerta de entrada a la IA: unificación de Bedrock y SageMaker

Para las organizaciones que utilizan modelos propietarios, TrueFoundry sirve como una interfaz API unificada para lecho rocoso amazónico y Amazon SageMaker.

Patrones de integración de Bedrock

En lugar de incorporar llamadas directas al SDK de AWS en el código de la aplicación, los desarrolladores dirigen las solicitudes a través de TrueFoundry Gateway. El Gateway realiza:

• Autenticación: Verifica la clave API interna con el registro del plano de control.
• Telemetría: Registra los recuentos de tokens de entrada y salida para la atribución granular de costos y los registros de auditoría.
• Uso de proxy: Firma las solicitudes mediante la función de IAM propia de Gateway y las reenvía al punto final de Bedrock InvokeModel.

Esta centralización permite a los administradores gestionar las políticas de acceso a nivel de puerta de enlace sin modificar constantemente las políticas de IAM ni rotar las credenciales de AWS.

Patrones de integración de SageMaker

TrueFoundry admite la implementación de modelos en los puntos finales de SageMaker. Sin embargo, la plataforma también ofrece la capacidad de implementar modelos directamente en EC2/EKS. Esta alternativa permite a las organizaciones evitar las primas que normalmente se asocian a los puntos finales de inferencia totalmente gestionados y, al mismo tiempo, mantener una experiencia de implementación uniforme para el desarrollador.

Compatibilidad con la infraestructura como código (IaC)

TrueFoundry está diseñado para integrarse con los flujos de trabajo de Infrastructure as Code existentes. La plataforma proporciona datos verificados Módulos Terraform para aprovisionar la infraestructura subyacente necesaria:

• VPC y redes: Configura subredes privadas, puertas de enlace NAT y grupos de seguridad de acuerdo con las prácticas recomendadas de AWS.
• Clúster EKS: Aprovisiona el plano de control de Kubernetes, los grupos de nodos administrados y los complementos esenciales, como el controlador CSI de EBS y CNI de la VPC.
• Bases de datos: Provisiones Amazon RDS instancias para el almacenamiento de metadatos si el plano de control está autohospedado.

Esto garantiza que el entorno esté compuesto por recursos de AWS estándar definidos en el archivo de estado de Terraform del cliente y que sea totalmente auditable.

Comparación: AWS Native frente a AWS + TrueFoundry

La siguiente tabla describe las diferencias operativas entre la creación de una plataforma con primitivas de AWS sin procesar y el uso de la superposición de TrueFoundry.

Conclusión: alineación arquitectónica

La integración de TrueFoundry con AWS se alinea con el patrón arquitectónico de utilizar el hiperescalador para garantizar la confiabilidad de la infraestructura y, al mismo tiempo, implementar un plano de control especializado para la administración específica de las aplicaciones.

Para las organizaciones que invierten en AWS, este modelo proporciona un mecanismo para modernizar las operaciones de inteligencia artificial y, al mismo tiempo, mantener los perímetros de residencia y seguridad de los datos existentes. El cliente conserva el control sobre la VPC y los límites de seguridad, y utiliza TrueFoundry para simplificar la complejidad del ciclo de vida de las aplicaciones de IA.

‍