腾讯广告上云:架构设计与优化方案全解析

发布于:2020 年 8 月 4 日 14:06

资深架构师 杨波,正在以案例项目驱动,原理+编程技术+工具结合落地微服务和云原生架构,立即查看 >>
腾讯广告上云:架构设计与优化方案全解析

导语 | “云上生长,降本增效”是 2020 年腾讯 AMS (广告营销服务线) 上云的主题,希望通过对腾讯云新技术的应用,及自研上云重构部署的机会,实现成本大幅下降,性能提升的双重目标。通过上半年实践,在腾讯云团队及运营管理部的支持下,整体效果超出预期。本文将讲述期间遇到过的困难及优化历程,希望与大家一同交流。文章作者:凌飞,腾讯运维开发工程师。

一、业务架构

腾讯广告上云:架构设计与优化方案全解析

本阶段上云的主要链路为上图中红框部分,这条链路为广告播放链路,是整个广告业务中最核心,也是性能要求最高的链路,有以下特点:

1. 请求量大

日均请求量近千亿级别,机器量占了 AMS 自有机器量的绝大部分,整体性能即使是 1% 的上下波动都会涉及几百台机器的变动。

2. 链路拓扑复杂及性能压力极大

整个播放链路涉及 40+ 的细分模块。在 100~200 毫秒(不同流量要求有差异)的极短时间内,需要访问所有模块,计算出一个最好的广告。

3. 数据量大

大量的广告数据及回流训练数据在整个网络中流转,对带宽及存储带来了极大的压力。

二、上云方案选型

当前上云的主流路线主要是 CVM 或 TKE,在考虑 AMS 的上云路线时,我们主要考虑了以下两点:

第一: 本次 AMS 上云的核心模块,物理机机型 90% 均为 80 core 以上机型,上云后单机必须在 80 core 以上,已经将一台 CVM 所有 core 都使用完,再从资源管理角度考虑 TKE ,基本没有收益了。

第二: AMS 当前的 CI/CD 流程及业务运营系统无法完全对接 TKE 平台,强行切换的成本 / 风险与预期的收益无法对等。

基于以上考虑,AMS 的上云策略为前期 CVM 为主,TKE 为辅,继续完善 TKE 管理系统的流程对接。

腾讯广告上云:架构设计与优化方案全解析

上云三大阶段

(1)基础设施上云

大量使用云服务器,此阶段最主要的是把自研 IDC 的流量上云,同时试用云数据库,云负载均衡等各种 PaaS 服务。

腾讯广告上云:架构设计与优化方案全解析

业务规划 灰度方案 环境适配 流量迁移 监控告警
容量规划 回滚方案 功能测试 流量验证 持续运营
组件规划 风险评估 性能测试 灰度验证
机房规划 放量方案 压力测试 放量迁移
预算规划

(2)架构升级,大量使用 PaaS 服务

弹性伸缩、Docker 化改造,大量使用各种 PaaS 服务,充分发挥云的高级功能。

(3)基于云生态的研发运维体系

建设基于云生态的研发运维体系,全面拥抱云生态。

三、优化历程

虽然名为优化历程,但更多是 AMS 技术团队与腾讯云团队相互磨合,共同进步的历程。提到的一些坑或者优化点,后面上云的同学可能再也不会碰到了,因为大多数已经通过产品化的方式固化在腾讯云服务中。这也算是腾讯推动“开源协同,自研上云”目的之一。

1. 基础环境适配

腾讯广告上云:架构设计与优化方案全解析

2. CVM 性能调优

(1)广告播放性能要求

腾讯广告上云:架构设计与优化方案全解析

  • 接入方式多种多样,流量方众多,耗时要求各不相同,耗时容忍度不同
  • 每种流量访问的下游数量不同导致耗时不同,每个都影响最终的耗时,耗时增加直接影响收入
  • 各流量之间请求相差悬殊,超时比例即使相同但绝对值不同

(2)如何评估 CVM 与物理机的性能差异?

采用 percentile 百分位统计:

将一组数据从小到大排序,并计算相应的累计百分位,则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为:一组 n 个观测值按数值大小排列。如,处于 p% 位置的值称第 p 百分位数。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

相对于平均值统计,百分位统计区间更大,反应更灵敏,可以更好更及时反应业务质量的变化。

(3)优化目标

腾讯广告上云:架构设计与优化方案全解析

(4)主要耗时表现

耗时:云主机在广告检索模块上 99p 耗时比物理机 CG1 高 8-10ms。

腾讯广告上云:架构设计与优化方案全解析

平台 配置
CG1 intel 2 个 20 核 CPU(6133),256G 内存,6*480G SSD,RAID,2*10G 网口
云主机 Intel 80 或者 76 逻辑核,256G 内存,硬盘为 CBS,网卡限速为万兆

(5)云主机 ping 抖动

现象:使用 CVM 时发现 99p 时延抖动严重,定位发现是云主机之间存在 ping 抖动问题。

腾讯广告上云:架构设计与优化方案全解析

排查过程

第一步:查看 ping 抖动是否由网络造成?

采用同一个 VPC 的 CVM,排除网络影响。 ping 的同时进行 tcpdump 抓包,确认网络 ping 抖动来源于母机或者 CVM。

腾讯广告上云:架构设计与优化方案全解析

第二步:母机查看各种指标,暂时未发现异常。

第三步:查看子机相关指标,OS、CPU、网卡流量,以及查看 /proc/interrupts,最终发现是 tlinux1.2 OS 自带的 ethtool 工具版本太老,设置网卡多队列失败。

腾讯广告上云:架构设计与优化方案全解析

第四步:升级 OS 后在大流量时故障复现,经过查看母机和子机 CPU 占用率,怀疑子机 vCPU 和母机线程争抢 CPU 导致。

采取措施

第一步:升级 ethtool 工具或者升级 OS 为 tkernel2 内核、腾讯云部署 QOS 组件。

第二步:使用 DPDK(数据平面开发套件),母机隔离出 4 个逻辑核专门用于包转发。

  • 如何更新存量?
  • 如何保证增量正常?
  • 如何规范腾讯云上架流程?

腾讯广告上云:架构设计与优化方案全解析

(6)CPU 抖动引起雪崩

现象:经过 DPDK 优化的机型在某模块上使用时在晚高峰不定时发生 CPU 抖动,失败引发 L5 调度,进而引起该模块云主机雪崩。

腾讯广告上云:架构设计与优化方案全解析

定位过程

发生 CPU 高时,使用率超过 50%。

经过分析,发现 CVM 中的 CPU 和母机 CPU 并不是一一对应,在子机中的 CPU 使用率比较高时,由于母机侧的自动负载均衡,会导致 CPU 跨核调度,发生 cache missing,由于没有透传 L3 cache,也使得不能使用 L3 cache,导致频繁的上下文切换。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

(7) AMD CPU 性能优化

AMD 使用表现如下:

腾讯广告上云:架构设计与优化方案全解析

同压力时对比 intel 云主机, AMD 物理机耗时抖动严重,无法应用于线上,转而使用 AMD CVM(CVM 配置:90 逻辑 core,独占一 socket)。

定位与分析

AMD 处理器单路 48 个物理核,双路总计 192 个逻辑核(线程),两个 NUMA 节点。NUMA 非一致内存访问,经过分析广告检索模块的内存占用,结合 NUMA 的内存访问统计,数据主要都位于 node 1 (N1) 上。而 sunfish 有一半的检索线程运行在 node 0 的 core 上,对这部分线程 node1 的内存属于远端内存,因此访存速度缓慢。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

收益

采用单 node 的 AMD 云主机经过测试耗时比 CG1 低 25% 以上,而成本经过测算 AMD 单机成本是 intel CG1 的 60%,经过此次验证也说明了硬件架构贴近业务架构特征所带来的收益,来加速 AMD 的落地。

腾讯广告上云:架构设计与优化方案全解析

3. 上云对现网影响如何做到可控

(1)离线试错

在不影响线上系统运行的前提下,克隆真实的在线请求到离线环境实现线下试错,降低系统风险,无用户体验影响,快速支持新版本新环境上线。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

(2)灰度方案设计

广点通模块众多,不可能全部同时上云,为了服务切换的平滑稳定,做到用户无感知,主要考虑到云环境初期的各种风险,包括专线质量、服务延时、机型适配等诸多方面。

既要上云,也不能无谓踩坑。既要保证业务平稳运行,维持高可用性,云上环境有问题,可以随时禁用,全部切回自研环境。

腾讯广告上云:架构设计与优化方案全解析

机器维度

云主机适配物理机配置,压测后上线,如有异常及时剔除。

模块维度

针对 AMS 耗时要求严苛的情况,确定哪些模块先上,哪些模块后上,逐步上线各模块。

SET 维度

一个 SET 具有完整的请求处理路径,包含接入层 + 逻辑层,各个 SET 对请求的耗时要求不同,确定哪些 SET 先上云,做到按 SET 回滚。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

4. CBS 存储优化

CBS 的可用性主要通过网络块存储方式提供服务,分布式三副本提供保障。而 AMS 上云模块的数据应用模式采用大量的数据频繁地实时更新。

网络服务 + 三副本是在机制层面提高了可用性,可以减少我们很多运维的工作。但是新技术应用在一套磨合成熟的架构里面,肯定会引出新的问题,我们不应该抗拒新技术,有问题解决问题。下文主要讲一下新的问题及互相妥协的过程。

带宽,通过网络提供服务,大量数据的实时更新就意味着产生极大的网络流量,那网络带宽有可能代替磁盘 IO 成为了文件读写的瓶颈。

成本,频繁的数据更新,意味着数据是类似 cache 性质的,那么对于数据可用性的要求其实并不需要到达三副本的级别。

(1)带宽问题

核心矛盾主要在带宽指标上。业务侧诉求是带宽越大越好,物理机的写入速度可以达到 300MB/s,而文件传输工具的峰值速度一般是 200MB/s(1.6Gb/s)。CBS 的诉求是小带宽,默认带宽是 100MB/s。由于双方诉求相差过大,最终上线时是使用了个折中的速度 180MB/s。

腾讯广告上云:架构设计与优化方案全解析

物理机网络传输带宽情况

CBS 侧操作

由于高性能云硬盘的上限带宽达不到 180MB/s,最终使用了 SSD 云硬盘(上限 260MB/s)。然后再通过云盘打标签(APPID+ 硬盘空间大小)的方式来配置带宽限速 180MB/s。

腾讯广告上云:架构设计与优化方案全解析

业务侧操作

带宽 = 数据大小 / 传输时间。带宽已经被限定,传输时间决定了数据加载速度,业务的需求是越小越好,为了减少对业务的影响,能优化的主要方向就是数据大小。主要是通过了以下三个方式来减少云盘的写入量。

第一 :每次传输的数据文件从全量文件修改为增量文件,减少单次传输的数据大小,将传输时间打平。

第二 :中间文件直接在内存操作,传输过来的文件会有一个解压的中间状态,这个操作放在 /dev/shm 目录下操作,减少云盘的写入量。在使用大内存机型的条件下,这个操作可以减少几十 G 文件读写压力。

腾讯广告上云:架构设计与优化方案全解析

数据写内存后,IO 变化情况

第三 :减少灾备数据的传输,双数据源增加主备标识,备机判断主机存活的情况下不做数据发布的操作。由于原来双数据源是无状态互为容灾的架构,增加主备标识后,效果是数据写入量直接减半,代价是故障时,数据更新会延迟一次文件传输的时间。

腾讯广告上云:架构设计与优化方案全解析

通过以上三招,将平均写 I/O 从 100+MB/s 降到 30MB/s,每 30 分钟文件写量从 120GB 降到 50GB 左右。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

磁盘 IO 优化前后对比

(2)成本问题

我们上云的模块基本都是接入层和逻辑层,机器上的数据也基本都是无状态的 cache 性质数据。这种类型的数据更多是要求性能,而对可用性的要求做到 raid5 级别就可以了,三副本的存储成本太高了。但三副本是 CBS 的核心机制,这里可操作的空间不是很大,期间我们也是考虑过一些别的方案,最终也没有实现。

CFS 方案

我们的数据的读写模式本质是一写几千读,CFS 在理论上也能支持,而且更合适。但是经过成本测算,CFS 的成本会比 SSD 云盘成本更高,而且 CFS 的自研业务需求较少,不利于通过运营手段分摊并减少成本,最终该方案未实施。

单副本方案

CBS 的同学也在考虑单副本的方案,由于最终方案尚未确定下来,不过多讨论。主要列举一下,我们业务对于单副本方案的需求或者关注点。

  • 系统盘与数据盘分离;
  • 故障率做到与物理盘坏盘率相同水平;
  • 底层物理故障不应该影响大量 CVM;
  • 可以接受停机维护,但是如果因为全盘目录损坏导致需要重装系统,以重新构建一些系统级目录,运维成本过高,则意义不大。

综合以上,由于 CBS 的高可用性保障及可根据业务形态调整配置的特性,业务侧对 CBS 还是非常认可的。在运维效率提升及成本优化的过程中,起到了非常大的帮助。

5. 网络时延优化

问题:云主机至自研 IDC ping 时延过高。

  • 广州到深圳 5ms;
  • 上海宝信云到自研 IDC 4-5ms。

主要措施:

  • 部署 pvgw 设备;
  • 直通车网络优化项目。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

6. TKE 服务建设

由于 CVM 对于小核心业务提供能力不足,经常出现亲和度不够导致同业务下多个小核心 CVM 来自于同一台宿主机,增大了业务风险和容灾能力不足。所以开始接入公司的 TKE 服务,但由于 TKE 公有云没有和腾讯内部的很多自研系统(监控运维)及账号打通,所以对大多自研上云业务并非最好选择。

腾讯广告上云:架构设计与优化方案全解析

(1)平台选择

接触了公司已有的两款 TKE 平台:STKE 和 TKEstack。

两个平台的相似点在于,都是以 TKE 为基础来提供容器化服务的方案。但差异在于 STKE 是专为公司自研上云提供的 TKE 服务,打通了更多的公司内部服务。

TKEstack 更多的则是面向私有化场景,但加入了适用于大数据计算的场景,并且和服务类型的应用混合部署。而在广告内部存在着大量的离线模型计算,TKEstack 的场景更贴近广告业务。

腾讯广告上云:架构设计与优化方案全解析

(2)TKEstack 优势

  • 支持丰富的网络模式,大幅拓展了容器应用场景,满足复杂应用容器化的特殊需求;
  • 提供全维度弹性资源限制,使得容器的稳定性、集群资源利用率均得到提升;
  • 实现了 GPU 卡、GPU 显存的虚拟化功能,可有效提升用户 GPU 资源使用效率;
  • 结合腾讯十多年海量运营经验,全新设计出的一种全新的易用的应用类型;
  • 自带 P2P 分发功能的镜像仓库,可防止镜像服务网卡流量被占满,并可显著提升了拉取镜像的速度。

在运维侧,则实现了小核服务的按需分配(低负载管理)和快速扩容(自动扩容)等功能,在业务质量和成本管理中都有着显著的提升。

(3)镜像管理

镜像可兼容 CSIGHUB,gaiastack 仓库,蓝盾和 mirrors 平台,现基础镜像都以 mirrors 平台管理为主,已实现 AMS 广告公共基础镜像的仓库服务提供,已完成广告自有基础镜像搭建并已提交至业务侧使用。并已完成私有仓库与平台之间的凭证互通,可实现平台拉取私有镜像。

腾讯广告上云:架构设计与优化方案全解析

(4)容器化 CI/CD

容器化的持续化集成区别于普通 IDC 业务的持续化集成,因为容器化还增加一步镜像构建的动作,这块现有方案为 csighub 的 hook 功能和蓝盾的流水线功能,可以检测某个 git 仓库的地址,一旦发生 commit 动作就会触发自动构建。

自动构建的镜像为运维侧提供的基础镜像或者增加了业务基础环境的业务镜像(如 PHP、jdk 等)

容器化的持续化部署也与普通 IDC 业务有所不同,普通 IDC 业务是根据一个下发管道,来把代码包下发到业务机器上,然后进行迭代后重启(如织云)。但容器化的 CD 是把原先提供服务的 pod 进行销毁,再根据上述自动构建的镜像进行重启拉起,这样就实现了一次自动化部署。

腾讯广告上云:架构设计与优化方案全解析

四、容错容灾部署

由于播放链路的机器是多年来逐渐部署起来的,有着比较重的历史包袱。而早年间,整体链路的耗时压力并没有现在这么严峻,所以在条带化的部署架构设计时,只考虑了按业务流量性质的条带化部署,各个模块的机器部署在不同的 IDC 中。

腾讯广告上云:架构设计与优化方案全解析

随着多年的发展,功能模块越来越多,请求数据包大小逐渐增大(包大小增加 60KB,同城跨 IDC 耗时就会增加 1ms 左右)。

再看业务架构中的特点二、链路模块多 + 整体耗时控制严格。这导致整体链路中跨 IDC 访问耗时占比比较高,占比在 10% 以上。所以这次自研上云是一个很好的契机,重构业务部署架构,在保证可用性的前提下,尽可能通过就近部署减少网络访问耗时。

腾讯广告上云:架构设计与优化方案全解析

1. 部署原则

为了达到这个目标,在进行新的 Set 划分时主要是按照以下几个原则:

  • 每个地域选择两个容灾 IDC 。
  • 接入层混布,使用相同 L5/STGW,通过权重控制物理机与 CVM 间的流量对比,物理机后面接物理逻辑 Set,CVM 后面接云 Set 。这样流量在物理及云之间切换时,对流量侧就是无感知的。
  • 逻辑层按 IDC 就近部署,这个会导致机器部署的碎片程度增加,管理单元数量大幅上涨,所以相应内部 Set 管理系统也得进行更新迭代。
  • 数据在物理及云各部署一套,由于部署一套在线数据的成本非常高,只能物理及云各部署一套,无法做跨城容灾部署主要也是受限于这里。

2. 容灾方案

容灾设计的前提是接入层及逻辑层为无状态服务,三地的物理及云数据均为完备数据。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

按 IDC 部署的云 Set 上 线,耗时大幅下降,相比混布的物理 Set ,耗时下降 26%~35% 。

腾讯广告上云:架构设计与优化方案全解析

腾讯广告上云:架构设计与优化方案全解析

平均时延先后对比

五、收益

腾讯广告上云:架构设计与优化方案全解析

本文转载自公众号云加社区(ID:QcloudCommunity)。

原文链接

https://mp.weixin.qq.com/s/34zxjiXF6Rq5geVEw1eFvw

阅读数:1174 发布于:2020 年 8 月 4 日 14:06

更多 架构、运维、测试 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 云端架构最佳实践:与故障同舞,与伸缩共生

    云端架构需要处理和应对可能出现的故障,保证架构和服务的可用性;还需要充分利用好云端的弹性,要能根据负载进行灵活的伸缩。

    2020 年 3 月 18 日

  • QQ 是如何完成 20 万台服务器全量上云的?

    截止到目前,QQ所有的业务都已经迁移到了腾讯云上。

    2020 年 2 月 4 日

  • 京东 618:Docker 扛大旗,弹性伸缩成重点

    不知不觉中,年中的618和年终的11.11已经成为中国电商的两大促销日,当然,这两天也是一年中系统访问压力最大的两天。对于京东而言,618更是这一年中最大的一次考试,考点是系统的扩展性、稳定性、容灾能力、运维能力、紧急故障处理能力。弹性计算云是京东2015年研发部战略项目,它基于Docker简化了应用的部署和扩容,提高了系统的伸缩能力。目前京东的图片系统、单品页、频道页、风控系统、缓存、登录、团购、O2O、无线、拍拍等业务都已经运行在弹性计算云系统中。

    2015 年 6 月 17 日

  • 首次公开:腾讯云虚拟化技术原理及可用性提升实践

    虚拟化技术是云计算最核心的技术之一,也是云计算商业模式的底层支撑。海量服务器需要通过虚拟化的技术形成大的资源池,其重要性不言而喻。

    2020 年 6 月 24 日

  • 楚楚街 11.11:特色移动电商的大促技术演进之路

    今年9月9日~11日,楚楚街的99大促顺利完成,抗住了峰值订单数为平时订单数100倍、流量峰值为平常峰值的50倍的压力。99大促的顺利进行不仅为双十一大促打下了良好的基础,也收获了很多宝贵的经验。大促的顺利进行离不开技术的支持,本文来介绍一下,楚楚街针对今年的两场大促,做了哪些技术上的优化升级。

    2016 年 11 月 10 日

  • 当企业上云成“标配”,如何打造差异化竞争能力?

    一方面用户关心什么样的云迁移方案能够让自己快速实现转型和业务创新,一方面他们也关注原有数据中心会面临什么样的变化和挑战——用户在云服务提供商方面的选择越来越多,云服务提供商也更加关注如何通过差异化服务取得竞争优势。

    2018 年 6 月 11 日

  • 第 194 讲 | 刘俊强:2019 年云计算趋势对技术人员的影响

    学会有条理的梳理工作、对数据安全敏感、持续学习等良好的工作习惯,相信面对云计算带来的挑战也将游刃有余。

    2019 年 3 月 27 日

  • 微服务如何实现 DevOps?

    拆分为微服务之后,多个微服务都需要进行测试,测试通过了都需要把代码发布到线上,这时候就迫切需要一种新的开发、测试和运维模式来解决这些问题。

    2018 年 10 月 27 日

  • 高可用、弹性动态的金融级移动架构在蚂蚁金服的演进之路

    2019 年 1 月 2 日

  • 腾讯万台规模的 Docker 应用实践

    Docker提供了一种在安全、可重复的环境中自动部署软件的方式,拉开了基于云计算平台发布产品方式的变革序幕。腾讯内部对Docker有着广泛的使用,其基于Yarn的代号为Gaia的调度平台可以同时兼容Docker和非Docker类型的应用,并提供高并发任务调度和资源管理,它具有高度可伸缩性和可靠性,能够支持MR等离线业务。为了剖析Docker on Gaia背后的实现细节,InfoQ专访了腾讯数据平台部高级工程师罗韩梅。

    2015 年 3 月 19 日