In che modo Logz.io accelera i consigli ML e le soluzioni di rilevamento delle anomalie con Amazon SageMaker

Ripubblicato da Platone

Seguaci: 0

Logz.io è un partner tecnologico avanzato di AWS Partner Network (APN). Competenze AWS in DevOps, sicurezza e dati e analisi. Logz.io offre una piattaforma di osservabilità SaaS (Software as a Service) basata sulle migliori soluzioni software open source per analisi di log, metriche e tracciamenti. I clienti inviano una quantità crescente di dati a Logz.io da varie fonti di dati per gestire l'integrità e le prestazioni delle loro applicazioni e servizi. Può essere travolgente per i nuovi utenti che desiderano navigare tra le varie dashboard create nel tempo, elaborare diverse notifiche di avviso e collegare i punti durante la risoluzione dei problemi di produzione.

Il tempo medio di rilevamento (MTTD) e il tempo medio di risoluzione (MTTR) sono parametri chiave per i nostri clienti. Vengono calcolati misurando il tempo in cui un utente nella nostra piattaforma inizia a indagare su un problema (come l'interruzione del servizio di produzione) fino al punto in cui smette di eseguire azioni sulla piattaforma correlate all'indagine specifica.

Per aiutare i clienti a ridurre MTTD e MTTR, Logz.io si sta rivolgendo al machine learning (ML) per fornire consigli su dashboard e query pertinenti ed eseguire il rilevamento di anomalie tramite autoapprendimento. Di conseguenza, l’utente medio dispone dell’esperienza aggregata dell’intera azienda, sfruttando la saggezza di molti. Abbiamo scoperto che la nostra soluzione può ridurre l’MTTR fino al 20%.

Man mano che l'MTTD diminuisce, gli utenti possono identificare il problema e risolverlo più rapidamente. Il nostro livello semantico dei dati contiene la semantica per avviare e interrompere un'indagine e la popolarità di ciascuna azione eseguita dall'utente rispetto a un avviso specifico.

In questo post condividiamo l'utilizzo di Logz.io Amazon Sage Maker per ridurre il tempo e gli sforzi per la nostra prova di concetto (POC), gli esperimenti dalla ricerca alla valutazione della produzione e come abbiamo ridotto i costi di inferenza della produzione.

La sfida

Fino a quando Logz.io non utilizzava SageMaker, il tempo tra la ricerca, i test POC e gli esperimenti sulla produzione era piuttosto lungo. Questo perché dovevamo creare processi Spark per raccogliere, pulire e normalizzare i dati. DevOps ha richiesto questo lavoro per leggere ogni origine dati. Le competenze DevOps e di ingegneria dei dati non fanno parte del nostro team ML e ciò ha causato un'elevata dipendenza tra i team.

Un'altra sfida è stata quella di fornire un servizio di inferenza ML ai nostri prodotti ottenendo al tempo stesso un rapporto costi/prestazioni ottimale. Il nostro scenario ottimale supporta il maggior numero possibile di modelli per un'unità di calcolo, fornendo al contempo un'elevata concorrenza da parte dei clienti con molti modelli. Avevamo flessibilità sul tempo di inferenza, perché la nostra finestra iniziale del flusso di dati per il servizio di inferenza è un intervallo di log di 5 minuti.

Fase di ricerca

La scienza dei dati è un processo iterativo che richiede un ambiente di sviluppo interattivo per la ricerca, convalidando l'output dei dati su ogni iterazione ed elaborazione dei dati. Pertanto, incoraggiamo i nostri ricercatori ML a utilizzare i notebook.

Per accelerare il ciclo di iterazione, volevamo testare il codice dei nostri notebook su dati di produzione reali, eseguendo il tutto su larga scala. Inoltre, volevamo evitare il collo di bottiglia di DevOps e data engineering durante il test iniziale in produzione, pur avendo la possibilità di visualizzare gli output e provare a stimare il runtime del codice.

Per implementare tutto ciò, volevamo fornire al nostro team di data science il pieno controllo e la responsabilità end-to-end dalla ricerca al test iniziale sulla produzione. Ne avevamo bisogno per estrarre facilmente i dati, preservando la gestione dell'accesso ai dati e monitorando tale accesso. Avevano inoltre bisogno di distribuire facilmente i propri notebook POC personalizzati in produzione in modo scalabile, monitorando al tempo stesso il tempo di esecuzione e i costi previsti.

Fase di valutazione

Durante questa fase, abbiamo valutato alcune piattaforme ML per supportare sia i requisiti di formazione che quelli di servizio. Abbiamo scoperto che SageMaker è il più appropriato per i nostri casi d'uso perché supporta sia l'addestramento che l'inferenza. Inoltre, è personalizzabile, quindi possiamo personalizzarlo in base al nostro processo di ricerca preferito.

Inizialmente siamo partiti da notebook locali, testando varie librerie. Abbiamo riscontrato problemi nell'estrazione di enormi quantità di dati dalla produzione. Successivamente, siamo rimasti bloccati in un punto della fase di modellazione che richiedeva molte ore su una macchina locale.

Abbiamo valutato molte soluzioni e alla fine abbiamo scelto la seguente architettura:

Targa dati – La versione open source di Targa dati ci ha aiutato a estrarre e unire facilmente i nostri dati utilizzando il nostro Spark Amazon EMR cluster con un semplice SQL, monitorando l'accesso ai dati
Istanza notebook SageMaker e processi di elaborazione – Questo ci ha aiutato con la scalabilità del runtime e la flessibilità dei tipi di macchine e dei framework ML, collaborando al tempo stesso al nostro codice tramite una connessione Git

Architettura della soluzione della fase di ricerca

Il diagramma seguente illustra l'architettura della soluzione della fase di ricerca ed è composta dai seguenti componenti:

Taccuini SageMaker – I data scientist li usano computer portatili per condurre le loro ricerche.
Funzione AWS Lambda - AWS Lambda è una soluzione serverless che esegue un processo di elaborazione su richiesta. Il lavoro utilizza un contenitore Docker con il notebook che vogliamo eseguire durante il nostro esperimento, insieme a tutti i nostri file comuni che devono supportare il notebook (requirements.txt e il codice delle funzioni multi-elaborazione in un notebook separato).
Amazon ECR - Registro dei contenitori Amazon Elastic (Amazon ECR) memorizza il nostro contenitore Docker.
Lavoro di elaborazione di SageMaker – Possiamo gestirlo lavoro di elaborazione dati su qualsiasi macchina ML ed esegue il nostro notebook con parametri.
Targa dati – Questo servizio ci aiuta a utilizzare SQL e a unire facilmente diverse origini dati. Lo traduce in codice Spark e lo ottimizza, monitorando l'accesso ai dati e contribuendo a ridurre le violazioni dei dati. La versione Xtra offriva ancora più funzionalità.
Amazon EMR – Questo servizio esegue le nostre estrazioni di dati come carichi di lavoro su Spark, contattando tutte le nostre risorse di dati.

Con il ciclo di vita dell'istanza notebook SageMaker, possiamo controllare il tempo di esecuzione massimo dell'istanza notebook, utilizzando il file autostop.py modello script.

Dopo aver testato i framework ML, abbiamo scelto il kernel SageMaker MXNet per le nostre fasi di clustering e ranking.

Per testare il codice del notebook sui nostri dati di produzione, abbiamo eseguito il notebook incapsulandolo tramite Docker in Amazon ECS e lo abbiamo eseguito come processo di elaborazione per convalidare il tempo di esecuzione massimo su diversi tipi di macchine.

Il contenitore Docker ci aiuta anche a condividere le risorse tra i test dei notebook. In alcuni casi, un notebook chiama altri notebook per utilizzare un multiprocesso suddividendo i frame di dati di grandi dimensioni in frame di dati più piccoli, che possono essere eseguiti simultaneamente su ciascuna vCPU in un tipo di macchina di grandi dimensioni.

La soluzione di inferenza della produzione in tempo reale

Nella fase di ricerca abbiamo utilizzato Parquet Servizio di archiviazione semplice Amazon (Amazon S3) per mantenere i nostri consigli. Questi vengono utilizzati una volta al giorno dalla nostra pipeline di progettazione per allegare le raccomandazioni al nostro meccanismo di avvisi.

Tuttavia, la nostra tabella di marcia richiede una soluzione con frequenza di aggiornamento più elevata e tirare una volta al giorno non è sufficiente a lungo termine, perché vogliamo fornire consigli anche durante l'indagine.

Per implementare questa soluzione su larga scala, abbiamo testato la maggior parte delle soluzioni endpoint SageMaker nella nostra ricerca sul rilevamento delle anomalie. Abbiamo testato 500 modelli predefiniti con un singolo computer endpoint di vario tipo e utilizzato client multi-thread simultanei per eseguire richieste all'endpoint. Abbiamo misurato il tempo di risposta, la CPU, la memoria e altri parametri (per ulteriori informazioni, vedere Monitora Amazon SageMaker con Amazon CloudWatch). Abbiamo scoperto che l'endpoint multimodello è perfetto per i nostri casi d'uso.

Un endpoint multimodello può ridurre drasticamente i nostri costi rispetto a un singolo endpoint o persino a Kubernetes per utilizzare i servizi Web Flask (o altri Python). Il nostro primo presupposto era che dovessimo fornire un singolo endpoint, utilizzando una piccola macchina da 4 vCPU, per ogni cliente e interrogare in media quattro modelli dedicati, perché ogni vCPU serve un modello. Con l'endpoint multi-modello, potremmo aggregare più clienti su un unico computer multi-endpoint.

Avevamo un modello e file di codifica per cliente e, dopo aver eseguito test di carico, abbiamo stabilito che potevamo servire 50 clienti, ciascuno utilizzando 10 modelli e persino utilizzando l'istanza ml.t2.medium più piccola per le nostre soluzioni.

In questa fase, abbiamo considerato l'utilizzo endpoint multi-modello. Gli endpoint multimodello forniscono una soluzione scalabile ed economica per distribuire un gran numero di modelli, consentendo di ospitare più modelli con un unico contenitore di inferenza. Ciò riduce i costi di hosting migliorando l'utilizzo degli endpoint rispetto all'utilizzo di più piccoli endpoint a modello singolo che servono ciascuno un singolo cliente. Riduce inoltre il sovraccarico di distribuzione poiché SageMaker gestisce il caricamento dei modelli in memoria e il loro ridimensionamento in base ai modelli di traffico verso di essi.

Inoltre, il vantaggio dell'endpoint multi-modello è che se si dispone di un'elevata velocità di inferenza da parte di clienti specifici, il suo framework preserva gli ultimi modelli di servizio in memoria per prestazioni migliori.

Dopo aver stimato i costi utilizzando endpoint multimodello rispetto a endpoint standard, abbiamo scoperto che ciò potrebbe potenzialmente portare a una riduzione dei costi di circa l'80%.

Il risultato

In questa sezione esaminiamo le fasi e l’esito del processo.

Utilizziamo la configurazione del notebook del ciclo di vita per abilitare l'esecuzione dei notebook come processi di elaborazione, incapsulando il notebook in un contenitore Docker per convalidare il codice più velocemente e utilizzare il meccanismo di arresto automatico:

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

Cloniamo il sagemaker-run-notebook Progetto GitHub e aggiungi quanto segue al contenitore:

I nostri requisiti pip
La possibilità di eseguire notebook dall'interno di un notebook, che ci consente un comportamento multi-elaborazione per utilizzare tutti i core di istanze ml.m5.12xlarge

Ciò ci consente di eseguire flussi di lavoro costituiti da molti notebook eseguiti come processi di elaborazione in una riga di codice, definendo al contempo il tipo di istanza su cui eseguire.

Poiché possiamo aggiungere parametri al notebook, possiamo ridimensionare la nostra elaborazione eseguendo simultaneamente orari, giorni o mesi diversi per estrarre ed elaborare i dati.

Possiamo anche creare lavori di pianificazione che eseguono notebook (e persino limitare il tempo di esecuzione).

Possiamo anche osservare le ultime esecuzioni e i loro dettagli, come il tempo di elaborazione.

Con la cartiera utilizzata nel contenitore, possiamo visualizzare l'output di ogni esecuzione, il che ci aiuta a eseguire il debug in produzione.

La nostra revisione dell'output del notebook ha la forma di un notebook standard di sola lettura.

L'utilizzo multiprocessore ci aiuta a scalare l'elaborazione di ciascun notebook e a utilizzarne tutti i core. Abbiamo generato funzioni in altri notebook che possono eseguire elaborazioni pesanti, come le seguenti:

Esplodi JSON
Trova le righe pertinenti in un DataFrame mentre il notebook principale divide il DataFrame #cpu-cores elementi
Esegui contemporaneamente il clustering per azioni di tipo avviso

Aggiungiamo quindi questi notebook funzionali nel contenitore che esegue il notebook come processo di elaborazione. Vedi il seguente file Docker (nota i comandi 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

Risultati

Durante la fase di ricerca, abbiamo valutato l'opzione di eseguire i nostri notebook così come sono per sperimentare e valutare le prestazioni del nostro codice su tutti i nostri dati rilevanti, non solo su un campione di dati. Abbiamo scoperto che incapsulare i nostri notebook utilizzando processi di elaborazione può essere un'ottima soluzione per noi, perché non abbiamo bisogno di riscrivere il codice e possiamo sfruttare la potenza delle istanze ottimizzate per il calcolo e la memoria di AWS e seguire facilmente lo stato del processo.

Durante la valutazione dell'inferenza, abbiamo valutato varie soluzioni endpoint SageMaker. Abbiamo scoperto che l'utilizzo di un endpoint multi-modello può aiutarci a servire circa 50 clienti, ciascuno con più modelli (circa 10) in una singola istanza, il che può soddisfare i nostri vincoli di bassa latenza e quindi farci risparmiare fino all'80% dei costi .

Con questa architettura di soluzione, siamo stati in grado di ridurre l'MTTR dei nostri clienti, che è un parametro principale per misurare il successo utilizzando la nostra piattaforma. Riduce il tempo totale dal momento in cui rispondi al nostro collegamento di avviso, che descrive un problema nei tuoi sistemi, a quando hai finito di indagare sul problema utilizzando la nostra piattaforma. Durante la fase di indagine, misuriamo le azioni degli utenti con e senza la nostra soluzione di consigli ML. Questo ci aiuta a fornire consigli sull'azione migliore per risolvere più rapidamente il problema specifico e individuare le anomalie per identificare la causa effettiva del problema.

Conclusione e prossimi passi

In questo post abbiamo condiviso come Logz.io ha utilizzato SageMaker per migliorare MTTD e MTTR.

Come passo successivo, stiamo valutando di espandere la soluzione con le seguenti funzionalità:

Ti invitiamo a provare Taccuini SageMaker. Per ulteriori esempi, consulta il Esempi di repository GitHub di SageMaker.

Informazioni sugli autori

Amit Gross è a capo del dipartimento di ricerca di Logz.io, che è responsabile delle soluzioni AI di tutti i prodotti Logz.io, dalla fase di ricerca alla fase di integrazione. Prima di Logz.io Amit ha gestito sia i gruppi di ricerca sulla scienza dei dati che quelli sulla sicurezza presso Here inc. e Cellebrite Inc. Amit ha conseguito un master in informatica presso l'Università di Tel-Aviv.

Yaniv Vaknin è uno specialista di machine learning presso Amazon Web Services. Prima di AWS, Yaniv ha ricoperto posizioni di leadership presso startup ed Enterprise basate sull'intelligenza artificiale, tra cui cofondatore e CEO di Dipsee.ai. Yaniv collabora con i clienti AWS per sfruttare la potenza del machine learning per risolvere attività del mondo reale e ricavare valore. Nel tempo libero, Yaniv ama giocare a calcio con i suoi ragazzi.

Eitan Sela è un architetto specializzato in soluzioni di machine learning con Amazon Web Services. Collabora con i clienti AWS per fornire guida e assistenza tecnica, aiutandoli a creare e utilizzare soluzioni di machine learning su AWS. Nel tempo libero, Eitan si diverte a fare jogging e leggere gli ultimi articoli sull'apprendimento automatico.