Hoe Logz.io ML-aanbevelingen en oplossingen voor anomaliedetectie versnelt met Amazon SageMaker

Heruitgegeven door Plato

volgers: 0

Logz.io is een AWS Partner Network (APN) Advanced Technology Partner met AWS-competenties in DevOps, beveiliging en gegevens en analyse. Logz.io biedt een software-as-a-service (SaaS) observatieplatform op basis van de beste open-source softwareoplossingen voor log-, metrische en traceringsanalyses. Klanten sturen steeds meer gegevens naar Logz.io vanuit verschillende gegevensbronnen om de gezondheid en prestaties van hun applicaties en services te beheren. Het kan overweldigend zijn voor nieuwe gebruikers die willen navigeren door de verschillende dashboards die in de loop van de tijd zijn gebouwd, verschillende waarschuwingsmeldingen willen verwerken en de punten willen verbinden bij het oplossen van productieproblemen.

Mean Time to Detect (MTTD) en Mean Time to Resolution (MTTR) zijn belangrijke maatstaven voor onze klanten. Ze worden berekend door de tijd te meten dat een gebruiker op ons platform een probleem begint te onderzoeken (zoals een storing in de productieservice) tot het punt waarop hij stopt met het uitvoeren van acties op het platform die verband houden met het specifieke onderzoek.

Om klanten te helpen MTTD en MTTR te verminderen, wendt Logz.io zich tot machine learning (ML) om aanbevelingen te doen voor relevante dashboards en vragen en afwijkingsdetectie uit te voeren via zelflerend. Als gevolg hiervan is de gemiddelde gebruiker uitgerust met de geaggregeerde ervaring van zijn hele bedrijf, gebruikmakend van de wijsheid van velen. We ontdekten dat onze oplossing MTTR tot wel 20% kan verminderen.

Naarmate MTTD afneemt, kunnen gebruikers het probleem identificeren en sneller oplossen. Onze semantische gegevenslaag bevat semantiek voor het starten en stoppen van een onderzoek en de populariteit van elke actie die de gebruiker uitvoert met betrekking tot een specifieke waarschuwing.

In dit bericht delen we hoe Logz.io gebruikte Amazon Sage Maker om de tijd en moeite te verminderen voor onze proof of concept (POC), experimenten van onderzoek tot productie-evaluatie, en hoe we onze productie-inferentiekosten hebben verlaagd.

De uitdaging

Totdat Logz.io SageMaker gebruikte, was de tijd tussen onderzoek naar POC-testen en experimenten met productie behoorlijk lang. Dit kwam omdat we Spark-taken moesten maken om de gegevens te verzamelen, op te schonen en te normaliseren. DevOps had dit werk nodig om elke gegevensbron te lezen. DevOps- en data-engineeringvaardigheden maken geen deel uit van ons ML-team en dit zorgde voor een grote afhankelijkheid tussen de teams.

Een andere uitdaging was om een ML-inferentieservice voor onze producten te bieden en tegelijkertijd een optimale kosten-prestatieverhouding te bereiken. Ons optimale scenario is het ondersteunen van zoveel mogelijk modellen voor een computereenheid en het bieden van hoge gelijktijdigheid van klanten met veel modellen. We hadden flexibiliteit met betrekking tot onze inferentietijd, omdat ons eerste venster van de gegevensstroom voor de inferentieservice een emmer met logboeken van 5 minuten is.

Onderzoeksfase

Datawetenschap is een iteratief proces dat een interactieve ontwikkelomgeving voor onderzoek vereist, waarbij de gegevensuitvoer bij elke iteratie en gegevensverwerking wordt gevalideerd. Daarom moedigen we onze ML-onderzoekers aan om notebooks te gebruiken.

Om de iteratiecyclus te versnellen, wilden we de code van onze notebooks testen op echte productiegegevens, terwijl we deze op schaal uitvoeren. Bovendien wilden we het knelpunt van DevOps en data-engineering tijdens de eerste test in productie vermijden, terwijl we de mogelijkheid hadden om de uitvoer te bekijken en de runtime van de code te proberen in te schatten.

Om dit te implementeren, wilden we ons data science-team volledige controle en end-to-end verantwoordelijkheid geven, van onderzoek tot eerste test op productie. We hadden ze nodig om gemakkelijk gegevens op te halen, met behoud van gegevenstoegangsbeheer en bewaking van deze toegang. Ze moesten ook hun op maat gemaakte POC-notebooks eenvoudig op een schaalbare manier in productie kunnen nemen, terwijl ze de runtime en verwachte kosten konden bewaken.

Evaluatie fase

Tijdens deze fase hebben we enkele ML-platforms geëvalueerd om zowel de trainings- als de servicevereisten te ondersteunen. We ontdekten dat SageMaker het meest geschikt is voor onze use cases omdat het zowel training als inferentie ondersteunt. Bovendien is het aanpasbaar, zodat we het kunnen afstemmen op ons favoriete onderzoeksproces.

Aanvankelijk begonnen we met lokale notebooks en testten we verschillende bibliotheken. We kwamen problemen tegen met het ophalen van enorme hoeveelheden gegevens uit de productie. Later zaten we vast in een punt van de modelleringsfase die vele uren in beslag nam op een lokale machine.

We hebben veel oplossingen geëvalueerd en uiteindelijk voor de volgende architectuur gekozen:

Gegevensbord – De open-sourceversie van Gegevensbord heeft ons geholpen onze gegevens eenvoudig te verzamelen en samen te voegen door onze Spark te gebruiken Amazon EMR clusters met een eenvoudige SQL, terwijl de toegang tot de gegevens wordt bewaakt
SageMaker-notebookinstantie en verwerkingstaken – Dit hielp ons met de schaalbaarheid van runtime en flexibiliteit van machinetypes en ML-frameworks, terwijl we onze code samenwerkten via een Git-verbinding

Oplossingsarchitectuur in de onderzoeksfase

Het volgende diagram illustreert de oplossingsarchitectuur van de onderzoeksfase en bestaat uit de volgende componenten:

SageMaker-notitieboekjes – Datawetenschappers gebruiken deze laptops om hun onderzoek uit te voeren.
AWS Lambda-functie - AWS Lambda is een serverloze oplossing die op verzoek een verwerkingstaak uitvoert. De taak gebruikt een Docker-container met de notebook die we tijdens ons experiment willen uitvoeren, samen met al onze algemene bestanden die de notebook moeten ondersteunen (requirements.txt en de code voor multi-processing-functies in een apart notitieblok).
Amazon ECR - Amazon Elastic Container-register (Amazon ECR) slaat onze Docker-container op.
SageMaker Verwerkingstaak – We kunnen dit uitvoeren taak voor gegevensverwerking op elke ML-machine, en het voert onze notebook uit met parameters.
Gegevensbord - Deze service helpt ons SQL te gebruiken en eenvoudig verschillende gegevensbronnen samen te voegen. Het vertaalt het naar Spark-code en optimaliseert het, terwijl het de toegang tot gegevens bewaakt en datalekken helpt verminderen. De Xtra-versie bood nog meer mogelijkheden.
Amazon EMR – Deze service voert onze gegevensextracties uit als workloads over Spark en neemt contact op met al onze gegevensbronnen.

Met de levenscyclus van de SageMaker-notebookinstantie kunnen we de maximale runtime van de notebookinstantie regelen met behulp van de autostop.py sjabloon scripts.

Na het testen van de ML-frameworks, kozen we de SageMaker MXNet-kernel voor onze cluster- en rankingfasen.

Om de notebookcode op onze productiegegevens te testen, hebben we de notebook uitgevoerd door deze in te kapselen via Docker in Amazon ECS en uitgevoerd als een verwerkingstaak om de maximale runtime op verschillende soorten machines te valideren.

De Docker-container helpt ons ook om bronnen te delen tussen de tests van notebooks. In sommige gevallen roept een notebook andere notebooks op om een multiproces te gebruiken door big dataframes op te splitsen in kleinere dataframes, die tegelijkertijd op elke vCPU in een groot machinetype kunnen draaien.

De real-time oplossing voor productie-inferentie

In de onderzoeksfase hebben we Parket gebruikt Amazon eenvoudige opslagservice (Amazon S3) bestanden om onze aanbevelingen te behouden. Deze worden één keer per dag uit onze technische pijplijn verbruikt om de aanbevelingen aan ons waarschuwingsmechanisme te koppelen.

Onze roadmap vereist echter een oplossing met een hogere verversingssnelheid en één keer per dag trekken is op de lange termijn niet voldoende, omdat we zelfs tijdens het onderzoek aanbevelingen willen doen.

Om deze oplossing op grote schaal te implementeren, hebben we de meeste SageMaker-eindpuntoplossingen getest in ons onderzoek naar anomaliedetectie. We hebben 500 van de vooraf gebouwde modellen getest met een enkele eindpuntmachine van verschillende typen en gelijktijdige multi-threaded clients gebruikt om verzoeken aan het eindpunt uit te voeren. We hebben de responstijd, CPU, geheugen en andere statistieken gemeten (voor meer informatie, zie Bewaak Amazon SageMaker met Amazon CloudWatch). We ontdekten dat het eindpunt met meerdere modellen perfect past bij onze use cases.

Een eindpunt met meerdere modellen kan onze kosten drastisch verlagen in vergelijking met een enkel eindpunt of zelfs Kubernetes om Flask (of andere Python) webservices te gebruiken. Onze eerste veronderstelling was dat we voor elke klant één eindpunt moesten bieden, met behulp van een kleine machine met 4 vCPU's, en dat we gemiddeld vier specifieke modellen moesten opvragen, omdat elke vCPU één model bedient. Met het multi-model endpoint konden we meer klanten samenvoegen op één multi-endpoint machine.

We hadden een model en coderingsbestanden per klant, en na belastingstests te hebben uitgevoerd, hebben we vastgesteld dat we 50 klanten konden bedienen, elk met 10 modellen en zelfs met de kleinste ml.t2.medium-instantie voor onze oplossingen.

In deze fase hebben we overwogen om te gebruiken eindpunten met meerdere modellen. Eindpunten met meerdere modellen bieden een schaalbare en kosteneffectieve oplossing om een groot aantal modellen te implementeren, zodat u meerdere modellen kunt hosten met één enkele inferentiecontainer. Dit verlaagt de hostingkosten door het gebruik van endpoints te verbeteren in vergelijking met het gebruik van meerdere kleine single-model endpoints die elk een enkele klant bedienen. Het vermindert ook de implementatieoverhead omdat SageMaker het laden van modellen in het geheugen beheert en ze schaalt op basis van de verkeerspatronen ernaartoe.

Bovendien is het voordeel van het eindpunt met meerdere modellen dat als u een hoog inferentiepercentage van specifieke klanten heeft, het raamwerk de laatst gebruikte modellen in het geheugen bewaart voor betere prestaties.

Nadat we de kosten hadden geschat met behulp van eindpunten met meerdere modellen versus standaardeindpunten, kwamen we erachter dat dit mogelijk zou kunnen leiden tot een kostenbesparing van ongeveer 80%.

De uitkomst

In deze sectie bekijken we de stappen en de uitkomst van het proces.

We gebruiken de lifecycle-notebookconfiguratie om de notebooks als verwerkingstaken uit te voeren, door de notebook in te kapselen in een Docker-container om de code sneller te valideren en het autostop-mechanisme te gebruiken:

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

We klonen de sagemaker-run-notebook GitHub-project en voeg het volgende toe aan de container:

Onze pip-vereisten
De mogelijkheid om notebooks vanuit een notebook uit te voeren, waardoor we multi-processing kunnen gebruiken om alle ml.m5.12xlarge-instantiekernen te gebruiken

Dit stelt ons in staat om workflows uit te voeren die bestaan uit veel notebooks die als verwerkingstaken in een coderegel worden uitgevoerd, terwijl we het instantietype definiëren waarop moet worden uitgevoerd.

Omdat we parameters aan de notebook kunnen toevoegen, kunnen we onze verwerking schalen door tegelijkertijd op verschillende uren, dagen of maanden gegevens op te halen en te verwerken.

We kunnen ook planningstaken maken die notebooks uitvoeren (en zelfs de looptijd beperken).

We kunnen ook de laatste runs en hun details, zoals de verwerkingstijd, observeren.

Met de papierfabriek die in de container wordt gebruikt, kunnen we de output van elke run bekijken, wat ons helpt bij het debuggen in de productie.

Onze beoordeling van de notebookuitvoer heeft de vorm van een standaard alleen-lezen notebook.

Het gebruik van meerdere processen helpt ons om op elke notebookverwerking te schalen en alle cores te gebruiken. We hebben functies gegenereerd in andere notebooks die zware verwerking kunnen uitvoeren, zoals de volgende:

Explodeer JSON's
Vind relevante rijen in een DataFrame terwijl het hoofdnotebook het DataFrame opsplitst #cpu-cores geeft je de mogelijkheid
Voer clustering per waarschuwingstype acties tegelijkertijd uit

Vervolgens voegen we deze functionele notebooks toe aan de container waarin de notebook wordt uitgevoerd als een verwerkingstaak. Zie het volgende Docker-bestand (let op de COPY-opdrachten):

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

Resultaten

Tijdens de onderzoeksfase hebben we de mogelijkheid geëvalueerd om onze notebooks te gebruiken zoals ze zijn, om te experimenteren en te evalueren hoe onze code presteert op al onze relevante gegevens, niet alleen op een steekproef van gegevens. We ontdekten dat het inkapselen van onze notebooks met behulp van verwerkingstaken goed bij ons past, omdat we geen code hoeven te herschrijven en we de kracht van AWS-computing-geoptimaliseerde en geheugen-geoptimaliseerde instanties kunnen gebruiken en de status van het proces gemakkelijk kunnen volgen.

Tijdens de inferentiebeoordeling hebben we verschillende SageMaker-eindpuntoplossingen geëvalueerd. We ontdekten dat het gebruik van een eindpunt met meerdere modellen ons kan helpen ongeveer 50 klanten te bedienen, elk met meerdere (ongeveer 10) modellen in één instantie, die kunnen voldoen aan onze beperkingen met lage latentie, en ons daarom tot 80% van de kosten kunnen besparen .

Met deze oplossingsarchitectuur konden we de MTTR van onze klanten verlagen, wat een belangrijke maatstaf is voor het meten van succes bij het gebruik van ons platform. Het verkort de totale tijd vanaf het moment dat u reageert op onze waarschuwingslink, die een probleem in uw systemen beschrijft, tot wanneer u klaar bent met het onderzoeken van het probleem met behulp van ons platform. Tijdens de onderzoeksfase meten we de acties van de gebruikers met en zonder onze ML-aanbevelingsoplossing. Dit helpt ons aanbevelingen te doen voor de beste actie om het specifieke probleem sneller op te lossen en afwijkingen op te sporen om de werkelijke oorzaak van het probleem te identificeren.

Conclusie en volgende stappen

In dit bericht deelden we hoe Logz.io SageMaker gebruikte om MTTD en MTTR te verbeteren.

Als volgende stap overwegen we de oplossing uit te breiden met de volgende functies:

We moedigen je aan om het uit te proberen SageMaker-notitieboekjes. Voor meer voorbeelden, bekijk de SageMaker-voorbeelden GitHub-opslagplaats.

Over de auteurs

Amit Gross leidt de onderzoeksafdeling van Logz.io, die verantwoordelijk is voor de AI-oplossingen van alle Logz.io-producten, van de onderzoeksfase tot de integratiefase. Voorafgaand aan Logz.io leidde Amit zowel Data Science als Security Research Groups bij Here inc. en Cellebrite inc. Amit heeft een M.Sc in informatica van de Universiteit van Tel-Aviv.

Yaniv Vaknin is Machine Learning-specialist bij Amazon Web Services. Vóór AWS bekleedde Yaniv leidinggevende posities bij AI-startups en Enterprise, waaronder mede-oprichter en CEO van Dipsee.ai. Yaniv werkt samen met AWS-klanten om de kracht van Machine Learning te benutten om echte taken op te lossen en waarde te ontlenen. In zijn vrije tijd speelt Yaniv graag voetbal met zijn jongens.

Eitan Sela is een Machine Learning Specialist Solutions Architect bij Amazon Web Services. Hij werkt samen met AWS-klanten om begeleiding en technische assistentie te bieden en hen te helpen bij het bouwen en gebruiken van machine learning-oplossingen op AWS. In zijn vrije tijd jogt Eitan graag en leest hij de nieuwste artikelen over machine learning.