当AIOps遇上MLOps：大规模部署ML模型需要什么

概述AIOps

AIOps，即人工智能运维，是利用人工智能、机器学习和高级分析技术来强化和自动化IT运维与基础设施管理的各个环节。它涵盖了对计算、数据存储和网络带宽等需求趋势的预测，负载的编排与优化，以及异常检测与根本原因的精准定位，旨在提升运维效率，同时避免对开发团队产生过多的低价值信号干扰。

从DevOps到MLOps：当前的编排器有何不足？

在本节将阐述从DevOps向MLOps的演变，并探讨当前编排器存在的不足。

我们从DevOps说起，它是一套将软件开发和IT运营相结合的实践方法，其目的是缩短系统的开发周期，并持续提供高质量的软件。我相信大家都很熟悉这个流程图，它包括规划、编码、构建、测试、发布、部署、运营及监控。

以Azure平台为例，开发者可利用Visual Studio等工具编码，并将代码提交至GitHub等平台。通过GitHub Actions构建和测试代码后，可将其转化为容器，推送至容器注册表或部署到如Kubernetes等编排器上（Kubernetes仅为示例，非唯一选择）。此外，也可选择其他平台或服务如App Service进行部署。随后，利用Azure Monitor、App Insights等工具进行监控。类似的服务和工具在各大云服务提供商中均可见，为开发者提供全方位支持。

MLOps是一套结合机器学习和开发运营的实践方法与工具，旨在简化生产环境中机器学习模型的部署、扩展、监控和管理流程。这个流程始于数据管理，因为机器学习高度依赖数据，需要识别数据中的模式。数据管理、处理、为训练准备数据，以及实时数据流式传输以供推理和服务，都是MLOps的关键环节。

此外，特征工程在MLOps中也占有重要地位，它涉及数据转换以创造新特征，对模型的未来表现有决定性影响。模型构建（即ML训练）则是选择、调整和比较模型的过程，以决定最终使用的模型，评估环节必不可少，用以确保模型性能。

一旦模型选定，就进入部署、服务、监控和生产阶段，以及后续的优化和微调。这个过程是循环的，因为模型在生产中的表现将指导未来的数据收集方向。我们需要不断更新数据收集，重新审视特征工程，并重新训练模型。简而言之，MLOps是一个多步骤的循环工作流程。

DevOps主要支持特定应用的部署，通常涉及应用的容器化及在特定集群中的部署。相比之下，MLOps则覆盖了一个更为宽泛且复杂的端到端工作流程，这个流程包括多个环节和依赖项，如数据管理、模型训练、特征工程以及模型服务等。这些环节对基础设施和配置的需求各不相同，因此在某种程度上，MLOps的复杂性超过了DevOps。

尽管MLOps可以利用DevOps来处理单个机器学习任务，如模型训练或服务部署，但DevOps仅仅是MLOps整个工作流程中的一个辅助部分。一个典型的MLOps工作流可能包括从数据仓库中提取数据、进行特征工程、使用并比较不同的模型、以及实时评估模型性能等步骤。这种复杂的工作流程和逻辑无法仅依靠DevOps来实现，因此我们需要MLOps来支持这种复杂的工作流程和逻辑。

当前的编排工具存在哪些不足？

以下是对一些在DevOps和MLOps中受欢迎的编排工具的探讨。经过对这些工具的比较分析，我发现它们在确保整个工作流程顺畅进行方面都存在某些不足。

Kubernetes，作为DevOps中最受欢迎的编排工具，虽在协调IT应用和增量集群上表现出色，能够轻松应对从扩展到故障管理，再到代码更新等一系列问题，但它仍有所局限。特别是，它主要处理的是单集群部署，如CPU集群或GPU集群。此外，Kubernetes并不总是支持自动扩展，而且它可能无法在应用层面检测到故障的根本原因。

在MLOps编排工具方面，Airflow虽然实现了配置即代码的理念，但它采用的是单体部署方式，这意味着整个工作流程都被部署在一个应用或容器中，这可能并不是最优的选择，因为每个步骤可能有不同的基础设施需求。此外，Airflow在处理复杂和定制化的工作流程时存在局限，例如，它不支持“如果-那么”的逻辑或基于数据行数来选择模型的工作流程。

新一代的MLOps编排工具，如Prefect和Argo，虽然在定制和支持更动态、更参数化的工作流程方面有所改进，但它们在配置方面仍然存在混乱。用户需要自己编写YAML文件和Dockerfile，而且基础设施配置主要依赖手动。此外，这些工具的测试能力有限，因为它们主要在生产环境中运行。

Kubeflow和Metaflow等新一代MLOps编排工具通过允许开发者在生产和开发环境中从笔记本运行工作流程解决了测试能力有限的问题，但它们仍然需要用户为每个流程部分创建不同的YAML文件和Dockerfile，并进行手动基础设施配置。

总的来说，尽管这些编排工具为开发者社区带来了显著的进步并适应了机器学习的需求，但它们在确保工作流程顺畅进行方面仍存在不足，这可能需要通过引入更高级别的抽象，如AIOps，来加以改进。

AIOps在MLOps中的相关用例

接下来我们将详细阐述AIOps的定义，深入探讨这一额外层级的功能和所实现的抽象，并剖析其中所涉及的AI技术或分析技术。

在ML管道中，包含数据提取、转换加载、特征工程、ML训练和ML服务等多个组件。这些组件需要底层资源的支持，这些资源可能位于本地或云端，甚至可能是混合或多云的配置。资源形式多样，包括物理基础设施如AWS的EC2实例，平台资源如Kubernetes编排器，或是软件即服务资源如Vertex AI等。对于开发者而言，在部署机器学习模型时，需访问这些遍布各云提供商的资源。不同的云提供商可能各自擅长不同的任务，如某些适合ETL，而其他适合ML训练。因此，我们需要一个中间层来匹配ML管道的需求与最适合的资源，这既是为了性能优化，也是为了成本控制。

AIOps层正是这样一个中间层，它在需求和资源之间提供抽象与匹配服务。它的功能涵盖容量扩展、工作负载编排，以及异常检测和根本原因分析等。

接下来，我们将深入探讨各个用例及其可应用的AI技术。首先从容量扩展开始，其中一个关键用例是工作负载配置文件的预测。这指的是基于任务定义、历史需求模式或数据，预测特定ML工作流任务所需的容量。

在预测过程中，我们会考虑任务的服务级别协议（SLA）、数据量及其模式、ML模型选择、并发请求数量、延迟期望等因素。该预测引擎将告诉我们所需的计算能力和类型（如CPU或GPU）、核心数量、数据容量及其最佳存储方式（内存或磁盘、SQL或非SQL格式），以及网络输入-输出带宽的需求。

为实现这一预测，我们可以采用多种技术。如果我们有应用程序或任务之前的需求模式，时间序列预测将非常有用。此外，我们还可以利用先前部署和测试的ML任务的知识进行推理，类似于Netflix根据用户观看历史进行推荐。通过这种逻辑，我们可以推断出与过去任务相似的新任务所需的最佳资源和基础设施。这些就是在这种情况下我们可以使用的技术。例如，在数据转换中，我们会考虑数据量、原始和目标数据模式；在ML训练中，我们会考虑数据和模型选择；在ML服务中，我们会考虑并发请求和性能期望等因素。

以医疗训练数据的转换为具体案例，我们来探讨一下这个过程。初始数据状态、数据量以及目标数据模式都是我们需要考虑的因素。理想情况下，引擎会根据这些数据预测出所需的存储容量，单位可能是以太字节或拍字节。同时，引擎还会建议存储容量的类型，例如，我们可能想使用数据仓库来存储原始和转换后的数据。

在数据转换过程中，我们可能需要使用内存。此外，引擎还能预测ETL工作所需的资源，例如数据仓库单元的数量。更为智能的是，引擎还能预测数据仓库单元的利用率会如何随时间变化，这样我们就不必始终配置固定数量的单元。相反，我们可以根据实际需求灵活地扩大或缩小规模，甚至设置自动扩展操作，从而更有效地管理资源。

另一个任务的例子是以预测癌症发病率的机器学习训练为任务。首先，我们已完成了数据转换，并准备使用这些数据来训练模型。我们可以选择特定的模型，如XGBoost或基于树的模型，或者让预测引擎来推荐最适合的模型。此外，我们还可以设定训练频率，如每天、每周或其他任何时间间隔。在提供了训练数据的描述后，预测引擎会告诉我们所需的计算类型和资源。例如，它可能会建议我们使用NVIDIA H100 GPU，并给出所需的实例数量。由于训练是离线操作，引擎还会预测在不同时间段的资源使用情况，以优化资源配置。

完成模型训练后，我们需要将其部署到生产环境中，以提供癌症发病率预测服务。在这个阶段，预测引擎同样会给出所需的计算类型和位置建议。例如，它可能会推荐我们使用NVIDIA Triton设备，并考虑到延迟和其他QoS要求，以确保服务的实时性和可靠性。

第二个用例，在MLOps操作中，另一个可以大规模应用人工智能的场景是优化工作负载分配。我们已经掌握了端到端机器学习工作流中不同任务的工作负载配置文件，接下来的目标就是进行有效的编排。这里的编排不同于Kubernetes中的概念，它指的是将ETL、特征工程、机器学习模型训练和机器学习服务等不同类型的工作负载进行合理分配。这些工作负载具有不同的需求，并且在不同的时间段运行。

为了实现工作负载的优化分配，我们首先需要进行工作负载汇总。这意味着将具有相似容量需求和地理位置的工作负载进行合并。例如，如果多个工作负载都需要相同类型的CPU，并且可以在同一CPU集群上运行，那么我们就可以将它们多路复用，从而提高基础设施的使用效率。

接下来，我们需要将汇总后的工作负载分配到不同的集群中。这可以通过运筹学或约束优化等方法来实现，目标是在满足基础设施需求的同时，最大化服务的工作负载数量，并以高水平的SLA提供服务，同时控制成本。在这个过程中，我们可能会设定不同的目标，如实现所有的SLA或最大化SLA的实现，而约束条件则包括我们拥有的容量和成本。

最后，根据分配结果，我们可以决定哪个集群最适合运行特定类型的工作负载。例如，对于ETL任务，我们可能会选择巴西的AWS集群；而对于机器学习服务，则可能会选择西欧的Azure集群。这种离线计算为我们提供了一个高级的指导方向，以便在一切正常时做出最优决策。同时，我们也需要准备对突发情况做出实时反应，以确保系统的稳定性和可靠性。

第三个用例关注的是如何快速检测并响应工作负载分配中的故障。在预测了工作负载配置文件并决定如何分配工作负载后，我们需要一个有效的故障检测机制。目标是尽快发现故障，甚至在最终用户察觉之前，并找出问题的根本原因。

我们有几个核心目标：首先，减少值班疲劳，通过分组类似警报和最小化误报来实现；其次，缩短检测时间，以便在用户受影响前发现问题；最后，深入了解故障原因，防止问题扩散。

为实现这些目标，我们可以观察来自集群健康状况的一系列信号，包括基础设施指标、应用级或任务特定KPI等。例如，ETL过程的数据行数异常、特征工程中的特征数量大幅变化，或是机器学习训练中的模型精度变化，都可能是故障的信号。

一旦检测到这些异常，我们会使用异常检测方法和假设检验来确定行为是否异常，并计算出一个异常分数。同时，我们会结合人类知识，如硬编码规则或专家经验，来进一步验证警报的有效性。

接下来，我们会对警报进行聚类，找出它们之间的相似之处，以便归因于特定任务、用户设备、基础设施等。这种分组有助于简化我们的工作方式，并减少值班团队的疲劳。

最终，我们会生成一个聚合了多个警报的“超级警报”，并进行根源分析。通过基于树的模型等方法，我们可以找出最常见的故障原因，并提出解决假设。

整个过程中，我们运用了多种技术，包括假设检验、聚类分析、基于树的模型和专家网络等，旨在自动生成高信号、低噪声的警报，并进行根源分析。这展示了如何利用人工智能和机器学习来改进机器学习工作流的部署方式。

结论

正如上文所述，AIOps对于解决机器学习工作流的复杂性至关重要。随着机器学习工作流的日益复杂，其涉及的依赖、需求和基础设施要求也越来越多。AIOps作为一种额外的抽象层次，能够有效地应对这种复杂性，从而简化开发人员的工作。它能够抽象化复杂的决策和操作，涵盖容量扩展、工作负载编排以及性能监控等多个方面。

Sector Alarm的首席架构师和数据主管，吉达·易卜拉辛认为，当云提供商或新平台提供商正确实施AIOps时，它将为多云和混合服务提供新的可能性，进而推动机器学习和大型语言模型的更广泛应用。在过去的一年里，我们已经看到大型语言模型如何促进了应用程序部署的普及，只需通过创建智能提示即可轻松部署应用。同样地，她相信通过构建由AIOps支持的层级，可以进一步简化机器学习的部署，并抽象出其操作的所有复杂性。在这个层级中，可以利用各种技术，从推理到时间序列预测和优化，来推动机器学习的更广泛应用。

- end -

原创作者: u_15605878 转载于: https://blog.51cto.com/u_15605878/11877459