Logz.io 如何使用 Amazon SageMaker 加速 ML 建议和异常检测解决方案

由柏拉图重新发布

关注： 0

登录是 AWS 合作伙伴网络 (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 最适合我们的用例，因为它同时支持训练和推理。此外，它是可定制的，因此我们可以根据我们喜欢的研究过程对其进行定制。

最初，我们从本地笔记本开始，测试各种库。我们在从生产中提取大量数据时遇到了问题。后来，我们陷入了建模阶段的一个阶段，在本地机器上花费了很多小时。

我们评估了很多方案，最终选择了如下架构：

铭牌 – 的开源版本铭牌通过使用我们的 Spark 帮助我们轻松地提取和加入我们的数据亚马逊电子病历使用简单的 SQL 集群，同时监控数据访问
SageMaker notebook 实例和处理作业 – 这帮助我们实现了运行时的可扩展性以及机器类型和 ML 框架的灵活性，同时通过 Git 连接协作我们的代码

研究阶段解决方案架构

下图说明了研究阶段的解决方案架构，由以下组件组成：

SageMaker 笔记本 – 数据科学家使用这些笔记本电脑进行他们的研究。
AWS Lambda函数 – AWS Lambda 是一种无服务器解决方案，可按需运行处理作业。该作业使用 Docker 容器，其中包含我们要在实验期间运行的笔记本，以及需要支持笔记本的所有常用文件（requirements.txt 以及单独笔记本中的多处理功能代码）。
亚马逊ECR – Amazon Elastic Container注册 (Amazon ECR) 存储我们的 Docker 容器。
SageMaker处理工作 – 我们可以运行这个数据处理作业在任何 ML 机器上，它都会使用参数运行我们的笔记本。
铭牌 – 该服务帮助我们使用 SQL 并轻松连接多个数据源。它将其转换为 Spark 代码并对其进行优化，同时监控数据访问并帮助减少数据泄露。 Xtra 版本提供了更多功能。
亚马逊电子病历 – 该服务将我们的数据提取作为工作负载运行在 Spark 上，联系我们所有的数据资源。

借助 SageMaker 笔记本实例生命周期，我们可以控制笔记本实例的最大运行时间，使用 autostop.py 模板脚本。

在测试 ML 框架后，我们选择了 SageMaker MXNet 内核用于我们的聚类和排名阶段。

为了在我们的生产数据上测试笔记本代码，我们通过 Amazon ECS 中的 Docker 封装笔记本来运行笔记本，并将其作为处理作业运行，以验证不同类型机器上的最大运行时间。

Docker 容器还帮助我们在笔记本的测试之间共享资源。在某些情况下，笔记本通过将大数据帧拆分为较小的数据帧来调用其他笔记本以利用多进程，这些数据帧可以在大型机器类型的每个 vCPU 上同时运行。

实时生产推理解决方案

在研究阶段，我们使用了Parquet 亚马逊简单存储服务 (Amazon S3) 文件来维护我们的建议。这些每天从我们的工程管道中消耗一次，以将建议附加到我们的警报机制中。

但是，我们的路线图需要更高刷新率的解决方案，从长远来看，每天拉一次是不够的，因为我们希望即使在调查期间也能提供建议。

为了大规模实施此解决方案，我们在异常检测研究中测试了大多数 SageMaker 端点解决方案。我们使用各种类型的单个端点机器测试了 500 个预构建模型，并使用并发多线程客户端向端点执行请求。我们测量了响应时间、CPU、内存和其他指标（有关更多信息，请参阅使用Amazon CloudWatch监控Amazon SageMaker). 我们发现多模型端点非常适合我们的用例。

与使用 Flask（或其他 Python）Web 服务的单个端点甚至 Kubernetes 相比，多模型端点可以显着降低我们的成本。我们的第一个假设是，我们必须使用 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 项目，并将以下内容添加到容器中：

我们的点子要求
从笔记本内部运行笔记本的能力，这使我们的多处理行为能够利用所有 ml.m5.12xlarge 实例内核

这使我们能够运行由许多笔记本组成的工作流，这些笔记本在一行代码中作为处理作业运行，同时定义要运行的实例类型。

因为我们可以向笔记本添加参数，所以我们可以通过在不同的时间、日期或月份同时运行来扩展我们的处理来提取和处理数据。

我们还可以创建运行笔记本的调度作业（甚至限制运行时间）。

我们还可以观察最后一次运行及其详细信息，例如处理时间。

通过容器中使用的 papermill，我们可以查看每次运行的输出，这有助于我们在生产中进行调试。

我们的笔记本输出审查采用标准只读笔记本的形式。

多处理利用有助于我们扩展每个笔记本处理并利用其所有核心。我们在其他笔记本中生成了可以进行繁重处理的函数，例如：

分解 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 存储库.

作者简介

阿米特·格罗斯 领导 Logz.io 的 Research 部门，负责 Logz.io 所有产品的 AI 解决方案，从研究阶段到集成阶段。在加入 Logz.io 之前，Amit 曾在 Here inc. 管理数据科学和安全研究小组。和 Cellebrite 公司Amit 拥有特拉维夫大学的计算机科学硕士学位。

亚尼夫·瓦克宁 是 Amazon Web Services 的机器学习专家。在加入 AWS 之前，Yaniv 在人工智能初创公司和企业担任领导职务，包括 Dipsee.ai 的联合创始人兼首席执行官。 Yaniv 与 AWS 客户合作，利用机器学习的力量来解决现实世界的任务并获得价值。在业余时间，Yaniv 喜欢和他的孩子们踢足球。