DevOps在MLOps当中的角色

我们在前面的写给MLOps人才培育苦手谈论到MLOps是一个需要大家通力合作的一项专案，除了该专案带来资讯和商业的影响力，在技术上也属於比较前缘、大部分的团队都还在摸索的阶段。今天想来谈一谈DevOps在MLOps当中的角色，ML团队可以怎麽样的更好跟DevOps团队沟通。

DevOps的职责

一个DevOps的养成如果要谈的话可能三天三夜都讲不完，如果以四个字来说：包山包海。如果以一句话来说，则是"精通部署、系统监测、开发以及产品环境维护、资源和数据管理、安全等方面的开发人员"。如果想学习更多的DevOps知识可以参照大卫和牛的文章。

Ankit Jain 提到一句话，我觉得可以用来区分DevOps和资料科学家的工作心法。 "把Pipeline视为一个产品，而不只是把模型视为一个产品。" 在资料科学家的养成当中，有非常多的时间跟心力在讨论，关於演算法怎麽选择、演算法细节怎麽实践、资料怎麽采样、资料怎麽载入、模型怎麽验证等等。这些谈话内容都是围绕在模型上面。但是以实际面来说，模型只占了非常小的一部分，甚至当模型上线之後，专案的花费除了当初训练的费用之外，还包含服务本身部署的机器上，模型训练所使用的时间、金钱等资源可能只占据了整个开发循环的10%左右。

而DevOps是怎麽看ML产品的？这可以从他们日常的工作当中窥见一二。今天不论是资料库、一个购物车网站、一个约会网站、或是具有ML功能的影音串流网站，这些服务在DevOps的眼中，就是大小不同、重量不同的积木们堆叠在一起。DevOps的工作就是确保这些积木们，都有足够的资源可以使这些服务可以运作良好。像是在使用者还没感受到不耐烦的时间内回覆使用者、乘载不同量级的使用者需求等等。也确保这些积木们彼此之间的通路是具有安全性的，只有被授权的人可以拜访某些服务，DevOps有一大部分的工作也是确保各个服务之间沟通合乎系统规范，有使用安全钥匙、并且定期更新这些钥匙。所以当DevOps在看ML产品的时候，他们其实不会很在乎模型的准度，反倒是很在乎，谁可以使用到这个服务、有多少人会来使用者个服务、在模型更新的时候是不是也会使用CI/CD更新、需不需要在团队里面做权限设定等等。

团队设置

倘若让ML团队自己架设与设置开发跟部属的环境，对於DevOps团队来说会是非常头痛的事情，安全性与合规性跟公司其他系统都不一致。一般常见的分工配置，如以下的图所示：

• 资料来源：DevOps team formation

(a. 图左)公司有一个中心的DevOps团队，负责支援各个开发团队的部署以及开发环境。通常在ML专案建立的初期，会需要有一个或两个人力，一周五天专职负责ML专案的DevOps相关设置。这跟过去一个DevOps可能一两天就用其他专案的模板，套用在其他软件专案的情况相较不同。举例来说，可以看一下kubeflow的部署yaml，感受一下假若全自架一个ML系统需要的资源以及权限有哪些。

(b. 图右)开发团队是跟公司的产品互相绑在一起的，也就是说每个产品都有自己的开发人员、ML团队、DevOps团队，在这样的状况下，可能各产品的设置都不太ㄧ样。公司可以讨论是否要建立一个资料、ML的中心平台，也就是图当中的另一种定义的核心团队(Core team)，让不同产品的ML团队可以上去使用，或是各产品之间独立开发。无论是否要设置一个统一的平台，建议不同产品之间的ML专案设置仍然可以互通有无，不必在公司里面重复制造轮子。

无论是这两种团队设置的哪一种，公司也必须要从人力资源的管理上去思考，在ML专案上的所有系统需求是否都是要自家开发团队维护。如果公司的DevOps资源真的不足够，发现自己管理各项服务的成本太高，也可以把专案的资源内容多使用各家云服务公司所提供的产品，减少许多公司内部的营运成本。这并不代表完全不需要DevOps了，还是会需要在网路安全、角色授权、安全钥设定、负载管理等地方需要DevOps团队的支援。

DevOps在MLOps可以协助的地方

DevOps的加入所带来的影响：可以让ML团队的程序码，必须要能够朝更自动化的方向去维护。也让整个开发流程更稳健。其中包含更好的系统负载(包含CI/CD、IaC、监控)，以及更好的安全性。

CI(持续整合)

CI与CD的基础，会是从版本控制、使用Git开始谈。ML专案当中，需要进版本控制的东西会有：(1)资料处理：资料处理前後的状态(2)训练模型：模型框架、超参数的设置、训练的时间以及使用的机器规格、模型版本(3)发布模型：发布的版本、时间、是谁授权、发布到哪些环境、是否有导流的参数配置(A/B test)。

建立基本的版本控制设定之後，也包含建立模型与部属模型的两个建构pipeline。一个专注在模型的建立、训练、注册模型。另一个则是专注在部属的行为，团队中谁会去检视训练结果、部署到哪一个环境。在这两个pipeline的设置，也都需要设置相对应的测试与验证，确保程序码以及相关资料的品质。

在持续整合的部分在一开始会有点零散，因为资料的来源可能不是单一来源、资料的格式可能来自结构与非结构的来源、不同阶段专案使用的特徵与演算法版本管理、需要储存的特徵值可能为使用者即时产生的，或是之後要一次存取的离线特徵等等。但是在经过几次的迭代之後，团队也能渐渐抓到合作、版本更迭的方式。

CD(持续部署)

在部署的部分目前都倾向让ML专案本身有一个後端server，与模型互动，而模型本身成为一个微服务，便於可扩展性。在部属的过程也须考虑当前版本是否跟其他版本进行A/B Test，确保与模型互通的客户旅程配置。

在持续部署上，DevOps也需设定不同环境，供ML团队，以及ML功能整合的产品团队一起测试。举例来说，电商平台上的推荐系统，确保电商平台在staging上能够与在staging上的推荐系统互动，且获得预期结果。

这些测试以及预热、负载测试都能够让产品能够无痛的上线。同时也包含上线之後的故障排除与回溯之前的部属版本。

IaC(架构即程序码)

在训练模型的过程当中，对资料来源的前处理、重新训练、使用机器以及评估模型这些设定，在过去可能都内嵌在程序码里面。现在则需要抽出来，让这些设定可以透过yaml档注入服务，让训练及部署的自动化程度更提高。也因为这个部分使得ML专案学习到其他软件专案的特性，让专案本身更容易范本化，长远来说也助於公司快速展开下一阶段的测试及市场扩张。

监控

日志的重要性，大概可以不必再重申。通常公司各个系统的日志，都会统一导流到一个集中的地方，像是Grafana、CloudWatch等，方便DevOps查找。同样的ML专案也需要注意的部分，也是要如何让日志输出到系统收集日志的收集点，方便统一导向公司的dashboard。

除此之外，也可以设置一些通知，例如说模型训练完成、测试完成，或者发现模型服务无法被正常呼叫、模型准确度突然骤降等等，都可以设置相对应的通知讯息到信箱、Slack、或其他公司内部使用的通讯软件。借助 MLOps 监控，团队可以花相对少的力气部署和管理数千个模型，这让过去ML团队只能管理少数模型的通点能够被解决。

安全性

上次在安全与合规性提到的那5点可以再复习一次，同样也是DevOps同事们流血流泪帮忙把关的!!!

资料科学家学习资源

在了解DevOps在专案当中的角色之後，资料科学家若想要学习跟部属相关的知识，也可以参考以下的MLOps Basics专案。

• 图片来源：MLOps Basics

最近在Github上看到这个MLOps Basics专案，发现是对资料科学家了解产品部署上面一个蛮完整的教学，其中包含config设定、转换模型格式，让模型可以更轻易地部署到容器、边缘设备等。也包含版本控制、容器的使用、Github action的使用(学习简单的CI)、与其他serverless服务互动以及如何看日志(log)。在学习的过程当中，也可以上网找相关资料、或者跟团队的DevOps请教其中一些跟产品部署相关比较陌生的概念。

常见服务

在这边简单列出几个谈论MLOps会使用到服务，之後可以再延伸讨论细节：
(1)版本控制：DVC
(2)资料处理：Airflow
(3)模型管理：MLflow
(4)ML平台：Kubeflow、SageMaker
(5)模型解释：SHAP
(6)模型服务：Seldon、KfServing、TFServing

有兴趣也可以到MLOps Resources看看其他相关资源。

结语

若要总结关於DevOps在MLOps的角色，那麽唯一的建议就是，尽早让资料科学家与DevOps一起讨论专案的规划。 不管是资料科学家或者DevOps都需要从自己的舒适圈迈出，彼此学习对方工作的思考模式以及沟通的语言、专有名词等。

资料科学家必须学习一个软件交付周期应该会走过的阶段、该注意的事情。而DevOps也需要学习ML专案和其他专案的相同以及相异处，ML专案在资源的配置上或是部署平台的维护也相较其他专案复杂，在一开始的时候也无法用其他软件专案的范本直接应用在ML专案。

不管你是来自团队的哪一方，开始花点时间去看看对方的工作内容，问问对方最近在烦恼的技术与非技术的问题等等，这都会对於团队的沟通、合作有很大的助益。

今天先谈到这边了，明天见。

Reference
本篇相关Reference都已放在文章中的连结。