Jak Logz.io przyspiesza rekomendacje ML i rozwiązania do wykrywania anomalii dzięki Amazon SageMaker

Opublikowane ponownie przez Plato

Obserwuje: 0

Logz.io jest zaawansowanym partnerem technologicznym AWS Partner Network (APN). Kompetencje AWS w zakresie DevOps, bezpieczeństwa oraz danych i analiz. Logz.io oferuje platformę obserwacji oprogramowania jako usługi (SaaS) opartą na najlepszych w swojej klasie rozwiązaniach oprogramowania typu open source do analizy logów, metryk i śledzenia. Klienci wysyłają do Logz.io coraz więcej danych z różnych źródeł, aby zarządzać stanem i wydajnością swoich aplikacji i usług. Może to być przytłaczające dla nowych użytkowników, którzy chcą poruszać się po różnych pulpitach nawigacyjnych tworzonych w czasie, przetwarzać różne powiadomienia o alertach i łączyć kropki podczas rozwiązywania problemów produkcyjnych.

Średni czas do wykrycia (MTTD) i średni czas do rozwiązania (MTTR) to kluczowe wskaźniki dla naszych klientów. Oblicza się je, mierząc czas, w jakim użytkownik na naszej platformie zaczyna badać problem (taki jak niedostępna usługa produkcyjna) do momentu, w którym przestaje wykonywać działania na platformie związane z konkretnym dochodzeniem.

Aby pomóc klientom zmniejszyć MTTD i MTTR, Logz.io zwraca się do uczenia maszynowego (ML), aby dostarczać rekomendacje dla odpowiednich pulpitów nawigacyjnych i zapytań oraz przeprowadzać wykrywanie anomalii poprzez samouczenie. W rezultacie przeciętny użytkownik jest wyposażony w zagregowane doświadczenie całej firmy, wykorzystując mądrość wielu osób. Odkryliśmy, że nasze rozwiązanie może obniżyć MTTR nawet o 20%.

Wraz ze spadkiem MTTD użytkownicy mogą zidentyfikować problem i szybciej go rozwiązać. Nasza warstwa semantyczna danych zawiera semantykę rozpoczynania i zatrzymywania dochodzenia oraz popularność każdej czynności wykonywanej przez użytkownika w odniesieniu do określonego alertu.

W tym poście dzielimy się sposobem korzystania z Logz.io Amazon Sage Maker aby skrócić czas i wysiłek związany z weryfikacją koncepcji (POC), eksperymentami od badań po ocenę produkcji oraz jak zmniejszyliśmy koszty wnioskowania o produkcji.

Wyzwanie

Dopóki Logz.io nie korzystało z SageMakera, czas między badaniami, testami POC i eksperymentami na produkcji był dość długi. Stało się tak, ponieważ musieliśmy utworzyć zadania platformy Spark w celu zbierania, czyszczenia i normalizacji danych. DevOps wymagał tej pracy, aby odczytać każde źródło danych. Umiejętności DevOps i inżynierii danych nie należą do naszego zespołu ML, co spowodowało dużą zależność między zespołami.

Kolejnym wyzwaniem było zapewnienie naszym produktom usługi wnioskowania ML przy jednoczesnym osiągnięciu optymalnego stosunku kosztów do wydajności. Naszym optymalnym scenariuszem jest obsługa jak największej liczby modeli dla jednostki obliczeniowej, przy jednoczesnym zapewnieniu dużej współbieżności od klientów z wieloma modelami. Mieliśmy elastyczność co do czasu wnioskowania, ponieważ nasze początkowe okno strumienia danych dla usługi wnioskowania to 5 minut wiadra dzienników.

Faza badań

Nauka o danych to proces iteracyjny, który wymaga interaktywnego środowiska programistycznego do badań, weryfikującego dane wyjściowe w każdej iteracji i przetwarzaniu danych. Dlatego zachęcamy naszych badaczy ML do korzystania z notatników.

Aby przyspieszyć cykl iteracji, chcieliśmy przetestować kod naszych notebooków na rzeczywistych danych produkcyjnych, jednocześnie uruchamiając go na dużą skalę. Ponadto chcieliśmy uniknąć wąskich gardeł DevOps i inżynierii danych podczas wstępnego testu w środowisku produkcyjnym, mając jednocześnie możliwość przeglądania danych wyjściowych i próby oszacowania czasu wykonania kodu.

Aby to wdrożyć, chcieliśmy zapewnić naszemu zespołowi analityki danych pełną kontrolę i pełną odpowiedzialność od badań po wstępne testy na produkcji. Potrzebowaliśmy ich do łatwego pobierania danych, przy jednoczesnym zachowaniu zarządzania dostępem do danych i monitorowania tego dostępu. Musieli także łatwo wdrożyć swoje niestandardowe notebooki POC do produkcji w skalowalny sposób, jednocześnie monitorując czas działania i oczekiwane koszty.

Faza oceny

W tej fazie oceniliśmy kilka platform ML, aby spełnić wymagania dotyczące szkoleń i obsługi. Stwierdziliśmy, że SageMaker jest najbardziej odpowiedni dla naszych przypadków użycia, ponieważ obsługuje zarówno szkolenie, jak i wnioskowanie. Co więcej, można go dostosować, dzięki czemu możemy go dostosować do preferowanego przez nas procesu badawczego.

Początkowo zaczynaliśmy od lokalnych notatników, testując różne biblioteki. Napotkaliśmy problemy z pobieraniem ogromnych danych z produkcji. Później utknęliśmy w punkcie fazy modelowania, która trwała wiele godzin na lokalnej maszynie.

Oceniliśmy wiele rozwiązań i ostatecznie wybraliśmy następującą architekturę:

Tabliczka znamionowa – Otwarta wersja oprogramowania Tabliczka znamionowa pomogli nam w łatwy sposób pobierać i łączyć nasze dane, wykorzystując naszą platformę Spark Amazon EMR klastry z prostym SQL, przy jednoczesnym monitorowaniu dostępu do danych
Instancja notatnika SageMaker i zadania przetwarzania – Pomogło nam to w skalowalności środowiska uruchomieniowego i elastyczności typów maszyn i frameworków ML, jednocześnie współpracując z naszym kodem za pośrednictwem połączenia Git

Architektura rozwiązania fazy badawczej

Poniższy diagram ilustruje architekturę rozwiązania fazy badawczej i składa się z następujących elementów:

Notatniki SageMaker – Wykorzystują je analitycy danych laptopy do prowadzenia swoich badań.
AWS Funkcja lambda - AWS Lambda to rozwiązanie bezserwerowe, które uruchamia zadanie przetwarzania na żądanie. Zadanie wykorzystuje kontener Docker z notatnikiem, który chcemy uruchomić podczas naszego eksperymentu, wraz ze wszystkimi naszymi wspólnymi plikami, które muszą obsługiwać notatnik (requirements.txt oraz kod funkcji wieloprocesorowych w osobnym notatniku).
Amazon ECR - Rejestr elastycznego pojemnika Amazon (Amazon ECR) przechowuje nasz kontener Docker.
Zadanie przetwarzania SageMaker – Możemy to uruchomić zadanie przetwarzania danych na dowolnej maszynie ML i uruchamia nasz notatnik z parametrami.
Tabliczka znamionowa – Ta usługa pomaga nam używać SQL i łatwo łączyć kilka źródeł danych. Tłumaczy go na kod Spark i optymalizuje, jednocześnie monitorując dostęp do danych i pomagając ograniczyć naruszenia danych. Wersja Xtra zapewniała jeszcze większe możliwości.
Amazon EMR – Ta usługa obsługuje nasze ekstrakcje danych jako obciążenia w Spark, kontaktując się ze wszystkimi naszymi zasobami danych.

Dzięki cyklowi życia instancji notatnika SageMaker możemy kontrolować maksymalny czas działania instancji notatnika za pomocą autostop.py szablon skrypt.

Po przetestowaniu frameworków ML wybraliśmy jądro SageMaker MXNet do naszych faz klastrowania i rankingu.

Aby przetestować kod notebooka na naszych danych produkcyjnych, uruchomiliśmy notebooka, hermetyzując go za pomocą Dockera w Amazon ECS i uruchomiliśmy go jako zadanie przetwarzania w celu sprawdzenia maksymalnego czasu działania na różnych typach maszyn.

Kontener Docker pomaga nam również udostępniać zasoby między testami notebooków. W niektórych przypadkach notebook wywołuje inne notebooki w celu wykorzystania wielu procesów poprzez podzielenie dużych ramek danych na mniejsze ramki danych, które mogą działać jednocześnie na każdym vCPU w dużej maszynie.

Rozwiązanie do wnioskowania o produkcji w czasie rzeczywistym

W fazie badawczej użyliśmy Parquet Usługa Amazon Simple Storage (Amazon S3), aby zachować nasze rekomendacje. Są one zużywane raz dziennie z naszego potoku inżynieryjnego w celu dołączenia zaleceń do naszego mechanizmu alertów.

Jednak nasz plan wymaga rozwiązania z wyższą częstotliwością odświeżania, a pobieranie raz dziennie nie wystarcza na dłuższą metę, ponieważ chcemy przedstawiać zalecenia nawet podczas dochodzenia.

Aby wdrożyć to rozwiązanie na dużą skalę, przetestowaliśmy większość rozwiązań punktów końcowych SageMaker w naszych badaniach nad wykrywaniem anomalii. Przetestowaliśmy 500 gotowych modeli z pojedynczym komputerem końcowym różnych typów i użyliśmy współbieżnych klientów wielowątkowych do wykonywania żądań do punktu końcowego. Zmierzyliśmy czas odpowiedzi, procesor, pamięć i inne wskaźniki (aby uzyskać więcej informacji, zobacz Monitoruj Amazon SageMaker za pomocą Amazon CloudWatch). Odkryliśmy, że wielomodelowy punkt końcowy idealnie pasuje do naszych przypadków użycia.

Wielomodelowy punkt końcowy może radykalnie obniżyć nasze koszty w porównaniu z pojedynczym punktem końcowym, a nawet Kubernetes do korzystania z usług sieciowych Flask (lub innych Python). Naszym pierwszym założeniem było zapewnienie pojedynczego punktu końcowego, używając małej maszyny z 4 procesorami wirtualnymi, dla każdego klienta i średnio wysyłając zapytanie do czterech dedykowanych modeli, ponieważ każdy procesor wirtualny obsługuje jeden model. Dzięki wielomodelowemu punktowi końcowemu mogliśmy agregować więcej klientów na jednej maszynie z wieloma punktami końcowymi.

Mieliśmy model i pliki kodowania dla każdego klienta, a po przeprowadzeniu testów obciążenia ustaliliśmy, że możemy obsłużyć 50 klientów, z których każdy korzysta z 10 modeli, a nawet z najmniejszej instancji ml.t2.medium dla naszych rozwiązań.

Na tym etapie rozważaliśmy użycie wielomodelowe punkty końcowe. Wielomodelowe punkty końcowe zapewniają skalowalne i ekonomiczne rozwiązanie do wdrażania dużej liczby modeli, umożliwiając hostowanie wielu modeli za pomocą jednego kontenera wnioskowania. Zmniejsza to koszty hostingu, poprawiając wykorzystanie punktów końcowych w porównaniu z używaniem wielu małych punktów końcowych z jednym modelem, z których każdy obsługuje jednego klienta. Zmniejsza to również koszty wdrożenia, ponieważ SageMaker zarządza ładowaniem modeli do pamięci i skalowaniem ich na podstawie wzorców ruchu do nich.

Ponadto zaletą wielu modeli punktów końcowych jest to, że jeśli masz wysoki współczynnik wnioskowania od określonych klientów, jego struktura zachowuje w pamięci ostatnie obsługujące modele w celu uzyskania lepszej wydajności.

Po oszacowaniu kosztów przy użyciu wielomodelowych punktów końcowych w porównaniu ze standardowymi punktami końcowymi dowiedzieliśmy się, że może to potencjalnie doprowadzić do redukcji kosztów o około 80%.

Wynik

W tej sekcji omówimy kroki i wynik procesu.

Korzystamy z konfiguracji notatników cyklu życia, aby umożliwić uruchamianie notatników jako zadań przetwarzania, poprzez enkapsulację notatnika w kontenerze Docker w celu szybszej weryfikacji kodu i wykorzystania mechanizmu autostop:

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

Klonujemy notatnik sagemaker-run GitHub i dodaj następujące elementy do kontenera:

Nasze wymagania dotyczące pipsów
Możliwość uruchamiania notatników z poziomu notebooka, co umożliwia nam zachowanie wieloprocesowe w celu wykorzystania wszystkich rdzeni instancji ml.m5.12xlarge

Dzięki temu możemy uruchamiać przepływy pracy, które składają się z wielu notatników działających jako zadania przetwarzania w wierszu kodu, przy jednoczesnym definiowaniu typu instancji, na których mają być uruchamiane.

Ponieważ możemy dodawać parametry do notatnika, możemy skalować nasze przetwarzanie, uruchamiając je jednocześnie w różnych godzinach, dniach lub miesiącach w celu pobierania i przetwarzania danych.

Możemy również tworzyć zadania planowania, które uruchamiają notebooki (a nawet ograniczają czas działania).

Możemy również obserwować ostatnie uruchomienia i ich szczegóły, takie jak czas przetwarzania.

Dzięki papierni, która jest używana w kontenerze, możemy przeglądać dane wyjściowe każdego przebiegu, co pomaga nam debugować w produkcji.

Nasza recenzja wyników notatnika ma postać standardowego notatnika tylko do odczytu.

Wykorzystanie wieloprocesorowości pomaga nam skalować przetwarzanie każdego notebooka i wykorzystywać wszystkie jego rdzenie. Wygenerowaliśmy funkcje w innych notatnikach, które mogą wykonywać ciężkie przetwarzanie, takie jak:

Eksploduj pliki JSON
Znajdź odpowiednie wiersze w DataFrame, podczas gdy główny notatnik dzieli DataFrame na #cpu-cores Elementy
Uruchamiaj klastrowanie jednocześnie dla akcji typu alertu

Następnie dodajemy te funkcjonalne notesy do kontenera, który uruchamia notes jako zadanie przetwarzania. Zobacz następujący plik Dockera (zwróć uwagę na polecenia 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

Efekt

W fazie badawczej oceniliśmy możliwość uruchomienia naszych notatników w celu eksperymentowania i oceny działania naszego kodu na wszystkich istotnych danych, a nie tylko na próbce danych. Odkryliśmy, że enkapsulacja naszych notatników za pomocą zadań przetwarzania może być dla nas bardzo odpowiednia, ponieważ nie musimy przepisywać kodu i możemy wykorzystać moc instancji AWS zoptymalizowanych pod kątem obliczeń i pamięci oraz łatwo śledzić stan procesu.

Podczas oceny wnioskowania oceniliśmy różne rozwiązania punktów końcowych SageMaker. Odkryliśmy, że korzystanie z wielomodelowego punktu końcowego może pomóc nam obsłużyć około 50 klientów, z których każdy ma wiele (około 10) modeli w jednej instancji, co może spełnić nasze ograniczenia dotyczące małych opóźnień, a tym samym zaoszczędzić nam do 80% kosztów .

Dzięki tej architekturze rozwiązania byliśmy w stanie obniżyć MTTR naszych klientów, który jest głównym miernikiem sukcesu korzystania z naszej platformy. Skraca to całkowity czas od momentu odpowiedzi na nasz link alertu, który opisuje problem w Twoich systemach, do zakończenia badania problemu za pomocą naszej platformy. Na etapie dochodzenia mierzymy działania użytkowników z naszym rozwiązaniem rekomendacji ML i bez niego. Pomaga nam to w dostarczaniu zaleceń dotyczących najlepszych działań w celu szybszego rozwiązania konkretnego problemu i wskazywania anomalii w celu zidentyfikowania faktycznej przyczyny problemu.

Podsumowanie i kolejne kroki

W tym poście podzieliliśmy się tym, jak Logz.io wykorzystał SageMaker do poprawy MTTD i MTTR.

W kolejnym kroku rozważamy rozszerzenie rozwiązania o następujące funkcje:

Zachęcamy do wypróbowania Notatniki SageMaker. Aby uzyskać więcej przykładów, sprawdź Przykłady SageMaker repozytorium GitHub.

O autorach

Amita Grossa kieruje działem badań Logz.io, który jest odpowiedzialny za rozwiązania AI wszystkich produktów Logz.io, od fazy badań do fazy integracji. Przed Logz.io Amit zarządzał zarówno Data Science, jak i Security Research Group w Here Inc. i Cellebrite Inc. Amit uzyskał tytuł magistra informatyki na Uniwersytecie w Tel Awiwie.

Janiw Waknin jest specjalistą ds. uczenia maszynowego w Amazon Web Services. Przed AWS Yaniv zajmował kierownicze stanowiska w startupach zajmujących się sztuczną inteligencją i przedsiębiorstwami, w tym był współzałożycielem i dyrektorem generalnym Dipsee.ai. Yaniv współpracuje z klientami AWS, aby wykorzystać moc uczenia maszynowego do rozwiązywania rzeczywistych zadań i uzyskiwania wartości. W wolnym czasie Yaniv lubi grać w piłkę nożną ze swoimi chłopcami.

Eitana Seli jest specjalistą ds. rozwiązań w zakresie uczenia maszynowego w Amazon Web Services. Współpracuje z klientami AWS, zapewniając wskazówki i pomoc techniczną, pomagając im budować i obsługiwać rozwiązania uczenia maszynowego w AWS. W wolnym czasie Eitan lubi biegać i czytać najnowsze artykuły o uczeniu maszynowym.