Як Logz.io прискорює рекомендації машинного навчання та рішення для виявлення аномалій за допомогою Amazon SageMaker

Перевидано Платоном

читають: 0

Logz.io є партнером AWS Partner Network (APN) Advanced Technology Partner Компетенції AWS у DevOps, Security, Data & Analytics. Logz.io пропонує платформу спостереження програмного забезпечення як послуги (SaaS), яка базується на найкращих у своєму класі програмних рішеннях з відкритим вихідним кодом для аналізу журналів, показників і трасування. Клієнти надсилають все більше даних на Logz.io з різних джерел даних, щоб керувати працездатністю та продуктивністю своїх програм і сервісів. Це може бути надзвичайно важко для нових користувачів, які хочуть переміщатися між різними інформаційними панелями, створеними з часом, обробляти різні сповіщення про сповіщення та з’єднувати точки під час усунення виробничих проблем.

Середній час виявлення (MTTD) і середній час вирішення (MTTR) є ключовими показниками для наших клієнтів. Вони розраховуються шляхом вимірювання часу, протягом якого користувач на нашій платформі починає досліджувати проблему (наприклад, припинення роботи служби виробництва) до того моменту, коли він припиняє виконувати дії на платформі, пов’язані з конкретним дослідженням.

Щоб допомогти клієнтам зменшити MTTD і MTTR, Logz.io звертається до машинного навчання (ML), щоб надавати рекомендації для відповідних інформаційних панелей і запитів і виконувати виявлення аномалій за допомогою самонавчання. У результаті пересічний користувач отримує сукупний досвід усієї своєї компанії, використовуючи мудрість багатьох. Ми виявили, що наше рішення може зменшити MTTR до 20%.

Коли MTTD зменшується, користувачі можуть швидше визначити проблему та вирішити її. Наш семантичний рівень даних містить семантику для початку та припинення розслідування, а також популярність кожної дії, яку користувач виконує щодо певного сповіщення.

У цій публікації ми розповідаємо, як використовувався Logz.io Amazon SageMaker щоб скоротити час і зусилля для нашого підтвердження концепції (POC), експериментів від досліджень до оцінки виробництва, а також як ми зменшили витрати на виробничі висновки.

Змагання

Поки Logz.io не використовував SageMaker, час між дослідженнями та тестуванням POC та експериментами на виробництві був досить тривалим. Це було тому, що нам потрібно було створити завдання Spark для збору, очищення та нормалізації даних. DevOps вимагала цієї роботи для читання кожного джерела даних. DevOps і навички розробки даних не є частиною нашої команди ML, і це спричинило високу залежність між командами.

Іншим завданням було надати послугу ML для наших продуктів, досягнувши оптимального співвідношення вартості та продуктивності. Наш оптимальний сценарій полягає в підтримці якомога більшої кількості моделей для обчислювального блоку, водночас забезпечуючи високий рівень паралелізму від клієнтів із багатьма моделями. У нас була гнучкість щодо часу висновків, оскільки наше початкове вікно потоку даних для служби висновків становить 5 хвилин журналів.

Етап дослідження

Наука про дані — це ітераційний процес, який вимагає інтерактивного середовища розробки для дослідження, перевірки вихідних даних на кожній ітерації та обробки даних. Тому ми заохочуємо наших дослідників ML використовувати блокноти.

Щоб прискорити цикл ітерації, ми хотіли перевірити код наших ноутбуків на реальних виробничих даних, одночасно запускаючи його в масштабі. Крім того, ми хотіли уникнути вузьких місць DevOps та обробки даних під час початкового тестування у виробництві, маючи можливість переглядати результати та намагатися оцінити час виконання коду.

Щоб реалізувати це, ми хотіли надати нашій команді з обробки даних повний контроль і наскрізну відповідальність від дослідження до початкового тестування на виробництві. Нам потрібні були вони, щоб легко отримувати дані, зберігаючи при цьому керування доступом до даних і моніторинг цього доступу. Їм також потрібно було легко розгорнути свої власні ноутбуки POC у виробництві з можливістю масштабування, одночасно відстежуючи час роботи та очікувані витрати.

Фаза оцінювання

Під час цього етапу ми оцінили кілька платформ машинного навчання, щоб підтримати вимоги як до навчання, так і до обслуговування. Ми виявили, що SageMaker найбільше підходить для наших випадків використання, оскільки він підтримує як навчання, так і висновки. Крім того, його можна налаштувати, тому ми можемо адаптувати його відповідно до нашого бажаного дослідницького процесу.

Спочатку ми почали з локальних блокнотів, тестуючи різні бібліотеки. У нас виникли проблеми з вилученням масивних даних із виробництва. Пізніше ми застрягли на етапі моделювання, який зайняв багато годин на локальній машині.

Ми оцінили багато рішень і врешті вибрали таку архітектуру:

DataPlate – Версія з відкритим кодом DataPlate допоміг нам легко отримати та об’єднати наші дані за допомогою нашого Spark Amazon EMR кластери за допомогою простого SQL, одночасно відстежуючи доступ до даних
Екземпляр блокнота SageMaker і завдання обробки – Це допомогло нам з масштабованістю середовища виконання та гнучкістю типів машин і фреймворків ML, під час спільної роботи над нашим кодом через з’єднання Git

Архітектура рішення фази дослідження

Наступна діаграма ілюструє архітектуру рішення на етапі дослідження та складається з таких компонентів:

Зошити SageMaker – Цим користуються дослідники даних ноутбуки для проведення своїх досліджень.
Функція AWS Lambda - AWS Lambda це безсерверне рішення, яке виконує завдання обробки на вимогу. Завдання використовує контейнер Docker із блокнотом, який ми хочемо запустити під час нашого експерименту, разом із усіма нашими звичайними файлами, які мають підтримувати блокнот (requirements.txt і код функцій багатопроцесорної обробки в окремому блокноті).
Amazon ECR - Реєстр контейнерів Amazon Elastic (Amazon ECR) зберігає наш контейнер Docker.
Завдання обробки SageMaker – Ми можемо це запустити робота з обробки даних на будь-якій машині ML, і він запускає наш блокнот із параметрами.
DataPlate – Ця послуга допомагає нам використовувати SQL і легко об’єднувати кілька джерел даних. Він перетворює його на код Spark і оптимізує його, одночасно відстежуючи доступ до даних і допомагаючи зменшити витоки даних. Версія Xtra надала ще більше можливостей.
Amazon EMR – Ця служба запускає наші вилучення даних як робочі навантаження через Spark, зв’язуючись із усіма нашими ресурсами даних.

За допомогою життєвого циклу екземпляра ноутбука SageMaker ми можемо контролювати максимальний час виконання екземпляра блокнота, використовуючи autostop.py шаблон сценарій

Після тестування фреймворків машинного навчання ми обрали ядро SageMaker MXNet для етапів кластеризації та ранжування.

Щоб перевірити код ноутбука на наших виробничих даних, ми запустили блокнот, інкапсулювавши його через Docker в Amazon ECS, і запустили його як завдання обробки, щоб перевірити максимальний час роботи на різних типах машин.

Контейнер Docker також допомагає нам ділитися ресурсами між тестами ноутбуків. У деяких випадках блокнот викликає інші блокноти для використання мультипроцесу, розділяючи великі кадри даних на менші кадри даних, які можуть виконуватися одночасно на кожному vCPU у великій машині.

Рішення для визначення виробництва в реальному часі

На етапі дослідження ми використовували паркет Служба простого зберігання Amazon (Amazon S3), щоб зберегти наші рекомендації. Вони споживаються один раз на день із нашого інженерного конвеєра, щоб додати рекомендації до нашого механізму сповіщень.

Однак наша дорожня карта потребує рішення з вищою частотою оновлення, і в довгостроковій перспективі витягувати один раз на день недостатньо, оскільки ми хочемо надавати рекомендації навіть під час розслідування.

Щоб реалізувати це рішення в масштабі, ми протестували більшість кінцевих рішень SageMaker під час нашого дослідження виявлення аномалій. Ми протестували 500 готових моделей з однією кінцевою машиною різних типів і використовували одночасні багатопотокові клієнти для виконання запитів до кінцевої точки. Ми виміряли час відгуку, ЦП, пам’ять та інші показники (додаткову інформацію див Відстежуйте Amazon SageMaker за допомогою Amazon CloudWatch). Ми виявили, що мультимодельна кінцева точка ідеально підходить для наших випадків використання.

Кінцева точка з кількома моделями може значно зменшити наші витрати порівняно з однією кінцевою точкою або навіть Kubernetes для використання веб-сервісів Flask (або інших Python). Наше перше припущення полягало в тому, що ми повинні забезпечити одну кінцеву точку, використовуючи невелику машину з 4 vCPU, для кожного клієнта, і в середньому запитувати чотири спеціальні моделі, оскільки кожен vCPU обслуговує одну модель. Завдяки мультимодельній кінцевій точці ми могли об’єднати більше клієнтів на одній машині з кількома кінцевими точками.

У нас була модель і файли кодування для кожного клієнта, і після виконання навантажувальних тестів ми визначили, що можемо обслуговувати 50 клієнтів, кожен з яких використовує 10 моделей і навіть використовує найменший екземпляр ml.t2.medium для наших рішень.

На цьому етапі ми розглядали використання багатомодельні кінцеві точки. Кінцеві точки з кількома моделями забезпечують масштабоване та економічно ефективне рішення для розгортання великої кількості моделей, що дає змогу розміщувати декілька моделей в одному контейнері висновків. Це зменшує витрати на хостинг за рахунок покращення використання кінцевої точки порівняно з використанням кількох невеликих кінцевих точок однієї моделі, кожна з яких обслуговує одного клієнта. Це також зменшує накладні витрати на розгортання, оскільки SageMaker керує завантаженням моделей у пам’ять і масштабує їх на основі шаблонів трафіку до них.

Крім того, перевага кінцевої точки з кількома моделями полягає в тому, що якщо у вас є висока частота висновків від конкретних клієнтів, її структура зберігає в пам’яті останні обслуговувані моделі для кращої продуктивності.

Після того, як ми оцінили витрати за допомогою мультимодельних кінцевих точок порівняно зі стандартними кінцевими точками, ми з’ясували, що це потенційно може призвести до зниження витрат приблизно на 80%.

Результат

У цьому розділі ми розглядаємо кроки та результати процесу.

Ми використовуємо конфігурацію блокнота життєвого циклу, щоб увімкнути запуск блокнотів як завдань обробки, інкапсулюючи блокнот у контейнер Docker, щоб швидше перевірити код і використовувати механізм автоматичної зупинки:

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

Ми клонуємо sagemaker-run-notebook Проект GitHub і додайте в контейнер таке:

Наші вимоги до піпсів
Можливість запускати блокноти з блокнота, що дає нам багатопроцесорну поведінку, щоб використовувати всі ядра екземплярів ml.m5.12xlarge

Це дає нам змогу запускати робочі процеси, які складаються з багатьох блокнотів, що виконуються як завдання обробки в рядку коду, одночасно визначаючи тип екземпляра для запуску.

Оскільки ми можемо додавати параметри до блокнота, ми можемо масштабувати нашу обробку, запускаючи її одночасно в різні години, дні або місяці, щоб отримувати та обробляти дані.

Ми також можемо створювати завдання планування, які запускають блокноти (і навіть обмежувати час виконання).

Ми також можемо спостерігати за останніми запусками та їхніми деталями, як-от час обробки.

За допомогою паперової фабрики, яка використовується в контейнері, ми можемо переглядати вихід кожного циклу, що допомагає нам налагодити виробництво.

Огляд нашого блокнота представлений у формі стандартного блокнота, призначеного лише для читання.

Використання кількох процесорів допомагає нам масштабувати обробку кожного ноутбука та використовувати всі його ядра. Ми створили функції в інших блокнотах, які можуть виконувати важку обробку, наприклад такі:

Розбийте файли JSON
Знайдіть відповідні рядки в DataFrame, поки основний блокнот розбиває DataFrame #cpu-cores елементи
Одночасно виконувати кластеризацію за типом попередження

Потім ми додаємо ці функціональні блокноти в контейнер, який запускає блокнот як завдання обробки. Перегляньте наступний файл Docker (зверніть увагу на команди 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

результати

Під час етапу дослідження ми оцінили можливість запустити наші блокноти як є, щоб поекспериментувати й оцінити, як наш код працює з усіма нашими релевантними даними, а не лише з вибіркою даних. Ми виявили, що інкапсуляція наших ноутбуків за допомогою завдань обробки може бути чудовою для нас, тому що нам не потрібно переписувати код і ми можемо використовувати потужність екземплярів, оптимізованих для обчислень і пам’яті AWS, і легко стежити за станом процесу.

Під час оцінки логічного висновку ми оцінювали різні кінцеві рішення SageMaker. Ми виявили, що використання кінцевої точки з кількома моделями може допомогти нам обслуговувати приблизно 50 клієнтів, кожен з яких має декілька (приблизно 10) моделей в одному екземплярі, що відповідає нашим обмеженням щодо низької затримки, а отже, заощаджує до 80% витрат. .

Завдяки цій архітектурі рішення ми змогли знизити MTTR наших клієнтів, що є основним показником для вимірювання успіху за допомогою нашої платформи. Це скорочує загальний час від моменту відповіді на наше посилання на сповіщення, яке описує проблему у ваших системах, до завершення дослідження проблеми за допомогою нашої платформи. На етапі розслідування ми вимірюємо дії користувачів із нашим рішенням для ML та без нього. Це допомагає нам надавати рекомендації щодо найкращих дій для швидшого вирішення конкретної проблеми та точного визначення аномалій, щоб визначити справжню причину проблеми.

Висновок і подальші дії

У цій публікації ми поділилися тим, як Logz.io використовував SageMaker для покращення MTTD і MTTR.

Як наступний крок ми розглядаємо можливість розширення рішення за допомогою таких функцій:

Заохочуємо вас спробувати Зошити SageMaker. Більше прикладів див Приклади SageMaker GitHub repo.

Про авторів

Аміт Гросс очолює дослідницький відділ Logz.io, який відповідає за рішення штучного інтелекту для всіх продуктів Logz.io, від етапу дослідження до етапу інтеграції. До Logz.io Аміт керував дослідницькими групами Data Science і Security Research Group в Here inc. і Cellebrite Inc. Аміт має ступінь магістра з інформатики Тель-Авівського університету.

Янів Вакнін є спеціалістом з машинного навчання в Amazon Web Services. До AWS Янів обіймав керівні посади в стартапах зі штучним інтелектом і Enterprise, включаючи співзасновника та генерального директора Dipsee.ai. Янів працює з клієнтами AWS, щоб використовувати потужність машинного навчання для вирішення реальних завдань і отримання цінності. У вільний час Янів любить грати у футбол зі своїми хлопцями.

Ейтан Села є спеціалістом з машинного навчання архітектором рішень Amazon Web Services. Він працює з клієнтами AWS, щоб надати рекомендації та технічну допомогу, допомагаючи їм створювати та використовувати рішення машинного навчання на AWS. У вільний час Ейтан любить бігати підтюпцем і читати останні статті про машинне навчання.