O que aprendemos servindo modelos de aprendizado de máquina em escala usando o Amazon SageMaker

Daitan Blocked Unblock Seguir Seguindo 7 de janeiro

Por Bruno Schionato, Diego Domingos, Fernando Moraes, Gustavo Rozato, Isac Souza, Marciano Nardi, Thalles Silva – Grupo Daitan

Na última vez, conversamos sobre como implantar modelos de aprendizado de máquina (ML) na produção usando o AWS Lambda . Seguindo nossos planos, damos um passo adiante e investigamos soluções mais completas. Neste post, voltamos nossa atenção para o Amazon SageMaker.

O SageMaker é uma plataforma para desenvolvimento e implementação de modelos ML. Ele promete facilitar o processo de treinamento e implantação de modelos para produção em escala.

Para atingir esse objetivo, oferece serviços que visam resolver os vários estágios do pipeline da ciência de dados, como:

  • Coleta e armazenamento de dados
  • Limpeza e preparação de dados
  • Treinamento e ajuste de modelos ML
  • Implantar na nuvem em escala

Com isso em mente, o SageMaker se posiciona como um serviço ML totalmente gerenciado.

O fluxo de trabalho típico para criar modelos ML envolve muitos passos. Neste contexto, o SageMaker pretende abstrair o processo de resolução de cada um destes estágios. De fato, como veremos, usando os algoritmos integrados da SageMaker, podemos implantar nossos modelos com uma simples linha de código.

O processo de treinamento, avaliação e implantação é feito usando os notebooks da Jupyter. O notebook Jupyter traz muitas vantagens. Dá liberdade para cientistas de dados experientes que já estão acostumados com a ferramenta. Além disso, também oferece flexibilidade para quem não tem muita experiência na área.

Em resumo, o SageMaker oferece muitos benefícios para quem deseja treinar e implantar modelos ML para produção. No entanto, o preço pode ser um problema.

Geralmente, o preço depende de como e onde você usa a infraestrutura da Amazon. Por razões óbvias, as instâncias de máquinas normais têm custos mais baixos do que as instâncias compatíveis com GPU. Observe que diferentes regiões têm preços diferentes. Além disso, a Amazon agrupa as máquinas para diferentes tarefas: construção, treinamento e implantação. Você pode encontrar a tabela de preços completa aqui .

Para treinamento, o SageMaker oferece muitos dos mais populares algoritmos ML incorporados. Alguns deles incluem K-Means, PCA, modelos de Sequência, Linear Learners e XGBoost. Além disso, a Amazon promete um excelente desempenho nessas implementações.

Além disso, se você quiser treinar um modelo usando uma biblioteca de terceiros, como o Keras, o SageMaker também lhe dará cobertura. Na verdade, ele suporta os frameworks ML mais populares. Alguns deles incluem:

Faça check- out desses exemplos usando o Tensorflow Estimators API e o Apache MXNet .

SageMaker – uma breve visão geral

Para entender como o SageMaker funciona, dê uma olhada no diagrama a seguir. Digamos que você queira treinar uma Rede Neural de Convolução Profunda simples (CNN) usando o Tensorflow.

A primeira caixa “Model Files” representa os arquivos de definição da CNN. Esta é a arquitetura do seu modelo. Convoluções, agrupamento e camadas densas, por exemplo, vão para lá. Note que, aqui, tudo é desenvolvido usando a estrutura de escolha – Tensorflow, neste caso.

Em segundo lugar, prosseguimos treinando o modelo usando essa estrutura. Para fazer isso, a Amazon lança as instâncias de computação ML e usa o código de treinamento e o conjunto de dados para realizar o processo de treinamento. Em seguida, salva os artefatos do modelo final e outra saída em um bucket S3 especificado. Observe que podemos aproveitar o treinamento paralelo. Isso pode ser feito via paralelismo de instância ou por ter máquinas com capacidade de GPU.

Usando os artefatos do modelo e um protocolo simples, ele cria um modelo SageMaker. Por fim, esse modelo pode ser implementado em um terminal com opções referentes ao número e ao tipo de instâncias nas quais implementar o modelo.

O SageMaker também possui um mecanismo muito interessante para ajustar modelos ML – o Automatic Model Tuning. Normalmente, ajustar modelos ML é uma tarefa consumidora de tempo e computacional. A razão é que as técnicas disponíveis dependem de métodos de força bruta, como busca de grade ou Pesquisa aleatória.

Para dar um exemplo, usando o Automatic Model Tuning, podemos selecionar um subconjunto de otimizadores possíveis, digamos Adam e / ou SGD, e alguns valores para a taxa de aprendizado. Em seguida, o mecanismo cuidará das combinações possíveis e se concentrará no conjunto de parâmetros que produz os melhores resultados.

Além disso, este processo é dimensionado. Podemos escolher o número de trabalhos a serem executados em paralelo, juntamente com o número máximo de trabalhos a serem executados. Depois disso, o Auto Tuning fará o trabalho. Esse recurso funciona com bibliotecas de terceiros e algoritmos internos. Observe que a Amazon fornece ajuste automático de modelo sem custo adicional.

Que tal usar os recursos de implantação do SageMaker para atender a um modelo pré-treinado? Isso mesmo, você pode treinar um novo modelo usando o Amazon Cloud ou usá-lo para servir um modelo pré-existente. Em outras palavras, você pode aproveitar a parte de serviço do SageMaker para implantar modelos que foram treinados fora dele.

Treinamento e implantação no SageMaker

Como sabemos, o SageMaker oferece uma variedade de estimadores ML populares. Também permite a possibilidade de obter um modelo pré-treinado e implementá-lo. No entanto, com base em nossos experimentos, é muito mais fácil usar suas implementações internas. O motivo é que para implantar modelos de terceiros usando as APIs do SageMaker, é preciso lidar com o gerenciamento de contêineres.

Assim, aqui colocamos o desafio de lidar com o pipeline ML completo usando o SageMaker. Vamos usá-lo das tarefas mais básicas para as mais avançadas. Algumas das tarefas envolvem:

  • Fazendo upload do conjunto de dados para um bucket S3
  • Pré-processamento do conjunto de dados para treinamento
  • Treinando e implantando o modelo

Tudo é feito na nuvem.

Como no post anterior, vamos ajustar um modelo linear usando o conjunto de dados de intrusão do KDD99. Você pode encontrar mais detalhes sobre o conjunto de dados e as etapas de pré-processamento deste artigo .

Todo o processo de treinamento e implantação do modelo é feito usando a interface de notebook Jupyter da SageMaker. Ele não precisa de nenhuma configuração e o notebook é executado em uma instância do EC2 de sua escolha. Aqui, escolhemos uma instância do EC2 ml.m4.xlarge para hospedar o notebook. Tivemos problemas ao carregar o conjunto de dados do KDD99 usando uma instância menos poderosa (devido à falta de espaço).

Dê uma olhada nas configurações das máquinas EC2:

Para ajustar modelos lineares, o SageMaker possui o algoritmo Linear Learner . Ele fornece uma solução para classificação e regressão. Com poucas linhas, podemos definir e ajustar o modelo no conjunto de dados.

Dê uma olhada na classe Estimator. É uma classe base que encapsula todos os diferentes algoritmos integrados do SageMaker. Entre outros parâmetros, alguns dos mais importantes incluem:

  • image_name: a imagem do contêiner a ser usada para treinamento.
  • train_instance_count: número de instâncias do EC2 usadas para treinamento.
  • train_instance_type: o tipo de instância do EC2 a ser usado para treinamento.
  • output_path: localização do S3 para salvar o resultado do treinamento.

Para definir que tipo de modelo queremos usar, definimos o parâmetro 'image_name' como 'linear-learner'. Para executar o procedimento de treinamento, escolhemos uma instância do EC2 ml.c4.xlarge . Tem 4 CPUs virtuais e 7,5 GB de RAM.

Os hiper-parâmetros do modelo incluem:

  • feature_dim: as dimensões de entrada
  • predictor_type: se classificação ou regressão
  • mini_batch_size: quantas amostras usar por etapa.

Finalmente, o SageMaker fornece uma API baseada em scikit-learn muito parecida para treinamento. Basta ligar para a função fit () e você está no negócio.

Agora vem a parte final – implantação. Para fazer isso, muito parecido com o treinamento, apenas executamos uma linha de código.

Essa rotina cuidará da implantação do modelo treinado em um endpoint da Amazon. Observe que precisamos especificar o tipo de instância que queremos, neste caso, uma instância do EC2 ml.m4.xlarge . Além disso, podemos definir um número mínimo de instâncias do EC2 para implantar nosso modelo. Para fazer isso, basta definir o parâmetro initial_instance_count para um valor maior que 1.

Auto Scaling

Nós temos dois objetivos principais com os testes.

  • Avaliar o pipeline completo de ML oferecido pela SageMaker
  • Para avaliar o treinamento e implantar a escalabilidade.

Em todos os testes, usamos a ferramenta SageMaker Auto Scaling. Como veremos, ajuda a controlar o trade-off de tráfego / instâncias.

Conforme indicado no site da AWS:

O AWS Auto Scaling monitora seus aplicativos e ajusta automaticamente a capacidade para manter um desempenho estável e previsível com o menor custo possível.

Em suma, o SageMaker Auto Scaling facilita a criação de planos de dimensionamento para vários recursos em muitos serviços. Esses serviços incluem Amazon EC2, Spot Fleets, tarefas do Amazon ECS e muito mais. A ideia é ajustar o número de instâncias em execução em resposta a alterações na carga de trabalho.

É importante observar que o Auto Scaling pode falhar em algumas situações. Mais especificamente, quando seu aplicativo sofre algum tipo de aumento de tráfego, o Auto Scaling pode não ajudar em nada. Sabemos que para novas instâncias (EC2), a Amazon precisa de algum tempo para configurar e configurar a máquina antes de poder processar solicitações. Com base em nossos experimentos, esse tempo de configuração pode levar de 5 a 7 minutos. Se o seu aplicativo tiver pequenos picos (digamos, de 2 a 4 minutos) no número de solicitações recebidas, no momento em que o tempo de configuração da instância do EC2 for concluído, a necessidade de mais poder de computação pode acabar.

Para resolver essa situação, a Amazon implementa uma política simples para dimensionar novas instâncias. Basicamente, depois de uma decisão de escalonamento, um período de esfriamento deve ser satisfeito antes que ocorra outra atividade de escala. Em outras palavras, cada ação para emitir uma nova instância é intercalada por um período de tempo fixo (configurável). Este mecanismo visa aliviar a sobrecarga para lançar uma nova máquina.

Além disso, se seu aplicativo tiver tráfego de usuário bem definido / previsível, o Auto Scaling também pode ser uma má escolha. Suponha que você hospede o site de um aplicativo. Você sabe que, em um horário específico, os aplicativos estarão abertos para centenas de milhões de usuários. Nessa situação, o tempo necessário para que o Auto Scaling seja configurado corretamente pode resultar em uma experiência de usuário ruim.

Resultados

Usamos Tauros e JMeter para executar testes de carga em nosso modelo ML desenvolvido com o Amazon SageMaker.

O primeiro cenário é definido da seguinte maneira:

  • Número de usuários simultâneos: 1000
  • Tempo de aceleração de 10 minutos
  • Tempo de espera de 10 minutos

Simplificando, o teste consiste em emitir solicitações de 1.000 usuários paralelos. Na primeira parte do teste (primeiros 10 minutos) o número de usuários é escalado de 0 a 1000 (aumento). Depois, os 1000 usuários continuam a enviar solicitações paralelas por mais 10 minutos (espera por período). Observe que cada usuário envia solicitações de maneira serial. Ou seja, para emitir um novo pedido, o usuário deve aguardar até que o atual termine.

Para os primeiros testes, decidimos usar uma única máquina. Como resultado, não definimos nenhum plano de dimensionamento que criasse novas instâncias ao atingir algum critério.

No gráfico abaixo, a linha azul (aumentando em uma forma de escada) é o número de usuários paralelos. A linha laranja representa o tempo médio de resposta e a linha verde o número de solicitações.

No início, o número de usuários varia de 0 a 1000. Conforme esperado, o número de solicitações emitidas para o modelo aumenta de maneira semelhante.

Na última parte do experimento (últimos 10 minutos), o número de acessos / solicitações e o tempo médio de resposta permanecem estáveis. Isto sugere que esta máquina única parece ser capaz de lidar com a carga útil atual.

Além disso, essa única máquina conseguiu processar uma solicitação média geral de 961,3 hits / s. Na verdade, depois de atingir o número máximo de usuários simultâneos (1000), essa média foi de quase 1200 solicitações / segundo.

Para acessar ainda mais nossa hipótese, decidimos adicionar um plano de escala aos nossos testes de carregamento. Aqui, quando o número de solicitações paralelas / minuto atinge a marca de 30k, instruímos o sistema a aumentar o número de instâncias em execução. Para todos os testes, o número máximo de instâncias foi definido como 10. No entanto, em todos os casos, o SageMaker Auto Scaling não utilizou todos os recursos disponíveis.

Para o teste abaixo, o Amazon Auto Scaling emitiu apenas mais uma instância para ajudar no processamento da carga útil atual. Isso é representado pela linha vermelha na figura de utilização da CPU abaixo.

No entanto, a adição dessa nova instância foi capaz de aumentar a taxa de transferência e reduzir a latência. Isso é perceptível após o tempo de 15h48.

Para acessar melhor a ferramenta Auto Scaling, decidimos reduzir o número limite de solicitações / minuto antes de dimensionar. Agora, o escalonamento automático é recomendado para iniciar uma nova instância assim que a taxa de transferência atingir 15 mil solicitações por minuto. Como consequência, o Auto Scale usou um total de 4 instâncias para corresponder ao plano de dimensionamento. Também é bastante intuitivo ver que à medida que o número de instâncias aumenta, o uso percentual da CPU diminui.

Percebemos que no início de todos os testes, tivemos um grande aumento na latência. Nossos experimentos sugerem que esse alto valor médio é causado pelo próprio teste (Taurus / JMeter) aquecendo e preparando recursos. Observe que, após o pico, o tempo de resposta diminui rapidamente para valores normais. Mais tarde, aumenta junto com o número de usuários virtuais (conforme esperado). Além disso, esse pico inicial não é visto nas estatísticas de latência do gateway da API ou do SageMaker – o que dá suporte aos nossos pensamentos iniciais.

Além disso, especificamente para este teste e escolha de modelo, o Auto Scale não foi muito eficaz. O motivo é que a quantidade de carga que estamos realizando no servidor é totalmente gerenciada por uma única máquina.

Conclusão

Aqui estão algumas das nossas observações sobre o SageMaker:

  • Ele oferece uma interface muito limpa e fácil de usar. Os notebooks da Jupyter oferecem muitas vantagens e os algoritmos integrados são fáceis de usar (API baseada no scikit-learn). Além disso, as máquinas usadas para treinamento são faturadas apenas quando o treinamento é feito. Nenhum pagamento por tempo ocioso 🙂
  • Ele tira muitas das tarefas chatas do ML. O dimensionamento automático e o ajuste automático de hiper-parâmetros são excelentes recursos.
  • Se estiver usando os algoritmos internos, a implantação é muito direta. Apenas uma linha de código.