Kako Logz.io pospešuje priporočila ML in rešitve za odkrivanje anomalij z Amazon SageMaker

Ponovno objavil Platon

Spremljevalci: 0

Logz.io je napredni tehnološki partner AWS Partner Network (APN) z Kompetence AWS na področju DevOps, varnosti ter podatkov in analitike. Logz.io ponuja platformo za opazovanje programske opreme kot storitve (SaaS), ki temelji na najboljših odprtokodnih programskih rešitvah za log, metriko in analitiko sledenja. Stranke pošiljajo vedno več podatkov na Logz.io iz različnih virov podatkov za upravljanje zdravja in učinkovitosti svojih aplikacij in storitev. Za nove uporabnike, ki želijo krmariti po različnih nadzornih ploščah, ustvarjenih skozi čas, obdelati različna opozorilna obvestila in povezati pike pri odpravljanju težav s proizvodnjo, je lahko izjemno.

Srednji čas do odkrivanja (MTTD) in srednji čas do razrešitve (MTTR) sta ključni meritvi za naše stranke. Izračunajo se z merjenjem časa, v katerem uporabnik na naši platformi začne raziskovati težavo (na primer izpad produkcijske storitve) do točke, ko preneha izvajati dejanja na platformi, ki so povezana z določeno preiskavo.

Da bi strankam pomagal zmanjšati MTTD in MTTR, se Logz.io obrača na strojno učenje (ML), da zagotovi priporočila za ustrezne nadzorne plošče in poizvedbe ter izvede zaznavanje anomalij s samoučenjem. Posledično je povprečen uporabnik opremljen z združenimi izkušnjami celotnega podjetja, ki izkoriščajo modrost mnogih. Ugotovili smo, da lahko naša rešitev zmanjša MTTR do 20 %.

Ko se MTTD zmanjša, lahko uporabniki prepoznajo težavo in jo hitreje rešijo. Naša semantična plast podatkov vsebuje semantiko za začetek in zaustavitev preiskave ter priljubljenost vsakega dejanja, ki ga uporabnik izvaja glede na določeno opozorilo.

V tej objavi delimo, kako je Logz.io uporabljal Amazon SageMaker zmanjšati čas in trud za naš dokaz koncepta (POC), poskuse od raziskav do ocene proizvodnje in kako smo zmanjšali stroške sklepanja o proizvodnji.

Izziv

Dokler Logz.io ni uporabljal SageMakerja, je bil čas med raziskavami, testiranjem POC in poskusi v proizvodnji precej dolg. To je bilo zato, ker smo morali ustvariti opravila Spark za zbiranje, čiščenje in normalizacijo podatkov. DevOps je to delo zahteval za branje vsakega vira podatkov. DevOps in veščine podatkovnega inženiringa niso del naše ekipe za strojno učenje, kar je povzročilo veliko odvisnost med ekipama.

Drug izziv je bil zagotoviti storitev sklepanja ML za naše izdelke, hkrati pa doseči optimalno razmerje med stroški in zmogljivostjo. Naš optimalni scenarij podpira čim več modelov za računalniško enoto, hkrati pa zagotavlja visoko sočasnost strank s številnimi modeli. Imeli smo prilagodljivost glede našega časa sklepanja, ker je naše začetno okno podatkovnega toka za storitev sklepanja 5-minutno vedro dnevnikov.

Raziskovalna faza

Podatkovna znanost je ponavljajoč se proces, ki zahteva interaktivno razvojno okolje za raziskovanje, preverjanje izhodnih podatkov pri vsaki ponovitvi in obdelavi podatkov. Zato naše raziskovalce ML spodbujamo k uporabi zvezkov.

Da bi pospešili cikel ponavljanja, smo želeli preizkusiti kodo naših prenosnikov na dejanskih proizvodnih podatkih, medtem ko jo izvajamo v velikem obsegu. Poleg tega smo se želeli izogniti ozkemu grlu DevOps in podatkovnega inženiringa med začetnim preizkusom v proizvodnji, hkrati pa smo imeli možnost ogleda izhodov in poskušali oceniti čas izvajanja kode.

Da bi to izvedli, smo želeli naši skupini za podatkovno znanost zagotoviti popoln nadzor in odgovornost od konca do konca od raziskave do začetnega testiranja proizvodnje. Potrebovali smo jih za enostavno črpanje podatkov, hkrati pa ohranili upravljanje dostopa do podatkov in spremljali ta dostop. Prav tako so morali svoje prenosnike POC po meri enostavno uvesti v proizvodnjo na razširljiv način, pri tem pa spremljati čas delovanja in pričakovane stroške.

Faza ocenjevanja

V tej fazi smo ovrednotili nekaj platform ML, da bi podprli zahteve glede usposabljanja in strežbe. Ugotovili smo, da je SageMaker najprimernejši za naše primere uporabe, ker podpira tako usposabljanje kot sklepanje. Poleg tega je prilagodljiv, tako da ga lahko prilagodimo svojemu želenemu raziskovalnemu procesu.

Sprva smo izhajali iz lokalnih zvezkov in testirali različne knjižnice. Naleteli smo na težave pri črpanju množičnih podatkov iz proizvodnje. Kasneje smo obtičali na točki faze modeliranja, ki je trajala veliko ur na lokalnem stroju.

Ocenili smo številne rešitve in na koncu izbrali naslednjo arhitekturo:

DataPlate – Odprtokodna različica DataPlate nam je z uporabo našega Spark pomagal enostavno črpati in združevati naše podatke Amazonski EMR grozdov s preprostim SQL, medtem ko spremlja dostop do podatkov
Primerek prenosnika SageMaker in opravila obdelave – To nam je pomagalo pri razširljivosti časa izvajanja in prilagodljivosti vrst strojev in ogrodij ML, medtem ko smo sodelovali pri naši kodi prek povezave Git

Raziskovalna faza arhitekture rešitve

Naslednji diagram ponazarja arhitekturo rešitve raziskovalne faze in je sestavljen iz naslednjih komponent:

Prenosniki SageMaker – Te uporabljajo podatkovni znanstveniki zvezki izvajati svoje raziskave.
AWS Lambda funkcija - AWS Lambda je rešitev brez strežnika, ki izvaja obdelavo na zahtevo. Opravilo uporablja vsebnik Docker z zvezkom, ki ga želimo izvajati med našim poskusom, skupaj z vsemi našimi skupnimi datotekami, ki morajo podpirati zvezke (requirements.txt in kodo večprocesnih funkcij v ločenem zvezku).
Amazon ECR - Registar elastičnih zabojnikov Amazon (Amazon ECR) hrani naš vsebnik Docker.
Naloga obdelave SageMaker – To lahko vodimo delo obdelave podatkov na katerem koli stroju ML in poganja naš prenosnik s parametri.
DataPlate – Ta storitev nam pomaga uporabljati SQL in enostavno združiti več virov podatkov. Prevede jo v kodo Spark in jo optimizira, hkrati pa spremlja dostop do podatkov in pomaga zmanjšati kršitve podatkov. Različica Xtra je zagotovila še več možnosti.
Amazonski EMR – Ta storitev izvaja naše ekstrakcije podatkov kot delovne obremenitve preko Spark, pri čemer vzpostavi stik z vsemi našimi podatkovnimi viri.

Z življenjskim ciklom primerka prenosnega računalnika SageMaker lahko nadzorujemo največji čas izvajanja primerka prenosnega računalnika z uporabo autostop.py Predloga skripta.

Po testiranju ogrodij ML smo izbrali jedro SageMaker MXNet za fazo združevanja v gruče in razvrščanja.

Da bi testirali kodo prenosnika na naših proizvodnih podatkih, smo prenosnik zagnali tako, da smo ga enkapsulirali prek Dockerja v Amazon ECS in ga zagnali kot opravilo obdelave, da bi preverili največji čas izvajanja na različnih vrstah strojev.

Vsebnik Docker nam pomaga tudi deliti vire med testi prenosnikov. V nekaterih primerih prenosni računalnik pokliče druge prenosne računalnike, da uporabijo večproces, tako da velike podatkovne okvire razdeli na manjše podatkovne okvire, ki se lahko hkrati izvajajo na vsakem vCPE v veliki vrsti stroja.

Rešitev za sklepanje proizvodnje v realnem času

V fazi raziskave smo uporabili parket Preprosta storitev shranjevanja Amazon (Amazon S3) za ohranitev naših priporočil. Ti se porabijo enkrat na dan iz našega inženirskega cevovoda, da se priporočila priložijo našemu mehanizmu opozoril.

Vendar pa naš časovni načrt zahteva rešitev z višjo hitrostjo osveževanja in vlečenje enkrat na dan dolgoročno ni dovolj, saj želimo zagotoviti priporočila tudi med preiskavo.

Za implementacijo te rešitve v velikem obsegu smo v naši raziskavi odkrivanja nepravilnosti preizkusili večino rešitev končne točke SageMaker. Preizkusili smo 500 vnaprej izdelanih modelov z enim strojem končne točke različnih vrst in uporabili sočasne večnitne odjemalce za izvajanje zahtev do končne točke. Izmerili smo odzivni čas, CPE, pomnilnik in druge meritve (za več informacij glejte Spremljajte Amazon SageMaker z Amazon CloudWatch). Ugotovili smo, da končna točka z več modeli popolnoma ustreza našim primerom uporabe.

Končna točka z več modeli lahko dramatično zmanjša naše stroške v primerjavi z eno samo končno točko ali celo Kubernetesom za uporabo spletnih storitev Flask (ali drugih Python). Naša prva predpostavka je bila, da moramo zagotoviti eno samo končno točko z uporabo majhnega stroja s 4 vCPE za vsako stranko in v povprečju poizvedovati po štirih namenskih modelih, ker vsak vCPE služi enemu modelu. S končno točko z več modeli bi lahko združili več strank na enem stroju z več končnimi točkami.

Imeli smo model in kodirne datoteke za vsako stranko in po opravljenih preskusih obremenitve smo ugotovili, da lahko oskrbujemo 50 strank, pri čemer vsaka uporablja 10 modelov in uporablja celo najmanjšo instanco ml.t2.medium za naše rešitve.

V tej fazi smo razmišljali o uporabi končne točke več modelov. Končne točke z več modeli zagotavljajo razširljivo in stroškovno učinkovito rešitev za uvajanje velikega števila modelov, kar vam omogoča gostovanje več modelov z enim vsebnikom sklepanja. To zmanjša stroške gostovanja z izboljšano uporabo končne točke v primerjavi z uporabo več majhnih končnih točk z enim modelom, od katerih vsaka služi eni stranki. Prav tako zmanjša stroške uvajanja, ker SageMaker upravlja nalaganje modelov v pomnilnik in njihovo skaliranje na podlagi vzorcev prometa do njih.

Poleg tega je prednost večmodelne končne točke v tem, da če imate visoko stopnjo sklepanja pri določenih strankah, njeno ogrodje ohrani zadnje servirane modele v pomnilniku za boljšo zmogljivost.

Potem ko smo ocenili stroške z uporabo večmodelnih končnih točk v primerjavi s standardnimi končnimi točkami, smo ugotovili, da bi to lahko vodilo do zmanjšanja stroškov za približno 80 %.

Rezultat

V tem razdelku pregledamo korake in izid postopka.

Konfiguracijo prenosnega računalnika življenjskega cikla uporabljamo za omogočanje izvajanja prenosnih računalnikov kot opravil obdelave, tako da prenosni računalnik enkapsuliramo v vsebnik Docker, da hitreje potrdimo kodo in uporabimo mehanizem samodejne ustavitve:

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

Kloniramo sagemaker-run-notebook Projekt GitHub in v vsebnik dodajte naslednje:

Naše zahteve za pip
Možnost izvajanja prenosnih računalnikov znotraj prenosnega računalnika, kar nam omogoča večprocesno vedenje za uporabo vseh jeder primerkov ml.m5.12xlarge

To nam omogoča zagon delovnih tokov, ki so sestavljeni iz številnih zvezkov, ki se izvajajo kot opravila obdelave v vrstici kode, medtem ko definiramo vrsto primerka, na katerem se izvaja.

Ker lahko zvezku dodajamo parametre, lahko prilagodimo našo obdelavo tako, da izvajamo istočasno ob različnih urah, dnevih ali mesecih za pridobivanje in obdelavo podatkov.

Ustvarimo lahko tudi opravila za razporejanje, ki poganjajo zvezke (in celo omejijo čas izvajanja).

Prav tako lahko opazujemo zadnje teke in njihove podrobnosti, kot je čas obdelave.

S papirnico, ki se uporablja v zabojniku, si lahko ogledamo izhod vsakega zagona, kar nam pomaga pri odpravljanju napak v proizvodnji.

Naš pregled izpisa zvezka je v obliki standardnega zvezka samo za branje.

Uporaba večprocesnih procesov nam pomaga razširiti obdelavo vsakega prenosnika in uporabiti vsa njegova jedra. V drugih zvezkih smo ustvarili funkcije, ki lahko izvajajo težke obdelave, kot so naslednje:

Razširite datoteke JSON
Poiščite ustrezne vrstice v DataFrame, medtem ko glavni prenosni računalnik razdeli DataFrame #cpu-cores elementi
Istočasno izvajajte dejanja združevanja v skupine glede na vrsto opozorila

Te funkcionalne zvezke nato dodamo v vsebnik, ki poganja zvezke kot opravilo obdelave. Oglejte si naslednjo datoteko Docker (upoštevajte ukaze 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

Rezultati

Med raziskovalno fazo smo ovrednotili možnost izvajanja naših zvezkov kot je, da bi eksperimentirali in ocenili, kako deluje naša koda na vseh naših ustreznih podatkih, ne le na vzorcu podatkov. Ugotovili smo, da je enkapsulacija naših prenosnih računalnikov z uporabo opravil obdelave lahko zelo primerna za nas, ker nam ni treba znova pisati kode in lahko izkoristimo moč instanc, optimiziranih za računalništvo in pomnilnik, ter enostavno sledimo statusu procesa.

Med ocenjevanjem sklepanja smo ovrednotili različne rešitve končnih točk SageMaker. Ugotovili smo, da nam lahko uporaba končne točke z več modeli pomaga služiti približno 50 strankam, od katerih ima vsaka več (približno 10) modelov v enem primeru, kar lahko izpolni naše omejitve nizke zakasnitve in nam tako prihrani do 80 % stroškov .

S to arhitekturo rešitve smo lahko zmanjšali MTTR naših strank, ki je glavno merilo za merjenje uspeha pri uporabi naše platforme. Skrajša skupni čas od točke odziva na našo opozorilno povezavo, ki opisuje težavo v vaših sistemih, do trenutka, ko ste končali z raziskovanjem težave z uporabo naše platforme. Med fazo preiskave merimo dejanja uporabnikov z in brez naše rešitve za priporočila ML. To nam pomaga zagotoviti priporočila za najboljši ukrep za hitrejšo rešitev določene težave in natančno določiti nepravilnosti, da ugotovimo dejanski vzrok težave.

Zaključek in naslednji koraki

V tej objavi smo delili, kako je Logz.io uporabil SageMaker za izboljšanje MTTD in MTTR.

Kot naslednji korak razmišljamo o razširitvi rešitve z naslednjimi funkcijami:

Spodbujamo vas, da preizkusite Prenosniki SageMaker. Za več primerov si oglejte Primeri SageMaker GitHub repo.

O avtorjih

Amit Gross vodi raziskovalni oddelek Logz.io, ki je odgovoren za rešitve AI vseh izdelkov Logz.io, od raziskovalne faze do faze integracije. Pred Logz.io je Amit vodil raziskovalni skupini za podatkovno znanost in varnost pri Here inc. in Cellebrite inc. Amit ima magisterij iz računalništva na Univerzi v Tel Avivu.

Janiv Vaknin je strokovnjak za strojno učenje pri Amazon Web Services. Pred AWS je Yaniv zasedal vodilne položaje pri zagonskih podjetjih AI in Enterprise, vključno s soustanoviteljem in izvršnim direktorjem Dipsee.ai. Yaniv sodeluje s strankami AWS, da bi izkoristil moč strojnega učenja za reševanje nalog v resničnem svetu in pridobivanje vrednosti. Yaniv v prostem času rad igra nogomet s svojimi fanti.

Eitan Sela je specialist za strojno učenje, arhitekt rešitev pri Amazon Web Services. Sodeluje s strankami AWS, da bi zagotovil smernice in tehnično pomoč ter jim pomagal zgraditi in upravljati rešitve strojnega učenja na AWS. V prostem času Eitan rad teče in bere najnovejše članke o strojnem učenju.