AI云原生浅谈:好将来AI中台实践

简介: 2020年云栖大会上,好将来AI中台负责人刘东东,分享了他对AI云原生的理解与好将来的AI中台实践,本文为演讲内容整理。数据库

AI时代的到来,给企业的底层IT资源的丰富与敏捷提出了更大的挑战,利用阿里云稳定、弹性的GPU云服务器,领先的GPU容器化共享和隔离技术,以及K8S集群管理平台,好将来经过云原生架构实现了对资源的灵活调度,为其AI中台奠基了敏捷而坚实的技术底座。安全

在2020年云栖大会上,好将来AI中台负责人刘东东,分享了他对AI云原生的理解与好将来的AI中台实践,本文为演讲内容整理。服务器

你们好,我是好将来AI中台技术负责人刘东东。今天我给你们带来的演讲主题是《好将来AI云原生的浅谈》。个人分享主要分红四个部分:架构

第一,AI服务对云原生的挑战。
第二,AI与云原生的服务部署。
第三,AI与云原生的服务治理。
最后想谈一谈, K8S与Spring Cloud的有机结合。


负载均衡

一、AI服务对云原生的挑战

首先,咱们来说一讲AI服务对云原生的挑战。在云原生时代,AI服务其中最大的一个特色就是,须要更大的算力支持,以及更强大的一个服务的稳定性。运维

 

image.png

咱们的服务不仅仅只是原来的一个单体服务,如今已经转入到一个集群服务。同时对性能的稳定性要求,已经从3个9,开始向5个9发起了挑战。异步

那么这些问题,已经再也不是原有的传统技术架构可以解决的。因此咱们须要一个新的技术架构。分布式

这个新的技术架构是什么呢?就是云原生。ide

咱们来看一看,云原生对咱们带来的变化。云原生带来的最大变化,我总结为四个要点和两大方面。微服务

四大要点分别是,DevOps、持续交付、微服务、容器的四个特色。两个方面则是服务部署和服务治理。固然,它还有12个要素的总体系统总结。

 

image.png

今天重点来说的是服务部署和服务治理。

在云原生浪潮下,咱们是如何处理服务部署和服务治理呢?

首先咱们经过AI与云原生的服务部署,即经过K8S,加上一个资源的虚拟化,资源的池化等技术,解决了AI服务对各类硬件资源的数量级增加需求。

第二个,AI服务与云原生的服务治理进行有机结合。经过服务治理的技术,包括服务发现、HPA、负载均衡等,解决AI服务对5个9的SLA的需求。

 

image.png

二、AI服务的云原生部署

第一点谈一下是怎么把AI与云原生的服务部署结合起来的。

首先看一下,在AI时代下服务部署有哪些特色呢?

第一个就是硬件资源需求与费用增加的一个矛盾。AI服务对于硬件的需求成数量级增加,可是硬件预算并无成数量级增加。

第二,AI服务对硬件的需求是多样化的。如,对高GPU的需求、高CPU的需求、高内存的需求,甚至还有部分混合的需求。

第三,AI服务对资源的隔离是有需求的。每个AI服务都可以独立使用这些资源,而且相互之间不会打扰。

第四,AI服务可以对资源池化有要求。AI服务不须要去感知机器的具体配置,一旦将全部的资源进行池化,便可下降资源碎片,提高使用率。

最后一点,AI服务对突发的资源是有请求的。由于流量是不可预知的,企业须要随时保持,可以随时扩充资源池的能力。

 

image.png

咱们的解决方案是什么呢?

首先,咱们使用Docker的虚拟化技术,实现资源的隔离。

而后使用GPU共享技术,将GPU、内存、CPU等资源进行池化,而后将整个资源进行统一的管理。

最后,使用K8S的resources,包括污点(taints)、容忍度(tolerations)等这些技术特性,实现服务的灵活配置。

另外,建议你们要买一些高配置的机器,这些高配置的机器,主要是为了进一步下降碎片。

固然,还要实现对整个集群硬件的监控,充分利用ECS能够各类复杂的时间规则调度特性(下图的cron是一个基于时间的做业调度任务),应对高峰流量。

 

image.png

接下来,咱们更仔细地看看好将来AI中台是如何解决这些AI部署问题的。

这个页面是咱们的一个Node的服务管理,经过这个业务,咱们是能够清晰看到每个服务器上面的部署状况,包括资源使用状况、部署哪些pod、哪些节点等等。

 

image.png

第二个其实是AI中台的服务部署页面。咱们是能够经过压码文件,精准地控制每个pod的内存、CPU、GPU的使用。同时,经过污点等技术,让服务器的多样化部署获得知足。

 

image.png

根据咱们的对比实验,使用云原生的方式部署对比用户自行部署,成本大概节省了65%。并且,这样的优点会随着AI集群的增加,在经济收益上和临时流量扩容上,将会受益更多。

三、AI与云原生服务治理

接下来再讨论一下AI与云原生的服务治理。

简单介绍一下什么叫微服务?其实微服务,只是服务的一种架构风格,它其实是将单个服务,做为一整套的小型服务开发,而后每个应用程序都有本身进程去运行,而且经过轻量级的一些,好比说HTTP、API等进行通讯。

 

image.png

这些服务,其实是围绕着业务自己去构建的,能够经过自动化的部署等手段去集中管理。同时,经过不一样的语言去编写,使用不一样的存储资源。

总结起来微服务有哪些特色?

第一,微服务它足够小,甚至它只能作一件事情。
第二,微服务是无状态的。
第三,微服务相互之间是相互独立的,而且它们是面向接口的。
最后,微服务是高度自治的,每一个人只对本身负责。


 

 

看到这些微服务的特色以后,再去想想,AI服务与微服务特色,咱们发现,AI服务天生适合微服务。每个微服务,其实本质上只作一件事情。好比OCR,OCR服务,只作OCR服务;ASR,主要作ASR服务。

继而,每个AI服务的请求都是独立的。举个简单例子,一个OCR请求和另一个OCR请求,在本质上是没有什么关联的。

AI服务对横向扩容是有天生苛求的。为何?由于AI服务队资源的渴求很是大。因而,这种扩容就显得很是有必要性了。

AI服务之间的依赖性也特别小。好比说像咱们的OCR服务,可能对NLP的服务,或者是对其它的AI服务,可能没有什么太大的要求。

全部的AI服务,均可以经过写申明式的HTTP,甚至API的方式,提供AI能力。
进一步去看一下AI服务,会发现,并不能将全部的AI服务进行微服务化。因而,咱们作了什么事?

第一,须要将AI服务作成一个无状态的服务,这些无状态服务,都是有畜牲化、无状态、可丢弃,而且不采用任何的一些磁盘或者内存的请求方式,去作一些存储功能。这样就可让服务部署在任何的一个节点,任何一个地方。

固然,并非全部的服务都能作到无状态。若是它有状态了怎么办呢?咱们会经过配置中心、日志中心、Redis、MQ,还有SQL等数据库,存储这些请求状态。同时,确保这些组件的高可靠性。

 

image.png

这个就是好将来AI中台PaaS的总体架构图。首先能够看一下最外层是服务接口层。最外层接口层是面向外部提供AI能力的。

平台层里最重要的层是服务网关,主要是负责一些动态路由、流量控制、负载均衡、鉴权等。再往下就是咱们的一些服务发现,注册中心,容错、配置管理、弹性伸缩等等一些功能。

再下面是业务层,这些业务层就是咱们所说的,一些AI的推理服务。

最下面就是阿里云给咱们提供的K8S集群。

也就是说总体的一个架构是,K8S负责服务部署,SpringCloud负责服务治理。

 

image.png

咱们是怎么经过技术手段来实现刚才说的一个总体架构图?

首先是经过Eureka做为注册中心,实现分布式系统的服务发现与注册。经过配置中心Apoll来管理服务器的配置属性,而且支持动态更新。网关Gateway,能够作到隔离内外层的效果。熔断Hystrix,主要是分为分时熔断和数量熔断,而后保护咱们的服务不被阻塞。

负载均衡加上Fegin操做,能够实现总体流量的负载均衡,而且将咱们的Eureka相关注册信息进行消费。消费总线Kafka是异步处理的组件。而后鉴权是经过Outh2+RBAC的方法去作的,实现了用户的登陆包括接口的鉴权管理,保证安全可靠。

链路追踪,采用的是Skywalking,经过这种APM的一个架构,咱们能够追踪每个请求的状况,便于定位和告警每个请求。

最后日志系统是经过Filebeat+ES,分布式收集整个集群的日志。

 

image.png

同时咱们也开发了一些本身的服务,好比说部署服务、Contral服务。主要是负责与K8S进行通讯,收集整个K8S集群里面服务的服务部署、K8S相关的硬件信息。

而后告警系统是经过Prometheus+Monitor去作的,能够收集硬件数据,负责资源、业务等相关的告警。

数据服务是主要用于下载,包括数据回流,而后截取咱们推理场景下的数据状况。

限流服务是限制每一个客户的请求和QPS相关功能。

HPA其实是最重要的一个部分。HPA不仅仅只支持内存级别的,或CPU级别的HPA,还支持一些P9九、QPS、GPU等相关规则。

最后是统计服务,主要是用于统计相关调用量,好比请求等。

 

image.png

咱们经过一个统一的控制台,对AI开发者提供了一站式的解决方案,经过一个平台解决了所有的服务治理问题,提高了运维的工做自动化,让原来须要几我的维护的一个AI服务的状况,变成了一我的可以作到维护十几个AI服务。

这个页面展现的就是服务路由、负载均衡、限流相关的配置页面。

 

image.png

这个页面展现的是咱们在接口级别的一些告警,以及部署级别的硬件告警。

 

image.png

这是日志检索,包括实时日志相关功能。

 

image.png

这个是手动伸缩和自动伸缩操做页面。其中自动伸缩包括CPU、内存级别的HPA,也包括基于相应响应时长制定HPA、定时的HPA。

 

 

四、K8S与Spring Cloud的有机结合

最后来聊一下K8S与SpringCloud的有机结合。

 

image.png

能够看一下这两张图。左图是咱们SpringCloud数据中心到路由的图。右边是K8S的service到它的pod的图。

这两个图在结构上是很是接近的。咱们是怎么作到呢?其实是将咱们的Application与K8S的service进行绑定,也就是说最终注册到咱们SpringCloud里面LB的地址,其实是把它转成了K8S service的地址。这样就能够将K8S与SpringCloud结合起来。这是路由级别集合。有了这个集合,就能达到最终的效果

 

image.png

SprigCloud它是一个Java的技术语言站。而AI服务的语言是多样化的,有C++、Java,甚至有PHP。

为了实现跨语言,咱们引入了sidecar技术,将AI服务与sidecar经过RPC去通讯,就能够屏蔽语言的特性。

Sidecar主要的功能有,应用服务发现与注册、路由追踪、链路追踪,以及健康检查。

今天个人演讲到此结束,很是感谢各位的聆听。谢谢你们。

原文连接 本文为阿里云原创内容,未经容许不得转载。

相关文章
相关标签/搜索