Hvordan Logz.io akselererer ML-anbefalinger og anomalideteksjonsløsninger med Amazon SageMaker

Publisert av Platon

Følgere: 0

Logz.io er en AWS Partner Network (APN) Advanced Technology Partner med AWS-kompetanse innen DevOps, sikkerhet og data og analyse. Logz.io tilbyr en programvare som en tjeneste (SaaS) observerbarhetsplattform basert på klassens beste åpen kildekode-programvareløsninger for logg-, metrisk- og sporingsanalyse. Kunder sender en økende mengde data til Logz.io fra ulike datakilder for å administrere helsen og ytelsen til applikasjonene og tjenestene deres. Det kan være overveldende for nye brukere som ønsker å navigere på tvers av de forskjellige dashbordene som er bygget over tid, behandle forskjellige varslinger og koble sammen punktene når de feilsøker produksjonsproblemer.

Gjennomsnittlig tid til å oppdage (MTTD) og gjennomsnittlig tid til oppløsning (MTTR) er nøkkeltall for våre kunder. De beregnes ved å måle tiden en bruker på plattformen vår begynner å undersøke et problem (for eksempel produksjonstjeneste nede) til det punktet når de slutter å utføre handlinger på plattformen som er relatert til den spesifikke undersøkelsen.

For å hjelpe kunder med å redusere MTTD og MTTR, henvender Logz.io seg til maskinlæring (ML) for å gi anbefalinger for relevante dashboards og spørringer og utføre avviksdeteksjon via selvlæring. Som et resultat er den gjennomsnittlige brukeren utstyrt med den samlede opplevelsen av hele selskapet, og utnytter visdommen til mange. Vi fant ut at vår løsning kan redusere MTTR med opptil 20 %.

Når MTTD reduseres, kan brukere identifisere problemet og løse det raskere. Det semantiske datalaget vårt inneholder semantikk for å starte og stoppe en undersøkelse, og populariteten til hver handling brukeren gjør med hensyn til et spesifikt varsel.

I dette innlegget deler vi hvordan Logz.io brukte Amazon SageMaker for å redusere tiden og innsatsen for vårt proof of concept (POC), eksperimenter fra forskning til produksjonsevaluering, og hvordan vi reduserte produksjonsslutningskostnadene våre.

Utfordringen

Inntil Logz.io brukte SageMaker, var tiden mellom forskning til POC-testing og eksperimenter på produksjon ganske lang. Dette var fordi vi trengte å opprette Spark-jobber for å samle inn, rense og normalisere dataene. DevOps krevde dette arbeidet for å lese hver datakilde. DevOps og dataingeniørferdigheter er ikke en del av vårt ML-team, og dette forårsaket en høy avhengighet mellom teamene.

En annen utfordring var å tilby en ML-slutningstjeneste til produktene våre samtidig som vi oppnådde optimalt forhold mellom kostnad og ytelse. Vårt optimale scenario er å støtte så mange modeller som mulig for en dataenhet, samtidig som det gir høy samtidighet fra kunder med mange modeller. Vi hadde fleksibilitet på slutningstiden vår, fordi vårt første vindu for datastrømmen for slutningstjenesten er 5 minutters bøtte med logger.

Forskningsfase

Datavitenskap er en iterativ prosess som krever et interaktivt utviklingsmiljø for forskning, som validerer datautgangen på hver iterasjon og databehandling. Derfor oppfordrer vi våre ML-forskere til å bruke notatbøker.

For å akselerere iterasjonssyklusen ønsket vi å teste koden til våre bærbare datamaskiner på ekte produksjonsdata, mens vi kjører den i skala. Videre ønsket vi å unngå flaskehalsen med DevOps og datateknikk under den første testen i produksjonen, samtidig som vi hadde muligheten til å se utdataene og prøve å estimere kodens kjøretid.

For å implementere dette ønsket vi å gi datavitenskapsteamet vårt full kontroll og ende-til-ende-ansvar fra forskning til første test på produksjon. Vi trengte at de enkelt kunne hente data, samtidig som vi beholdt administrasjonen av datatilgang og overvåket denne tilgangen. De trengte også å enkelt distribuere de tilpassede POC-notebookene sine i produksjon på en skalerbar måte, mens de overvåket kjøretiden og forventede kostnader.

Evalueringsfase

I løpet av denne fasen evaluerte vi noen få ML-plattformer for å støtte både opplærings- og serveringskrav. Vi fant ut at SageMaker er den mest hensiktsmessige for våre brukstilfeller fordi den støtter både opplæring og slutning. Videre kan den tilpasses, slik at vi kan skreddersy den i henhold til vår foretrukne forskningsprosess.

I utgangspunktet tok vi utgangspunkt i lokale notatbøker, og testet ulike biblioteker. Vi fikk problemer med å hente massive data fra produksjonen. Senere ble vi sittende fast i et punkt i modelleringsfasen som tok mange timer på en lokal maskin.

Vi evaluerte mange løsninger og valgte til slutt følgende arkitektur:

DataPlate – Åpen kildekode-versjonen av DataPlate hjalp oss med å trekke og slå sammen dataene våre enkelt ved å bruke vår Spark Amazon EMR klynger med en enkel SQL, mens du overvåker datatilgangen
SageMaker notatbokforekomst og behandlingsjobber – Dette hjalp oss med skalerbarheten til kjøretid og fleksibiliteten til maskintyper og ML-rammeverk, mens vi samarbeidet med koden vår via en Git-tilkobling

Forskningsfase løsningsarkitektur

Følgende diagram illustrerer løsningsarkitekturen til forskningsfasen, og består av følgende komponenter:

SageMaker notatbøker – Dataforskere bruker disse notatbøker å gjennomføre sin forskning.
AWS Lambda-funksjon - AWS Lambda er en serverløs løsning som kjører en prosesseringsjobb på forespørsel. Jobben bruker en Docker-beholder med notatboken vi ønsker å kjøre under eksperimentet vårt, sammen med alle våre vanlige filer som må støtte notatboken (requirements.txt og multiprosesseringsfunksjonskoden i en egen notatbok).
Amazon ECR - Amazon Elastic Container Registry (Amazon ECR) lagrer vår Docker-beholder.
SageMaker Behandler jobb – Vi kan kjøre dette databehandlingsjobb på hvilken som helst ML-maskin, og den kjører vår bærbare med parametere.
DataPlate – Denne tjenesten hjelper oss å bruke SQL og enkelt koble sammen flere datakilder. Den oversetter den til Spark-kode og optimerer den, samtidig som den overvåker datatilgang og bidrar til å redusere datainnbrudd. Xtra-versjonen ga enda flere muligheter.
Amazon EMR – Denne tjenesten kjører datauttrekkene våre som arbeidsbelastninger over Spark, og kontakter alle dataressursene våre.

Med SageMaker notebook-forekomstlivssyklus kan vi kontrollere maksimal kjøretid for notebook-forekomster ved å bruke autostop.py mal skript.

Etter å ha testet ML-rammeverket, valgte vi SageMaker MXNet-kjernen for våre klynge- og rangeringsfaser.

For å teste notisbokkoden på produksjonsdataene våre, kjørte vi notisboken ved å innkapsle den via Docker i Amazon ECS og kjørte den som en behandlingsjobb for å validere maksimal kjøretid på forskjellige typer maskiner.

Docker-beholderen hjelper oss også med å dele ressurser blant bærbare tester. I noen tilfeller kaller en notatbok andre notatbøker for å bruke en multiprosess ved å dele opp store datarammer i mindre datarammer, som kan kjøres samtidig på hver vCPU i en stor maskintype.

Produksjonsslutningsløsningen i sanntid

I forskningsfasen brukte vi Parkett Amazon enkel lagringstjeneste (Amazon S3)-filer for å opprettholde våre anbefalinger. Disse konsumeres en gang om dagen fra vår tekniske pipeline for å knytte anbefalingene til varslingsmekanismen vår.

Veikartet vårt krever imidlertid en løsning med høyere oppdateringsfrekvens, og å trekke én gang om dagen er ikke nok på lang sikt, fordi vi ønsker å gi anbefalinger selv under undersøkelsen.

For å implementere denne løsningen i stor skala, testet vi de fleste av SageMaker-endepunktløsningene i vår forskning om anomalideteksjon. Vi testet 500 av de forhåndsbygde modellene med en enkelt endepunktsmaskin av forskjellige typer og brukte samtidige flertrådede klienter for å utføre forespørsler til endepunktet. Vi målte responstid, CPU, minne og andre beregninger (for mer informasjon, se Overvåk Amazon SageMaker med Amazon CloudWatch). Vi fant ut at multi-modell endepunktet passer perfekt for våre brukstilfeller.

Et endepunkt med flere modeller kan redusere kostnadene våre dramatisk sammenlignet med et enkelt endepunkt eller til og med Kubernetes for å bruke Flask (eller andre Python) nettjenester. Vår første antakelse var at vi må gi et enkelt endepunkt, ved hjelp av en 4-vCPU liten maskin, for hver kunde, og i gjennomsnitt spørre fire dedikerte modeller, fordi hver vCPU tjener én modell. Med flermodellendepunktet kunne vi samle flere kunder på én enkelt multi-endepunktsmaskin.

Vi hadde en modell og kodingsfiler per kunde, og etter å ha utført belastningstester, fant vi ut at vi kunne betjene 50 kunder, hver med 10 modeller og til og med bruke den minste ml.t2.medium-forekomsten for våre løsninger.

På dette stadiet vurderte vi å bruke flermodell-endepunkter. Multi-modell endepunkter gir en skalerbar og kostnadseffektiv løsning for å distribuere et stort antall modeller, slik at du kan være vert for flere modeller med en enkelt konklusjonsbeholder. Dette reduserer hostingkostnadene ved å forbedre endepunktutnyttelsen sammenlignet med å bruke flere små enkeltmodellendepunkter som hver betjener en enkelt kunde. Det reduserer også distribusjonskostnader fordi SageMaker administrerer lasting av modeller i minnet og skalerer dem basert på trafikkmønstrene til dem.

Videre er endepunktfordelen med flere modeller at hvis du har en høy slutningsrate fra spesifikke kunder, bevarer rammeverket de siste serveringsmodellene i minnet for bedre ytelse.

Etter at vi estimerte kostnadene ved å bruke multi-modell endepunkter vs. standard endepunkter, fant vi ut at det potensielt kan føre til kostnadsreduksjon på omtrent 80 %.

Resultatet

I denne delen gjennomgår vi trinnene og resultatet av prosessen.

Vi bruker livssykluskonfigurasjonen for den bærbare datamaskinen for å muliggjøre kjøring av notatbøkene som behandlingsjobber, ved å kapsle inn notatboken i en Docker-beholder for å validere koden raskere og bruke 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 kloner sagemaker-run-notebook GitHub-prosjektet, og legg til følgende i beholderen:

Våre pip-krav
Muligheten til å kjøre notatbøker fra en notatbok, noe som gjør oss i stand til å bruke multi-prosessering av alle ml.m5.12xlarge forekomstkjernene

Dette gjør oss i stand til å kjøre arbeidsflyter som består av mange bærbare datamaskiner som kjører som behandlingsjobber i en kodelinje, mens vi definerer forekomsttypen som skal kjøres på.

Fordi vi kan legge til parametere til den bærbare datamaskinen, kan vi skalere behandlingen vår ved å kjøre samtidig til forskjellige timer, dager eller måneder for å hente og behandle data.

Vi kan også lage planleggingsjobber som kjører notatbøker (og til og med begrense kjøretiden).

Vi kan også observere de siste kjøringene og deres detaljer, for eksempel behandlingstid.

Med papirfabrikken som brukes i beholderen, kan vi se produksjonen av hver kjøring, noe som hjelper oss å feilsøke i produksjonen.

Vår notisbok-utdatagjennomgang er i form av en standard skrivebeskyttet notatbok.

Utnyttelse av flere prosesser hjelper oss å skalere på hver bærbar PC-behandling og utnytte alle kjernene. Vi genererte funksjoner i andre bærbare datamaskiner som kan gjøre tung prosessering, for eksempel følgende:

Explode JSONs
Finn relevante rader i en DataFrame mens hovednotatboken deler DataFrame inn #cpu-cores elementer
Kjør gruppering per varslingstype handlinger samtidig

Vi legger deretter til disse funksjonelle notatbøkene i beholderen som kjører notatboken som en behandlingsjobb. Se følgende Docker-fil (legg merke til COPY-kommandoene):

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øpet av forskningsfasen evaluerte vi muligheten til å kjøre bærbare datamaskiner som de er for å eksperimentere og evaluere hvordan koden vår presterer på alle relevante data, ikke bare et utvalg data. Vi fant ut at innkapsling av bærbare PC-er ved hjelp av prosesseringsjobber kan passe godt for oss, fordi vi ikke trenger å skrive om kode og vi kan utnytte kraften til AWS-beregningsoptimaliserte og minneoptimaliserte forekomster og følge statusen til prosessen enkelt.

Under slutningsvurderingen evaluerte vi ulike SageMaker-endepunktløsninger. Vi fant ut at bruk av et endepunkt med flere modeller kan hjelpe oss med å betjene omtrent 50 kunder, som hver har flere (omtrent 10) modeller i en enkelt forekomst, noe som kan møte begrensningene våre med lav latens, og derfor spare oss for opptil 80 % av kostnadene .

Med denne løsningsarkitekturen klarte vi å redusere MTTR for kundene våre, som er en hovedmåling for å måle suksess ved å bruke plattformen vår. Det reduserer den totale tiden fra du svarer på varslingslenken vår, som beskriver et problem i systemene dine, til du er ferdig med å undersøke problemet ved å bruke plattformen vår. I undersøkelsesfasen måler vi brukernes handlinger med og uten vår ML-anbefalingsløsning. Dette hjelper oss med å gi anbefalinger for den beste handlingen for å løse det spesifikke problemet raskere og finne uregelmessigheter for å identifisere den faktiske årsaken til problemet.

Konklusjon og neste steg

I dette innlegget delte vi hvordan Logz.io brukte SageMaker for å forbedre MTTD og MTTR.

Som et neste trinn vurderer vi å utvide løsningen med følgende funksjoner:

Vi oppfordrer deg til å prøve SageMaker notatbøker. For flere eksempler, sjekk ut SageMaker eksempler GitHub repo.

Om forfatterne

Amit Gross leder forskningsavdelingen til Logz.io, som er ansvarlig for AI-løsningene til alle Logz.io-produkter, fra forskningsfasen til integrasjonsfasen. Før Logz.io har Amit ledet både datavitenskapelige og sikkerhetsforskningsgrupper hos Here inc. og Cellebrite inc. Amit har M.Sc i informatikk fra Tel-Aviv University.

Yaniv Vaknin er maskinlæringsspesialist hos Amazon Web Services. Før AWS hadde Yaniv lederstillinger med AI-startups og Enterprise, inkludert medgründer og administrerende direktør i Dipsee.ai. Yaniv jobber med AWS-kunder for å utnytte kraften til maskinlæring for å løse oppgaver i den virkelige verden og oppnå verdi. På fritiden liker Yaniv å spille fotball med guttene sine.

Eitan Sela er en maskinlæringsspesialist løsningsarkitekt med Amazon Web Services. Han jobber med AWS-kunder for å gi veiledning og teknisk assistanse, og hjelpe dem med å bygge og drifte maskinlæringsløsninger på AWS. På fritiden liker Eitan å jogge og lese de siste maskinlæringsartiklene.