亲历Intel CPU漏洞的正面袭击

Posted 2020-10-20

作为已经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性能下降，导致我们整体计算能力下降，为了解决问题，不得不增加更多的计算单元，评估下来是这样的：
2.1，Redis整体计算能力，下降超过50%
2.2，Receiver Cluster等网络IO密集型服务，下降30%
2.3，编译执行的程序，下降20%左右
2.4，其他服务器，下降5%左右

为什么Redis性能下降如此明显：
1方面是因为AWS的第三代Intel CPU受漏洞影响最为严重，性能下降最多，另外1方面，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，防止潜在的攻击带来更大的损失。

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