Logz.io เร่งความเร็วคำแนะนำ ML และโซลูชันการตรวจจับความผิดปกติด้วย Amazon SageMaker ได้อย่างไร

เผยแพร่ซ้ำโดยเพลโต

ผู้ติดตาม: 0

Logz.io เป็นพันธมิตรด้านเทคโนโลยีขั้นสูงของ AWS Partner Network (APN) กับ ความสามารถ AWS ใน DevOps ความปลอดภัย ข้อมูล & Analytics. 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 เหมาะสมที่สุดสำหรับกรณีการใช้งานของเรา เนื่องจากรองรับทั้งการฝึกอบรมและการอนุมาน นอกจากนี้ยังปรับแต่งได้ ดังนั้นเราจึงสามารถปรับแต่งตามกระบวนการวิจัยที่เราต้องการได้

เริ่มแรก เราเริ่มจากโน้ตบุ๊กในเครื่อง ทดสอบไลบรารีต่างๆ เราพบปัญหาในการดึงข้อมูลจำนวนมากจากการผลิต ต่อมา เราติดอยู่ในขั้นตอนการสร้างแบบจำลองซึ่งใช้เวลาหลายชั่วโมงในเครื่องท้องถิ่น

เราประเมินโซลูชันมากมาย และสุดท้ายเลือกสถาปัตยกรรมต่อไปนี้:

แผ่นข้อมูล – เวอร์ชันโอเพ่นซอร์สของ แผ่นข้อมูล ช่วยให้เราดึงและเข้าร่วมข้อมูลของเราได้อย่างง่ายดายโดยใช้ Spark . ของเรา อเมซอน EMR คลัสเตอร์ด้วย SQL อย่างง่าย ในขณะที่ตรวจสอบการเข้าถึงข้อมูล
อินสแตนซ์โน้ตบุ๊ก SageMaker และงานการประมวลผล – สิ่งนี้ช่วยให้เรามีความสามารถในการปรับขนาดของรันไทม์และความยืดหยุ่นของประเภทเครื่องและเฟรมเวิร์ก ML ในขณะที่ทำงานร่วมกันโค้ดของเราผ่านการเชื่อมต่อ Git

สถาปัตยกรรมโซลูชันขั้นตอนการวิจัย

ไดอะแกรมต่อไปนี้แสดงสถาปัตยกรรมโซลูชันของขั้นตอนการวิจัย และประกอบด้วยส่วนประกอบต่อไปนี้:

โน้ตบุ๊ค SageMaker – นักวิทยาศาสตร์ข้อมูลใช้สิ่งเหล่านี้ โน๊ตบุ๊ค เพื่อทำการวิจัย
ฟังก์ชัน AWS Lambda - AWS แลมบ์ดา เป็นโซลูชันแบบไร้เซิร์ฟเวอร์ที่รันงานการประมวลผลตามต้องการ งานนี้ใช้คอนเทนเนอร์ Docker กับโน้ตบุ๊กที่เราต้องการเรียกใช้ระหว่างการทดลอง ร่วมกับไฟล์ทั่วไปทั้งหมดของเราที่ต้องรองรับโน้ตบุ๊ก (requirements.txt และโค้ดฟังก์ชันการประมวลผลหลายตัวในโน้ตบุ๊กแยกต่างหาก)
อเมซอน ECR - การลงทะเบียน Amazon Elastic Container (Amazon ECR) จัดเก็บคอนเทนเนอร์ Docker ของเรา
งานประมวลผล SageMaker – เราสามารถเรียกใช้สิ่งนี้ได้ งานประมวลผลข้อมูล บนเครื่อง ML ใดๆ และรันโน้ตบุ๊กของเราพร้อมพารามิเตอร์
แผ่นข้อมูล – บริการนี้ช่วยให้เราใช้ SQL และเข้าร่วมแหล่งข้อมูลต่างๆ ได้อย่างง่ายดาย มันแปลเป็นรหัส Spark และปรับให้เหมาะสม ในขณะที่ตรวจสอบการเข้าถึงข้อมูลและช่วยลดการละเมิดข้อมูล รุ่น Xtra ให้ความสามารถมากยิ่งขึ้น
อเมซอน EMR – บริการนี้เรียกใช้การดึงข้อมูลของเราเป็นปริมาณงานบน Spark โดยติดต่อแหล่งข้อมูลทั้งหมดของเรา

ด้วยวงจรชีวิตอินสแตนซ์โน้ตบุ๊ก SageMaker เราสามารถควบคุมรันไทม์สูงสุดของอินสแตนซ์โน้ตบุ๊กได้โดยใช้ autostop.py เทมเพลต ต้นฉบับ

หลังจากทดสอบเฟรมเวิร์ก ML แล้ว เราเลือกเคอร์เนล SageMaker MXNet สำหรับขั้นตอนการจัดกลุ่มและการจัดอันดับของเรา

ในการทดสอบโค้ดโน้ตบุ๊กบนข้อมูลการผลิตของเรา เรารันโน้ตบุ๊กด้วยการห่อหุ้มผ่าน Docker ใน Amazon ECS และรันเป็นงานประมวลผลเพื่อตรวจสอบรันไทม์สูงสุดบนเครื่องประเภทต่างๆ

คอนเทนเนอร์ Docker ยังช่วยให้เราแบ่งปันทรัพยากรระหว่างการทดสอบของโน้ตบุ๊ก ในบางกรณี โน้ตบุ๊กเรียกโน้ตบุ๊กอื่น ๆ เพื่อใช้หลายกระบวนการโดยแยกเฟรมข้อมูลขนาดใหญ่ออกเป็นเฟรมข้อมูลขนาดเล็กลง ซึ่งสามารถทำงานพร้อมกันบน vCPU แต่ละตัวในประเภทเครื่องขนาดใหญ่ได้

โซลูชันการอนุมานการผลิตแบบเรียลไทม์

ในขั้นตอนการวิจัย เราใช้ไม้ปาร์เก้ บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (Amazon S3) เพื่อรักษาคำแนะนำของเรา สิ่งเหล่านี้ถูกใช้วันละครั้งจากไปป์ไลน์ทางวิศวกรรมของเราเพื่อแนบคำแนะนำเข้ากับกลไกการแจ้งเตือนของเรา

อย่างไรก็ตาม แผนงานของเราต้องการโซลูชันอัตราการรีเฟรชที่สูงขึ้น และการดึงวันละครั้งไม่เพียงพอในระยะยาว เนื่องจากเราต้องการให้คำแนะนำแม้ในระหว่างการตรวจสอบ

เพื่อนำโซลูชันนี้ไปใช้ในวงกว้าง เราได้ทดสอบโซลูชันปลายทางของ SageMaker ส่วนใหญ่ในการวิจัยการตรวจจับสิ่งผิดปกติของเรา เราทดสอบโมเดลที่สร้างไว้ล่วงหน้า 500 รุ่นด้วยเครื่องปลายทางเครื่องเดียวในประเภทต่างๆ และใช้ไคลเอ็นต์แบบมัลติเธรดพร้อมกันเพื่อดำเนินการตามคำขอไปยังปลายทาง เราวัดเวลาตอบสนอง, CPU, หน่วยความจำ และตัววัดอื่นๆ (สำหรับข้อมูลเพิ่มเติม โปรดดูที่ ตรวจสอบ 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-รัน-โน๊ตบุ๊ค โครงการ 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 ซึ่งรับผิดชอบโซลูชัน AI ของผลิตภัณฑ์ Logz.io ทั้งหมด ตั้งแต่ขั้นตอนการวิจัยไปจนถึงขั้นตอนการผสานรวม ก่อนที่จะมี Logz.io Amit ได้จัดการทั้ง Data Science และ Security Research Groups ที่ Here inc. และเซลเลอไบร์ทอิงค์ Amit สำเร็จการศึกษาระดับปริญญาโทด้านวิทยาการคอมพิวเตอร์จากมหาวิทยาลัยเทลอาวีฟ

ยานีฟ วัคนิน เป็นผู้เชี่ยวชาญด้าน Machine Learning ที่ Amazon Web Services ก่อนหน้าร่วมงานกับ AWS Yaniv ดำรงตำแหน่งผู้นำกับสตาร์ทอัพ AI และ Enterprise รวมถึงผู้ร่วมก่อตั้งและ CEO ของ Dipsee.ai Yaniv ทำงานร่วมกับลูกค้าของ AWS เพื่อควบคุมพลังของ Machine Learning เพื่อแก้ปัญหาในโลกแห่งความเป็นจริงและรับมูลค่า ในเวลาว่าง Yaniv สนุกกับการเล่นฟุตบอลกับลูกๆ ของเขา

เอตัน เซล่า เป็นสถาปนิกโซลูชันผู้เชี่ยวชาญด้านการเรียนรู้ของเครื่องด้วย Amazon Web Services เขาทำงานร่วมกับลูกค้าของ AWS เพื่อให้คำแนะนำและความช่วยเหลือด้านเทคนิค ช่วยสร้างและใช้งานโซลูชันแมชชีนเลิร์นนิงบน AWS ในเวลาว่าง Eitan สนุกกับการวิ่งจ็อกกิ้งและอ่านบทความแมชชีนเลิร์นนิงล่าสุด