Training/Serving一体化的AI微服务框架设计 (一)

Posted by Akilis on 06 Jul, 2020

Introduction

现代BI，以自然语言搜索作为用户入口，背后依托NLP，Knowledge Graph，ML等技术提供更智能的数据查询、分析、探索服务。BI的交互式特点，即所想即所得的核心特征，又使得背后的技术设计和实现均需根据该特征加以配合和考虑，基于研究和实践，提出如下ML微服务框架，可实现快速原型，验证算法在实际的业务场景下，能否对数据集进行有效探索与利用，对BI端输出AI能力。

Design

Targets

用户以同步的方式使用BI产品的各种功能，因此ML驱动的功能也应当遵循此交互模式，给用户一致性的体验。ML驱动的功能包括聚类、时序数据预测、What-if高级分析等。
高资源利用率以及快速失败原则。控制资源使用，甄别重复训练请求，管理过期模型。
微服务具有良好scale-out能力，随着用户量的增长，服务可以加入更多资源，线性地提升吞吐，而不增加延时。

Interfaces

Training. BI端传入数据集、模型规约，AI端训练模型，输出训练结果，保持会话ID。
Serving. BI端传入数据集、模型规约、会话ID，AI端做模型推断，返回结果。

Components

Web Framework. 对外输出training/serving REST API。
Model core. 核心模型层，模型抽象为fit/predict接口，负责训练与推断。save/load接口负责模型持久化与动态加载。

Implementation

Flask搭建training/serving end-points. Gunicorn作为WSGI server，为了保证下文的伸缩性，需采用单worker模式。
算法模型基于Sklearn/StatsModel等轻量级算法库，结合模型使用场景特点，经过实验论证，选择出最泛化模型，来适应各种业务场景下的数据集。结合少量grid search，trade-off时间与性能表现，实现算法。
training依托进程严格控制时间与资源管理。
借助web框架能力，多线程serving。
定义数据集、模型规约，抽象模型工厂方法，根据请求数据和规约创建对应的模型。
training阶段调用模型fit, save接口，serving阶段调用模型load, fit接口.
性能优化手段
- 资源使用控制
  - 问题描述：避免服务器过载，导致其它正在服务的请求受到影响。
  - 解决方案：监控并限制正处于training的数量，达到性能瓶颈的阈值时直接拒绝服务，快速失败，不影响正在训练的模型。上线后，可以通过日志分析并调优触发拒绝的阈值。
- 重复训练请求
  - 问题描述：接口调用方可能反复提交同样的训练请求，造成重复训练，浪费资源。
  - 解决方案：请求中参数携带Session ID (SID)，服务端保存SID关联的训练信息，当接收到重复提交时，如果模型还未训练完成，则告知模型正在训练中，如果模型已经训练完成则直接返回训练结果.
- 过期模型管理
  - 问题描述：处于Serving中的模型可能后期不再使用，或者使用不频繁。而且由于内存限制，也不能无限增长。
  - 解决方案：使用LRU缓存策略，只保证一部分常用模型的在线serving，其它通过持久化技术来动态加载与卸载。
- 伸缩性
  - 问题描述：当单台机器资源使用达到上限时，如何投入资源服务更多请求。
  - 解决方案：多服务器节点组成集群，配置负载均衡策略，使得系统具备线性扩展的能力。要实现training和serving的请求在同一个节点处理（即Serving Locality），请求Header都携带SID，负载均衡基于SID HASH值，实现类似基于session LB的效果。

Conclusion

training是CPU-consuming的任务, 而高并发的serving又带来I/O-consuming的压力，本文的设计方法，开发轻量接口，快速原型，在实际业务场景，打磨AI能力。

FRAMEWORK ML TRAINING SERVING WEB

Login