Arquitetura para MLOps usando a TensorFlow Extended, a Vertex AI Pipelines e o Cloud Build

Last reviewed 2023-01-20 UTC

Neste documento, descrevemos a arquitetura geral de um sistema de machine learning (ML) usando bibliotecas da TensorFlow Extended (TFX). Nele também discutimos como configurar a integração contínua (CI), a entrega contínua (CD) e o treinamento contínuo (CT) para o sistema de ML usando o Cloud Build e a Vertex AI Pipelines.

Neste documento, os termos sistema de ML e pipeline de ML referem-se aos pipelines de treinamento de modelos de ML, e não aos pipelines de pontuação ou previsão.

Este documento destina-se a cientistas de dados e engenheiros de ML que querem adaptar práticas de CI/CD para migrar soluções de ML para produção no Google Cloud e querem ajudar a garantir a qualidade, a facilidade de manutenção e a capacidade de adaptação dos pipelines de ML.

Neste documento, discutimos os seguintes tópicos:

• Noções básicas de CI/CD e automação em ML
• Como projetar um pipeline de ML integrado com o TFX
• Como orquestrar e automatizar o pipeline de ML usando a Vertex AI Pipelines.
• Como configurar um sistema de CI/CD para o pipeline de ML usando o Cloud Build

MLOps

Para integrar um sistema de ML em um ambiente de produção, você precisa orquestrar
as etapas no seu pipeline de ML. Também precisa automatizar a execução do pipeline para o treinamento contínuo dos seus modelos. Para testar novas ideias e recursos, adote práticas de CI/CD nas novas implementações dos pipelines. Nas seções a seguir, fornecemos uma visão geral resumida dos processos de CI/CD e CT em ML.

Automação do pipeline de ML

Em alguns casos de uso, o processo manual de treinamento, validação e implantação de modelos de ML pode ser suficiente. Essa abordagem manual funciona quando sua equipe gerencia apenas alguns modelos de ML que não são retreinados ou não são alterados com frequência. Porém, na prática, os modelos muitas vezes se fragmentam quando implantados no mundo real porque não se adaptam às mudanças na dinâmica dos ambientes ou aos dados que descrevem essa dinâmica.

Para que seu sistema de ML se adapte a essas mudanças, é necessário aplicar as seguintes técnicas de MLOps:

• Automatizar a execução do pipeline de ML para retreinar novos modelos em novos dados a fim de capturar padrões emergentes. O CT é abordado mais adiante neste documento, na seção ML com a Vertex AI Pipelines.
• Configurar um sistema de entrega contínua para implantar com frequência novas implementações de todo o pipeline de ML. Abordaremos as técnicas de CI/CD mais adiante neste documento, na seção Como configurar CI/CD para ML no Google Cloud.

É possível automatizar os pipelines de produção de ML para retreinar os modelos com novos dados. É possível acionar o pipeline sob demanda, conforme programado, quando houver disponibilidade de novos dados, em caso de degradação do desempenho do modelo, quando houver alterações significativas nas propriedades estatísticas dos dados ou com base em outras condições.

Pipeline de CI/CD em comparação com o pipeline de CT

A disponibilidade de novos dados é um gatilho para retreinar o modelo de ML. A disponibilidade de uma nova implementação do pipeline de ML (incluindo nova arquitetura de modelo, engenharia de atributos e hiperparâmetros) é outro gatilho importante para executar novamente o pipeline de ML. Essa nova implementação do pipeline de ML serve como uma nova versão do serviço de previsão de modelo, por exemplo, um microsserviço com uma API REST para exibição on-line. A diferença entre os dois casos é a seguinte:

• Para treinar um novo modelo de ML com dados novos, o pipeline de CT implantado anteriormente é executado. Nenhum pipeline ou componente novo é implantado, apenas um novo serviço de previsão ou modelo recém-treinado é exibido no final do pipeline.
• Para treinar um novo modelo de ML com uma implementação nova, um novo pipeline é implantado por meio de um pipeline de CI/CD.

Para implantar novos pipelines de ML rapidamente, é preciso configurar um pipeline de CI/CD. Esse pipeline é responsável por implantar automaticamente novos pipelines e componentes de ML quando novas implementações estão disponíveis e aprovadas para vários ambientes (como desenvolvimento, teste, preparo, pré-produção, canário e produção).

No diagrama a seguir, consulte a relação entre o pipeline de CI/CD e o pipeline de CT de ML.

Figura 1. Pipelines de CI/CD e CT de ML.

A saída desses pipelines é a seguinte:

• Se for fornecida uma nova implementação, um pipeline de CI/CD bem-sucedido implantará um novo pipeline de CT de ML.
• Se novos dados forem fornecidos, um pipeline de CT treina um novo modelo e o implanta como um serviço de previsão.

Como projetar um sistema de ML baseado em TFX

Nas seções a seguir, abordamos o design de um sistema de ML integrado usando a TensorFlow Extend (TFX) para configurar um pipeline de CI/CD para o sistema de ML. Há vários frameworks para criar modelos de ML, mas o TFX é uma plataforma de ML integrada para desenvolvimento e implantação de sistemas de ML de produção. Um pipeline da TFX é uma sequência de componentes que implementam um sistema de ML. Esse pipeline da TFX é projetado para tarefas de ML escalonáveis e de alto desempenho. Essas tarefas incluem modelagem, treinamento, validação, exibição de inferência e gerenciamento de implantações. As principais bibliotecas do TFX são as seguintes:

• TensorFlow Data Validation (TFDV) (em inglês): usada para detectar anomalias nos dados.
• TensorFlow Transform (TFT) (em inglês): usada para pré-processamento de dados e engenharia de atributos.
• TensorFlow Estimators e Keras (em inglês): usadas para criar e treinar modelos de ML.
• TensorFlow Model Analysis (TFMA) (em inglês): usada para a avaliação e análises de modelo de ML.
• TensorFlow Serving (TFServing) (em inglês): usada para exibir modelos de ML como APIs REST e gRPC.

Visão geral do sistema de ML do TFX

No diagrama a seguir, veja como as várias bibliotecas da TFX são integradas para compor um sistema de ML.

Figura 2. Um sistema de ML típico baseado em TFX.

Na figura 2, veja um sistema de ML típico baseado em TFX. As etapas a seguir podem ser concluídas manualmente ou por um pipeline automatizado:

1. Extração de dados: a primeira etapa é extrair os novos dados de treinamento das fontes de dados. As saídas desta etapa são arquivos de dados usados para treinar e avaliar o modelo.
2. Validação de dados: o TFDV valida os dados em relação ao esquema de dados (brutos) esperado. O esquema de dados é criado e corrigido durante a fase de desenvolvimento, antes da implantação do sistema. As etapas de validação de dados detectam anomalias relacionadas à distribuição de dados e aos desvios de esquema. As saídas dessa etapa são as anomalias, se houver, e uma decisão sobre a execução de etapas downstream.
3. Transformação de dados: depois que os dados são validados, eles são divididos e preparados para a tarefa de ML por meio de transformações de dados e operações de engenharia de atributos usando TFT. As saídas dessa etapa são arquivos de dados para treinar e avaliar o modelo, geralmente transformado no formato TFRecords. Além disso, os artefatos de transformação produzidos ajudam a construir as entradas do modelo e incorporar o processo de transformação no modelo salvo exportado após o treinamento.
4. Treinamento e ajuste do modelo: para implementar e treinar o modelo de ML, use as APIs tf.estimator ou tf.Keras (em inglês) com os dados transformados produzidos pela etapa anterior. Para selecionar as configurações de parâmetros que levam ao melhor modelo, use o Keras tuner, uma biblioteca de ajuste de hiperparâmetros para Keras. Como alternativa, é possível usar outros serviços, como Katib, Vertex AI Vizier ou o sintonizador de hiperparâmetros da Vertex AI. A saída dessa etapa é um modelo salvo usado para avaliação e outro modelo salvo usado para a exibição on-line do modelo para previsão.
5. Avaliação e validação do modelo: quando o modelo é exportado após a etapa de treinamento, a qualidade do modelo é avaliada em um conjunto de dados de teste usando a TFMA. A TFMA avalia a qualidade do modelo como um todo e identifica qual parte do modelo de dados não está funcionando. Essa avaliação garante que o modelo apenas se promovido para exibição se atender aos critérios de qualidade. Os critérios podem ser bom desempenho em vários subconjuntos de dados (por exemplo, informações demográficas e locais) e desempenho aprimorado em comparação com modelos anteriores ou um modelo de referência. A saída dessa etapa é um conjunto de métricas de desempenho e uma decisão sobre a promoção do modelo para produção.
6. Exibição de modelo para previsão: após a validação do modelo recém-treinado, ele é implantado como um microsserviço para exibir previsões on-line usando a TensorFlow Serving. A saída dessa etapa é um serviço de previsão implantado do modelo de ML treinado. É possível substituir essa etapa armazenando o modelo treinado em um registro de modelo. Posteriormente, um modelo separado que exibe o processo de CI/CD é iniciado.

Consulte um exemplo sobre como usar as bibliotecas da TFX, em Tutorial de componente do TFX Keras.

Sistema de ML do TFX no Google Cloud

Em um ambiente de produção, os componentes do sistema precisam ser executados em grande escala em uma plataforma confiável. O diagrama a seguir mostra como cada etapa do pipeline de ML da TFX é executada usando um serviço gerenciado no Google Cloud, o que garante agilidade, confiabilidade e desempenho em grande escala.

Figura 3. Sistema de ML baseado em TFX no Google Cloud.

Na tabela a seguir, veja os principais serviços do Google Cloud mostrados na figura 3:

Etapa	Biblioteca da TFX	Serviço do Google Cloud
Extração e validação de dados	TensorFlow Data Validation	Dataflow
Transformação de dados	TensorFlow Transform	Dataflow
Treinamento e ajuste de modelos	TensorFlow	Treinamento da Vertex AI
Avaliação e validação de modelo	TensorFlow Model Analysis	Dataflow
Exibição de modelo para previsões	TensorFlow Serving	Previsão de IA do Vertex
Armazenamento de modelos	Não relevante	Vertex AI Model Registry

• O Dataflow é um serviço totalmente gerenciado, sem servidor e confiável para executar pipelines do Apache Beam em grande escala no Google Cloud. O Dataflow é usado para escalonar os seguintes processos:
  • Cálculo de estatísticas para validar os dados recebidos
  • Execução de preparo e transformação de dados
  • Avaliação do modelo em um grande conjunto de dados
  • Cálculo de métricas em diferentes aspectos do conjunto de dados de avaliação
• O Cloud Storage é um serviço de armazenamento altamente disponível e durável para objetos binários grandes. O Cloud Storage hospeda artefatos produzidos durante a execução do pipeline de ML, incluindo o seguinte:
  • Anomalias de dados (se houver)
  • Dados e artefatos transformados
  • Modelo exportado (treinado)
  • Métricas de avaliação de modelo
• O Vertex AI Training é um serviço gerenciado para treinar modelos de ML em escala. É possível executar jobs de treinamento de modelo com contêineres pré-criados para TensorFlow, Scikit learn, XGBoost e PyTorch. Também é possível executar qualquer framework usando seus próprios contêineres personalizados. Para a infraestrutura de treinamento, é possível usar aceleradores e vários nós para treinamento distribuído. Além disso, há disponibilidade de um serviço bayesiano escalonável e baseado em otimização para ajuste de hiperparâmetros.
• O Vertex AI Prediction é um serviço gerenciado para execução de previsões em lote usando os modelos treinados e as previsões on-line, implantando os modelos como um microsserviço com uma API REST. O serviço também se integra ao Vertex Explainable AI e ao Vertex AI Model Monitoring para entender os modelos e receber alertas quando há distorção ou deslocamento de atributo ou recurso.
• O Vertex AI Model Registry permite gerenciar o ciclo de vida dos modelos de ML. Controle as versões dos modelos importados e veja as métricas de desempenho. É possível usar um modelo para previsões em lote ou implantá-lo para exibição on-line usando o Vertex AI Prediction

Como orquestrar o sistema de ML usando a Vertex AI Pipelines

Neste documento, abordamos como projetar um sistema de ML baseado em TFX e como executar cada componente do sistema em grande escala no Google Cloud. No entanto, você precisa de um orquestrador para reunir esses diferentes componentes do sistema. O orquestrador executa o pipeline em uma sequência e passa automaticamente de uma etapa para outra com base nas condições definidas. Por exemplo, uma condição definida pode executar a etapa de exibição do modelo após a etapa de avaliação do modelo se as métricas de avaliação atenderem a limites predefinidos. As etapas também podem ser executadas em paralelo para economizar tempo. Por exemplo, validar a infraestrutura de implantação e avaliar o modelo. A orquestração do pipeline de ML é útil nas fases de desenvolvimento e produção:

• Durante a fase de desenvolvimento, a orquestração ajuda os cientistas de dados a executar o experimento de ML, em vez de executar manualmente cada etapa.
• Durante a fase de produção, a orquestração ajuda a automatizar a execução do pipeline de ML com base em uma programação ou determinadas condições de acionamento.

ML com a Vertex AI Pipelines

A Vertex AI Pipelines é um serviço gerenciado do Google Cloud que permite orquestrar e automatizar pipelines de ML para que cada componente do pipeline seja executado em contêineres do Google Cloud ou de outras plataformas na nuvem. Os parâmetros e artefatos de pipeline gerados são armazenados automaticamente no Vertex ML Metadata, que permite o rastreamento de linhagem e execução. O serviço Vertex AI Pipelines consiste em:

• uma interface do usuário para gerenciar e rastrear experimentos, jobs e execuções;
• um mecanismo para programar fluxos de trabalho de ML com várias etapas;
• um SDK do Python para definir e manipular pipelines e componentes;
• Integração com o [Vertex ML Metadata] para salvar informações sobre execuções, modelos, conjuntos de dados e outros artefatos.

Veja a seguir um pipeline executado na Vertex AI Pipelines:

• Um conjunto de tarefas de ML contentorizadas ou componentes. Um componente de pipeline é um código autossuficiente que é empacotado como uma imagem do Docker. Um componente realiza uma etapa no pipeline. Ele usa argumentos de entrada e gera artefatos.
• Uma especificação da sequência de tarefas de ML, definida por meio de uma linguagem de domínio específico (DSL) Python. A topologia do fluxo de trabalho é definida implicitamente com a conexão das saídas de uma etapa upstream às entradas de uma etapa downstream. Uma etapa da definição do pipeline invoca um componente no pipeline. Em um pipeline complexo, os componentes podem ser executados várias vezes, em loops ou executados condicionalmente.
• Um conjunto de parâmetros de entrada do pipeline. Os valores são passados para os componentes do pipeline, incluindo os critérios de filtragem de dados e onde armazenar os artefatos que o pipeline produz.

O diagrama a seguir mostra um exemplo de gráfico da Vertex AI Pipelines.

Figura 4. Um exemplo de gráfico da Vertex AI Pipelines.

SDK do Kubeflow Pipelines

Com o SDK do Kubeflow Pipelines, é possível criar componentes, definir a orquestração deles e executá-los como um pipeline. Para que um componente seja invocado no pipeline, é preciso criar uma operação de componente. Para criá-la, use os seguintes métodos:

• Implementação de um componente Python leve: esse componente não exige que você crie uma nova imagem de contêiner para cada alteração de código, sendo destinado a iterações rápidas em um ambiente de notebook. É possível criar um componente leve da sua função Python usando a função kfp.components.create_component_from_func ou o decorador @component.

• Criação de componente reutilizável: essa função exige que o componente tenha uma especificação do componente no arquivo component.yaml. A especificação de componente descreve o componente para o Kubeflow Pipelines em termos de argumentos, o URL da imagem do contêiner do Docker a ser executado e as saídas. As operações de componentes são criadas automaticamente com base nos arquivos component.yaml usando a função kfp.components.load_component durante a compilação do pipeline. Os arquivos YAML de especificação de componente podem ser compartilhados na organização e reutilizados em diferentes orquestrações do pipeline.

• Uso de componentes predefinidos do Google Cloud: o SDK dos componentes de pipeline do Google Cloud fornece componentes predefinidos que executam vários serviços gerenciados no Google Cloud, usando os parâmetros necessários. Esses componentes ajudam a executar tarefas usando serviços como o BigQuery, o Dataflow, o Dataproc e a Vertex AI. Para facilitar o uso, carregue esses componentes usando o SDK google_cloud_pipeline_components. Outros componentes predefinidos estão disponíveis para a execução de jobs em outras plataformas e serviços.

Também é possível usar a TFX Pipeline DSL e os componentes do TFX (em inglês). Um componente do TFX encapsula a funcionalidade de metadados. O driver fornece metadados ao executor, consultando o armazenamento de metadados. O editor aceita os resultados do executor e os armazena em metadados. Também é possível implementar seu componente personalizado, que tem a mesma integração com os metadados. É possível compilar os pipelines da TFX para um YAML compatível com a Vertex AI Pipelines usando tfx.orchestration.experimental.KubeflowV2DagRunner. Depois, envie o arquivo para a Vertex AI Pipelines para execução.

O diagrama a seguir mostra como, na Vertex AI Pipelines, uma tarefa conteinerizada pode invocar outros serviços, como jobs do BigQuery, jobs de treinamento distribuídos da Vertex AI e jobs do Dataflow.

Figura 5. Vertex AI Pipelines que invoca serviços gerenciados do Google Cloud.

A Vertex AI Pipelines permite orquestrar e automatizar um pipeline de ML de produção executando os serviços necessários do Google Cloud. Na Figura 5, o Vertex ML Metadata serve como o armazenamento de metadados de ML para a Vertex AI Pipelines.

Os componentes do pipeline não ficam limitados à execução de serviços relacionados à TFX no Google Cloud. Esses componentes podem executar qualquer serviço relacionado a dados e computação, incluindo Dataproc para jobs do SparkML, AutoML e outras cargas de trabalho de computação.

As tarefas de conteinerização na Vertex AI Pipelines têm as seguintes vantagens:

• Desassociam o ambiente de execução do ambiente de execução do seu código.
• Fornecem a reprodutibilidade do código entre o ambiente de desenvolvimento e de produção, já que as coisas testadas são as mesmas na produção.
• Isolam cada componente do pipeline, cada um pode ter a própria versão do ambiente de execução, linguagens diferentes e bibliotecas diferentes.
• Ajudam na composição de pipelines complexos.
• Integração com o Vertex ML Metadata para rastreamento e reprodutibilidade de execuções e artefatos de pipelines.

Para uma introdução abrangente à Vertex AI Pipelines, consulte a lista de exemplos de notebooks disponíveis.

Como acionar e programar a Vertex AI Pipelines

Ao implantar um pipeline na produção, é preciso automatizar as respectivas execuções, dependendo dos cenários apresentados na seção Automação do pipeline de ML.

O SDK da Vertex AI permite operar o pipeline de maneira programática. A classe google.cloud.aiplatform.PipelineJob inclui APIs para criar experimentos e implantar e executar pipelines. Usando o SDK, é possível invocar pipelines da Vertex AI de outro serviço para alcançar gatilhos baseados em eventos ou programador.

Figura 6. Diagrama de fluxo que demonstra vários gatilhos da Vertex AI Pipelines usando Pub/Sub e Cloud Functions

Na Figura 6, é possível ver um exemplo de como acionar o serviço Vertex AI Pipelines para executar um pipeline. O pipeline é acionado usando o SDK da Vertex AI do Cloud Functions. O Cloud Functions é um assinante do Pub/Sub acionado com base em novas mensagens. Qualquer serviço que queira acionar a execução do pipeline pode simplesmente publicar no tópico do Pub/Sub correspondente. No exemplo acima, há três serviços de publicação:

• O Cloud Scheduler publica mensagens em uma programação e, portanto, aciona o pipeline.
• O Cloud Composer publica mensagens como parte de um fluxo de trabalho maior. Por exemplo, um fluxo de trabalho de ingestão de dados que aciona o pipeline de treinamento depois que novos dados são ingeridos no BigQuery.
• O Cloud Logging publica uma mensagem com base em registros que atendem a alguns critérios de filtragem. É possível configurar os filtros para detectar a chegada de novos dados ou até alertas de desvio e deslocamento gerados pelo serviço Vertex AI Model Monitoring.

Como configurar CI/CD para ML no Google Cloud

O Kubeflow Pipelines permite orquestrar sistemas de ML com várias etapas, incluindo pré-processamento de dados, treinamento e avaliação de modelos e implantação de modelos. Na fase de exploração da ciência de dados, a Vertex AI Pipelines ajuda na experimentação rápida de todo o sistema. Na fase de produção, a Vertex AI Pipelines permite automatizar a execução do pipeline com base em novos dados para treinar ou treinar novamente o modelo de ML.

Arquitetura de CI/CD

O diagrama a seguir mostra uma visão geral de alto nível de CI/CD para ML com a Vertex AI Pipelines.

Figura 7: visão geral de alto nível de CI/CD com a Vertex AI Pipelines.

Na essência dessa arquitetura está o Cloud Build. O Cloud Build pode importar origem do Cloud Source Repositories, do GitHub ou do Bitbucket e, em seguida, executar um build de acordo com suas especificações e produzir artefatos, como contêineres do Docker ou arquivos .tar do Python.

O Cloud Build executa o build como uma série de etapas de criação, definidas em um arquivo de configuração do build (cloudbuild.yaml). Cada etapa de criação é executada em um contêiner do Docker. É possível usar as etapas de compilação compatíveis fornecidas pelo Cloud Build ou escrever suas próprias etapas de compilação.

O processo do Cloud Build, que executa o CI/CD necessário para seu sistema de ML, pode ser executado manualmente ou por meio de gatilhos de compilação automatizados. Gatilhos executam as etapas de compilação configuradas sempre que alterações são enviadas para a origem do build. É possível definir um gatilho de compilação para executar a rotina de compilação em alterações ao repositório de origem ou para executá-la somente quando as alterações corresponderem a determinados critérios.

Além disso, é possível ter rotinas de compilação (arquivos de configuração do Cloud Build) que são executadas em resposta a diferentes gatilhos. Por exemplo, é possível ter rotinas de criação que são acionadas quando as confirmações são feitas na ramificação de desenvolvimento ou na ramificação mestre.

É possível usar substituições de variáveis de configuração para definir as variáveis de ambiente em tempo de compilação. Essas substituições são capturadas dos builds acionados. Essas variáveis incluem $COMMIT_SHA, $REPO_NAME, $BRANCH_NAME, $TAG_NAME e $REVISION_ID. Outras variáveis não baseadas em gatilho são $PROJECT_ID e $BUILD_ID. Substituições são úteis para variáveis com um valor que não é conhecido até o momento da criação ou para reutilizar uma solicitação de criação existente com valores variáveis diferentes.

Caso de uso de fluxo de trabalho de CI/CD

Um repositório de código-fonte costuma incluir:

• O código-fonte do fluxo de trabalho de pipelines do Python em que o fluxo de trabalho do pipeline está definido
• O código-fonte de componentes de pipeline do Python e os respectivos arquivos de especificação para os diferentes componentes de pipeline, como validação e transformação de dados, treinamento e avaliação de modelo e da exibição de modelo.
• Dockerfiles necessários para a criação de imagens de contêiner do Docker, uma para cada componente do pipeline.
• Testes de unidade e integração do Python para testar os métodos implementados no componente e no pipeline em geral.
• Outros scripts, incluindo o arquivo cloudbuild.yaml, gatilhos de teste e implantações de pipeline.
• Arquivos de configuração (por exemplo, settings.yaml), incluindo configurações dos parâmetros de entrada do pipeline.
• notebooks usados para análise exploratória de dados, análise de modelos e experimentação interativa em modelos;

No exemplo a seguir, uma rotina de compilação é acionada quando um desenvolvedor envia código-fonte para a ramificação de desenvolvimento do ambiente de ciência de dados.

Figura 8. Exemplos de etapas de compilação executadas pelo Cloud Build.

Conforme mostrado na figura 7, o Cloud Build executa as seguintes etapas de compilação:

1. O repositório do código-fonte é copiado para o ambiente de execução do Cloud Build, no diretório /workspace.
2. Execução de testes de unidade e integração.
3. (Opcional) Análises de código estático são executadas, como Pylint.
4. Se os testes forem aprovados, as imagens de contêiner do Docker serão criadas, uma para cada componente do pipeline. As imagens são marcadas com o parâmetro $COMMIT_SHA.
5. É feito upload das imagens de contêiner do Docker no Artifact Registry.
6. O URL da imagem é atualizado em cada um dos arquivos component.yaml com as imagens de contêiner do Docker criadas e marcadas.
7. O fluxo de trabalho do pipeline é compilado para produzir o arquivo pipeline.json.
8. O arquivo pipeline.json é enviado para o Artifact Registry.
9. (Opcional) Executar o pipeline com os valores de parâmetro como parte de um teste de integração ou execução de produção. O pipeline executado gera um novo modelo e também pode implantá-lo como uma API na Vertex AI Prediction.

Para ver um exemplo de MLOps de ponta a ponta pronto para produção que inclui CI/CD usando o Cloud Build, consulte o guia oficial no GitHub.

Outras considerações

Ao configurar a arquitetura de CI/CD de ML no Google Cloud, considere os seguintes aspectos:

• Para o ambiente de ciência de dados, é possível usar uma máquina local ou um Vertex AI Workbench.
• Será possível configurar o pipeline automatizado do Cloud Build para pular gatilhos, por exemplo, se apenas arquivos de documentação forem editados ou se os notebooks de experimentação forem modificados.
• É possível executar o pipeline para testes de integração e regressão como um teste de compilação. Antes de o pipeline ser implantado no ambiente de destino, use o método wait() para aguardar a conclusão da execução do pipeline enviado.
• Como alternativa ao uso do Cloud Build, é possível usar outros sistemas de compilação, como o Jenkins. Uma implantação pronta do Jenkins está disponível no Google Cloud Marketplace.
• É possível configurar o pipeline para ser implantado automaticamente em diferentes ambientes, incluindo desenvolvimento, teste e preparo, com base em diferentes gatilhos. Além disso, é possível implantar manualmente em ambientes específicos, como pré-produção ou produção, geralmente após o recebimento de uma aprovação de lançamento. É possível ter várias rotinas de compilação para diferentes gatilhos ou para diferentes ambientes de destino.
• É possível usar o Apache Airflow, um framework de programação e orquestração conhecido para fluxos de trabalho de uso geral, que pode ser executado usando o serviço Cloud Composer totalmente gerenciado. Para mais informações sobre como orquestrar pipelines de dados com o Cloud Composer e o Cloud Build, consulte Como configurar um pipeline de CI/CD para seu fluxo de trabalho de processamento de dados.
• Ao implantar uma nova versão do modelo em produção, implante-a como versão canário para ter uma ideia do desempenho (CPU, memória e uso do disco). Antes de configurar o novo modelo para exibir todo o tráfego ativo, também é possível realizar testes A/B. Configure o novo modelo para exibir de 10% a 20% do tráfego ativo. Se o novo modelo tiver um desempenho melhor que o atual, será possível configurar o novo modelo para exibir todo o tráfego. Caso contrário, o sistema de exibição reverterá para o modelo atual.

A seguir

• Saiba mais sobre Entrega contínua no estilo GitOps com o Cloud Build.
• Saiba mais sobre Como configurar um pipeline de CI/CD para seu fluxo de trabalho de processamento de dados.
• Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.