人工智能和机器学习 应用现代化

基于容器技术构建灵活可扩展的机器学习云平台

摘要

深度学习是数据科学领域近年来的重大突破，而容器和Kubernetes技术无疑是当前软件工程领域的明星。当两者结合，深度学习能够快速的交付实现价值。业界已经有一些很好的尝试，比如KubeFlow，但是距离企业的需求尚有差距。本文主要介绍如何通过VMware的核心产品vRealize Automation和PKS，结合KubeFlow，实现企业级灵活高扩展的机器学习云平台。

 

背景：当数据科学遇到软件工程

 

机器学习和容器技术其实一直以来分属两个不同的技术领域。机器学习属于数据科学，关注点主要是算法。比如语音识别，就是构建算法模型，并基于大量数据进行训练，从而提升识别的准确率。

而容器技术是近年来软件工程领域的重要进展。软件工程研究的目标是：面对复杂多变的需求，如何构建健壮可靠的软件系统。比如，我们时常听到的一个笑话，就是程序员因为需求不停的变更，而殴打产品经理，讲的其实就是软件工程的问题。

看上去这是两个相关性几乎垂直的领域，需要的技能也差别很大。但是我们却听到一些数据科学家的抱怨。在Twitter上面，有人讲“在企业里面的机器学习，工程师用了三周的时间去开发一个模型，但是已经过去11个月了，却仍然没有上线部署。”

其实，这不是一个新的讨论。早在2015年，Google的一篇论文就告诉我们，机器学习中存在着大量的“技术债务”（如下图中蓝颜色部分所示），这些技术债务正是导致明明模型和算法已经就绪，但是却迟迟不能部署到生产，不能产生真正价值的原因。

图1：Hidden Technical Debt in Machine Learning Systems, 2015,  Scully, D., et al (Google inc.)

 

在刚刚结束的2019 欧洲KubeCon和CloudNativeCon上面，有人展示了下面一张图，印证了同样的观点 —— 模型的构建只是整个机器学习系统中的一个步骤。

图2：机器学习应用的开发和部署过程

 

应用写出来都是需要给用户使用的，所以，归根结底，所有应用最终都不可避免的遇到软件工程方面的挑战。

 

机器学习系统的可扩展性挑战

 

软件工程也是一个非常复杂的体系，包括可靠性、可扩展性、性能、安全等等。每一个话题都可以是很长的讨论。本文主要从IT基础设施的角度讨论如何通过容器技术构建一个灵活高可扩展的机器学习系统。

我们看一下机器学习在可扩展性方面遇到了什么样的挑战。

在图2中，我们看到企业级机器学习应用的步骤很多，但是其中最核心的就是：训练和推理。

 

训练

训练任务通常以批处理（Batch Processing）的方式进行，规模（Scale）主要取决于模型复杂度和用于训练的数据量的大小。在训练阶段，不同的任务可能需要不同规模的IT基础设施资源和相应的机器学习框架。对于CPU、GPU、内存的数量或者大小有着不同的要求。从原则上讲，一个经过正确调优的训练任务会用满所有的资源；而越多的资源，则意味着越短的处理时间和越快的反馈。

笔者在之前的文章《VMware云平台加速机器学习》中，建议使用虚拟机的方式交付包含GPU或者vGPU的虚拟机（如图3所示）。在资源不足的时候，用户需要通过创建新的虚拟机，并调整应用以可以使用到新增加的资源。另外，如果用户的机器学习框架需要变更，需要在每一台虚拟机中进行手动更新；或者销毁所有的虚拟机，然后重新申请包含所需要的机器学习框架的虚拟机。

图3：通过虚拟机交付机器学习基础设施

 

推理

推理模块通常情况下是集成到应用系统中，以在线处理（online）的方式提供服务。规模（Scale）主要取决于并发请求的数量。其架构如下图所示：

图4：常见的推理应用的架构

 

推理模块需要的计算资源，通常来说，比训练要少一些。但是依然取决于并发请求的数量。当大量的并发进入到推理模块的时候，推理模块需要自动的扩展；当并发数量下降的时候，需要收缩集群以释放资源。采用传统的方式，即使是使用虚拟机，也需要手工的操作，才能完成扩展。机器学习推理系统的可扩展性要求，相对于训练环节，要求更高。

 

业界已有解决方案及差距分析

 

KubeFlow

容器技术作为近年来最为火热的技术之一，已经有了很多的尝试。包括，Nvidia提供了各类机器学习框架的容器镜像registry，用户可以通过docker pull命令很容易的从互联网上面下载机器学习框架的docker image到本地。这当然是有益的，但docker只是解决了机器学习框架镜像的管理问题，依然需要很多的手工操作才能完成扩展。

而kubernetes才是从根本上解决可扩展性问题的方法。这里我想介绍一个开源项目：KubeFlow。KubeFlow是基于kubernetes的定制化扩展，以满足机器学习应用的需求。KubeFlow拥有kubernetes的几乎所有的特性。KubeFlow隐藏了很多的细节，使得机器学习工程师可以很方便的使用kubernetes去执行机器学习的任务。

KubeFlow的第一个版本0.1发布的日期是2018年4月份，当前的版本是0.5（发布于2019年4月）。尽管在2019 欧洲KubeCon和CloudNativeCon上面，KubeFlow工程师认为KubeFlow 0.5已经Production Ready，但是对于1.0的发布依然非常谨慎，其中提到了稳定性问题和多用户/多租户支持的问题。

在笔者的实际使用中，笔者也体会到，和很多的开源项目一样，初期的很多版本都是集中于功能，在稳定性和文档方面有很多的挑战，至少笔者第一次按照文档安装并没有成功，后来才发现文档遗漏了一些重要步骤。KubeFlow的版本迭代速度很快，新的功能不断推出，但是版本之间的兼容性未必经过很好的验证。

但是请不要误解，尽管存在一些问题，但KubeFlow依然是一个很好的项目。KubeFlow大大的简化了在kubernetes上面运行机器学习任务的复杂度。只不过笔者认为，如果要真正将KubeFlow用在生产环境，采用多集群的方式是必要的。

 

多集群KubeFlow

正如CNCF的调查中提到，多集群已经成为了业界共识，其主要的原因为三点：提升可用性、更好的隔离、个性化的管理流程。对于基于KubeFlow的机器学习系统来说，多集群尤为重要，我们稍稍展开做一点阐述：

  1. 正如前文提到KubeFlow当前版本的稳定性并不是很高。多集群的好处是：即使在KubeFlow的运行或者变更过程中遇到问题，影响面也不会很大。在2018年KubeCon和CloudNativeCon上面，来自英国Monzo银行的工程师就和大家介绍过，他们采用一个Kubernetes集群，在变更过程中遇到一个bug，导致整体宕机。
  2. Kubernetes当前对于资源的限制方式较为初级，而且缺乏对GPU资源的限制。为了方便使用者的理解，以及避免资源争用，最好是分开多个集群。这一点在训练环节尤为重要，因为某一个训练任务都很可能耗尽集群的所有资源。
  3. 训练和推理对于停机窗口的需求是不一样，如果是在线推理，推理集群是需要考虑到整体应用的可用性；而训练任务是批处理，所以只要任务结束，就可以进行停机运维。
  4. KubeFlow的版本需求可能不一样。之前我们提到KubeFlow的版本更新很快，有的用户需要用到新的版本中的新的功能，而有的用户在当前版本上面可能运行很稳定。不同的集群可以满足不同的版本需求。
  5. 机器学习任务对于GPU的需求是不一样的：大部分深度学习任务在训练阶段需要用到很多的GPU，但是也不是所有；推理阶段可能并不需要那么多的GPU，vGPU也许就可以满足，或者只使用CPU也可以。

多集群带来了很多的益处，但是也给运维人员带来了额外的负担。如何简化运维，采用自动化和自服务的方式管理多集群，成为了一个现实的挑战。

 

基于VMware PKS、vRealize Automation和KubeFlow的企业级可扩展机器学习平台

 

下面就介绍一下，使用VMware PKS和vRealize Automation，结合KubeFlow，来帮助用户实现企业级灵活高可扩展性的机器学习平台。

 

技术架构

VMware PKS是一个企业级的Kubernetes管理平台，其中包含的一个重要组件是BOSH。通过BOSH，管理员可以管理Kubernetes集群的整个生命周期，包括创建、变更和删除等。Kubernetes的node是运行在vSphere平台之上的虚拟机。

图5：系统整体架构示意图

 

如上图所示，右边是基于虚拟化的资源池，当然其中包括直通模式的GPU和虚拟化的vGPU。整个创建过程如图所示：

  1. 用户登录vRealize Automation的自服务门户，选择KubeFlow服务，选择相关的参数之后，提交请求。
  2. 蓝图自动调用PKS的API，PKS使用BOSH模块创建虚拟机，并自动化部署Kubernetes。
  3. 蓝图自动调用工作流脚本，为VM增加GPU，或者vGPU。当然，如果这个集群不需要GPU/vGPU，这一步可以跳过。
  4. 蓝图调用工作流脚本，安装KubeFlow。

 

针对于训练集群的生命周期管理方式，根据不同的场景，有以下建议做法：

  1. 使用者遵循“申请->使用->回收”这样的集群生命周期管理流程，在使用过程中，100%使用资源，用完即回收。
  2. 一个租户（小组或者个人）按照资金的投入情况，分配一个集群，多个任务可以在其中并发运行。用户使用kubernetes的namespace进行多训练任务隔离和调度。

 

针对于推理集群来说，集群的生命周期较长，可以根据应用类型的不同，提供基于vGPU和基于GPU直通模式的两类KubeFlow集群。集群的节点可以通过PKS/BOSH进行动态伸缩。

 

用户体验

我们可以看一下用户体验的具体截图。

用户进入自己的门户，看到KubeFlow集群的服务（下图第二个服务）。

图6：用户登录自服务门户，看到KubeFlow的服务

 

用户点击“请求”之后，进入到参数设置。用户可以选择不同的节点配置、节点数量和KubeFlow的版本。


图7：用户选择KubeFlow集群的参数

 

实现层面的技术点

上述平台的实现其实技术上并不复杂，基本上都可以使用RestAPI调用来完成，其中有两点需要特别提出：

  1. 针对于GPU/vGPU的调度。读者可以参考笔者之前的Blog文章《基于vRealize Automation实现机器学习云平台》，其中详细介绍了GPU Scheduler的设计。
  2. vRealize Automation在实现中只是使用其XaaS的蓝图，而不是常用的IaaS蓝图，XaaS蓝图通过vRealize Orchestrator调用PKS的RestAPI，实现kubernetes集群的创建与调整。

 

总结

 

软件工程领域近年来最重大的进展是容器和Kubernetes技术；而数据科学领域的明星无疑是机器学习在深度学习领域的突破。当两者相遇，无疑可以创造更大的价值。

还记得，2018年在Nvidia的GTC用户大会的主体演讲中，Nvidia的CEO老黄给大家展示了图像识别的推理应用，在面对大量的并发请求时，如何自动化的快速扩展。其实，这并不困难，借助于VMware和KubeFlow，你也能做到！

 

图8：2018年在Nvidia的GTC用户大会，CEO黄仁勋展示在线推理系统的自动化扩展

 

最后，我还是想啰嗦几句。技术是为了满足需求。在笔者看来，大部分的场景下，只是使用虚拟机就可以满足机器学习应用对于可扩展性的需求。您可以参看《基于vRealize Automation实现机器学习云平台》。但是如果您遇到本文所描述的需求，也请不要忘记，VMware和开源社区可以帮助到您。

 

 

相关文章