Kuidas Logz.io kiirendab ML-i soovitusi ja anomaaliate tuvastamise lahendusi Amazon SageMakeriga

Taasavaldanud Platon

järgijaid: 0

Logz.io on AWS-i partnervõrgustiku (APN) arenenud tehnoloogiapartner AWS-i pädevused DevOpsis, turvalisuses ning andmetes ja analüüsis. Logz.io pakub tarkvara kui teenuse (SaaS) jälgimisplatvormi, mis põhineb oma klassi parimatel avatud lähtekoodiga tarkvaralahendustel logi-, mõõdiku- ja jälgimisanalüütika jaoks. Kliendid saadavad erinevatest andmeallikatest Logz.io-le üha rohkem andmeid, et hallata oma rakenduste ja teenuste tervist ja jõudlust. See võib olla tohutu uutele kasutajatele, kes soovivad navigeerida erinevatel aja jooksul loodud armatuurlaudadel, töödelda erinevaid hoiatusteateid ja ühendada punkte tootmisprobleemide tõrkeotsingul.

Keskmine tuvastamise aeg (MTTD) ja keskmine eraldusvõime saavutamise aeg (MTTR) on meie klientide jaoks peamised mõõdikud. Nende arvutamiseks mõõdetakse aega, mille jooksul meie platvormi kasutaja alustab probleemi uurimist (nt tootmisteenuse lõppemist) kuni hetkeni, mil ta lõpetab konkreetse uurimisega seotud toimingute tegemise platvormil.

Et aidata klientidel MTTD-d ja MTTR-i vähendada, kasutab Logz.io masinõpet (ML), et pakkuda soovitusi asjakohaste armatuurlaudade ja päringute jaoks ning teha kõrvalekaldeid iseõppimise teel. Selle tulemusena on tavakasutaja varustatud kogu oma ettevõtte koondkogemusega, kasutades paljude tarkust. Leidsime, et meie lahendus võib vähendada MTTR-i kuni 20%.

MTTD vähenedes saavad kasutajad probleemi tuvastada ja selle kiiremini lahendada. Meie andmesemantiline kiht sisaldab semantikat uurimise alustamiseks ja peatamiseks ning iga toimingu populaarsust, mida kasutaja konkreetse hoiatuse suhtes teeb.

Selles postituses jagame, kuidas Logz.io kasutas Amazon SageMaker et vähendada aega ja vaeva meie kontseptsiooni tõestamiseks (POC), katseteks alates uuringust kuni tootmise hindamiseni ja kuidas me vähendasime oma tootmiskulusid.

Väljakutse

Kuni Logz.io kasutas SageMakerit, oli aeg uurimistöö ja POC-testimise ning tootmiskatsete vahel üsna pikk. Selle põhjuseks oli asjaolu, et andmete kogumiseks, puhastamiseks ja normaliseerimiseks pidime looma Sparki töökohad. DevOps nõudis seda tööd iga andmeallika lugemiseks. DevOps ja andmetehnoloogia oskused ei kuulu meie ML-i meeskonna hulka ning see põhjustas meeskondade vahel suure sõltuvuse.

Teine väljakutse oli pakkuda oma toodetele ML-i järeldusteenust, saavutades samal ajal optimaalse kulu ja jõudluse suhte. Meie optimaalne stsenaarium on arvutusüksuse võimalikult paljude mudelite toetamine, pakkudes samal ajal klientidelt paljude mudelitega samaaegset koostööd. Järeldusaja osas oli meil paindlikkus, sest järeldusteenuse andmevoo esialgne aken on 5-minutiline logide ämber.

Uuringute etapp

Andmeteadus on iteratiivne protsess, mis nõuab uurimistööks interaktiivset arenduskeskkonda, mis kinnitab andmeväljundit igal iteratsioonil ja andmetöötlusel. Seetõttu julgustame oma ML-i teadlasi märkmikke kasutama.

Iteratsioonitsükli kiirendamiseks tahtsime oma sülearvutite koodi testida tegelike tootmisandmetega, samal ajal seda mastaapselt käivitades. Lisaks soovisime vältida DevOpsi ja andmetöötluse kitsaskohti tootmise esialgse testimise ajal, võimaldades samal ajal vaadata väljundeid ja proovida koodi käitusaega hinnata.

Selle rakendamiseks soovisime anda oma andmeteaduse meeskonnale täieliku kontrolli ja täieliku vastutuse alates uurimistööst kuni tootmise esialgse katsetamiseni. Vajasime neid andmete hõlpsaks hankimiseks, säilitades samal ajal andmetele juurdepääsu haldamise ja jälgides seda juurdepääsu. Samuti pidid nad oma kohandatud POC-sülearvutid lihtsalt skaleeritaval viisil tootmisse juurutama, jälgides samal ajal käitusaega ja eeldatavaid kulusid.

Hindamisfaas

Selle etapi jooksul hindasime mõnda ML-i platvormi, et toetada nii koolituse kui ka teenindamise nõudeid. Leidsime, et SageMaker on meie kasutusjuhtumite jaoks kõige sobivam, kuna see toetab nii koolitust kui ka järeldusi. Lisaks on see kohandatav, nii et saame seda kohandada vastavalt meie eelistatud uurimisprotsessile.

Algselt alustasime kohalikest märkmikest, testides erinevaid raamatukogusid. Meil tekkis probleeme tohutute andmete hankimisel tootmisest. Hiljem jäime modelleerimisfaasi punkti, mis võttis kohalikul masinal mitu tundi.

Hindasime paljusid lahendusi ja valisime lõpuks järgmise arhitektuuri:

DataPlate - avatud lähtekoodiga versioon DataPlate aitas meil Sparki kasutades oma andmeid hõlpsalt tõmmata ja ühendada Amazon EMR klastreid lihtsa SQL-iga, jälgides samal ajal juurdepääsu andmetele
SageMakeri märkmiku eksemplari ja töötlemistööd - See aitas meil parandada käitusaja skaleeritavust ning masinatüüpide ja ML-raamistike paindlikkust, tehes samal ajal koodiga koostööd Git-ühenduse kaudu

Uurimisfaasi lahenduse arhitektuur

Järgnev diagramm illustreerib uurimisfaasi lahendusarhitektuuri ja koosneb järgmistest komponentidest:

SageMakeri märkmikud – Andmeteadlased kasutavad neid märkmikud oma uurimistööd läbi viia.
AWS lambda funktsioon - AWS Lambda on serverita lahendus, mis käivitab nõudmisel töötlemistööd. Töö kasutab Dockeri konteinerit sülearvutiga, mida tahame katse ajal käitada, koos kõigi meie levinud failidega, mis peavad sülearvutit toetama (requirements.txt ja mitme töötlusega funktsioonide kood eraldi märkmikus).
Amazon ECR - Amazoni elastsete konteinerite register (Amazon ECR) hoiab meie Dockeri konteinerit.
SageMakeri töötlemistöö – Me saame seda juhtida andmetöötlustöö mis tahes ML-masinas ja see töötab meie sülearvuti parameetritega.
DataPlate – See teenus aitab meil SQL-i kasutada ja mitme andmeallikaga hõlpsalt liituda. See tõlgib selle Sparki koodiks ja optimeerib seda, jälgides samal ajal juurdepääsu andmetele ja aidates vähendada andmetega seotud rikkumisi. Xtra versioon pakkus veelgi rohkem võimalusi.
Amazon EMR – See teenus käivitab meie andmete väljavõtteid töökoormusena Sparki kaudu, võttes ühendust kõigi meie andmeressurssidega.

SageMakeri sülearvuti eksemplari elutsükliga saame juhtida sülearvuti eksemplari maksimaalset käitusaega, kasutades autostop.py šabloon skript.

Pärast ML-i raamistike testimist valisime oma rühmitamise ja järjestamise faaside jaoks SageMaker MXNeti tuuma.

Sülearvuti koodi testimiseks meie tootmisandmetel kasutasime sülearvutit, kapseldades selle Amazon ECS-i Dockeri kaudu, ja käitasime seda töötlemistööna, et kontrollida maksimaalset käitusaega erinevat tüüpi masinatel.

Dockeri konteiner aitab meil ka sülearvutite testide vahel ressursse jagada. Mõnel juhul kutsub sülearvuti teisi sülearvuteid kasutama mitut protsessi, jagades suured andmekaadrid väiksemateks andmekaadriteks, mis võivad samaaegselt töötada suure masinatüübi igas vCPU-s.

Reaalajas tootmise järelduste lahendus

Uurimisfaasis kasutasime Parketti Amazoni lihtne salvestusteenus (Amazon S3) failid, et säilitada meie soovitused. Neid tarbitakse üks kord päevas meie inseneritorustikust, et lisada soovitused meie hoiatusmehhanismile.

Meie tegevuskava nõuab aga suuremat värskendussageduse lahendust ja pikemas perspektiivis ei piisa kord päevas tõmbamisest, sest soovime anda soovitusi ka uurimise ajal.

Selle lahenduse ulatuslikuks rakendamiseks testisime oma anomaaliate tuvastamise uuringus enamikku SageMakeri lõpp-punkti lahendustest. Testisime 500 eelehitatud mudelit ühe erinevat tüüpi lõpp-punkti masinaga ja kasutasime lõpp-punkti päringute tegemiseks samaaegseid mitme lõimega kliente. Mõõtsime reaktsiooniaega, protsessorit, mälu ja muid mõõdikuid (lisateabe saamiseks vt Jälgige Amazon SageMakerit rakendusega Amazon CloudWatch). Leidsime, et mitme mudeliga lõpp-punkt sobib meie kasutusjuhtudeks ideaalselt.

Mitme mudeliga lõpp-punkt võib meie kulusid järsult vähendada võrreldes ühe lõpp-punkti või isegi Kubernetesiga Flaski (või muude Pythoni) veebiteenuste kasutamiseks. Meie esimene eeldus oli, et peame pakkuma iga kliendi jaoks ühe lõpp-punkti, kasutades 4-vCPU-ga väikest masinat, ja esitama keskmiselt päringu nelja spetsiaalse mudeli kohta, kuna iga vCPU teenindab ühte mudelit. Mitme mudeli lõpp-punktiga saaksime koondada rohkem kliente ühte mitme lõpp-punktiga masinasse.

Meil oli mudeli- ja kodeerimisfailid iga kliendi kohta ning pärast koormustestide tegemist otsustasime, et suudame teenindada 50 klienti, millest igaüks kasutab 10 mudelit ja isegi kasutades meie lahenduste jaoks väikseimat ml.t2.medium eksemplari.

Selles etapis kaalusime kasutamist mitme mudeli lõpp-punktid. Mitme mudeli lõpp-punktid pakuvad skaleeritavat ja kulutõhusat lahendust suure hulga mudelite juurutamiseks, võimaldades teil hostida mitut mudelit ühe järelduskonteineriga. See vähendab hostimiskulusid, parandades lõpp-punkti kasutamist võrreldes mitme väikese ühe mudeli lõpp-punkti kasutamisega, millest igaüks teenindab ühte klienti. See vähendab ka juurutamise üldkulusid, kuna SageMaker haldab mudelite mällu laadimist ja nende skaleerimist nende liiklusmustrite alusel.

Lisaks on mitme mudeli lõpp-punkti eeliseks see, et kui teil on teatud klientidelt kõrge järelduste määr, säilitab selle raamistik parema jõudluse huvides mällu viimaseid teenindavaid mudeleid.

Pärast seda, kui hindasime kulusid mitme mudeli ja standardsete lõpp-punktide abil, avastasime, et see võib kaasa tuua kulude vähenemise ligikaudu 80%.

Tulemus

Selles jaotises käsitleme protsessi etappe ja tulemusi.

Kasutame sülearvuti elutsükli konfiguratsiooni, et võimaldada sülearvutite käitamist töötlemistöödena, kapseldades sülearvuti Dockeri konteinerisse, et kood kiiremini valideerida ja automaatse peatamise mehhanismi kasutada:

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

Kloonime sagemaker-run-märkmik GitHubi projekti ja lisage konteinerisse järgmine:

Meie pipi nõuded
Võimalus käitada märkmikke sülearvuti sees, mis võimaldab meil mitut töötlemiskäitumist, et kasutada ära kõik ml.m5.12xsuured eksemplari tuumad

See võimaldab meil käivitada töövooge, mis koosnevad paljudest märkmikutest, mis töötavad koodireas töötlemistöödena, määratledes samal ajal käitatava eksemplari tüübi.

Kuna saame sülearvutile parameetreid lisada, saame oma töötlemist skaleerida, käivitades samaaegselt erinevatel tundidel, päevadel või kuudel, et andmeid tõmmata ja töödelda.

Samuti saame luua ajastamistöid, mis käitavad märkmikke (ja isegi piirata tööaega).

Samuti saame jälgida viimaseid jookse ja nende üksikasju, näiteks töötlemisaega.

Konteineris kasutatava paberiveski abil saame vaadata iga käitamise väljundit, mis aitab meil tootmises siluda.

Meie sülearvuti väljundi ülevaade on standardse kirjutuskaitstud sülearvuti kujul.

Mitmetöötluse kasutamine aitab meil iga sülearvuti töötlemist skaleerida ja kasutada kõiki selle tuumasid. Lõime teistes sülearvutites funktsioone, mis suudavad teha rasket töötlemist, näiteks järgmised:

Plahvatage JSON-id
Otsige DataFrame'ist üles asjakohased read, samal ajal kui põhimärkmik jagab DataFrame'i #cpu-cores elemendid
Käivitage üheaegselt rühmitamist hoiatuse tüübi järgi

Seejärel lisame need funktsionaalsed märkmikud konteinerisse, mis käitab sülearvutit töötlemistööna. Vaadake järgmist Dockeri faili (pange tähele COPY käske):

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

Tulemused

Uurimisfaasis hindasime võimalust kasutada oma märkmikke nii, nagu katsetada ja hinnata, kuidas meie kood toimib kõigi meie asjakohaste andmete, mitte ainult andmete näidise puhul. Leidsime, et meie sülearvutite kapseldamine töötlemistöödega võib meile suurepäraselt sobida, kuna me ei pea koodi ümber kirjutama ja saame kasutada AWS-i arvutus- ja mäluoptimeeritud eksemplare ning protsessi olekut hõlpsalt jälgida.

Järelduste hindamise käigus hindasime erinevaid SageMakeri lõpp-punkti lahendusi. Leidsime, et mitme mudeli lõpp-punkti kasutamine võib aidata meil teenindada ligikaudu 50 klienti, millest igaühel on ühes eksemplaris mitu (umbes 10) mudelit, mis vastab meie madala latentsusaja piirangutele ja säästab seega kuni 80% kuludest. .

Selle lahenduse arhitektuuriga suutsime vähendada oma klientide MTTR-i, mis on meie platvormi kasutamise edukuse mõõtmise peamine mõõdik. See vähendab koguaega, mis kulub meie hoiatuslingile, mis kirjeldab teie süsteemides esinevat probleemi, vastamisest kuni meie platvormi abil probleemi uurimise lõpetamiseni. Uurimisetapis mõõdame kasutajate tegevust nii meie ML-soovituslahendusega kui ka ilma. See aitab meil anda soovitusi konkreetse probleemi kiiremaks lahendamiseks parimaks toiminguks ja tuvastada kõrvalekalded, et tuvastada probleemi tegelik põhjus.

Järeldus ja järgmised sammud

Selles postituses jagasime, kuidas Logz.io kasutas SageMakerit MTTD ja MTTR parandamiseks.

Järgmise sammuna kaalume lahenduse laiendamist järgmiste funktsioonidega.

Soovitame teil proovida SageMakeri märkmikud. Rohkemate näidete saamiseks vaadake SageMaker GitHubi repo näited.

Autoritest

Amit Gross juhib Logz.io uurimisosakonda, mis vastutab kõikide Logz.io toodete tehisintellektilahenduste eest alates uurimisfaasist kuni integratsioonifaasini. Enne Logz.io't on Amit juhtinud nii andmeteaduse kui ka turvalisuse uurimisrühmi ettevõttes Here inc. ja Cellebrite inc. Amit on Tel-Avivi ülikoolist omandanud arvutiteaduse magistrikraadi.

Janiv Vaknin on Amazon Web Servicesi masinõppe spetsialist. Enne AWS-i oli Yaniv juhtivatel kohtadel tehisintellekti idufirmades ja Enterprise'is, sealhulgas Dipsee.ai kaasasutaja ja tegevjuht. Yaniv teeb koostööd AWS-i klientidega, et rakendada masinõppe võimsust, et lahendada reaalseid ülesandeid ja saada väärtust. Vabal ajal mängib Yaniv oma poistega jalgpalli.

Eitan Sela on Amazon Web Servicesi masinõppe spetsialisti lahenduste arhitekt. Ta teeb koostööd AWS-i klientidega, et pakkuda juhiseid ja tehnilist abi, aidates neil AWS-is masinõppelahendusi luua ja kasutada. Vabal ajal naudib Eitan sörkimist ja uusimate masinõppeartikleid lugemist.