Roadmap para una base empresarial de MLOps con Amazon SageMaker

Por Dr. Sokratis Kartakis is a Senior Machine Learning Specialist Solutions Architect,
Georgios Schinas is a Specialist Solutions Architect for AI/ML ,
Giuseppe Angelo Porcelli is a Principal Machine Learning Specialist Solutions Architect e
Shelbee Eigenbrode is a Principal AI and Machine Learning Specialist Solutions Architect

A medida que las empresas adoptan el aprendizaje automático (machine learning, o ML) en sus organizaciones, los flujos de trabajo manuales para crear, entrenar y desplegar modelos de ML tienden a convertirse en cuellos de botella para la innovación. Para superar esto, las empresas necesitan dar forma a un modelo operativo claro que defina cómo deben colaborar e interactuar múltiples roles, como científicos de datos, ingenieros de datos, ingenieros de ML, TI y representantes del negocio; cómo separar intereses, responsabilidades y habilidades; y cómo aprovechar los servicios de AWS de manera óptima. Esta combinación de ML y Operaciones, llamada MLOps, está ayudando a las empresas a optimizar su ciclo de vida de ML de extremo a extremo e impulsando la productividad de los científicos de datos, manteniendo al mismo tiempo una alta precisión de modelos y mejorando la seguridad y el cumplimiento de regulaciones.

En este artículo, aprenderá sobre las fases clave de la construcción de una base de MLOps, cómo los múltiples roles trabajan juntos sobre esta base; y cómo las herramientas de Amazon SageMaker y sus integraciones con otros servicios de AWS pueden acelerar la adopción de ML en una empresa.

Modelo de madurez de MLOps

Construir una base de MLOps que pueda cubrir las necesidades de operaciones, personas y tecnología de los clientes empresariales es un desafío. Por lo tanto, definimos el siguiente modelo de madurez que define las capacidades necesarias de MLOps en cuatro fases clave.

1. Fase inicial: Durante esta fase, los científicos de datos son capaces de experimentar y construir, entrenar y desplegar modelos en AWS utilizando los servicios de Amazon SageMaker. El entorno de desarrollo sugerido es Amazon SageMaker Studio, en el que los científicos de datos son capaces de experimentar y colaborar en base a notebooks de Studio.

2. Fase repetible: Al tener la capacidad de experimentar en AWS, el siguiente paso es crear flujos de trabajo automáticos para preprocesar datos, construir y entrenar modelos, es decir, pipelines de ML. Los científicos de datos colaboran con los ingenieros de ML en un entorno separado para crear código fuente y algoritmos robustos y listos para producción, orquestados con Amazon SageMaker Pipelines. Los modelos generados se almacenan y comparan en el registro de modelos de SageMaker.

3. Fase confiable: Incluso si los modelos se han generado a través de pipelines de ML, deben probarse antes de pasar a producción. Por lo tanto, en esta fase se introduce la metodología de pruebas automáticas, tanto para el modelo como para la infraestructura de activación, en un ambiente de prueba aislado (pre-producción) que simula producción. Tras la ejecución exitosa de las pruebas, los modelos se despliegan en el ambiente aislado de producción. Para promover los modelos entre los múltiples ambientes, se requieren evaluaciones y aprobaciones manuales.

4. Fase escalable: Después de la promoción a producción de la primera solución de ML, es necesario escalar la base de MLOps para dar soporte a múltiples equipos de ciencia de datos para colaborar y producir decenas o cientos de casos de uso de ML. En esta fase, introducimos la construcción de plantillas de soluciones, que aportan velocidad a la generación de valor al reducir el tiempo de desarrollo de nuevas soluciones en producción de semanas a días. Además, automatizamos la instanciación de ambientes seguros de MLOps para permitir que múltiples equipos operen con sus datos, reduciendo la dependencia y sobrecarga de TI.

En las siguientes secciones, mostramos cómo construir una base de MLOps basada en el modelo de madurez anterior y en los siguientes principios:

• Flexibilidad: los científicos de datos pueden adaptarse a cualquier framework (por ejemplo, TensorFlow o PyTorch)
• Reproducibilidad: Los científicos de datos son capaces de recrear u observar experimentos anteriores (por ejemplo, código, datos y resultados).
• Reusabilidad: Los científicos de datos y los ingenieros de ML pueden reutilizar el código fuente y los pipelines de ML, evitando inconsistencias y costos.
• Escalabilidad: Los científicos de datos y los ingenieros de ML pueden escalar recursos y servicios bajo demanda.
• Auditabilidad: Los científicos de datos, TI y departamento legal son capaces de auditar registros, versiones y dependencias de artefactos y datos.
• Consistencia: Debido a que MLOps se compone de múltiples ambientes, la base debe eliminar la variación entre ambientes.

Fase inicial

En la fase inicial, el objetivo es crear un ambiente de experimentación seguro, donde el científico de datos reciba snapshots de los datos y experimente usando notebooks de SageMaker para demostrar que se puede resolver un problema de negocio específico con ML. Para lograr esto, se recomienda un entorno Sagemaker Studio con acceso personalizado a los servicios a través de endpoints de VPC. El código fuente de la arquitectura de referencia está disponible en los ejemplos proporcionados por el equipo de SageMaker en Secure Data Science With Amazon SageMaker Studio Reference Architecture (en inglés).

Además de los servicios de SageMaker, los científicos de datos pueden utilizar otros servicios para procesar los datos, como Amazon Athena y AWS Glue, mientras que los notebooks se almacenan y versionan en repositorios de AWS CodeCommit (ver la siguiente figura).

Fase repetible

Una vez que los científicos de datos hayan demostrado que ML puede resolver el problema de negocio y se hayan familiarizado con la experimentación, entrenamiento y despliegue de modelos de SageMaker, el siguiente paso es comenzar a productivizar la solución de ML. La siguiente figura ilustra esta arquitectura.

En esta etapa, es necesaria la separación de intereses. Dividimos el ambiente en varias cuentas de AWS:

1. Data lake: Almacena todos los datos ingestados desde on-premises (u otros sistemas) a la nube. Los ingenieros de datos pueden crear pipelines de extracción, transformación y carga (ETL) que combinan múltiples fuentes de datos y preparan los conjuntos de datos necesarios para los casos de uso de ML. Los datos se catalogan a través del catálogo de AWS Glue y se comparten con otros usuarios y cuentas a través de AWS Lake Formation (la capa de gobierno de datos). En la misma cuenta, se puede desplegar Amazon SageMaker Feature Store, pero no lo cubrimos en este artículo. Para más información, puede consultar Enable feature reuse across accounts and teams using Amazon SageMaker Feature Store (en inglés).

2. Experimentación: Permite a los científicos de datos realizar sus investigaciones. La única diferencia es que el origen de los snapshots de datos es el data lake. Los científicos de datos tienen acceso solo a conjuntos de datos específicos que pueden ser anonimizados, en caso de GDPR u otras restricciones de privacidad de datos. Además, la cuenta de experimentación puede tener acceso a Internet para permitir a los científicos de datos utilizar nuevos frameworks de ciencia de datos o bibliotecas de código abierto de terceros. Por lo tanto, la cuenta de experimentación es considerada como parte del ambiente no productivo.

3. Desarrollo (dev): La primera etapa del ambiente de producción. Los científicos de datos pasan de los notebooks al mundo de los flujos de trabajo automáticos y SageMaker Pipelines. Deben colaborar con ingenieros de ML para abstraer su código y garantizar la cobertura de las pruebas, manejo de errores y calidad del código. El objetivo es desarrollar pipelines de ML, que son flujos de trabajo automáticos que preprocesan, entrenan, evalúan y registran modelos en el registro de modelos de SageMaker. El despliegue de los pipelines de ML se maneja solo a través de pipelines de CI/CD, y el acceso a la consola de AWS está restringido. No se permite la conexión a Internet ya que el pipeline de ML tiene acceso a los datos de producción en el data lake (solo lectura).

4. Herramientas (o automatización): Contiene los repositorios de AWS CodeCommit, los pipelines de CI/CD AWS CodePipeline, el registro de modelos de SageMaker y Amazon ECR para alojar contenedores personalizados. Como el data lake es la única fuente de la verdad para los datos, la cuenta de herramientas es para el código, los contenedores y los artefactos producidos.

Tenga en cuenta que esta convención de nomenclatura de cuentas y la estrategia de varias cuentas pueden variar dependiendo de las necesidades del negocio, pero esta estructura está destinada a mostrar los niveles de aislamiento recomendados. Por ejemplo, el nombre de la cuenta de desarrollo puede cambiarse a cuenta de entrenamiento de modelos o cuenta de construcción.

Para lograr el despliegue automático, es importante comprender cómo pasar de los notebooks a los pipelines de ML y estandarizar los repositorios de código y la estructura de datos, que lo analizamos en las siguientes secciones.

De notebooks a pipelines de ML

El objetivo del ambiente de desarrollo es reestructurar, aumentar, mejorar y escalar el código en los notebooks y trasladarlo a los pipelines de ML. Un pipeline de ML es un conjunto de pasos que son responsables de preprocesar los datos, entrenar o usar modelos, y postprocesar los resultados. Cada paso debe realizar exactamente una tarea (una transformación específica) y ser lo suficientemente abstracto (por ejemplo, pasar nombres de columna como parámetros de entrada) para permitir la reutilización. El siguiente diagrama ilustra un pipeline de ejemplo.

Para implementar pipelines de ML, los científicos de datos (o ingenieros de ML) usan SageMaker Pipelines. Un pipeline de Amazon SageMaker es una serie de pasos interconectados (SageMaker processing jobs, training, HPO) que se especifican mediante una definición de pipeline JSON, utilizando un SDK de Python. Esta definición codifica un pipeline usando un gráfico acíclico dirigido (DAG). Este DAG entrega información sobre los requisitos y las relaciones entre cada paso de su pipeline de ML.

Dependiendo del caso de uso, el pipeline de ML se puede separar en dos tipos principales: entrenamiento e inferencia batch.

La siguiente figura ilustra el flujo para un pipeline de ML de entrenamiento.

La fase de preprocesamiento (“Pre-Processing”, en la figura) puede consistir en múltiples pasos. Algunas transformaciones comunes de ciencia de datos son la división y muestreo de datos (conjuntos de entrenamiento, validación, prueba), one-hot encoding o vectorización, agrupación, y escalado. El paso de entrenamiento del modelo (“Model Training”) podría ser un único trabajo de entrenamiento, si el científico de datos conoce la mejor configuración del modelo, o un trabajo de optimización de hiperparámetros (HPO), en el que AWS define los mejores hiperparámetros para el modelo (método bayesiano) y produce el correspondiente artefacto del modelo. En el paso de evaluación (“Model Evaluation”), el artefacto del modelo producido se utiliza para realizar inferencias al conjunto de datos de validación. Luego, el pipeline de ML verifica si las métricas de precisión producidas (como F1, precisión, deciles de ganancia) superan los umbrales necesarios. Si este paso es exitoso, entonces los artefactos y metadatos del modelo se mueven al registro de modelos para ser usados en producción. Tenga en cuenta que el paso “Export baseline” aprovecha la funcionalidad de Amazon SageMaker Model Monitor produciendo objetos JSON con las estadísticas que se utilizarán más adelante para la detección de desviación del modelo (model drift) y que se pueden almacenar en el registro de modelos de SageMaker como metadatos del modelo.

En caso de la inferencia batch, los científicos de datos son capaces de crear pipelines similares, como se ilustra en la siguiente figura.

El paso de preprocesamiento de la inferencia batch es a menudo el mismo que el de entrenamiento, excluyendo el muestreo de datos y la columna de datos reales (ground truth). La inferencia batch es el paso que envía datos en lotes para su inferencia al endpoint correspondiente, y se puede implementar aprovechando la transformación batch. El paso de postprocesamiento produce estadísticas adicionales, por ejemplo, la distribución de resultados, o une los resultados con identificadores externos. Luego, un paso de monitoreo del modelo es capaz de comparar las estadísticas de referencia (baseline) de los datos utilizados para el entrenamiento (metadatos JSON del modelo en el registro de modelos) contra los nuevos datos entrantes para inferencia.

Los pasos de preprocesamiento podrían omitirse si los científicos de datos crean modelos de pipelines que se pueden almacenar en el registro de modelos de SageMaker. Para más detalles, consulte Host models along with pre-processing logic as serial inference pipeline behind one endpoint (en inglés).

Estandarización de repositorios

Para permitir la colaboración entre científicos de datos e ingenieros de ML, es necesaria la estandarización de la estructura del repositorio de código. Además, la estandarización es beneficiosa para la estructura de pipelines de CI/CD, permitiendo la incorporación de pasos de validación automática, construcción (por ejemplo, construcción de contenedores personalizados) y pasos de prueba.

El siguiente ejemplo ilustra la separación de las soluciones de ML en dos repositorios: un repositorio de construcción y entrenamiento para entrenamiento (y opcionalmente modelo de pipeline) y despliegue para promover los modelos de pipelines de inferencia batch o instanciar endpoints en tiempo real:

Repositorio de construcción y entrenamiento

# Repositorio de entrenamiento/construcción
algorithms/
    shared_libraries/
        test/
            input/ # (opcional)
            output/ # (opcional)
            test_<step>.py
        <help_functions1>.py
        <help_functions2>.py
        README.md
    preprocessing/ # 1 carpeta por trabajo de preprocessing job, el orden se define en la lógica del pipeline de ML
        <preprocessing_job_name1> # p.ej. classic ml: one-hot encoding
            test/
                input/ # (opcional)
                output/ # (opcional)
                test_<step>.py
            __main__.py
            dockerfile # (opcional) define el dockerfile en el caso de contenedores custom
            README.md
       <preprocessing_job_name2> # p.ej. classic ml: one-hot encoding
        ...
    training/ # (opcional) cada carpeta es un trabajo de entrenamiento en SageMaker
        <training_job_name>/
            test/
                input/ # (optional)
                output/ # (optional)
                test_<step>.py
            __main__.py
            README.md
    inference/ # (opcional) para inferencia batch
        <batch_inference_job_name>/ # un trabajo por cada nombre de trabajo de entrenamiento si estamos construyendo múltiples modelos
            __main__.py
            README.md
    postprocessing/ # cada uno es un trabajo de postprocesamiento en SageMaker
        <postprocessing_job_name1>/
            test/
                input/ # (opcional)
                output/ # (opcional)
                test_<step>.py
           __main__.py
            README.md
        <postprocessing_job_name2>/
        ...
ml_pipelines/
    training/ # (nota) Se pueden definir múltiples pipelines de ML de entrenamiento
        ml-pipeline-training.py # Define pipelines de ML de entrenamiento usando SageMaker Pipeline SDK
        input.json # (opcional - json o yaml) Configuración del pipeline de ML para permitir reusabilidad
    README.md
notebooks/
    *.ipynb # Los notebooks originales tal como los crearon los científicos de datos
    README.md
build_spec.yml
README.md

Repositorio de despliegue

# Repositorio de despliegue
inference_config/
    staging/
        inference_config.json # Pipeline de ML de inferencia batch o configuración de endpoint en tiempo real para permitir la reusabilidad
    prod/
        inference_config.json # Pipeline de ML de inferencia batch o configuración de endpoint en tiempo real para permitir la reusabilidad
    README.md
app_infra/
    api_gateway/...
    lambda/...
    event_bridge/...
    batch_inference/ml-pipeline-inference.py # Define el pipeline de ML de inferencia batch
tests/
    integration_test/
        test_<description>.py
        test_<description>.py
        # …
    stress_test/
        test_<description>.py
    other_test/
        test_<description>.py
    README.md
README.md

El repositorio de construcción y entrenamiento se divide en tres carpetas principales:

1. Algoritmos: Los científicos de datos desarrollan el código para cada paso de los pipelines de ML en la carpeta raíz de algoritmos. Los pasos se pueden agrupar en preprocesamiento, entrenamiento, inferencia batch, postprocesamiento (evaluación). En cada grupo, se pueden definir múltiples pasos en las subcarpetas correspondientes, las cuales contienen una carpeta para las pruebas unitarias (incluyendo entradas y salidas opcionales), las funciones principales, el archivo README y un dockerfile en caso de necesitar un contenedor personalizado. Además de main, se pueden almacenar múltiples archivos de código en la misma carpeta. Las bibliotecas helper comunes a todos los pasos se pueden almacenar en una carpeta de shared library. Los científicos de datos son responsables del desarrollo de las pruebas unitarias, ya que son dueños de la lógica de los pasos, mientras que los ingenieros de ML son responsables de la mejora del manejo de errores y la recomendación de la cobertura de pruebas. El pipeline de CI/CD es responsable de ejecutar las pruebas, construir los contenedores automáticamente (de ser necesario) y empaquetar los múltiples archivos de código fuente.

2. Pipelines de ML: Habiendo desarrollado el código fuente y las pruebas de cada paso, el siguiente paso es definir los pasos de SageMaker Pipelines en otra carpeta raíz. Cada definición de pipeline de ML se coloca en una subcarpeta que contiene el archivo .py y un archivo JSON o YAML para parámetros de entrada, tales como rangos de hiperparámetros. Es necesario un archivo README para describir los pipelines de ML.

3. Notebooks: Esta carpeta contiene los notebooks de origen que el científico de datos utilizó durante la experimentación.

El repositorio de despliegue consta de tres partes principales:

1. Configuración de inferencia: Contiene la configuración de endpoints en tiempo real o inferencia batch por cada entorno de desarrollo, por ejemplo, los tipos de instancia.

2. Infraestructura de aplicaciones: Contiene el código fuente de la infraestructura necesaria para ejecutar la inferencia, de ser necesario. Esto podría ser un mecanismo de activación a través de Amazon EventBridge, Amazon API Gateway, funciones de AWS Lambda o SageMaker Pipelines.

3. Pruebas: Consta de múltiples subcarpetas dependiendo de la metodología de pruebas del cliente. Se sugiere como conjunto mínimo de pruebas, una prueba de integración (ejecución end-to-end de la inferencia, incluyendo la infraestructura de aplicaciones), pruebas de stress (examinar casos de borde) y pruebas de ML (por ejemplo, la distribución de puntuaciones “scores” de confianza o probabilidades).

Al realizar commit de los cambios en el repositorio de construcción y entrenamiento, un pipeline de CI/CD es responsable de validar la estructura del repositorio, realizar las pruebas, desplegar y ejecutar los pipelines de ML. Un pipeline de CI/CD diferente se encargará de la promoción de los modelos que examinaremos en la siguiente sección.

Estandarizando las ramas de repositorios y CI/CD

Para asegurar la robustez de los pipelines de ML en la cuenta de desarrollo, se sugiere una estrategia de repositorio de múltiples ramas (multi-branch), mientras que el despliegue se realiza solo a través de pipelines de CI/CD. Los científicos de datos deben utilizar una rama llamada “feature branch” para desarrollar su nueva funcionalidad (código fuente) y una vez que estén listos para desplegar los correspondientes pipelines de ML, pueden entonces enviarla a la rama de desarrollo. Una alternativa a este enfoque es permitir el despliegue de pipelines de ML por feature branch. El artículo Improve your data science workflow with a multi-branch training MLOps pipeline using AWS (en inglés) describe esta alternativa.

La siguiente figura ilustra la estrategia de ramas y los pasos necesarios del pipeline de CI/CD que ejecutamos en el entorno de desarrollo para el pipeline de ML y para la construcción de modelos.

Un ejemplo de código del enfoque de múltiples ramas se puede encontrar en Multi-Branch MLOps training pipeline (en inglés). Se puede almacenar los modelos producidos por un pipeline de ML basado en feature branches en un grupo de modelos (model group) separados por feature, y luego decomisionarlos durante un merge request con la rama principal. Los modelos del grupo de modelos principal serán los que se promoverán a producción.

Estandarizando la estructura de datos

Igualmente importante a la estandarización del código fuente es la estandarzación de la estructura de los datos, lo que permite a los científicos de datos y a los ingenieros de ML depurar, auditar y monitorear el origen y la historia de los modelos y los pipelines de ML. El siguiente diagrama ilustra tal ejemplo.

Para simplificar, supongamos que los datos históricos de entrada aterrizan en un bucket de la cuenta de desarrollo bajo la sub-key input (normalmente esto se encuentra en el data lake). Para cada caso de uso de ML, se necesita crear una sub-key separada. Para gatillar una nueva ejecución de un Pipeline de ML, el científico de datos debe realizar un git commit y push, lo que desencadena el pipeline de CI/CD. Luego, el pipeline de CI/CD crea una sub-key copiando los artefactos de código (la sub-key code) y los datos de entrada (sub-key input) bajo una subpartición del id de build. Por ejemplo, el id de build puede ser una combinación de fecha y hora y hash de git, o un id de ejecución de pipeline de SageMaker. Esta estructura permite a los científicos de datos auditar y consultar implementaciones y ejecuciones pasadas. Después de esto, el pipeline de CI/CD despliega y gatilla el pipeline de ML. Durante la ejecución del pipeline de ML, cada paso exporta los resultados intermedios a ml-pipeline-outputs. Es importante recordar que las diferentes feature branches despliegan y ejecutan una nueva instancia de pipeline de ML y cada una necesita exportar los resultados intermedios a una subcarpeta diferente con una nueva sub-key y/o que incorpore como prefijo o sufijo estandarizado el id de la feature branch.

Este enfoque apoya la auditabilidad completa para cada experimentación. Sin embargo, el enfoque multi-branch de la estrategia de desarrollo genera una gran cantidad de datos. Por lo tanto, es necesaria una estrategia de ciclo de vida de datos. Se sugiere eliminar al menos los datos de cada pipeline de ML por feature branch en cada pull/merge request que sea exitoso. Pero esto depende del modelo operacional y de la granularidad de auditoría que el negocio necesite soportar. Un enfoque similar se puede utilizar en los pipelines de ML de inferencia batch.

Fase confiable

Después de la separación inicial de intereses entre científicos de datos, ingenieros de ML e ingenieros de datos mediante el uso de múltiples cuentas, el siguiente paso es promover los modelos producidos desde el registro de modelos a un entorno aislado para realizar inferencias. Sin embargo, necesitamos asegurar la robustez de los modelos desplegados. Por lo tanto, la simulación del modelo desplegado en un entorno espejo al de producción, a saber pre-producción (o staging).

La siguiente figura ilustra esta arquitectura.

La promoción de un despliegue de modelo y endpoint en un ambiente de pre-producción se realiza aprovechando los eventos de actualización de estado del registro de modelos (o git push en el repositorio de despliegue) que gatillan un pipeline de CI/CD separado usando eventos de Amazon EventBridge. El primer paso del pipeline de CI/CD solicita una aprobación manual por parte del científico de datos líder (y opcionalmente el/la Product Owner, Analista de Negocios u otros científicos de datos líderes). Quienes aprueben necesitan validar los KPI de desempeño del modelo y QA del código en el repositorio de despliegue. Después de la aprobación, el pipeline de CI/CD ejecuta el código de prueba en el repositorio de despliegue (pruebas de integración, pruebas de estrés, pruebas de ML). Además del endpoint del modelo, el CI/CD prueba también la infraestructura de activación, como EventBridge, funciones Lambda o API Gateway. El siguiente diagrama muestra esta arquitectura actualizada.

Tras la ejecución exitosa de las pruebas, el pipeline de CI/CD notifica a nuevos (o los mismos) aprobadores que un modelo está listo para promoverse a producción. En esta etapa, el analista de negocios podría querer realizar algunas pruebas estadísticas de hipótesis adicionales sobre los resultados del modelo. Después de la aprobación, los modelos y la infraestructura de activación se despliegan en producción. Amazon SageMaker admite varios métodos de despliegue, tales como blue/green, Canary y A/B testing (vea más en Deployment Guardrails). Si el pipeline de CI/CD falla, entonces un mecanismo de rollback devuelve el sistema al último estado robusto.

El siguiente diagrama ilustra los pasos principales del pipeline de CI/CD para promover un modelo y la infraestructura para gatillar el endpoint del modelo, como API Gateway, funciones Lambda y EventBridge.

Integración de data lake y MLOps

En este punto, es importante comprender los requisitos de datos por cada etapa de desarrollo y por cada cuenta, y la forma de incorporar MLOps con un data lake centralizado. El siguiente diagrama ilustra las capas de MLOps y data lake.

En el data lake, los ingenieros de datos son responsables de unir múltiples fuentes de datos y crear los datasets correspondientes (por ejemplo, una tabla única de datos estructurados, una sola carpeta con archivos PDF o imágenes) para los casos de uso de ML, mediante la construcción de pipelines de ETL según hayan sido definidos por los científicos de datos (por ejemplo, durante el fase de análisis exploratorio de datos). Esos datasets se pueden dividir en datos históricos, datos para inferencia y pruebas. Todos los datos están catalogados (por ejemplo, en el catálogo de AWS Glue) y se pueden compartir con otras cuentas y usuarios aprovechando Lake Formation como capa de gobierno de datos (para datos estructurados). Al momento de escribir este artículo, Lake Formation es compatible solo con queries de Amazon Athena, trabajos de AWS Glue, y Amazon EMR.

Por otro lado, el entorno de MLOps necesita nutrir los pipelines de ML con datasets específicos ubicados en buckets locales en entornos de desarrollo (dev), pre-producción (pre-prod) y producción (prod). El entorno de desarrollo (dev) es responsable de construir y entrenar los modelos bajo demanda usando pipelines de SageMaker extrayendo datos del data lake. Por lo tanto, sugerimos como primer paso del pipeline tener un paso de Amazon Athena, en el caso donde solo se requiera muestreo/consulta de datos, o un paso de Amazon EMR si se requieren transformaciones más complejas. Como alternativa, puede usar un trabajo de AWS Glue a través de un paso de callback, pero no aún como un paso nativo en SageMaker Pipelines.

Pre-prod y prod son responsables, respectivamente, de realizar pruebas y realizar inferencia en tiempo real y batch. En el caso de la inferencia en tiempo real, no es necesario enviar datos a las cuentas MLOps pre-prod/prod, ya que los datos de entrada para inferencia pueden ser incluidos en el payload de la solicitud de API Gateway. En el caso de la inferencia batch (o datos de entrada de gran tamaño), los datasets necesarios, ya sea datos de prueba o datos para inferencia, necesitan moverse a los buckets locales de datos de ML respectivos (es decir, pre-prod/prod). Existen dos opciones de mover datos a pre-prod y prod: gatillando Athena o Amazon EMR para extraer los datos del data lake, o hacer un push de los datos desde el data lake a esas cuentas MLOps. La primera opción requiere el desarrollo de mecanismos adicionales en las cuentas de MLOps, por ejemplo, crear eventos EventBridge programados (sin conocimiento sobre si los datos en el data lake se han actualizado) o eventos de S3 en EventBridge tras la llegada de datos en el data lake (ver más detalles en Simplifying cross-account access with Amazon EventBridge resource policies, en inglés). Tras capturar el evento en el lado de MLOps, una query de Athena o Amazon EMR puede traer los datos localmente y activar la inferencia asincrónica o la transformación batch. Este proceso se puede integrar en un pipeline de SageMaker para mayor simplicidad. La segunda opción es agregar en el último paso del pipeline de ETL la funcionalidad de enviar datos a los buckets de MLOps. Sin embargo, este enfoque combina las responsabilidades (el data lake gatilla la inferencia) y requiere que Lake Formation proporcione acceso al data lake para escribir en los buckets de MLOps.

El último paso es trasladar los resultados de inferencia de vuelta al data lake. Para catalogar los datos y ponerlos a disposición de otros usuarios, los datos deben regresar como una nueva fuente de datos al bucket de landing.

Fase escalable

Tras el desarrollo de las bases de MLOps y la productivización extremo a extremo del primer caso de uso de ML, ya se deberían haber probado y finalizado la infraestructura de dev, pre-prod, prod, así como el repositorio, pipeline de CI/CD y estructura de datos. El siguiente paso es incorporar nuevos casos de uso de ML y equipos en la plataforma. Para acelerar el time-to-value, SageMaker permite a los usuarios crear plantillas perzonalizadas de proyectos de SageMaker (SageMaker projects) que se pueden usar para instanciar plantillas de repositorios y pipelines de CI/CD automáticamente. Al tener estas plantillas de SageMaker Project, los científicos de datos líderes son responsables de crear instancias de nuevos proyectos y asignar equipos dedicados  para cada nuevo caso de uso de ML.

El siguiente diagrama ilustra este proceso.

El problema se vuelve más complejo si diferentes equipos de científicos de datos (o múltiples unidades de negocio que necesitan productivizar ML) tienen acceso a diferentes datos confidenciales y múltiples dueños de producto son responsables de pagar facturas separadas para el entrenamiento, despliegue y ejecución de los modelos. En este contexto, es necesario contar con un grupo separado de cuentas de MLOps (experimentación, dev, pre-prod, prod) por cada equipo. Para permitir la creación sencilla de nuevas cuentas de MLOps, incorporamos otra cuenta, denominada advanced analytics governance, a la que pueden acceder los miembros de TI para permitirles catalogar, instanciar o decomisionar cuentas MLOps bajo demanda. Específicamente, esta cuenta  contiene repositorios con el código asociado a la infraestructura de las cuentas de MLOps (VPC, subredes, endpoints, buckets, roles y políticas de AWS Identitiy and Access Management (IAM), stacks de AWS CloudFormation), un producto de AWS Service Catalog para desplegar automáticamente los stacks de Cloud Formation de la infraestructura en las múltiples cuentas con un clic y una tabla de Amazon DynamoDB para catalogar metadatos, incluyendo qué equipo es responsable de cada grupo de cuentas. Al tener esta capacidad, el equipo de TI instancia cuentas de MLOps bajo demanda y asigna los usuarios, el acceso a los datos por cada cuenta y restricciones de seguridad consistentes.

Con base en este escenario, separamos las cuentas en efímeras y duraderas. Data lake y tooling son cuentas duraderas y cumplen el rol de punto único de verdad para los datos y para el código fuente, respectivamente. Las cuentas de MLOps son en su mayoría stateless y se instancian o decomisionan bajo demanda, haciéndolas efímeras. Incluso si se da de baja un grupo de cuentas de MLOps, los usuarios o auditores pueden verificar experimentos y resultados pasados, puesto que éstos se almacenan en entornos duraderos.

Si desea utilizar la interfaz de usuario de SageMaker Studio para MLOps, la cuenta de tooling es parte de la cuenta de dev, según la siguiente figura.

Si el usuario desea utilizar interfaz de usuario de SageMaker Studio para MLOps, la cuenta de tooling es parte de la cuenta de dev según la figura anterior.El código fuente de ejemplo de esta base de MLOps se puede encontrar en MLOps Multi Account Setup with AWS CDK (repositorio en inglés).

Tenga en cuenta que SageMaker provee la capacidad de reemplazar AWS CodeCommit y AWS CodePipeline por otras herramientas de desarrollo de terceros, como GitHub y Jenkins (se pueden encontrar más detalles en Create Amazon SageMaker projects using third-party source control and Jenkins y SageMaker Projects MLOps Template with GitLab and GitLab Pipelines, ambos en inglés).

Resumen de roles, operaciones y tecnología

Con el modelo de madurez de MLOps, podemos definir un diseño de arquitectura claro y una hoja de ruta de entrega. Sin embargo, cada rol necesita tener una visión clara de las cuentas y servicios clave de AWS con los que se debe interactuar, y las operaciones a realizar. El siguiente diagrama resume esas categorías:

Conclusión

Una base robusta de MLOps, que defina claramente la interacción entre múltiples roles y tecnologías, puede aumentar la velocidad de obtención de valor y reducir los costos, al tiempo que permite a los científicos de datos centrarse en la innovación.  En este artículo, hemos mostrado cómo construir dicha base en fases que conduzcan al negocio a incrementar paulatinamente su madurez en MLOps, logrando apoyar a múltiples equipos de ciencia de datos y casos de uso de ML en producción. Definimos un modelo operativo que consta de múltiples roles con múltiples habilidades y responsabilidades. Finalmente, compartimos ejemplos sobre cómo estandarizar el desarrollo de código (repositorios y pipelines de CI/CD), el almacenamiento y uso compartido de datos y el aprovisionamiento de infraestructura segura de MLOps para entornos empresariales. Múltiples clientes empresariales han adoptado este enfoque y son capaces de productivizar sus soluciones de ML en días en lugar de meses.

Si tiene algún comentario o duda, déjelos en la sección de comentarios.

Este artículo fue traducido desde el Blog de AWS en inglés.

Acerca de los autores

Dr. Sokratis Kartakis es Senior Machine Learning Specialist Solutions Architect en Amazon Web Services. Sokratis se enfoca en habilitar clients empresariales para industrializar sus soluciones de Machine Learning (ML) aprovechando los servicios de AWS y moldeando su modelo operacional, p.ej., bases de MLOps, y roadmap de transformación usando mejores prácticas de desarrollo. Ha pasado más de 15 años inventando, diseñando, liderando e implementando soluciones innovadoras de extremo a extremo de nivel productive de ML e Internet de las cosas (IoT), en los dominios de energía, retail, salud, finanza/banca, automovilismo, etc. Sokratis disfruta pasar su tiempo libre con familia y amigos, o likes to spend his spare time with family and friends, o andando en moto.

Georgios Schinas es Specialist Solutions Architect para IA/ML la region de EMEA. Está basado en Londres y trabaja de forma cercana con clientes de Reino Unido e Irlanda. Georgios ayuda a los clientes a diseñar y desplegar aplicaciones de machine learning en producción en AWS, con un interés particular en prácticas de MLOps y habilitar a los clientes para efectuar machine learning a escala. En su tiempo libre, disfruta viajar, cocinar y pasar tiempo con amigos y familia.

Giuseppe Angelo Porcelli es Principal Machine Learning Specialist Solutions Architect en Amazon Web Services. Con muchos años de background en ML e ingeniería de software, trabaja con clientes de cualquier tamaño para entender en profundidad sus necesidades técnicas y de negocio y diseñar soluciones de IA y Machine Learning que usen de la major forma la nube de AWS y el stack de Machine Learning de AWS. Ha trabajado en proyectos en diferentes dominios, incluyendo MLOps, Visión Computacional, PLN, e involucrando un amplio conjunto de servicios. En su tiempo libre, Giuseppe disfruta jugar fútbol.

Shelbee Eigenbrode es Principal AI and Machine Learning Specialist Solutions Architect en Amazon Web Services (AWS). Ha estado en el área de tecnología por 24 años abarcando múltiples industrias, tecnologías, y roles. Actualmente está enfocada en combinar su background de DevOps y ML en el dominio de MLOps, para ayudar a los clientes a entregar y administrar cargas de trabajo de ML a gran escala. Con más de 35 patentes adjudicadas sobre varios dominios de tecnología, ella tiene una pasión por la innovación continua y el uso de los datos para alcanzar objetivos de negocio. Shelbee es co-creadora e instructora de la especialización Practical Data Science en Coursera. Además, es Co-Directora del chapter de Denver de Women In Big Data (WiBD). En su tiempo libre, le gusta pasar tiempo con su familia, amigos sus hiperactivos perros.

Traductores

Rodrigo Alarcón es Senior Machine Learning Strategy Solutions Architect en Amazon Web Services, basado en Santiago, Chile.

Sayde Aguilar es ML Engineer en Amazon Web Services, basada en Cuidad de México.

Revisores

Francisco Fagas es Senior Solutions Architect en Amazon Web Services, basado en Santiago, Chile.