最佳实践:阿里云倚天ECS在千寻位置时空智能服务的规模化应用

本文涉及的产品
云服务器 ECS,每月免费额度200元 3个月
云服务器ECS,u1 2核4GB 1个月
简介: 阿里云、平头哥及安谋科技联合举办的飞天技术沙龙探讨了倚天Arm架构在业务创新中的应用。活动中,千寻位置运维专家分享了将核心业务迁移到倚天处理器ECS实例的成功案例,强调了倚天处理器的高能效比和降本增效优势。迁移过程涉及操作系统、CICD系统和监控系统的适配,以及业务系统的性能测试。目前,千寻已迁移了上千台ECS实例到倚天处理器,实现了成本和效率的显著提升。未来计划继续扩展倚天处理器在核心业务和K8S中的应用。

5月16日,由阿里云、平头哥及安谋科技共同主办的飞天技术沙龙《业务创新新选择,倚天Arm架构深入探索》在上海成功举行。来自阿里云、平头哥及安谋科技的专家为现场观众深入解读了Arm架构的核心优势,并重点分享了基于倚天710的计算实例g8y在大数据和视频领域优化的最佳实践,以帮助企业用户了解倚天ECS实例如何在成本、效率方面提供助力。



图:千寻位置运维专家李轲韡


现场,千寻位置运维专家李轲韡分享了《阿里云倚天在时空智能服务上的规模化应用》主题演讲,重点分享了千寻位置的核心业务迁移至倚天ECS实例的最佳实践以及迁移的经验,以下内容根据他的演讲整理而成。


我是来自千寻的李轲韡。今天很高兴和大家分享千寻位置在迁移倚天处理器ECS实例背后的故事。现在千寻已经有上千台ECS实例运行在倚天处理器上。


一、为什么要迁移到倚天处理器



很简单,降本增效。倚天处理器是一个能效非常高的处理器,用少量的研发资源投入,实现一个比较高性价比的产出,通过这种技术的演进路线,可以有效降低阿里云上的云资源成本。


接下来介绍整体的迁移步骤,首先是支撑系统的准备,包括调研操作系统、选型、基本的适配工作。


第二是CICD系统的适配,也就是CICD系统需要兼容ARM架构和X86架构。运维和开发操作ECS时,不应该关注ECS到底是ARM还是X86,系统应该能够自动处理掉。


第三是监控系统的适配,倚天处理器的ECS上在做基础指标的采集时,有一定的适配工作。


完成了基础系统的准备工作后,就可以做业务系统的准备。我们知道C++代码在X86和ARM处理器上要重新编译,而绝大多数的Java代码可以直接使用,所以需要把所有和处理器架构相关的代码做重新编译。


接下来对功能进行完整的回归测试,做必要的性能上的压力测试,业务系统也准备就绪了。


最后是迁移的策略,千寻在制定迁移策略时有两个假设。第一,对于自研系统,只要投入足够多的人力是一定可以迁移的。第二,对同一份代码,无论运行的ECS实例数是多少,投入迁移的人力成本是差不多的。基于这两点假设,我们制定了迁移策略。


把相同代码的ECS实例的费用做了排序,当同样一份代码运行的ECS所花掉的钱越多,就越先迁移。从金额由高到低逐步迁移,最后定了一个比例,当百分之多少的应用全部迁移完,就完成了。把目标和策略定完后,开始逐步迁移工作。



二、迁移前准备工作


下面是准备工作中遇到的具体情况。


首先基础环境的准备。之前用的是阿里云的六代ECS,Intel Xeon Platinum 8269CY的CPU,目标是倚天710。操作系统原来用的是Alibaba Cloud Linux 2,在阿里云的ECS上使用Alibaba Cloud Linux可以获得阿里云免费的商业支持,在操作系统的层面遇到的问题,阿里云会支持的相对好一些,所以千寻一直选用这个操作系统。




在倚天710上,阿里云唯一官方商业支持的操作系统是Alibaba Cloud Linux 3,考虑到Alibaba Cloud Linux 2明年三月份就会终止生命周期,借着迁移倚天710的机会,把操作系统从Alibaba Cloud Linux 2升级到了Alibaba Cloud Linux 3。


接下来是JDK,原来在X86实例上千寻用的JDK是Oracle JDK的1.8.0_192版本,也就是1.8系列的最后一个免费版本,后面的版本都是收费的。在ARM上换成了OpenJDK,更换的理由在后面PPT详细介绍。



上图展示的是性能对比测试数据。这是千寻的C++应用,上面两条曲线是X86处理器,下面两条是ARM处理器。上面两条曲线的平均值分别是47%和41%,下面两条都是26%,可以看到性能提升都超过50%以上。



这是纯Java应用的一个性能对比测试。ARM处理器在同样的CPU核心数下,它的性能略低一点。ARM处理器的CPU占用率是69%,X86的CPU占用率是64%。



为什么要更换OpenJDK?因为Oracle JDK的最后一个免费版本在ARM处理器上没有G1 GC特性的。因为千寻的业务对数据延时非常敏感,当没有G1 GC支持时,数据延时的波动在一秒以上,下面这个图在使用了OpenJDK开启了G1 GC的特性后,整个数据延时在200ms左右。为了保证业务的低延时特性,我们在ARM处理器上更换成了OpenJDK。


接下来是迁移过程中碰到的一个现象。Linux内核是每隔五秒采集一次负载,每采集一次负载会消耗掉一个CPU时间片的时间。当负载采样时,它是根据滑动窗口逐步滑动的,比如第一个时间片,后面第二个时间片,经过若干次采样后,会回到最早采样的时间点。


千寻的业务特性是秒脉冲,所有的服务器在每一秒的前几个时间片里都特别忙,在每一秒的后面的时间片都特别闲。在X86处理器上CPU的时间片默认是一毫秒,这导致每隔1毫秒,5秒采一次,也就是5000秒,大概83分钟,每隔83分钟会有一个负载波动的周期。



在ARM处理器上时间片默认是四毫秒,只需要250次采样就完成一个负载周期,也就是1250秒,大概是21分钟不到。我们看到系统的负载波动没有变化,但是在ARM处理器上,负载波动曲线频率是X86处理器上的4倍。这只是一个现象,不代表任何问题,开发团队关注到了并分析了原因。



接下来是要关注的问题。左边是一段示例代码,可以看到它的行为,在test load的方法里面正常应该返回一个布朗值。在if条件没有触发时,没有写return true。在main方法里面调用两次,正常情况下第一次应该能够执行并且打一条信息,第二次不会进入if的条件。在老的X86处理器的平台上,Alibaba Cloud Linux 2以及GCC 7版本的编译器发现无论有没有return true,编译结果和执行结果没有任何区别。


在GCC 10上,编译的时候会提示一个警告,函数不应该返回为空。在X86上可以看到,它会运行两次,错误地进入两次if条件,然后出现一个段错误。在ARM处理器上进入一次后,程序卡住了。过了一会儿被系统OOM杀掉了。注意一些老的代码可能会遗漏return,在老的编译器上没有任何问题的情况下,使用新的GCC 10编译时,如果看到返回函数有一个返回类型的警告,一定要把警告处理掉。


否则会出现各种各样奇怪的问题。这里举的例子,一个段错误,一个OOM被杀掉。我们看到在开启O3编译时,最后的main方法,return被编译器丢掉了,导致整个执行栈进入到错误的堆栈中,把一些正确定义的变量写坏掉,会出现各种奇怪的现象,所以这种类型的编译警告一定要处理掉。


三、正式迁移


上面是所有的准备工作,接下来是正式迁移。



这是千寻位置核心业务迁移的时间线。今年4月份开始做初步的调研工作。在倚天处理器的ECS上做了一些基本工作。5月份在测试环境进行完整的功能测试,同时做了一定规模的性能测试。6月份其中一条核心业务线的生产ECS替换了50%的ECS为倚天处理器实例,运行了一段时间没有问题。


7月份把这条业务线所有的ECS全部替换成倚天处理器实例。8月份发现这条业务线跑的没问题,所以其他业务线开始逐步推广适配倚天ECS。9月份其他业务线逐步在生产环境做50%的替换,这个替换工作现在还在持续进行中。



下面是一个性价比的测算。这边挑了两个场景,分别是千寻的业务对于倚天处理器最友好的场景和最不友好的场景。原来用的是第6代的C6系列,和C8Y系列做对比,同样是8核16G的ECS,第一个场景C++,40G的磁盘。倚天处理器的ECS只能购买ESSD,原来用的高效云盘,所以磁盘的成本会高一些。


价格是官网原价,没有任何折扣。原来C6的实例是762元,倚天是532.5元。性能基准C++的话,倚天的性能基准在C++场景大概是原来C6实例的1.46倍,整体性价比提升在100%以上。也就是原来用X86的ECS 1000元能干完的事情,换成倚天只要不到500元。


下面是一个纯Java应用场景。它的磁盘也比较大,它的ESSD会花更多钱,价格差距没那么大,888元和712.5元。因为Java的基准性能ARM会略低,所以整个性价比提升在15%以上。C6的1000元能干完的事,换成倚天的不到850元。这两个场景相对比较极端,千寻平均换倚天的收益是多少?大概是30%以上。



接下来是几点注意事项。


第一是后面的分享中会提到Easy Yitian的工具,可以帮助快速评估程序迁移倚天处理器的兼容性。

第二是周边的配套系统。为了配套整个倚天ECS相关的业务系统生产环境,CICD和监控系统要提前进行准备和测试工作。

第三是拉长时间线,灰度迁移。因为操作系统和JDK版本都换掉了,灰度迁移可以尽可能把问题提前暴露出来,降低影响。


因为整个迁移过程拉的比较长,在这个过程中,所有的X86和ARM的测试环境和CICD的环境是需要长期共存的。比如一个应用迁了半年才迁完,这半年中,每发布一个版本,所有的X86和ARM版本要分别测一遍,直到最后一台X86的生产服务器下线,全部换成ARM。


接下来是ECS宿主机的打散度。千寻现在有上千台倚天ECS实例,但是阿里云倚天处理器的宿主机,相比于X86处理器的宿主机数量比较少,虽然X86和倚天整个底层的故障率没有区别,但是千寻实例相对比较多,在倚天处理器的宿主机上,可能一台宿主机上跑了3台,5台,6台千寻的实例。


如果一台宿主机发生故障,千寻业务可能感受比较明显。如果涉及到比较大量的倚天ECS的迁移,建议和阿里云提前沟通好ECS在宿主机上的打散度怎么样。另外阿里云提供了一个ECS部署集功能,可以强制把ECS打散到不同的宿主机上,这部分可以根据迁移时的情况和阿里云沟通。


最后是我们验证发现ARM处理器在上下文切换场景特别多的情况下,性能会下降。这部分可能从业务上考虑,尽可能避免上下文切换。


四、后续计划



在后续计划中,首先千寻会继续迁移核心业务到倚天处理器的实例,希望把核心业务全部迁移到基于倚天的处理器的ECS实例上。第二点考虑把K8S的worker也迁移到基于倚天处理器ECS实例。


第三点是RDS经济版,基于倚天的RDS只有MySQL 8.0,目前千寻还有很多业务跑在5.6、 5.7上,需要做完改造后,再往RDS经济版上迁。最后千寻对外输出的项目能否借鉴倚天处理器的迁移经验。


以上就是本次分享的全部内容。

相关实践学习
一小时快速掌握 SQL 语法
本实验带您学习SQL的基础语法,快速入门SQL。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2天前
|
弹性计算 运维 安全
阿里云ecs使用体验
整了台服务器部署项目上线
|
3天前
|
弹性计算
阿里云ECS的使用心得
本文主要讲述了我是如何了解到ECS,使用ECS的一些经验,以及自己的感悟心得
|
4天前
|
弹性计算
阿里云ECS使用体验
在申请高校学生免费体验阿里云ECS云服务器后的一些使用体验和感受。
|
4天前
|
弹性计算
阿里云ECS的使用心得
本文主要讲述了我是如何了解到ECS,使用ECS的一些经验,以及自己的感悟心得
|
4天前
|
弹性计算 网络协议 Serverless
Serverless 应用引擎操作报错合集之使用ecs,反代到函数的内网域名上,提示{"ErrorCode":"DomainNameNotFound",是什么原因
Serverless 应用引擎(SAE)是阿里云提供的Serverless PaaS平台,支持Spring Cloud、Dubbo、HSF等主流微服务框架,简化应用的部署、运维和弹性伸缩。在使用SAE过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
5天前
|
弹性计算 运维 安全
阿里云ecs使用体验
整了台服务器部署项目上线
|
6天前
|
弹性计算
阿里云ECS的使用心得
本文主要讲述了我是如何了解到ECS,使用ECS的一些经验,以及自己的感悟心得
|
7天前
|
弹性计算
阿里云ECS使用体验
在申请高校学生免费体验阿里云ECS云服务器后的一些使用体验和感受。
|
7天前
|
弹性计算
阿里云ECS的使用心得
本文主要讲述了我是如何了解到ECS,使用ECS的一些经验,以及自己的感悟心得
|
8天前
|
运维 监控 搜索推荐
客户案例 | 阿里云向量检索 Milvus 版在识货电商检索场景的应用与实践
本文分享了阿里云向量检索 Milvus 版在识货电商检索场景的应用与实践。阿里云的 Milvus 服务以其性能稳定和功能多样化的向量检索能力,为识货团队在电商领域的向量检索场景中搭建业务系统提供了强有力的支持。

相关产品

  • 云服务器 ECS