AWS自动化机器学习-十一、MLSDLC 的持续集成、部署和训练

作者: Apache CN
机器学习

如果你回顾一些关于机器学习的架构最佳实践内容，即在 AWS 上构建一个安全的企业机器学习平台白皮书，甚至是关于 MLOps 的 SageMaker 文档，你会注意到在自动化应用的各种挑战中，它们都需要有一个跨职能团队。

那么，为什么跨职能的敏捷团队对 AWS 上的自动化 ML 如此重要？ AWS 提供了许多与 ML 相关的技术，这些技术在功能上经常重叠，为他们的客户提供了选择和灵活性。此外，业界提供了许多经过试验和测试的流程指南，如 CI/CD，来自动化这一流程。然而，无论是 AWS 还是行业都无法影响一个公司的组织结构或应用开发文化。任何变化都需要在组织内部发生，并由组织来完成。

在 [第 10 章] B17649_10_ePub.xhtml##_idTextAnchor133) 、*机器学习软件开发生命周期(MLSDLC

在本章中，我们将重点关注 MLSDLC 流程的自动化，以了解我们在第 10 章【机器学习软件开发生命周期(MLSDLC)简介】中创建的各种工件如何映射到流程的每个阶段。

为此，我们将讨论以下主题:

  • 编纂持续集成阶段
  • 管理持续部署阶段
  • 管理持续训练

在本章结束时，您将完成一个自动化的端到端 MLSDLC 流程，该流程将 ACME 网站以及年龄计算器模型部署到生产环境中。这将为您提供必要的框架，以便在进行任何代码更改或添加任何新数据时，继续自动化该过程。

技术要求

对于本章，您将需要以下内容:

  • 网络浏览器。(为了获得最佳体验，建议您使用 Chrome 或 Firefox。)
  • 访问您在本书中一直使用的 AWS 帐户。
  • 访问您在本书中一直使用的 Cloud9 开发环境。
  • 参考 AWS 免费层的使用限制，以避免不必要的成本。
  • 本章的源代码示例在本书的 GitHub 资源库(https://GitHub . com/packt publishing/Automated-Machine-Learning-on-AWS/tree/main/chapter 11)中提供。

编纂持续集成阶段

在这一节，我们将从 [第 10 章] B17649_10_ePub.xhtml##_idTextAnchor133) ，*机器学习软件开发生命周期介绍(MLSDLC ![Figure 11.1 – The Platform Team's role within the MLSDLC process ]

图 11.1-平台团队在 MLSDLC 流程中的角色

正如您所见，由于平台团队位于跨职能团队的中间，他们负责将所有解决方案组件粘合在一起。一旦所有的部分都被粘合在一起，平台团队就负责根据业务用例验证这些组件是否能很好地协同工作。例如，平台团队将验证 web 应用用户可以将鲍鱼属性数据输入到 web UI 中，并将该数据作为推理请求数据发送到 ML 模型，其中 ML 模型向用户返回有效响应。

那么，平台团队如何将各个部分整合在一起呢？更重要的是，平台团队如何以连续和自动化的方式做到这一点？

回答这些问题的最佳方式是实际展示平台团队在构建他们的集成工件时所执行的典型任务。

构建集成工件

为了测试是否所有的部分都匹配在一起，平台团队在测试或质量保证 ( QA )环境中创建了一个生产解决方案的实体模型。然后对解决方案执行功能测试，也称为系统测试，以确保整个系统按照预期方式工作。此外，为了自动化这个过程，平台团队将解决方案编码为 CDK 构造。

为了作为平台团队来构建这个结构，我们将继续使用我们在 [第 10 章] B17649_10_ePub.xhtml##_idTextAnchor133) 、*机器学习软件开发生命周期介绍(MLSDLC

  1. 登录您在本书中一直使用的同一个 AWS 帐户，打开 AWS Cloud9 控制台(https://console . AWS . Amazon . com/cloud 9)。
  2. 在 Your environments 部分，点击 MLOps-IDE 开发环境的 Open IDE 按钮。
  3. 使用 Cloud9 工作区内的终端窗口，运行以下命令，将本书的 GitHub 存储库中预构建的堆栈结构复制到stack.py文件夹:
    $ cd ~/environment/acme-web-application
$ cp ~/environment/src/Chapter11/Files/cdk/test_application_stack.py acme_web_application/stacks/
  4. 使用左侧导航面板，双击test_application_stack.py文件开始查看。
  5. 现在,test_applciation_stack.py文件已经打开，我们可以查看由 stack 构造创建的最重要的 AWS 资源。除了加载必要的 CDK Python 库和实例化TestApplicationStack()类，我们必须声明的第一个变量是endpoint_name。这是我们将给予 SageMaker 托管端点的名称，它正在托管我们训练好的模型。
  6. 接下来，我们必须定义一个名为sagemaker_test_role的 IAM 角色。SageMaker 将使用这个角色来访问存储生产级模型的模型注册中心。
  7. 我们必须定义的下一个变量是模型本身。这里，我们必须使用 SageMaker CDK 模块的CfnModel()类实例化 SageMaker 模型。我们还必须定义一个AwsCustomResource()来对 SSM 服务进行 API 调用，并检索指向模型注册中心内已训练模型位置的参数。
  8. 既然我们已经定义了模型，我们需要分配托管模型所需的计算资源。这是通过使用CfnEndpointConfig()类实例化endpoint_config变量来完成的。由于这是为了测试环境，我们不需要提供可扩展的计算资源，我们只需要提供测试模型所需的最少的计算实例。这就是为什么我们为测试环境指定了一个ml.t2.large实例类型。
  9. 有了model和endpoint_config之后，我们可以使用CfnEndpoint()类实例化endpoint，从而完成测试环境的模型部署部分。
  10. The next component of the test environment is to create the back-service for the website's Contact form and the Age Calculator form. The Platform Team provides this backend functionality as a api variable as an HttpApi() gateway class. The team also distributes the static HTML components as part of a CloudFrontWebDistribution() class. 注意 由于 CloudFront 发行版仅用于测试各种工件集成，我们将发行版价格类别指定为PRICE_CLASS_100。这意味着静态网站内容将只分发到北美、南非和中东的 edges。通过不使用 CloudFront 的完整全球分发功能，我们可以将测试成本降至最低。要了解更多关于 CloudFront 分布类和边缘位置的信息，可以查看定价文档(【https://aws.amazon.com/cloudfront/pricing/】T2)。
  11. 一旦网站的内容被上传到 S3 并通过 CloudFront 分发，我们就可以为联系人表单和年龄计算器表单创建路径，它们将指向一个formHandler Lambda 获取网站 API 请求并基于requests路径处理它们。例如，如果formHandler Lambda 从/api/predict路径接收到一个 API POST请求，它会将请求有效负载发送到 SageMaker 托管的模型进行推断。然后，它将从托管模型中获取推理响应，并将其发送回网站。
  12. 最后，我们必须使用 CDK 的CfnOutput()模块创建两个输出。第一个输出称为self.cdn_output，包含cdn.domain_name作为它的值。这将允许我们捕获网站的网址。
  13. 第二个输出称为self.api_output，并提供api.url作为一个值，本质上是提供表单 API 的 URL。

我们将在下一节中使用这些输出来构建测试工件。

构建测试工件

为了测试应用，我们需要设身处地为应用用户着想，了解他们如何与 web 应用中提供的功能进行交互。由于我们的示例网站仅由一个 HTML 页面、一个联系表单和年龄计算器预测表单组成，为了测试系统的整体功能，我们必须确认这些组件做了它们应该做的事情。

按照以下步骤创建必要的测试:

  1. 使用 Cloud9 workspace 的终端窗口，运行以下命令，将预先构建的测试脚本复制到acme-web-application文件夹:
    $ cd ~/environment/acme-web-application
$ rm –rf tests
$ cp -R ~/environment/src/Chapter11/Files/tests .
  2. 使用 Cloud9 环境的左侧导航面板，展开tests文件夹，然后双击system_test.py文件来查看测试代码。

如果你看一下测试代码，你会发现我们使用 Python requests库来模拟用户发出网站请求。第一个测试通过验证我们从 web 服务器获得了适当的状态代码，以及交付的内容是 HTML 代码，来关注网站本身。本质上，该测试模拟网站正在运行并且可以访问。

第二个测试关注后端 RESTful API。在这个测试中，我们将样本鲍鱼属性数据发送到后端 API，后者又将数据发送到托管生产模型进行推断。然后，我们验证是否收到了相应的状态代码，以及预测鲍鱼年龄的 HTML 响应。本质上，这个测试模拟了年龄计算器的用户体验。 最后一个测试模拟对后端 API 的错误调用，以确保 API 以正确的错误消息做出响应。这种测试并不总是必要的，但是测试应用是否以正确的错误作出响应可以确保当错误发生时，它们可以被正确地调试，因为我们知道应用正在正确地报告任何错误。

既然我们已经为系统编写了一些基本的功能测试，我们就可以构建生产环境了。

构建生产工件

现在我们已经完成了必要的工作，我们有了一个公平的想法，即被测试的系统工件将在生产中工作。因此，要创建生产环境，我们必须复制我们在测试或 QA 环境中使用的应用结构。请遵循以下步骤:

  1. 使用 Cloud9 workspace 的终端窗口，运行以下命令从本书的 GitHub 存储库中复制预构建的生产工件:
    $ cd ~/environment/acme-web-application
$ cp ~/environment/src/Chapter11/Files/cdk/production_application_stack.py acme_web_application/stacks/
  2. 使用左侧导航面板，双击production_application_stack.py文件进行查看。

如果您比较生产应用结构和测试应用结构，您会注意到有一些额外的组件。首先，我们创建了一个新的 S3 存储桶来存储所有的生产应用日志。这个存储桶将存储网站访问的所有日志，以及记录来自生产模型的推理日志。您可能还记得 [第 10 章] B17649_10_ePub.xhtml##_idTextAnchor133)*【机器学习软件开发生命周期(MLSDLC

在定义endpoint_config时，您会看到，对于生产环境，我们通过使用ml.c5.large实例，使用大小合适的生产计算资源来托管模型。我们还指定了最少的2实例，这样我们就可以利用 SageMaker 托管模型的高可用性(多个 AWS 可用性区域)特性。此外，我们通过data_capture_config打开推理，将所有推理请求数据和所有响应推理响应记录到日志桶中。

我们添加到产品构造中的另一个新组件是createBaseline Lambda 函数。因为生产构造正在部署生产级 ML 模型，所以我们想要捕获其预期性能的统计分析。这样，通过引用捕获的推理响应，我们可以监控模型的质量漂移。为此，我们为 Lambda 函数定义了baseline_creator变量，然后作为CustomResource()触发 Lambda 执行。

最后，我们添加了scaling_target变量并提供了策略，该策略指定了端点如何扩展。对于我们的生产环境，当每个ml.c5.large实例在 15 分钟内每秒钟收到超过750个请求时，我们将开始伸缩。

在测试和生产构造中，我们已经用实例化了formHandler和createBaseline Lambda 函数。这两个变量都是指组成这些功能的代码工件。因此，在我们关闭测试和生产 CDK 构件之前，我们需要用预构建的 Lambda 构件更新源代码 respiratory，以确保在我们部署它们时这些构件不会失败。请按照以下步骤操作:

  1. 使用 Cloud9 workspace 的终端窗口，运行以下命令将formHandler和createBaseline Lambda 代码复制到克隆的存储库中:
    $ cd ~/environment/acme-web-application
$ cp -R ~/environment/src/Chapter11/Files/lambda/ .

至此，我们已经为管道的集成阶段创建了所有必要的工件。现在，我们必须通过将这些组件添加到 CDK 管道来创建用于持续集成的自动化组件。

自动化持续集成流程

在 [第十章] B17649_10_ePub.xhtml##_idTextAnchor133)*机器学习软件开发生命周期(MLSDLC 1. 在您的 Cloud9 终端窗口中，运行以下命令来更新acme_pipeline_stack.py构造:

    $ cd ~/environment/acme-web-application
    $ cp ~/environment/src/Chapter11/Files/cdk/acme_pipeline_stack.py acme_web_application/
  1. 在左侧导航面板中，双击acme_pipeline_stack.py文件进行查看。

如果您将新的acme_pipeline_stack.py文件与我们在 [第 10 章] B17649_10_ePub.xhtml##_idTextAnchor133) 、*机器学习软件开发生命周期介绍(MLSDLC

…
from .stacks.ml_workflow_stack import MLWorkflowStack

…

然后，我们实例化这个堆栈的一个名为MLWorklowStage()的类，作为 CDK 流水线阶段构造。我们还提供了将堆栈实例化为流水线阶段所需的各种参数，并定义了特定的堆栈输出(在这种情况下，是状态机的 ARN):

…
class MLWorkflowStage(cdk.Stage):
    def __init__(self, scope: cdk.Construct, id: str, *, group_name: str, threshold: float, data_bucket_name: str, feature_group_name: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        ml_workflow_stack = MLWorkflowStack(
            self,
            "MLWorkflowStack",
            group_name=group_name,
            threshold=threshold,
            data_bucket_name=data_bucket_name,
            feature_group_name=feature_group_name
        )
        self.sfn_arn = ml_workflow_stack.sfn_output

…

通过将所有 CDK 堆栈实例化为单独的阶段构造，我们实质上是将每个构造定义为管道体的连续部分。例如，如果你向下滚动到我们已经定义了PipelineStack()类的地方，你会看到MLWorkflow() stage 构造已经被ml_workflow_stage变量定义了。然后，使用 CDK 管道模块的add_stage() 方法将ml_workflow_stage变量添加到管道体中。

注意

有关Stage()构造以及如何将其纳入 CDK 管道的更多详细信息，请参考以下关于 CDK 管道的 AWS 博客:https://AWS . Amazon . com/blogs/developer/CDK-Pipelines-continuous-delivery-for-AWS-CDK-applications/。请记住，这个博客是基于 CDK 管道模块的预览版本。2021 年 7 月，AWS 发布 CDK 管线为一般可用 ( GA )。要查看预览版和 GA 版的区别，可以参考 API 文档([https://github . com/AWS/AWS-CDK/blob/master/packages/% 40 AWS-CDK/pipelines/ORIGINAL _ API . MD])。

此外，您将看到，当我们将ml_workflow_stage和test_stage变量添加到管道中时，我们还定义了一个post参数。通过使用此参数，我们可以定义额外的阶段操作或阶段步骤，这些操作或步骤将在部署阶段构造后执行。在ml_workflow_stage变量的情况下，我们实例化了CodeBuildStep()类模块的一个实例来运行一个名为invoke.py的 Python 文件。该脚本采用 Step Functions 状态机的 ARN(部署在ml_workflow_stage构造中)并开始执行工作流。或者，在test_stage的情况下，我们实例化ShellStep()类模块来运行system_test.py文件，该文件测试应用的功能。

注意

我们使用CodeBuildStep()代表ml_workflow_stage和ShellStep()代表test_stage的原因是，我们可以使用role_policy_statements参数来提供必要的 IAM 权限，以启动和监控步骤功能状态机的执行。

您将看到的最后一个变化是管道的self_mutation参数现在被设置为True。这意味着我们将使管道能够动态适应(自变异)任何代码变化。例如，如果您打开您所在地区的代码管道管理控制台(https://console.aws.amazon.com/codesuite/codepipeline/)并点击 ACME -WebApp-Pipeline ，您将看到管道的当前结构只有两个阶段: ![Figure 11.2 – Current structure of the CDK Pipeline ]

图 11.2-CDK 管道的当前结构

当我们将工件更新提交给源代码库时，这些变化已经触发了流水线执行。然而，由于self_mutation参数当前被设置为False，添加堆栈和阶段代码构造并没有修改流水线结构。

现在，平台团队必须完成 CDK 项目，以实现自变异。请遵循以下步骤:

  1. To finalize the CDK project, go to the Terminal windows in your Cloud9 workspace and run the following command to get the name of the SageMaker Feature Group:
    $ aws sagemaker list-feature-groups --name-contains abalone
    注意

_idTextAnchor133)*机器学习软件开发生命周期(MLSDLC

  1. 从输出中复制FeatureGroupName键的值。
  2. 使用 Cloud9 工作区的左侧导航面板，展开acme-web-application文件夹并双击app.py文件开始编辑它。
  3. 用您在步骤 1 中运行的命令的输出替换PLACEHOLDER变量赋值，如下面的代码片段所示:
    …
MODEL_GROUP = f"PackageGroup"
FEATURE_GROUP = "<Add the name of the SageMaker Feature Group>"
CODECOMMIT_REPOSITORY = "acme-web-application"
…
  4. 保存并关闭app.py文件。
  5. 在您的 Cloud9 终端窗口中使用以下命令，添加最终的管道工件——invoke.py文件——并将更改提交到存储库:
    $ cd ~/environment/acme-web-application/
$ cp ~/environment/src/Chapter11/Files/scripts/invoke.py scripts/
$ git add -A
$ git commit -m "Finalized CDK application"
$ git push
  6. 因为我们已经更新了 CDK 应用，所以运行以下命令来重新部署应用:
    $ cdk deploy

恭喜你！您刚刚编写了一个自动化的基于 ML 的应用。然而，我们仍然没有完成。下一步是监控自动化过程，以确认我们所创建的东西被部署到生产中，并且满足业务用例的功能需求。当我们管理编码解决方案的持续部署时，我们将在下一节中关注这项任务。

管理持续部署阶段

到目前为止，我们主要关注参与计划、设计和编写解决方案的人员。然而，您会回忆起 [第 10 章] B17649_10_ePub.xhtml##_idTextAnchor133) ，《机器学习软件开发生命周期(MLSDLC ![Figure 11.3 – The plan and design phases of the MLSDLC process ]

图 11.3–mls DLC 流程的计划和设计阶段

在这里，您可以看到我们已经完成了 MLSDLC 流程的计划和设计阶段。作为一个跨职能团队，我们已经审查了 ACME web 应用的业务目标和需求。使用 CDK，不同的团队已经将他们对应用设计的贡献整理成文。既然已经部署了设计，我们可以进入自动化 MLSDLC 流程的下一个阶段——构建阶段。

回顾构建阶段

要查看构建流程，请打开您当前 aws 区域的 code pipeline(https://console . AWS . Amazon . com/code suite/code pipeline/pipelines/)管理控制台；您将看到 ACME -WebApp-Pipeline 。打开管道后，您将立即看到管道已经自我变异，合并了我们定义的阶段。向下滚动管道将显示资产阶段，如下面的屏幕截图所示: ![Figure 11.4 – The Assets stage ]

图 11.4–资产阶段 资产阶段是 mls DLC 构建阶段的第一部分，在这里构建 ML 容器映像、各种 Lambda 函数和静态 HTML web 内容。正如您所看到的，我们不需要创建一个专门的构建阶段来创建这些资产；CDK 管道自动完成这项工作。然而，一旦创建了这些管道资产，构建过程就没有完成。

为了成功执行整个 MLSDLC 过程，构建阶段还需要一个生产级 ML 模型。因此，如下面的屏幕截图所示，进一步向下滚动以显示构建过程的第二部分——构建-MLWorkflow 阶段: ![Figure 11.5 – The Build-MLWorkflow stage ]

图 11.5–构建工作流阶段

如你所见，三个独立的动作组成了构建工作流阶段。这些是准备、展开和执行动作。 Prepare 动作创建一个 CloudFormation 变更集来检查堆栈正在部署的 AWS 资源，从而保证任何提议的更改不会影响现有的关键 AWS 资源。这实质上是对持续集成环境中的建议资源的内置完整性或集成测试，其中现有的堆栈会随着管道的变化而自动更新。因为这是第一次创建 ML 工作流，所以准备阶段继续到部署阶段，在这里使用 AWS CloudFormation 部署堆栈。

一旦创建了堆栈，就会运行invoke.py脚本。回想一下，invoke.py脚本创建了一个阶跃函数状态机的执行。这个状态机反过来训练一个生产级的 ML 模型。

注意

如果你点击内的invoke.py脚本，构建日志。

如果您打开步进功能控制台(https://console.aws.amazon.com/states/home)并点击以 MLWorkflow… 开头的状态机名称，您将看到执行列表。点击这个按钮可以显示工作流程的当前状态。工作流完成后，执行图应该如下所示: ![Figure 11.6 – State machine execution graph ]

图 11.6-状态机执行图

如您所见，这个是工作流第一次被执行。如果模型的性能低于阈值，它将作为模型包添加到 SageMaker 模型注册中心。下面的屏幕截图显示了注册表中模型版本指标的示例: ![Figure 11.7 – Model version metrics ]

图 11.7–模型版本度量

正如您所看到的，使用 SageMaker Studio UI，ML 团队可以跟踪由工作流产生的各种模型的血统。由于我们还启用了实验跟踪，ML 团队也可以在 SageMaker Studio UI 中对数据处理、模型训练和模型评估试验进行评估。以下屏幕截图显示了由工作流生成的训练实验示例: ![Figure 11.8 – Training experiment details ]

图 11.8-训练实验细节

注意

有关如何使用 SageMaker Studio 比较 SageMaker 实验和试用的更多信息，请参考以下 SageMaker 文档:https://docs . AWS . Amazon . com/sage maker/latest/DG/experiments-view-compare . html。

由于执行 ML 工作流是 Build-MLWorkflow 阶段的最后一个动作，我们已经完成了 MLSDLC 流程的构建阶段。在这个阶段，流水线自动移动到测试阶段。

回顾测试阶段

一旦建立了各种管道资产和生产级 ML 模型，我们必须进入测试阶段，如下图所示: ![Figure 11.9 – The test phase of the MLSDLC process ]

图 11.9–mls DLC 流程的测试阶段

在测试阶段，我们的管道将解决方案的伪生产版本部署到测试或 QA 环境中。如果我们在 CodePipeline 控制台中查看管道的这个阶段，您将会看到这个测试部署阶段也有三个阶段操作。下面的截图显示了测试部署阶段的一个例子: ![Figure 11.10 – The Test-Deployment stage ]

图 11.10–测试部署阶段

如您所见，执行这三个系统测试的system_test.py文件。

小费

一旦 System-Test stage 动作完成，您可以通过 CloudFormation 控制台(【https://console.aws.amazon.com/cloudformation/home】)删除Test-Deployment-TestApplicationStackcloud formation 栈。我们对这些资源没有任何进一步的要求，我们也不希望因为它们闲置而产生任何进一步的 AWS 使用成本。

您可能还记得上一节中的，这三个测试通过访问网站和向年龄计算器模型发送 ML 推断请求来模拟用户对解决方案的体验。通过点击系统测试动作的细节链接，您将看到运行系统测试的 CodeBuild 构建日志输出。

注意

如果系统测试脚本由于某种原因失败了，那么系统测试动作以及测试部署阶段将会失败。这些测试中的任何一个失败并不一定意味着 MLSDLC 过程会失败。自动化 MLSDLC 过程的全部要点，尤其是自动化系统测试，是为了验证一旦解决方案最终部署到生产中，我们可以对其功能充满信心。因此，如果测试失败，我们可以向支持团队提供调试反馈，他们可以反过来解决问题并重新执行管道。

既然管道的测试-部署阶段已经完成，我们有了一个经过测试的解决方案，我们就可以将该解决方案部署到生产环境中了。这就是 MLSDLC 的部署阶段。

审查部署和维护阶段

一旦在伪生产解决方案上运行了所有的系统测试，我们应该有信心为我们的用户准备好生产版本。如下图所示，我们已经准备好最终将解决方案部署到生产环境中。部署后，我们可以管理和维护它: ![Figure 11.11 – The deploy and maintain phases of the MLSDLC process ]

图 11.11–mls DLC 流程的部署和维护阶段

从 CDK 管道的角度来看，负责生产部署的阶段与测试部署阶段相同，该阶段也有准备和部署阶段动作，但没有系统测试阶段动作。下面的屏幕截图显示了在生产-部署阶段中仅执行这两个操作的示例: ![Figure 11.12 – The Production-Deployment stage ]

图 11.12-生产部署阶段

虽然 pipeline 的阶段可能相似，但是作为 CloudFormation 堆栈部署的解决方案有些不同。首先，生产堆栈部署了更适合生产环境的最佳 AWS 资源。例如，生产堆栈使用优化的 C5 计算资源来托管模型，并实现额外的灵活性，因为这些计算资源可以根据用户需求进行扩展和缩减。

此外，从production_application_stack.py文件开始，我们为CloudFrontDistribution()类启用了logging_config。这使得解决方案部署后的维护更加容易，因为我们将所有的 web 事务日志存储在 S3。这使运营团队能够了解堆栈中的情况，并使用这些信息进行故障排除和调试。

除此之外，您还记得，在production_application_stack.py文件中，我们还创建了createBaseline Lambda 函数，并使用CustomResource CDK 模块调用它。在下面取自 Lambda 函数的index.py文件的代码片段中，您可以看到这个函数运行一个 SageMaker 处理作业来执行测试数据的统计分析。它使用由 AWS 提供的sagemaker-model-monitor-analyze容器来实现这一点，以便为训练模型的预期性能设定基线:

...
image_map = {
    "us-east-1": "156813124566.dkr.ecr.us-east-1.amazonaws.com/sagemaker-model-monitor-analyzer",
...
        logger.info(f'Creating Basline Suggestion Job: {request["ProcessingJobName"]}')
        try:
            response = sm.create_processing_job(**request)
            return {
                "PhysicalResourceId": response["ProcessingJobArn"],
                "Data": {
                    "ProcessingJobName": request["ProcessingJobName"],
                    "BaselineResultsUri": f"s3://{logs_bucket}/baselining/results"
                }
            }
...

通过将此统计基线分析与从生产模型中捕获的推理响应数据相结合，运营团队可以检测模型是否偏离了其预期目的。

此外，通过促进数据捕获和基线数据，运营团队可以通过实现 sage maker Model Monitor(https://docs . AWS . Amazon . com/sage maker/latest/DG/Model-Monitor . html)来自动化漂移检测流程。Model Monitor 将使用这些数据源，按照预定义的时间表自动检测各种模型漂移。

注意

我们在本例中没有实现自动模型监控功能，因为模型监控模块提供了多种内置漂移检测功能。您可以查看文档以确定数据质量(https://docs . AWS . Amazon . com/sagemaker/latest/DG/model-monitor-data-quality . html)、模型质量(https://docs . AWS . Amazon . com/sagemaker/latest/DG/model-monitor-model-quality . html)、偏差漂移(https://docs . AWS . Amazon . com/sagemaker/latest/DG/clarify-model-monitor-html

一旦管道的生产-部署阶段完成，我们将会看到我们关闭了循环并完成了 MLSDLC 流程，如下图所示: ![Figure 11.13 – Completed MLSDLC process ]

图 11.13–完成的 MLSDLC 流程

让我们通过回顾我们的用户在使用 ACME web 应用和年龄计算器组件时可能经历的事情来看看我们已经构建了什么。

回顾应用用户体验

要查看生产应用，请打开 CloudFormation 控制台(https://console.aws.amazon.com/cloudformation/home)并单击生产-部署-ProdApplicationStack 旁边的单选按钮以打开堆栈。点击输出选项卡查看堆栈输出，如下图所示: ![Figure 11.14 – CloudFormation stack outputs ]

图 11.14–云形成堆栈输出

如你所见，我们有两个堆栈输出。 FormAPIURL 输出是用于处理年龄计算器推理请求的 API 网关地址，而 CloudFrontURL 输出指向网站的地址。点击 CloudFrontURL 的值查看网站。以下截图显示了 ACME Fishing Logistics 网站: ![Figure 11.15 – ACME Fishing Logistics website ]

图 11.15-ACME 渔业物流网站

现在，让我们试试年龄计算器组件，看看一个渔民如何能够看到他捕获的鲍鱼的预测年龄。下面的截图显示了当一个渔民点击试试我们的年龄计算器按钮时出现的年龄计算器表单: ![Figure 11.16 – Age Calculator form ]

图 11.16-年龄计算器表单

如您所见，计算鲍鱼年龄表格提供了鲍鱼的各种样本尺寸。输入这些样本尺寸，点击提交按钮，查看 ML 模型预测的结果。以下屏幕截图显示了来自已训练模型的示例响应: ![Figure 11.17 – Age Prediction ]

图 11.17–年龄预测

正如你所看到的，根据提供的样本尺寸，模型预测鲍鱼有 10 个 T2 环。根据鲍鱼数据集的 UCI 机器学习知识库(https://archive . ics . UCI . edu/ml/datasets/鲍鱼)，环数加上 1.5 的值给出了以年为单位的年龄。因此，渔民可以看到鲍鱼的年龄是 11.5 岁，从而决定是将捕获物扔回去还是保存起来。 **恭喜你！我们现在有一个工作的 web 应用和一个内置的 ML 模型供我们的 fisherman 客户使用。我们使用自动化的 MLSDLC 流程来实现这一业务目标。

然而，您会记得 MLSDLC 过程不同于典型的 SDLC 过程，因为我们不仅在业务案例或源代码改变时，而且在训练数据改变时，连续地自动化基于 ML 的应用的发布。请记住，ML 模型的好坏取决于它所训练的数据。那么，当我们有新数据时，我们如何持续自动执行 MLSDLC 流程？

下一节我们将通过探讨持续训练 ( CT )的概念来回答这个问题。

管理持续训练

在 [第 9 章] B17649_09_ePub.xhtml#_idTextAnchor123) 、使用 Amazon Managed Workflow for Apache Airflow 构建 ML 工作流中，我们了解了如何使用 air flow 创建以数据为中心的 ML 流程，并根据新的鲍鱼调查数据训练年龄计算器模型。在 第 10 章 、*机器学习软件开发生命周期(MLSDLC ![Figure 11.18 – Data Airflow DAG ]

图 11.18–数据流 DAG

如您所见，当新的鲍鱼调查数据被添加到 S3 桶时，气流 DAG 开始。然后对调查数据进行预处理，以设计相关的训练特征；这些特征随后被吸收到特征存储中。一旦新数据被接收到功能存储中，就会触发 MLSDLC 流程的发布变更，以自动化发布解决方案的新变更集的流程。本质上，这创造了一个持续的训练过程。

此外，在本章的开始，我们看到了平台团队如何通过扩展 CDK 管道来提供管理和执行 acme-data-workflow DAG 的必要 AWS 资源，从而将持续训练的概念融入 CI/CD 方法中。例如，如果您在代码管道控制台中打开 ACME-WebApp-Pipeline ，您将看到构建-数据-工作流阶段，如以下截图所示: ![Figure 11.19 – The Build-DataWorkflow stage ]

图 11.19–构建数据工作流阶段

正如您所看到的， Build-DataWorkflow 阶段有一个准备和一个部署阶段动作，从而准备并部署一个 CloudFormation 变更集。这一部署的结果是在 VPC 内的 MWAA 环境，加上 DAG，以及上传到 S3 的支持资产。由于这是 CDK 管道的最后阶段，我们最终创建了 CI/CD/CT 管道，将持续训练纳入 MLSDLC 流程。

然而，在我们看到完整的端到端 MLSDLC 过程之前，我们需要模拟添加新的鲍鱼调查数据。我们将在下一节中完成这项工作。

创建新的鲍鱼调查数据

在 [第 9 章]:

  1. 打开 SageMaker 管理控制台(https://console.aws.amazon.com/sagemaker/home，在左侧面板中，点击 SageMaker 域部分下的工作室链接。
  2. 一旦 SageMaker 域仪表盘打开，点击启动应用下拉菜单并从列表中选择工作室打开工作室 IDE。
  3. Within the left-hand file panel, expand the Notebooks folder within the Chapter11 folder of the cloned src folder. 注意

_idTextAnchor133)*机器学习软件开发生命周期介绍(MLSDLC

  1. 双击Simulating New Abalone Survey Data.ipynb文件打开笔记本。
  2. 从内核菜单中，点击重启内核并运行所有单元……选项。
  3. 一旦创建了笔记本，就可以关闭 SageMaker Studio UI。

现在，我们已经模拟了新的鲍鱼调查数据，并将数据集上传到 S3，我们可以在行动中回顾连续的训练过程。

回顾持续训练流程

当数据团队最初在continuous_training_pipeline.py文件中定义气流 DAG 时，他们使用S3PrefixSensor()提供者不断检查 S3 桶中的新数据。因此，现在我们已经模拟了新的鲍鱼调查数据，气流 DAG 应该开始运行。

但是，需要手动启用 DAG 才能开始运行。要查看运行中的持续训练流程并启用 DAG，请执行以下步骤:

  1. 打开 https://console.aws.amazon.com/mwaa/home MWAA 控制台，点击 acme-airflow-environment 的 Open Airflow UI 链接。
  2. 一旦 Airflow UI 打开，切换 acme-data-workflow DAG 旁边的暂停/取消暂停 DAG 按钮以启用它。DAG 应该会自动启动。
  3. 单击 DAG 链接查看运行。DAG 仪表盘打开后，点击图形视图按钮，如图图 11.18 所示。
  4. 您可以跟踪 DAG 的进度，并通过单击特定任务和单击日志按钮来查看每个任务的日志。
  5. 一旦运行了每个任务,完成的图表应该如下所示: ![Figure 11.20 – Completed data workflow graph ]

图 11.20-完整的数据工作流程图

作为 DAG 运行完成的结果，您可以重新打开代码管道控制台来查看 ACME-WebApp-Pipeline 重启。至此，您已经创建了一个 CI/CD/CT 管道，它通过在 AWS 上自动化 MLSDLC 过程来持续构建和部署基于 ML 的应用。

清理

为了避免不必要的 AWS 使用成本，您可以通过打开 CloudFormation 控制台，然后按照与创建栈相反的顺序删除各个栈，来删除由 CDK 管道创建的资源。例如，选择构建-数据工作流-数据工作流堆栈，然后点击删除按钮。删除该堆栈后，对生产-部署-ProdApplicationStack 执行相同的操作。

注意

根据要删除的堆栈，您可能需要手动清空特定堆栈的 S3 存储桶，然后才能删除该堆栈。

继续沿着 CloudFormation 堆栈列表往下做，直到删除了 acme-web-application 堆栈。本章到此结束。

总结

在本书的最后一章中，向您介绍了 MLSDLC 的概念，以及如何使用这种方法来创建基于 ML 的应用。在前两章中，我们已经关注了创建基于 ML 的应用所需的三个主要成功因素中的两个——人和过程。

通过关注跨职能团队和敏捷团队如何合作，我们了解了每个团队如何贡献其领域专业知识来解决 MLSDLC 的业务计划需求和解决方案设计需求。

这项工作的实际成果是一组编码的 CDK 堆栈结构，当平台团队将与粘合在一起时，创建了一个 CI/CD/CT 管道。这一 CI/CD/CT 管道发挥了作用，并且是实现 MLSDLC 方法自动化背后的机制。例如，管道的每个阶段对应于 MLSDLC 方法的一个特定阶段，我们看到了执行 CI/CD/CT 管道如何不可避免地自动化 MLSDLC 流程，不仅将应用部署到生产中，还建立了持续自动化的永久生命周期。

虽然这些章节没有特别关注成功的 MLSDLC 方法的技术方面，但 AWS 技术如何实现 MLSDLC 过程是显而易见的。

因此，在本章中，通过将这些技术结合起来，我们已经成功地展示了 AWS 上自动化 ML 的端到端示例。

恭喜你！你已经看完了这本书。现在，您应该有足够的代码引用来插入一些 ML 模型，并在 AWS 上自动化它们。

延伸阅读

以下是对 AWS 内容的一些参考，强调了跨职能团队作为 AWS 上成功的 ML 自动化的关键的重要性:

文章列表

更多推荐

更多
  • AWS自动化机器学习-十一、MLSDLC 的持续集成、部署和训练 技术要求，编纂持续集成阶段，管理持续部署阶段，管理持续训练，延伸，构建集成工件，构建测试工件，构建生产工件，自动化持续集成流程，回顾构建阶段，回顾测试阶段，审查部署和维护阶段，回顾应用用户体验，创建新的鲍鱼调查数据，回顾持续训练流程，清
    Apache CN

    机器学习

  • AWS自动化机器学习-六、使用 AWS 步骤函数自动化机器学习过程 技术要求，介绍 AWS 步骤功能，使用 Step 函数 Data Science SDK for CI/CD，建立 CI/CD 渠道资源，创建状态机，解决状态机的复杂性，更新开发环境，创建管道工件库，构建管道应用构件，部署 CI/CD
    Apache CN

    机器学习

  • AWS自动化机器学习-第三部分：优化以源代码为中心的自动化机器学习方法 本节将向您介绍整体 CI/CD 流程的局限性，以及如何将 ML 从业者的角色进一步整合到管道构建流程中。本节还将介绍这种角色集成如何简化自动化过程，并通过向您介绍 AWS Step 函数向您展示一种优化的方法。本节包括以下章节:
    Apache CN

    机器学习

  • AWS自动化机器学习-一、AWS 上的自动化机器学习入门 技术要求，洗钱流程概述，洗钱过程的复杂性，端到端 ML 流程示例，AWS 如何使 ML 开发和部署过程更容易自动化，介绍 ACME 渔业物流，ML 的情况，从数据中获得洞察力，建立正确的模型，训练模型，评估训练好的模型，探索可能的后续步
    Apache CN

    机器学习

  • AWS自动化机器学习-二、使用 SageMaker 自动驾驶器自动化机器学习模型开发 技术要求，介绍 AWS AI 和 ML 前景，SageMaker 自动驾驶器概述，利用 SageMaker 自动驾驶器克服自动化挑战，使用 SageMaker SDK 自动化 ML 实验，SageMaker Studio 入门，准备实验
    Apache CN

    机器学习

  • AWS自动化机器学习-四、机器学习的持续集成和持续交（CI/CD） 四、机器学习的持续集成和持续交CI/CD技术要求，介绍 CI/CD 方法，通过 CI/CD 实现 ML 自动化，在 AWS 上创建 CI/CD 管道，介绍 CI/CD 的 CI 部分，介绍 CI/CD 的 CD 部分，结束循环，采取以部
    Apache CN

    机器学习

  • AWS自动化机器学习-九、使用 Amazon Managed Workflows 为 Apache AirFlow 构建 ML 工作流 技术要求，开发以数据为中心的工作流程，创建合成鲍鱼调查数据，执行以数据为中心的工作流程，构建和单元测试数据 ETL 工件，构建气流 DAG，清理， 在前面的年龄计算器示例中，我们了解了如何通过 ML 从业者和开发人员团队之间的跨职能
    Apache CN

    机器学习

  • AWS自动化机器学习-七、使用 AWS 步骤函数构建 ML 工作流 技术要求，构建状态机工作流，执行集成测试，监控管道进度，设置服务权限，创建 ML 工作流程， 在本章中，我们将从第六章中的 [处继续，使用 AWS 步骤函数自动化机器学习过程。您将从那一章中回忆起，我们正在努力实现的主要目标是简化
    Apache CN

    机器学习

  • AWS自动化机器学习-八、使用 Apache Airflow 实现机器学习过程的自动化 技术要求，介绍阿帕奇气流，介绍亚马逊 MWAA，利用气流处理鲍鱼数据集，配置 MWAA 系统的先决条件，配置 MWAA 环境， 当建立一个 ML 模型时，有一个所有 ML 从业者都知道的基本原则；也就是说，最大似然模型只有在数据被训练时
    Apache CN

    机器学习

  • AWS自动化机器学习-五、自动化 ML 模型的持续部署 技术要求，部署 CI/CD 管道，构建 ML 模型工件，执行自动化 ML 模型部署，整理管道结构，创建 CDK 应用，部署管道应用，查看建模文件，审查申请文件，查看模型服务文件，查看容器构建文件，提交 ML 工件，清理， 在 [第 4
    Apache CN

    机器学习

    • Apache CN

    878
    文章数
    1066
    获赞数
    1024
    粉丝数
    机器学习

    近期文章

    更多
    文章目录

      热门标签

      更多

      推荐作者

      更多