Arquitetura TrueFoundry - Machine Learning no Kubernetes!

A TrueFoundry facilita muito a implantação de aplicações em clusters Kubernetes na sua própria conta de provedor de nuvem. Isso é feito abstraindo os componentes de infraestrutura para cientistas de dados e desenvolvedores, enquanto impõe as melhores práticas de segurança, infraestrutura e otimização de custos.

As principais motivações por trás da arquitetura atual da TrueFoundry são:

1. Os dados não devem sair da sua conta na nuvem/on-premise: O Machine Learning geralmente envolve a interação com muitos dados. Se os dados saírem da sua conta na nuvem (VPC), há um risco de a segurança dos dados ser comprometida e também acabamos incorrendo em custos de egresso/ingresso de dados. É por isso que a TrueFoundry foi projetada desde o início para manter dados e computação dentro do seu próprio ambiente.
2. ML herda os princípios de SRE dentro da sua organização: As empresas geralmente implementam todas as pilhas de implantação, monitoramento e alerta para implantar seus microsserviços de software. Queríamos que o ML herdasse as mesmas práticas e não seguisse uma rota de configuração de infraestrutura paralela. Isso facilita para as equipes de infraestrutura e SRE imporem as melhores práticas de segurança e otimização de custos em toda a organização.
3. Nativo da Nuvem: A TrueFoundry é construída sobre Kubernetes e, portanto, é nativa da nuvem por design. No entanto, embora o Kubernetes seja nativo da nuvem, existem muitas diferenças intrincadas entre as distribuições Kubernetes da AWS (EKS), GCP (GKE) e Azure (AKS). Alguns exemplos dessas diferenças são:

O GKE Autopilot impõe ter os mesmos valores para requisições e limites de recursos, enquanto AKS, EKS e GKE Standard não o fazem.

EKS e GKE têm uma opção para provisionamento automático de nós, enquanto o AKS não oferece uma maneira para isso.

O tempo de provisionamento de nós é bastante alto para o AKS, o que leva a um comportamento de autoescalonamento muito lento.

Ser nativo da nuvem nos permite ter acesso aos diferentes hardwares fornecidos por diferentes provedores de nuvem, especialmente no caso de GPUs.

4. Integrar em vez de reinventar: A TrueFoundry integra-se com a maioria dos sistemas comumente usados em vez de reinventar a roda. Essa filosofia impulsiona muitas de nossas decisões de arquitetura. Às vezes, isso torna a jornada mais difícil para nós, já que nem sempre é fácil construir integrações onde APIs sólidas não estão disponíveis - mas fazemos o trabalho árduo de construir essas APIs e interfaces para que nossos usuários não precisem aprender mais uma ferramenta.

Pilha de ML para iteração rápida e impacto

O Machine Learning exige uma pilha complicada a ser configurada para que cientistas de dados experimentem e entreguem rapidamente.

Idealmente, os desenvolvedores deveriam dedicar mais tempo à camada verde superior, enquanto as camadas inferiores deveriam ser completamente abstraídas deles. A TrueFoundry oferece uma pilha aberta e personalizável que funciona com o que você já está usando e ajuda os cientistas de dados a iterar nas aplicações sem se preocupar com as camadas de infraestrutura subjacentes.

No diagrama abaixo, a TrueFoundry fornece o Treinamento de Modelos, o Servir de Modelos e o Registro de Modelos para facilitar que os cientistas de dados construam, rastreiem e implementem modelos.

O conjunto principal de integrações que a TrueFoundry oferece atualmente são:

1. CI/CD: Github Actions, Bitbucket Pipelines, Jenkins. Estamos adicionando integrações adicionais com base na demanda dos clientes.
2. Malha de Serviço: Atualmente operamos com Istio. Planejamos dar suporte a outros controladores Ingress e provedores de malha de serviço como Linkerd, Nginx.
3. Monitoramento: As aplicações implementadas pela TrueFoundry podem ser monitoradas usando qualquer um dos seus sistemas de monitoramento existentes, como Prometheus, Cloudwatch, DataDog, NewRelic, ELK stack, etc.
4. Gerenciamento de Custos: Fornecemos atribuição de custos granular por nível de serviço/namespace usando OpenCost. A TrueFoundry também oferece insights diretamente aos desenvolvedores para reduzir o custo de seus serviços.
5. Controle de Acesso: A TrueFoundry se integra com a maioria dos IDPs como Okta, Auth0, AzureAD, Keycloak usando protocolos OIDC ou SAML para autenticação. A autorização para diferentes workspaces é incorporada ao produto para definir permissões em um nível granular.
6. Gerenciamento de Segredos: A TrueFoundry se integra com Hashcorp Vault, GCP Secrets Manager e AWS Parameter Store para gerenciamento de segredos. Também planejamos adicionar a integração com Azure Vault e AWS Secrets Manager.
7. Motor de Fluxo de Trabalho: A TrueFoundry se integra com ArgoWorkflows para fornecer um motor de fluxo de trabalho aos cientistas de dados.

Arquitetura TrueFoundry

A TrueFoundry oferece uma arquitetura de plano dividido que compreende os seguintes componentes principais:

1. Plano de Controle: Este é o cérebro do sistema TrueFoundry, que orquestra as implantações entre os diferentes planos de computação. Oferecemos um plano de controle hospedado em nosso plano padrão. Para clientes empresariais, o plano de controle também pode ser implantado na nuvem dos clientes.
2. Plano de Computação: Este é o cluster Kubernetes onde o código do usuário é executado. Há um agente no plano de computação (tfy-agent) que se comunica com o plano de controle e executa os comandos recebidos do plano de controle. O código do usuário que acessa os dados é executado no plano de computação – e, portanto, o cluster do plano de computação deve estar próximo aos dados.

3. Interfaces de Cliente: Desenvolvedores e cientistas de dados podem se comunicar com a UI usando um SDK Python, nossa UI web ou as CLIs da TrueFoundry (servicefoundry e mlfoundry). A TrueFoundry também expõe APIs para que os clientes construam fluxos de trabalho de automação, que estão documentadas aqui: https://docs.truefoundry.com/reference

4. Servidor de Autenticação: Existe um servidor central de autenticação e licenciamento que mantém o controle de todas as organizações e seus membros. Este servidor é hospedado pela TrueFoundry e também pode se integrar com IDPs externos para fornecer uma experiência de logon único a todos os nossos usuários.

Vantagens desta arquitetura

Rede Segura

O componente tfy-agent não possui entrada (ingress) e é responsável por iniciar a conexão com o plano de controle. Ele estabelece uma conexão criptografada persistente com o plano de controle, através da qual a comunicação ocorre. Isso permite que o sistema funcione mesmo que os clusters do plano de computação sejam privados ou estejam em VPCs diferentes. A única restrição é que a URL do plano de controle deve ser acessível a todos os clusters do plano de computação. Você também pode controlar as permissões concedidas ao tfy-agent usando o Kubernetes RBAC para ter acesso a determinados namespaces.

Dependência flexível do plano de controle Truefoundry

O plano de controle do Truefoundry é responsável apenas por orquestrar as implantações para o plano de computação. Ele não está no caminho crítico do fluxo de requisições para os serviços implantados. Assim, mesmo que você remova o plano de controle do Truefoundry, todos os serviços implantados continuam a funcionar sem problemas. Esse desacoplamento da confiabilidade do serviço do Truefoundry ajuda a garantir que o Truefoundry não esteja no caminho crítico da confiabilidade do serviço.

Gerenciamento Eficiente de Múltiplos Clusters

O Plano de Controle do Truefoundry oferece uma visão unificada para visualizar todos os clusters Kubernetes em provedores de nuvem e on-premise na empresa. Isso também facilita bastante a movimentação de cargas de trabalho de um cluster para outro usando nosso recurso de Clonar e Promover.

Menor custo e manutenção

O agente Truefoundry é um componente muito leve que reside em cada cluster, enquanto é necessária apenas uma única cópia do plano de controle. O plano de controle requer mais recursos (3 CPU, 6 GB RAM), enquanto o agente precisa de apenas 0,2 CPU e 400 MB RAM. À medida que o volume de tráfego e o número de equipes aumentam, geralmente precisamos adicionar mais clusters com base em regiões ou equipes. Mas o plano de controle não precisa ser replicado, o que permite menor custo e manutenção.

Uma olhada no Plano de Controle do Truefoundry

O Plano de Controle do Truefoundry é composto por múltiplos microsserviços que orquestram as implantações, o armazenamento de metadados de modelo, etc. Os principais componentes do plano de controle do Truefoundry são:

1. UI Web

2. Microsserviços para orquestrar implantações: O plano de controle é composto por alguns microsserviços para orquestrar as implantações entre os clusters e também armazena em cache as atualizações em tempo real de todos os clusters conectados no plano de computação.

3. Banco de Dados Postgres: É usado para armazenar todas as informações sobre equipes, serviços implantados e seus metadados.

Cluster do Plano de Computação

Precisamos instalar alguns componentes no cluster do Plano de Computação para obter todos os benefícios do Truefoundry. A lista é a seguinte:

1. tfy-agent (Obrigatório): Este é o agente truefoundry que inicia a conexão com o plano de controle e ajuda a coordenar as instruções do plano de controle.
2. ArgoCD (Obrigatório): O ArgoCD é usado para aplicar todos os manifestos ao cluster Kubernetes. Isso é melhor do que fazer uma instalação via Helm porque o controlador ArgoCD garante que o estado interno esteja sincronizado com o estado desejado nos manifestos e não está sujeito a falhas de instalação do Helm.
3. Istio (Atualmente obrigatório, será opcional no futuro): Atualmente, dependemos do Istio como controlador de entrada para o cluster. Não exigimos a execução de sidecars do Istio e eles podem ser ativados opcionalmente, se necessário para casos de uso como TLS mútuo. Também planejamos usar as APIs Gateway do Kubernetes, o que nos permitirá trabalhar com múltiplos controladores de entrada como Nginx, Linkerd, Traefik, etc.
4. Argo Workflows (Obrigatório apenas para execução de tarefas): Utilizamos o ArgoWorkflows para executar todas as tarefas dentro do cluster devido às opções mais avançadas que ele oferece em comparação com as tarefas do Kubernetes.
5. Argo Rollouts (Obrigatório): Utilizamos o ArgoRollouts para suportar implantações Canary e BlueGreen no Kubernetes. Atualmente, este é um pré-requisito obrigatório, mas será opcional no futuro.
6. Prometheus (Opcional): Esta é uma dependência opcional necessária para exibir métricas como CPU, memória, contagem de requisições para os serviços.
7. Keda (Opcional): Esta é uma dependência opcional e necessária se você quiser habilitar o autoescalonamento para suas cargas de trabalho.
8. Loki (Opcional): Isso ajuda na agregação de logs e é uma dependência opcional. Você sempre pode usar qualquer outro agregador de logs com o qual se sinta confortável, como ELK Stack, Cloudwatch, Datadog, etc.
9. Drivers (EFS, EBS, GPU): Eles são necessários se você precisar de suporte a GPU ou volume em seu cluster.
10. Controlador de Notebook (Opcional):  Isso é necessário se você quiser fornecer Notebooks no cluster Kubernetes.

Restrições na AMI do cluster Kubernetes

O Truefoundry pode funcionar com qualquer AMI subjacente, incluindo Bottlerocket na AWS. Como o agente é como qualquer outro gráfico Helm rodando no Kubernetes, não temos restrições ou requisitos das AMIs subjacentes e podemos rodar em qualquer AMI, incluindo máquinas bare metal.

Permissões para tfy-agent

O tfy-agent executa todas as ações no usuário Kubernetes em nome dos usuários logados na plataforma Truefoundry. Portanto, ele requer acesso de administrador em um determinado conjunto de namespaces nos quais os usuários têm permissão para implantar as aplicações. Temos funcionalidade para listar em lista negra ou lista branca um determinado conjunto de namespaces e o agente só pode executar ações nesses namespaces.

Autenticação no Truefoundry

O Truefoundry depende de um servidor de autenticação que reside em nossos servidores para licenciamento e autenticação.

Autorização no Truefoundry

O Truefoundry oferece controle RBAC granular em nível de tenant, cluster, workspace e repositório ML. Para entender os mecanismos RBAC no Truefoundry, você pode ler nossa documentação aqui: https://docs.truefoundry.com/docs/collaboration-and-access-control

Todas as regras de autorização residem na tabela Postgres no plano de controle, e cada chamada de API é verificada para determinar se o usuário está autorizado a realizar essa conexão.

Pipeline de Construção de Imagens no plano de controle

A Truefoundry oferece um pipeline básico de construção de imagens otimizado para construir imagens muito rapidamente no Kubernetes. Caso você queira personalizar o pipeline de construção de imagens para incluir verificações estáticas ou outras ferramentas de varredura de vulnerabilidades, há duas abordagens:

1. Você pode continuar usando seu próprio pipeline de CI para construir imagens e, em seguida, fornecer o URI da imagem construída como entrada para as implantações da Truefoundry.
2. Você pode personalizar o pipeline de construção da Truefoundry para incluir os componentes que desejar. É basicamente um ArgoWorkflow e, como você possui o plano de controle no plano Enterprise, você está livre para personalizá-lo como quiser.

Gerenciamento de Segredos na Truefoundry

Truefoundry integra-se com os armazenamentos de gerenciamento de segredos mais populares. Não armazena os valores dos segredos, apenas o caminho para eles.