Visão da TrueFoundry

Visão Geral: Uma plataforma para desenvolvedores que facilita a criação e gestão de serviços seguindo todas as melhores práticas e oferece uma visão geral completa da infraestrutura, incluindo monitoramento de sistemas, dados, custos e impacto, com foco inicial em Machine Learning!

Visão para a TrueFoundry (5 a 10 anos)

No seu cerne, a TrueFoundry visa tornar a experiência do desenvolvedor fluida para executar e gerenciar Microsserviços — onde, com o nível certo de abstrações, os desenvolvedores podem focar apenas em escrever a lógica de negócios em velocidades de iteração muito altas.

Imagine um fluxo onde, após escrever o código — eu possa chamar um gênio e informar meus requisitos, como o tipo de serviço (Serverless, CronJob, Banco de Dados, um serviço de API), requisitos de recursos como CPU, memória, etc., e o gênio cria o serviço com as melhores práticas como GitOps, Infraestrutura como Código (IAC) e então exibe um painel com todas as métricas criadas.

Queremos ser capazes de alcançar as seguintes coisas com o servicefoundry:

Provisionamento Centralizado de Infraestrutura usando IAC

O ServiceFoundry irá provisionar e hospedar os componentes de infraestrutura de código aberto mais comumente usados na nuvem do usuário. Alguns exemplos disso podem ser:

1. Lançar cluster Kubernetes com as melhores práticas de segurança configuradas.
2. Instalar componentes de infraestrutura centralizados (ou usar serviços gerenciados) como Kafka, Spark, Redis, Prometheus, Grafana, etc.
3. Podemos usar serviços gerenciados em nuvem para alguns deles, como AWS Elastic Search.
4. Lançar bancos de dados, camadas de armazenamento. (usar versões gerenciadas por enquanto)
5. Sistemas de orquestração de pipeline como Airflow, Argo, etc.
6. CI / CD (Github Actions, Gitlab, AWS Code Pipelines)
7. Agregação de Logs (ELK, EFK)
8. Monitoramento (Métricas padrão e personalizadas)
9. Alertas

Criar Serviço

1. Construir e implantar serviços com base em modelos configuráveis. O ServiceFoundry será um conjunto de princípios com uma abordagem específica para automatizar o seguinte:

• Gerenciamento e Empacotamento de Dependências (Docker, Zip)
• Testes
• Gerenciamento de Configuração (Configurações estáticas e dinâmicas)
• Provisionamento de infraestrutura (sobre infraestrutura centralizada provisionada anteriormente)
• Configuração de autoescalonamento
• CI/CD
• Agregação de logs
• Geração de Dashboards com métricas padrão (Usuários podem adicionar métricas personalizadas)
• Alertas

De forma semelhante ao acima, também queremos fazer o mesmo para Modelos de ML, Bancos de Dados.

A ServiceFoundry visa otimizar a implantação e o monitoramento dos tipos de serviços padrão:

1. Serviço de API com Balanceamento de Carga (com autoescalonamento baseado em diferentes parâmetros)
2. Serviço de Jobs (Tarefas Cron, tarefas acionadas por eventos)
3. Serverless
4. Serviços com Estado
5. Site Estático

Catálogo e Gráfico de Serviços

Todos os serviços criados usando a ServiceFoundry podem ser visualizados em um único local, juntamente com seus metadados completos. Este catálogo também exibirá todos os ambientes para cada aplicação, como dev, staging e prod. Isso resulta em um portal de plataforma para desenvolvedores onde desenvolvedores e líderes de negócios podem visualizar os serviços em execução na organização. Alguns dos principais metadados associados a cada serviço são:

1. Link para o Repositório Github
2. Configuração
3. Links de Monitoramento
4. Equipe e proprietários
5. Capacidade de adicionar membros com diferentes níveis de controle de acesso.
6. Custo

TrueFoundry MLOps (Plataforma ML First)

O foco inicial da TrueFoundry será fornecer uma plataforma MLOps contínua que se concentra no pipeline pós-construção do modelo e facilita muito para os cientistas de dados implantar, monitorar e retreinar seus modelos.

Um pipeline de aprendizado de máquina compreende a seguinte infraestrutura centralizada:

Uma breve explicação das diferentes etapas envolvidas:

1. Pipeline de Dados e Feature Store: Isso é essencialmente um problema de big data onde precisamos obter as features a serem usadas no modelo, computadas a partir do datalake e disponíveis dentro das restrições de tempo exigidas tanto para treinamento quanto para produção, sem disparidade. Geralmente, utiliza um motor de orquestração de fluxo de trabalho como Airflow, Argo, Kubeflow pipelines.
2. Treinamento de Modelo: O treinamento de modelo é essencialmente um trabalho distribuído que exige muito poder computacional e pode ser executado em várias máquinas. Ele também deve oferecer resiliência integrada através do salvamento e restauração de checkpoints.
3. Servir Modelos: Isso é basicamente um microsserviço que recebe requisições para fazer as previsões do modelo e pode ter requisitos variados como GPU, alto poder computacional e requisitos de memória. Cada modelo é geralmente hospedado como um único microsserviço — portanto, quando uma equipe escala para dezenas de modelos, torna-se um problema gerenciar dezenas de microsserviços, o que por si só já é um grande problema.
4. Monitoramento de Modelo: Isso inclui tanto o monitoramento de métricas do sistema quanto o monitoramento específico de aprendizado de máquina relacionado ao desempenho e à degradação do modelo. Isso também exige sistemas para armazenar os dados registrados, executar agregações neles e, finalmente, calcular as métricas.
5. Gerenciamento de Modelo: Isso rastreia todos os dados relacionados aos modelos e suas diferentes versões e experimentos. É altamente útil para depurar problemas posteriormente e reverter.

Devido a tantas partes móveis e diferentes tecnologias envolvidas, geralmente várias pessoas estão envolvidas em um projeto de ML, como Engenheiro de Dados, Cientista de Dados, Engenheiro de ML, DevOps e Gerente de Produto. Um projeto bem-sucedido exige a coordenação entre todas essas diferentes personas, o que leva a muitos atrasos e prejudica a velocidade de um cientista de dados.

Um fluxo de trabalho típico em empresas para um pipeline de aprendizado de máquina se parece com:

Objetivo principal da plataforma de ML

Queremos automatizar as partes do pipeline de ML que podem ser automatizadas e capacitar o cientista de dados a testar seus modelos em produção e iterar rapidamente, com o mínimo de dependências de outras equipes possível. Nossa motivação vem dos produtos criados por equipes de Plataforma em grandes empresas de tecnologia que permitem que todas as equipes se movam muito mais rápido e implementem e iterem por conta própria.

Não abordamos problemas relacionados a dados neste momento — essa seção será introduzida mais tarde.

Uma plataforma de ML fundamental é composta pelos seguintes serviços (além da infraestrutura central)

1. Treinamento (Um trabalho agendado com diferentes gatilhos)
2. Serviço de Modelo (Um Serviço de API com Balanceamento de Carga)
3. Armazenamento (Artefatos, conjuntos de dados, dados de inferência de modelo)
4. Serviço de Monitoramento de ML (Um serviço para calcular métricas a partir de dados)
5. Serviço de Engenharia de Features

Se pudermos implantar facilmente esses serviços, manter o versionamento em diferentes estágios e gerar monitoramento para cada um deles, o problema de ML Ops será muito mais simples.

Este blog foi publicado pela primeira vez no Medium em https://abhishekch09.medium.com/d8e159743a4b