Wie Logz.io ML-Empfehlungen und Anomalieerkennungslösungen mit Amazon SageMaker beschleunigt

Neuauflage von Plato

Verfolger: 0

Logz.io ist ein AWS Partner Network (APN) Advanced Technology Partner mit AWS-Kompetenzen in den Bereichen DevOps, Sicherheit sowie Daten und Analysen. Logz.io bietet eine Software-as-a-Service (SaaS)-Beobachtungsplattform, die auf erstklassigen Open-Source-Softwarelösungen für Protokoll-, Metrik- und Tracing-Analysen basiert. Kunden senden immer mehr Daten aus verschiedenen Datenquellen an Logz.io, um den Zustand und die Leistung ihrer Anwendungen und Dienste zu verwalten. Für neue Benutzer kann es überwältigend sein, durch die verschiedenen Dashboards zu navigieren, die im Laufe der Zeit erstellt wurden, verschiedene Warnmeldungen zu verarbeiten und bei der Behebung von Produktionsproblemen den Überblick zu behalten.

Die mittlere Erkennungszeit (MTTD) und die mittlere Lösungszeit (MTTR) sind wichtige Kennzahlen für unsere Kunden. Sie werden berechnet, indem die Zeit gemessen wird, die ein Benutzer auf unserer Plattform mit der Untersuchung eines Problems (z. B. Ausfall eines Produktionsdienstes) beginnt, bis zu dem Punkt, an dem er aufhört, Aktionen auf der Plattform auszuführen, die mit der spezifischen Untersuchung zusammenhängen.

Um Kunden dabei zu helfen, MTTD und MTTR zu reduzieren, setzt Logz.io auf maschinelles Lernen (ML), um Empfehlungen für relevante Dashboards und Abfragen bereitzustellen und eine Anomalieerkennung durch Selbstlernen durchzuführen. Dadurch verfügt der durchschnittliche Benutzer über die Gesamterfahrung seines gesamten Unternehmens und nutzt die Weisheit vieler. Wir haben festgestellt, dass unsere Lösung die MTTR um bis zu 20 % reduzieren kann.

Mit abnehmender MTTD können Benutzer das Problem schneller identifizieren und lösen. Unsere Datensemantikschicht enthält Semantik zum Starten und Stoppen einer Untersuchung sowie die Beliebtheit jeder Aktion, die der Benutzer in Bezug auf eine bestimmte Warnung ausführt.

In diesem Beitrag teilen wir mit, wie Logz.io verwendet wird Amazon Sage Maker um den Zeit- und Arbeitsaufwand für unseren Proof of Concept (POC), Experimente von der Forschung bis zur Produktionsbewertung zu reduzieren und wie wir unsere Produktionsinferenzkosten reduziert haben.

Die Herausforderung

Bis Logz.io SageMaker einsetzte, war die Zeit zwischen der Forschung, dem POC-Test und den Experimenten in der Produktion ziemlich lang. Der Grund hierfür war, dass wir Spark-Jobs erstellen mussten, um die Daten zu sammeln, zu bereinigen und zu normalisieren. DevOps erforderte diese Arbeit, um jede Datenquelle zu lesen. DevOps- und Data-Engineering-Fähigkeiten sind nicht Teil unseres ML-Teams, was zu einer hohen Abhängigkeit zwischen den Teams führte.

Eine weitere Herausforderung bestand darin, einen ML-Inferenzdienst für unsere Produkte bereitzustellen und gleichzeitig ein optimales Kosten-Leistungs-Verhältnis zu erreichen. Unser optimales Szenario besteht darin, so viele Modelle wie möglich für eine Recheneinheit zu unterstützen und gleichzeitig eine hohe Parallelität von Kunden mit vielen Modellen zu gewährleisten. Wir hatten Flexibilität hinsichtlich unserer Inferenzzeit, da unser anfängliches Fenster des Datenstroms für den Inferenzdienst einen 5-Minuten-Bucket mit Protokollen umfasst.

Forschungsphase

Data Science ist ein iterativer Prozess, der eine interaktive Entwicklungsumgebung für die Forschung erfordert und die Datenausgabe bei jeder Iteration und Datenverarbeitung validiert. Daher ermutigen wir unsere ML-Forscher, Notebooks zu verwenden.

Um den Iterationszyklus zu beschleunigen, wollten wir den Code unserer Notebooks anhand realer Produktionsdaten testen und ihn gleichzeitig im großen Maßstab ausführen. Darüber hinaus wollten wir den Engpass von DevOps und Data Engineering während des ersten Tests in der Produktion vermeiden und gleichzeitig die Möglichkeit haben, die Ausgaben anzuzeigen und zu versuchen, die Codelaufzeit abzuschätzen.

Um dies umzusetzen, wollten wir unserem Data-Science-Team die volle Kontrolle und End-to-End-Verantwortung von der Forschung bis zum ersten Test in der Produktion übertragen. Wir brauchten sie, um Daten einfach abzurufen und gleichzeitig die Datenzugriffsverwaltung und die Überwachung dieses Zugriffs beizubehalten. Außerdem mussten sie ihre benutzerdefinierten POC-Notebooks einfach und skalierbar in der Produktion bereitstellen und gleichzeitig die Laufzeit und die erwarteten Kosten überwachen.

Bewertungsphase

In dieser Phase haben wir einige ML-Plattformen evaluiert, um sowohl Schulungs- als auch Serviceanforderungen zu erfüllen. Wir haben festgestellt, dass SageMaker für unsere Anwendungsfälle am besten geeignet ist, da es sowohl Training als auch Inferenz unterstützt. Darüber hinaus ist es anpassbar, sodass wir es an unseren bevorzugten Forschungsprozess anpassen können.

Zunächst begannen wir mit lokalen Notebooks und testeten verschiedene Bibliotheken. Wir hatten Probleme beim Abrufen großer Datenmengen aus der Produktion. Später steckten wir an einem Punkt der Modellierungsphase fest, der auf einem lokalen Computer viele Stunden dauerte.

Wir haben viele Lösungen evaluiert und uns schließlich für die folgende Architektur entschieden:

Datenplatte – Die Open-Source-Version von Datenplatte hat uns durch die Nutzung unseres Spark geholfen, unsere Daten einfach abzurufen und zusammenzuführen Amazon EMR Cluster mit einem einfachen SQL, während der Datenzugriff überwacht wird
SageMaker-Notebook-Instanz und Verarbeitungsaufträge – Dies hat uns bei der Skalierbarkeit der Laufzeit und der Flexibilität von Maschinentypen und ML-Frameworks geholfen, während wir unseren Code über eine Git-Verbindung zusammenarbeiten konnten

Lösungsarchitektur in der Forschungsphase

Das folgende Diagramm veranschaulicht die Lösungsarchitektur der Forschungsphase und besteht aus den folgenden Komponenten:

SageMaker-Notizbücher – Datenwissenschaftler nutzen diese Laptops um ihre Forschung durchzuführen.
AWS Lambda-Funktion - AWS Lambda ist eine serverlose Lösung, die einen Verarbeitungsjob bei Bedarf ausführt. Der Job verwendet einen Docker-Container mit dem Notebook, das wir während unseres Experiments ausführen möchten, zusammen mit allen unseren gemeinsamen Dateien, die das Notebook unterstützen müssen (requirements.txt und den Multi-Processing-Funktionscode in einem separaten Notizbuch).
Amazon ECR - Amazon Elastic Container-Registrierung (Amazon ECR) speichert unseren Docker-Container.
SageMaker-Verarbeitungsjob – Wir können das ausführen Datenverarbeitungsauftrag auf jeder ML-Maschine und führt unser Notebook mit Parametern aus.
Datenplatte – Dieser Service hilft uns, SQL zu verwenden und mehrere Datenquellen einfach zu verbinden. Es übersetzt es in Spark-Code und optimiert ihn, während es gleichzeitig den Datenzugriff überwacht und dabei hilft, Datenschutzverletzungen zu reduzieren. Die Xtra-Version bot noch mehr Möglichkeiten.
Amazon EMR – Dieser Dienst führt unsere Datenextraktionen als Workloads über Spark aus und kontaktiert alle unsere Datenressourcen.

Mit dem Lebenszyklus der SageMaker-Notebook-Instanz können wir die maximale Laufzeit der Notebook-Instanz mithilfe von steuern autostop.py Vorlage Skripte.

Nachdem wir die ML-Frameworks getestet hatten, entschieden wir uns für den SageMaker MXNet-Kernel für unsere Clustering- und Ranking-Phasen.

Um den Notebook-Code auf unseren Produktionsdaten zu testen, haben wir das Notebook ausgeführt, indem wir es über Docker in Amazon ECS gekapselt und als Verarbeitungsauftrag ausgeführt haben, um die maximale Laufzeit auf verschiedenen Maschinentypen zu validieren.

Der Docker-Container hilft uns auch dabei, Ressourcen zwischen den Notebook-Tests zu teilen. In manchen Fällen ruft ein Notebook andere Notebooks dazu auf, einen Multiprozess zu nutzen, indem es große Datenrahmen in kleinere Datenrahmen aufteilt, die gleichzeitig auf jeder vCPU in einem großen Maschinentyp ausgeführt werden können.

Die Echtzeit-Produktionsinferenzlösung

In der Forschungsphase haben wir Parkett verwendet Amazon Simple Storage-Service (Amazon S3)-Dateien, um unsere Empfehlungen beizubehalten. Diese werden einmal täglich aus unserer Engineering-Pipeline verbraucht, um die Empfehlungen an den Mechanismus unserer Warnungen anzuhängen.

Unsere Roadmap erfordert jedoch eine Lösung mit höherer Bildwiederholfrequenz und ein einmaliges Ziehen am Tag reicht auf lange Sicht nicht aus, da wir bereits während der Untersuchung Empfehlungen geben möchten.

Um diese Lösung im großen Maßstab zu implementieren, haben wir die meisten SageMaker-Endpunktlösungen in unserer Forschung zur Anomalieerkennung getestet. Wir haben 500 der vorgefertigten Modelle mit einem einzelnen Endpunktcomputer verschiedener Typen getestet und gleichzeitig Multithread-Clients verwendet, um Anfragen an den Endpunkt auszuführen. Wir haben die Reaktionszeit, CPU, Speicher und andere Kennzahlen gemessen (weitere Informationen finden Sie unter Überwachen Sie Amazon SageMaker mit Amazon CloudWatch). Wir haben festgestellt, dass der Multimodell-Endpunkt perfekt für unsere Anwendungsfälle geeignet ist.

Ein Endpunkt mit mehreren Modellen kann unsere Kosten im Vergleich zu einem einzelnen Endpunkt oder sogar Kubernetes zur Verwendung von Flask-Webdiensten (oder anderen Python-Webdiensten) erheblich senken. Unsere erste Annahme war, dass wir für jeden Kunden einen einzelnen Endpunkt mit einer kleinen Maschine mit 4 vCPUs bereitstellen und im Durchschnitt vier dedizierte Modelle abfragen müssen, da jede vCPU ein Modell bedient. Mit dem Multi-Modell-Endpunkt könnten wir mehr Kunden auf einem einzigen Multi-Endpunkt-Computer zusammenfassen.

Wir hatten ein Modell und Codierungsdateien pro Kunde und nach Durchführung von Lasttests stellten wir fest, dass wir 50 Kunden bedienen konnten, wobei jeder 10 Modelle und sogar die kleinste ml.t2.medium-Instanz für unsere Lösungen nutzte.

In dieser Phase haben wir über die Verwendung nachgedacht Endpunkte mit mehreren Modellen. Multimodell-Endpunkte bieten eine skalierbare und kostengünstige Lösung für die Bereitstellung einer großen Anzahl von Modellen und ermöglichen Ihnen das Hosten mehrerer Modelle mit einem einzigen Inferenzcontainer. Dies reduziert die Hosting-Kosten durch eine verbesserte Endpunktauslastung im Vergleich zur Verwendung mehrerer kleiner Einzelmodell-Endpunkte, die jeweils einen einzelnen Kunden bedienen. Es reduziert auch den Bereitstellungsaufwand, da SageMaker das Laden von Modellen in den Speicher und deren Skalierung basierend auf den Datenverkehrsmustern zu ihnen verwaltet.

Darüber hinaus besteht der Vorteil des Multi-Modell-Endpunkts darin, dass bei einer hohen Inferenzrate von bestimmten Kunden das Framework die zuletzt bereitgestellten Modelle im Speicher behält, um eine bessere Leistung zu erzielen.

Nachdem wir die Kosten mithilfe von Endpunkten mit mehreren Modellen im Vergleich zu Standardendpunkten geschätzt hatten, stellten wir fest, dass dies möglicherweise zu einer Kostenreduzierung von etwa 80 % führen könnte.

Das Ergebnis

In diesem Abschnitt überprüfen wir die Schritte und das Ergebnis des Prozesses.

Wir verwenden die Lifecycle-Notebook-Konfiguration, um die Ausführung der Notebooks als Verarbeitungsjobs zu ermöglichen, indem wir das Notebook in einen Docker-Container kapseln, um den Code schneller zu validieren und den Autostop-Mechanismus zu verwenden:

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

Wir klonen das sagemaker-run-notebook GitHub-Projekt und fügen Sie dem Container Folgendes hinzu:

Unsere Pip-Anforderungen
Die Möglichkeit, Notebooks aus einem Notebook heraus auszuführen, was uns ein Multi-Processing-Verhalten ermöglicht, um alle Kerne der ml.m5.12xlarge-Instanz zu nutzen

Dadurch können wir Workflows ausführen, die aus vielen Notebooks bestehen, die als Verarbeitungsjobs in einer Codezeile ausgeführt werden, und gleichzeitig den Instanztyp definieren, auf dem ausgeführt werden soll.

Da wir dem Notebook Parameter hinzufügen können, können wir unsere Verarbeitung skalieren, indem wir sie gleichzeitig zu verschiedenen Stunden, Tagen oder Monaten ausführen, um Daten abzurufen und zu verarbeiten.

Wir können auch Planungsjobs erstellen, die Notebooks ausführen (und sogar die Laufzeit begrenzen).

Wir können auch die letzten Läufe und deren Details, wie z. B. die Bearbeitungszeit, beobachten.

Mit der Papiermühle, die im Container verwendet wird, können wir die Ausgabe jedes Laufs anzeigen, was uns beim Debuggen in der Produktion hilft.

Unsere Überprüfung der Notebook-Ausgabe erfolgt in Form eines standardmäßigen schreibgeschützten Notebooks.

Durch die Nutzung mehrerer Prozessoren können wir die Verarbeitung jedes Notebooks skalieren und alle Kerne nutzen. Wir haben in anderen Notebooks Funktionen generiert, die eine umfangreiche Verarbeitung durchführen können, wie zum Beispiel die folgenden:

JSONs auflösen
Suchen Sie nach relevanten Zeilen in einem DataFrame, während das Hauptnotizbuch den DataFrame aufteilt #cpu-cores Elemente
Führen Sie Clustering-Aktionen pro Alarmtyp gleichzeitig aus

Anschließend fügen wir diese funktionalen Notebooks dem Container hinzu, der das Notebook als Verarbeitungsauftrag ausführt. Sehen Sie sich die folgende Docker-Datei an (beachten Sie die COPY-Befehle):

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

Die Ergebnisse

Während der Forschungsphase haben wir die Möglichkeit geprüft, unsere Notebooks so auszuführen, wie sie sind, um zu experimentieren und zu bewerten, wie sich unser Code mit allen unseren relevanten Daten und nicht nur mit einer Stichprobe von Daten verhält. Wir haben festgestellt, dass die Kapselung unserer Notebooks mithilfe von Verarbeitungsaufträgen eine gute Lösung für uns sein kann, da wir den Code nicht neu schreiben müssen und die Leistung der rechen- und speicheroptimierten AWS-Instanzen nutzen und den Status des Prozesses problemlos verfolgen können.

Während der Inferenzbewertung haben wir verschiedene SageMaker-Endpunktlösungen bewertet. Wir haben herausgefunden, dass die Verwendung eines Endpunkts mit mehreren Modellen uns dabei helfen kann, etwa 50 Kunden zu bedienen, von denen jeder über mehrere (ungefähr 10) Modelle in einer einzigen Instanz verfügt. Dadurch können wir unsere Anforderungen an niedrige Latenzzeiten erfüllen und uns daher bis zu 80 % der Kosten einsparen .

Mit dieser Lösungsarchitektur konnten wir die MTTR unserer Kunden reduzieren, die eine wichtige Messgröße für die Erfolgsmessung unserer Plattform darstellt. Es verkürzt die Gesamtzeit von der Reaktion auf unseren Warnlink, der ein Problem in Ihren Systemen beschreibt, bis zu dem Zeitpunkt, an dem Sie mit der Untersuchung des Problems über unsere Plattform fertig sind. Während der Untersuchungsphase messen wir die Aktionen der Nutzer mit und ohne unsere ML-Empfehlungslösung. Dies hilft uns, Empfehlungen für die besten Maßnahmen zu geben, um das spezifische Problem schneller zu lösen und Anomalien zu lokalisieren, um die tatsächliche Ursache des Problems zu identifizieren.

Fazit und nächste Schritte

In diesem Beitrag haben wir erzählt, wie Logz.io SageMaker verwendet hat, um MTTD und MTTR zu verbessern.

Als nächsten Schritt überlegen wir, die Lösung um folgende Funktionen zu erweitern:

Wir ermutigen Sie, es auszuprobieren SageMaker-Notizbücher. Weitere Beispiele finden Sie im SageMaker-Beispiele GitHub-Repo.

Über die Autoren

Amit Gross leitet die Forschungsabteilung von Logz.io, die für die KI-Lösungen aller Logz.io-Produkte verantwortlich ist, von der Forschungsphase bis zur Integrationsphase. Vor Logz.io leitete Amit sowohl die Data Science- als auch die Sicherheitsforschungsgruppen bei Here Inc. und Cellebrite Inc. Amit hat einen M.Sc. in Informatik von der Universität Tel Aviv.

Yaniv Vaknin ist Spezialist für maschinelles Lernen bei Amazon Web Services. Vor AWS hatte Yaniv Führungspositionen bei KI-Startups und Unternehmen inne, unter anderem als Mitbegründer und CEO von Dipsee.ai. Yaniv arbeitet mit AWS-Kunden zusammen, um die Leistungsfähigkeit des maschinellen Lernens zu nutzen, um reale Aufgaben zu lösen und Mehrwert zu schaffen. In seiner Freizeit spielt Yaniv gerne mit seinen Jungs Fußball.

Eitan Sela ist ein Machine Learning Specialist Solutions Architect bei Amazon Web Services. Er arbeitet mit AWS-Kunden zusammen, um Anleitungen und technische Unterstützung bereitzustellen und ihnen dabei zu helfen, Lösungen für maschinelles Lernen auf AWS zu entwickeln und zu betreiben. In seiner Freizeit geht Eitan gerne joggen und liest die neuesten Artikel über maschinelles Lernen.