十多年ML系统SRE经验,Google练出4大ML可靠性战略

“不只是为了省钱,或只是减少丢脸时刻,避免影响顾客,更重要的价值是,SRE是确保ML创新速度的关键。”Google ML SRE团队负责人Todd Underwood在去年10月全球SRE年会演讲时,他特别强调,这才是Google早在13年前开始将SRE经验和知识运用到ML系统的关键理由。

Google在2003年首创了第一个SRE(Site Reliability Engineering,服务可靠性工程)团队,通过系统架构设计、运维流程改善等各种做法,来确保系统运行的更可靠。2014年,Google公开了这套SRE方法论和经验,后来也成了许多企业运维自家网站和线上服务可靠性的重要参考。

不只是用来确保网站和线上服务的可靠性,13年前,Google已经将SRE成功运用到搜索服务,存储系统、广告资料存储系统的可靠性运维上,当时开始思考,是不是能将SRE运用到ML系统上,决定先从匹兹堡办公室的Google Ads品质团队开始,运用到依赖大量机器学习算法的Google的广告推荐机制上。

因为Google关键字广告采点击计费,点击才会计价,靠ML模型来推荐的广告越符合搜索需求,就会能成功吸引浏览者来点击。

Todd Underwood指出,广告系统越稳定可靠,营收就能越稳定,因此决定开始从这套系统开始导入SRE做法,称为“ML SRE”。Todd Underwood就是13年前发起了Ads ML SRE团队的关键人物之一,

Todd Underwood表示,AI跟ML其实很不一样,AI是从人、应用需求角度来看,但ML则是要让计算机系统可以运用机器学习技术来解决问题,是一种利用资料来训练模型的做法,ML是AI的一个子集。

Todd Underwood也公开了Google内部所用ML系统概略架构,跟大多数企业常见的ML训练流程差异不大。这个ML系统架构包括了5个流程,从资料搜集、资料准备、模型训练、品质管控到提供推论服务,Google打造了一套模型管理工具和流程调度系统,用来关注模型、特征和资料的元数据。Google也特别重视资料读取、资料检查、特征资料的分布和变动等资料品质的管控。

Google SRE工程师Mary McGlohon正是过去4年来负责运维和开发这套超大规模ML系统的工程师之一。

Mary McGlohon指出,机器学习系统过于复杂和庞大,必需要打造工具来分析,才能探索问题,对ML SRE来说,就不用知道每一件事的业务逻辑,也可以做事。

因此,Google也自行发展了不少ML SRE工具,从更大的尺度来观察系统,找出各种可能出错的状态,并依据过去的错误设计更好的实例方式。

虽然,Google没有公开这些ML SRE工具,但Mary McGlohon归纳出四个Google用来提高ML可靠性的SRE战略,这正是他们过去十多年确保ML系统可靠性的关键秘诀。

这四个策略,包括了,第一,要让失效问题看得见,才能知道为何出错。其次,也需要尽可能验证各种异动,才能避免异动带来的错误,并且要厘清对资料完整性的要求,最后则是得妥善管理工作流程的等待任务。

Mary McGlohon指出,若误以为ML是魔术,这是一个偏见,对在乎系统稳定的工程师来说,今天的偷懒,可能会带来明天的技术债,先分析ML系统的特征,才能知道系统出错时会有哪些风险,让我们知道可以如何管理风险。

ML系统的特别之处,第一是大量资料的依赖性。因为机器学习算法非常强大,可以有效识别信号和噪声,这就导致不需要筛选或过滤资料,也能提升预测能力。

甚至,不需要知道哪些数据源更有价值直接全部导入,这会带来一个后果,累计越久,就会有越多资料依赖性(data dependencies)问题,这也是Google ML系统的一大特质。其次,ML系统其实是一套庞大交互作用的流程系统,必须知道如何安排这些流程,才能管理风险。

最后一点,ML是一种超大规模的非典型工作负载,不同的ML批次运算,会有不一样的运算和资料I/O需求,这对资源调度工作带来很大的挑战。

Google也曾从分析了过去15年ML系统上百起宕机事件的检讨报告后归纳,出19种ML系统宕机问题,Mary McGlohon指出,其中只有30%的问题,是来自ML系统内部的问题,像是标记错误,模型配置设置错误,但高达40%的问题是来自分布式系统的内部问题,例如负载均衡出错,数据结构没有优化,工作调度安排错误等。

“从这个结果告诉我们,ML系统的运维可以借鉴其他分布式系统的运维和最佳实务做法。”Mary McGlohon指出,Google的ML系统是一种分布式系统,资料密集,流程化的系统,我们挑选了分布式系统最佳实务,资料完整性最佳实务,和工作流程优化实务来缓解风险。

ML SRE关键策略1:让失效问题看得见

“要知道如何解决故障之前,得先知道何时会故障,看得见故障是一件重要的事。”Mary McGlohon表示。

Google内部有一套协调调度平台,可以用来设计模型开发流程,可以设置模型配置,并提供仪表板来检查模型性能,可以用来观察模型如何运行。

不过,Mary McGlohony则是建议,SRE团队最好可以创建一些模型品质预警通知,通知模型开发者以及系统运维人员,一旦模型品质开始下滑,可以在更多用户发现之前,让模型开发者可以展开行动,退回前一版,或赶快开始调查原因。

“仪表板是一种降低事故风险的好方法,发生事故时,要确保开发这个模型的核心人员也能观察到系统的信息,他们可以成为解决问题的帮手。”Mary McGlohon说。

ML SRE关键策略2:尽可能验证各种异动

但只靠预警机制还不够,更主动的SRE方法是进一步验证各种系统上线的变动,可以从二进制档和资料的变动来关注。

如何最有效关注系统的变动,Mary McGlohon建议,任何系统都会有带有业务逻辑的二进制文件,不管是,特征处理,模型训练,或推论服务等,都会用到二进制档,因此,可以验证这些二进制档来确保是否顺利运行,另一个可以关注变动的地方是系统配置档的变动。例如像是资料Schema配置,不同阶段的各种配置。

关注二进制档和配置档的变动,最好的做法就是创建一个上线前的Staging(准备)阶段和环境,在这个环境中,复制一份正式系统,进行测试,验证性能,来确保异动的影响符合预期,确定没有问题才正式上线。

在Staging阶段较容易发现可能导致宕机的错误,但不容易发现性能问题的影响,例如I/O用量,CPU用量,一条工作流程跟大量工作流程同时执行的影响不一样,后者可能导致很多等待的任务,而影响了系统运行。

Google还会关注另外一种变动,就是资料变动,可以从原始资料变动,特征资料更新的脧中,模型表征的变动,推论资料的产生等。 “侦测资料本身的异动,是一种防止事故的做法。”Mary McGlohon表示。

如何最有效关注系统的变动,Google建议,任何系统都会有带有业务逻辑的二进制文件,不管是,特征处理,模型训练,或推论服务等,都会用到二进制档,因此,可以验证这些二进制档来确保是否顺利运行,另一个可以关注变动的地方是系统配置档的变动。例如像是资料Schema配置,不同阶段的各种配置。Google还会关注另外一种变动,就是资料变动,从原始资料变动,特征资料更新的脧中,模型表征的变动,推论资料的产生等。图片来源/Google

ML SRE关键策略3:更清楚掌握对资料完整性的要求

另外,创建模型后,在正式上线之前,Google会先用测试资料来了解模型的性能,或是在准备好特征资料后,先筛选出异常资料,避免对模型训练产生影响。Mary McGlohon表示,对特征资料越熟悉,就越能这样事先过滤,而且不能单靠资料异常检查,还是需要搭配对配置档和二进制档异动检查,来确保ML环境准备正常,也才能避免坏资料产生问题。

如何分辨哪些资料是异常资料,就得对资料完整性的要求,清楚了解送入ML系统的资料是否符合训练所需,而且能准时送达。

尤其,很多外部问题会影响资料品质,例如标记出错,数据源在不同时来自不同地方,资料处理流程在第三方,甚至可能无法监控资料来发生了什么事。Google SRE会要求,组织内部资料负责窗口,有任何资料需求的调整,也得通知SRE。

另一个做法是简化ML,避免坏资料带来长期的影响,也可以创建系统回复机制。例如遇到资料错误,或不完整的资料,训练出了有问题的模型,若有回复机制,就可以回到一个安全不容易出错的模型快照版本

ML SRE关键策略4:妥善管理工作流程的等待任务

Google ML SRE最后一项关键策略是ML工作流程优化,因为经常有大量工作流程同时进行,重载会是常见问题,一旦流程宕机,或者资料晚到,就得有弹性来应对,因此,Mary McGlohon表示,需要创建流程退回机制,另外要有工作量优先级机制,才知道哪一项任务可以延后,最后要让调度机制更聪明,例如可以针对系统备援来进行资源调度,一旦遇到宕机时就可以采用。

Google ML SRE最后一项关键策略是ML工作流程优化,因为经常有大量工作流程同时进行,重载会是常见问题,一旦流程宕机,或者资料晚到,就倒有弹性来应对,因此,Google建议,需要创建流程退回机制,另外要有工作量优先级机制,才知道哪一项任务可以延后,最后要让调度机制更聪明,例如针对系统备援来进行资源调度,一旦遇到宕机时就可以采用。图片来源/Google

ML SRE和SRE有两大挑战不一样

Todd Underwood指出,ML SRE特别跟其他SRE做法,有两件事不一样。第一是,新模型和新团队需要很大的弹性,可能有各种技术考量,业务需求,或资料限制,必须调整模型。

因为需要可以定制化的模型架构,容易增加新功能,超快速部署,负责团队能快速修改问题直接执行模型来更新,也就是说,Todd Underwood表示,ML系统,希望能够尽快正式上线,这意味着,机器学习训练要高可用,容量分派自动化,调度自动化,SRE自动支持等。但是,要具备高度弹性,也代表了不容易标准化,这是第一个挑战。

第二个不一样之处是,ML SRE的另一个挑战是“模型品质”,Todd Underwood指出,尤其要思考该如何对模型品质负责。Google常见做法是由模型开发者来确保模型品质,但在ML模型上线之后,很多问题是来自系统性问题,而非模型的问题,只靠模型开发者解决不了问题。

“如何对模型品质负责,这是一个还没有答案的ML SRE大问题,这真的是一个非常难解的问题。”Todd Underwood强调。

为了解决这个模型品质问题,Google正在思考的做法是,创建升级检查清单,也就是可以检查一个ML模型是否能从实验状态,进入到正式上线状态的检查清单。这个挑战也就是要定义一个模型的服务水准目标(SLO),关键是“如何判断,一个模型可以正常运行。”Todd Underwood说。

目前,Google有几项定义“模型正常运行”的角度,例如资料是否不完整,过大,过小,或者会出现不同版本。训练速度太慢,或容易卡住。或是训练过程太消耗资源、模型品质突然改变(准确度下滑)、服务无法加载模型、模型加载服务后变慢等。

Todd Underwood说:“这些就是我们会设立指标的地方,来测量数据和性能,来判断什么样的模型品质够好,可以升级到正式环境。还会搭配其他指标如Model元数据是否完整,和其他模型的依赖性检查等。

下一步,Google ML SRE想要做到5件事,Todd Underwood分享,一方面说服组织使用稍旧的ML技术但搭配可以自动化建模的做法,够用就好的ML,不是用最新技术。

其次,要打造一个兼顾各种功能和稳定性的端到端平台,但要把这些功能尽量背景化,希望做到,一个按钮就可以完成。

Todd Underwood也希望大幅降低训练成本,并且把各种ML服务变成API,可以稳定且方便集成到各种应用中,让ML无所不在,最后则是要创建ML品质评量机制,适用各处而且值得信任。

发表评论