Article / 文章中心

ADmobile首席架构师王威:广告业务云上运维最佳实践

发布时间:2022-01-06 点击数:271

12月21日,在阿里云弹性计算年度峰会上,ADmobile首席架构师王威发表了《ADmobile广告业务云上弹性计算最佳实践》的演讲,介绍了ADmobile业务云上最佳实践。

王威-小尺寸.png

【图:ADmobile首席架构师王威】


本文主要根据王威的演讲整理而成,内容分为四部分:

  1. 业务背景介绍;
  2. 业务发展中的技术痛点;
  3. 解决方案;
  4. 实践经验。

01 ADmobile(艾狄墨搏)业务背景介绍


图1.jpg


ADmobile是一家程序化的广告聚合SaaS服务商,通过自主研发的广告聚合管理系统,整合流量管理、UR工具,为APP广告变现提升收益。通过一站式广告聚合平台,ADmobile提供专业多维度的数据报表,还有聚合管理、灵活的运营方式和多样灵活的优化工具。

2-业务发展变化.jpg


上图可以看到,ADmobile业务发展中服务资源的变化:从最早期就是一台服务器、一个数据库支撑我们业务发展,到现在有200台以上的服务器,还有数据库、中间件、负载均衡等一系列云资源。业务高峰的时候,ECS数量一度达到400台,甚至曾经超过500台;业务高速发展的同时,流量也在激增,对于技术和运维都是一种极大的挑战。


02  ADmobile业务发展中的三大技术痛点


在早期的方案当中,对于流量峰值的变化,基本无法灵活应对,只能通过部署服务器去应对流量波动。一些特殊的日子,例如618、双11的大促期间,流量会出现爆发式增长,这需要技术人员提前准备足量的服务器,应对流量的激增,保证我们业务能够平稳运行。

3-早期方案.jpg


早期部署方式也比较传统,即在一台指定的服务器上,把我们的项目运营好,制定一些相应的启动脚本来生成ECS镜像,通过批量的创建ECS来保证服务正常运行。

4-早期技术架构.jpg


早期的技术架构看上去很简单,总共只有3个服务,这是我们在线运营的业务。通过负载均衡进入服务A,通过服务发现调用B和C,整体三个服务支撑了我们现在的一大块业务。这个技术架构中,所有的服务器都是固定的,所以无法根据流量变化去实时动态调节服务器资源,因此造成了服务器资源很大的冗余和浪费

5-技术痛点.jpg


服务资源冗余、突发大流量的应对困难、镜像生成非常耗时(基本上需要数十分钟甚至小时级别),这三个技术痛点导致很难应对业务实时的变化发布。


03 我们的解决方案


6-现在的方案.jpg


当前,ADmobile选择了增加了弹性服务器组,发布方式上采用了ECS自动同步最新服务,并采用了Jenkins+K8s的一键部署。在一台服务器上把服务部署好,其他的服务器会定时同步最新的服务,并重新启动服务,这样避免了重新生成ECS镜像,可以实现更加灵活的发布。

7-技术架构1.jpg


上图是我们技术架构中的一个,相比早期的架构可以明显地看到多了一个弹性伸缩组。弹性伸缩组的存在,既避免了服务器资源很大的冗余和浪费,又能更好地应对一些大量流量的突增业务。在弹性伸缩组里面还可以通过部署一部分抢占式实例,来进一步降低服务器成本。

8-技术架构2.jpg


这是另一个业务架构,它是基于K8s搭建的,现在比较流行通用的架构,分为数据层、服务层、网关层和展示层。

1. 数据层,可能包括数据库MySQL、缓存Redis、对象存储OSS等。


2. 服务层以K8s为核心,包括我们自己搭建的Kubernetes,只有在进行发布的时候才会占用一些资源,不发布的时候基本上不占用资源。


3. 网关层,主要是通过负载均衡对外提供服务,目前在尝试将服务网格应用到业务中,还处于测试阶段,接下来如果测试稳定,可能就会把负载均衡全部切到服务网格上。


4. 展示层,包括PC端、移动端、小程序等。在这种架构中间,还使用了阿里云的平台服务,像注册中心、日志记录等服务穿插在整个业务的所有过程中。

以下介绍我们在实际工作中遇到的常见问题及解决方案。


1、如何应对流量激增

9-常见问题1.jpg


这是很多业务运行过程中都会碰到的问题,流量激增可以分为两类:一类是可预测的流量,例如,早高峰或者晚高峰由于用户量的增加导致流量激增,这种可预测的流量激增,可以定时的扩容的策略来保证业务运行;另一类是不可预测的流量,一般可以通过API或者SDK方式自定义监控指标,借用阿里云的接口提前进行扩容,即根据指标的波动、变化进行相应的扩容或者缩容。实现方式是根据自己的业务结合阿里云的SDK 、API相应的脚本进行编写。


2、如何选择监控指标

10-常见问题2.jpg


伸缩容过程中的一些监控指标,例如平均负载、CPU使用率、内存使用率、网络流量、磁盘IO等,可以根据不同的应用类型来选择不同的监控指标。以JAVA应用为例,它是比较占用内存的,当内存占比到70%-80%,它的CPU占用可能还很小;如果我们监控它的CPU使用率,尽管CPU占用处于正常范围,而内存可能已经用到90%或者更高,这种监控指标的选择是不太恰当的,我们应该根据不同的应用灵活地选择监控指标。


3、如何选择扩容和缩容的指标值

11-常见问题3.jpg


这个主要是指阿里云弹性伸缩组的扩容和缩容的指标值。根据我们的实践,不建议设置相等值,例如,当CPU使用率大于50%的时候进行扩容,CPU使用率小于50%的时候进行缩容。这是因为扩容或者缩容都有冷却时间,如果CPU的使用率就在50%左右上下波动,可能最终导致我们的扩容或者缩容的目的无法实现。

 

04  四大实践经验总结


12-实践经验总结.jpg


我们总结的实践经验有4点:


第一,不要把所有的ECS都交给弹性伸缩组来控制。因为弹性伸缩组是比较灵活的,如果我们设置的指标不太严格,可能导致ECS出现无序的扩容,或者出现ECS数量变成零等异常情况,从而对业务造成影响。


第二,弹性伸缩组里面设置合适的实例上限。这个和第一个类似,如果不设置上限或者上限值设置的不合理,可能会导致无序扩容,应用异常或者监控指标持续上升,最终导致服务器数量异常,对成本带来负担。


第三,部署适当比例的抢占式实例。抢占式实例的折扣在活动中可能低到1折,如果业务结构合适,通过分配一定比例的抢占式实例,可以有效地降低成本。


第四,善用云上运维自动化服务。阿里云提供了很多好用的工具,例如使用ECS云助手,可以对服务器进行批量的漏洞修复或者软件升级。

13-实例展示.jpg



最后,分享一个弹性伸缩组的案例。在上图中,最高峰的时候,ECS数量应该有45台,最低的时候有10台,并且最低10台的时候我们做了一定的冗余处理。如果放开限制,ECS数量会变得更少,通过这样的部署方案,经过测算,成本总共降低了约30%。

12月21日,在阿里云弹性计算年度峰会上,ADmobile首席架构师王威发表了《ADmobile广告业务云上弹性计算最佳实践》的演讲,介绍了ADmobile业务云上最佳实践。

王威-小尺寸.png

【图:ADmobile首席架构师王威】


本文主要根据王威的演讲整理而成,内容分为四部分:

  1. 业务背景介绍;
  2. 业务发展中的技术痛点;
  3. 解决方案;
  4. 实践经验。

01 ADmobile(艾狄墨搏)业务背景介绍


图1.jpg


ADmobile是一家程序化的广告聚合SaaS服务商,通过自主研发的广告聚合管理系统,整合流量管理、UR工具,为APP广告变现提升收益。通过一站式广告聚合平台,ADmobile提供专业多维度的数据报表,还有聚合管理、灵活的运营方式和多样灵活的优化工具。

2-业务发展变化.jpg


上图可以看到,ADmobile业务发展中服务资源的变化:从最早期就是一台服务器、一个数据库支撑我们业务发展,到现在有200台以上的服务器,还有数据库、中间件、负载均衡等一系列云资源。业务高峰的时候,ECS数量一度达到400台,甚至曾经超过500台;业务高速发展的同时,流量也在激增,对于技术和运维都是一种极大的挑战。


02  ADmobile业务发展中的三大技术痛点


在早期的方案当中,对于流量峰值的变化,基本无法灵活应对,只能通过部署服务器去应对流量波动。一些特殊的日子,例如618、双11的大促期间,流量会出现爆发式增长,这需要技术人员提前准备足量的服务器,应对流量的激增,保证我们业务能够平稳运行。

3-早期方案.jpg


早期部署方式也比较传统,即在一台指定的服务器上,把我们的项目运营好,制定一些相应的启动脚本来生成ECS镜像,通过批量的创建ECS来保证服务正常运行。

4-早期技术架构.jpg


早期的技术架构看上去很简单,总共只有3个服务,这是我们在线运营的业务。通过负载均衡进入服务A,通过服务发现调用B和C,整体三个服务支撑了我们现在的一大块业务。这个技术架构中,所有的服务器都是固定的,所以无法根据流量变化去实时动态调节服务器资源,因此造成了服务器资源很大的冗余和浪费

5-技术痛点.jpg


服务资源冗余、突发大流量的应对困难、镜像生成非常耗时(基本上需要数十分钟甚至小时级别),这三个技术痛点导致很难应对业务实时的变化发布。


03 我们的解决方案


6-现在的方案.jpg


当前,ADmobile选择了增加了弹性服务器组,发布方式上采用了ECS自动同步最新服务,并采用了Jenkins+K8s的一键部署。在一台服务器上把服务部署好,其他的服务器会定时同步最新的服务,并重新启动服务,这样避免了重新生成ECS镜像,可以实现更加灵活的发布。

7-技术架构1.jpg


上图是我们技术架构中的一个,相比早期的架构可以明显地看到多了一个弹性伸缩组。弹性伸缩组的存在,既避免了服务器资源很大的冗余和浪费,又能更好地应对一些大量流量的突增业务。在弹性伸缩组里面还可以通过部署一部分抢占式实例,来进一步降低服务器成本。

8-技术架构2.jpg


这是另一个业务架构,它是基于K8s搭建的,现在比较流行通用的架构,分为数据层、服务层、网关层和展示层。

1. 数据层,可能包括数据库MySQL、缓存Redis、对象存储OSS等。


2. 服务层以K8s为核心,包括我们自己搭建的Kubernetes,只有在进行发布的时候才会占用一些资源,不发布的时候基本上不占用资源。


3. 网关层,主要是通过负载均衡对外提供服务,目前在尝试将服务网格应用到业务中,还处于测试阶段,接下来如果测试稳定,可能就会把负载均衡全部切到服务网格上。


4. 展示层,包括PC端、移动端、小程序等。在这种架构中间,还使用了阿里云的平台服务,像注册中心、日志记录等服务穿插在整个业务的所有过程中。

以下介绍我们在实际工作中遇到的常见问题及解决方案。


1、如何应对流量激增

9-常见问题1.jpg


这是很多业务运行过程中都会碰到的问题,流量激增可以分为两类:一类是可预测的流量,例如,早高峰或者晚高峰由于用户量的增加导致流量激增,这种可预测的流量激增,可以定时的扩容的策略来保证业务运行;另一类是不可预测的流量,一般可以通过API或者SDK方式自定义监控指标,借用阿里云的接口提前进行扩容,即根据指标的波动、变化进行相应的扩容或者缩容。实现方式是根据自己的业务结合阿里云的SDK 、API相应的脚本进行编写。


2、如何选择监控指标

10-常见问题2.jpg


伸缩容过程中的一些监控指标,例如平均负载、CPU使用率、内存使用率、网络流量、磁盘IO等,可以根据不同的应用类型来选择不同的监控指标。以JAVA应用为例,它是比较占用内存的,当内存占比到70%-80%,它的CPU占用可能还很小;如果我们监控它的CPU使用率,尽管CPU占用处于正常范围,而内存可能已经用到90%或者更高,这种监控指标的选择是不太恰当的,我们应该根据不同的应用灵活地选择监控指标。


3、如何选择扩容和缩容的指标值

11-常见问题3.jpg


这个主要是指阿里云弹性伸缩组的扩容和缩容的指标值。根据我们的实践,不建议设置相等值,例如,当CPU使用率大于50%的时候进行扩容,CPU使用率小于50%的时候进行缩容。这是因为扩容或者缩容都有冷却时间,如果CPU的使用率就在50%左右上下波动,可能最终导致我们的扩容或者缩容的目的无法实现。

 

04  四大实践经验总结


12-实践经验总结.jpg


我们总结的实践经验有4点:


第一,不要把所有的ECS都交给弹性伸缩组来控制。因为弹性伸缩组是比较灵活的,如果我们设置的指标不太严格,可能导致ECS出现无序的扩容,或者出现ECS数量变成零等异常情况,从而对业务造成影响。


第二,弹性伸缩组里面设置合适的实例上限。这个和第一个类似,如果不设置上限或者上限值设置的不合理,可能会导致无序扩容,应用异常或者监控指标持续上升,最终导致服务器数量异常,对成本带来负担。


第三,部署适当比例的抢占式实例。抢占式实例的折扣在活动中可能低到1折,如果业务结构合适,通过分配一定比例的抢占式实例,可以有效地降低成本。


第四,善用云上运维自动化服务。阿里云提供了很多好用的工具,例如使用ECS云助手,可以对服务器进行批量的漏洞修复或者软件升级。

13-实例展示.jpg


最后,分享一个弹性伸缩组的案例。在上图中,最高峰的时候,ECS数量应该有45台,最低的时候有10台,并且最低10台的时候我们做了一定的冗余处理。如果放开限制,ECS数量会变得更少,通过这样的部署方案,经过测算,成本总共降低了约30%。