案例：在AWS上透过SageMaker跟CodePipeline驾驭MLOps的参考架构(上)

在经历了几篇的MLOps基础概念之後，想在後面的文章带大家看看几个案例。透过案例来学习，会对专案在技术上的架构全貌更清楚。今天选的案例是这篇：Taming Machine Learning on AWS with MLOps: A Reference Architecture，文章内容谈论如何在AWS上透过SageMaker跟CodePipeline驾驭MLOps。包含专案的技术跟商业目标以及透过架构来示范有哪些主要服务，可以怎麽串接这些服务。

• 图片来源：Taming Machine Learning on AWS with MLOps: A Reference Architecture

如果单从架构图来看，可能会遇到的问题像是：不知道可以从哪里开始看、什麽样的架构是好的或不好的架构、以及还有没有哪些没有写在架构图上的东西。在看案例的时候，我会拆分几个面向：(1)专案是否具有产业特殊性(2)会需要哪些人一起完成(3)有哪些Pipeline(4)每一区块需要的服务(5)如何依照使用情境的顺序将各服务串接(6)各方面的可扩张性。本文章会谈论到的，主要包含(2)、(3)，下一篇则包含(4)、(5)。

人物介绍

简单提一下这些不同角色的名称和他们在专案里面做的事情。这个案例是属於各个产业都通用的，所以就没有领域专家在其中。

(1)资料工程师(data engineer)：公司里面协助资料科学家、商业分析师取得、清理专案的资料的角色，也会依照资料读取方的需求，协助整理资料的特徵，以便於更快速地进行到建模或者建立报表的阶段。

(2)资料科学家(data scientist)：每个公司对於资料科学家的职务范围都不大相同，有时候包含很广的职务范围，从拿资料、整理资料、训练模型等等都有。在这一个案例当中，我们简单的把职务内容缩减为：训练模型、在乎模型准度的角色。

(3)ML工程师(ml engineers)：与资料科学家有蛮大部分的重叠，将其定义为：训练模型、在乎模型准度的角色。

(4)软件工程师(software developers)：在这边的角色是协助资料科学家能够更友善的与pipeline以及docker互动。这个工作内容有时候也是让DevOps同事协助了。因此在ML专案中，大部分并不会特定再去雇用一个软件工程师。

(5)DevOps工程师(devops engineers)：负责照顾专案从建置到部署的生产管线建置。

Pipeline介绍

机器学习的专案，主要分为，收集资料、资料处理、建立模型、模型注册、模型部署。收到使用者回馈之後，再回到资料处理、建立模型的循环，产生新的版本的模型服务。从架构图来看，主要会看到三个Pipeline。

(1)Model training/retraining Pipeline：包含验证资料、资料前处理、训练以及验证模型。若通过验证则进行到注册模型的步骤。透过这个pipeline可以记录：数据的来源、训练资料集的位置以及实验中产生的数据以及模型输出。

(2)Model deployment Pipeline：模型的部署包含了如果得到发布模型的授权，就部署到服务端点(endpoint)上，以及模型监测。

(3)SageMaker Container Image CI/CD build Pipeline：这个Pipeline属於比较进阶的情境，资料科学家们需具备把自己的训练程序码包成在容器环境内可以执行的能力。由於SageMaker提供建立好的Docker Image让资料科学家可以客制化使用其各项功能，所以才会有这个Pipeline。方便提升实验的重现性。如果不是使用SageMaker的开发者，也依旧可以维护自己使用的平台、框架支援的docker环境，在不同平台上面重现实验。

除了这三个pipeline之外，还有一些执行细节，像是：
(a)模型注册：用於版本控制，纪录训练结果的模型注册。(b)资料集版本控制：使用Amazon S3 的版本控制实现的资料集版本控制。(c)流程追踪：ML 工作流程步骤使用Amazon SageMaker Lineage Tracking实现的可审计性、可见性和再现性。(d)角色管理：使用AWS Identity and Access Management (IAM) ，实施角色授权，确保只有经过授权才能访问。

结语

明天继续针对每一区块需要的服务和如何依照使用情境的顺序将各服务串接的部分介绍。