כיצד Logz.io מאיץ המלצות ML ופתרונות זיהוי אנומליות עם Amazon SageMaker

הועלה מחדש על ידי אפלטון

עוקב: 0

Logz.io הוא שותף טכנולוגי מתקדם של AWS Partner Network (APN) עם מיומנויות AWS ב-DevOps, אבטחה ונתונים ואנליטיקה. Logz.io מציעה פלטפורמת תצפית תוכנה כשירות (SaaS) המבוססת על פתרונות תוכנה בקוד פתוח הטובים מסוגו עבור ניתוחי יומנים, מדדים ומעקב. לקוחות שולחים כמות הולכת וגדלה של נתונים אל Logz.io ממקורות נתונים שונים כדי לנהל את התקינות והביצועים של היישומים והשירותים שלהם. זה יכול להיות מכריע עבור משתמשים חדשים שמחפשים לנווט בין לוחות המחוונים השונים שנבנו לאורך זמן, לעבד התראות התראות שונות ולחבר את הנקודות בעת פתרון בעיות ייצור.

זמן ממוצע לזיהוי (MTTD) וזמן ממוצע לפתרון (MTTR) הם מדדי מפתח עבור הלקוחות שלנו. הם מחושבים על ידי מדידת הזמן שבו משתמש בפלטפורמה שלנו מתחיל לחקור בעיה (כגון ירידה בשירות הייצור) עד לנקודה שבה הוא מפסיק לבצע פעולות בפלטפורמה הקשורות לחקירה הספציפית.

כדי לעזור ללקוחות להפחית את ה-MTTD וה-MTTR, Logz.io פונה ללמידת מכונה (ML) כדי לספק המלצות ללוחות מחוונים ושאילתות רלוונטיות ולבצע זיהוי חריגות באמצעות למידה עצמית. כתוצאה מכך, המשתמש הממוצע מצויד בחוויה המצטברת של כל החברה שלו, וממנף את החוכמה של רבים. מצאנו שהפתרון שלנו יכול להפחית את MTTR עד 20%.

ככל שה-MTTD פוחת, המשתמשים יכולים לזהות את הבעיה ולפתור אותה מהר יותר. שכבת הנתונים הסמנטית שלנו מכילה סמנטיקה להתחלה ולעצירת חקירה, ואת הפופולריות של כל פעולה שהמשתמש עושה ביחס להתראה ספציפית.

בפוסט זה, אנו משתפים כיצד Logz.io השתמש אמזון SageMaker כדי לצמצם את הזמן והמאמץ עבור הוכחת הרעיון (POC), ניסויים ממחקר להערכת ייצור, וכיצד הפחתנו את עלות ההסקת הייצור שלנו.

האתגר

עד ש-Logz.io השתמשה ב-SageMaker, הזמן בין מחקר לבדיקת POC וניסויים בייצור היה די ארוך. זה היה בגלל שהיינו צריכים ליצור משרות Spark כדי לאסוף, לנקות ולנרמל את הנתונים. DevOps דרש עבודה זו כדי לקרוא כל מקור נתונים. DevOps וכישורי הנדסת נתונים אינם חלק מצוות ה-ML שלנו, וזה גרם לתלות גבוהה בין הצוותים.

אתגר נוסף היה לספק שירות מסקנות ML למוצרים שלנו תוך השגת יחס עלות מול ביצועים אופטימלי. התרחיש האופטימלי שלנו הוא תמיכה בכמה שיותר מודלים עבור יחידת מחשוב, תוך מתן התאמה גבוהה מלקוחות עם דגמים רבים. הייתה לנו גמישות בזמן ההסקה שלנו, מכיוון שהחלון הראשוני שלנו של זרם הנתונים עבור שירות ההסקה הוא 5 דקות של יומנים.

שלב המחקר

מדעי הנתונים הוא תהליך איטרטיבי הדורש סביבת פיתוח אינטראקטיבית למחקר, המאמת את פלט הנתונים בכל איטרציה ועיבוד נתונים. לכן, אנו מעודדים את חוקרי ה-ML שלנו להשתמש במחברות.

כדי להאיץ את מחזור האיטרציה, רצינו לבדוק את הקוד של המחברות שלנו על נתוני ייצור אמיתיים, תוך כדי הפעלתו בקנה מידה. יתר על כן, רצינו למנוע את צוואר הבקבוק של DevOps והנדסת נתונים במהלך הבדיקה הראשונית בייצור, תוך יכולת לצפות בפלטים ולנסות להעריך את זמן הריצה של הקוד.

כדי ליישם זאת, רצינו לספק לצוות מדעי הנתונים שלנו שליטה מלאה ואחריות מקצה לקצה ממחקר ועד בדיקה ראשונית בייצור. היינו צריכים אותם כדי למשוך נתונים בקלות, תוך שמירה על ניהול גישה לנתונים ומעקב אחר גישה זו. הם גם היו צריכים לפרוס בקלות את מחברות ה-POC המותאמות אישית שלהם לייצור באופן מדרגי, תוך ניטור זמן הריצה והעלויות הצפויות.

שלב הערכה

במהלך שלב זה, הערכנו כמה פלטפורמות ML כדי לתמוך הן בדרישות ההדרכה והן בדרישות ההגשה. מצאנו ש- SageMaker הוא המתאים ביותר למקרי השימוש שלנו מכיוון שהוא תומך הן בהדרכה והן בהסקה. יתר על כן, הוא ניתן להתאמה אישית, כך שנוכל להתאים אותו לפי תהליך המחקר המועדף עלינו.

בתחילה, התחלנו ממחברות מקומיות, בדקנו ספריות שונות. נתקלנו בבעיות עם שליפת נתונים מסיביים מהייצור. מאוחר יותר, היינו תקועים בנקודה של שלב הדוגמנות שלקח שעות רבות במכונה מקומית.

הערכנו פתרונות רבים ולבסוף בחרנו בארכיטקטורה הבאה:

DataPlate – גרסת הקוד הפתוח של DataPlate עזר לנו למשוך ולהצטרף לנתונים שלנו בקלות על ידי שימוש ב-Spark שלנו אמזון EMR אשכולות עם SQL פשוט, תוך ניטור הגישה לנתונים
מופע מחברת SageMaker ועבודות עיבוד - זה עזר לנו עם המדרגיות של זמן הריצה והגמישות של סוגי מכונות ומסגרות ML, תוך שיתוף פעולה עם הקוד שלנו באמצעות חיבור Git

ארכיטקטורת פתרונות בשלב המחקר

התרשים הבא ממחיש את ארכיטקטורת הפתרון של שלב המחקר, ומורכב מהמרכיבים הבאים:

מחברות SageMaker - מדעני נתונים משתמשים באלה מחשבים ניידים לבצע את המחקר שלהם.
פונקצית AWS Lambda - AWS למבדה הוא פתרון ללא שרת המריץ עבודת עיבוד לפי דרישה. העבודה משתמשת בקונטיינר Docker עם המחברת שאנו רוצים להפעיל במהלך הניסוי שלנו, יחד עם כל הקבצים הנפוצים שלנו שצריכים לתמוך במחברת (requirements.txt וקוד פונקציות ריבוי העיבוד במחברת נפרדת).
אמזון ECR - מרשם מיכל אלסטי של אמזון (Amazon ECR) מאחסן את מיכל ה-Docker שלנו.
עבודת עיבוד SageMaker - אנחנו יכולים להפעיל את זה עבודת עיבוד נתונים על כל מכונת ML, והוא מריץ את המחברת שלנו עם פרמטרים.
DataPlate - שירות זה עוזר לנו להשתמש ב-SQL ולהצטרף בקלות למספר מקורות נתונים. הוא מתרגם אותו לקוד Spark ומייעל אותו, תוך ניטור גישה לנתונים ועוזר בצמצום הפרות נתונים. גרסת ה-Xtra סיפקה עוד יותר יכולות.
אמזון EMR - שירות זה מפעיל את מיצוי הנתונים שלנו כעומסי עבודה מעל Spark, תוך יצירת קשר עם כל משאבי הנתונים שלנו.

עם מחזור החיים של מופע המחברת של SageMaker, אנו יכולים לשלוט בזמן הריצה המרבי של מופעי המחברת, באמצעות autostop.py תבנית תַסרִיט.

לאחר בדיקת מסגרות ה-ML, בחרנו בליבת SageMaker MXNet לשלבי האשכול והדירוג שלנו.

כדי לבחון את קוד המחברת על נתוני הייצור שלנו, הרצנו את המחברת על ידי עטיפתו באמצעות Docker באמזון ECS והרצנו אותו כעבודת עיבוד כדי לאמת את זמן הריצה המקסימלי על סוגים שונים של מכונות.

הקונטיינר של Docker גם עוזר לנו לחלוק משאבים בין הבדיקות של מחברות. במקרים מסוימים, מחברת קורא למחברות אחרות להשתמש בתהליך ריבוי על ידי פיצול מסגרות נתונים גדולים למסגרות נתונים קטנות יותר, שיכולות לפעול בו-זמנית על כל vCPU בסוג מכונה גדול.

פתרון הסקת הייצור בזמן אמת

בשלב המחקר השתמשנו בפרקט שירות אחסון פשוט של אמזון (Amazon S3) קבצים כדי לשמור על ההמלצות שלנו. אלה נצרכים פעם ביום מהצינור ההנדסי שלנו כדי לצרף את ההמלצות למנגנון ההתראות שלנו.

עם זאת, מפת הדרכים שלנו דורשת פתרון של קצב רענון גבוה יותר ומשיכה פעם ביום אינה מספיקה בטווח הארוך, מכיוון שאנו רוצים לספק המלצות גם במהלך החקירה.

כדי ליישם את הפתרון הזה בקנה מידה, בדקנו את רוב פתרונות נקודות הקצה של SageMaker במחקר זיהוי אנומליות שלנו. בדקנו 500 מהדגמים המובנים מראש עם מכונת קצה בודדת מסוגים שונים והשתמשנו בלקוחות מרובי-הליכים במקביל כדי לבצע בקשות לנקודת הקצה. מדדנו את זמן התגובה, המעבד, הזיכרון ומדדים אחרים (למידע נוסף, ראה עקוב אחר אמזון SageMaker עם אמזון 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 -

אנחנו משבטים את מחברת-מרווה-מריץ פרויקט GitHub, והוסיפו את הדברים הבאים למיכל:

דרישות ה-pip שלנו
היכולת להפעיל מחברות מתוך מחברת, מה שמאפשר לנו התנהגות ריבוי עיבודים כדי לנצל את כל ליבות המופע ml.m5.12xlarge

זה מאפשר לנו להפעיל זרימות עבודה המורכבות ממחברות רבות הפועלות כעבודות עיבוד בשורת קוד, תוך הגדרת סוג המופע לרוץ עליו.

מכיוון שאנו יכולים להוסיף פרמטרים למחברת, אנו יכולים להתאים את העיבוד שלנו על ידי ריצה בו-זמנית בשעות, ימים או חודשים שונים כדי למשוך ולעבד נתונים.

אנחנו יכולים גם ליצור עבודות תזמון שמריצות מחברות (ואפילו להגביל את זמן הריצה).

אנו יכולים גם לצפות בריצות האחרונות ובפרטיהן, כגון זמן עיבוד.

עם טחנת הנייר המשמשת במיכל, אנו יכולים לראות את הפלט של כל הפעלה, מה שעוזר לנו לבצע ניפוי באגים בייצור.

סקירת הפלט של המחברת שלנו היא בצורת מחברת רגילה לקריאה בלבד.

ניצול ריבוי עיבודים עוזר לנו לשנות את קנה המידה בכל עיבוד של מחברת ולנצל את כל הליבות שלו. יצרנו פונקציות במחברות אחרות שיכולות לבצע עיבוד כבד, כגון:

פיצוץ JSONs
מצא שורות רלוונטיות ב-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 עמית ניהל הן קבוצות מחקר מדעי הנתונים והן אבטחה ב- Here inc. ו- Cellebrite inc. עמית בעל M.Sc במדעי המחשב מאוניברסיטת תל אביב.

יניב וקנין הוא מומחה ללמידת מכונות ב- Amazon Web Services. לפני AWS, יניב מילא תפקידי מנהיגות עם חברות הזנק AI ו- Enterprise כולל מייסד ומנכ"ל Dipsee.ai. יניב עובד עם לקוחות AWS לרתום את העוצמה של Machine Learning כדי לפתור משימות בעולם האמיתי ולגזור ערך. בזמנו הפנוי יניב נהנה לשחק כדורגל עם הבנים שלו.

איתן סלע הוא ארכיטקט פתרונות מומחה למידת מכונה עם שירותי האינטרנט של אמזון. הוא עובד עם לקוחות AWS כדי לספק הדרכה וסיוע טכני, ועוזר להם לבנות ולהפעיל פתרונות למידת מכונה ב-AWS. בזמנו הפנוי, איתן נהנה לרוץ ולקרוא את המאמרים האחרונים של למידת מכונה.