Arquitetura de MLOps usando TFX, pipelines do Kubeflow e Cloud Build

Neste documento, descrevemos a arquitetura geral de um sistema de machine learning (ML) usando bibliotecas do TensorFlow Extended (TFX). Nele também, abordamos como configurar integração contínua (CI), entrega contínua (CD) e treinamento contínuo (CT, na sigla em inglês) para o sistema de ML usando o Cloud Build e os pipelines do Kubeflow.

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

Este documento é destinado 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 qualidade, facilidade de manutenção e de adaptação dos pipelines de ML.

Neste documento, abordamos 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 pipelines do Kubeflow
  • 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. Além disso, é preciso automatizar a execução do pipeline para o treinamento contínuo dos 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 de alto nível 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. Na prática, no entanto, os modelos muitas vezes se dividem quando implantados no mundo real, por não se adaptarem à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 para capturar padrões emergentes. O CT é abordado mais adiante neste documento, na seção ML com Kubeflow Pipelines.
  • Configurar um sistema de entrega contínua para implantar com frequência novas implementações de todo o pipeline de ML. Abordaremos 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 seus modelos com novos dados. É possível acionar o pipeline sob demanda, conforme programado, na disponibilidade de novos dados, na 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, você precisa 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, veja a relação entre o pipeline de CI/CD e o pipeline de CT de ML.

A saída do pipeline de CI/CD é o pipeline de CT.

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 bem-sucedido exibirá um novo serviço de previsão de modelo.

Como projetar um sistema de ML baseado em TFX

Nas seções a seguir, abordamos como projetar um sistema de ML integrado usando o 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 do TFX é uma sequência de componentes que implementam um sistema de ML. Esse pipeline do 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:

Visão geral do sistema de ML do TFX

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

Etapas de um sistema de ML baseado em TFX.

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 origens 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 a distribuição de dados e desvios de esquema. As saídas desta 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 desta etapa são arquivos de dados para treinar e avaliar o modelo, geralmente transformado no formato TFRecords (em inglês). Além disso, os artefatos de transformação produzidos ajudam a construir as entradas do modelo e exportar o modelo salvo 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, ou use outros serviços como Katib (links em inglês). A saída desta 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, ele é avaliado em um conjunto de dados quanto à qualidade usando 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 ajuda a garantir que o modelo só seja promovido para exibição se atender aos critérios de qualidade. Os critérios podem incluir 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 desta 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 TensorFlow Serving. A saída desta etapa é um serviço de previsão implantado do modelo de ML treinado. É possível substituir esta etapa armazenando o modelo treinado em um registro de modelo. Posteriormente, um modelo separado que exibe o processo de CI/CD é iniciado.

Para um tutorial que mostra como usar as bibliotecas do TFX, consulte ML com TensorFlow Extended (TFX) (em inglês).

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. No diagrama a seguir, veja como cada etapa do pipeline de ML do TFX é executada usando um serviço gerenciado no Google Cloud, o que garante agilidade, confiabilidade e desempenho em grande escala.

Etapas de um sistema de ML baseado em TFX no Google Cloud.

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 do 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 AI Platform Training
Avaliação e validação de modelo TensorFlow Model Analysis Dataflow
Exibição de modelo para previsão TensorFlow Serving AI Platform Prediction
Armazenamento de artefatos de modelo N/A AI Hub
  • 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 AI Hub é um repositório hospedado de nível empresarial para descobrir, compartilhar e reutilizar recursos de inteligência artificial (IA) e ML. Para armazenar modelos treinados e validados, além dos metadados relevantes, use o AI Hub como um registro de modelo.

  • O AI Platform é um serviço gerenciado para treinar e exibir modelos de ML em grande escala. O AI Platform Training, além de ser compatível com os modelos do TensorFlow, Scikit-learn e XGboost, também aceita modelos implementados em qualquer framework usando um contêiner personalizado fornecido pelo usuário. Além disso, há disponibilidade de um serviço Bayesiano (em inglês) escalonável e baseado em otimização para ajuste de hiperparâmetros. Os modelos treinados podem ser implantados no AI Platform Prediction como um microsserviço que tem uma API REST.

Como orquestrar o sistema de ML usando pipelines do Kubeflow

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 poderá 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. 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 pipelines do Kubeflow

O Kubeflow é um framework de código aberto do Kubernetes (links em inglês) para desenvolver e executar cargas de trabalho de ML portáteis. Kubeflow Pipelines (em inglês) é um serviço do Kubeflow que permite compor, orquestrar e automatizar sistemas de ML, em que cada componente do sistema pode ser executado no Kubeflow, no Google Cloud ou em outras plataformas de nuvem. A plataforma Kubeflow 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. O Kubeflow Pipelines usa o Argo (em inglês) para orquestrar os recursos do Kubernetes;
  • um SDK do Python para definir e manipular pipelines e componentes;
  • notebooks para interagir com o sistema usando o SDK do Python;
  • um armazenamento de metadados de ML para salvar informações sobre execuções, modelos, conjuntos de dados e outros artefatos.

Veja, a seguir, como se constitui um pipeline do Kubeflow:

  • Um conjunto de tarefas de ML contentorizadas ou componentes. Um componente de pipeline é um código autossuficiente que é empacotado como uma imagem do Docker (em inglês). Um componente usa argumentos de entrada, produz arquivos de saída e executa uma etapa no pipeline.

  • Uma especificação da sequência de tarefas de ML, definida por meio de uma linguagem de domínio específico (DSL, na sigla em inglês) (em inglês) 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 na 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 deles 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.

No diagrama a seguir, veja um gráfico de exemplo do Kubeflow Pipelines.

Gráfico do pipeline de ML usando o Kubeflow Pipelines.

Figura 4. Um gráfico de exemplo do Kubeflow Pipelines.

Componentes do Kubeflow Pipelines

Para que um componente seja invocado no pipeline, você precisa 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 de sua função Python usando a função kfp.components.func_to_container_op (em inglês).

  • Criação de componente reutilizável: essa funcionalidade exige que o componente inclua uma especificação de componente (links em inglês) 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 ops de componente são criadas automaticamente dos arquivos component.yaml usando a função ComponentStore.load_components no SDK do Kubeflow Pipelines (links em inglês) durante a compilação do pipeline. As especificações reutilizáveis de component.yaml podem ser compartilhadas com o AI Hub (em inglês) para composição em diferentes projetos do Kubeflow Pipelines.

  • Uso de componentes predefinidos do Google Cloud (em inglês): o Kubeflow Pipelines fornece componentes predefinidos que executam vários serviços gerenciados no Google Cloud fornecendo os parâmetros necessários. Esses componentes ajudam a executar tarefas usando serviços como BigQuery, Dataflow, Dataproc e AI Platform (links em inglês). Esses componentes predefinidos do Google Cloud também estão disponíveis no AI Hub. Assim como o uso de componentes reutilizáveis, essas ops são criadas automaticamente das especificações predefinidas de componente por meio de ComponentStore.load_components (em inglês). Outros componentes predefinidos (em inglês) estão disponíveis para executar jobs no Kubeflow e em outras plataformas.

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 (em inglês), que tem a mesma integração com os metadados. O TFX fornece uma interface de linha de comando (CLI, na sigla em inglês) que compila o código Python do pipeline em um arquivo YAML e descreve o fluxo de trabalho do Argo (em inglês). Em seguida, você envia o arquivo para o Kubeflow Pipelines.

No diagrama a seguir, veja, no Pipeline Kubeflow, como uma tarefa contentorizada pode invocar outros serviços, como jobs do BigQuery, jobs de treinamento (distribuídos) do AI Platform e jobs do Dataflow.

Arquitetura do Kubeflow Pipelines no Google Cloud.

Figura 5. Pipeline de ML com Kubeflow Pipelines e serviços gerenciados do Google Cloud.

Os pipelines do Kubeflow permitem orquestrar e automatizar um pipeline de ML de produção executando os serviços necessários do Google Cloud. Na figura 5, o Cloud SQL funciona como armazenamento de metadados de ML para o Kubeflow Pipelines.

Os componentes do Kubeflow Pipelines não estão limitados à execução de serviços relacionados ao 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 contentorização no Kubeflow 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, visto que as coisas testadas são as mesmas na produção.
  • Isolam cada componente no pipeline, cada um podendo ter a própria versão do ambiente de execução, linguagens diferentes e bibliotecas diferentes.
  • Ajudam na composição de pipelines complexos.
  • Integram-se ao armazenamento de metadados de ML para fins de rastreamento e reprodutibilidade.

Para uma introdução abrangente ao Kubeflow Pipelines e um exemplo com bibliotecas do TFX, consulte a postagem do blog Primeiros passos com o Kubeflow Pipelines (em inglês).

Como acionar e programar Kubeflow Pipelines

Quando você implanta um pipeline do Kubeflow na produção, precisa automatizar as respectivas execuções, dependendo dos cenários apresentados na seção Automação do pipeline de ML.

O Kubeflow Pipelines fornece um SDK do Python para operar o pipeline de forma programática. A classe kfp.Client (em inglês) inclui APIs para criar experimentos e implantar e executar pipelines. Ao usar o SDK do Kubeflow Pipelines, você tem como invocar o Kubeflow Pipelines usando os seguintes serviços:

O Kubeflow Pipelines também fornece um programador integrado para pipelines recorrentes nele.

Como configurar CI/CD para ML no Google Cloud

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

Arquitetura de CI/CD

No diagrama a seguir, veja um panorama de alto nível de CI/CD para ML com Kubeflow Pipelines.

Arquitetura de CI/CD para pipeline de ML usando Kubeflow Pipelines.

Figura 6: visão geral de alto nível de CI/CD para Kubeflow Pipelines.

A essência dessa arquitetura é o Cloud Build, um serviço gerenciado que executa seus builds na infraestrutura do Google Cloud. O Cloud Build pode importar origem do Cloud Source Repositories, do GitHub ou do Bitbucket (links em inglês) 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 seu build como uma série de etapas de compilação, definidas em um arquivo de configuração de compilação (cloulbuild.yaml). Cada etapa de versã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. Os 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, a seguinte configuração é possível:

  • Uma rotina de compilação começa quando são feitas confirmações em uma ramificação de desenvolvimento.
  • Uma rotina de compilação começa quando são feitas confirmações na ramificação mestre.

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

Caso de uso de fluxo de trabalho de CI/CD

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

  • código-fonte Python para implementar os componentes do Kubeflow Pipelines, incluindo validação de dados, transformação de dados, treinamento de modelo, avaliação de modelo e exibição de modelo;
  • testes de unidade do Python para testar os métodos implementados no componente;
  • Dockerfiles necessários para criar imagens de contêiner do Docker, uma para cada componente do Kubeflow Pipelines;
  • o arquivo component.yaml que define as especificações de componente (em inglês) do pipeline, usadas para gerar as ops de componente na definição do pipeline;
  • um módulo do Python (por exemplo, pipeline.py) em que o fluxo de trabalho do Kubeflow Pipelines é definido;
  • outros scripts e arquivos de configuração, incluindo os arquivos cloudbuild.yaml;
  • notebooks usados para análise exploratória de dados, análise de modelo e experimentação interativa em modelos;
  • um arquivo de configurações (por exemplo, settings.yaml), incluindo configurações dos parâmetros de entrada do pipeline.

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.

Exemplos de etapas de compilação.

Figura 7. 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. Os testes de unidade são executados.
  3. (Opcional) A análise de código estático é executada, como Pylint (em inglês).
  4. Se os testes forem aprovados, as imagens de contêiner do Docker serão criadas, uma para cada componente do Kubeflow Pipelines. As imagens são marcadas com o parâmetro $COMMIT_SHA.
  5. É feito o upload das imagens de contêiner do Docker para o Container 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 Kubeflow Pipelines é compilado para produzir o arquivo workflow.tar.gz.
  8. É feito o upload do arquivo workflow.tar.gz é para o Cloud Storage.
  9. O pipeline compilado é implantado no Kubeflow Pipelines, o que envolve:
    1. ler os parâmetros de pipeline do arquivo settings.yaml;
    2. criar um experimento (ou usar um atual);
    3. implantar o pipeline no Kubeflow Pipelines e marcar o nome dele com uma versão;
  10. (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 implanta um modelo como uma API no AI Platform.

Para ver um exemplo abrangente do Cloud Build que abrange a maioria dessas etapas, consulte um exemplo simples de CI/CD com Kubeflow Pipelines e Cloud Build (em inglês).

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 uma instância de notebooks do AI Platform baseada em uma VM de aprendizado profundo (DLVM, na sigla em inglês).
  • 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 da implantação do pipeline no ambiente de destino, use o método wait_for_pipeline_completion (em inglês) para executá-lo em um conjunto de dados de exemplo e testá-lo.
  • 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 receber 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 (em inglês), 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 na 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 do 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