O blog da AWS

Roteiro para uma base empresarial de MLOps com o Amazon SageMaker

Por Dr. Sokratis Kartakis é Senior Machine Learning Specialist Solutions Architect;
Georgios Schinasé Specialist Solutions Architect em AI/ML;
Giuseppe Angelo Porcelli é Principal Machine Learning Specialist Solutions Architect; e
Shelbee Eigenbrode é Principal AI e Machine Learning Specialist Solutions Architect

 

À medida que as empresas adotam Aprendizado de Máquina (Machine Learning, ou ML) em suas organizações, fluxos de trabalho manuais para criar, treinar e implantar modelos de ML tendem a se tornar gargalos para a inovação. Para superar isso, as empresas precisam criar um processo operacional claro que defina como os vários papéis, desde cientistas de dados, engenheiros de dados, engenheiros de ML, engenheiros de TI e representantes comerciais, devem colaborar e interagir. Também, é preciso entender como separar interesses, responsabilidades e habilidades; e como tirar proveito dos serviços da AWS de uma forma ideal. Essa combinação de ML e operações, chamada MLOps, está ajudando as empresas a otimizarem seu ciclo de vida de ML, aumentar a produtividade dos cientistas de dados, enquanto, ao mesmo tempo, mantém a alta precisão de modelos e melhorar a segurança e conformidade regulatória.

 

Neste artigo, você aprenderá sobre as principais fases da criação de uma base de MLOps, como várias funções trabalham juntas nessa fundação e como as ferramentas do Amazon SageMaker e suas integrações com outros serviços da AWS podem acelerar a adoção de ML em uma empresa.

Modelo de maturidade de MLOps

Construir uma base de MLOps que possa atender às necessidades operacionais, de pessoal e de tecnologia dos clientes corporativos é um desafio. Portanto, definimos o seguinte modelo de maturidade que define as capacidades necessárias de MLOps em quatro fases principais.

 

  1. Fase Inicial: Durante essa fase, os cientistas de dados podem experimentar, criar, treinar e implantar modelos na AWS usando os serviços do Amazon SageMaker. O ambiente de desenvolvimento sugerido é o Amazon SageMaker Studio, onde cientistas de dados podem experimentar e colaborar com base nos notebooks do Amazon SageMaker Studio.
  2. Fase Repetível: Com a capacidade de experimentar na AWS, a próxima etapa é criar fluxos de trabalho automáticos para pré-processar dados, criar e treinar modelos, ou seja, pipelines de ML. Cientistas de dados colaboram com engenheiros de ML em um ambiente separado para criar código-fonte e algoritmos robustos e prontos para produção, orquestrados com o Amazon SageMaker Pipelines. Os modelos gerados são armazenados e comparados no Model Registry do Amazon SageMaker.
  3. Fase Confiável: Mesmo que os modelos tenham sido gerados por meio de pipelines de ML, eles devem ser testados antes de entrarem em produção. Portanto, nessa fase, a metodologia de teste automatizado é introduzida, tanto para o modelo quanto para a infraestrutura de ativação, em um ambiente de teste isolado (pré-produção) que simula a produção. Após a execução bem-sucedida dos testes, os modelos são implantados em um ambiente de produção isolado. Para implantar modelos em vários ambientes, avaliações e aprovações manuais podem ser necessárias.
  4. Fase Escalável: Após a implantação em produção da primeira solução de ML, é necessário escalar a base de MLOps para apoiar várias equipes de ciência de dados a colaborar e produzir dezenas ou centenas de casos de uso de ML. Nessa fase, introduzimos a construção de modelos de soluções, que agilizam a geração de valor ao reduzir o tempo de desenvolvimento de novas soluções em produção de semanas para dias. Além disso, automatizamos a criação de ambientes seguros de MLOps para permitir que várias equipes operem com seus dados, reduzindo a dependência e a sobrecarga do time de TI.

Nas seções a seguir, mostramos como criar uma base de MLOps baseado no modelo de maturidade anterior e nos seguintes princípios:

  • Flexibilidade: Os cientistas de dados podem se adaptar a qualquer framework (por exemplo, TensorFlow ou PyTorch).
  • Reprodutibilidade: Os cientistas de dados podem recriar ou observar experimentos anteriores (por exemplo, código, dados e resultados).
  • Reusabilidade: Os cientistas de dados e engenheiros de ML podem reutilizar o código-fonte e os pipelines de ML, evitando inconsistências e custos.
  • Escalabilidade: Os cientistas de dados e engenheiros de ML podem escalar recursos e serviços sob demanda.
  • Auditabilidade: Os cientistas de dados, departamentos jurídicos e de TI são capazes de auditar registros, versões e dependências de artefatos e dados.
  • Consistência: Como MLOps é composto por vários ambientes, a base deve eliminar a variação entre os ambientes.

Fase Inicial

Na fase inicial, o objetivo é criar um ambiente de experimentação seguro, em que o cientista de dados receba porções (snapshots) dos dados e experimente usando os notebooks do SageMaker para demonstrar que um problema de negócio específico pode ser resolvido com ML. Para conseguir isso, recomenda-se um ambiente do SageMaker Studio com acesso personalizado aos serviços AWS por meio de VPC Endpoints. O código-fonte da arquitetura de referência está disponível nos exemplos fornecidos pela equipe do SageMaker em Secure Data Science With Amazon SageMaker Studio Reference Architecture (em inglês).
Além dos serviços do SageMaker, os cientistas de dados podem usar outros serviços para processar dados, como o Amazon Athena e o AWS Glue, enquanto os notebooks são armazenados e versionados nos repositórios do AWS CodeCommit (veja a figura abaixo).

Fase Repetível

Depois que os cientistas de dados demonstrarem que o problema de negócio pode ser resolvido com ML e se familiarizarem com a experimentação, treinamento e implantação dos modelos no SageMaker, a próxima etapa é começar a produtizar a solução de ML. A figura a seguir ilustra essa arquitetura.

 

Nesse estágio, a separação de interesses é necessária. Dividimos o ambiente em várias contas da AWS:

  1. Data Lake: Ela armazena todos os dados ingeridos localmente (ou de outros sistemas) na nuvem. Os engenheiros de dados podem criar pipelines de extração, transformação e carregamento (Extract, Transform and Load, ou ETL) que combinam várias fontes de dados e preparam os conjuntos de dados necessários para os casos de uso de ML. Os dados são catalogados por meio do catálogo do AWS Glue e compartilhados com outros usuários e contas por meio do AWS Lake Formation (a camada de governança de dados). O Amazon SageMaker Feature Store pode ser implantado na mesma conta, mas não abordaremos isso neste artigo. Para obter mais informações, consulte Enable feature reuse across accounts and teams using Amazon SageMaker Feature Store (em inglês).
  2. Experimentação: Ela permite que cientistas de dados conduzam suas pesquisas. A única diferença é que a origem das porções (snapshots) de dados é o Data Lake. Os cientistas de dados têm acesso somente a conjuntos de dados específicos que podem ser anonimizados, no caso da LGPD ou de outras restrições de privacidade de dados. Além disso, a conta de experimentação pode ter acesso à Internet para permitir que cientistas de dados usem novos frameworks de ciência de dados ou bibliotecas de código aberto de terceiros. Portanto, a conta de experimentação é considerada parte do ambiente não produtivo.
  3. Desenvolvimento (Dev): A primeira etapa do ambiente de produção. Os cientistas de dados saem dos notebooks para o mundo dos fluxos de trabalho automatizados e do SageMaker Pipelines. Eles devem colaborar com engenheiros de ML para abstrair seu código e garantir a cobertura dos testes, o tratamento de erros e a qualidade do código. O objetivo é desenvolver pipelines de ML, que são fluxos de trabalho automáticos que pré-processam, treinam, avaliam e registram modelos no registro de modelos do SageMaker. A implantação de pipelines de ML é feita somente por meio de pipelines de CI/CD, e o acesso ao console da AWS é restrito. A conexão com a Internet não é permitida porque o pipeline de ML tem acesso aos dados de produção no Data Lake (somente leitura).
  4. Ferramentas (ou automação): Ela contém os repositórios do AWS CodeCommit, os pipelines de CI/CD do AWS CodePipeline, o registro de modelos SageMaker e o Amazon ECR para hospedar contêineres personalizados. Como o Data Lake é a única fonte confiável de dados, a conta de Ferramentas é para o código, os contêineres e os artefatos produzidos.

Lembre-se de que essa convenção de nomenclatura de contas e a estratégia de várias contas podem variar de acordo com as necessidades da empresa, mas essa estrutura tem como objetivo mostrar os níveis de isolamento recomendados. Por exemplo, o nome da conta de desenvolvimento pode ser alterado para uma conta de treinamento de modelos ou uma conta de construção.

Para alcançar o estado de implantação automática, é importante entender como migrar dos notebooks para os pipelines de ML e padronizar os repositórios de código e a estrutura de dados, que discutiremos nas seções a seguir.

De notebooks a pipelines de ML

O objetivo do ambiente de desenvolvimento é reestruturar, aumentar, melhorar e escalar o código em notebooks e transferi-lo para pipelines de ML. Um pipeline de ML é um conjunto de etapas responsáveis pelo pré-processamento dos dados, pelo treinamento ou pelo uso de modelos e pelo pós-processamento dos resultados. Cada etapa deve realizar exatamente uma tarefa (uma transformação específica) e ser abstrata o suficiente (por exemplo, passar nomes de colunas como parâmetros de entrada) para permitir a reutilização. O diagrama a seguir ilustra um exemplo de uma pipeline de ML.

Para implementar pipelines de ML, cientistas de dados (ou engenheiros de ML) usam o Amazon SageMaker Pipelines. Um pipeline do Amazon SageMaker é uma série de etapas interconectadas (SageMaker Processing Jobs, SageMaker Training Jobs, HPO) que são especificadas usando uma definição de pipeline JSON, usando uma SDK Python. Essa definição codifica um pipeline usando um Grafo Acíclico Dirigido (DAG). Esse DAG fornece informações sobre os requisitos e as relações entre cada etapa do seu pipeline de ML.

Dependendo do caso de uso, o pipeline de ML pode ser separado em dois tipos principais: treinamento e inferência em lote.

A figura a seguir ilustra o fluxo de um pipeline de treinamento de ML.

A fase de pré-processamento (Pre-Processing, na figura) pode consistir em várias etapas. Algumas transformações comuns de ciência de dados são divisão e amostragem de dados (conjuntos de treinamento, validação, testes), vetorização (One-hot encoding), agrupamento e normalização. A etapa treinamento de modelo (Model Training) pode ser um único trabalho (Job) de treinamento, se o cientista de dados souber a melhor configuração do modelo, ou um trabalho (Job) de otimização de hiperparâmetros (HPO), no qual a AWS define os melhores hiperparâmetros para o modelo (método Bayesiano, por exemplo) e produz o artefato do modelo correspondente. Na etapa avaliação do modelo (Model Evaluation), o artefato do modelo produzido é usado para fazer inferências no conjunto de dados de validação. O pipeline de ML então verifica se as métricas de precisão produzidas (como F1, precisão, percentis, por exemplo) superam os valores necessários. Se essa etapa for bem-sucedida, os artefatos e metadados do modelo serão movidos para o registro de modelos para uso em produção. Observe que a etapa de exportação dos dados de base (Export Baseline) aproveita a funcionalidade do Amazon SageMaker Model Monitor ao produzir objetos JSON com estatísticas que serão usadas posteriormente para detectar desvio do modelo (Model drift) e que podem ser armazenados no registro de modelos do SageMaker como metadados do modelo.

No caso da inferência em lote, os cientistas de dados são capazes de criar pipelines semelhantes, conforme ilustrado na figura a seguir.

A etapa de pré-processamento (Pre-Processing) da inferência em lote geralmente é a mesma da etapa de treinamento, excluindo a amostragem de dados e a coluna de dados com rótulos reais (Ground truth). A inferência em lote é a etapa que envia dados em lotes para inferência ao endpoint correspondente e pode ser implementada aproveitando a transformação em lote. A etapa de pós-processamento (Post-Processing) produz estatísticas adicionais, por exemplo, a distribuição dos resultados, ou combina os resultados com identificadores externos. Em seguida, uma etapa de monitoramento do modelo (Model Monitoring) é capaz de comparar as estatísticas dos dados de base usados para treinamento (metadados JSON do modelo no registro de modelos) com os novos dados recebidos para inferência.

As etapas de pré-processamento podem ser omitidas se os cientistas de dados criarem modelos em pipeline que possam ser armazenados no registro de modelos do SageMaker. Para obter mais detalhes, consulte Host models along with pre-processing logic as serial inference pipeline behind one endpoint (em inglês).

Padronização de repositórios

Para permitir a colaboração entre cientistas de dados e engenheiros de ML, é necessário padronizar a estrutura do repositório de código. Além disso, a padronização é benéfica para a estrutura do pipeline de CI/CD, permitindo a incorporação de etapas de validação automática, construção (por exemplo, de contêineres personalizados) e etapas de teste.

O exemplo a seguir ilustra a separação de soluções de ML em dois repositórios: um repositório de construção e treinamento para a etapa de treinamento (e, opcionalmente, um modelo de pipeline) e um repositório de implantação para promover modelos de pipeline de inferência em lote ou instanciar endpoints em tempo real:

Repositório de construção e treinamento

# Repositório de treinamento/construção
algorithms/
    shared_libraries/
        test/
            input/ # (opcional)
            output/ # (opcional)
            test_<step>.py
        <help_functions1>.py
        <help_functions2>.py
        README.md
    preprocessing/ # 1 pasta por trabalho de pré-processamento, a ordem é definida na lógica do pipeline de ML
        <preprocessing_job_name1> # por exemplo, ml clássico: one-hot encoding
            test/
                input/ # (opcional)
                output/ # (opcional)
                test_<step>.py
            __main__.py
            dockerfile # (opcional) define o dockerfile no caso de contêineres personalizados
            README.md
       <preprocessing_job_name2> # por exemplo, ml clássico: one-hot encoding
        ...
    training/ # (opcional) cada pasta é um trabalho de treinamento no SageMaker
        <training_job_name>/
            test/
                input/ # (opcional)
                output/ # (opcional)
                test_<step>.py
            __main__.py
            README.md
    inference/ # (opcional) para inferencia batch
        <batch_inference_job_name>/ # um trabalho para cada nome de trabalho de treinamento se estivermos criando vários modelos
            __main__.py
            README.md
    postprocessing/ # cada um é um trabalho de pós-processamento no SageMaker
        <postprocessing_job_name1>/
            test/
                input/ # (opcional)
                output/ # (opcional)
                test_<step>.py
           __main__.py
            README.md
        <postprocessing_job_name2>/
        ...
ml_pipelines/
    training/ # (nota) Vários canais de treinamento de ML podem ser definidos
        ml-pipeline-training.py # Defina canais de treinamento de ML usando o SDK do SageMaker Pipeline
        input.json # (opcional - json o yaml) Configurando o pipeline de ML para permitir a reutilização
    README.md
notebooks/
    *.ipynb # Os notebooks originais criados por cientistas de dados
    README.md
build_spec.yml
README.md

 

Repositório de implantação

# Repositorio de despliegue
inference_config/
    staging/
        inference_config.json # Pipeline de ML de inferência em lote ou configuração de endpoint em tempo real para permitir a reutilização
    prod/
        inference_config.json # Pipeline de ML de inferência em lote ou configuração de endpoint em tempo real para permitir a reutilização
    README.md
app_infra/
    api_gateway/...
    lambda/...
    event_bridge/...
    batch_inference/ml-pipeline-inference.py # Defina o pipeline de inferência em lote de ML
tests/
    integration_test/
        test_<description>.py
        test_<description>.py
        # …
    stress_test/
        test_<description>.py
    other_test/
        test_<description>.py
    README.md
README.md

 

O repositório de construção e treinamento é dividido em três pastas principais:

  1. Algoritmos: Os cientistas de dados desenvolvem o código para cada etapa dos pipelines de ML na raiz da pasta algoritmo. As etapas podem ser agrupadas em pré-processamento, treinamento, inferência em lote, pós-processamento (avaliação). Em cada grupo, várias etapas podem ser definidas nas subpastas correspondentes, que contêm uma pasta para testes de unidade (incluindo entradas e saídas opcionais), as funções principais, o arquivo README e um Dockerfile se você precisar de um contêiner personalizado. Além do arquivo principal (main), vários arquivos de código podem ser armazenados na mesma pasta. As bibliotecas auxiliares comuns a todas as etapas podem ser armazenadas em uma pasta de biblioteca compartilhada. Os cientistas de dados são responsáveis por desenvolver testes unitários, pois eles são donos da lógica de processamento em cada uma das etapas, enquanto os engenheiros de ML são responsáveis por melhorar o tratamento de erros e recomendar a cobertura dos testes. O pipeline de CI/CD é responsável por executar os testes, criar os contêineres automaticamente (se necessário) e empacotar os vários arquivos de código-fonte.
  2. Pipelines ML: Depois de desenvolver o código-fonte e testar cada etapa, o próximo passo é definir os passos do Amazon SageMaker Pipelines em outra pasta raiz. Cada definição de pipeline de ML é colocada em uma subpasta contendo o arquivo .py e um arquivo JSON ou YAML para parâmetros de entrada, como intervalos de hiperparâmetros. É necessário um arquivo README para descrever os pipelines de ML.
  3. Notebooks: Essa pasta contém os notebooks originais que o cientista de dados usou durante a experimentação.

O repositório de implantação consiste em três partes principais:

  1. Configuração de inferência: Ele contém a configuração do endpoint em tempo real ou da inferência em lote para cada ambiente de desenvolvimento, como por exemplo os tipos de instância.
  2. Infraestrutura de aplicativos: Ele contém o código-fonte da infraestrutura necessária para executar a inferência, se necessário. Isso pode ser um mecanismo de ativação por meio do Amazon EventBridge, do Amazon API Gateway, das funções do AWS Lambda ou do SageMaker Pipelines.
  3. Testes: Ele consiste em várias subpastas, dependendo da metodologia de teste do cliente. Como um conjunto mínimo, os testes de integração (execução de inferência de ponta a ponta, incluindo a infraestrutura do aplicativo), testes de estresse (examinando casos extremos) e testes de ML (por exemplo, a distribuição de pontuações de confiança ou probabilidades) são sugeridos.

Ao realizar alterações no repositório de construção e treinamento, um pipeline de CI/CD é responsável por validar a estrutura do repositório, testar, implantar e executar pipelines de ML. Um pipeline diferente de CI/CD será responsável pela promoção dos modelos que examinaremos na próxima seção.

Padronização das branches de repositórios e CI/CD

Para garantir a robustez dos pipelines de ML na conta de desenvolvimento, sugere-se uma estratégia de repositórios com múltiplas branches, enquanto a implantação é feita somente por meio de pipelines de CI/CD. Os cientistas de dados devem usar uma branch chamada “branch de recursos” para desenvolver sua nova funcionalidade (código-fonte) e, quando estiverem prontos para implantar os pipelines de ML correspondentes, podem enviá-la para a branch de desenvolvimento. Uma alternativa a essa abordagem é permitir a implantação de pipelines de ML por branch de recurso. O artigo Melhore seu fluxo de trabalho de ciência de dados com um pipeline de treinamento de MLOps em várias filiais usando a AWS (em inglês) descreve essa alternativa.

A figura a seguir ilustra a estratégia de ramificação e as etapas necessárias do pipeline de CI/CD que executamos no ambiente de desenvolvimento para o pipeline de ML e para a criação de modelos.

Um exemplo de código que ilustra a abordagem de múltiplas branch pode ser entendido no blogpost Pipeline de Treinamento de MLOps Multi-Branch (em inglês). Você pode armazenar os modelos produzidos por um pipeline de ML com base em branch de recurso em grupos de modelos separados por recurso e depois desativá-los durante uma solicitação de mesclagem de código (merge request) com a branch principal. Os modelos do grupo principal serão aqueles que serão implantados para produção.

Padronização da estrutura de dados

Igualmente importante para a padronização do código-fonte é a padronização da estrutura de dados, que permite que cientistas de dados e engenheiros de ML depurem, auditem e monitorem a origem e o histórico dos modelos e pipelines de ML. O diagrama a seguir ilustra esse exemplo.

Para simplificar, assumiremos que os dados históricos de entrada são inseridos em um bucket da conta de desenvolvimento sob a sub-diretório de input (entrada) (geralmente localizado no Data Lake). Para cada caso de uso de ML, é preciso criar um sub-diretório separado. Para acionar uma nova execução de um pipeline de ML, o cientista de dados deve executar os comandos git commit e depois git push, que acionam o pipeline de CI/CD. Em seguida, o pipeline de CI/CD cria um sub-diretório copiando os artefatos de código (o sub-diretório code) e os dados de entrada (o sub-diretório input) em uma sub-partição do id de construção. Por exemplo, o ID de compilação pode ser uma combinação de data e hora com o git hash ou um ID de execução do pipeline do SageMaker. Essa estrutura permite que os cientistas de dados auditem e consultem implementações e execuções anteriores. Depois disso, o pipeline de CI/CD implanta e aciona o pipeline de ML. Durante a execução do pipeline de ML, cada etapa exporta os resultados intermediários para o diretório ml-pipeline-outputs. É importante lembrar que as diferentes branch de recurso implantam e executam uma nova instância do pipeline de ML e cada uma precisa exportar os resultados intermediários para uma subpasta diferente em um novo sub-diretório e/ou que inclua o ID da branch de recurso como prefixo ou sufixo padrão.

Essa abordagem oferece suporte à auditabilidade total de cada experimento. No entanto, a abordagem multi-branch da estratégia de desenvolvimento gera muitos dados. Portanto, é necessária uma estratégia de ciclo de vida dos dados. Sugere-se remover pelo menos os dados de cada pipeline de ML por branch de recurso em cada solicitação de extração (pull)/mescla (merge) bem-sucedida. Mas isso depende do modelo operacional e da granularidade da auditoria que a empresa precisa suportar. Uma abordagem semelhante pode ser usada em pipelines de ML de inferência em lote.

Fase Confiável

Após a separação inicial entre contas de cientistas de dados, engenheiros de ML e engenheiros de dados, a próxima etapa é promover os modelos produzidos a partir do registro do modelo (model registry) em um ambiente isolado para fazer inferências. No entanto, precisamos garantir a robustez dos modelos implantados. Portanto, a simulação do modelo implantado em um ambiente espelho da produção é mandatório, podendo ser chamado de pré-produção (ou teste).

A figura a seguir ilustra essa arquitetura.

A promoção de um modelo e endpoint em um ambiente de pré-produção é feita usando os eventos de atualização dos registros do modelo (ou git push para o repositório de implantação) que acionam um pipeline separado de CI/CD usando eventos do Amazon EventBridge. A primeira etapa do pipeline de CI/CD requer aprovação manual do cientista de dados líder (e, opcionalmente, do product owner, analista de negócios ou outros cientistas de dados líderes). Aqueles que aprovam precisam validar os KPIs de desempenho do modelo e o controle de qualidade do código no repositório de implantação. Após a aprovação, o pipeline de CI/CD executa o código de teste no repositório de implantação (testes de integração, testes de estresse, testes de ML). Além do endpoint do modelo, o pipeline de CI/CD também testa a infraestrutura de ativação, como o Amazon EventBridge, funções AWS Lambda ou o Amazon API Gateway. O diagrama a seguir mostra essa arquitetura atualizada.

Após a execução bem-sucedida dos testes, o pipeline de CI/CD notifica os novos (ou os mesmos) aprovadores que um modelo está pronto para ser promovido para produção. Nesse estágio, o analista de negócios pode realizar alguns testes estatísticos adicionais de hipóteses sobre os resultados do modelo. Após a aprovação, os modelos e a infraestrutura de ativação são implantados em produção. O Amazon SageMaker oferece suporte a vários métodos de implantação, como testes Azul/Verde, Canário e implantação A/B (veja mais sobre Deployment Guardrails). Se o pipeline de CI/CD falhar, um mecanismo de reversão retornará o sistema ao último estado estável.

O diagrama a seguir ilustra as principais etapas do pipeline de CI/CD para a promoção e a infraestrutura para acionar o endpoint do modelo, como o API Gateway, as funções do Lambda e o EventBridge.

Integração do Data Lake com MLOps

Nesse ponto, é importante entender os requisitos de dados para cada estágio de desenvolvimento e para cada conta, e como incorporar MLOps a um Data Lake centralizado. O diagrama a seguir ilustra as camadas de MLOps e Data Lake.

No Data Lake, os engenheiros de dados são responsáveis por unir várias fontes de dados e criar os conjuntos de dados correspondentes (por exemplo, uma única tabela de dados estruturados, uma única pasta com arquivos ou imagens PDF) para casos de uso de ML, criando pipelines de ETL conforme definido por cientistas de dados (por exemplo, durante a fase de análise de dados exploratória). Esses conjuntos de dados podem ser divididos em dados históricos, dados para inferência e testes. Todos os dados são catalogados (por exemplo, no catálogo do AWS Glue) e podem ser compartilhados com outras contas e usuários usando o AWS Lake Formation como uma camada de governança de dados (para dados estruturados). No momento em que este artigo foi escrito, o Lake Formation oferece suporte somente às consultas do Amazon Athena, aos trabalhos do AWS Glue e ao Amazon EMR.

Por outro lado, o ambiente MLOps precisa nutrir os pipelines de ML com conjuntos de dados específicos localizados em buckets locais em ambientes de desenvolvimento, pré-produção e produção. O ambiente de desenvolvimento (Dev) é responsável por criar e treinar modelos sob demanda usando os pipelines do SageMaker e extraindo dados do Data Lake. Portanto, sugerimos o Amazon Athena como primeira etapa do pipeline no caso em que somente a amostragem/consulta de dados seja necessária, ou uma etapa do Amazon EMR, se forem necessárias transformações mais complexas. Como alternativa, você pode usar um trabalho do AWS Glue por meio de uma etapa de retorno de chamada (callback), mas ainda não como uma etapa nativa no SageMaker Pipelines.

As etapas de pré-produção (Pre-Prod) e produção (Prod) são responsáveis, respectivamente, por realizar testes e inferências em tempo real e em lote. No caso de inferência em tempo real, não é necessário enviar dados para as contas MLOps pre-prod/prod pois os dados de entrada para inferência podem ser incluídos na carga de solicitação do API Gateway. No caso de inferência em lote (ou grandes dados de entrada), os conjuntos de dados necessários, sejam dados de teste ou dados para inferência, precisam ser movidos para os respectivos compartimentos de dados de ML locais (ou seja, pre-prod/prod). Há duas opções para mover dados para pré-produção e produção: acionando o Athena ou o Amazon EMR para extrair os dados do Data Lake ou enviando os dados do Data Lake para essas contas MLOps. A primeira opção requer o desenvolvimento de mecanismos adicionais nas contas MLOps, por exemplo, a criação de eventos programados do EventBridge (sem saber se os dados no Data Lake foram atualizados) ou eventos do S3 no EventBridge após a chegada dos dados no Data Lake (para obter mais detalhes consulte Simplificar o acesso entre contas com as políticas de recursos do Amazon EventBridge, em inglês). Depois de capturar o evento no lado do MLOps, uma consulta do Athena ou do Amazon EMR pode buscar os dados localmente e acionar inferência assíncrona ou transformação em lote. Esse processo pode ser integrado a um pipeline do SageMaker para maior simplicidade. A segunda opção é adicionar na última etapa do pipeline de ETL a funcionalidade de envio de dados para os buckets MLOps. No entanto, essa abordagem combina responsabilidades (o Data Lake aciona a inferência) e exige que o Lake Formation forneça acesso ao Data Lake para gravar nos buckets do MLOps.

A etapa final é mover os resultados da inferência de volta para o Data Lake. Para catalogar os dados e disponibiliza-los para outros usuários, os dados devem retornar como uma nova fonte de dados para o bucket de destino.

Fase Escalável

Após a base de MLOps ser estabelecida e da produção de ponta a ponta do primeiro caso de uso, a infraestrutura de desenvolvimento, pré-produção e produção, bem como o repositório, o pipeline de CI/CD e a estrutura de dados, foram testados e finalizados. A próxima etapa é incorporar novos casos de uso e equipes de ML à plataforma. Para acelerar o tempo de geração de valor, o SageMaker permite que os usuários criem templates de projetos personalizados que podem ser usados para instanciar repositórios e pipelines de CI/CD automaticamente. Com esses templates , a liderança dos cientistas de dados é responsável por instanciar novos projetos e designar equipes dedicadas para cada novo caso de uso de ML.

O diagrama a seguir ilustra esse processo

O problema se torna mais complexo se diferentes equipes de cientistas de dados (ou várias unidades de negócios que precisam produzir ML) tiverem acesso a diferentes dados confidenciais e vários donos do produto (product owners) forem responsáveis por pagar contas separadas pelo processo de treinamento, implantação e execução dos modelos. Nesse contexto, é necessário ter um grupo separado de contas MLOps (experimentação, dev, pre-prod, prod) para cada equipe. Para permitir a fácil criação de novas contas MLOps, adicionamos outra conta, chamada governança de análise avançada, que pode ser acessada por membros de TI para permitir que eles cataloguem, instanciem ou eliminem contas MLOps sob demanda. Especificamente, essa conta contém repositórios com o código associado à infraestrutura da conta MLOps (VPC, sub-redes, endpoints, buckets, funções e políticas do AWS Identity and Access Management (IAM), stacks do AWS CloudFormation), um AWS Service Catalog para implantar automaticamente stacks de infraestrutura do Cloud Formation em várias contas com um clique e uma tabela do Amazon DynamoDB para catalogar metadados, incluindo qual equipe é responsável por cada grupo de contas. Com esse recurso, a equipe de TI instancia contas de MLOps sob demanda e atribui usuários, acesso aos dados e restrições de segurança consistentes.

Com base nesse cenário, separamos as contas em efêmeras e duráveis. O Data Lake e as ferramentas são contas duráveis e servem como o único ponto de verdade para os dados e para o código-fonte, respectivamente. As contas MLOps são, em sua maioria, stateless e são instanciadas ou desativadas sob demanda, tornando-as efêmeras. Mesmo que um grupo de contas MLOps seja removido, os usuários ou auditores podem verificar experimentos e resultados anteriores, pois eles são armazenados em ambientes duráveis.

Se você quiser usar o SageMaker Studio para MLOps, a conta de ferramentas passa a fazer parte da conta de desenvolvimento, conforme mostrado na figura a seguir. O exemplo de código-fonte para esse banco de dados MLOps pode ser encontrado em Configuração de várias contas do MLOps com o AWS CDK (repositório em inglês).

Observe que o SageMaker oferece a capacidade de substituir o AWS CodeCommit e o AWS CodePipeline por outras ferramentas de desenvolvimento de terceiros, como GitHub e Jenkins (mais detalhes podem ser encontrados em Create Amazon SageMaker projects using third-party source control and Jenkins y SageMaker Projects MLOps Template with GitLab and GitLab Pipelines, ambos em inglês).

Visão geral dos papéis, operações e tecnologia

Com o modelo de maturidade do MLOps, podemos definir um projeto de arquitetura claro e um roteiro de entrega. No entanto, cada papel precisa ter uma visão clara das principais contas e serviços da AWS com os quais interagir e das operações a serem executadas. O diagrama a seguir resume essas categorias:

Conclusão

Uma base robusta de MLOps, que define claramente a interação entre vários papéis e tecnologias, pode aumentar a velocidade de obtenção de valor e reduzir custos, ao mesmo tempo em que permite que os cientistas de dados se concentrem na inovação. Neste artigo, mostramos como construir essa base em fases que levam a empresa a aumentar gradualmente sua maturidade em MLOps, conseguindo apoiar várias equipes de ciência de dados e casos de uso de ML em produção. Definimos um modelo operacional que consiste em pessoas desempenhando vários papéis com habilidades e responsabilidades diferentes. Por fim, compartilhamos exemplos de como padronizar o desenvolvimento de código (repositórios e pipelines de CI/CD), o armazenamento e o compartilhamento de dados e, por fim, o fornecimento de infraestrutura segura de MLOps para ambientes corporativos. Vários clientes corporativos adotaram essa abordagem e são capazes de produtizar suas soluções de ML em dias, ao invés de meses.

 

Este artigo foi traduzido do blog da AWS em inglês.

 

Acerca de los autores

Dr. Sokratis Kartakis é arquiteto sênior de soluções especializado em aprendizado de máquina na Amazon Web Services. Sokratis se concentra em permitir que clientes empresariais industrializem suas soluções de aprendizado de máquina (ML) aproveitando os serviços da AWS e moldando seu modelo operacional, por exemplo, bases de MLOps e roteiro de transformação usando as melhores práticas de desenvolvimento. Ele passou mais de 15 anos inventando, projetando, liderando e implementando soluções inovadoras de ML e Internet das Coisas (IoT), de ponta a ponta e de nível produtivo, nos domínios de energia, varejo, saúde, finanças/bancos, automobilismo, etc. Sokratis gosta de passar seu tempo livre com a família e amigos, ou gosta de passar seu tempo livre com a família e amigos, ou andar de moto.

 

 

 

 

Georgios Schinas é arquiteto de soluções especializado em IA/ML na região EMEA. Ele mora em Londres e trabalha em estreita colaboração com clientes no Reino Unido e na Irlanda. Georgios ajuda os clientes a projetar e implantar aplicativos de aprendizado de máquina em produção na AWS, com um interesse particular nas práticas de MLOps e permitindo que os clientes realizem aprendizado de máquina em grande escala. Em seu tempo livre, ele gosta de viajar, cozinhar e passar tempo com amigos e familiares.

 

 

 

 

Giuseppe Angelo Porcelli é arquiteto principal de soluções de aprendizado de máquina na Amazon Web Services. Com muitos anos de experiência em ML e engenharia de software, ele trabalha com clientes de qualquer tamanho para entender suas necessidades técnicas e comerciais em profundidade e projetar soluções de IA e aprendizado de máquina que façam o melhor uso da nuvem da AWS e da pilha de aprendizado de máquina da AWS. Ele trabalhou em projetos em diferentes domínios, incluindo MLOps, Visão Computacional, PLN e envolvendo uma ampla gama de serviços. Em seu tempo livre, Giuseppe gosta de jogar futebol.

 

 

 

 

Shelbee EigenbrodeShelbee Eigenbrode é arquiteta principal de soluções especialista em IA e aprendizado de máquina na Amazon Web Services (AWS). Ela está na área de tecnologia há 24 anos, cobrindo vários setores, tecnologias e funções. Atualmente, ela está focada em combinar sua experiência em DevOps e ML no domínio de MLOps, para ajudar os clientes a entregar e gerenciar cargas de trabalho de ML em grande escala. Com mais de 35 patentes concedidas em vários domínios de tecnologia, ela é apaixonada pela inovação contínua e pelo uso de dados para atingir os objetivos de negócios. Shelbee é cocriadora e instrutora da especialização Practical Data Science no Coursera. Além disso, ela é co-diretora do capítulo de Denver de Women In Big Data (WiBD). Em seu tempo livre, ela gosta de passar tempo com sua família, amigos e seus cães hiperativos.

 

 

 

 

Tradutores

Yan Marim é arquiteto de soluções na AWS e tem interesse principalmente em AI/ML. Atualmente apoia clientes na sua jornada de transformação digital na nuvem.

 

 

 

 

Rafael Almeida é arquiteto de soluções na AWS, atuando com pequenas e médias empresas, trabalhando também em conjunto com o time de espcialistas em AI/ML no Brasil.

 

 

 

 

João Martins é arquiteto de soluções na AWS desde 2018. Atualmente trabalha no time de Aceleração em Nuvem onde assume o papel de Especialista de AI/ML. Dentre suas responsabilidades está a tarefa de ser um facilitador para empresas de todas as indústrias e tamanhos no uso de tecnologias voltadas a Inteligência Artificial.

 

 

 

 

Revisor

Phelipe Fabres é treinador técnico sênior na Amazon Web Services, com sede em São Paulo, Brasil.