Cómo Logz.io acelera las recomendaciones de ML y las soluciones de detección de anomalías con Amazon SageMaker

Reeditado por Platón

seguidores: 0

logz.io es un socio de tecnología avanzada de la red de socios de AWS (APN) con Competencias de AWS en DevOps, seguridad y datos y análisis. Logz.io ofrece una plataforma de observabilidad de software como servicio (SaaS) basada en las mejores soluciones de software de código abierto de su clase para análisis de registros, métricas y seguimiento. Los clientes envían una cantidad cada vez mayor de datos a Logz.io desde varias fuentes de datos para administrar el estado y el rendimiento de sus aplicaciones y servicios. Puede ser abrumador para los nuevos usuarios que buscan navegar a través de los diversos paneles creados a lo largo del tiempo, procesar diferentes notificaciones de alerta y conectar los puntos al solucionar problemas de producción.

El tiempo medio de detección (MTTD) y el tiempo medio de resolución (MTTR) son métricas clave para nuestros clientes. Se calculan midiendo el tiempo que un usuario de nuestra plataforma comienza a investigar un problema (como la caída del servicio de producción) hasta el punto en que deja de realizar acciones en la plataforma que están relacionadas con la investigación específica.

Para ayudar a los clientes a reducir el MTTD y el MTTR, Logz.io está recurriendo al aprendizaje automático (ML) para proporcionar recomendaciones para paneles y consultas relevantes y realizar la detección de anomalías a través del autoaprendizaje. Como resultado, el usuario promedio está equipado con la experiencia agregada de toda su empresa, aprovechando la sabiduría de muchos. Descubrimos que nuestra solución puede reducir el MTTR hasta en un 20 %.

A medida que disminuye el MTTD, los usuarios pueden identificar el problema y resolverlo más rápido. Nuestra capa semántica de datos contiene semántica para iniciar y detener una investigación, y la popularidad de cada acción que el usuario está realizando con respecto a una alerta específica.

En esta publicación, compartimos cómo usó Logz.io Amazon SageMaker para reducir el tiempo y el esfuerzo de nuestra prueba de concepto (POC), los experimentos desde la investigación hasta la evaluación de la producción, y cómo redujimos nuestro costo de inferencia de producción.

El desafío

Hasta que Logz.io usó SageMaker, el tiempo entre la investigación y las pruebas POC y los experimentos en producción era bastante largo. Esto se debió a que necesitábamos crear trabajos de Spark para recopilar, limpiar y normalizar los datos. DevOps requirió este trabajo para leer cada fuente de datos. Las habilidades de ingeniería de datos y DevOps no forman parte de nuestro equipo de ML, y esto provocó una gran dependencia entre los equipos.

Otro desafío fue brindar un servicio de inferencia de ML a nuestros productos y al mismo tiempo lograr una relación costo-rendimiento óptima. Nuestro escenario óptimo es admitir tantos modelos como sea posible para una unidad informática, al tiempo que proporciona una alta concurrencia de clientes con muchos modelos. Tuvimos flexibilidad en nuestro tiempo de inferencia, porque nuestra ventana inicial del flujo de datos para el servicio de inferencia es un cubo de registros de 5 minutos.

Fase de investigación

La ciencia de datos es un proceso iterativo que requiere un entorno de desarrollo interactivo para la investigación, validando la salida de datos en cada iteración y procesamiento de datos. Por lo tanto, alentamos a nuestros investigadores de ML a usar cuadernos.

Para acelerar el ciclo de iteración, queríamos probar el código de nuestros portátiles en datos de producción reales, mientras lo ejecutamos a escala. Además, queríamos evitar el cuello de botella de DevOps y la ingeniería de datos durante la prueba inicial en producción, mientras teníamos la capacidad de ver los resultados e intentábamos estimar el tiempo de ejecución del código.

Para implementar esto, queríamos brindarle a nuestro equipo de ciencia de datos control total y responsabilidad integral desde la investigación hasta la prueba inicial en producción. Los necesitábamos para extraer datos fácilmente, al mismo tiempo que preservamos la gestión del acceso a los datos y monitoreamos este acceso. También necesitaban implementar fácilmente sus computadoras portátiles POC personalizadas en producción de manera escalable, mientras monitoreaban el tiempo de ejecución y los costos esperados.

Fase de evaluación

Durante esta fase, evaluamos algunas plataformas de ML para admitir los requisitos de capacitación y servicio. Descubrimos que SageMaker es el más apropiado para nuestros casos de uso porque admite tanto el entrenamiento como la inferencia. Además, es personalizable, por lo que podemos adaptarlo de acuerdo con nuestro proceso de investigación preferido.

Inicialmente, partimos de cuadernos locales, probando varias bibliotecas. Nos encontramos con problemas al extraer datos masivos de producción. Más tarde, nos quedamos atrapados en un punto de la fase de modelado que tomó muchas horas en una máquina local.

Evaluamos muchas soluciones y finalmente elegimos la siguiente arquitectura:

Placa de datos – La versión de código abierto de Placa de datos nos ayudó a extraer y unir nuestros datos fácilmente utilizando nuestro Spark EMR de Amazon clústeres con un SQL simple, mientras se monitorea el acceso a los datos
Instancia de notebook de SageMaker y trabajos de procesamiento – Esto nos ayudó con la escalabilidad del tiempo de ejecución y la flexibilidad de los tipos de máquinas y los marcos de ML, mientras colaboramos con nuestro código a través de una conexión Git.

Arquitectura de la solución de la fase de investigación

El siguiente diagrama ilustra la arquitectura de la solución de la fase de investigación y consta de los siguientes componentes:

Cuadernos SageMaker – Los científicos de datos usan estos ordenadores portátiles para realizar su investigación.
Función AWS Lambda – AWS Lambda es una solución sin servidor que ejecuta un trabajo de procesamiento bajo demanda. El trabajo usa un contenedor Docker con el cuaderno que queremos ejecutar durante nuestro experimento, junto con todos nuestros archivos comunes que necesitan ser compatibles con el cuaderno (requirements.txt y el código de funciones de multiprocesamiento en un cuaderno aparte).
ECR de Amazon – Registro de contenedores elásticos de Amazon (Amazon ECR) almacena nuestro contenedor Docker.
Trabajo de procesamiento de SageMaker – Podemos ejecutar esto trabajo de procesamiento de datos en cualquier máquina ML, y ejecuta nuestro cuaderno con parámetros.
Placa de datos – Este servicio nos ayuda a usar SQL y unir varias fuentes de datos fácilmente. Lo traduce a código Spark y lo optimiza, al tiempo que supervisa el acceso a los datos y ayuda a reducir las filtraciones de datos. La versión Xtra proporcionó aún más capacidades.
EMR de Amazon – Este servicio ejecuta nuestras extracciones de datos como cargas de trabajo sobre Spark, contactando todos nuestros recursos de datos.

Con el ciclo de vida de la instancia de notebook de SageMaker, podemos controlar el tiempo máximo de ejecución de la instancia de notebook, usando el autostop.py plantilla guión.

Después de probar los marcos de ML, elegimos el kernel SageMaker MXNet para nuestras fases de agrupación y clasificación.

Para probar el código del cuaderno en nuestros datos de producción, ejecutamos el cuaderno encapsulándolo a través de Docker en Amazon ECS y lo ejecutamos como un trabajo de procesamiento para validar el tiempo de ejecución máximo en diferentes tipos de máquinas.

El contenedor Docker también nos ayuda a compartir recursos entre las pruebas de los portátiles. En algunos casos, una notebook llama a otras notebooks para utilizar un multiproceso mediante la división de marcos de datos grandes en marcos de datos más pequeños, que pueden ejecutarse simultáneamente en cada vCPU en un tipo de máquina grande.

La solución de inferencia de producción en tiempo real

En la fase de investigación, utilizamos Parquet Servicio de almacenamiento simple de Amazon (Amazon S3) archivos para mantener nuestras recomendaciones. Estos se consumen una vez al día desde nuestro canal de ingeniería para adjuntar las recomendaciones a nuestro mecanismo de alertas.

Sin embargo, nuestra hoja de ruta requiere una solución con una frecuencia de actualización más alta y extraer una vez al día no es suficiente a largo plazo, porque queremos brindar recomendaciones incluso durante la investigación.

Para implementar esta solución a escala, probamos la mayoría de las soluciones de terminales de SageMaker en nuestra investigación de detección de anomalías. Probamos 500 de los modelos preconstruidos con una sola máquina de punto final de varios tipos y utilizamos clientes de subprocesos múltiples simultáneos para realizar solicitudes al punto final. Medimos el tiempo de respuesta, la CPU, la memoria y otras métricas (para obtener más información, consulte Monitoree Amazon SageMaker con Amazon CloudWatch). Descubrimos que el punto final multimodelo se adapta perfectamente a nuestros casos de uso.

Un punto final multimodelo puede reducir nuestros costos drásticamente en comparación con un punto final único o incluso Kubernetes para usar los servicios web de Flask (u otros Python). Nuestra primera suposición fue que debemos proporcionar un punto final único, usando una máquina pequeña de 4 vCPU, para cada cliente, y en promedio consultar cuatro modelos dedicados, porque cada vCPU sirve a un modelo. Con el punto final multimodelo, podríamos agregar más clientes en una sola máquina multipunto.

Teníamos un modelo y archivos de codificación por cliente, y después de hacer pruebas de carga, determinamos que podíamos atender a 50 clientes, cada uno usando 10 modelos e incluso usando la instancia más pequeña de ml.t2.medium para nuestras soluciones.

En esta etapa, consideramos utilizar puntos finales de varios modelos. Los terminales multimodelo brindan una solución escalable y rentable para implementar una gran cantidad de modelos, lo que le permite alojar múltiples modelos con un solo contenedor de inferencia. Esto reduce los costos de hospedaje al mejorar la utilización de puntos finales en comparación con el uso de varios puntos finales pequeños de un solo modelo, cada uno de los cuales atiende a un solo cliente. También reduce la sobrecarga de implementación porque SageMaker administra la carga de modelos en la memoria y los escala en función de los patrones de tráfico hacia ellos.

Además, la ventaja del punto final multimodelo es que si tiene una alta tasa de inferencia de clientes específicos, su marco conserva los últimos modelos de servicio en la memoria para un mejor rendimiento.

Después de estimar los costos usando terminales multimodelo en comparación con terminales estándar, descubrimos que potencialmente podría conducir a una reducción de costos de aproximadamente un 80 %.

El resultado

En esta sección, revisamos los pasos y el resultado del proceso.

Usamos la configuración del cuaderno de ciclo de vida para habilitar la ejecución de los cuadernos como trabajos de procesamiento, encapsulando el cuaderno en un contenedor Docker para validar el código más rápido y usar el mecanismo de parada automática:

#!/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 -

Clonamos el sagemaker-ejecutar-cuaderno proyecto de GitHub y agregue lo siguiente al contenedor:

Nuestros requisitos de pipa
La capacidad de ejecutar cuadernos desde dentro de un cuaderno, lo que nos permite un comportamiento de procesamiento múltiple para utilizar todos los núcleos de instancia ml.m5.12xlarge

Esto nos permite ejecutar flujos de trabajo que consisten en muchos cuadernos que se ejecutan como trabajos de procesamiento en una línea de código, mientras se define el tipo de instancia en el que se ejecutará.

Debido a que podemos agregar parámetros al cuaderno, podemos escalar nuestro procesamiento ejecutando simultáneamente en diferentes horas, días o meses para extraer y procesar datos.

También podemos crear trabajos de programación que ejecuten cuadernos (e incluso limitar el tiempo de ejecución).

También podemos observar las últimas ejecuciones y sus detalles, como el tiempo de procesamiento.

Con la fábrica de papel que se usa en el contenedor, podemos ver el resultado de cada ejecución, lo que nos ayuda a depurar la producción.

Nuestra revisión de la salida de la computadora portátil tiene la forma de una computadora portátil estándar de solo lectura.

La utilización de procesamiento múltiple nos ayuda a escalar en el procesamiento de cada notebook y utilizar todos sus núcleos. Generamos funciones en otros portátiles que pueden realizar un procesamiento pesado, como las siguientes:

Explotar JSON
Encuentre filas relevantes en un DataFrame mientras el cuaderno principal divide el DataFrame en #cpu-cores elementos
Ejecute acciones de agrupación por tipo de alerta simultáneamente

Luego agregamos estos cuadernos funcionales al contenedor que ejecuta el cuaderno como un trabajo de procesamiento. Consulte el siguiente archivo Docker (observe los 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 la fase de investigación, evaluamos la opción de ejecutar nuestros cuadernos tal cual para experimentar y evaluar el rendimiento de nuestro código en todos nuestros datos relevantes, no solo en una muestra de datos. Descubrimos que encapsular nuestras computadoras portátiles mediante trabajos de procesamiento puede ser una excelente opción para nosotros, porque no necesitamos volver a escribir el código y podemos utilizar el poder de las instancias optimizadas para computación y memoria de AWS y seguir fácilmente el estado del proceso.

Durante la evaluación de la inferencia, evaluamos varias soluciones de terminales de SageMaker. Descubrimos que el uso de un punto final de varios modelos puede ayudarnos a atender a aproximadamente 50 clientes, cada uno con varios modelos (aproximadamente 10) en una sola instancia, lo que puede cumplir con nuestras restricciones de baja latencia y, por lo tanto, ahorrarnos hasta un 80 % del costo. .

Con esta arquitectura de solución, pudimos reducir el MTTR de nuestros clientes, que es una métrica principal para medir el éxito en el uso de nuestra plataforma. Reduce el tiempo total desde el momento en que responde a nuestro enlace de alerta, que describe un problema en sus sistemas, hasta que termina de investigar el problema con nuestra plataforma. Durante la fase de investigación, medimos las acciones de los usuarios con y sin nuestra solución de recomendación de ML. Esto nos ayuda a brindar recomendaciones sobre la mejor acción para resolver el problema específico más rápido y detectar anomalías para identificar la causa real del problema.

Conclusión y próximos pasos

En esta publicación, compartimos cómo Logz.io usó SageMaker para mejorar MTTD y MTTR.

Como próximo paso, estamos considerando expandir la solución con las siguientes funciones:

Te animamos a probar Cuadernos SageMaker. Para obtener más ejemplos, consulte el Ejemplos de SageMaker repositorio de GitHub.

Acerca de los autores

amit bruto lidera el departamento de Investigación de Logz.io, que es responsable de las soluciones de IA de todos los productos de Logz.io, desde la fase de investigación hasta la fase de integración. Antes de Logz.io, Amit administró los grupos de investigación de seguridad y ciencia de datos en Here inc. y Cellebrite inc. Amit tiene una maestría en ciencias de la computación de la Universidad de Tel-Aviv.

Yaniv Vaknin es un especialista en aprendizaje automático en Amazon Web Services. Antes de AWS, Yaniv ocupó puestos de liderazgo en nuevas empresas de IA y Enterprise, incluido el cofundador y director ejecutivo de Dipsee.ai. Yaniv trabaja con los clientes de AWS para aprovechar el poder del aprendizaje automático para resolver tareas del mundo real y obtener valor. En su tiempo libre, Yaniv disfruta jugando al fútbol con sus hijos.

Eitan Sela es un arquitecto de soluciones especializado en aprendizaje automático con Amazon Web Services. Trabaja con los clientes de AWS para brindar orientación y asistencia técnica, ayudándolos a crear y operar soluciones de aprendizaje automático en AWS. En su tiempo libre, a Eitan le gusta hacer jogging y leer los últimos artículos sobre aprendizaje automático.