Hvordan Logz.io accelererer ML-anbefalinger og anomalidetektionsløsninger med Amazon SageMaker

Genudgivet af Platon

Abonnenter: 0

Logz.io er en AWS Partner Network (APN) Advanced Technology Partner med AWS-kompetencer inden for DevOps, Sikkerhed og Data & Analytics. Logz.io tilbyder en software as a service (SaaS) observationsplatform baseret på klassens bedste open source-softwareløsninger til log-, metrisk- og sporingsanalyse. Kunder sender en stigende mængde data til Logz.io fra forskellige datakilder for at styre sundheden og ydeevnen af deres applikationer og tjenester. Det kan være overvældende for nye brugere, der ønsker at navigere på tværs af de forskellige dashboards, der er bygget over tid, behandle forskellige advarselsmeddelelser og forbinde prikkerne ved fejlfinding af produktionsproblemer.

Middeltid til detektion (MTTD) og middeltid til opløsning (MTTR) er nøglemålinger for vores kunder. De beregnes ved at måle den tid, en bruger på vores platform begynder at undersøge et problem (såsom produktionsservice nede) til det punkt, hvor de holder op med at udføre handlinger på platformen, der er relateret til den specifikke undersøgelse.

For at hjælpe kunder med at reducere MTTD og MTTR, henvender Logz.io sig til maskinlæring (ML) for at give anbefalinger til relevante dashboards og forespørgsler og udføre anomalidetektion via selvlæring. Som et resultat er den gennemsnitlige bruger udstyret med den samlede oplevelse af hele deres virksomhed, hvilket udnytter manges visdom. Vi fandt ud af, at vores løsning kan reducere MTTR med op til 20 %.

Efterhånden som MTTD falder, kan brugerne identificere problemet og løse det hurtigere. Vores semantiske datalag indeholder semantik til at starte og stoppe en undersøgelse og populariteten af hver handling, som brugeren udfører med hensyn til en specifik advarsel.

I dette indlæg deler vi, hvordan Logz.io brugte Amazon SageMaker at reducere tiden og indsatsen for vores proof of concept (POC), eksperimenter fra forskning til produktionsevaluering, og hvordan vi reducerede vores produktionsinferensomkostninger.

Udfordringen

Indtil Logz.io brugte SageMaker, var tiden mellem forskning til POC-test og eksperimenter med produktion ret lang. Dette skyldtes, at vi skulle oprette Spark-jobs for at indsamle, rense og normalisere dataene. DevOps krævede dette arbejde for at læse hver datakilde. DevOps og dataingeniørfærdigheder er ikke en del af vores ML-team, og dette forårsagede en høj afhængighed mellem holdene.

En anden udfordring var at levere en ML-slutningstjeneste til vores produkter, samtidig med at vi opnåede optimalt forhold mellem omkostninger og ydeevne. Vores optimale scenarie er at understøtte så mange modeller som muligt for en computerenhed, samtidig med at det giver høj samtidighed fra kunder med mange modeller. Vi havde fleksibilitet med hensyn til vores inferenstid, fordi vores indledende vindue for datastrømmen for inferenstjenesten er 5 minutters spand af logfiler.

Forskningsfase

Datavidenskab er en iterativ proces, der kræver et interaktivt udviklingsmiljø for forskning, der validerer dataoutput på hver iteration og databehandling. Derfor opfordrer vi vores ML-forskere til at bruge notesbøger.

For at accelerere iterationscyklussen ønskede vi at teste vores notebooks kode på rigtige produktionsdata, mens vi kørte den i skala. Desuden ønskede vi at undgå flaskehalsen ved DevOps og datateknik under den indledende test i produktionen, samtidig med at vi havde mulighed for at se output og forsøge at estimere kodens runtime.

For at implementere dette ønskede vi at give vores datavidenskabsteam fuld kontrol og ende-til-ende-ansvar fra forskning til indledende test på produktion. Vi havde brug for dem til nemt at trække data, samtidig med at vi bevarer dataadgangsstyringen og overvåger denne adgang. De skulle også nemt implementere deres brugerdefinerede POC-notebooks i produktionen på en skalerbar måde, mens de overvågede køretiden og forventede omkostninger.

Evalueringsfase

I denne fase evaluerede vi nogle få ML-platforme for at understøtte både trænings- og serveringskrav. Vi fandt ud af, at SageMaker er den mest passende til vores brugstilfælde, fordi den understøtter både træning og konklusioner. Desuden kan den tilpasses, så vi kan skræddersy den i henhold til vores foretrukne forskningsproces.

Til at begynde med tog vi udgangspunkt i lokale notesbøger og testede forskellige biblioteker. Vi løb ind i problemer med at trække massive data fra produktionen. Senere sad vi fast i et punkt i modelleringsfasen, der tog mange timer på en lokal maskine.

Vi vurderede mange løsninger og valgte til sidst følgende arkitektur:

Dataplade – Open source-versionen af Dataplade hjalp os med nemt at trække og samle vores data ved at bruge vores Spark Amazon EMR klynger med en simpel SQL, mens dataadgangen overvåges
SageMaker notebook-instans og behandlingsjob – Dette hjalp os med skalerbarheden af runtime og fleksibiliteten af maskintyper og ML-frameworks, mens vi samarbejdede vores kode via en Git-forbindelse

Løsningsarkitektur i forskningsfasen

Følgende diagram illustrerer forskningsfasens løsningsarkitektur og består af følgende komponenter:

SageMaker notesbøger – Dataforskere bruger disse notesbøger at udføre deres forskning.
AWS Lambda funktion - AWS Lambda er en serverløs løsning, der kører et behandlingsjob efter behov. Jobbet bruger en Docker-beholder med den notesbog, vi vil køre under vores eksperiment, sammen med alle vores almindelige filer, der skal understøtte notesbogen (requirements.txt og multi-processing-funktionskoden i en separat notesbog).
Amazon ECR - Amazon Elastic Container Registry (Amazon ECR) opbevarer vores Docker container.
SageMaker Processing job - Vi kan køre det her databehandler job på enhver ML-maskine, og den kører vores notebook med parametre.
Dataplade – Denne service hjælper os med at bruge SQL og nemt forbinde flere datakilder. Den oversætter den til Spark-kode og optimerer den, mens den overvåger dataadgang og hjælper med at reducere databrud. Xtra-versionen gav endnu flere muligheder.
Amazon EMR – Denne service kører vores dataudtræk som arbejdsbelastninger over Spark og kontakter alle vores dataressourcer.

Med SageMaker notebook-forekomstens livscyklus kan vi kontrollere den maksimale notebook-forekomst runtime ved hjælp af autostop.py skabelon scripts.

Efter at have testet ML-rammerne, valgte vi SageMaker MXNet-kernen til vores klynge- og rangeringsfaser.

For at teste notebookkoden på vores produktionsdata kørte vi notebooken ved at indkapsle den via Docker i Amazon ECS og kørte den som et behandlingsjob for at validere den maksimale runtime på forskellige typer maskiner.

Docker-beholderen hjælper os også med at dele ressourcer blandt notebooks' test. I nogle tilfælde kalder en notebook andre notebooks til at bruge en multi-proces ved at opdele big data frames i mindre data frames, som kan køre samtidigt på hver vCPU i en stor maskintype.

Produktionsinferensløsningen i realtid

I forskningsfasen brugte vi Parket Amazon Simple Storage Service (Amazon S3) filer for at opretholde vores anbefalinger. Disse indtages en gang om dagen fra vores tekniske pipeline for at vedhæfte anbefalingerne til vores alarmmekanisme.

Vores køreplan kræver dog en løsning med højere opdateringshastighed, og at trække én gang om dagen er ikke nok på lang sigt, fordi vi ønsker at give anbefalinger selv under undersøgelsen.

For at implementere denne løsning i stor skala, testede vi de fleste af SageMaker-slutpunktsløsningerne i vores forskning om anomalidetektion. Vi testede 500 af de præbyggede modeller med en enkelt endepunktsmaskine af forskellige typer og brugte samtidige multi-threaded klienter til at udføre anmodninger til endepunktet. Vi målte responstid, CPU, hukommelse og andre målinger (for mere information, se Overvåg Amazon SageMaker med Amazon CloudWatch). Vi fandt ud af, at multi-model-endepunktet passer perfekt til vores anvendelsestilfælde.

Et multi-model slutpunkt kan reducere vores omkostninger dramatisk sammenlignet med et enkelt slutpunkt eller endda Kubernetes til at bruge Flask (eller andre Python) webtjenester. Vores første antagelse var, at vi skal levere et enkelt slutpunkt, ved hjælp af en 4-vCPU lille maskine, for hver kunde, og i gennemsnit forespørge fire dedikerede modeller, fordi hver vCPU tjener én model. Med multi-model-endepunktet kunne vi samle flere kunder på en enkelt multi-endpoint-maskine.

Vi havde en model og indkodningsfiler pr. kunde, og efter at have udført belastningstests fandt vi ud af, at vi kunne betjene 50 kunder, hver ved at bruge 10 modeller og endda bruge den mindste ml.t2.medium-instans til vores løsninger.

I denne fase overvejede vi at bruge multi-model slutpunkter. Multi-model slutpunkter giver en skalerbar og omkostningseffektiv løsning til at implementere et stort antal modeller, så du kan hoste flere modeller med en enkelt inferensbeholder. Dette reducerer hostingomkostningerne ved at forbedre slutpunktudnyttelsen sammenlignet med at bruge flere små enkeltmodelslutpunkter, der hver betjener en enkelt kunde. Det reducerer også implementeringsomkostningerne, fordi SageMaker administrerer indlæsning af modeller i hukommelsen og skalerer dem baseret på trafikmønstrene til dem.

Ydermere er fordelen med multi-model slutpunkt, at hvis du har en høj inferensrate fra specifikke kunder, bevarer dens ramme de sidste serveringsmodeller i hukommelsen for bedre ydeevne.

Efter at vi havde estimeret omkostninger ved at bruge multi-model endpoints vs. standard endpoints, fandt vi ud af, at det potentielt kunne føre til en omkostningsreduktion på ca. 80 %.

Resultatet

I dette afsnit gennemgår vi trinene og resultatet af processen.

Vi bruger notebook-konfigurationen for livscyklus til at gøre det muligt at køre notebooks som behandlingsjob ved at indkapsle notesbogen i en Docker-beholder for at validere koden hurtigere og bruge autostop-mekanismen:

#!/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 kloner sagemaker-run-notesbog GitHub-projekt, og tilføj følgende til containeren:

Vores pip krav
Evnen til at køre notebooks inde fra en notesbog, hvilket gør det muligt for os at bruge multi-processing adfærd til at bruge alle ml.m5.12xlarge instanskernerne

Dette gør os i stand til at køre arbejdsgange, der består af mange notesbøger, der kører som behandlingsjob i en kodelinje, mens vi definerer den instanstype, der skal køres på.

Fordi vi kan tilføje parametre til notesbogen, kan vi skalere vores behandling ved at køre samtidigt på forskellige timer, dage eller måneder for at hente og behandle data.

Vi kan også oprette planlægningsjob, der kører notebooks (og endda begrænser køretiden).

Vi kan også observere de sidste kørsler og deres detaljer, såsom behandlingstid.

Med papirmøllen, der bruges i containeren, kan vi se output fra hver kørsel, hvilket hjælper os med at fejlsøge i produktionen.

Vores notebook output gennemgang er i form af en standard skrivebeskyttet notesbog.

Multi-processing-udnyttelse hjælper os med at skalere på hver notebook-behandling og udnytte alle dens kerner. Vi genererede funktioner i andre notebooks, der kan udføre tung behandling, såsom følgende:

Eksploder JSON'er
Find relevante rækker i en DataFrame, mens hovednotesbogen opdeler DataFrame i #cpu-cores elementer
Kør clustering pr. advarselstype handlinger samtidigt

Vi tilføjer derefter disse funktionelle notesbøger til den container, der kører notesbogen som et behandlingsjob. Se følgende Docker-fil (læg mærke til COPY-kommandoerne):

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

Resultater

I løbet af forskningsfasen vurderede vi muligheden for at køre vores notebooks, som den er, for at eksperimentere og evaluere, hvordan vores kode klarer sig på alle vores relevante data, ikke kun et udsnit af data. Vi fandt ud af, at indkapsling af vores notebooks ved hjælp af behandlingsjob kan passe godt for os, fordi vi ikke behøver at omskrive kode, og vi kan udnytte kraften i AWS-beregningsoptimerede og hukommelsesoptimerede forekomster og nemt følge processens status.

Under slutningsvurderingen evaluerede vi forskellige SageMaker-slutpunktsløsninger. Vi fandt ud af, at brugen af et multi-model slutpunkt kan hjælpe os med at betjene cirka 50 kunder, der hver har flere (ca. 10) modeller i en enkelt instans, hvilket kan opfylde vores begrænsninger med lav latency og derfor spare os for op til 80 % af omkostningerne .

Med denne løsningsarkitektur var vi i stand til at reducere vores kunders MTTR, hvilket er en vigtig metrik til at måle succes ved hjælp af vores platform. Det reducerer den samlede tid fra svaret på vores advarselslink, som beskriver et problem i dine systemer, til du er færdig med at undersøge problemet ved hjælp af vores platform. I undersøgelsesfasen måler vi brugernes handlinger med og uden vores ML-anbefalingsløsning. Dette hjælper os med at give anbefalinger til den bedste handling for at løse det specifikke problem hurtigere og lokalisere uregelmæssigheder for at identificere den faktiske årsag til problemet.

Konklusion og næste skridt

I dette indlæg delte vi, hvordan Logz.io brugte SageMaker til at forbedre MTTD og MTTR.

Som et næste skridt overvejer vi at udvide løsningen med følgende funktioner:

Vi opfordrer dig til at prøve SageMaker notesbøger. For flere eksempler, tjek SageMaker eksempler på GitHub repo.

Om forfatterne

Amit Gross leder forskningsafdelingen i Logz.io, som er ansvarlig for AI-løsningerne af alle Logz.io produkter, fra forskningsfasen til integrationsfasen. Forud for Logz.io har Amit ledet både datavidenskabs- og sikkerhedsforskningsgrupper hos Here inc. og Cellebrite inc. Amit har M.Sc i datalogi fra Tel-Aviv University.

Yaniv Vaknin er Machine Learning Specialist hos Amazon Web Services. Før AWS havde Yaniv lederstillinger hos AI-startups og Enterprise, herunder medstifter og CEO af Dipsee.ai. Yaniv arbejder med AWS-kunder for at udnytte kraften i Machine Learning til at løse opgaver i den virkelige verden og opnå værdi. I sin fritid nyder Yaniv at spille fodbold med sine drenge.

Eitan Sela er en Machine Learning Specialist Solutions Architect med Amazon Web Services. Han arbejder sammen med AWS-kunder for at yde vejledning og teknisk assistance og hjælpe dem med at bygge og betjene maskinlæringsløsninger på AWS. I sin fritid nyder Eitan at jogge og læse de seneste maskinlæringsartikler.