Comment Logz.io accélère les recommandations ML et les solutions de détection d'anomalies avec Amazon SageMaker

Republié par Platon

Suiveurs: 0

Logz.io est un partenaire technologique avancé du réseau de partenaires AWS (APN) avec Compétences AWS en DevOps, sécurité et données et analyses. Logz.io propose une plate-forme d'observabilité logicielle en tant que service (SaaS) basée sur les meilleures solutions logicielles open source pour l'analyse des journaux, des métriques et du traçage. Les clients envoient une quantité croissante de données à Logz.io à partir de diverses sources de données pour gérer la santé et les performances de leurs applications et services. Cela peut être écrasant pour les nouveaux utilisateurs qui cherchent à naviguer dans les différents tableaux de bord construits au fil du temps, à traiter différentes notifications d'alerte et à relier les points lors du dépannage des problèmes de production.

Le temps moyen de détection (MTTD) et le temps moyen de résolution (MTTR) sont des mesures clés pour nos clients. Ils sont calculés en mesurant le temps qu'un utilisateur de notre plate-forme commence à enquêter sur un problème (tel que l'arrêt du service de production) jusqu'au moment où il arrête d'effectuer des actions sur la plate-forme liées à l'enquête spécifique.

Pour aider les clients à réduire le MTTD et le MTTR, Logz.io se tourne vers l'apprentissage automatique (ML) pour fournir des recommandations pour les tableaux de bord et les requêtes pertinents et effectuer la détection des anomalies via l'auto-apprentissage. En conséquence, l'utilisateur moyen est équipé de l'expérience agrégée de toute son entreprise, tirant parti de la sagesse de beaucoup. Nous avons constaté que notre solution peut réduire le MTTR jusqu'à 20 %.

À mesure que le MTTD diminue, les utilisateurs peuvent identifier le problème et le résoudre plus rapidement. Notre couche sémantique de données contient une sémantique pour démarrer et arrêter une enquête, ainsi que la popularité de chaque action effectuée par l'utilisateur par rapport à une alerte spécifique.

Dans cet article, nous partageons comment Logz.io a utilisé Amazon Sage Maker pour réduire le temps et les efforts pour notre preuve de concept (POC), les expériences de la recherche à l'évaluation de la production, et comment nous avons réduit nos coûts d'inférence de production.

Le défi

Jusqu'à ce que Logz.io utilise SageMaker, le temps entre la recherche, les tests POC et les expériences de production était assez long. En effet, nous devions créer des tâches Spark pour collecter, nettoyer et normaliser les données. DevOps nécessitait ce travail pour lire chaque source de données. Les compétences en DevOps et en ingénierie des données ne font pas partie de notre équipe ML, ce qui a entraîné une forte dépendance entre les équipes.

Un autre défi consistait à fournir un service d'inférence ML à nos produits tout en obtenant un rapport coût/performance optimal. Notre scénario optimal prend en charge autant de modèles que possible pour une unité de calcul, tout en offrant une simultanéité élevée des clients avec de nombreux modèles. Nous avions de la flexibilité sur notre temps d'inférence, car notre fenêtre initiale du flux de données pour le service d'inférence est de 5 minutes de seau de journaux.

Phase de recherche

La science des données est un processus itératif qui nécessite un environnement de développement interactif pour la recherche, validant la sortie des données à chaque itération et traitement des données. Par conséquent, nous encourageons nos chercheurs en ML à utiliser des cahiers.

Pour accélérer le cycle d'itération, nous voulions tester le code de nos notebooks sur des données de production réelles, tout en l'exécutant à grande échelle. De plus, nous voulions éviter le goulot d'étranglement du DevOps et de l'ingénierie des données lors du test initial en production, tout en ayant la possibilité de visualiser les sorties et d'essayer d'estimer le temps d'exécution du code.

Pour mettre cela en œuvre, nous voulions fournir à notre équipe de science des données un contrôle total et une responsabilité de bout en bout, de la recherche au test initial en production. Nous en avions besoin pour extraire facilement les données, tout en préservant la gestion des accès aux données et en surveillant ces accès. Ils devaient également déployer facilement leurs ordinateurs portables POC personnalisés en production de manière évolutive, tout en surveillant le temps d'exécution et les coûts prévus.

Phase d'évaluation

Au cours de cette phase, nous avons évalué quelques plates-formes de ML afin de prendre en charge à la fois les exigences de formation et de service. Nous avons constaté que SageMaker est le plus approprié pour nos cas d'utilisation car il prend en charge à la fois la formation et l'inférence. De plus, il est personnalisable, nous pouvons donc l'adapter en fonction de notre processus de recherche préféré.

Au départ, nous sommes partis de cahiers locaux, en testant diverses bibliothèques. Nous avons rencontré des problèmes pour extraire des données massives de la production. Plus tard, nous avons été bloqués à un point de la phase de modélisation qui a pris de nombreuses heures sur une machine locale.

Nous avons évalué de nombreuses solutions et avons finalement choisi l'architecture suivante :

Plaque de données – La version open source de Plaque de données nous a aidés à extraire et à joindre facilement nos données en utilisant notre Spark Amazon DME clusters avec un simple SQL, tout en surveillant l'accès aux données
Instance de bloc-notes SageMaker et tâches de traitement – Cela nous a aidés avec l'évolutivité de l'exécution et la flexibilité des types de machines et des frameworks ML, tout en collaborant notre code via une connexion Git

Architecture de la solution de la phase de recherche

Le schéma suivant illustre l'architecture de la solution de la phase de recherche et se compose des composants suivants :

Carnets SageMaker – Les data scientists les utilisent ordinateurs portables pour mener leurs recherches.
Fonction AWS Lambda - AWS Lambda est une solution sans serveur qui exécute une tâche de traitement à la demande. Le travail utilise un conteneur Docker avec le bloc-notes que nous voulons exécuter pendant notre expérience, ainsi que tous nos fichiers communs qui doivent prendre en charge le bloc-notes (requirements.txt et le code des fonctions multi-traitements dans un cahier séparé).
ECR d'Amazon - Registre des conteneurs élastiques Amazon (Amazon ECR) stocke notre conteneur Docker.
Travail de traitement SageMaker – Nous pouvons exécuter ceci travail de traitement de données sur n'importe quelle machine ML, et il exécute notre bloc-notes avec des paramètres.
Plaque de données – Ce service nous aide à utiliser SQL et à joindre facilement plusieurs sources de données. Il le traduit en code Spark et l'optimise, tout en surveillant l'accès aux données et en aidant à réduire les violations de données. La version Xtra offrait encore plus de fonctionnalités.
Amazon DME – Ce service exécute nos extractions de données en tant que charges de travail sur Spark, en contactant toutes nos ressources de données.

Avec le cycle de vie de l'instance de bloc-notes SageMaker, nous pouvons contrôler la durée d'exécution maximale de l'instance de bloc-notes, à l'aide de la autostop.py modèle scripts.

Après avoir testé les frameworks ML, nous avons choisi le noyau SageMaker MXNet pour nos phases de clustering et de classement.

Pour tester le code du bloc-notes sur nos données de production, nous avons exécuté le bloc-notes en l'encapsulant via Docker dans Amazon ECS et l'avons exécuté en tant que tâche de traitement pour valider le temps d'exécution maximal sur différents types de machines.

Le conteneur Docker nous aide également à partager les ressources entre les tests des notebooks. Dans certains cas, un ordinateur portable appelle d'autres ordinateurs portables pour utiliser un multi-processus en divisant les trames de données volumineuses en trames de données plus petites, qui peuvent s'exécuter simultanément sur chaque vCPU dans un type de machine de grande taille.

La solution d'inférence de production en temps réel

Dans la phase de recherche, nous avons utilisé Parquet Service de stockage simple Amazon (Amazon S3) pour maintenir nos recommandations. Ceux-ci sont consommés une fois par jour à partir de notre pipeline d'ingénierie pour attacher les recommandations à notre mécanisme d'alertes.

Cependant, notre feuille de route nécessite une solution à taux de rafraîchissement plus élevé et tirer une fois par jour n'est pas suffisant à long terme, car nous voulons fournir des recommandations même pendant l'enquête.

Pour mettre en œuvre cette solution à grande échelle, nous avons testé la plupart des solutions de terminaux SageMaker dans notre recherche de détection d'anomalies. Nous avons testé 500 des modèles prédéfinis avec une seule machine de point de terminaison de différents types et utilisé des clients multithreads simultanés pour effectuer des requêtes vers le point de terminaison. Nous avons mesuré le temps de réponse, le processeur, la mémoire et d'autres mesures (pour plus d'informations, voir Surveillez Amazon SageMaker avec Amazon CloudWatch). Nous avons constaté que le point de terminaison multimodèle est parfaitement adapté à nos cas d'utilisation.

Un point de terminaison multimodèle peut réduire considérablement nos coûts par rapport à un point de terminaison unique ou même à Kubernetes pour utiliser les services Web Flask (ou d'autres Python). Notre première hypothèse était que nous devions fournir un point de terminaison unique, en utilisant une petite machine à 4 vCPU, pour chaque client, et interroger en moyenne quatre modèles dédiés, car chaque vCPU sert un modèle. Avec le point de terminaison multi-modèle, nous pourrions regrouper plus de clients sur une seule machine multi-points de terminaison.

Nous avions un modèle et des fichiers d'encodage par client, et après avoir effectué des tests de charge, nous avons déterminé que nous pouvions servir 50 clients, chacun utilisant 10 modèles et même en utilisant la plus petite instance ml.t2.medium pour nos solutions.

Dans cette étape, nous avons envisagé d'utiliser points de terminaison multimodèle. Les points de terminaison multimodèles offrent une solution évolutive et rentable pour déployer un grand nombre de modèles, vous permettant d'héberger plusieurs modèles avec un seul conteneur d'inférence. Cela réduit les coûts d'hébergement en améliorant l'utilisation des points de terminaison par rapport à l'utilisation de plusieurs petits points de terminaison à modèle unique qui desservent chacun un seul client. Cela réduit également les frais généraux de déploiement, car SageMaker gère le chargement des modèles en mémoire et les met à l'échelle en fonction des modèles de trafic vers eux.

De plus, l'avantage du point de terminaison multi-modèle est que si vous avez un taux d'inférence élevé de clients spécifiques, son cadre conserve les derniers modèles de service en mémoire pour de meilleures performances.

Après avoir estimé les coûts en utilisant des points de terminaison multimodèles par rapport aux points de terminaison standard, nous avons découvert que cela pourrait potentiellement conduire à une réduction des coûts d'environ 80 %.

Le résultat

Dans cette section, nous passons en revue les étapes et le résultat du processus.

Nous utilisons la configuration du bloc-notes Lifecycle pour activer l'exécution des blocs-notes en tant que tâches de traitement, en encapsulant le bloc-notes dans un conteneur Docker afin de valider le code plus rapidement et d'utiliser le mécanisme d'arrêt automatique :

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

Nous clonons le carnet de notes sagemaker projet GitHub, puis ajoutez les éléments suivants au conteneur :

Nos besoins en pip
La possibilité d'exécuter des blocs-notes à partir d'un bloc-notes, ce qui nous permet un comportement multi-traitement pour utiliser tous les cœurs d'instance ml.m5.12xlarge

Cela nous permet d'exécuter des flux de travail composés de nombreux blocs-notes exécutés en tant que tâches de traitement dans une ligne de code, tout en définissant le type d'instance à exécuter.

Comme nous pouvons ajouter des paramètres au bloc-notes, nous pouvons faire évoluer notre traitement en exécutant simultanément à différentes heures, jours ou mois pour extraire et traiter les données.

Nous pouvons également créer des tâches de planification qui exécutent des blocs-notes (et même limiter le temps d'exécution).

Nous pouvons également observer les dernières exécutions et leurs détails, tels que le temps de traitement.

Avec la papeterie utilisée dans le conteneur, nous pouvons afficher la sortie de chaque cycle, ce qui nous aide à déboguer en production.

Notre revue de sortie de bloc-notes se présente sous la forme d'un bloc-notes standard en lecture seule.

L'utilisation du multitraitement nous aide à évoluer sur chaque ordinateur portable et à utiliser tous ses cœurs. Nous avons généré des fonctions dans d'autres notebooks qui peuvent effectuer des traitements lourds, comme les suivants :

Décomposer les JSON
Trouvez les lignes pertinentes dans un DataFrame pendant que le bloc-notes principal divise le DataFrame en #cpu-cores éléments
Exécuter simultanément des actions de clustering par type d'alerte

Nous ajoutons ensuite ces blocs-notes fonctionnels dans le conteneur qui exécute le bloc-notes en tant que tâche de traitement. Voir le fichier Docker suivant (notez les commandes 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

Résultats

Au cours de la phase de recherche, nous avons évalué la possibilité d'exécuter nos blocs-notes tels quels pour expérimenter et évaluer les performances de notre code sur toutes nos données pertinentes, et pas seulement sur un échantillon de données. Nous avons constaté que l'encapsulation de nos blocs-notes à l'aide de tâches de traitement peut nous convenir parfaitement, car nous n'avons pas besoin de réécrire le code et nous pouvons utiliser la puissance des instances AWS optimisées pour le calcul et la mémoire et suivre facilement l'état du processus.

Au cours de l'évaluation de l'inférence, nous avons évalué diverses solutions de terminaux SageMaker. Nous avons constaté que l'utilisation d'un point de terminaison multimodèle peut nous aider à servir environ 50 clients, chacun ayant plusieurs (environ 10) modèles dans une seule instance, ce qui peut répondre à nos contraintes de faible latence, et donc nous faire économiser jusqu'à 80 % du coût. .

Grâce à cette architecture de solution, nous avons pu réduire le MTTR de nos clients, qui est un indicateur principal pour mesurer le succès de l'utilisation de notre plateforme. Cela réduit le temps total entre la réponse à notre lien d'alerte, qui décrit un problème dans vos systèmes, et le moment où vous avez terminé d'enquêter sur le problème à l'aide de notre plateforme. Lors de la phase d'investigation, nous mesurons les actions des utilisateurs avec et sans notre solution de recommandation ML. Cela nous aide à fournir des recommandations sur la meilleure action pour résoudre le problème spécifique plus rapidement et à identifier les anomalies pour identifier la cause réelle du problème.

Conclusion et prochaines étapes

Dans cet article, nous avons partagé comment Logz.io a utilisé SageMaker pour améliorer MTTD et MTTR.

Dans une prochaine étape, nous envisageons d'étendre la solution avec les fonctionnalités suivantes :

Nous vous encourageons à essayer Carnets SageMaker. Pour plus d'exemples, consultez le Exemples de référentiel GitHub SageMaker.

À propos des auteurs

Amit Gross dirige le département Recherche de Logz.io, qui est responsable des solutions d'IA de tous les produits Logz.io, de la phase de recherche à la phase d'intégration. Avant Logz.io, Amit a géré les groupes de recherche en science des données et en sécurité chez Here inc. et Cellebrite inc. Amit est titulaire d'une maîtrise en informatique de l'Université de Tel-Aviv.

Yaniv Vaknine est spécialiste de l'apprentissage automatique chez Amazon Web Services. Avant AWS, Yaniv a occupé des postes de direction dans des startups d'IA et des entreprises, notamment co-fondateur et PDG de Dipsee.ai. Yaniv travaille avec les clients AWS pour exploiter la puissance du Machine Learning pour résoudre des tâches du monde réel et générer de la valeur. Dans ses temps libres, Yaniv aime jouer au football avec ses garçons.

Eitan Sela est un architecte de solutions spécialiste de l'apprentissage automatique chez Amazon Web Services. Il travaille avec les clients d'AWS pour fournir des conseils et une assistance technique, en les aidant à créer et à exploiter des solutions d'apprentissage automatique sur AWS. Dans ses temps libres, Eitan aime faire du jogging et lire les derniers articles sur l'apprentissage automatique.