MLOps en el perímetro con Amazon SageMaker Edge Manager y AWS IoT Greengrass

Internet de las cosas (IoT) ha permitido a los clientes de múltiples industrias, como la fabricación, la automoción y la energía, monitorear y controlar entornos del mundo real. Al implementar una variedad de dispositivos IoT de borde, como cámaras, termostatos y sensores, puede recopilar datos, enviarlos a la nube y crear modelos de aprendizaje automático (ML) para predecir anomalías, fallas y más. Sin embargo, si el caso de uso requiere predicción en tiempo real, debe enriquecer su solución de IoT con capacidades de ML en el perímetro (ML@Edge). ML@Borde es un concepto que desvincula el ciclo de vida del modelo de ML del ciclo de vida de la aplicación y le permite ejecutar una canalización de ML de extremo a extremo que incluye preparación de datos, creación de modelos, compilación y optimización de modelos, implementación de modelos (en una flota de dispositivos perimetrales), ejecución de modelos, y supervisión y gobierno de modelos. Implementa la aplicación una vez y ejecuta la canalización de ML tantas veces como sea necesario.

Como puedes imaginar, implementar todos los pasos que propone el concepto ML@Edge no es baladí. Hay muchas preguntas que los desarrolladores deben abordar para implementar una solución ML@Edge completa, por ejemplo:

• ¿Cómo opero modelos ML en una flota (cientos, miles o millones) de dispositivos en el perímetro?
• ¿Cómo aseguro mi modelo mientras lo implemento y lo ejecuto en el perímetro?
• ¿Cómo superviso el rendimiento de mi modelo y lo vuelvo a entrenar, si es necesario?

En esta publicación, aprenderá cómo responder a todas estas preguntas y crear una solución integral para automatizar su canalización de ML@Edge. Verás cómo usar Administrador de borde de Amazon SageMaker, Estudio Amazon SageMakery AWS IoT Greengrass v2 para crear un entorno MLOps (Operaciones ML) que automatice el proceso de creación e implementación de modelos ML en grandes flotas de dispositivos perimetrales.

En las siguientes secciones, presentamos una arquitectura de referencia que detalla todos los componentes y flujos de trabajo necesarios para crear una solución completa para MLOps centrada en cargas de trabajo perimetrales. Luego profundizamos en los pasos que esta solución ejecuta automáticamente para construir y preparar un nuevo modelo. También le mostramos cómo preparar los dispositivos perimetrales para comenzar a implementar, ejecutar y monitorear modelos ML, y demostramos cómo monitorear y mantener los modelos ML implementados en su flota de dispositivos.

Resumen de la solución

La producción de modelos robustos de ML requiere la colaboración de varias personas, como científicos de datos, ingenieros de ML, ingenieros de datos y partes interesadas del negocio, bajo una infraestructura semiautomática que sigue operaciones específicas (MLOps). Además, la modularización del entorno es importante para dar a todas estas personas diferentes la flexibilidad y agilidad para desarrollar o mejorar (independientemente del flujo de trabajo) el componente del que son responsables. Un ejemplo de una infraestructura de este tipo consiste en varias cuentas de AWS que permiten esta colaboración y producción de los modelos ML tanto en la nube como en los dispositivos perimetrales. En la siguiente arquitectura de referencia, mostramos cómo organizamos las múltiples cuentas y servicios que componen esta plataforma MLOps de extremo a extremo para crear modelos de ML e implementarlos en el perímetro.

Esta solución consta de las siguientes cuentas:

• Cuenta de lago de datos – Los ingenieros de datos incorporan, almacenan y preparan datos de múltiples fuentes de datos, incluidas bases de datos locales y dispositivos IoT.
• cuenta de herramientas – Los operadores de TI administran y verifican las canalizaciones de CI/CD para la entrega e implementación continuas y automatizadas de paquetes modelo de ML en las cuentas de preproducción y producción para dispositivos periféricos remotos. Las ejecuciones de canalizaciones de CI/CD se automatizan mediante el uso de Puente de eventos de Amazon, que supervisa los eventos de cambio de estado de los modelos y objetivos de ML AWS CodePipeline.
• Cuenta de experimentación y desarrollo. – Los científicos de datos pueden realizar investigaciones y experimentar con múltiples técnicas de modelado y algoritmos para resolver problemas comerciales basados ​​en ML, creando soluciones de prueba de concepto. Los ingenieros de ML y los científicos de datos colaboran para escalar una prueba de concepto, creando flujos de trabajo automatizados usando Canalizaciones de Amazon SageMaker para preparar datos y construir, entrenar y empaquetar modelos ML. La implementación de las canalizaciones se realiza a través de canalizaciones de CI/CD, mientras que el control de versiones de los modelos se logra mediante el Registro de modelo de Amazon SageMaker. Los científicos de datos evalúan las métricas de varias versiones del modelo y solicitan la promoción del mejor modelo a producción activando la canalización de CI/CD.
• Cuenta de preproducción – Antes de la promoción del modelo al entorno de producción, el modelo debe probarse para garantizar la solidez en un entorno de simulación. Por lo tanto, el entorno de preproducción es un simulador del entorno de producción, en el que los extremos del modelo de SageMaker se implementan y prueban automáticamente. Los métodos de prueba pueden incluir una prueba de integración, una prueba de estrés o pruebas específicas de ML en los resultados de la inferencia. En este caso, el entorno de producción no es un extremo de modelo de SageMaker sino un dispositivo perimetral. Para simular un dispositivo de borde en preproducción, son posibles dos enfoques: usar un Nube informática elástica de Amazon (Amazon EC2) con las mismas características de hardware, o utilice un banco de pruebas en el laboratorio que consista en los dispositivos reales. Con esta infraestructura, la canalización de CI/CD implementa el modelo en el simulador correspondiente y realiza las múltiples pruebas automáticamente. Una vez que las pruebas se ejecutan correctamente, la canalización de CI/CD requiere aprobación manual (por ejemplo, de la parte interesada de IoT para promover el modelo a producción).
• Cuenta de producción – En el caso de alojar el modelo en la nube de AWS, la canalización de CI/CD implementa un punto de enlace del modelo de SageMaker en la cuenta de producción. En este caso, el entorno de producción consta de varias flotas de dispositivos perimetrales. Por lo tanto, la canalización de CI/CD usa Edge Manager para implementar los modelos en la flota de dispositivos correspondiente.
• Dispositivos de borde – Los dispositivos perimetrales remotos son dispositivos de hardware que pueden ejecutar modelos ML mediante Edge Manager. Permite que la aplicación en esos dispositivos administre los modelos, ejecute inferencias contra los modelos y capture datos de forma segura en Servicio de almacenamiento simple de Amazon (Amazon S3).

Proyectos de SageMaker ayudarlo a automatizar el proceso de aprovisionamiento de recursos dentro de cada una de estas cuentas. No profundizamos en esta función, pero para obtener más información sobre cómo crear una plantilla de proyecto de SageMaker que implemente modelos ML en todas las cuentas, consulte Implementación de modelos de varias cuentas con Amazon SageMaker Pipelines.

Cuenta de preproducción: gemelo digital

Después del proceso de entrenamiento, el modelo resultante necesita ser evaluado. En la cuenta de preproducción, tiene un dispositivo Edge simulado. representa el gemelo digital del dispositivo perimetral en el que se ejecuta el modelo ML en producción. Este entorno tiene el doble propósito de realizar las pruebas clásicas (como unidad, integración y humo) y ser un campo de juego para el equipo de desarrollo. Este dispositivo se simula utilizando una instancia EC2 donde se implementaron todos los componentes necesarios para administrar el modelo ML.

Los servicios involucrados son los siguientes:

• Núcleo de AWS IoT - Usamos Núcleo de AWS IoT para crear objetos de AWS IoT, crear una flota de dispositivos, registrar la flota de dispositivos para que pueda interactuar con la nube, crear certificados X.509 para autenticar dispositivos perimetrales en AWS IoT Core, asociar el alias de rol con AWS IoT Core que se generó cuando ha creado la flota, obtenga un punto de enlace específico de la cuenta de AWS para el proveedor de credenciales, obtenga un archivo oficial de Amazon Root CA y cargue el archivo de Amazon CA en Amazon S3.
• Amazon Sagemaker Neo – Sabio neo optimiza automáticamente los modelos de aprendizaje automático para que la inferencia se ejecute más rápido sin pérdida de precisión. Admite el modelo de aprendizaje automático ya creado con DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX o XGBoost y capacitado en Amazon SageMaker o en cualquier otro lugar. Luego, elige la plataforma de hardware de destino, que puede ser una instancia de alojamiento de SageMaker o un dispositivo perimetral basado en procesadores de Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments o Xilinx.
• Administrador de borde – Usamos Edge Manager para registrar y administrar el dispositivo de borde dentro de las flotas de Sagemaker. Las flotas son colecciones de dispositivos agrupados lógicamente que puede usar para recopilar y analizar datos. Además, el empaquetador Edge Manager empaqueta el modelo optimizado y crea un componente AWS IoT Greengrass V2 que se puede implementar directamente. Puede usar Edge Manager para operar modelos ML en una flota de cámaras inteligentes, parlantes inteligentes, robots y otras flotas de dispositivos SageMaker.
• AWS IOT Greengrass V2 – AWS IoT Greengrass le permite implementar componentes en los dispositivos simulados utilizando una instancia EC2. Mediante el uso del agente AWS IoT Greengrass V2 en las instancias EC2, podemos simplificar el acceso, la administración y la implementación del agente y el modelo de Edge Manager en los dispositivos. Sin AWS IoT Greengrass V2, la configuración de dispositivos y flotas para usar Edge Manager requiere que copie manualmente el agente desde un depósito de versión S3. Con la integración de AWS IoT Greengrass V2 y Edge Manager, es posible utilizar componentes de AWS IoT Greengrass V2. Los componentes son módulos de software prediseñados que pueden conectar dispositivos perimetrales a servicios de AWS o servicios de terceros a través de AWS IoT Greengrass.
• Agente de Edge Manager – El agente de Edge Manager se implementa a través de AWS IoT Greengrass V2 en la instancia EC2. El agente puede cargar varios modelos a la vez y hacer inferencias con los modelos cargados en los dispositivos perimetrales. La cantidad de modelos que puede cargar el agente está determinada por la memoria disponible en el dispositivo.
• Amazon S3 – Usamos un depósito S3 para almacenar los datos capturados de inferencia del agente Edge Manager.

Podemos definir una cuenta de preproducción como un gemelo digital para probar modelos de ML antes de moverlos a dispositivos perimetrales reales. Esto ofrece los siguientes beneficios:

• Agilidad y flexibilidad – Los científicos de datos y los ingenieros de ML deben validar rápidamente si el modelo de ML y los scripts asociados (scripts de preprocesamiento e inferencia) funcionarán en el perímetro del dispositivo. Sin embargo, los departamentos de IoT y ciencia de datos en grandes empresas pueden ser entidades diferentes. Al replicar de manera idéntica la pila de tecnología en la nube, los científicos de datos y los ingenieros de ML pueden iterar y consolidar artefactos antes de la implementación.
• Evaluación de riesgos y tiempo de producción acelerados – La implementación en el dispositivo perimetral es la etapa final del proceso. Después de validar todo en un entorno aislado y autónomo, asegúrelo para que cumpla con las especificaciones requeridas por el perímetro en términos de calidad, rendimiento e integración. Esto ayuda a evitar una mayor participación de otras personas en el departamento de IoT para corregir e iterar versiones de artefactos.
• Colaboración en equipo mejorada y calidad y rendimiento mejorados – El equipo de desarrollo puede evaluar inmediatamente el impacto del modelo ML analizando las métricas de hardware perimetral y midiendo el nivel de interacciones con herramientas de terceros (p. ej., tasa de E/S). Luego, el equipo de IoT solo es responsable de la implementación en el entorno de producción y puede estar seguro de que los artefactos son precisos para un entorno de producción.
• Zona de juegos integrada para pruebas – Dado el objetivo de los modelos ML, el entorno de preproducción en un flujo de trabajo tradicional debe estar representado por un dispositivo de borde fuera del entorno de la nube. Esto introduce otro nivel de complejidad. Se necesitan integraciones para recopilar métricas y comentarios. En cambio, mediante el uso del entorno simulado del gemelo digital, se reducen las interacciones y se acorta el tiempo de comercialización.

Cuenta de producción y entorno perimetral

Una vez que se completan las pruebas y se logra la estabilidad del artefacto, puede continuar con la implementación de producción a través de las canalizaciones. La implementación de artefactos ocurre mediante programación después de que un operador haya aprobado el artefacto. Sin embargo, el acceso a la Consola de administración de AWS se otorga a los operadores en modo de solo lectura para poder monitorear los metadatos asociados con las flotas y, por lo tanto, tener una idea de la versión del modelo ML implementado y otras métricas asociadas con el ciclo de vida.

Las flotas de dispositivos perimetrales pertenecen a la cuenta de producción de AWS. Esta cuenta tiene configuraciones de red y seguridad específicas para permitir la comunicación entre la nube y los dispositivos perimetrales. Los principales servicios de AWS implementados en la cuenta de producción son Edge Manager, que es responsable de administrar todas las flotas de dispositivos, recopilar datos y operar modelos de aprendizaje automático, y AWS IoT Core, que administra objetos de IoT, certificados, alias de roles y puntos finales.

Al mismo tiempo, necesitamos configurar un dispositivo perimetral con los servicios y componentes para administrar los modelos de ML. Los componentes principales son los siguientes:

• AWS IOT Greengrass V2
• Un agente de Edge Manager
• Certificados de AWS IoT
• Application.py, que es responsable de orquestar el proceso de inferencia (recuperar información del origen de datos perimetrales y realizar inferencias mediante el agente de Edge Manager y el modelo ML cargado)
• Una conexión a Amazon S3 o la cuenta del lago de datos para almacenar datos inferidos

Canalización de aprendizaje automático automatizado

Ahora que sabe más sobre la organización y los componentes de la arquitectura de referencia, podemos profundizar en la canalización de ML que usamos para crear, entrenar y evaluar el modelo de ML dentro de la cuenta de desarrollo.

Una tubería (construida usando Canalizaciones de creación de modelos de Amazon SageMaker) es una serie de pasos interconectados definidos por una definición de canalización JSON. Esta definición de canalización codifica una canalización mediante un gráfico acíclico dirigido (DAG). Este DAG brinda información sobre los requisitos y las relaciones entre cada paso de su canalización. La estructura del DAG de una tubería está determinada por las dependencias de datos entre los pasos. Estas dependencias de datos se crean cuando las propiedades de la salida de un paso se pasan como entrada a otro paso.

Para permitir que los equipos de ciencia de datos automaticen fácilmente la creación de nuevas versiones de modelos ML, es importante introducir pasos de validación y datos automatizados para alimentar y mejorar continuamente los modelos ML, así como estrategias de monitoreo de modelos para habilitar la activación de canalización. El siguiente diagrama muestra una canalización de ejemplo.

Para habilitar las capacidades de automatización y MLOps, es importante crear componentes modulares para crear artefactos de código reutilizables que se puedan compartir en diferentes pasos y casos de uso de ML. Esto le permite mover rápidamente la implementación de una fase de experimentación a una fase de producción mediante la automatización de la transición.

Los pasos para definir una canalización de ML para habilitar el entrenamiento continuo y el control de versiones de los modelos de ML son los siguientes:

• preprocesamiento – El proceso de limpieza de datos, ingeniería de características y creación de conjuntos de datos para entrenar el algoritmo ML
• Formación – El proceso de entrenamiento del algoritmo ML desarrollado para generar una nueva versión del artefacto del modelo ML
• Evaluación – El proceso de evaluación del modelo ML generado, para extraer métricas clave relacionadas con el comportamiento del modelo en nuevos datos no vistos durante la fase de entrenamiento
• Registro – El proceso de creación de versiones del nuevo artefacto del modelo ML entrenado mediante la vinculación de las métricas extraídas con el artefacto generado

Puede ver más detalles sobre cómo crear una canalización de SageMaker en el siguiente cuaderno.

Activar canalizaciones de CI/CD mediante EventBridge

Cuando termine de construir el modelo, puede iniciar el proceso de implementación. El último paso de la canalización de SageMaker definida en la sección anterior registra una nueva versión del modelo en el grupo de registro de modelo específico de SageMaker. La implementación de una nueva versión del modelo ML se administra mediante el estado del registro del modelo. Al aprobar o rechazar manualmente una versión del modelo de ML, este paso genera un evento que es capturado por EventBridge. Este evento puede iniciar una nueva canalización (CI/CD esta vez) para crear una nueva versión del componente AWS IoT Greengrass que luego se implementa en las cuentas de preproducción y producción. La siguiente captura de pantalla muestra nuestra regla EventBridge definida.

Esta regla supervisa el grupo de paquetes de modelos de SageMaker buscando actualizaciones de paquetes de modelos en el estado Approved or Rejected.

A continuación, la regla de EventBridge se configura para apuntar a CodePipeline, que inicia el flujo de trabajo de creación de un nuevo componente de AWS IoT Greengrass mediante el uso de Amazon SageMaker Neo y Edge Manager.

Optimice los modelos de ML para la arquitectura de destino

Neo le permite optimizar los modelos ML para realizar inferencias en dispositivos perimetrales (y en la nube). Optimiza automáticamente los modelos de ML para un mejor rendimiento en función de la arquitectura de destino y desacopla el modelo del marco original, lo que le permite ejecutarlo en un tiempo de ejecución ligero.

Consulte lo siguiente cuaderno para ver un ejemplo de cómo compilar un modelo PyTorch Resnet18 usando Neo.

Cree el paquete de implementación incluyendo el componente AWS IoT Greengrass

Edge Manager le permite administrar, asegurar, implementar y monitorear modelos en una flota de dispositivos de borde. En el siguiente cuaderno, puede ver más detalles sobre cómo crear una flota minimalista de dispositivos perimetrales y realizar algunos experimentos con esta función.

Después de configurar la flota y compilar el modelo, debe ejecutar un trabajo de empaquetado de Edge Manager, que prepara el modelo para implementarlo en la flota. Puede iniciar un trabajo de empaque utilizando el SDK de Boto3. Para nuestros parámetros, usamos el modelo optimizado y los metadatos del modelo. Al agregar los siguientes parámetros a OutputConfig, el trabajo también prepara un componente de AWS IoT Greengrass V2 con el modelo:

• PresetDeploymentType
• PresetDeploymentConfig

Ver el siguiente código:

import boto3
import time

SageMaker_client = boto3.client('SageMaker')

SageMaker_client.create_edge_packaging_job(
    EdgePackagingJobName="mlops-edge-packaging-{}".format(int(time.time()*1000)),
    CompilationJobName=compilation_job_name,
    ModelName="PytorchMLOpsEdgeModel",
    ModelVersion="1.0.0",
    RoleArn=role,
    OutputConfig={
        'S3OutputLocation': 's3://{}/model/'.format(bucket_name),
        "PresetDeploymentType": "GreengrassV2Component",
        "PresetDeploymentConfig": json.dumps(
            {"ComponentName": component_name, "ComponentVersion": component_version}
        ),
    }
)

Implemente modelos ML en el perímetro a escala

Ahora es el momento de implementar el modelo en su flota de dispositivos perimetrales. En primer lugar, tenemos que asegurarnos de que disponemos de los medios necesarios Gestión de identidades y accesos de AWS (YO SOY) permisos para aprovisionar nuestros dispositivos IoT y poder implementar componentes en ellos. Necesitamos dos elementos básicos para comenzar a incorporar dispositivos en nuestra plataforma IoT:

• política de gestión de identidades y accesos – Esta política permite el aprovisionamiento automático de dichos dispositivos, adjuntos al usuario o rol que realiza el aprovisionamiento. Debe tener permisos de escritura de IoT para crear la cosa y el grupo de IoT, así como para adjuntar las políticas necesarias al dispositivo. Para obtener más información, consulte Política de IAM mínima para que el instalador aprovisione recursos.
• Rol de IAM – este rol se adjunta a las cosas y grupos de IoT que creamos. Puede crear este rol en el momento del aprovisionamiento con permisos básicos, pero carecerá de funciones como el acceso a Amazon S3 o Servicio de administración de claves de AWS (AWS KMS) que podría necesitar más adelante. Puede crear este rol de antemano y reutilizarlo cuando aprovisionemos el dispositivo. Para obtener más información, consulte Autorizar dispositivos principales para interactuar con AWS.

Instalación y aprovisionamiento de AWS IoT Greengrass

Después de implementar la política y el rol de IAM, estamos listos para instale el software AWS IoT Greengrass Core con aprovisionamiento automático de recursos. Si bien es posible aprovisionar los recursos de IoT siguiendo pasos manuales, existe el procedimiento conveniente de aprovisionar automáticamente estos recursos durante la instalación del núcleo de AWS IoT Greengrass v2. Esta es la opción preferida para incorporar rápidamente nuevos dispositivos a la plataforma. Además default-jdk, es necesario instalar otros paquetes, como curl, unzipy python3.

Cuando aprovisionamos nuestro dispositivo, el nombre del elemento IoT debe ser exactamente el mismo que el del dispositivo perimetral definido en Edge Manager; de lo contrario, los datos no se capturarán en el depósito S3 de destino.

El instalador puede crear el rol y el alias de AWS IoT Greengrass durante la instalación si no existen. Sin embargo, se crearán con permisos mínimos y requerirán agregar manualmente más políticas para interactuar con otros servicios como Amazon S3. Recomendamos crear estos recursos de IAM de antemano como se muestra anteriormente y luego reutilizarlos a medida que incorpora nuevos dispositivos en la cuenta.

Empaquetado de componentes de modelo e inferencia

Una vez que se ha desarrollado nuestro código, podemos implementar tanto el código (para inferencia) como nuestros modelos ML como componentes en nuestros dispositivos.

Después de entrenar el modelo de ML en SageMaker, puede optimizar el modelo con Neo mediante un trabajo de compilación de Sagemaker. Los artefactos del modelo compilado resultantes se pueden empaquetar en un componente GreenGrass V2 mediante el empaquetador Edge Manager. Luego, se puede registrar como un componente personalizado en el Mis componentes sección en la consola de AWS IoT Greengrass. Este componente ya contiene los comandos de ciclo de vida necesarios para descargar y descomprimir el artefacto del modelo en nuestro dispositivo, de modo que el código de inferencia pueda cargarlo para enviar las imágenes capturadas a través de él.

En cuanto al código de inferencia, debemos crear un componente usando la consola o Interfaz de línea de comandos de AWS (CLI de AWS). Primero, empaquetamos nuestro código fuente de inferencia y las dependencias necesarias para Amazon S3. Después de cargar el código, podemos crear nuestro componente usando una receta en .yaml o JSON como el siguiente ejemplo:

---
RecipeFormatVersion: 2020-01-25
ComponentName: dummymodel.inference
ComponentVersion: 0.0.1
ComponentDescription: Deploys inference code to a client
ComponentPublisher: Amazon Web Services, Inc.
ComponentDependencies:
  aws.GreenGrass.TokenExchangeService:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
  dummymodel:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
Manifests:
  - Platform:
      os: linux
      architecture: "*"
    Lifecycle:
      install: |-
        apt-get install python3-pip
        pip3 install numpy
        pip3 install sysv_ipc
        pip3 install boto3
        pip3 install grpcio-tools
        pip3 install grpcio
        pip3 install protobuf
        pip3 install SageMaker
        tar xf {artifacts:path}/sourcedir.tar.gz
      run:
        script: |-
          sleep 5 && sudo python3 {work:path}/inference.py 
    Artifacts:
      - URI: s3://BUCKET-NAME/path/to/inference/sourcedir.tar.gz
        Permission:
          Execute: OWNER

Esta receta de ejemplo muestra el nombre y la descripción de nuestro componente, así como los requisitos previos necesarios antes de ejecutar nuestro comando de secuencia de comandos. La receta desempaqueta el artefacto en un entorno de carpeta de trabajo en el dispositivo y usamos esa ruta para ejecutar nuestro código de inferencia. El comando de AWS CLI para crear dicha receta es:

aws greengrassv2 create-component-version --region $REGION 
                                          --inline-recipe fileb://path/to/recipe.yaml

Ahora puede ver este componente creado en la consola de AWS IoT Greengrass.

Tenga cuidado con el hecho de que la versión del componente es importante y debe especificarse en el archivo de receta. Repetir el mismo número de versión devolverá un error.

Después de configurar nuestro modelo y código de inferencia como componentes, estamos listos para implementarlos.

Implemente la aplicación y el modelo con AWS IoT Greengrass

En las secciones anteriores, aprendió a empaquetar el código de inferencia y los modelos de ML. Ahora podemos crear una implementación con varios componentes que incluyan tanto los componentes como las configuraciones necesarias para que nuestro código de inferencia interactúe con el modelo en el dispositivo perimetral.

El agente de Edge Manager es el componente que debe instalarse en cada dispositivo de borde para habilitar todas las capacidades de Edge Manager. En la consola de SageMaker, tenemos una flota de dispositivos definida, que tiene un depósito de S3 asociado. Todos los dispositivos de borde asociados con la flota capturarán e informarán sus datos a esta ruta S3. El agente se puede implementar como un componente en AWS IoT Greengrass v2, lo que facilita su instalación y configuración que si el agente se implementara en modo independiente. Al implementar el agente como componente, debemos especificar sus parámetros de configuración, es decir, la flota de dispositivos y la ruta de S3.

Creamos una configuración de implementación con los componentes personalizados para el modelo y el código que acabamos de crear. Esta configuración se define en un archivo JSON que enumera el nombre y el destino de la implementación, así como los componentes de la implementación. Podemos agregar y actualizar los parámetros de configuración de cada componente, como en el agente Edge Manager, donde especificamos el nombre de la flota y el depósito.

{
    "targetArn": "targetArn",
    "deploymentName": "dummy-deployment",
    "components": {
        "aws.GreenGrass.Nucleus": {
            "version": "2.5.3",
        },
        "aws.GreenGrass.Cli": {
            "version": "2.5.3"
        },
        "aws.GreenGrass.SageMakerEdgeManager": {
            "version": 1.1.0,
            "configurationUpdate": {
                "merge": {
                "DeviceFleetName": "FLEET-NAME",
                "BucketName": "BUCKET-NAME-URI"
                }
            }
        },
        "dummymodel.inference": {
            "version": "0.0.1"
        },
        "dummymodel": {
            "version": "0.0.1"
        }
    }
}

Vale la pena señalar que hemos agregado no solo el modelo, los componentes de inferencia y el agente, sino también la CLI y el núcleo de AWS IoT Greengrass como componentes. El primero puede ayudar a depurar ciertas implementaciones localmente en el dispositivo. Este último se agrega a la implementación para configurar el acceso a la red necesario desde el propio dispositivo si es necesario (por ejemplo, la configuración del proxy), y también en caso de que desee realizar una actualización OTA del núcleo de AWS IoT Greengrass v2. El núcleo no se implementa porque está instalado en el dispositivo y solo se aplicará la actualización de configuración (a menos que haya una actualización). Para implementar, simplemente necesitamos ejecutar el siguiente comando sobre la configuración anterior. Recuerde configurar el ARN de destino al que se aplicará la implementación (una cosa de IoT o un grupo de IoT). También podemos desplegar estos componentes desde la consola.

aws greengrassv2 create-deployment --region $REGION 
                                   --cli-input-json file://path/to/deployment.json

Monitoree y administre los modelos de ML implementados en el perímetro

Ahora que su aplicación se ejecuta en los dispositivos perimetrales, es hora de comprender cómo monitorear la flota para mejorar la gobernanza, el mantenimiento y la visibilidad. En la consola de SageMaker, elija Administrador de borde en el panel de navegación, luego elija Flotas de dispositivos Edge. Desde aquí, elige tu flota.

En la página de detalles de la flota, puede ver algunos metadatos de los modelos que se ejecutan en cada dispositivo de su flota. El informe de flota se genera cada 24 horas.

Los datos capturados por cada dispositivo a través de Edge Agent se envían a un depósito S3 en formato de líneas json (JSONL). El proceso de envío de datos capturados se gestiona desde el punto de vista de la aplicación. Por lo tanto, es libre de decidir si desea enviar estos datos, cómo y con qué frecuencia.

Puede usar estos datos para muchas cosas, como monitorear la deriva de datos y la calidad del modelo, crear un nuevo conjunto de datos, enriquecer un lago de datos y más. Un ejemplo simple de cómo utilizar estos datos es cuando identifica alguna desviación de datos en la forma en que los usuarios interactúan con su aplicación y necesita entrenar un nuevo modelo. Luego, crea un nuevo conjunto de datos con los datos capturados y lo vuelve a copiar en la cuenta de desarrollo. Esto puede iniciar automáticamente una nueva ejecución de su entorno que crea un nuevo modelo y lo vuelve a implementar en toda la flota para mantener el rendimiento de la solución implementada.

Conclusión

En esta publicación, aprendió a crear una solución completa que combina MLOps y ML@Edge mediante los servicios de AWS. Crear una solución de este tipo no es trivial, pero esperamos que la arquitectura de referencia que se presenta en esta publicación pueda inspirarlo y ayudarlo a crear una arquitectura sólida para sus propios desafíos comerciales. También puede usar solo las partes o módulos de esta arquitectura que se integran con su entorno MLOps existente. Al crear prototipos de un solo módulo a la vez y utilizar los servicios de AWS apropiados para abordar cada parte de este desafío, puede aprender a crear un entorno de MLOps sólido y también a simplificar aún más la arquitectura final.

Como próximo paso, le recomendamos que pruebe Sagemaker Edge Manager para administrar su ciclo de vida de ML en el perímetro. Para obtener más información sobre cómo funciona Edge Manager, consulte Implemente modelos en el perímetro con SageMaker Edge Manager .

Sobre los autores

Bruno Pistón es un arquitecto de soluciones especializado en IA/ML para AWS con sede en Milán. Trabaja con clientes de cualquier tamaño para ayudarlos a comprender profundamente sus necesidades técnicas y diseñar soluciones de IA y aprendizaje automático que aprovechen al máximo la nube de AWS y la pila de aprendizaje automático de Amazon. Su campo de especialización es el aprendizaje automático de extremo a extremo, la industrialización del aprendizaje automático y MLOps. Le gusta pasar tiempo con sus amigos y explorar nuevos lugares, así como viajar a nuevos destinos.

mateo calabrese es un arquitecto de entrega de clientes de AI/ML en el equipo de servicios profesionales de AWS. Trabaja con grandes empresas de EMEA en proyectos de IA/ML, ayudándolas a proponer, diseñar, entregar, escalar y optimizar las cargas de trabajo de producción de ML. Su principal experiencia es ML Operation (MLOps) y Machine Learning at Edge. Su objetivo es acortar su tiempo para generar valor y acelerar los resultados comerciales al proporcionar las mejores prácticas de AWS. En su tiempo libre, le gusta caminar y viajar.

Raúl Díaz García es un científico de datos sénior en el equipo de servicios profesionales de AWS. Trabaja con clientes de grandes empresas en EMEA, donde les ayuda a habilitar soluciones relacionadas con la visión por computadora y el aprendizaje automático en el espacio de IoT.

Sokratis Kartakis es Arquitecto Senior de Soluciones Especialista en Aprendizaje Automático para Amazon Web Services. Sokratis se enfoca en permitir que los clientes empresariales industrialicen sus soluciones de Machine Learning (ML) al explotar los servicios de AWS y dar forma a su modelo operativo, es decir, la base de MLOps y la hoja de ruta de transformación aprovechando las mejores prácticas de desarrollo. Ha dedicado más de 15 años a inventar, diseñar, liderar e implementar soluciones innovadoras de ML e Internet de las cosas (IoT) de nivel de producción de extremo a extremo en los dominios de energía, venta minorista, salud, finanzas/banca, automovilismo, etc. A Sokratis le gusta pasar su tiempo libre con familiares y amigos, o andar en motocicleta.

Samir Araújo es un arquitecto de soluciones de AI / ML en AWS. Ayuda a los clientes a crear soluciones de IA / ML que resuelven sus desafíos comerciales mediante AWS. Ha estado trabajando en varios proyectos de IA / ML relacionados con la visión por computadora, el procesamiento del lenguaje natural, el pronóstico, el aprendizaje automático en el borde y más. Le gusta jugar con proyectos de hardware y automatización en su tiempo libre, y tiene un interés particular por la robótica.