Hogyan gyorsítja fel a Logz.io az ML ajánlásokat és az anomália-észlelési megoldásokat az Amazon SageMaker segítségével

Újra kiadta Platón

Követő: 0

Logz.io az AWS Partner Network (APN) fejlett technológiai partnere AWS-kompetenciák a DevOps, a biztonság, valamint az adatok és elemzések területén. A Logz.io egy szoftver, mint szolgáltatás (SaaS) megfigyelési platformot kínál, amely kategóriájában a legjobb nyílt forráskódú szoftvermegoldásokon alapul naplózási, metrikus és nyomkövetési elemzésekhez. Az ügyfelek egyre több adatot küldenek a Logz.io-nak különböző adatforrásokból, hogy kezeljék alkalmazásaik és szolgáltatásaik állapotát és teljesítményét. Hatalmas lehet az új felhasználók számára, akik szeretnének navigálni az idők során felépített különböző irányítópultok között, feldolgozni a különböző riasztási értesítéseket, és összekapcsolni a pontokat a termelési problémák hibaelhárítása során.

Az átlagos észlelési idő (MTTD) és az átlagos felbontásig tartó idő (MTTR) kulcsfontosságú mérőszámok ügyfeleink számára. Kiszámításuk úgy történik, hogy mérik azt az időt, amikor egy felhasználó a platformunkon elkezd kivizsgálni egy problémát (például az éles szolgáltatás leállását) addig a pontig, amikor abbahagyja az adott vizsgálathoz kapcsolódó műveletek végrehajtását a platformon.

Az MTTD és az MTTR csökkentésének segítése érdekében a Logz.io a gépi tanuláshoz (ML) fordul, hogy ajánlásokat adjon a releváns irányítópultokhoz és lekérdezésekhez, és öntanuláson keresztül anomáliák észlelését végezze. Ennek eredményeként az átlagos felhasználó a teljes vállalata összesített tapasztalatával rendelkezik, sokak bölcsességét kihasználva. Azt találtuk, hogy megoldásunk akár 20%-kal is csökkentheti az MTTR-t.

Az MTTD csökkenésével a felhasználók azonosíthatják a problémát, és gyorsabban megoldhatják. Adatszemantikai rétegünk szemantikát tartalmaz a vizsgálat elindításához és leállításához, valamint a felhasználó által egy adott riasztással kapcsolatban végrehajtott műveletek népszerűségét.

Ebben a bejegyzésben megosztjuk, hogyan használta a Logz.io Amazon SageMaker hogy csökkentsük a koncepció bizonyítására (POC), a kísérletekre a kutatástól a gyártás értékeléséig fordított időt és erőfeszítést, valamint azt, hogy hogyan csökkentettük a gyártási következtetési költségünket.

A kihívás

Amíg a Logz.io nem használta a SageMaker-t, a kutatástól a POC-tesztelésig és a gyártási kísérletekig eltelt idő meglehetősen hosszú volt. Ennek oka az volt, hogy Spark-feladatokat kellett létrehoznunk az adatok összegyűjtéséhez, tisztításához és normalizálásához. A DevOps ezt a munkát az egyes adatforrások beolvasásához igényelte. A DevOps és az adatmérnöki készségek nem tartoznak az ML csapatunkhoz, és ez nagy függőséget okozott a csapatok között.

Egy másik kihívás az volt, hogy ML következtetési szolgáltatást biztosítsunk termékeinkhez, miközben elérjük az optimális költség/teljesítmény arányt. Optimális forgatókönyvünk az, hogy a lehető legtöbb modellt támogatjuk egy számítástechnikai egységhez, miközben magas egyidejűséget biztosítunk az ügyfelektől sok modellel. Rugalmas voltunk a következtetési időnket illetően, mivel a következtetési szolgáltatás adatfolyamának kezdeti ablaka 5 percnyi naplózóna.

Kutatási szakasz

Az adattudomány egy iteratív folyamat, amely interaktív fejlesztői környezetet igényel a kutatáshoz, minden iteráció és adatfeldolgozás során érvényesíti az adatkimenetet. Ezért ösztönözzük ML kutatóinkat a notebook használatára.

Az iterációs ciklus felgyorsítása érdekében a notebookok kódját valós termelési adatokon akartuk tesztelni, miközben azt nagy méretben futtattuk. Ezenkívül el akartuk kerülni a DevOps és az adatkezelés szűk keresztmetszetét a gyártás kezdeti tesztje során, miközben meg tudtuk nézni a kimeneteket, és megpróbáltuk megbecsülni a kód futási idejét.

Ennek megvalósítása érdekében teljes körű ellenőrzést és teljes felelősséget akartunk biztosítani adattudományi csapatunknak a kutatástól a gyártás kezdeti teszteléséig. Szükségünk volt rájuk, hogy könnyen lehívják az adatokat, miközben megőrizték az adathozzáférés kezelését és figyelemmel kísérték ezt a hozzáférést. Egyedi POC notebookjaikat is egyszerűen, méretezhető módon üzembe kellett helyezniük a termelésben, miközben figyelemmel kísérték a futási időt és a várható költségeket.

Értékelési szakasz

Ebben a fázisban értékeltünk néhány ML platformot, hogy támogassuk mind a képzési, mind a kiszolgálási követelményeket. Azt találtuk, hogy a SageMaker a legmegfelelőbb a mi felhasználási eseteinkhez, mert támogatja a képzést és a következtetést is. Ezenkívül személyre szabható, így testre szabhatjuk az általunk preferált kutatási folyamatnak megfelelően.

Kezdetben helyi notebookokból indultunk ki, különféle könyvtárakat teszteltünk. Problémákba ütköztünk, amikor hatalmas mennyiségű adatot vontunk le a termelésből. Később elakadtunk a modellezési fázis egy pontjában, ami sok órát vett igénybe egy helyi gépen.

Számos megoldást értékeltünk, és végül a következő architektúrát választottuk:

DataPlate – A nyílt forráskódú változata DataPlate Sparkunk segítségével könnyen lehívhatjuk és összekapcsolhatjuk adatainkat Amazon EMR fürtök egy egyszerű SQL-lel, miközben figyelik az adathozzáférést
SageMaker notebook példány és feldolgozási feladatok – Ez segített a futásidő skálázhatóságában és a géptípusok és ML keretrendszerek rugalmasságában, miközben a kódunkat Git kapcsolaton keresztül dolgoztuk ki.

Kutatási fázis megoldás architektúra

Az alábbi diagram a kutatási fázis megoldásarchitektúráját szemlélteti, és a következő komponensekből áll:

SageMaker notebookok – Az adattudósok ezeket használják laptopok kutatásaik elvégzésére.
AWS lambda funkció - AWS Lambda egy szerver nélküli megoldás, amely igény szerint futtatja a feldolgozási feladatokat. A feladat egy Docker-tárolót használ a kísérlet során futtatni kívánt notebookhoz, valamint az összes gyakori fájlunkhoz, amelyeknek támogatniuk kell a notebookot (requirements.txt és a többfeldolgozó funkciók kódja egy külön notebookban).
Amazon ECR - Amazon Elastic Container Registry (Amazon ECR) tárolja a Docker konténerünket.
SageMaker feldolgozási munka - Ezt le tudjuk vezetni adatfeldolgozó munkakör bármely ML gépen, és paraméterekkel futtatja a notebookunkat.
DataPlate – Ez a szolgáltatás segít nekünk az SQL használatában és több adatforráshoz való egyszerű csatlakozásban. Lefordítja Spark kódra és optimalizálja azt, miközben figyeli az adatokhoz való hozzáférést és segít csökkenteni az adatszivárgást. Az Xtra verzió még több lehetőséget biztosított.
Amazon EMR – Ez a szolgáltatás adatkinyeréseinket munkaterhelésként futtatja a Spark felett, felveszi a kapcsolatot az összes adatforrásunkkal.

A SageMaker notebook példány életciklusával szabályozhatjuk a notebook példány maximális futási idejét a segítségével autostop.py sablon szkripteket.

Az ML keretrendszerek tesztelése után a SageMaker MXNet kernelt választottuk a klaszterezési és rangsorolási fázisainkhoz.

A notebook kódjának gyártási adatainkon való teszteléséhez futtattuk a notebookot úgy, hogy az Amazon ECS-ben lévő Docker segítségével beágyaztuk, és feldolgozási feladatként futtattuk, hogy ellenőrizzük a maximális futási időt a különböző típusú gépeken.

A Docker konténer abban is segít, hogy megosszuk az erőforrásokat a notebookok tesztjei között. Egyes esetekben a notebook felhívja a többi noteszgépet, hogy több folyamatot használjanak fel a nagy adatkeretek kisebb adatkeretekre való felosztásával, amelyek egyidejűleg futhatnak egy nagy géptípus minden egyes vCPU-ján.

A valós idejű termelési következtetési megoldás

A kutatási szakaszban parkettát használtunk Amazon egyszerű tárolási szolgáltatás (Amazon S3) fájlokat, hogy fenntartsuk ajánlásainkat. Ezeket naponta egyszer elfogyasztjuk mérnöki folyamatunkból, hogy az ajánlásokat riasztási mechanizmusunkhoz csatoljuk.

Útitervünk azonban magasabb frissítési gyakoriságú megoldást igényel, és a napi egyszeri lehúzás hosszú távon nem elég, mert a vizsgálat során is szeretnénk ajánlásokat adni.

A megoldás nagyarányú megvalósítása érdekében a legtöbb SageMaker végpontmegoldást teszteltük anomália-észlelési kutatásunk során. Az előre elkészített modellek közül 500-at teszteltünk egyetlen különböző típusú végponti géppel, és párhuzamos, többszálú klienseket használtunk a végponthoz intézett kérések végrehajtásához. Megmértük a válaszidőt, a CPU-t, a memóriát és egyéb mutatókat (további információért lásd: Az Amazon SageMaker monitorozása az Amazon CloudWatch segítségével). Azt találtuk, hogy a többmodell végpont tökéletesen illeszkedik a mi felhasználási eseteinkhez.

Egy több modellből álló végpont drasztikusan csökkentheti költségeinket egyetlen végponthoz vagy akár a Kuberneteshez képest a Flask (vagy más Python) webszolgáltatások használatához képest. Első feltételezésünk az volt, hogy egyetlen végpontot kell biztosítanunk, egy 4 vCPU-s kisgépet használva minden ügyfél számára, és átlagosan négy dedikált modellt kell lekérdeznünk, mivel minden vCPU egy modellt szolgál ki. A többmodell végponttal több ügyfelet tudtunk összesíteni egyetlen többvégpontos gépen.

Ügyfelenként rendelkeztünk modell- és kódolási fájlokkal, és terhelési tesztek elvégzése után megállapítottuk, hogy 50 ügyfelet tudunk kiszolgálni, egyenként 10 modellt használva, és megoldásainkhoz a legkisebb ml.t2.medium példányt is felhasználva.

Ebben a szakaszban fontolóra vettük a használatát több modellből álló végpontok. A több modellből álló végpontok méretezhető és költséghatékony megoldást kínálnak nagyszámú modell üzembe helyezéséhez, lehetővé téve több modell tárolását egyetlen következtetési tárolóval. Ez csökkenti a hosztolási költségeket a végpontok kihasználtságának javításával, összehasonlítva több kis egymodellű végpont használatával, amelyek mindegyike egyetlen ügyfelet szolgál ki. Csökkenti a telepítési többletköltséget is, mivel a SageMaker kezeli a modellek betöltését a memóriába, és a hozzájuk érkező forgalmi minták alapján méretezi azokat.

Ezen túlmenően a többmodell végpont előnye, hogy ha magas a következtetési arány bizonyos ügyfelektől, a keretrendszer megőrzi az utolsó kiszolgáló modelleket a memóriában a jobb teljesítmény érdekében.

Miután megbecsültük a költségeket a többmodelles végpontok és a szabványos végpontok használatával, rájöttünk, hogy ez potenciálisan körülbelül 80%-os költségcsökkentéshez vezethet.

Az eredmény

Ebben a részben áttekintjük a folyamat lépéseit és kimenetelét.

Az életciklus jegyzetfüzet-konfigurációt használjuk a notebookok feldolgozási feladatként történő futtatásának lehetővé tételére oly módon, hogy a notebookot egy Docker-tárolóba foglaljuk a kód gyorsabb érvényesítése és az automatikus leállítási mechanizmus használata érdekében:

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

klónozzuk a sagemaker-run-notebook GitHub projektet, és adja hozzá a következőket a tárolóhoz:

Pip követelményeink
A notebookok notebookon belüli futtatásának képessége, amely lehetővé teszi számunkra a több feldolgozási viselkedést az összes ml.m5.12xlarge példánymag felhasználásához

Ez lehetővé teszi olyan munkafolyamatok futtatását, amelyek számos, egy kódsorban feldolgozási feladatként futó notebookból állnak, miközben meghatározzuk a futtatandó példánytípust.

Mivel paramétereket adhatunk a notebookhoz, a feldolgozást méretezhetjük úgy, hogy egyszerre futunk különböző órákban, napokon vagy hónapokban az adatok lekéréséhez és feldolgozásához.

Létrehozhatunk olyan ütemezési feladatokat is, amelyek notebookokat futtatnak (és még a futási időt is korlátozzák).

Megfigyelhetjük az utolsó futtatásokat és azok részleteit is, például a feldolgozási időt.

A tárolóban használt papírgyárral minden futtatás kimenetét megtekinthetjük, ami segít a hibakeresésben a termelésben.

A notebook kimeneti áttekintésünk szabványos, csak olvasható jegyzetfüzet formájában készült.

A többfeldolgozós használat segít minden noteszgép-feldolgozásban skálázni, és minden magját felhasználni. Más notebookokban olyan függvényeket hoztunk létre, amelyek nagy feldolgozásra képesek, például a következők:

Explode JSON-ok
Keresse meg a megfelelő sorokat egy DataFrame-ben, miközben a fő notebook felosztja a DataFrame-et #cpu-cores elemek
A riasztástípusonkénti fürtözési műveletek egyidejű futtatása

Ezután hozzáadjuk ezeket a funkcionális jegyzetfüzeteket a tárolóhoz, amely feldolgozási feladatként futtatja a notebookot. Tekintse meg a következő Docker-fájlt (figyelje meg a COPY parancsokat):

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

Eredmények

A kutatási szakaszban megvizsgáltuk a notebookok futtatásának lehetőségét, hogy kísérletezzen, és értékeljük, hogyan teljesít a kódunk az összes releváns adatunkon, nem csak egy adatmintán. Megállapítottuk, hogy notebookjaink feldolgozási feladatokkal történő beágyazása remekül illeszkedik számunkra, mert nem kell újraírnunk a kódot, és kihasználhatjuk az AWS számítás- és memóriaoptimalizált példányok erejét, és könnyen követhetjük a folyamat állapotát.

A következtetés értékelése során különféle SageMaker végpontmegoldásokat értékeltünk. Megállapítottuk, hogy egy több modellből álló végpont segítségével körülbelül 50 ügyfelet tudunk kiszolgálni, amelyek mindegyike több (körülbelül 10) modellel rendelkezik egyetlen példányban, ami megfelel az alacsony késleltetési időre vonatkozó korlátainknak, és így a költségek akár 80%-át is megtakaríthatja. .

Ezzel a megoldás-architektúrával csökkenteni tudtuk ügyfeleink MTTR-jét, amely a platformunk használatának sikerének fő mérőszáma. Lecsökkenti a teljes időt a rendszere problémáját leíró riasztási hivatkozásunkra való válaszadástól addig, amíg befejezi a probléma kivizsgálását platformunk használatával. A vizsgálati szakaszban mérjük a felhasználók tevékenységét az ML ajánlási megoldásunkkal és anélkül. Ez segít abban, hogy javaslatokat adjunk az adott probléma gyorsabb megoldásához szükséges legjobb lépésekre, és pontosan meghatározzuk az anomáliákat a probléma tényleges okának azonosítása érdekében.

Következtetés és a következő lépések

Ebben a bejegyzésben megosztottuk, hogyan használta a Logz.io a SageMakert az MTTD és az MTTR javítására.

Következő lépésként a megoldást a következő funkciókkal bővítjük:

Javasoljuk, hogy próbálja ki SageMaker notebookok. További példákért nézze meg a SageMaker példák GitHub repo.

A szerzőkről

Amit Gross vezeti a Logz.io kutatási részlegét, amely az összes Logz.io termék mesterséges intelligenciájáért felelős, a kutatási fázistól az integrációs szakaszig. A Logz.io előtt Amit Data Science és Security Research Groupokat is irányított a Here inc.-nél. és a Cellebrite inc. Amit a Tel-Aviv Egyetemen szerzett MSc-t számítástechnikából.

Yaniv Vaknin az Amazon Web Services gépi tanulási szakértője. Az AWS előtt Yaniv vezető pozíciókat töltött be az AI startupoknál és az Enterprise-nál, beleértve a Dipsee.ai társalapítóját és vezérigazgatóját. A Yaniv együttműködik az AWS-ügyfelekkel, hogy a Machine Learning erejét valós feladatok megoldására és értékteremtésre fordítsa. Szabadidejében Yaniv szívesen focizik a fiaival.

Eitan Sela az Amazon Web Services gépi tanulási specialistája. Együttműködik az AWS-ügyfelekkel, hogy útmutatást és technikai segítséget nyújtson, segítve őket az AWS-en futó gépi tanulási megoldások kiépítésében és üzemeltetésében. Szabadidejében Eitan szívesen kocog, és olvassa a legújabb gépi tanulási cikkeket.