MLOps na borda com Amazon SageMaker Edge Manager e AWS IoT Greengrass

A Internet das Coisas (IoT) permitiu que clientes de vários setores, como manufatura, automotivo e energia, monitorassem e controlassem ambientes do mundo real. Ao implantar uma variedade de dispositivos IoT de borda, como câmeras, termostatos e sensores, você pode coletar dados, enviá-los para a nuvem e criar modelos de aprendizado de máquina (ML) para prever anomalias, falhas e muito mais. No entanto, se o caso de uso exigir previsão em tempo real, você precisará enriquecer sua solução de IoT com recursos de ML na borda (ML@Edge). ML@Edge é um conceito que separa o ciclo de vida do modelo de ML do ciclo de vida do aplicativo e permite executar um pipeline de ML de ponta a ponta que inclui preparação de dados, construção de modelo, compilação e otimização de modelo, implantação de modelo (para uma frota de dispositivos de borda), execução do modelo e monitoramento e governança do modelo. Você implanta o aplicativo uma vez e executa o pipeline de ML quantas vezes precisar.

Como você pode imaginar, implementar todos os passos propostos pelo conceito ML@Edge não é trivial. Há muitas questões que os desenvolvedores precisam responder para implementar uma solução ML@Edge completa, por exemplo:

• Como posso operar modelos de ML em uma frota (centenas, milhares ou milhões) de dispositivos na borda?
• Como faço para proteger meu modelo ao implantá-lo e executá-lo na borda?
• Como monitoro o desempenho do meu modelo e o treino novamente, se necessário?

Nesta postagem, você aprende como responder a todas essas perguntas e construir uma solução ponta a ponta para automatizar seu pipeline ML@Edge. Você verá como usar Gerenciador de borda do Amazon SageMaker, Estúdio Amazon SageMaker e AWS IoT Greengrass v2 para criar um ambiente MLOps (Operações de ML) que automatize o processo de construção e implantação de modelos de ML para grandes frotas de dispositivos de borda.

Nas próximas seções, apresentamos uma arquitetura de referência que detalha todos os componentes e fluxos de trabalho necessários para construir uma solução completa para MLOps focada em cargas de trabalho de borda. Em seguida, nos aprofundamos nas etapas que esta solução executa automaticamente para construir e preparar um novo modelo. Também mostramos como preparar os dispositivos de borda para começar a implantar, executar e monitorar modelos de ML e demonstramos como monitorar e manter os modelos de ML implantados em sua frota de dispositivos.

Visão geral da solução

A produção de modelos robustos de ML requer a colaboração de várias pessoas, como cientistas de dados, engenheiros de ML, engenheiros de dados e partes interessadas de negócios, em uma infraestrutura semiautomática após operações específicas (MLOps). Além disso, a modularização do ambiente é importante para dar a todas essas diferentes personas flexibilidade e agilidade para desenvolver ou melhorar (independentemente do fluxo de trabalho) o componente pelo qual são responsáveis. Um exemplo de tal infraestrutura consiste em múltiplas contas AWS que permitem esta colaboração e produção dos modelos de ML tanto na nuvem quanto nos dispositivos de borda. Na arquitetura de referência a seguir, mostramos como organizamos as diversas contas e serviços que compõem esta plataforma MLOps ponta a ponta para construir modelos de ML e implantá-los na borda.

Esta solução consiste nas seguintes contas:

• Conta do data lake – Os engenheiros de dados ingerem, armazenam e preparam dados de diversas fontes de dados, incluindo bancos de dados locais e dispositivos IoT.
• Conta de ferramentas – Os operadores de TI gerenciam e verificam pipelines de CI/CD para entrega e implantação contínuas e automatizadas de pacotes de modelos de ML nas contas de pré-produção e produção para dispositivos remotos de borda. As execuções de pipelines de CI/CD são automatizadas por meio do uso de Amazon Event Bridge, que monitora eventos de status de alteração de modelos e destinos de ML AWS Code Pipeline.
• Conta de experimentação e desenvolvimento – Os cientistas de dados podem realizar pesquisas e experimentar múltiplas técnicas de modelagem e algoritmos para resolver problemas de negócios baseados em ML, criando soluções de prova de conceito. Engenheiros de ML e cientistas de dados colaboram para dimensionar uma prova de conceito, criando fluxos de trabalho automatizados usando Pipelines Amazon SageMaker para preparar dados e construir, treinar e empacotar modelos de ML. A implantação dos pipelines é conduzida por pipelines de CI/CD, enquanto o controle de versão dos modelos é obtido usando o Registro de modelo do Amazon SageMaker. Os cientistas de dados avaliam as métricas de múltiplas versões do modelo e solicitam a promoção do melhor modelo para produção, acionando o pipeline de CI/CD.
• Conta de pré-produção – Antes da promoção do modelo para o ambiente de produção, o modelo precisa ser testado para garantir robustez em um ambiente de simulação. Portanto, o ambiente de pré-produção é um simulador do ambiente de produção, no qual os endpoints do modelo SageMaker são implantados e testados automaticamente. Os métodos de teste podem incluir um teste de integração, um teste de estresse ou testes específicos de ML nos resultados de inferência. Nesse caso, o ambiente de produção não é um endpoint do modelo SageMaker, mas um dispositivo de borda. Para simular um dispositivo de borda em pré-produção, duas abordagens são possíveis: usar um Amazon Elastic Compute Nuvem (Amazon EC2) com as mesmas características de hardware ou use uma plataforma de teste em laboratório que consiste nos dispositivos reais. Com esta infraestrutura, o pipeline CI/CD implanta o modelo no simulador correspondente e conduz os múltiplos testes automaticamente. Após a execução bem-sucedida dos testes, o pipeline de CI/CD requer aprovação manual (por exemplo, da parte interessada da IoT para promover o modelo para produção).
• Conta de produção – No caso de hospedar o modelo na Nuvem AWS, o pipeline de CI/CD implanta um endpoint do modelo SageMaker na conta de produção. Neste caso, o ambiente de produção consiste em múltiplas frotas de dispositivos de ponta. Portanto, o pipeline de CI/CD usa o Edge Manager para implantar os modelos na frota de dispositivos correspondente.
• Dispositivos Edge – Dispositivos de borda remota são dispositivos de hardware que podem executar modelos de ML usando o Edge Manager. Ele permite que o aplicativo nesses dispositivos gerencie os modelos, execute inferências nos modelos e capture dados com segurança em Serviço de armazenamento simples da Amazon (Amazônia S3).

Projetos SageMaker ajudá-lo a automatizar o processo de provisionamento de recursos dentro de cada uma dessas contas. Não nos aprofundamos nesse recurso, mas para saber mais sobre como construir um modelo de projeto SageMaker que implanta modelos de ML em contas, confira Implantação de modelo de várias contas com Amazon SageMaker Pipelines.

Conta de pré-produção: gêmeo digital

Após o processo de treinamento, o modelo resultante precisa ser avaliado. Na conta de pré-produção, você tem um dispositivo Edge simulado. Representa o gêmeo digital do dispositivo de borda no qual o modelo de ML é executado em produção. Este ambiente tem a dupla finalidade de realizar os testes clássicos (como unitário, integração e smoke) e ser um playground para a equipe de desenvolvimento. Este dispositivo é simulado usando uma instância EC2 onde todos os componentes necessários para gerenciar o modelo de ML foram implantados.

Os serviços envolvidos são os seguintes:

• Núcleo da AWS IoT - Nós usamos Núcleo da AWS IoT para criar objetos de coisa do AWS IoT, criar uma frota de dispositivos, registrar a frota de dispositivos para que ela possa interagir com a nuvem, criar certificados X.509 para autenticar dispositivos de borda no AWS IoT Core, associar o alias de função ao AWS IoT Core que foi gerado quando que a frota criou, obtenha um endpoint específico da conta da AWS para o provedor de credenciais, obtenha um arquivo Amazon Root CA oficial e carregue o arquivo Amazon CA no Amazon S3.
• Amazon Sagemaker Neo – Sábio Neo otimiza automaticamente modelos de aprendizado de máquina para que a inferência seja executada mais rapidamente, sem perda de precisão. Ele oferece suporte ao modelo de aprendizado de máquina já construído com DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX ou XGBoost e treinado no Amazon SageMaker ou em qualquer outro lugar. Em seguida, você escolhe sua plataforma de hardware de destino, que pode ser uma instância de hospedagem SageMaker ou um dispositivo de ponta baseado em processadores Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments ou Xilinx.
• Gerenciador de borda – Usamos o Edge Manager para registrar e gerenciar o dispositivo edge nas frotas Sagemaker. Frotas são coleções de dispositivos agrupados logicamente que você pode usar para coletar e analisar dados. Além disso, o empacotador Edge Manager empacota o modelo otimizado e cria um componente AWS IoT Greengrass V2 que pode ser implantado diretamente. Você pode usar o Edge Manager para operar modelos de ML em uma frota de câmeras inteligentes, alto-falantes inteligentes, robôs e outras frotas de dispositivos SageMaker.
• AWS IoT Greengrass V2 - AWS IoT Greengrass permite implantar componentes nos dispositivos simulados usando uma instância EC2. Ao usar o agente AWS IoT Greengrass V2 nas instâncias EC2, podemos simplificar o acesso, o gerenciamento e a implantação do agente e modelo do Edge Manager nos dispositivos. Sem o AWS IoT Greengrass V2, a configuração de dispositivos e frotas para usar o Edge Manager exige que você copie manualmente o agente de um bucket de versão do S3. Com a integração do AWS IoT Greengrass V2 e do Edge Manager, é possível usar componentes do AWS IoT Greengrass V2. Os componentes são módulos de software pré-criados que podem conectar dispositivos de borda a serviços da AWS ou serviços de terceiros por meio do AWS IoT Greengrass.
• Agente Edge Manager – O agente Edge Manager é implantado por meio do AWS IoT Greengrass V2 na instância do EC2. O agente pode carregar vários modelos ao mesmo tempo e fazer inferências com modelos carregados em dispositivos de borda. O número de modelos que o agente pode carregar é determinado pela memória disponível no dispositivo.
• Amazon S3 – Usamos um bucket S3 para armazenar os dados capturados por inferência do agente Edge Manager.

Podemos definir uma conta de pré-produção como um gêmeo digital para testar modelos de ML antes de movê-los para dispositivos de ponta reais. Isso oferece os seguintes benefícios:

• Agilidade e flexibilidade – Cientistas de dados e engenheiros de ML precisam validar rapidamente se o modelo de ML e os scripts associados (scripts de pré-processamento e inferência) funcionarão na borda do dispositivo. No entanto, os departamentos de IoT e de ciência de dados em grandes empresas podem ser entidades diferentes. Ao replicar de forma idêntica a pilha de tecnologia na nuvem, os cientistas de dados e engenheiros de ML podem iterar e consolidar artefatos antes da implantação.
• Avaliação de risco e tempo de produção acelerados – A implantação no dispositivo de borda é o estágio final do processo. Depois de validar tudo em um ambiente isolado e independente, garanta que ele esteja de acordo com as especificações exigidas pela borda em termos de qualidade, desempenho e integração. Isso ajuda a evitar maior envolvimento de outras pessoas no departamento de IoT para corrigir e iterar versões de artefatos.
• Melhor colaboração em equipe e melhor qualidade e desempenho – A equipe de desenvolvimento pode avaliar imediatamente o impacto do modelo de ML analisando métricas de hardware de ponta e medindo o nível de interações com ferramentas de terceiros (por exemplo, taxa de E/S). Então, a equipe de IoT é responsável apenas pela implantação no ambiente de produção e pode ter certeza de que os artefatos são precisos para um ambiente de produção.
• Playground integrado para testes – Dado o objetivo dos modelos de ML, o ambiente de pré-produção em um fluxo de trabalho tradicional deve ser representado por um dispositivo de ponta fora do ambiente de nuvem. Isso introduz outro nível de complexidade. Integrações são necessárias para coletar métricas e feedback. Em vez disso, ao usar o ambiente simulado de gêmeo digital, as interações são reduzidas e o tempo de lançamento no mercado é reduzido.

Conta de produção e ambiente de borda

Depois que os testes forem concluídos e a estabilidade do artefato for alcançada, você poderá prosseguir para a implantação de produção por meio dos pipelines. A implantação do artefato ocorre programaticamente depois que um operador aprovou o artefato. No entanto, o acesso ao Console de gerenciamento da AWS é concedido aos operadores em modo somente leitura para poder monitorar metadados associados às frotas e, portanto, ter insights sobre a versão do modelo de ML implantado e outras métricas associadas ao ciclo de vida.

As frotas de dispositivos de borda pertencem à conta de produção da AWS. Esta conta possui configurações específicas de segurança e rede para permitir a comunicação entre a nuvem e os dispositivos de borda. Os principais serviços da AWS implantados na conta de produção são o Edge Manager, responsável por gerenciar todas as frotas de dispositivos, coletar dados e operar modelos de ML, e o AWS IoT Core, que gerencia objetos, certificados, alias de função e endpoints de IoT.

Ao mesmo tempo, precisamos configurar um dispositivo de ponta com os serviços e componentes para gerenciar modelos de ML. Os principais componentes são os seguintes:

• AWS IoT Greengrass V2
• Um agente do Edge Manager
• Certificados AWS IoT
• Application.py, que é responsável por orquestrar o processo de inferência (recuperar informações da fonte de dados de borda e realizar inferência usando o agente Edge Manager e o modelo de ML carregado)
• Uma conexão com o Amazon S3 ou a conta do data lake para armazenar dados inferidos

Pipeline de ML automatizado

Agora que você sabe mais sobre a organização e os componentes da arquitetura de referência, podemos nos aprofundar no pipeline de ML que usamos para construir, treinar e avaliar o modelo de ML dentro da conta de desenvolvimento.

Um pipeline (construído usando Pipelines de criação de modelos do Amazon SageMaker) é uma série de etapas interconectadas definidas por uma definição de pipeline JSON. Esta definição de pipeline codifica um pipeline usando um gráfico acíclico direcionado (DAG). Este DAG fornece informações sobre os requisitos e relacionamentos entre cada etapa do seu pipeline. A estrutura do DAG de um pipeline é determinada pelas dependências de dados entre as etapas. Essas dependências de dados são criadas quando as propriedades da saída de uma etapa são passadas como entrada para outra etapa.

Para permitir que as equipes de ciência de dados automatizem facilmente a criação de novas versões de modelos de ML, é importante introduzir etapas de validação e dados automatizados para alimentar e melhorar continuamente os modelos de ML, bem como estratégias de monitoramento de modelos para permitir o acionamento de pipeline. O diagrama a seguir mostra um exemplo de pipeline.

Para habilitar automações e recursos de MLOps, é importante criar componentes modulares para criar artefatos de código reutilizáveis ​​que possam ser compartilhados em diferentes etapas e casos de uso de ML. Isso permite mover rapidamente a implementação de uma fase de experimentação para uma fase de produção, automatizando a transição.

As etapas para definir um pipeline de ML para permitir o treinamento contínuo e o controle de versão de modelos de ML são as seguintes:

• Pré-processando – O processo de limpeza de dados, engenharia de recursos e criação de conjunto de dados para treinar o algoritmo de ML
• Training – O processo de treinamento do algoritmo de ML desenvolvido para gerar uma nova versão do artefato do modelo de ML
• Avaliação – O processo de avaliação do modelo de ML gerado, para extrair as principais métricas relacionadas ao comportamento do modelo em novos dados não vistos durante a fase de treinamento
• Registo – O processo de versionamento do novo artefato do modelo de ML treinado, vinculando as métricas extraídas ao artefato gerado

Você pode ver mais detalhes sobre como construir um pipeline SageMaker a seguir caderno.

Acione pipelines de CI/CD usando EventBridge

Ao terminar de construir o modelo, você poderá iniciar o processo de implantação. A última etapa do pipeline do SageMaker definido na seção anterior registra uma nova versão do modelo no grupo de registro de modelo específico do SageMaker. A implantação de uma nova versão do modelo de ML é gerenciada usando o status do registro do modelo. Ao aprovar ou rejeitar manualmente uma versão do modelo de ML, esta etapa gera um evento que é capturado pelo EventBridge. Esse evento pode então iniciar um novo pipeline (desta vez CI/CD) para criar uma nova versão do componente AWS IoT Greengrass que é então implantada nas contas de pré-produção e produção. A captura de tela a seguir mostra nossa regra EventBridge definida.

Esta regra monitora o grupo de pacotes de modelo do SageMaker procurando atualizações de pacotes de modelo no status Approved or Rejected.

A regra do EventBridge é então configurada para direcionar o CodePipeline, que inicia o fluxo de trabalho de criação de um novo componente do AWS IoT Greengrass usando Amazon Sage Maker Neo e Gerenciador de Borda.

Otimize modelos de ML para a arquitetura de destino

Neo permite otimizar modelos de ML para realizar inferência em dispositivos de ponta (e na nuvem). Ele otimiza automaticamente os modelos de ML para melhor desempenho com base na arquitetura de destino e desacopla o modelo da estrutura original, permitindo executá-lo em um tempo de execução leve.

Consulte o seguinte caderno para obter um exemplo de como compilar um modelo PyTorch Resnet18 usando Neo.

Crie o pacote de implantação incluindo o componente AWS IoT Greengrass

O Edge Manager permite gerenciar, proteger, implantar e monitorar modelos em uma frota de dispositivos de borda. Na sequência caderno, você pode ver mais detalhes sobre como construir uma frota minimalista de dispositivos de ponta e realizar alguns experimentos com esse recurso.

Depois de configurar a frota e compilar o modelo, você precisa executar um trabalho de empacotamento do Edge Manager, que prepara o modelo para ser implantado na frota. Você pode iniciar um trabalho de empacotamento usando o Boto3 SDK. Para nossos parâmetros, usamos o modelo otimizado e os metadados do modelo. Adicionando os seguintes parâmetros ao OutputConfig, o trabalho também prepara um componente do AWS IoT Greengrass V2 com o modelo:

• PresetDeploymentType
• PresetDeploymentConfig

Veja o seguinte 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}
        ),
    }
)

Implante modelos de ML na borda em escala

Agora é hora de implantar o modelo em sua frota de dispositivos de borda. Em primeiro lugar, precisamos de garantir que dispomos dos recursos necessários Gerenciamento de acesso e identidade da AWS (IAM) permissões para provisionar nossos dispositivos IoT e poder implantar componentes neles. Exigimos dois elementos básicos para começar a integrar dispositivos em nossa plataforma IoT:

• Política de IAM – Esta política permite o provisionamento automático de tais dispositivos, vinculados ao usuário ou função que executa o provisionamento. Ele deve ter permissões de gravação de IoT para criar o item e o grupo de IoT, bem como para anexar as políticas necessárias ao dispositivo. Para obter mais informações, consulte Política mínima de IAM para o instalador provisionar recursos.
• Papel do IAM – esta função está associada às coisas e grupos de IoT que criamos. Você pode criar essa função no momento do provisionamento com permissões básicas, mas faltarão recursos como acesso ao Amazon S3 ou Serviço de gerenciamento de chaves AWS (AWS KMS) que pode ser necessário posteriormente. Você pode criar essa função antecipadamente e reutilizá-la quando provisionarmos o dispositivo. Para obter mais informações, consulte Autorizar dispositivos principais para interagir com a AWS.

Instalação e provisionamento do AWS IoT Greengrass

Depois de implementarmos a política e a função do IAM, estaremos prontos para instalar o software AWS IoT Greengrass Core com provisionamento automático de recursos. Embora seja possível provisionar os recursos de IoT seguindo etapas manuais, existe o procedimento conveniente de provisionar automaticamente esses recursos durante a instalação do núcleo do AWS IoT Greengrass v2. Esta é a opção preferida para integrar rapidamente novos dispositivos à plataforma. Além do mais default-jdk, outros pacotes precisam ser instalados, como curl, unzip e python3.

Quando provisionamos nosso dispositivo, o nome da coisa IoT deve ser exatamente igual ao dispositivo de borda definido no Edge Manager, caso contrário, os dados não serão capturados no bucket S3 de destino.

O instalador poderá criar a função e o alias do AWS IoT Greengrass durante a instalação, caso eles não existam. No entanto, eles serão criados com permissões mínimas e exigirão a adição manual de mais políticas para interagir com outros serviços, como o Amazon S3. Recomendamos criar esses recursos IAM antecipadamente, conforme mostrado anteriormente, e reutilizá-los à medida que você integra novos dispositivos à conta.

Embalagem de componentes de modelo e inferência

Depois que nosso código for desenvolvido, podemos implantar tanto o código (para inferência) quanto nossos modelos de ML como componentes em nossos dispositivos.

Depois que o modelo de ML for treinado no SageMaker, você poderá otimizar o modelo com o Neo usando um trabalho de compilação do Sagemaker. Os artefatos do modelo compilado resultantes podem então ser empacotados em um componente GreenGrass V2 usando o empacotador Edge Manager. Em seguida, ele pode ser registrado como um componente personalizado no Meus componentes seção no console do AWS IoT Greengrass. Este componente já contém os comandos de ciclo de vida necessários para baixar e descompactar o artefato do modelo em nosso dispositivo, para que o código de inferência possa carregá-lo para enviar as imagens capturadas por meio dele.

Em relação ao código de inferência, devemos criar um componente utilizando o console ou Interface de linha de comando da AWS (AWS CLI). Primeiro, empacotamos nosso código-fonte de inferência e as dependências necessárias no Amazon S3. Depois de fazer upload do código, podemos criar nosso componente usando uma receita em .yaml ou JSON como no exemplo a seguir:

---
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

Este exemplo de receita mostra o nome e a descrição do nosso componente, bem como os pré-requisitos necessários antes do nosso comando de execução do script. A receita descompacta o artefato em um ambiente de pasta de trabalho no dispositivo e usamos esse caminho para executar nosso código de inferência. O comando AWS CLI para criar tal receita é:

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

Agora você pode ver esse componente criado no console do AWS IoT Greengrass.

Cuidado com o fato de que a versão do componente é importante e deve ser especificada no arquivo de receita. Repetir o mesmo número de versão retornará um erro.

Depois que nosso modelo e código de inferência forem configurados como componentes, estaremos prontos para implantá-los.

Implante o aplicativo e o modelo usando o AWS IoT Greengrass

Nas seções anteriores, você aprendeu como empacotar o código de inferência e os modelos de ML. Agora podemos criar uma implantação com vários componentes que incluem componentes e configurações necessárias para que nosso código de inferência interaja com o modelo no dispositivo de borda.

O agente Edge Manager é o componente que deve ser instalado em cada dispositivo de borda para habilitar todos os recursos do Edge Manager. No console do SageMaker, temos uma frota de dispositivos definida, que possui um bucket S3 associado. Todos os dispositivos de borda associados à frota capturarão e reportarão seus dados para esse caminho S3. O agente pode ser implantado como um componente no AWS IoT Greengrass v2, o que facilita a instalação e a configuração do que se o agente fosse implantado no modo independente. Ao implantar o agente como um componente, precisamos especificar seus parâmetros de configuração, ou seja, a frota de dispositivos e o caminho S3.

Criamos uma configuração de implantação com os componentes personalizados para o modelo e código que acabamos de criar. Essa configuração é definida em um arquivo JSON que lista o nome e o destino da implantação, bem como os componentes da implantação. Podemos adicionar e atualizar os parâmetros de configuração de cada componente, como no agente Edge Manager, onde especificamos o nome da frota e o bucket.

{
    "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"
        }
    }
}

É importante notar que adicionamos não apenas o modelo, os componentes de inferência e o agente, mas também a CLI e o núcleo do AWS IoT Greengrass como componentes. O primeiro pode ajudar a depurar determinadas implantações localmente no dispositivo. Este último é adicionado à implantação para configurar o acesso à rede necessário a partir do próprio dispositivo, se necessário (por exemplo, configurações de proxy) e também caso você queira realizar uma atualização OTA do núcleo do AWS IoT Greengrass v2. O núcleo não é implantado porque está instalado no dispositivo e somente a atualização da configuração será aplicada (a menos que haja uma atualização em vigor). Para implantar, precisamos simplesmente executar o seguinte comando na configuração anterior. Lembre-se de configurar o ARN de destino ao qual a implantação será aplicada (uma coisa ou grupo de IoT). Também podemos implantar esses componentes a partir do console.

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

Monitore e gerencie modelos de ML implantados na borda

Agora que seu aplicativo está sendo executado nos dispositivos de borda, é hora de entender como monitorar a frota para melhorar a governança, a manutenção e a visibilidade. No console do SageMaker, escolha Gerenciador de borda no painel de navegação e escolha Frotas de dispositivos periféricos. A partir daqui, escolha sua frota.

Na página de detalhes da frota você pode ver alguns metadados dos modelos que estão rodando em cada dispositivo da sua frota. O relatório da frota é gerado a cada 24 horas.

Os dados capturados por cada dispositivo por meio do Edge Agent são enviados para um bucket S3 em formato de linhas json (JSONL). O processo de envio de dados capturados é gerenciado do ponto de vista do aplicativo. Você é, portanto, livre para decidir se deseja enviar esses dados, como e com que frequência.

Você pode usar esses dados para muitas coisas, como monitorar o desvio de dados e a qualidade do modelo, construir um novo conjunto de dados, enriquecer um data lake e muito mais. Um exemplo simples de como utilizar esses dados é quando você identifica algum desvio de dados na maneira como os usuários estão interagindo com seu aplicativo e precisa treinar um novo modelo. Em seguida, você cria um novo conjunto de dados com os dados capturados e os copia de volta para a conta de desenvolvimento. Isso pode iniciar automaticamente uma nova execução do seu ambiente que cria um novo modelo e o reimplanta em toda a frota para manter o desempenho da solução implantada.

Conclusão

Neste post, você aprendeu como construir uma solução completa que combina MLOps e ML@Edge usando serviços AWS. Construir tal solução não é trivial, mas esperamos que a arquitetura de referência apresentada neste post possa inspirar e ajudar você a construir uma arquitetura sólida para seus próprios desafios de negócios. Você também pode usar apenas as partes ou módulos dessa arquitetura que se integram ao seu ambiente MLOps existente. Ao prototipar um único módulo por vez e usar os serviços apropriados da AWS para enfrentar cada parte desse desafio, você pode aprender como construir um ambiente MLOps robusto e também simplificar ainda mais a arquitetura final.

Como próxima etapa, encorajamos você a experimentar o Sagemaker Edge Manager para gerenciar seu ciclo de vida de ML na borda. Para obter mais informações sobre como o Edge Manager funciona, consulte Implante modelos na borda com o SageMaker Edge Manager .

Sobre os autores

Bruno Pistone é um arquiteto de soluções especialista em IA/ML para AWS com sede em Milão. Ele trabalha com clientes de qualquer tamanho para ajudá-los a entender profundamente suas necessidades técnicas e projetar soluções de IA e Machine Learning que fazem o melhor uso da Nuvem AWS e da pilha Amazon Machine Learning. Suas áreas de especialização são Machine Learning de ponta a ponta, Machine Learning Industrialization e MLOps. Ele gosta de passar tempo com seus amigos e explorar novos lugares, além de viajar para novos destinos.

Matteo Calabrese é arquiteto de entrega de clientes de AI/ML na equipe de serviços profissionais da AWS. Ele trabalha com grandes empresas da EMEA em projetos de IA/ML, ajudando-as a propor, projetar, entregar, dimensionar e otimizar cargas de trabalho de produção de ML. Suas principais expertises são ML Operation (MLOps) e Machine Learning at Edge. Seu objetivo é reduzir o tempo de obtenção de valor e acelerar os resultados de negócios, fornecendo as melhores práticas da AWS. Nas horas vagas gosta de fazer caminhadas e viajar.

Raúl Díaz García é cientista de dados sênior na equipe de serviços profissionais da AWS. Ele trabalha com grandes clientes empresariais em toda a EMEA, onde os ajuda a habilitar soluções relacionadas à visão computacional e ao aprendizado de máquina no espaço IoT.

Sokratis Kartakis é arquiteto de soluções especialista em aprendizado de máquina sênior da Amazon Web Services. A Sokratis se concentra em permitir que clientes corporativos industrializem suas soluções de aprendizado de máquina (ML), explorando os serviços da AWS e moldando seu modelo operacional, ou seja, a base de MLOps e o roteiro de transformação, aproveitando as melhores práticas de desenvolvimento. Ele passou mais de 15 anos inventando, projetando, liderando e implementando soluções inovadoras de ML e Internet das Coisas (IoT) em nível de produção de ponta a ponta nas áreas de energia, varejo, saúde, finanças/bancos, esportes motorizados, etc. Sokratis gosta de passar seu tempo livre com a família e amigos, ou andando de moto.

Samir Araújo é arquiteto de soluções de AI / ML na AWS. Ele ajuda os clientes a criar soluções de AI / ML que resolvem seus desafios de negócios usando AWS. Ele tem trabalhado em vários projetos de AI / ML relacionados à visão computacional, processamento de linguagem natural, previsão, ML na borda e muito mais. Ele gosta de brincar com projetos de hardware e automação em seu tempo livre e tem um interesse particular por robótica.