写点什么

性能提升 20%,字节跳动 HTTPDNS 从中心下沉到边缘

  • 2024-07-30
    北京
  • 本文字数:3259 字

    阅读完需:约 11 分钟

大小:1.77M时长:10:18
性能提升20%,字节跳动HTTPDNS从中心下沉到边缘

摘要:本文介绍了 HTTPDNS 服务从中心迁移至边缘详细的落地过程。主要内容为:

  • HTTPDNS 下沉边缘实践遇到的挑战,包括服务放置、流量调度

  • HTTPDNS 下沉边缘解决方案

  • 从性能、成本出发,谈谈 HTTPDNS 下沉边缘后的收益


传统的 DNS 流程中,客户端基于 UDP 协议向 Local DNS 服务器发送 DNS 查询请求,这个过程中会存在缓存刷新不可控、DNS 劫持、解析结果跨网、解析超时等风险,近年来,HTTPDNS 解决方案逐渐兴起。HTTPDNS 是面向多端应用(移动端 APP,PC 客户端应用)的域名解析服务,通过使用 HTTP 或 HTTPS 协议替代传统的 UDP 协议,客户端的域名解析请求直接由 HTTPDNS 服务器接收和响应,实现了域名防劫持、精准调度、解析结果及时生效


以字节跳动内部业务为例,如抖音、今日头条、西瓜视频和番茄小说等,QPS 峰值达千万级,解析请求量日达万亿次,日常流量极大,为保障业务稳定运行,应用了火山引擎移动解析 HTTPDNS(以下简称 HTTPDNS)为域名提供递归 DNS 服务,支撑起超大解析请求量。


由于 HTTPDNS 服务全面覆盖字节跳动头部 APP,在节约成本以及性能优化上存在强烈诉求,在此背景下 HTTPDNS 团队经过调研,决定将 HTTPDNS 服务从中心迁移至边缘,以下将从实践难点、解决方案和收益多个维度分享详细落地过程。


一、HTTPDNS 下沉边缘实践挑战


1.服务放置


由于边缘计算节点分散、基础设施异构等原因,边缘服务放置一度成为下沉边缘过程中的研究热点,现有方案在处理边缘放置问题时,会将其转化为指定场景下资源约束的目标优化问题,针对成本、质量、流量方向,行业内均有对应研究:


  • 针对成本,有研究通过多云的模式进行最小冗余成本建模,来实现资源动态分配。

  • 针对质量,有研究通过构建服务依赖模型、最佳冗余动态算法保障可靠性,以及成本和质量均衡模型,来实现质量保障。

  • 针对流量,有研究从流量迁移、设备移动、时空轨迹以及资源预部署等,实现流量稳定迁移。


在实际应用过程中,流量及设备迁移特征显著、边缘节点性能差异、稳定性波动大等因素,会干扰现有放置问题模型,因此需要进一步探索基于流量特征和边缘节点资源质量的放置问题


2.流量调度


边缘计算的流量调度场景主要分为端边调度和云边调度,部分场景会出现边边调度。不同调度阶段拥有相对成熟的调度技术,包括基于 DNS 的端边调度、基于 BGP ANYCAST 的骨干网路由调度以及云网络下的云原生流量调度。



实践过程中面临的流量调度挑战,主要围绕着端边调度和云边调度:


  • 端边调度挑战:5G 和工业互联网接入的大量异构设备,以及设备迁移导致的流量波动,是端边调度需要应对的主要挑战。解决这一问题可借助云边协同作业与全局分布式调度的策略。然而,实际操作遇到的难题主要在于缺乏精确的调度手段,并且未能充分利用客户端与边缘节点之间协同联动的潜力。尽管通过实时流量感知配合机器学习进行训练是一种可行的方法,但这种方案处理的数据量巨大,导致应用成本过高,难以满足现实需求。

  • 云边调度挑战:边缘计算由于其固有特性,在处理大规模集中式数据方面相较于传统中心化架构存在一定局限性。因此,云边协同的流量处理和计算模式采纳了业界广泛认可的计算架构,云边调度发挥了云计算与边缘计算各自的优势,达成数据和流量的更高效处理。然而,边缘计算在资源分配上仍面临局部不足与全局分散的挑战。举例来说,在约束优化路由模型中,评价指标有时与实际业务场景不符,未能充分考虑用户体验。此外,行业内某些区域分层调度模型在实际应用中遇到了边缘基础设施不统一的问题,同时区域内及区域间的容灾问题也尤为突出。


二、HTTPDNS 下沉边缘解决方案


1.可视化评价模型指导服务放置


针对基于流量特征和边缘节点资源质量的放置问题,在实践过程方案,HTTPDNS 团队不断进行尝试优化,最终选择通过使用全链路的拨测和数据采集方法,基于实时数据驱动的模式,进行在线的放置算法仿真训练,形成可视化的评价模型,以指导 HTTPDNS 服务在边缘机房的节点选择和服务放置。基本流程如下图:



2.接入 GTM 打造调度解决方案


针对流量调度挑战,由于内部服务采用域名(配合兜底策略)的接入方式,接入域名配置 DNS 智能解析实现用户就近访问边缘接入节点。考虑到边缘接入节点 IP 的网络服务可靠性和质量对比 IDC 机房优势不明显,因此 HTTPDNS 团队最终决定引入云调度 GTM 解决调度问题。


火山引擎云调度 GTM 基于解析进行流量调度,可以实现流量的就近接入(地理位置/性能)、负载均衡。GTM 借助分布式、多协议健康检查能力来实现故障容灾(Failover),诸如“同城容灾”、“异地多活”等场景。此外 GTM 还提供了多云环境下的流量编排、资源粘合能力,可视化的健康检查数据分析、操作日志等功能帮助排查定位问题,便于日常运维。


想了解更多云调度 GTM 的小伙伴可以点击这里:


重点应用:


  • 智能调度:通过云调度 GTM 的「智能调度-容量优先」模式实现基于机房容量的智能调度,在满足机房容量的前提下生成全局时延最低的 DNS 调度规则,从而能够在边缘节点割接/故障时实现自动容灾;

  • 故障容灾:支持边缘节点通过控制台、API 接口和 Agent 的方式上报节点容量等信息,基于节点的数据上报情况和健康检查探测的情况,云调度 GTM 作为策略中心更新和下发调度策略,实现边缘节点的故障容灾。



调度解决方案优势:

  • 建设成本低:部署轻量,架构侵入较小,建设成本较低;整体配置和管理简单;

  • 动态调度保障性能最优:在边缘多节点、多机房的场景下,能够基于性能和容量进行动态调度,在确保机房水位低于目标水位的前提下实现全局性能最优;

  • 支持可视化:支持调度配置和结果的可视化展示、健康检查可视化查询。




应用火山引擎云调度 GTM 来实现容量调度是一次新的尝试,在全面接入云调度 GTM 之后,对比传统域名智能解析调度模式,边缘节点容量调度模式能从性能、容灾、成本等方面带来收益,也验证了云调度 GTM 在方案中不可或缺的重要性。


调度解决方案收益:

指标类型指标收益总结
性能请求时延平均接入时延 -5.01%(-11ms)整体延时优化5%
流量调度漂移减少 15%
请求成功率持平
TTFB平均 TTFB -4.1%(-3.5ms)
流量波动cpu负载波动标准差:5%->1%,优化80%
容灾自动容灾成功率100%智能解析线路级故障感知
60 秒自动容灾
边缘故障感知耗时60s
流量收敛时长3min 90%+收敛
成本带宽成本回源带宽降低 10%运维:配置、切流管理,完全自动托管
容灾:从预案模式10分钟, 到自动容灾1 分钟
资源成本:cpu冗余量可减少 20%
成本运维成本易用:基于容量&性能矩阵,均匀分流。仅需要用户维护机房容量信息。

好用:火山控制台一键完成调度策略计算,流量调度结果支持可视化。机房故障自动重调度,机房裁撤一键完成流量重分配。

复杂场景支持:新建机房快速完成接入调度。大面积故障场景容灾自动化高。


三、更强大的解析调度,性能提升 20%+


实践过程持续了六个月时间,在成本优化与性能提升方面均取得显著效果。


1.成本优化


总成本优化约 35%,其中负载均衡资源优化约 50%,计算资源优化约 30%,带宽成本优化约 70%,且最终实现了边缘集群总容量千万 QPS 级别,与中心机房完全互备。


2.性能提升


完成从中心到边缘的迁移后,火山引擎移动解析 HTTPDNS 服务性能出现显著提升,对比同类服务出现显著优势。


在边缘服务建设完成后,我们逐步将原中心机房承载的千万 QPS 级别流量迁移到边缘服务集群上。根据实际的性能提升情况, 先后将全国大部分区域的三大运营商接入流量迁移到边缘。在这个过程中,我们关注并采集流量的网络指标变化数据,各个区域均有性能收益,详见下表:


下沉区域总耗时-平均值-差异百分比(%)总耗时-50分位-差异百分比(%)TTFB-平均值-差异百分比(%)TTFB-50分位-差异百分比(%)
西南-15-44-38-64
西北-16-36-36-47
东北-10-14-15-23
华北-16-41-29-63
华中-23-50-37-70
华南-7-15-11-36


为了能够更直观感受火山引擎移动解析 HTTPDNS 服务与其他 HTTPDNS 服务的性能数据对比,我们使用国内主流的第三方拨测平台,进行了近千个拨测节点、覆盖全国的拨测对比。从拨测结果可以看出,不论是从地理位置上,还是分运营商讨论,火山引擎移动解析 HTTPDNS 都在首屏时间、建立连接时间、首包时间和内容下载时间上表现优异,最终实现总下载时间实现领先。


全国:

厂商总下载时间(s)首屏时间(s)建立连接时间(s)首包时间(s)内容下载时间(s)
火山 HTTPDNS0.2520.2540.0240.0260.037
其他-1 HTTPDNS0.2790.2820.0350.040.039
其他-2 HTTPDNS0.3270.3290.050.0630.039


分运营商:

运营商厂商总下载时间(s)首屏时间(s)建立连接时间(s)首包时间(s)内容下载时间(s)
中国电信火山 HTTPDNS0.260.2630.0230.0270.031
中国联通火山 HTTPDNS0.2420.2440.0240.0260.04
中国移动火山 HTTPDNS0.2560.2570.0240.0260.038
中国电信其他-1 HTTPDNS0.2870.2910.0340.040.034
中国联通其他-1 HTTPDNS0.2720.2750.0360.0410.043
中国移动其他-1 HTTPDNS0.2790.280.0360.0380.041
中国电信其他-2 HTTPDNS0.330.3330.0490.0610.033
中国联通其他-2 HTTPDNS0.330.3320.0530.0680.043
中国移动其他-2 HTTPDNS0.320.3210.0490.060.041


总结


整体下沉实践方案中,HTTPDNS 团队不断进行新尝试,探索并应用了基于 GTM 的反馈式调度模型,更好地应对了边缘计算资源局部紧张、全局分散以及稳定性抖动频繁的挑战,从而弱化边缘放置问题带来的资源开销,并提升流量调度效率、资源利用率以及降低容灾和运维难度。


通过下沉边缘,HTTPDNS 进一步优化使用成本,提升服务性能,而此次实践通过将 HTTPDNS 服务从中心云架构迁移至边缘云架构模式,使边缘计算在互联网传统业务场景中得到应用,也是边缘云云原生的一次工程探索实践。


本项目应用了火山引擎边缘计算多个产品服务,不仅使用了边缘网络提供的四、七层负载均衡产品,还将 HTTPDNS 服务全部运行在边缘容器上,通过弹性公网 IP 完成边缘服务的回源以及控制。HTTPDNS 联动边缘计算打造的下沉边缘实践案例,作为行业实践,希望为同行业提供一些有益参考。



未来,HTTPDNS 团队将持续探索边缘计算容器化弹性调度技术的应用,应对亿级接入、千万 QPS 流量所带来的流量迁移、接入抖动问题,并进一步提升设备利用率并节约成本。

2024-07-30 11:574782

评论

发布
暂无评论
发现更多内容

Architecture Phase1 Week7:Summarize

phylony-lu

极客大学架构师训练营

JVM真香系列:轻松理解class文件到虚拟机(上)

田维常

JVM

架构师训练营第三周作业

leo

极客大学架构师训练营

设计模式

小黄鱼

极客大学架构师训练营

[架构师训练营第 1 期] 第七周学习总结

猫切切切切切

极客大学架构师训练营

应用实战——数据库设计时设计标识字段的一些思考【mysql】

老农小江

数据库设计 实战

[架构师训练营第 1 期] 第七周命题作业

猫切切切切切

极客大学架构师训练营

Week3作业一

幸福小子

单例模式

架构师训练营第 1 期 -第七周作业

睁眼看世界

极客大学架构师训练营

第七周总结

fmouse

极客大学架构师训练营

7.7 第七周课后练习

张荣召

架构 2 期 - 第三周作业(1)

浮生一梦

极客大学架构师训练营 第三章作业 2组

架构师训练营—第七周作业

Geek_shu1988

架构师训练营第七周课程笔记及心得

Airs

第七周作业

Geek_ce484f

极客大学架构师训练营

第三章课后作业

博博

week07作业

龙卷风

架构师一期

第七周作业

fmouse

极客大学架构师训练营

《Java并发编程的艺术》.pdf

田维常

电子书

【第七周】课后作业

云龙

架构师训练营第三周学习笔记

李日盛

设计模式

《一本小小的MyBatis源码分析书》.pdf

田维常

电子书

组合模式

猴子胖胖

设计模式 Go 语言

性能优化一第七周作业「架构师训练营第 1 期」

天天向善

性能测试中并发量与响应时间和吞吐量的关系

天天向上

极客大学架构师训练营

架构一期第七周作业

Airs

第七周作业总结

Geek_ce484f

极客大学架构师训练营

多团队如何评估故事点(译) ——来自Mike Cohn的建议

Bruce Talk

敏捷开发 Agile 估算与计划

JVM真香系列:轻松理解class文件到虚拟机(下)

田维常

JVM

架构师训练营—第七周学习总结

Geek_shu1988

极客大学架构师训练营

Week3小结

幸福小子

设计模式

性能提升20%,字节跳动HTTPDNS从中心下沉到边缘_字节跳动_火山引擎_InfoQ精选文章