Crie fluxos de trabalho de aprendizado de máquina de ponta a ponta repetíveis, seguros e extensíveis usando o Kubeflow na AWS

Esta é uma postagem de blog de convidado co-escrita com athenahealth.

athenahealth um fornecedor líder de software e serviços habilitados para rede para grupos médicos e sistemas de saúde em todo o país. Seus registros eletrônicos de saúde, gerenciamento do ciclo de receita e ferramentas de envolvimento do paciente permitem acesso a qualquer hora e em qualquer lugar, gerando melhores resultados financeiros para seus clientes e permitindo que seus clientes fornecedores ofereçam atendimento de melhor qualidade.

No espaço de inteligência artificial (IA), a athenahealth usa ciência de dados e aprendizado de máquina (ML) para acelerar processos de negócios e fornecer recomendações, previsões e insights em vários serviços. Desde sua primeira implementação em serviços automatizados de documentos, processando sem contato milhões de documentos de provedor-paciente, até seu trabalho mais recente em assistentes virtuais e melhorando o desempenho do ciclo de receita, athenahealth continua aplicando IA para ajudar a aumentar a eficiência, recursos de serviço e melhores resultados para os provedores e seus pacientes.

Esta postagem no blog demonstra como o athenahealth usa Kubeflow na AWS (uma distribuição de Kubeflow específica da AWS) para criar e otimizar um fluxo de trabalho de ciência de dados de ponta a ponta que preserva as ferramentas essenciais, otimiza a eficiência operacional, aumenta a produtividade do cientista de dados e prepara o cenário para ampliar seus recursos de ML com mais facilidade.

Kubeflow é a plataforma de ML de código aberto dedicada a tornar as implantações de fluxos de trabalho de ML no Kubernetes simples, portáteis e escaláveis. O Kubeflow consegue isso incorporando ferramentas de código aberto relevantes que se integram bem ao Kubernetes. Alguns desses projetos incluem Argo para orquestração de pipeline, Istio para service mesh, Jupyter para notebooks, Spark, TensorBoard e Katib. O Kubeflow Pipelines ajuda a criar e implantar fluxos de trabalho de ML portáteis e escaláveis ​​que podem incluir etapas como extração de dados, pré-processamento, treinamento de modelo e avaliação de modelo na forma de pipelines repetíveis.

A AWS está contribuindo para a comunidade Kubeflow de código aberto fornecendo sua própria distribuição Kubeflow (chamada Kubeflow na AWS) que ajuda organizações como athenahealth a criar fluxos de trabalho de ML altamente confiáveis, seguros, portáteis e escaláveis ​​com sobrecarga operacional reduzida por meio da integração com serviços gerenciados da AWS. A AWS oferece várias opções de implantação do Kubeflow, como implantação com Amazon Cognito, implantação com Serviço de banco de dados relacional da Amazon (Amazon RDS) e Serviço de armazenamento simples da Amazon (Amazon S3) e implantação de baunilha. Para obter detalhes sobre integração de serviços e complementos disponíveis para cada uma dessas opções, consulte desenvolvimento.

Hoje, o Kubeflow na AWS oferece um caminho claro para usar o Kubeflow, aprimorado com os seguintes serviços da AWS:

Muitos clientes da AWS estão aproveitando a distribuição do Kubeflow na AWS, incluindo athenahealth.

Aqui, a equipe de MLOps da athenahealth discute os desafios que encontraram e as soluções que criaram em sua jornada no Kubeflow.

Desafios com o ambiente de ML anterior

Antes de adotarmos o Kubeflow na AWS, nossos cientistas de dados usavam um conjunto padronizado de ferramentas e um processo que permitia flexibilidade na tecnologia e no fluxo de trabalho usados ​​para treinar um determinado modelo. Os componentes de exemplo das ferramentas padronizadas incluem uma API de ingestão de dados, ferramentas de verificação de segurança, o pipeline de CI/CD criado e mantido por outra equipe dentro do athenahealth e uma plataforma de serviço comum criada e mantida pela equipe de MLOps. No entanto, à medida que nosso uso de IA e ML amadureceu, a variedade de ferramentas e infraestrutura criadas para cada modelo cresceu. Embora ainda pudéssemos apoiar o processo existente, vimos os seguintes desafios no horizonte:

• Manutenção e crescimento – Reproduzir e manter ambientes de treinamento de modelo exigiu mais esforço à medida que o número de modelos implantados aumentou. Cada projeto mantinha uma documentação detalhada que descrevia como cada script era usado para construir o modelo final. Em muitos casos, este foi um processo elaborado envolvendo 5 a 10 scripts com várias saídas cada. Eles precisavam ser rastreados manualmente com instruções detalhadas sobre como cada saída seria usada nos processos subsequentes. Manter isso ao longo do tempo tornou-se complicado. Além disso, à medida que os projetos se tornaram mais complexos, o número de ferramentas também aumentou. Por exemplo, a maioria dos modelos utilizava Spark e TensorFlow com GPUs, o que exigia uma variedade maior de configurações de ambiente. Com o tempo, os usuários mudariam para versões mais recentes de ferramentas em seus ambientes de desenvolvimento, mas não poderiam executar scripts mais antigos quando essas versões se tornassem incompatíveis. Consequentemente, manter e aumentar projetos mais antigos exigia mais tempo e esforço de engenharia. Além disso, à medida que novos cientistas de dados se juntavam à equipe, as transferências de conhecimento e a integração demoravam mais, porque a sincronização de ambientes locais incluía muitas dependências não documentadas. Alternar entre projetos enfrentou os mesmos problemas porque cada modelo tinha seus próprios fluxos de trabalho.
• Segurança – Levamos a segurança a sério e, portanto, priorizamos a conformidade com todas as obrigações contratuais, legais e regulatórias associadas ao ML e à ciência de dados. Os dados devem ser utilizados, armazenados e acessados ​​de maneiras específicas, e incorporamos processos robustos para garantir que nossas práticas cumpram nossas obrigações legais, bem como se alinhem às melhores práticas do setor. Antes da adoção do Kubeflow, garantir que os dados fossem armazenados e acessados ​​de uma maneira específica envolvia a verificação regular em vários fluxos de trabalho diversos. Sabíamos que poderíamos melhorar a eficiência consolidando esses diversos fluxos de trabalho em uma única plataforma. No entanto, essa plataforma precisaria ser flexível o suficiente para se integrar bem com nossas ferramentas padronizadas.
• Operações – Também vimos uma oportunidade de aumentar a eficiência operacional e a gestão por meio da centralização do registro e monitoramento dos fluxos de trabalho. Como cada equipe desenvolveu suas próprias ferramentas, coletamos essas informações de cada fluxo de trabalho individualmente e as agregamos.

A equipe de ciência de dados avaliou várias soluções para consolidar os fluxos de trabalho. Além de atender a esses requisitos, procuramos uma solução que se integrasse perfeitamente à infraestrutura e às ferramentas padronizadas existentes. Selecionamos o Amazon EKS e o Kubeflow na AWS como nossa solução de fluxo de trabalho.

O ciclo de desenvolvimento do cientista de dados incorporando o Kubeflow

Um projeto de ciência de dados começa do zero: sem dados, sem código, apenas o problema de negócios que pode ser resolvido com ML. A primeira tarefa é uma prova de conceito (POC) para descobrir se os dados contêm sinal suficiente para tornar um modelo de ML eficaz na solução do problema de negócios, começando com a consulta do conjunto de dados brutos de nosso data warehouse Snowflake. Esse estágio é iterativo, e os cientistas de dados usam pods do Kubernetes ou notebooks Kubeflow Jupyter durante esse processo.

Nosso cluster Kubeflow usa o autoescalador de cluster Karpenter, que facilita a criação de recursos para os cientistas de dados, pois eles só precisam se concentrar na definição dos tipos de instância desejados, enquanto o trabalho de provisionamento é feito por um conjunto de provisionadores Karpenter predefinidos. Temos provisionadores separados para tipos de instância de CPU e GPU, e todas as instâncias compatíveis com o Amazon EKS se enquadram em uma dessas duas categorias de acordo com nossa configuração de provisionador. Os cientistas de dados escolhem os tipos de instância usando seletores de nós, e o Karpenter cuida do gerenciamento do ciclo de vida do nó.

Depois que a consulta é desenvolvida, os cientistas de dados extraem os dados brutos para um local no Amazon S3 e, em seguida, iniciam um notebook Jupyter da interface do usuário do AWS Kubeflow para explorar os dados. O objetivo é criar o conjunto de recursos que será usado para treinar o primeiro modelo. Isso permite que os cientistas de dados determinem se há sinal suficiente nos dados para atender às necessidades de negócios do cliente.

Depois que os resultados são satisfatórios, os cientistas de dados passam para o próximo estágio do ciclo de desenvolvimento e transformam suas descobertas em um pipeline robusto. Eles convertem o código POC em código de qualidade de produção que é executado em escala. Para garantir a conformidade por meio do uso de bibliotecas aprovadas, um contêiner é criado com a imagem de base apropriada do Docker. Para nossos cientistas de dados, descobrimos que fornecer uma imagem de base padrão Python, TensorFlow e Spark oferece flexibilidade suficiente para a maioria das cargas de trabalho, se não todas. Eles podem usar o Dockerfile de seu componente para personalizar ainda mais seu ambiente de desenvolvimento. Esse Dockerfile é então utilizado pelo processo de CI/CD para construir a imagem de componentes que será usada na produção, mantendo assim a consistência entre os ambientes de desenvolvimento e produção.

Temos uma ferramenta que dá aos cientistas de dados a capacidade de lançar seu ambiente de desenvolvimento em um pod executado no Kubernetes. Quando esse pod está em execução, os cientistas de dados podem anexar o IDE do Visual Studio Code diretamente ao pod e depurar seu código de modelo. Depois de executar o código com sucesso, eles podem enviar suas alterações para o git e um novo ambiente de desenvolvimento é criado com as alterações mais recentes.

O pipeline padrão de ciência de dados consiste em estágios que incluem extração, pré-processamento, treinamento e avaliação. Cada estágio no pipeline aparece como um componente no Kubeflow, que consiste em um pod do Kubernetes que executa um comando com algumas informações passadas como parâmetros. Esses parâmetros podem ser valores estáticos ou referências à saída de um componente anterior. A imagem do Docker usada no pod é criada a partir do processo de CI/CD. Os detalhes desse processo aparecem no fluxo de trabalho de CI/CD discutido na próxima seção.

Ciclo de Desenvolvimento no Kubeflow. O fluxo de trabalho de desenvolvimento começa à esquerda com o POC. O modelo concluído é implantado na plataforma de serviço de modelo athenahealth em execução no Amazon ECS.

Processo de CI/CD que suporta fluxos de trabalho automatizados

Como parte de nosso processo de CI/CD, usamos o Jenkins para criar e testar todas as imagens de componentes do Kubeflow em paralelo. Após a conclusão bem-sucedida, o modelo de componente de pipeline contém ponteiros de referência para as imagens e o pipeline resultante é carregado no Kubeflow. Os parâmetros no pipeline do Jenkins permitem que os usuários iniciem os pipelines e executem seus testes de treinamento de modelo após compilações bem-sucedidas.

Como alternativa, para manter um ciclo de desenvolvimento curto, os cientistas de dados também podem iniciar o pipeline de sua máquina local, modificando quaisquer parâmetros de pipeline que possam estar experimentando.

Existem ferramentas para garantir que os ponteiros de referência da compilação CI/CD sejam utilizados por padrão. Se houver um artefato implantável no repositório, a lógica de CI/CD continuará a implantar o artefato na plataforma de serviço de modelo athenahealth (o Serviço de previsão) em execução no Amazon ECS com AWS Fargate. Após todos esses estágios terem passado, o cientista de dados mescla o código com o branch primário. Os pipelines e artefatos implantáveis ​​são então enviados para produção.

Fluxo de trabalho de implantação de CI/CD. Este diagrama descreve o fluxo de trabalho de compilação e implantação do Data Science. O processo de CI/CD é conduzido por Jenkins.

Segurança

Ao consolidar nossos fluxos de trabalho de ciência de dados, conseguimos centralizar nossa abordagem para proteger o pipeline de treinamento. Nesta seção, discutimos nossa abordagem à segurança de dados e cluster.

A segurança dos dados

A segurança dos dados é de extrema importância na athenahealth. Por esse motivo, desenvolvemos e mantemos uma infraestrutura totalmente compatível com os regulamentos e normas que protegem a segurança e a integridade desses dados.

Para garantir que atendemos aos padrões de conformidade de dados, provisionamos nossa infraestrutura da AWS de acordo com nossas diretrizes corporativas athenahealth. Os dois principais armazenamentos de dados são o Amazon RDS para metadados de pipeline altamente escaláveis ​​e o Amazon S3 para artefatos de pipeline e modelo. Para o Amazon S3, garantimos que os buckets sejam criptografados, os endpoints HTTPS sejam aplicados e as políticas de bucket e Gerenciamento de acesso e identidade da AWS (IAM) as funções seguem os princípios de privilégio mínimo ao permitir o acesso aos dados. Isso também vale para os dados do Amazon RDS: a criptografia está sempre habilitada e os grupos de segurança e o acesso a credenciais seguem o princípio de privilégio mínimo. Essa padronização garante que apenas as partes autorizadas tenham acesso aos dados e esse acesso seja rastreado.

Além dessas medidas, a plataforma também passa por avaliações de ameaças à segurança e verificações contínuas de segurança e conformidade.

Também atendemos aos requisitos de retenção de dados por meio do gerenciamento do ciclo de vida dos dados para todos os buckets do S3 que contêm dados confidenciais. Esta política move automaticamente os dados para Geleira Amazon S3 após 30 dias da criação. Exceções a isso são gerenciadas por meio de solicitações de recuperação de dados e são aprovadas ou negadas caso a caso. Isso garante que todos os fluxos de trabalho estejam em conformidade com a política de retenção de dados. Isso também resolve o problema com a recuperação de dados se um modelo tiver um desempenho insatisfatório e for necessário um novo treinamento ou quando um novo modelo precisar ser avaliado em relação a uma iteração histórica do conjunto de dados de um modelo mais antigo.

Para restringir o acesso ao Amazon S3 e Amazon RDS de dentro do Kubeflow na AWS e Amazon EKS, usamos IRSA (IAM Roles for Service Accounts), que fornece provisionamento de permissão baseado em IAM para recursos no Kubernetes. Cada locatário no Kubeflow tem uma conta de serviço pré-criada exclusiva que associamos a uma função do IAM criada especificamente para atender aos requisitos de acesso de locatário. O acesso do usuário aos locatários também é restrito usando a associação ao grupo de grupos de usuários do Amazon Cognito para cada usuário. Quando um usuário é autenticado no cluster, o token gerado contém declarações de grupo e o Kubernetes RBAC usa essas informações para permitir ou negar acesso a um recurso específico no cluster. Essa configuração é explicada com mais detalhes na próxima seção.

Segurança de cluster usando isolamento multiusuário

Conforme observamos na seção anterior, os cientistas de dados realizam análises exploratórias de dados, executam análises de dados e treinam modelos de ML. Para alocar recursos, organizar dados e gerenciar fluxos de trabalho com base em projetos, o Kubeflow na AWS fornece isolamento com base em namespaces do Kubernetes. Esse isolamento funciona para interagir com a IU do Kubeflow; no entanto, ele não fornece nenhuma ferramenta para controlar o acesso à API do Kubernetes usando o Kubectl. Isso significa que o acesso do usuário pode ser controlado na interface do usuário do Kubeflow, mas não na API do Kubernetes via Kubectl.

A arquitetura descrita no diagrama a seguir resolve esse problema unificando o acesso a projetos no Kubeflow com base em associações de grupo. Para isso, aproveitamos os manifestos do Kubeflow on AWS, que têm integração com grupos de usuários do Amazon Cognito. Além disso, usamos o controle de acesso baseado em função (RBAC) do Kubernetes para controlar a autorização no cluster. As permissões do usuário são provisionadas com base na associação ao grupo do Amazon Cognito. Essas informações são passadas ao cluster com o token gerado pelo cliente OIDC. Esse processo é simplificado graças à funcionalidade integrada do Amazon EKS que permite associar provedores de identidade OIDC para autenticar com o cluster.

Por padrão, a autenticação do Amazon EKS é realizada pelo autenticador do IAM, que é uma ferramenta que permite a autenticação com um cluster EKS usando credenciais do IAM. Este método de autenticação tem seus méritos; no entanto, não é adequado para nosso caso de uso porque o athenahealth usa o Microsoft Azure Active Directory para serviço de identidade em toda a organização.

Isolamento de namespace do Kubernetes. Os Cientistas de Dados podem obter associação a um único ou vários grupos conforme necessário para seu trabalho. O acesso é revisado regularmente e removido conforme apropriado.

O Azure Active Directory, sendo um serviço de identidade de toda a empresa, é a fonte da verdade para controlar o acesso do usuário ao cluster Kubeflow. A configuração para isso inclui a criação de um aplicativo corporativo do Azure que atua como principal de serviço e a adição de grupos para vários locatários que exigem acesso ao cluster. Essa configuração no Azure é espelhada no Amazon Cognito configurando um provedor de identidade OIDC federado que terceiriza a responsabilidade de autenticação para o Azure. O acesso aos grupos do Azure é controlado pelo SailPoint IdentityIQ, que envia solicitações de acesso ao proprietário do projeto para permitir ou negar conforme apropriado. No grupo de usuários do Amazon Cognito, dois clientes de aplicativos são criados: um é usado para configurar a autenticação do cluster Kubernetes usando o provedor de identidade OIDC e o outro para proteger a autenticação do Kubeflow na interface do usuário do Kubeflow. Esses clientes são configurados para passar declarações de grupo na autenticação com o cluster e essas declarações de grupo são usadas junto com o RBAC para configurar a autorização no cluster.

As vinculações de função RBAC do Kubernetes são configuradas entre grupos e a função de cluster Kubeflow-edit, que é criada ao instalar o Kubeflow no cluster. Essa associação de função garante que qualquer usuário que interaja com o cluster após efetuar login via OIDC possa acessar os namespaces para os quais eles têm permissões, conforme definido em suas declarações de grupo. Embora isso funcione para usuários que interagem com o cluster usando Kubectl, a IU do Kubeflow atualmente não fornece acesso a usuários com base na associação ao grupo porque não usa RBAC. Em vez disso, ele usa o recurso Política de autorização do Istio para controlar o acesso dos usuários. Para superar esse desafio, desenvolvemos um controlador personalizado que sincroniza usuários pesquisando grupos do Amazon Cognito e adiciona ou remove associações de função correspondentes para cada usuário, e não por grupo. Essa configuração permite que os usuários tenham o mesmo nível de permissões ao interagir com a IU do Kubeflow e o Kubectl.

Eficiência operacional

Nesta seção, discutimos como aproveitamos as ferramentas de código aberto e da AWS disponíveis para gerenciar e depurar nossos fluxos de trabalho, bem como minimizar o impacto operacional da atualização do Kubeflow.

Registro e monitoramento

Para registro, utilizamos FluentD para enviar todos os nossos registros de contêiner para Serviço Amazon OpenSearch e métricas do sistema para o Prometheus. Em seguida, usamos o Kibana e a interface do usuário do Grafana para pesquisar e filtrar logs e métricas. O diagrama a seguir descreve como configuramos isso.

Registro do Kubeflow. Usamos a interface do usuário do Grafana e o Kibana para visualizar e filtrar os logs

A captura de tela a seguir é uma visualização da interface do usuário do Kibana do nosso pipeline.

Exemplo de visualização da interface do usuário do Kibana. O Kibana permite visualizações personalizadas.

Atualizações seguras de cluster Kubeflow

À medida que integramos os usuários ao Kubeflow na AWS, mantemos uma experiência de usuário confiável e consistente, ao mesmo tempo em que permitimos que a equipe de MLOps permaneça ágil no lançamento e na integração de novos recursos. Na superfície, Kustomize parece modular para que possamos trabalhar e atualizar um componente de cada vez sem afetar os outros, permitindo assim adicionar novos recursos com o mínimo de interrupção para os usuários. No entanto, na prática, existem cenários em que a melhor abordagem é simplesmente criar um novo cluster Kubernetes em vez de aplicar atualizações em nível de componente para clusters existentes. Encontramos dois casos de uso em que fazia mais sentido criar clusters completamente novos:

• Atualizar para uma versão do Kubernetes em que a AWS fornece atualizações de cluster no local. No entanto, fica difícil testar se cada um dos recursos do Kubeflow e do Kubernetes está funcionando conforme o esperado e os manifestos mantêm a compatibilidade com versões anteriores.
• Atualizar o Kubeflow para uma versão mais recente onde há vários recursos adicionados ou modificados e quase sempre não é uma ideia promissora realizar atualizações in-loco em um cluster Kubernetes existente.

Ao abordar esse problema, desenvolvemos uma estratégia que nos permite ter substituições seguras de cluster sem afetar nenhuma carga de trabalho existente. Para isso, tivemos que atender aos seguintes critérios:

• Separe os recursos de armazenamento e computação do Kubeflow para que os metadados do pipeline, os artefatos do pipeline e os dados do usuário sejam retidos ao desprovisionar o cluster mais antigo
• Integre-se ao Kubeflow nos manifestos da AWS para que, quando ocorrer uma atualização de versão do Kubeflow, sejam necessárias alterações mínimas
• Tenha uma maneira fácil de reverter se as coisas derem errado após a atualização do cluster
• Ter uma interface simples para promover um cluster candidato à produção

O diagrama a seguir ilustra essa arquitetura.

Atualização segura do cluster Kubeflow. Depois que o teste do Kubeflow Candidate for bem-sucedido, ele será promovido ao Kubeflow Prod por meio de uma atualização para o Route 53.

Os manifestos do Kubeflow na AWS vêm pré-empacotados com integrações do Amazon RDS e Amazon S3. Com esses serviços gerenciados atuando como armazenamentos de dados comuns, podemos configurar uma estratégia de implantação azul-verde. Para conseguir isso, garantimos que os metadados do pipeline sejam persistidos no Amazon RDS, que funciona independentemente do cluster EKS, e que os logs e artefatos do pipeline sejam persistidos no Amazon S3. Além de metadados e artefatos de pipeline, também configuramos o FluentD para rotear logs de pod para o Amazon OpenSearch Service.

Isso garante que a camada de armazenamento seja completamente separada da camada de computação e, assim, permite testar as alterações durante as atualizações de versão do Kubeflow em um cluster EKS completamente novo. Depois que todos os testes forem bem-sucedidos, podemos simplesmente alterar o Amazon Route 53 Registro DNS para o cluster candidato que hospeda o Kubeflow. Além disso, mantemos o cluster antigo em execução como backup por alguns dias, caso precisemos reverter.

Benefícios do Amazon EKS e do Kubeflow na AWS para nosso pipeline de ML

O Amazon EKS e o pacote Kubeflow on AWS moveram nosso fluxo de trabalho de desenvolvimento para um padrão que incentiva fortemente o treinamento de modelo repetível. Essas ferramentas nos permitem ter clusters totalmente definidos com locatários totalmente definidos e executar código totalmente definido.

Muitas vitórias da construção dessa plataforma são menos quantitativas e têm mais a ver com a forma como os fluxos de trabalho melhoraram tanto para os desenvolvedores quanto para os usuários da plataforma. Por exemplo, o MinIO foi substituído pelo acesso direto ao Amazon S3, o que nos aproxima de nossos fluxos de trabalho originais e reduz o número de serviços que devemos manter. Também podemos utilizar o Amazon RDS como back-end para Kubeflow, o que permite migrações mais fáceis entre clusters e nos dá a capacidade de fazer backup de nossos pipelines todas as noites.

Também consideramos benéficas as melhorias na integração do Kubeflow com os serviços gerenciados da AWS. Por exemplo, com Amazon RDS, Amazon S3 e Amazon Cognito pré-configurados nos manifestos do Kubeflow na AWS, economizamos tempo e esforço na atualização para distribuições mais recentes do Kubeflow. Quando costumávamos modificar manualmente os manifestos oficiais do Kubeflow, a atualização para uma nova versão demorava várias semanas, do design ao teste.

A mudança para o Amazon EKS nos dá a oportunidade de definir nosso cluster no Kustomize (agora parte do Kubectl) e no Terraform. Acontece que, para o trabalho de plataforma, o Kubernetes e o Terraform são muito fáceis de trabalhar depois de dedicar tempo suficiente para aprender. Após muitas iterações, as ferramentas disponíveis facilitam muito a execução de operações de plataforma padrão, como atualizar um componente ou trocar um cluster de desenvolvimento inteiro. Em comparação com a execução de trabalhos em bruto Amazon Elastic Compute Nuvem (Amazon EC2), é difícil comparar a enorme diferença que faz ter pods bem definidos com limpeza de recursos garantida e mecanismos de repetição integrados.

O Kubernetes fornece ótimos padrões de segurança e apenas arranhamos a superfície do que o isolamento multiusuário nos permite fazer. Vemos o isolamento multiusuário como um padrão que tem mais retorno no futuro, quando a plataforma de treinamento produz dados em nível de produção e trazemos desenvolvedores de fora de nossa equipe.

Enquanto isso, o Kubeflow nos permite ter um treinamento de modelo reproduzível. Mesmo com os mesmos dados, nenhum treinamento produz modelos idênticos, mas temos a próxima melhor coisa. Com o Kubeflow, sabemos exatamente qual código e dados foram usados ​​para treinar um modelo. A integração melhorou muito porque cada etapa do nosso pipeline é definida de forma clara e programática. Quando novos cientistas de dados têm a tarefa de corrigir um bug, eles precisam de muito menos apoio porque há uma estrutura clara de como as saídas de código são usadas entre os estágios.

O uso do Kubeflow também gera muitas melhorias de desempenho em comparação com a execução em uma única instância do EC2. Muitas vezes, no treinamento de modelos, os cientistas de dados precisam de diferentes ferramentas e otimizações para pré-processamento e treinamento. Por exemplo, o pré-processamento geralmente é executado usando ferramentas de processamento de dados distribuídos, como o Spark, enquanto o treinamento geralmente é executado usando instâncias de GPU. Com os pipelines do Kubeflow, eles podem especificar diferentes tipos de instância para diferentes estágios no pipeline. Isso permite que eles usem as poderosas instâncias de GPU em um estágio e uma frota de máquinas menores para processamento distribuído em outro estágio. Além disso, como os pipelines do Kubeflow descrevem as dependências entre os estágios, os pipelines podem executar estágios em paralelo.

Por fim, como criamos um processo para adicionar locatários ao cluster, agora há uma maneira mais formal de registrar equipes em um locatário no cluster. Como usamos o Kubecost para rastrear custos em nosso cluster EKS, ele nos permite atribuir custos a um único projeto, em vez de atribuir custos no nível da conta, que inclui todos os projetos de ciência de dados. O Kubecost apresenta um relatório do dinheiro gasto por namespace, que é fortemente acoplado ao locatário ou equipe responsável por executar o pipeline.

Apesar de todos os benefícios, alertamos para realizar esse tipo de migração apenas se houver total adesão dos usuários. Os usuários que dedicam tempo obtêm muitos benefícios ao usar o Amazon EKS e o Kubernetes, mas há uma curva de aprendizado significativa.

Conclusão

Com a implementação do Kubeflow no pipeline da AWS em nossa infraestrutura de ML de ponta a ponta, conseguimos consolidar e padronizar nossos fluxos de trabalho de ciência de dados, mantendo nossas ferramentas essenciais (como CI/CD e serviço de modelo). Nossos cientistas de dados agora podem alternar entre projetos com base nesse fluxo de trabalho sem a sobrecarga de aprender a manter um conjunto de ferramentas completamente diferente. Para alguns de nossos modelos, também ficamos agradavelmente surpresos com a velocidade do novo fluxo de trabalho (cinco vezes mais rápido), que permitiu mais iterações de treinamento e, consequentemente, a produção de modelos com melhores previsões.

Também estabelecemos uma base sólida para aumentar nossos recursos de MLOps e dimensionar o número e o tamanho de nossos projetos. Por exemplo, à medida que fortalecemos nossa postura de governança na linhagem e rastreamento de modelos, reduzimos nosso foco de mais de 15 fluxos de trabalho para apenas um. E quando a vulnerabilidade do Log4shell veio à tona no final de 2021, conseguimos nos concentrar em um único fluxo de trabalho e remediar rapidamente conforme necessário (realizando Registro do Amazon Elastic Container (Amazon ECR), atualização do Amazon OpenSearch Service, atualização de nossas ferramentas e muito mais) com impacto mínimo no trabalho contínuo dos cientistas de dados. À medida que os aprimoramentos da AWS e do Kubeflow se tornam disponíveis, podemos incorporá-los como acharmos melhor.

Isso nos leva a um aspecto importante e discreto de nossa adoção do Kubeflow na AWS. Um dos resultados críticos dessa jornada é a capacidade de implementar atualizações e aprimoramentos no Kubeflow perfeitamente para nossos cientistas de dados. Embora tenhamos discutido nossa abordagem para isso anteriormente, também contamos com os manifestos do Kubeflow fornecidos pela AWS. Iniciamos nossa jornada no Kubeflow como uma prova de conceito em 2019, antes do lançamento da versão 1.0.0. (Atualmente, estamos na versão 1.4.1, avaliando a versão 1.5. A AWS já está trabalhando na versão 1.6.) Nos três anos seguintes, houve pelo menos seis lançamentos com conteúdo substancial. Por meio de sua abordagem disciplinada para integrar e validar essas atualizações e liberar os manifestos em um cronograma previsível e confiável, a equipe do Kubeflow na AWS tem sido crucial para permitir que a equipe de MLOps da athenahealth planeje nosso roteiro de desenvolvimento e, consequentemente, nossas alocações de recursos e áreas de foco , mais para o futuro com maior confiança.

Você pode seguir o Repositório do AWS Labs GitHub para rastrear todas as contribuições da AWS para o Kubeflow. Você também pode encontrar equipes da AWS no Kubeflow #AWS Canal Slack; seu feedback ajuda a AWS a priorizar os próximos recursos para contribuir com o projeto Kubeflow.

---

Sobre os autores

Kanwaljit Khurmi é arquiteto de soluções sênior da Amazon Web Services. Ele trabalha com os clientes da AWS para fornecer orientação e assistência técnica, ajudando-os a melhorar o valor de suas soluções ao usar a AWS. A Kanwaljit é especializada em ajudar os clientes com aplicativos em contêiner e de aprendizado de máquina.

Tyler Kalbach é Membro Principal do Corpo Técnico da athenahealth. Tyler tem aproximadamente 7 anos de experiência em análise, ciência de dados, redes neurais e desenvolvimento de aplicativos de aprendizado de máquina no espaço de saúde. Ele contribuiu para várias soluções de Machine Learning que atualmente atendem ao tráfego de produção. Atualmente trabalhando como cientista de dados principal na organização de engenharia da athenahealth, Tyler fez parte da equipe que construiu a nova plataforma de treinamento de aprendizado de máquina para a athenahealth desde o início desse esforço.

Victor Krylov é Membro Principal do Corpo Técnico da athenahealth. Victor é engenheiro e scrum master, ajudando cientistas de dados a criar pipelines de aprendizado de máquina rápidos e seguros. Na athenahealth, ele trabalhou em interfaces, pedidos clínicos, prescrições, agendamento, análises e agora aprendizado de máquina. Ele valoriza código escrito de forma limpa e bem testado por unidade, mas tem uma obsessão doentia por código de uma linha. Em seu tempo livre, ele gosta de ouvir podcasts enquanto passeia com seu cachorro.

Sasank Vemuri é um membro-chefe da equipe técnica da athenahealth. Ele tem experiência no desenvolvimento de soluções orientadas a dados em domínios como saúde, seguros e bioinformática. Atualmente, Sasank trabalha projetando e desenvolvendo plataformas de treinamento e inferência de machine learning na AWS e Kubernetes que ajudam no treinamento e na implantação de soluções de ML em escala.

Anu Tumkur é Arquiteto na athenahealth. Anu tem mais de duas décadas de experiência em arquitetura, design e desenvolvimento, construindo vários produtos de software em aprendizado de máquina, operações em nuvem, big data, pipelines de dados distribuídos em tempo real, tecnologia de anúncios, análise de dados, análise de mídia social. Anu atualmente trabalha como arquiteto na organização de Engenharia de Produto da athenahealth nas equipes de Machine Learning Platform e Data Pipeline.

William Tsen é Gerente Sênior de Engenharia da athenahealth. Ele tem mais de 20 anos de experiência em liderança de engenharia na construção de soluções em TI de saúde, computação distribuída de big data, redes ópticas inteligentes, sistemas de edição de vídeo em tempo real, software empresarial e subscrição de saúde em grupo. William atualmente lidera duas equipes incríveis na athenahealth, as equipes de engenharia de Machine Learning Operations e DevOps, na organização de Engenharia de Produto.