成本降低40%、资源利用率提高20%的AI应用产品云原生容器化之路,ai云平台解决方案-ESG跨境

成本降低40%、资源利用率提高20%的AI应用产品云原生容器化之路,ai云平台解决方案

2022-05-15

617

成本降低40%、资源利用率提高20%的AI应用产品云原生容器化之路,ai云平台解决方案AI应用云原生容器化降低40%成本，提高20%资源利用率的方法简介为了满足公有云SaaS场景下服务和模型快速迭代交付的需求，保证服务在不稳定、高并发情况下的高成功率，进一步提高资源利用率，AI应用产品中心进行了一系列的调研和实践。本文......

成本降低40%、资源利用率提高20%的AI应用产品云原生容器化之路,ai云平台解决方案

AI应用云原生容器化降低40%成本，提高20%资源利用率的方法

简介

为了满足公有云SaaS场景下服务和模型快速迭代交付的需求，保证服务在不稳定、高并发情况下的高成功率，进一步提高资源利用率，AI应用产品中心进行了一系列的调研和实践。本文将重点介绍团队在集装箱化方面的实践经验。

背景和问题

公共AI SaaS产品(如人脸融合[1])的一般服务流程如下:C端或B端客户通过采集设备采集图像、音频、视频，再通过云端API等接入方式输入。服务器利用强大的计算能力、充足的资源和相对成熟的算法来处理客户输入的多媒体内容。

如上图所示，对于一般流程，我们面临三个挑战。

1.采集质量不稳定:由于采集设备的差异，采集的质量也会有所不同。以图像处理为例，大图像和小图像会给我们的服务带来不同的压力，有时服务会因为集中大图像而失败。

2.短期、高并发需求:我们的客户会利用我们的能力实现不同的游戏玩法。利用人脸融合推广游戏活动是一种很常见的运营手段，但这种活动短期内会给我们的服务带来很高的并发压力。

3.模型和服务的快速迭代:AI SaaS服务的竞争非常激烈，客户经常会提出新的要求。另外算法上难免会有badcase，所以我们的服务也不得不频繁升级迭代。

让我们来看看容器化之前我们的简化架构(如上图所示)。在物理机开发部署的背景下，我们的逻辑服务无论是结构还是基础都属于大泥球模式。此外，算法服务往往良莠不齐。

这种架构也导致繁忙的服务之间频繁的资源抢夺，影响服务成功率和耗时，导致我们无法很好的满足客户的需求；但是闲暇时间的资源利用率很低，容易造成资源浪费。

用两个实际例子来说明:

当升级发布时，我们需要首先从LB中删除一个节点，并观察在升级服务之前没有流量进入该节点。升级完成后，手动测试服务是否成功，测试结果OK后再添加回LB。

客户搞活动，提出了高并发的要求。如果当前的物理机/vm资源池不满足，他们需要紧急向资源同学提出物理机需求。资源同学与机器协调后，我们需要手动重新初始化机器环境/网络，然后执行上述操作1。活动结束后机器闲置，很容易浪费成本。

为了更好地满足客户的迭代需求，减轻R&D运维负担，弥补灵活性，接入高效的业务管控平台，这是我们迫切需要的。利用公司对云的推广，我们对架构组件进行了多轮研究和优化。本文主要阐述集装箱化过程。

集装箱化过程记录

到目前为止，我们的容器化云可以分为三步:容器化、稳定性提升、利用率提升。

集装箱化

这里的集装箱化映射到业务。除了将服务载体从物理机迁移到容器之外，主要是将原来复杂的逻辑解耦，微服务。

如下图所示，我们先为服务本身做了一个瘦身微服务。此外，借助容器的容量，我们将原来的混合服务完全分离。如何进行微服务会因服务不同而有所不同，本文不再赘述。

提高了稳定性

在集装箱化的第一步之后，我们很快享受到了飞行服务的升级和扩张速度。同时，对集装箱化的简单理解也给我们带来了一些新的问题。

1.呼叫量波动的服务由于频繁的扩展和收缩而失败。

2.部分客户大图在低芯集装箱上的处理效率较低。

3.由于群集资源不足，容器无法按需扩展。

对于以上三个问题，我们也分别找出了解决方法。

灵活使用探针

起初，我们的所有服务都没有提供生存和准备状态检测(probe [2])。Prestop在扩容的时候加了一层保护，但是不彻底，扩容的时候服务失效是必然的。

探测器为我们提供了另一个强有力的解决方案。开始时，我们参考链接中的例子，进行简单的端口检查，以确定服务是否正常运行。后来我们发现了更灵活的应用技巧和场景。下面举几个例子供大家参考，还有更有趣的做法。

例1:刚开始的时候，人们经常会遇到LB Agent启动时获取路线不可避免的失败。我们可以使用ready探针来预加载LB(如下图所示)，这样可以达到成功获取LB后标志服务成功启动的效果。

例2:由于低版本操作系统的一些实例存在弱密码问题，我们需要升级所有依赖于旧版本操作系统的映像。这个工作对我们来说是极其繁重的，所以在容器标记服务启动之前，我们也使用探针杀死所有弱密码。

例3:某服务比较特殊，内存使用情况波动频繁。当内存小于某个值时，服务偶尔会失败，但端口会正常存活。这时候我们可以用ConfigMap+python脚本来做一些复杂的检测:

筛选和适应大图像

容器化后，我们发现一个算法在接收高分辨率图片时服务成功率会有波动，因为算法在提取特征时会消耗更多。这种现象在物理机上部署时被物理机的核多的优势掩盖了，一旦到了核少的容器就显露出来了。为了解决这个问题，我们在上层逻辑中加入了大图过滤的功能(如下图所示)。如果检测到是大图，我们就回到物理机集群(由于TKEx最初提供的是8核的最高规格容器，后来扩展到支持24核及以上)。如果是一般的图，我们就去集装箱集群。

多集群部署

在使用TKEx的时候，我们经常会遇到因为整个集群资源不足，导致部署的工作负载无法扩展到指定的max值，一度非常苦恼。

TKEx的同学也推荐我们在其他集群复制一个资源。当一个群集无法扩展时，另一个群集将充当备份。经过这次调整，我们的扩张成功率逐渐提高。

后来整个地区出现资源短缺，我们就在多个地区部署了一些对延时不那么敏感的服务(如下图)，最终进一步降低了集群资源短缺的风险。

在一个地方资源不足的情况下使用多区域部署和LB时，LB一般会根据后端响应时间动态调整各个节点的权重，所以要注意以下两点:

近距离访问

根据上下游调整LB权重(比如上游业务部署在广州，下游业务同时部署在南京和广州，意味着南京和广州的LB权重分别为130，100)

提高利用率

经过一轮稳定性的提升，我们可以更加自信的利用我们的灵活性，利用率得到了显著的提升。然而，还有两个问题阻碍了我们的进一步利用。一个是有些服务模型大，启动慢，在流量突然增加的情况下，服务不能及时扩展。这时候就得提前占用一些资源，导致利用率达不到。

针对第一个问题，我们选取了一些有固定流量的服务。利用TKE提供的定时HPA能力，在已知流量高峰前定期进行一轮扩容。

结果

目前我们的AI服务已经基本完成了容器化升级。成功率高，扩展快，欢迎扫码体验。