Hur Logz.io accelererar ML-rekommendationer och anomalidetekteringslösningar med Amazon SageMaker

Återutgiven av Platon

anhängare: 0

Logz.io är en AWS Partner Network (APN) Advanced Technology Partner med AWS-kompetenser inom DevOps, säkerhet och data & analys. Logz.io erbjuder en mjukvara som en tjänst (SaaS) observerbarhetsplattform baserad på klassens bästa mjukvarulösningar med öppen källkod för logg-, metrisk- och spårningsanalys. Kunder skickar en ökande mängd data till Logz.io från olika datakällor för att hantera hälsan och prestanda för sina applikationer och tjänster. Det kan vara överväldigande för nya användare som vill navigera över de olika instrumentpanelerna som byggts över tiden, bearbeta olika varningsmeddelanden och koppla ihop punkterna vid felsökning av produktionsproblem.

Mean Time to Detect (MTTD) och Mean Time to Resolution (MTTR) är nyckeltal för våra kunder. De beräknas genom att mäta den tid en användare på vår plattform börjar undersöka ett problem (som produktionstjänst nere) till den punkt då de slutar göra åtgärder på plattformen som är relaterade till den specifika utredningen.

För att hjälpa kunder att minska MTTD och MTTR, vänder sig Logz.io till maskininlärning (ML) för att ge rekommendationer för relevanta instrumentpaneler och frågor och utföra anomalidetektering via självlärande. Som ett resultat är den genomsnittliga användaren utrustad med den samlade upplevelsen av hela sitt företag, vilket drar nytta av mångas visdom. Vi upptäckte att vår lösning kan minska MTTR med upp till 20 %.

När MTTD minskar kan användare identifiera problemet och lösa det snabbare. Vårt semantiska datalager innehåller semantik för att starta och stoppa en undersökning, och populariteten för varje åtgärd som användaren gör med avseende på en specifik varning.

I det här inlägget delar vi hur Logz.io använde Amazon SageMaker för att minska tiden och ansträngningen för vårt proof of concept (POC), experiment från forskning till produktionsutvärdering, och hur vi minskade vår produktions slutledningskostnad.

Utmaningen

Tills Logz.io använde SageMaker var tiden mellan forskning till POC-testning och experiment på produktion ganska lång. Detta berodde på att vi behövde skapa Spark-jobb för att samla in, rengöra och normalisera data. DevOps krävde detta arbete för att läsa varje datakälla. DevOps och datateknikfärdigheter är inte en del av vårt ML-team, och detta orsakade ett stort beroende mellan teamen.

En annan utmaning var att tillhandahålla en ML-inferenstjänst till våra produkter samtidigt som vi uppnådde ett optimalt förhållande mellan kostnad och prestanda. Vårt optimala scenario är att stödja så många modeller som möjligt för en datorenhet, samtidigt som det ger hög samtidighet från kunder med många modeller. Vi hade flexibilitet när det gäller vår slutledningstid, eftersom vårt initiala fönster för dataströmmen för slutledningstjänsten är 5 minuters hink med loggar.

Forskningsfas

Datavetenskap är en iterativ process som kräver en interaktiv utvecklingsmiljö för forskning, som validerar datautgången för varje iteration och databehandling. Därför uppmuntrar vi våra ML-forskare att använda anteckningsböcker.

För att påskynda iterationscykeln ville vi testa våra bärbara datorers kod på verklig produktionsdata, samtidigt som vi körde den i skala. Dessutom ville vi undvika flaskhalsen med DevOps och datateknik under det första testet i produktionen, samtidigt som vi hade möjlighet att se utdata och försöka uppskatta kodens körtid.

För att implementera detta ville vi ge vårt datavetenskapsteam full kontroll och helhetsansvar från forskning till första test på produktion. Vi behövde dem för att enkelt hämta data, samtidigt som vi bevarade dataåtkomsthanteringen och övervakade denna åtkomst. De behövde också enkelt distribuera sina anpassade POC-anteckningsböcker i produktion på ett skalbart sätt, samtidigt som de övervakade körtiden och förväntade kostnader.

Utvärderingsfas

Under denna fas utvärderade vi några ML-plattformar för att stödja både utbildnings- och serveringskrav. Vi fann att SageMaker är det mest lämpliga för våra användningsfall eftersom det stöder både utbildning och slutledning. Dessutom är den anpassningsbar, så vi kan skräddarsy den enligt vår föredragna forskningsprocess.

Till en början utgick vi från lokala anteckningsböcker och testade olika bibliotek. Vi stötte på problem med att hämta massiv data från produktionen. Senare fastnade vi i en punkt i modelleringsfasen som tog många timmar på en lokal maskin.

Vi utvärderade många lösningar och valde slutligen följande arkitektur:

DataPlate – Den öppna källkodsversionen av DataPlate hjälpte oss att enkelt dra och sammanfoga vår data genom att använda vår Spark Amazon EMR kluster med en enkel SQL, samtidigt som man övervakar dataåtkomsten
SageMaker anteckningsbok instans och bearbetning jobb – Detta hjälpte oss med skalbarheten av körtid och flexibiliteten hos maskintyper och ML-ramverk, samtidigt som vi samarbetade med vår kod via en Git-anslutning

Forskningsfas lösningsarkitektur

Följande diagram illustrerar forskningsfasens lösningsarkitektur och består av följande komponenter:

SageMaker anteckningsböcker – Dataforskare använder dessa bärbara datorer att bedriva sin forskning.
AWS Lambda-funktion - AWS Lambda är en serverlös lösning som kör ett bearbetningsjobb på begäran. Jobbet använder en Docker-behållare med den anteckningsbok vi vill köra under vårt experiment, tillsammans med alla våra vanliga filer som behöver stödja anteckningsboken (requirements.txt och multibearbetningsfunktionskoden i en separat anteckningsbok).
Amazon ECR - Amazon Elastic Container Registry (Amazon ECR) lagrar vår Docker-container.
SageMaker Bearbetar jobb – Vi kan köra det här databearbetningsjobb på vilken ML-maskin som helst, och den kör vår bärbara dator med parametrar.
DataPlate – Den här tjänsten hjälper oss att använda SQL och enkelt ansluta flera datakällor. Den översätter den till Spark-kod och optimerar den, samtidigt som den övervakar dataåtkomst och hjälper till att minska dataintrång. Xtra-versionen gav ännu fler möjligheter.
Amazon EMR – Den här tjänsten kör våra dataextraktioner som arbetsbelastningar över Spark och kontaktar alla våra dataresurser.

Med SageMaker notebook-instansens livscykel kan vi kontrollera den maximala notebook-instansens körtid med hjälp av autostop.py mall skript.

Efter att ha testat ML-ramverken valde vi SageMaker MXNet-kärnan för våra klustrings- och rankningsfaser.

För att testa notebook-koden på våra produktionsdata, körde vi notebook-datorn genom att kapsla in den via Docker i Amazon ECS och körde den som ett bearbetningsjobb för att validera maximal körtid på olika typer av maskiner.

Docker-behållaren hjälper oss också att dela resurser bland anteckningsböckers tester. I vissa fall anropar en bärbar dator andra bärbara datorer för att använda en multiprocess genom att dela upp stora dataramar i mindre dataramar, som kan köras samtidigt på varje vCPU i en stor maskintyp.

Produktionsinferenslösningen i realtid

I forskningsfasen använde vi Parkett Amazon enkel lagringstjänst (Amazon S3)-filer för att behålla våra rekommendationer. Dessa konsumeras en gång om dagen från vår tekniska pipeline för att bifoga rekommendationerna till vår varningsmekanism.

Vår färdplan kräver dock en lösning med högre uppdateringsfrekvens och att dra en gång om dagen räcker inte på lång sikt, eftersom vi vill ge rekommendationer även under utredningen.

För att implementera denna lösning i stor skala testade vi de flesta av SageMakers slutpunktslösningar i vår forskning om anomalidetektering. Vi testade 500 av de förbyggda modellerna med en enda slutpunktsmaskin av olika typer och använde samtidiga flertrådiga klienter för att utföra förfrågningar till slutpunkten. Vi mätte svarstiden, CPU, minne och andra mätvärden (för mer information, se Övervaka Amazon SageMaker med Amazon CloudWatch). Vi fann att flermodellslutpunkten passar perfekt för våra användningsfall.

En flermodellslutpunkt kan minska våra kostnader dramatiskt jämfört med en enda slutpunkt eller till och med Kubernetes för att använda Flask (eller andra Python) webbtjänster. Vårt första antagande var att vi måste tillhandahålla en enda slutpunkt, med en 4-vCPU liten maskin, för varje kund, och i genomsnitt fråga fyra dedikerade modeller, eftersom varje vCPU tjänar en modell. Med flermodellslutpunkten skulle vi kunna samla fler kunder på en enda multi-endpointmaskin.

Vi hade en modell och kodningsfiler per kund, och efter att ha gjort belastningstester bestämde vi att vi kunde betjäna 50 kunder, var och en med 10 modeller och till och med med den minsta ml.t2.medium-instansen för våra lösningar.

I detta skede övervägde vi att använda flermodell slutpunkter. Flermodellslutpunkter ger en skalbar och kostnadseffektiv lösning för att distribuera ett stort antal modeller, vilket gör att du kan vara värd för flera modeller med en enda slutledningsbehållare. Detta minskar värdkostnaderna genom att förbättra slutpunktsanvändningen jämfört med att använda flera små enda-modellslutpunkter som var och en betjänar en enda kund. Det minskar också distributionskostnader eftersom SageMaker hanterar att ladda modeller i minnet och skala dem baserat på trafikmönstren till dem.

Dessutom är fördelen med flera modeller att om du har en hög slutledningsfrekvens från specifika kunder, bevarar dess ramverk de sista visningsmodellerna i minnet för bättre prestanda.

Efter att vi uppskattat kostnaderna med hjälp av multi-modell endpoints kontra standard endpoints, upptäckte vi att det potentiellt kunde leda till kostnadsreduktion på cirka 80 %.

Resultatet

I det här avsnittet går vi igenom stegen och resultatet av processen.

Vi använder livscykelkonfigurationen för anteckningsboken för att möjliggöra körning av bärbara datorer som bearbetningsjobb, genom att kapsla in anteckningsboken i en Docker-behållare för att validera koden snabbare och använda autostoppmekanismen:

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

Vi klonar sagemaker-run-anteckningsbok GitHub-projektet och lägg till följande i behållaren:

Våra pip-krav
Möjligheten att köra anteckningsböcker inifrån en anteckningsbok, vilket gör det möjligt för oss att hantera flera instanser för att använda alla ml.m5.12xlarge instanskärnor

Detta gör att vi kan köra arbetsflöden som består av många bärbara datorer som körs som bearbetningsjobb i en kodrad, samtidigt som vi definierar instanstypen som ska köras på.

Eftersom vi kan lägga till parametrar till den bärbara datorn kan vi skala vår bearbetning genom att köra samtidigt vid olika timmar, dagar eller månader för att hämta och bearbeta data.

Vi kan också skapa schemaläggningsjobb som kör bärbara datorer (och till och med begränsa körtiden).

Vi kan också observera de senaste körningarna och deras detaljer, såsom handläggningstid.

Med pappersbruket som används i behållaren kan vi se resultatet från varje körning, vilket hjälper oss att felsöka i produktionen.

Vår utdatarecension för anteckningsboken är i form av en standard skrivskyddad anteckningsbok.

Multibearbetningsanvändning hjälper oss att skala på varje notebook-bearbetning och använda alla dess kärnor. Vi genererade funktioner i andra bärbara datorer som kan göra tung bearbetning, som följande:

Explodera JSONs
Hitta relevanta rader i en DataFrame medan huvudanteckningsboken delar upp DataFrame #cpu-cores element
Kör klustring per varningstyp åtgärder samtidigt

Vi lägger sedan till dessa funktionella anteckningsböcker i behållaren som kör anteckningsboken som ett bearbetningsjobb. Se följande Docker-fil (lägg märke till COPY-kommandona):

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

Resultat

Under forskningsfasen utvärderade vi möjligheten att köra våra bärbara datorer som de är för att experimentera och utvärdera hur vår kod presterar på alla våra relevanta data, inte bara ett urval av data. Vi fann att inkapsling av våra bärbara datorer med hjälp av bearbetningsjobb kan passa bra för oss, eftersom vi inte behöver skriva om kod och vi kan utnyttja kraften i AWS-beräkningsoptimerade och minnesoptimerade instanser och enkelt följa processens status.

Under slutledningsbedömningen utvärderade vi olika SageMakers slutpunktslösningar. Vi upptäckte att användning av en flermodellslutpunkt kan hjälpa oss att betjäna cirka 50 kunder, som var och en har flera (ungefär 10) modeller i en enda instans, vilket kan möta våra begränsningar med låg latens och därför spara oss upp till 80 % av kostnaden .

Med denna lösningsarkitektur kunde vi minska våra kunders MTTR, vilket är ett huvudmått för att mäta framgång med vår plattform. Det minskar den totala tiden från det att du svarar på vår varningslänk, som beskriver ett problem i dina system, tills du är klar med att undersöka problemet med vår plattform. Under utredningsfasen mäter vi användarnas agerande med och utan vår ML-rekommendationslösning. Detta hjälper oss att ge rekommendationer för bästa åtgärd för att lösa det specifika problemet snabbare och lokalisera avvikelser för att identifiera den faktiska orsaken till problemet.

Slutsats och nästa steg

I det här inlägget delade vi hur Logz.io använde SageMaker för att förbättra MTTD och MTTR.

Som ett nästa steg överväger vi att utöka lösningen med följande funktioner:

Vi uppmuntrar dig att prova SageMaker anteckningsböcker. För fler exempel, kolla in SageMaker exempel GitHub repo.

Om författarna

Amit Gross leder Logz.ios forskningsavdelning, som ansvarar för AI-lösningarna för alla Logz.io-produkter, från forskningsfasen till integrationsfasen. Före Logz.io har Amit lett både datavetenskap och säkerhetsforskningsgrupper på Here inc. och Cellebrite inc. Amit har en M.Sc i datavetenskap från Tel-Aviv University.

Yaniv Vaknin är en maskininlärningsspecialist på Amazon Web Services. Innan han började på AWS hade Yaniv ledande befattningar med AI-startups och Enterprise, inklusive medgrundare och VD för Dipsee.ai. Yaniv arbetar med AWS-kunder för att utnyttja kraften i maskininlärning för att lösa verkliga uppgifter och skapa värde. På fritiden tycker Yaniv om att spela fotboll med sina pojkar.

Eitan Sela är en lösningsarkitekt för maskininlärning med Amazon Web Services. Han arbetar med AWS-kunder för att ge vägledning och teknisk assistans, och hjälpa dem att bygga och driva maskininlärningslösningar på AWS. På fritiden tycker Eitan om att jogga och läsa de senaste maskininlärningsartiklarna.