Como Logz.io acelera recomendações de ML e soluções de detecção de anomalias com Amazon SageMaker

Republicado por Platão

seguidores: 0

Logz.io é um parceiro de tecnologia avançada da AWS Partner Network (APN) com Competências da AWS em DevOps, segurança e dados e análises. Logz.io oferece uma plataforma de observabilidade de software como serviço (SaaS) baseada nas melhores soluções de software de código aberto para análises de log, métricas e rastreamento. Os clientes estão enviando uma quantidade cada vez maior de dados de diversas fontes de dados para o Logz.io para gerenciar a integridade e o desempenho de seus aplicativos e serviços. Pode ser complicado para novos usuários que desejam navegar pelos vários painéis criados ao longo do tempo, processar diferentes notificações de alerta e conectar os pontos ao solucionar problemas de produção.

O tempo médio de detecção (MTTD) e o tempo médio de resolução (MTTR) são métricas importantes para nossos clientes. Eles são calculados medindo o tempo que um usuário em nossa plataforma começa a investigar um problema (como inatividade do serviço de produção) até o ponto em que ele para de realizar ações na plataforma relacionadas à investigação específica.

Para ajudar os clientes a reduzir MTTD e MTTR, a Logz.io está recorrendo ao aprendizado de máquina (ML) para fornecer recomendações para painéis e consultas relevantes e realizar detecção de anomalias por meio de autoaprendizagem. Como resultado, o usuário médio fica equipado com a experiência agregada de toda a empresa, aproveitando a sabedoria de muitos. Descobrimos que nossa solução pode reduzir o MTTR em até 20%.

À medida que o MTTD diminui, os usuários podem identificar o problema e resolvê-lo mais rapidamente. Nossa camada semântica de dados contém a semântica para iniciar e interromper uma investigação e a popularidade de cada ação que o usuário realiza em relação a um alerta específico.

Neste post, compartilhamos como Logz.io usou Amazon Sage Maker para reduzir o tempo e o esforço para nossa prova de conceito (POC), experimentos desde a pesquisa até a avaliação da produção e como reduzimos nosso custo de inferência de produção.

O desafio

Até o Logz.io usar o SageMaker, o tempo entre a pesquisa, os testes POC e os experimentos em produção era bastante longo. Isso ocorreu porque precisávamos criar jobs do Spark para coletar, limpar e normalizar os dados. O DevOps exigia esse trabalho para ler cada fonte de dados. As habilidades de DevOps e engenharia de dados não fazem parte de nossa equipe de ML e isso causou uma grande dependência entre as equipes.

Outro desafio foi fornecer um serviço de inferência de ML para nossos produtos e, ao mesmo tempo, alcançar a relação custo x desempenho ideal. Nosso cenário ideal é suportar o maior número possível de modelos para uma unidade de computação, ao mesmo tempo em que fornece alta simultaneidade de clientes com muitos modelos. Tivemos flexibilidade em nosso tempo de inferência, pois nossa janela inicial do fluxo de dados para o serviço de inferência é de 5 minutos de intervalo de logs.

Fase de pesquisa

A ciência de dados é um processo iterativo que requer um ambiente de desenvolvimento interativo para pesquisa, validando a saída de dados em cada iteração e processamento de dados. Portanto, incentivamos nossos pesquisadores de ML a usar notebooks.

Para acelerar o ciclo de iteração, queríamos testar o código dos nossos notebooks em dados reais de produção, enquanto o executávamos em escala. Além disso, queríamos evitar o gargalo do DevOps e da engenharia de dados durante o teste inicial em produção, ao mesmo tempo que tínhamos a capacidade de visualizar os resultados e tentar estimar o tempo de execução do código.

Para implementar isso, queríamos fornecer à nossa equipe de ciência de dados controle total e responsabilidade de ponta a ponta, desde a pesquisa até o teste inicial na produção. Precisávamos que eles extraíssem dados com facilidade, preservando ao mesmo tempo o gerenciamento de acesso aos dados e monitorando esse acesso. Eles também precisavam implantar facilmente seus notebooks POC personalizados na produção de maneira escalonável, enquanto monitoravam o tempo de execução e os custos esperados.

Fase de avaliação

Durante esta fase, avaliamos algumas plataformas de ML para atender aos requisitos de treinamento e atendimento. Descobrimos que o SageMaker é o mais apropriado para nossos casos de uso porque oferece suporte tanto para treinamento quanto para inferência. Além disso, é personalizável, para que possamos adaptá-lo de acordo com nosso processo de pesquisa preferido.

Inicialmente, partimos de notebooks locais, testando diversas bibliotecas. Tivemos problemas ao extrair dados massivos da produção. Mais tarde, ficamos presos em um ponto da fase de modelagem que demorava muitas horas em uma máquina local.

Avaliamos muitas soluções e finalmente escolhemos a seguinte arquitetura:

Placa de dados – A versão de código aberto do Placa de dados nos ajudou a extrair e unir nossos dados facilmente utilizando nosso Spark Amazon EMR clusters com um SQL simples, enquanto monitora o acesso aos dados
Instância de notebook SageMaker e trabalhos de processamento – Isso nos ajudou com a escalabilidade do tempo de execução e flexibilidade dos tipos de máquinas e estruturas de ML, ao mesmo tempo em que colaboramos com nosso código por meio de uma conexão Git

Arquitetura da solução da fase de pesquisa

O diagrama a seguir ilustra a arquitetura da solução da fase de pesquisa e consiste nos seguintes componentes:

Cadernos SageMaker – Os cientistas de dados usam estes laptops para conduzir suas pesquisas.
Função AWS Lambda - AWS Lambda é uma solução sem servidor que executa um trabalho de processamento sob demanda. O trabalho usa um contêiner Docker com o notebook que queremos executar durante nosso experimento, junto com todos os nossos arquivos comuns que precisam dar suporte ao notebook (requirements.txt e o código das funções de multiprocessamento em um notebook separado).
ECR da Amazon - Registro do Amazon Elastic Container (Amazon ECR) armazena nosso contêiner Docker.
Trabalho de processamento SageMaker – Podemos executar isso trabalho de processamento de dados em qualquer máquina de ML e executa nosso notebook com parâmetros.
Placa de dados – Este serviço nos ajuda a usar SQL e juntar facilmente várias fontes de dados. Ele o traduz para o código Spark e o otimiza, ao mesmo tempo em que monitora o acesso aos dados e ajuda a reduzir violações de dados. A versão Xtra oferece ainda mais recursos.
Amazon EMR – Este serviço executa nossas extrações de dados como cargas de trabalho no Spark, entrando em contato com todos os nossos recursos de dados.

Com o ciclo de vida da instância do notebook SageMaker, podemos controlar o tempo máximo de execução da instância do notebook, usando o autostop.py modelo script.

Depois de testar as estruturas de ML, escolhemos o kernel SageMaker MXNet para nossas fases de clustering e classificação.

Para testar o código do notebook em nossos dados de produção, executamos o notebook encapsulando-o via Docker no Amazon ECS e executamos como um trabalho de processamento para validar o tempo de execução máximo em diferentes tipos de máquinas.

O contêiner Docker também nos ajuda a compartilhar recursos entre os testes dos notebooks. Em alguns casos, um notebook chama outros notebooks para utilizar um multiprocesso, dividindo grandes quadros de dados em quadros de dados menores, que podem ser executados simultaneamente em cada vCPU em um tipo de máquina grande.

A solução de inferência de produção em tempo real

Na fase de pesquisa, utilizamos Parquet Serviço de armazenamento simples da Amazon (Amazon S3) para manter nossas recomendações. Eles são consumidos uma vez por dia em nosso pipeline de engenharia para anexar as recomendações ao nosso mecanismo de alertas.

No entanto, nosso roteiro exige uma solução com taxa de atualização mais alta e extrair uma vez por dia não é suficiente no longo prazo, porque queremos fornecer recomendações mesmo durante a investigação.

Para implementar esta solução em escala, testamos a maioria das soluções de endpoint SageMaker em nossa pesquisa de detecção de anomalias. Testamos 500 modelos pré-construídos com uma única máquina de endpoint de vários tipos e usamos clientes multithread simultâneos para executar solicitações ao endpoint. Medimos o tempo de resposta, CPU, memória e outras métricas (para obter mais informações, consulte Monitore o Amazon SageMaker com o Amazon CloudWatch). Descobrimos que o endpoint multimodelo é perfeito para nossos casos de uso.

Um endpoint multimodelo pode reduzir nossos custos drasticamente em comparação com um único endpoint ou mesmo Kubernetes para usar serviços da web Flask (ou outros Python). Nossa primeira suposição foi que deveríamos fornecer um único endpoint, usando uma pequena máquina com 4 vCPUs, para cada cliente e, em média, consultar quatro modelos dedicados, porque cada vCPU atende a um modelo. Com o endpoint multimodelo, poderíamos agregar mais clientes em uma única máquina multiendpoint.

Tínhamos um modelo e arquivos de codificação por cliente e, após fazer testes de carga, determinamos que poderíamos atender 50 clientes, cada um usando 10 modelos e até mesmo usando a menor instância ml.t2.medium para nossas soluções.

Nesta etapa, pensamos em usar endpoints multi-modelo. Os endpoints multimodelos fornecem uma solução escalável e econômica para implantar um grande número de modelos, permitindo hospedar vários modelos com um único contêiner de inferência. Isso reduz os custos de hospedagem, melhorando a utilização do endpoint em comparação ao uso de vários endpoints pequenos de modelo único, cada um atendendo a um único cliente. Ele também reduz a sobrecarga de implantação porque o SageMaker gerencia o carregamento de modelos na memória e o dimensiona com base nos padrões de tráfego para eles.

Além disso, a vantagem do endpoint multimodelo é que se você tiver uma alta taxa de inferência de clientes específicos, sua estrutura preserva os últimos modelos de serviço na memória para melhor desempenho.

Depois de estimarmos os custos usando endpoints multimodelos versus endpoints padrão, descobrimos que isso poderia levar a uma redução de custos de aproximadamente 80%.

O efeito

Nesta seção, revisamos as etapas e o resultado do processo.

Usamos a configuração do notebook de ciclo de vida para permitir a execução dos notebooks como trabalhos de processamento, encapsulando o notebook em um contêiner Docker para validar o código mais rapidamente e usar o mecanismo autostop:

#!/bin/bash # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License"). You
# may not use this file except in compliance with the License. A copy of
# the License is located at
#
# http://aws.amazon.com/apache2.0/
#
# or in the "license" file accompanying this file. This file is
# distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
# ANY KIND, either express or implied. See the License for the specific
# language governing permissions and limitations under the License. set -e # OVERVIEW
# This script installs the sagemaker_run_notebook extension package in SageMaker Notebook Instance
#
# There are two parameters you need to set:
# 1. S3_LOCATION is the place in S3 where you put the extension tarball
# 2. TARBALL is the name of the tar file that you uploaded to S3. You should just need to check
# that you have the version right.
sudo -u ec2-user -i <<'EOF'
# PARAMETERS
VERSION=0.18.0
EXTENSION_NAME=sagemaker_run_notebook
# Set up the user setting and workspace directories
mkdir -p /home/ec2-user/SageMaker/.jupyter-user/{workspaces,user-settings}
# Run in the conda environment that the Jupyter server uses so that our changes are picked up
source /home/ec2-user/anaconda3/bin/activate JupyterSystemEnv
# Install the extension and rebuild JupyterLab so it picks up the new UI
aws s3 cp s3://aws-emr-resources-11111111-us-east-1/infra-sagemaker/sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz ./sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz
pip install sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz jupyter lab build
source /home/ec2-user/anaconda3/bin/deactivate
EOF # sudo -u ec2-user -i <<'EOF'
# PARAMETERS
for PACKAGE in pandas dataplate awswrangler==2.0.0 ipynb==0.5.1 prison==0.1.3 PyMySQL==0.10.1 requests==2.25.0 scipy==1.5.4 dtaidistance joblib sagemaker_run_notebook-0.18.0-Logz-latest.tar.gz fuzzywuzzy==0.18.0; do echo $PACKAGE # Note that "base" is special environment name, include it there as well. for env in base /home/ec2-user/anaconda3/envs/*; do source /home/ec2-user/anaconda3/bin/activate $(basename "$env") if [ $env = 'JupyterSystemEnv' ]; then continue fi pip install --upgrade "$PACKAGE" source /home/ec2-user/anaconda3/bin/deactivate done
done
jupyter lab build # Tell Jupyter to use the user-settings and workspaces directory on the EBS
# volume.
echo "export JUPYTERLAB_SETTINGS_DIR=/home/ec2-user/SageMaker/.jupyter-user/user-settings" >> /etc/profile.d/jupyter-env.sh
echo "export JUPYTERLAB_WORKSPACES_DIR=/home/ec2-user/SageMaker/.jupyter-user/workspaces" >> /etc/profile.d/jupyter-env.sh # The Jupyter server needs to be restarted to pick up the server part of the
# extension. This needs to be done as root.
initctl restart jupyter-server --no-wait # OVERVIEW
# This script stops a SageMaker notebook once it's idle for more than 2 hour (default time)
# You can change the idle time for stop using the environment variable below.
# If you want the notebook the stop only if no browsers are open, remove the --ignore-connections flag
#
# Note that this script will fail if either condition is not met
# 1. Ensure the Notebook Instance has internet connectivity to fetch the example config
# 2. Ensure the Notebook Instance execution role permissions to SageMaker:StopNotebookInstance to stop the notebook
# and SageMaker:DescribeNotebookInstance to describe the notebook.
# PARAMETERS
IDLE_TIME=3600 echo "Fetching the autostop script"
wget https://raw.githubusercontent.com/aws-samples/amazon-sagemaker-notebook-instance-lifecycle-config-samples/master/scripts/auto-stop-idle/autostop.py echo "Starting the SageMaker autostop script in cron" (crontab -l 2>/dev/null; echo "*/5 * * * * /usr/bin/python $PWD/autostop.py --time $IDLE_TIME --ignore-connections") | crontab -

Nós clonamos o sagemaker-run-notebook Projeto GitHub e adicione o seguinte ao contêiner:

Nossos requisitos de pip
A capacidade de executar notebooks de dentro de um notebook, o que nos permite um comportamento de multiprocessamento para utilizar todos os núcleos de instância ml.m5.12xlarge

Isso nos permite executar fluxos de trabalho que consistem em muitos notebooks executados como trabalhos de processamento em uma linha de código, enquanto definimos o tipo de instância a ser executado.

Como podemos adicionar parâmetros ao notebook, podemos dimensionar nosso processamento executando simultaneamente em diferentes horas, dias ou meses para extrair e processar dados.

Também podemos criar jobs de agendamento que executam notebooks (e até mesmo limitar o tempo de execução).

Também podemos observar as últimas execuções e seus detalhes, como o tempo de processamento.

Com a fábrica de papel que é utilizada no container, podemos visualizar o resultado de cada tiragem, o que nos ajuda a depurar na produção.

Nossa análise de saída de notebook está na forma de um notebook padrão somente leitura.

A utilização de multiprocessamento nos ajuda a dimensionar o processamento de cada notebook e a utilizar todos os seus núcleos. Geramos funções em outros notebooks que podem realizar processamento pesado, como as seguintes:

Explodir JSONs
Encontre linhas relevantes em um DataFrame enquanto o notebook principal divide o DataFrame em #cpu-cores elementos
Execute ações de clustering por tipo de alerta simultaneamente

Em seguida, adicionamos esses notebooks funcionais ao contêiner que executa o notebook como um trabalho de processamento. Veja o seguinte arquivo Docker (observe os comandos COPY):

ARG BASE_IMAGE=need_an_image
FROM $BASE_IMAGE ENV JUPYTER_ENABLE_LAB yes
ENV PYTHONUNBUFFERED TRUE COPY requirements.txt /tmp/requirements.txt
RUN pip install papermill jupyter nteract-scrapbook boto3 requests==2.20.1
RUN pip install -r /tmp/requirements.txt ENV PYTHONUNBUFFERED=TRUE
ENV PATH="/opt/program:${PATH}" # Set up the program in the image
COPY multiprocessDownloadNormalizeFunctions.ipynb /tmp/multiprocessDownloadNormalizeFunctions.ipynb
COPY multiprocessFunctions.ipynb /tmp/multiprocessFunctions.ipynb
COPY run_notebook execute.py /opt/program/
ENTRYPOINT ["/bin/bash"] # because there is a bug where you have to be root to access the directories
USER root

Resultados

Durante a fase de pesquisa, avaliamos a opção de executar nossos notebooks como estão, para experimentar e avaliar o desempenho de nosso código em todos os nossos dados relevantes, não apenas em uma amostra de dados. Descobrimos que encapsular nossos notebooks usando trabalhos de processamento pode ser uma ótima opção para nós, porque não precisamos reescrever o código e podemos utilizar o poder das instâncias otimizadas para computação e memória da AWS e acompanhar facilmente o status do processo.

Durante a avaliação de inferência, avaliamos várias soluções de endpoint SageMaker. Descobrimos que o uso de um endpoint multimodelo pode nos ajudar a atender aproximadamente 50 clientes, cada um com vários (aproximadamente 10) modelos em uma única instância, o que pode atender às nossas restrições de baixa latência e, portanto, economizar até 80% do custo .

Com esta arquitetura de solução, conseguimos reduzir o MTTR dos nossos clientes, que é uma métrica principal para medir o sucesso na utilização da nossa plataforma. Isso reduz o tempo total desde a resposta ao nosso link de alerta, que descreve um problema em seus sistemas, até quando você termina de investigar o problema usando nossa plataforma. Durante a fase de investigação, medimos as ações dos usuários com e sem nossa solução de recomendação de ML. Isso nos ajuda a fornecer recomendações sobre a melhor ação para resolver o problema específico com mais rapidez e identificar anomalias para identificar a causa real do problema.

Conclusão e próximas etapas

Neste post, compartilhamos como Logz.io usou o SageMaker para melhorar o MTTD e o MTTR.

Como próximo passo, estamos considerando expandir a solução com os seguintes recursos:

Nós encorajamos você a experimentar Cadernos SageMaker. Para mais exemplos, confira o Exemplos do SageMaker repositório GitHub.

Sobre os autores

Amit Gross lidera o departamento de Pesquisa da Logz.io, responsável pelas soluções de IA de todos os produtos Logz.io, desde a fase de pesquisa até a fase de integração. Antes da Logz.io, Amit gerenciou grupos de pesquisa de ciência de dados e segurança na Here inc. e Cellebrite Inc. Amit possui mestrado em ciência da computação pela Universidade de Tel-Aviv.

Yaniv Vaknin é especialista em aprendizado de máquina na Amazon Web Services. Antes da AWS, Yaniv ocupou cargos de liderança em startups de IA e empresas, incluindo cofundador e CEO da Dipsee.ai. Yaniv trabalha com clientes da AWS para aproveitar o poder do aprendizado de máquina para resolver tarefas do mundo real e gerar valor. Nas horas vagas, Yaniv gosta de jogar futebol com os meninos.

Eitan Sela é um arquiteto de soluções especialista em aprendizado de máquina da Amazon Web Services. Ele trabalha com clientes da AWS para fornecer orientação e assistência técnica, ajudando-os a criar e operar soluções de machine learning na AWS. Em seu tempo livre, Eitan gosta de correr e ler os artigos mais recentes de aprendizado de máquina.