关于腾讯云:成本降低40资源利用率提高20的-AI-应用产品云原生容器化之路

作者

郭云龙，腾讯云高级工程师，目前就任于 CSIG 云产品三部-AI 利用产品核心，现负责核心后盾业务框架开发。

导语

为了满足 AI 能力在私有云 SaaS 场景下，服务和模型须要疾速迭代交付的需要，保障服务在不稳固高并发时的高成功率，以及进一步晋升资源利用率，AI 利用产品核心进行了一系列的调研与实际，本篇将重点介绍团队在容器化方面的实践经验。

背景和问题

私有云 AI SaaS 产品（如人脸交融)的个别服务流程为：C 端或 B 端客户通过采集设施采集图像、音视频等，经由云 API 等接入形式传入，服务端利用弱小的计算能力、短缺的资源和绝对成熟的算法对客户输出的多媒体内容进行解决。

如上图所示，对于个别流程来说，咱们面临着三个挑战。

1. 采集品质不稳固：因为采集设施之间存在差别，采集到的品质也会存在差别，拿图像处理来说，大图和小图会给咱们的服务带来不同的压力，有时服务会因为集中的大图并发产生失败。
2. 短期、高并发需要多：咱们的客户会用咱们的能力实现不同的玩法，应用人脸交融来进行游戏流动宣传就是一个很常见的经营伎俩，然而这种流动会给咱们的服务带来短期内的高并发压力。
3. 模型、服务迭代快：AI SaaS 服务的竞争十分强烈，常常会有客户提出新的需要，加上算法难免会有 badcase，所以咱们的服务也要进行很频繁的降级迭代。

咱们再来看下咱们容器化前的精简架构（如上图所示），物理机的开发部署大背景下，咱们的逻辑服务不论是构造上还是根底上都属于大泥球模式，另外算法服务也常有混布的景象存在。

这种架构也导致了忙时服务间抢占资源的状况频繁产生，影响服务成功率及耗时，导致咱们没有方法很好的满足客户的需要；而闲时资源利用率非常低，容易造成资源节约。

以两个理论的例子来阐明：

1. 降级公布时，咱们须要先从LB中剔除一个节点，并在节点上察看没有流量进入后进行服务降级。降级实现后，人工对服务进行胜利性检测，检测后果ok后再加回LB中。
2. 客户搞流动时提出高并发需要，如果以后物理机/vm资源池不满足，须要向资源同学紧急提物理机需要，资源同学协调到机器后，咱们须要人工对机器环境/网络从新初始化，而后执行上述1操作。待流动完结后机器闲置，易造成老本节约。

为了更好的满足客户一直迭代的需要，加重研发的运维累赘，补齐弹性能力和接入高效的服务管控平台对咱们来说是迫切需要的。趁着公司推动上云的机会，咱们对架构组件进行了几轮调研和优化。本文次要对容器化过程进行论述。

容器化过程记录

咱们的容器化上云到当初为止能够分为三步：容器化，稳定性晋升和利用率晋升。

容器化

这里的容器化映射到业务上来说，除了将服务载体由物理机迁徙到容器上，更次要是将原来的简单逻辑解耦，微服务化。

如下图所示，咱们先对服务自身做了瘦身微服务化，另外借助于容器的能力，将原来混布的服务彻底离开。如何进行微服务化会因业务的不同存在差别，本篇对此不做赘述。

稳定性晋升

在第一步容器化之后，咱们很快享受到了飞个别的服务降级和扩容速度。同时对容器化比拟通俗的了解也给咱们带来了一些新的问题。

1. 调用量稳定较大的服务因为频繁扩缩容导致业务失败
2. 一些客户传的大图在低核容器上解决效率较低
3. 集群资源紧缺导致的容器无奈按需扩容等。

对于上述三个问题，咱们也别离找出了应答计划。

灵便应用探针

起初咱们的服务都是没有设置存活和就绪检测（探针 ）的，Prestop 给缩容时加上了一层爱护，然而并不彻底，而且在扩容时难免会有服务失败。

探针给咱们提供了另一种弱小的解决形式。一开始时，咱们参照链接中的示例，进行简略的端口查看来判断服务是否失常运行。起初咱们发现了更多灵便的使用技巧和应用场景。以下列出几个例子供大家参考以及发散出更多乏味实际。

例子1：在一开始时大家常常遇到 LB Agent 启动时获取路由必然失败的状况，咱们能够应用就绪探针来进行 LB 的预加载（如下图），即可达到 LB 获取胜利后标记服务启动胜利的成果。

例子2：因为一些低版本OS的实例存在弱口令的问题，大家须要把所有依赖旧版OS的镜像全副降级，这个工作对咱们来说是及其沉重的，于是咱们同样利用了探针，在容器标记服务启动前把弱口令全副干掉。

例子3：某个服务比拟非凡，内存占用常常稳定，当内存小于某个值时，服务会偶现失败，然而端口失常存活。这时咱们能够应用 ConfigMap+python 脚本来进行一些简单的检测：

针对大图进行筛选适配

容器化后，咱们发现某个算法在接管到高分辨率图片时，服务成功率会呈现稳定，起因是算法在对提特色时会呈现更多的耗费，这一景象在物理机上部署时被物理机核数多的劣势掩盖住了，一旦到了核数较低的容器上就露出了进去。为了解决这个问题，咱们在下层逻辑中新增了大图筛选性能（如下图所示），如果检测到是大图，则走回物理机集群（因为初始时 TKEx 提供最高规格容器核数为 8 核，起初才裁减反对了 24 核及以上），如果是个别图片，则走容器集群。

多集群部署

在应用 TKEx 时，咱们常常会碰到部署的 workload 会因为整体集群资源有余的起因，无奈扩容到指定的 max 值，一度十分苦恼。

TKEx 的同学也是举荐咱们在其余的集群复制一份资源，当一个集群扩不进去时，另一个集群充当备份角色。在这么调整过后，咱们的扩容成功率逐渐回升。

起初又呈现了整个地区的资源都比拟紧缺的状况，于是咱们把一些对时延不那么敏感的服务进行了多地区部署（如下图），最终将集群资源有余的危险进一步升高。

当一地资源有余的状况下应用多地区部署以及 LB 时，个别 LB 都会依据后端响应工夫动静调整各节点权重，所以咱们应留神以下两点：

1. 敞开就近拜访
2. 依据上下游调整 LB 权重（比方上游服务部署在广州，上游同时部署了南京和广州，这是南京和广州的 LB 权重别离为130，100）

利用率晋升

在进行过一轮稳定性晋升之后，咱们能够更加自信的利用弹性能力，利用率也有了显著晋升。不过仍旧有两个问题妨碍着咱们的利用率更进一步。一个是有些服务模型大，启动慢，流量突增时服务无奈很及时的扩容进去，这时咱们必须要提前占用一些资源导致利用率提不下来。

针对第一个问题，咱们筛选了局部流量有法则的服务。利用 TKE 提供的定时 HPA 能力，在已知流量顶峰前定时进行一轮扩容。

成绩

以后咱们的 AI 服务曾经根本实现容器化的降级。成功率高，扩容快，欢送大家扫码进行体验。

对于咱们

更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~

福利：公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！