返回 登录
1

亲历Intel CPU漏洞的正面袭击

作者简介:白冬立,热云数据创始人兼CEO,在大数据分析,挖掘与应用领域深耕10年。曾在Zynga全面负责Zynga北京的数据分析和数据系统的研发工作,并直接与美国总部CEO汇报(Zynga-昔日美国社交游戏巨头)。还曾任职于热酷游戏,担任架构师,负责搭建公司的核心数据仓库系统。

作为已经3年多没有写过代码的程序员来说,本篇不应该算是一篇技术型的文章,而是作为服务上千家客户的ToB大数据创业公司的一次经历,可能很多人对于我们的产品了解并不多,所以我先简单介绍下我们的技术和业务应用场景,我们有多个SaaS产品,有给游戏公司提供免费使用的游戏数据分析平台,有专门做效果广告监测的Ad Tracking系统,以及把移动广告监测和多维用户行为分析数据打通的TrackingIO系统,其中系统架构较为复杂的是TrackingIO,同时使用TrackingIO的客户也较多,每天的数据点数为几十亿的规模,而本文标题中提到的Intel CPU漏洞对于我们的几个SaaS产品均有影响,我主要以TrackingIO作为案例总结。

系统介绍

TrackingIO的技术架构方面,我们使用了典型的Haddop生态系统作为大数据架构基础,2016年我们使用混合云的方式部署的服务,2017年都迁移到了AWS,其中用户Log收集的服务我们早期使用Scribed和Flume但是发现均存在丢数据的情况,所以后来我们自己写了一套Java的分布式的日志收集系统,实时计算方面我们用典型的Kafka + Storm的流式计算架构,持久化的NoSql数据库一部分用了Redis,一部分用了AWS的DynamoDB,实时用户行为分析的部分是结合了Parquet+Kudu+Presto,离线计算用AWS EMR+Hive,另外离线数据挖掘的独立系统我们用了Spark,系统架构如下:

数据流向:

图片描述

整体架构:

图片描述

主要的业务场景

1,客户在客户端,或者服务器端接我们的Android、iOS、REST API的SDK,报送数据到我们的Log Receiver的Cluster。
2,Receiver的集群收到数据后做一些业务逻辑处理后,一部分数据落地到本地磁盘,一部分数据发送至Kafka集群。
3,Storm集群从Kafka读取数据后,做业务逻辑处理,其中一部分逻辑要读写Redis,一部分逻辑要读写Dynamo DB。
4,实时的多维用户行为分析MR程序从Kafka读取数据写入Kudu,并同步到Hive,离线的数据交给Parquet做批量模型处理,最后由Presto视图做数据合并。
5,离线的程序全部交给ETL系统做处理,本次不做介绍。

漏洞发现过程

我们的系统是部署在AWS上的,平时正常情况下,即便是每天在数据发送的高峰期间,Storm消耗Kafka集群的数据也不会有Message Lag,而1/4号从傍晚开始,我们的监控系统开始发现有Kafka数据堆积,很快数据挤压就超过了2亿条,如图所示:

图片描述

Kafka数据堆积的问题,可能由不同的因素引发,比如之前我们就遇到过Dynamo DB的读写并发高导致Storm的数据消耗慢的情况,除了Kafka数据的堆积,我们还发现Receiver Cluster也出现了整体处理性能的下降,Timeout等问题。

在数据流量没有异常增加的情况下,我们程序也没有做什么更新,出现这个现象,我们还是有诸多疑惑的,然而解决问题是首要任务,OPS给Storm的集群逐步增加了4倍的服务器,给Receiver Cluster增加了30%的服务器,Receiver的问题很快解决了,然而发现Kafka堆积的消耗还是没有快多少,反而挤压越来越多,数据消耗每10分钟只有不到500万条,从Redis的监控数据看连接数是上来了(如图),但Storm的Spout程序有很多超时发生。

图片描述

每个节点都增加了一些服务器后,到了凌晨3、4点钟整个集群数据在低谷的时候,Storm的消耗速度依然没有显著提升,我们OPS就开始怀疑是不是1月2号Google发布的Intel CPU漏洞的问题影响,但在凌晨我们无法和AWS确认技术细节,只能等到1/5号上班后,我们得到了AWS的确认,他们升级了Intel的CPU内核补丁来修复Intel CPU的漏洞,导致所有服务器的CPU性能均有下降,其中我们用的r3.large(3代CPU)的类型影响最大。

解决办法

在得到AWS官方确认后,我们将整个Redis集群使用的CPU类型升级到了r4.xlarge,同时增大了Redis集群服务器规模之后,Storm的消耗速度开始恢复,集群消耗Kafka的数据也提高到了每10分钟1200万条以上,监控来看数据积压开始下降,而因为积压数据量太大,导致zookeeper的集群压力也变大,中间我们还升级了一次zookeeper的磁盘空间,到了1/6号凌晨集群挤压的所有数据全部消耗完毕,数据无一条丢失,如下图:

图片描述

目前来看,解决本次Intel CPU漏洞的办法就是增加机器,对于CPU密集型或者依赖CPU缓存的服务则增加了更多服务器。(本案例基于服务部署在AWS上的情况)
如果没有用云服务,延迟修复Intel CPU漏洞,让服务器带着漏洞裸奔,也不会受此影响,但不排除有被黑客攻击,盗取数据的风险。

带来的影响:

1,我们服务的上千家客户均无法查看实时数据,导致所有正在投放广告的客户无法实时看到广告监测效果数据,对投放产生了明显的影响,时间之久是我们提供服务以来史无前例的。
2,因为整体CPU性能下降,导致我们整体计算能力下降,为了解决问题,不得不增加更多的计算单元,评估下来是这样的:
3,Redis整体计算能力,下降超过50%
4,Receiver Cluster等网络IO密集型服务,下降30%
5,编译执行的程序,下降20%左右
6,其他服务器,下降5%左右

为什么Redis性能下降如此明显:

一方面是因为AWS的第三代Intel CPU受漏洞影响最为严重,性能下降最多,另外一方面,Redis的设计是特别依赖CPU的2、3级缓存来提升性能的,本次Intel CPU漏洞补丁修复后,导致CPU的缓存能力下降,从而影响Redis的性能(这块还需要深入做专业度更强的技术研究)

关于Intel CPU漏洞:

原始文章:(需要翻墙)
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

如何看待 2018 年 1 月 2 日爆出的 Intel CPU 设计漏洞?
https://www.zhihu.com/question/265012502/answer/289320187?utm_medium=social&utm_source=wechat_session&from=timeline&isappinstalled=0

详解Intel漏洞怎么拿到内核数据的:
https://mp.weixin.qq.com/s/2OBig3rejp1yUupBH9O7FA

比较专业的分析Meltdown和Spectre漏洞的文章:
1. https://meltdownattack.com/meltdown.pdf
2. https://spectreattack.com/spectre.pdf
3. https://securitytracker.com/id/1040071

结语

从本次漏洞产生的影响来看,我们的系统架构还有很多需要完善的地方,而这种CPU级别的漏洞对于全球的计算机、互联网行业均带来的影响还是很可怕的,还是希望各个公司的IT部门尽快修复此Bug,防止潜在的攻击带来更大的损失。

最后感谢我们所有客户的理解和支持,我们将一如既往提供越来越完善的大数据产品和服务!在应对突发问题上相信我们的工程师团队能够做的越来越好。

评论