Arquitectura para operaciones de aprendizaje automático (MLOps) mediante TFX, Kubeflow Pipelines y Cloud Build

En este documento, se describe la arquitectura general de un sistema de aprendizaje automático (AA) mediante las bibliotecas de TensorFlow Extended (TFX). También se analiza cómo configurar una integración continua (CI), una entrega continua (CD) y un entrenamiento continuo (CT) para el sistema de AA mediante Cloud Build y Kubeflow Pipelines.

En este documento, los términos sistema de AA y canalización de AA hacen referencia a canalizaciones de entrenamiento de modelos de AA, en lugar de canalizaciones de predicción o puntuación de modelos.

Este documento está dirigido a ingenieros de AA y científicos de datos que deseen adaptar sus prácticas de CI/CD para llevar soluciones de AA a la producción en Google Cloud y que quieran garantizar la calidad, la capacidad de mantenimiento y la adaptabilidad de sus canalizaciones de AA.

En este documento, se incluyen los siguientes temas:

  • Explicación de las IC/EC y la automatización en el AA
  • Diseño de una canalización integrada de AA con TFX
  • Organización y automatización de la canalización de AA mediante Kubeflow Pipelines
  • Configuración de un sistema de IC/EC para la canalización de AA mediante Cloud Build

Operaciones de aprendizaje automático

Para integrar un sistema de AA en un entorno de producción, debes organizar los pasos en la canalización de AA. Además, debes automatizar la ejecución de la canalización para el entrenamiento continuo de los modelos. Para experimentar con ideas y funciones nuevas, debes adoptar prácticas de CI/CD en las implementaciones nuevas de las canalizaciones. En las siguientes secciones, se proporciona una descripción general de alto nivel de CI/CD y CT en el AA.

Automatización de canalizaciones de AA

En algunos casos prácticos, el proceso manual de entrenamiento, validación e implementación de modelos de AA puede ser suficiente. Este enfoque manual funciona si tu equipo administra solo unos pocos modelos de AA que no se vuelven a entrenar ni se cambian con frecuencia. Sin embargo, en la práctica, los modelos a menudo se rompen cuando se implementan en el mundo real, ya que no se adaptan a los cambios de la dinámica del entorno o a los datos que describen esa dinámica.

Para que el sistema de AA se adapte a esos cambios, debes aplicar las siguientes técnicas de operaciones de aprendizaje automático:

  • Automatiza la ejecución de la canalización de AA para volver a entrenar modelos nuevos en datos nuevos a fin de capturar patrones emergentes. El entrenamiento continuo se explica más adelante en este documento en la sección AA con Kubeflow Pipelines.
  • Configura un sistema de entrega continua para realizar con frecuencia implementaciones nuevas de la canalización de AA completa. La CI/CD se analiza más adelante en este documento, en la sección Configuración de CI/CD para el AA en Google Cloud.

Puedes automatizar las canalizaciones de producción de AA para volver a entrenar los modelos con datos nuevos. Puedes activar la canalización a pedido o según estos factores: un programa, la disponibilidad de datos nuevos, la degradación del rendimiento del modelo, los cambios significativos de las propiedades estadísticas de los datos, o según otras condiciones.

Comparación entre la canalización de CI/CD y la de CT

La disponibilidad de datos nuevos es un activador para volver a entrenar el modelo de AA. La disponibilidad de una implementación nueva de la canalización de AA (incluida la arquitectura, la ingeniería de atributos y los hiperparámetros del modelo nuevo) constituye otro activador importante para volver a ejecutar la canalización de AA. Esta implementación nueva de la canalización de AA actúa como una versión nueva del servicio de predicción del modelo, por ejemplo, un microservicio con una API de REST para la entrega en línea. La diferencia entre ambos casos es la siguiente:

  • Para entrenar un modelo de AA nuevo con datos nuevos, se ejecuta la canalización de CT que se implementó antes. No se implementan canalizaciones ni componentes nuevos; solo se entrega un servicio de predicción nuevo o un modelo recién entrenado al final de la canalización.
  • Para entrenar un modelo de AA nuevo con una implementación nueva, se implementa una canalización nueva a través de una canalización de CI/CD.

Para implementar canalizaciones de AA nuevas con rapidez, debes configurar una canalización de CI/CD. Esta canalización se encarga de implementar de forma automática las canalizaciones y los componentes de AA nuevos cuando hay implementaciones nuevas disponibles y aprobadas para varios entornos (como el desarrollo, la prueba, la etapa de pruebas, la preproducción, el canary y la producción).

En el siguiente diagrama, se muestra la relación entre la canalización de CI/CD y la de CT de AA.

El resultado de la canalización de CI/CD es la canalización de CT.

Figura 1. Canalizaciones de IC/EC y de ET de AA.

El resultado de estas canalizaciones es el siguiente:

  • Si se realiza una implementación nueva, una canalización de CI/CD exitosa implementa una nueva canalización de CT de AA.
  • Si se proporcionan datos nuevos, una canalización de CT exitosa entrega un servicio de predicción de modelos nuevo.

Diseña un sistema de AA basado en TFX

En las siguientes secciones, se analiza cómo diseñar un sistema de AA integrado mediante TensorFlow Extend (TFX) con el fin de configurar una canalización de CI/CD para el sistema de AA. Aunque existen varios frameworks que permiten compilar modelos de AA, TFX es una plataforma de AA integrada para el desarrollo y la implementación de sistemas de AA de producción. Una canalización de TFX es una secuencia de componentes que implementan un sistema de AA. Esta canalización de TFX está diseñada para tareas de AA escalables y de alto rendimiento. Estas tareas incluyen la creación de modelos, el entrenamiento, la validación, la inferencia y la administración de implementaciones. Las bibliotecas clave de TFX son las siguientes:

Descripción general del sistema de AA de TFX

En el siguiente diagrama, se muestra cómo se integran las distintas bibliotecas de TFX para componer un sistema de AA.

Pasos de un sistema de AA basado en TFX

Figura 2. Un sistema típico de AA basado en TFX.

En la Figura 2, se muestra un sistema típico de AA basado en TFX. Los siguientes pasos se pueden completar de forma manual o mediante una canalización automatizada:

  1. Extracción de datos: El primer paso consiste en extraer los datos de entrenamiento nuevos de las fuentes de datos. Mediante este paso, se obtienen los archivos de datos que se usan para entrenar y evaluar el modelo.
  2. Validación de datos: TFDV valida los datos con el esquema de datos (sin procesar) requerido. El esquema de datos se crea y se corrige durante la fase de desarrollo, antes de la implementación del sistema. Los pasos de la validación de datos detectan anomalías relacionadas con la distribución de datos y los sesgos de esquemas. Mediante este paso, se detectan las anomalías (si hay); también se determina si se ejecutarán o no los pasos descendentes.
  3. Transformación de los datos: Una vez que los datos se validan, estos se dividen y se preparan para la tarea de AA mediante transformaciones de datos y operaciones de ingeniería de atributos con TFT. Con este paso, se obtienen los archivos de datos para entrenar y evaluar el modelo, por lo general, en formato TFRecords. Además, los artefactos de transformación que se producen ayudan a crear las entradas del modelo y exportar el modelo guardado después del entrenamiento.
  4. Entrenamiento y ajuste del modelo: Para implementar y entrenar el modelo de AA, usa las API de tf.estimator o tf.Keras con los datos transformados del paso anterior. A fin de seleccionar la configuración de parámetros que permita obtener el mejor modelo, puedes usar el configurador de Keras, una biblioteca de ajuste de hiperparámetros para Keras, o puedes usar otros servicios, como Katib. Con este paso, se obtiene un modelo guardado que se usa en la evaluación y otro modelo guardado usado en las entregas en línea del modelo para la predicción.
  5. Evaluación y validación del modelo: Cuando el modelo se exporta después del paso de entrenamiento, se evalúa en un conjunto de datos de prueba para examinar su calidad mediante el TFMA. Con el TFMA, se evalúa la calidad del modelo como un todo y se identifica qué parte del modelo de datos no funciona. Esta evaluación ayuda a garantizar que el modelo se use para entregar solo si cumple con los criterios de calidad. Estos criterios pueden incluir un rendimiento favorable en varios subconjuntos de datos (por ejemplo, datos demográficos y ubicaciones) y un rendimiento superior al de modelos anteriores o modelos comparativos. Mediante este paso, se obtiene un conjunto de métricas de rendimiento, que permiten decidir si se debe promover el modelo a producción.
  6. Entrega del modelo para la predicción: Una vez que se valida el modelo recién entrenado, se implementa como un microservicio que entrega predicciones en línea mediante TensorFlow Serving. Con este paso, se obtiene un servicio de predicción implementado del modelo de AA entrenado. Si deseas reemplazar este paso, almacena el modelo entrenado en un registro de modelos. Luego, se inicia otro proceso de CI/CD de entrega del modelo.

Para ver un instructivo en el que se muestra cómo usar las bibliotecas de TFX, consulta AA con TensorFlow Extended (TFX).

Sistema de AA de TFX en Google Cloud

En un entorno de producción, los componentes del sistema deben ejecutarse a gran escala en una plataforma confiable. En el siguiente diagrama, se muestra cómo cada paso de la canalización de AA de TFX se ejecuta mediante un servicio administrado en Google Cloud, que garantiza agilidad, confiabilidad y rendimiento a gran escala.

Pasos de un sistema de AA basado en TFX en Google Cloud.

Figura 3. Sistema de AA basado en TFX en Google Cloud.

En la siguiente tabla, se describen los servicios clave de Google Cloud que se muestran en la figura 3:

Paso Biblioteca de TFX Servicio de Google Cloud
Extracción y validación de datos Validación de datos de TensorFlow Dataflow
Transformación de datos TensorFlow Transform Dataflow
Entrenamiento y ajuste de modelos TensorFlow AI Platform Training
Evaluación y validación de modelos Análisis de modelos de TensorFlow Dataflow
Entrega de modelos para la predicción TensorFlow Serving AI Platform Prediction
Almacenamiento de artefactos de modelos NA AI Hub
  • Dataflow es un servicio confiable, completamente administrado y sin servidores que permite ejecutar canalizaciones de Apache Beam a gran escala en Google Cloud. Dataflow se usa para escalar los siguientes procesos:

    • Calcular las estadísticas para validar los datos entrantes
    • Preparar y transformar los datos
    • Evaluar el modelo en un conjunto de datos grande
    • Calcular las métricas según diferentes aspectos del conjunto de datos de evaluación
  • Cloud Storage es un almacenamiento duradero y con alta disponibilidad para objetos binarios de gran tamaño. Cloud Storage aloja artefactos producidos durante la ejecución de la canalización de AA, incluidos los siguientes:

    • Anomalías en los datos (si existen)
    • Artefactos y datos transformados
    • Modelo exportado (entrenado)
    • Métricas de evaluación de modelos
  • AI Hub es un repositorio alojado de nivel empresarial para descubrir, compartir y reutilizar elementos de AA y de inteligencia artificial (IA). Para almacenar modelos entrenados y validados, junto con los metadatos correspondientes, puedes usar AI Hub como registro de modelos.

  • AI Platform es un servicio administrado que permite entrenar y entregar modelos de AA a gran escala. AI Platform Training admite modelos de TensorFlow, Scikit-learn y XGboost y, también, modelos implementados en cualquier framework que use un contenedor personalizado proporcionado por el usuario. Además, está disponible un servicio escalable bayesiano basado en la optimización para el ajuste de hiperparámetros. Los modelos entrenados se pueden implementar en AI Platform Prediction como un microservicio que tiene una API de REST.

Organiza el sistema de AA mediante Kubeflow Pipelines

En este documento, se explica cómo diseñar un sistema de AA basado en TFX y cómo ejecutar cada componente del sistema a gran escala en Google Cloud. Sin embargo, necesitas un organizador para conectar estos componentes diferentes del sistema. El organizador ejecuta la canalización en una secuencia y pasa de un paso a otro de forma automática según las condiciones definidas. Por ejemplo, una condición definida podría ser ejecutar el paso de entrega del modelo después del paso de evaluación si las métricas de evaluación alcanzan los límites predefinidos. Organizar la canalización de AA es útil en las fases de desarrollo y producción:

  • Durante la fase de desarrollo, la organización ayuda a los científicos de datos a ejecutar el experimento de AA, en lugar de tener que ejecutar cada paso de forma manual.
  • Durante la fase de producción, la organización ayuda a automatizar la ejecución de la canalización de AA según un programa o condiciones de activación determinadas.

AA con Kubeflow Pipelines

Kubeflow es un framework de código abierto de Kubernetes para desarrollar y ejecutar cargas de trabajo de AA portátiles. Kubeflow Pipelines es un servicio de Kubeflow que te permite componer, organizar y automatizar sistemas de AA, en los que cada componente puede ejecutarse en Kubeflow, Google Cloud o en otras plataformas de nube. La plataforma de Kubeflow Pipelines consta de los siguientes componentes:

  • Una interfaz de usuario para administrar y realizar un seguimiento de experimentos, trabajos y ejecuciones
  • Un motor para programar flujos de trabajo de AA de varios pasos. Las canalizaciones de Kubeflow usan Argo para organizar los recursos de Kubernetes
  • Un SDK de Python para definir y manipular las canalizaciones y los componentes
  • Notebooks para interactuar con el sistema mediante el SDK de Python
  • Un almacén de metadatos de AA para guardar información sobre las ejecuciones, los modelos, los conjuntos de datos y otros artefactos

Lo siguiente constituye una canalización de Kubeflow:

  • Un conjunto de tareas de AA en contenedores, o componentes. Un componente de canalización es un código autónomo que se empaqueta como una imagen de Docker. Un componente toma argumentos de entrada, produce archivos de resultado y realiza un paso en la canalización.

  • Una especificación de la secuencia de las tareas de AA, definida a través de un lenguaje específico de dominio (DSL) de Python. La topología del flujo de trabajo se define de forma implícita cuando se conectan los resultados de un paso ascendente con los de un paso descendente. Un paso en la definición de la canalización invoca a un componente de la canalización. En una canalización compleja, los componentes pueden ejecutarse varias veces en bucles o de forma condicional.

  • Un conjunto de parámetros de entrada de la canalización, cuyos valores se pasan a los componentes de la canalización, incluidos los criterios para filtrar datos y la ubicación en la que se almacenan los artefactos que produce la canalización.

En el siguiente diagrama, se puede ver un grafo de muestra de Kubeflow Pipelines.

Grafo de canalización de AA mediante Kubeflow Pipelines

Figura 4. Un grafo de muestra de Kubeflow Pipelines

Componentes de Kubeflow Pipelines

A fin de que un componente se invoque en la canalización, debes crear una operación de componente. Para crearla, puedes usar los siguientes métodos:

  • Implementa un componente liviano de Python: Este componente no requiere que compiles una imagen de contenedor nueva para cada cambio de código y está diseñado a fin de lograr una iteración rápida en entornos de notebook. Puedes crear un componente liviano a partir de tu función de Python mediante la función kfp.components.func_to_container_op.

  • Crea un componente reutilizable: Esta función requiere que el componente incluya una especificación en el archivo component.yaml. En la especificación del componente, se describe el componente de Kubeflow Pipelines en términos de los argumentos, la URL de la imagen de contenedor de Docker que se ejecutará y los resultados. Las operaciones del componente se crean de forma automática a partir de los archivos component.yaml mediante la función ComponentStore.load_components del SDK de Kubeflow Pipelines durante la compilación de la canalización. Las especificaciones reutilizables de component.yaml se pueden compartir en AI Hub para obtener capacidad de integración en diferentes proyectos de Kubeflow Pipelines.

  • Usa componentes predefinidos de Google Cloud: Kubeflow Pipelines proporciona componentes predefinidos que ejecutan varios servicios administrados en Google Cloud mediante el suministro de los parámetros necesarios. Estos componentes te ayudan a ejecutar tareas mediante servicios como BigQuery, Dataflow, Dataproc y AI Platform. Estos componentes predefinidos de Google Cloud también están disponibles en AI Hub. Como ocurre con los componentes reutilizables, estas operaciones de componentes se crean de forma automática a partir de las especificaciones predefinidas de los componentes a través de ComponentStore.load_components. Hay más componentes predefinidos disponibles para ejecutar trabajos en Kubeflow y otras plataformas.

También puedes usar la DSL de canalización de TFX y los componentes de TFX. Un componente de TFX encapsula las funciones de los metadatos. El controlador proporciona metadatos al ejecutor mediante consultas al almacén de metadatos. El publicador acepta los resultados del ejecutor y los almacena en metadatos. También puedes implementar un componente personalizado, que tiene la misma integración en los metadatos. TFX proporciona una interfaz de línea de comandos (CLI) que compila el código de Python de la canalización en un archivo YAML y describe el flujo de trabajo de Argo. Luego, puedes enviar el archivo a Kubeflow Pipelines.

En el siguiente diagrama, se muestra cómo en Kubeflow Pipelines, una tarea en contenedores puede invocar otros servicios, como trabajos de BigQuery, trabajos de entrenamiento de AI Platform (distribuido) y trabajos de Dataflow.

Arquitectura de Kubeflow Pipelines en Google Cloud

Figura 5. Canalización de AA con Kubeflow Pipelines y servicios administrados de Google Cloud.

Kubeflow Pipelines te permite organizar y automatizar una canalización de AA de producción mediante la ejecución de los servicios necesarios de Google Cloud. En la figura 5, Cloud SQL actúa como el almacén de metadatos de AA para Kubeflow Pipelines.

Los componentes de Kubeflow Pipelines no están limitados a ejecutar servicios relacionados con TFX en Google Cloud. Estos componentes pueden ejecutar cualquier servicio relacionado con datos y procesamiento, incluido Dataproc para trabajos de SparkML, AutoML y otras cargas de trabajo de procesamiento.

Las tareas de creación de contenedores en Kubeflow Pipelines presentan las siguientes ventajas:

  • Separan el entorno de ejecución del entorno de ejecución de código.
  • Proporcionan reproducibilidad del código entre el entorno de desarrollo y el de producción, ya que lo que se prueba es lo mismo en producción.
  • Aíslan todos los componentes de la canalización; cada uno puede tener su propia versión del entorno de ejecución, diferentes lenguajes y distintas bibliotecas.
  • Ayudan en la composición de canalizaciones complejas.
  • Se integran en el almacén de metadatos de AA para obtener rastreabilidad y reproducibilidad.

Para obtener una introducción completa a Kubeflow Pipelines y un ejemplo con bibliotecas de TFX, consulta la entrada de blog Comienza a usar Kubeflow Pipelines.

Activa y programa Kubeflow Pipelines

Cuando implementas una canalización de Kubeflow en producción, debes automatizar sus ejecuciones, según las situaciones que se analizan en la sección Automatización de canalizaciones de AA.

Kubeflow Pipelines proporciona un SDK de Python para usar la canalización de manera programática. La clase kfp.Client incluye API para crear experimentos e implementar y ejecutar canalizaciones. Con el SDK de Kubeflow Pipelines, puedes invocar Kubeflow Pipelines mediante los siguientes servicios:

Kubeflow Pipelines también proporciona un programador integrado para las canalizaciones recurrentes en la plataforma.

Configura la CI/CD para el AA en Google Cloud

Kubeflow Pipelines te permite organizar sistemas de AA que implican varios pasos, incluido el procesamiento previo de datos y el entrenamiento, la evaluación y la implementación de modelos. En la fase de exploración de ciencia de datos, Kubeflow Pipelines ayuda con la experimentación rápida de todo el sistema. En la fase de producción, Kubeflow Pipelines te permite automatizar la ejecución de canalizaciones en función de datos nuevos para entrenar o volver a entrenar el modelo de AA.

Arquitectura de CI/CD

En el siguiente diagrama, se muestra una descripción general de alto nivel de CI/CD para el AA con Kubeflow Pipelines.

Arquitectura de CI/CD para canalizaciones de AA mediante Kubeflow Pipelines.

Figura 6: Descripción general de alto nivel de IC/EC para canalizaciones de Kubeflow.

En el centro de esta arquitectura, se encuentra la infraestructura Cloud Build. Cloud Build puede importar código fuente de Cloud Source Repositories, GitHub o Bitbucket y, luego, ejecutar una compilación según tus especificaciones y producir artefactos, como contenedores de Docker o archivos tar de Python.

Cloud Build ejecuta la compilación como una serie de pasos de compilación, que se definen en un archivo de configuración de compilación (cloudbuild.yaml). Cada paso de compilación se ejecuta en un contenedor de Docker. Puedes usar los pasos de compilación admitidos que proporciona Cloud Build o escribir tus propios pasos de compilación.

El proceso de Cloud Build, que ejecuta las CI/CD necesarias para el sistema de AA, se puede ejecutar de forma manual o mediante activadores de compilación automatizados. Los activadores ejecutan los pasos de compilación configurados cada vez que se envían cambios a la fuente de compilación. Puedes configurar un activador de compilación para ejecutar la rutina de compilación ante cambios en el repositorio de código fuente o solo cuando los cambios coincidan con criterios específicos.

Además, puedes tener rutinas de compilación (archivos de configuración de Cloud Build) que se ejecuten en respuesta a activadores diferentes. Por ejemplo, puedes tener la siguiente configuración:

  • Una rutina de compilación comienza cuando se realizan confirmaciones en una rama de desarrollo.
  • Una rutina de compilación comienza cuando se realizan confirmaciones en la rama principal.

Puedes usar sustituciones de variables de configuración para definir las variables de entorno en el momento de la compilación. Estas sustituciones se capturan a partir de compilaciones activadas. Estas variables incluyen $COMMIT_SHA, $REPO_NAME, $BRANCE_NAME, $TAG_NAME y $REVISION_ID. Otras variables no basadas en activadores son $PROJECT_ID y $BUILD_ID. Las sustituciones son útiles para las variables cuyo valor no se conoce hasta el momento de la compilación o si deseas reutilizar una solicitud de compilación existente con diferentes valores de variables.

Caso práctico de flujo de trabajo de CI/CD

Por lo general, un repositorio de código fuente incluye los siguientes elementos:

  • El código fuente de Python para implementar los componentes de Kubeflow Pipelines, incluida la validación y la transformación de datos, y el entrenamiento, la evaluación y la deriva de modelos
  • Pruebas de unidades de Python para probar los métodos implementados en el componente
  • Los Dockerfiles necesarios a fin de crear imágenes de contenedor de Docker, una para cada componente de Kubeflow Pipelines
  • El archivo component.yaml que define las especificaciones de componentes de la canalización. Estas especificaciones se usan para generar las operaciones de componentes en la definición de la canalización
  • Un módulo de Python (por ejemplo, el módulo pipeline.py) en el que se define el flujo de trabajo de Kubeflow Pipelines
  • Otras secuencias de comandos y archivos de configuración, incluidos los archivos cloudbuild.yaml
  • Notebooks usados para el análisis exploratorio de datos, el análisis de modelos y la experimentación interactiva en modelos
  • Un archivo de configuración (por ejemplo, el archivo settings.yaml), incluidas las opciones de configuración de los parámetros de entrada de la canalización

En el siguiente ejemplo, se activa una rutina de compilación cuando un desarrollador envía código fuente a la rama de desarrollo desde el entorno de ciencia de datos.

Ejemplo de pasos de compilación.

Figura 7. Ejemplo de pasos de compilación realizados por Cloud Build.

Como se muestra en la figura 7, Cloud Build realiza los siguientes pasos de compilación:

  1. El repositorio de código fuente se copia en el entorno de ejecución de Cloud Build, en el directorio /workspace.
  2. Se ejecutan pruebas de unidades.
  3. Se ejecuta un análisis de código estático, como Pylint (opcional).
  4. Si las pruebas se realizan de forma correcta, se compilan las imágenes de contenedor de Docker, una para cada componente de Kubeflow Pipelines. Las imágenes se etiquetan con el parámetro $COMMIT_SHA.
  5. Las imágenes de contenedor de Docker se suben a Container Registry.
  6. La URL de las imágenes se actualiza en cada uno de los archivos component.yaml con las imágenes de contenedor de Docker creadas y etiquetadas.
  7. El flujo de trabajo de Kubeflow Pipelines se compila para producir el archivo workflow.tar.gz.
  8. El archivo workflow.tar.gz se sube a Cloud Storage.
  9. La canalización compilada se implementa en Kubeflow Pipelines, lo que implica los siguientes pasos:
    1. Lee los parámetros de canalización del archivo settings.yaml.
    2. Crea un experimento (o usa uno existente).
    3. Implementa la canalización en Kubeflow Pipelines (y etiqueta su nombre con una versión).
  10. Ejecuta la canalización con los valores del parámetro como parte de una prueba de integración o ejecución de producción (opcional). La canalización ejecutada implementa un modelo como una API en AI Platform.

Para ver un ejemplo completo de Cloud Build en el que se explique la mayoría de estos pasos, consulta A Simple CI/CD Example with Kubeflow Pipelines and Cloud Build (Un ejemplo simple de CI/CD con Kubeflow Pipelines y Cloud Build).

Consideraciones adicionales

Cuando configures la arquitectura de CI/CD de AA en Google Cloud, ten en cuenta la siguiente información:

  • Para el entorno de ciencia de datos, puedes usar una máquina local o una instancia de Notebooks que se base en una VM de aprendizaje profundo (DLVM).
  • Puedes configurar la canalización automatizada de Cloud Build para omitir activadores, por ejemplo, si solo se editan los archivos de documentación o si se modifican los notebooks de experimentación.
  • Puedes ejecutar la canalización para las pruebas de integración y regresión como una prueba de compilación. Antes de implementar la canalización en el entorno de destino, puedes usar el método wait_for_pipeline_completion para ejecutar la canalización en un conjunto de datos de muestra a fin de probarla.
  • Como alternativa a Cloud Build, puedes usar otros sistemas de compilación, como Jenkins. En Google Cloud Marketplace, puedes encontrar una implementación de Jenkins lista para usar.
  • Puedes configurar la canalización para que se implemente de forma automática en diferentes entornos, incluido el entorno de desarrollo, el de prueba y el de etapa de pruebas, en función de distintos activadores. Además, puedes implementar de forma manual en entornos específicos, como el de preproducción o de producción, por lo general, después de que la versión se aprueba. Puedes tener varias rutinas de compilación para diferentes activadores o entornos de destino.
  • Puedes usar Apache Airflow, un framework popular de organización y programación, para los flujos de trabajo de uso general, que puedes ejecutar mediante el servicio completamente administrado de Cloud Composer. Para obtener más información sobre cómo organizar canalizaciones de datos con Cloud Composer y Cloud Build, consulta Configura una canalización de CI/CD para el flujo de trabajo de procesamiento de datos.
  • Cuando implementes una versión nueva del modelo en producción, impleméntala como un lanzamiento Canary para tener una idea de su rendimiento (CPU, memoria y uso del disco). Antes de configurar el modelo nuevo para entregar todo el tráfico en vivo, también puedes realizar pruebas A/B. Configura el modelo nuevo para que entregue del 10% al 20% del tráfico en vivo. Si el modelo nuevo tiene un mejor rendimiento que el actual, puedes configurarlo para que entregue todo el tráfico. De lo contrario, el sistema de entrega revierte al modelo actual.

¿Qué sigue?