数据库全量SQL分析与审计系统性能优化之旅

• 1 背景

• 2 现状及挑战

• 3 分析及优化

  • 3.1 数据采集端介绍

  • 3.2 基础性能测试

  • 3.3 CPU画像分析

  • 3.4 脱敏分析及改进

  • 3.5 调度分析及改进

  • 3.6 垃圾回收压力分析及改进

  • 3.7 解包分析及改进

• 4 最终成果

• 5 未来规划

• 本文作者

• 招聘信息

1 背景

数据库安全一直是美团信息安全团队和数据库团队非常注重的领域，但由于历史原因，对数据库的访问只具备采样审计能力，导致对于一些攻击事件无法快速地发现、定损和优化。安全团队根据历史经验，发现攻击访问数据库基本上都存在着某些特征，经常会使用一些特定SQL，我们希望通过对MySQL访问流量进行全量分析，识别出惯用SQL，在数据库安全性上做到有的放矢。

2 现状及挑战

下图是采样MySQL审计系统的架构图，数据采集端基于pcap抓包方式实现，数据处理端选用美团大数据中心的日志接入方案。所有MySQL实例都部署了用于采集MySQL相关数据的rds-agent、日志收集的log-agent。rds-agent抓取到MySQL访问数据，通过log-agent上报到日志接收端，为了减少延时，上报端与接收端间做了同机房调度优化。日志接收端把数据写入到约定的Kafka中，安全团队通过Storm实时消费Kafka分析出攻击事件，并定期拉数据持久化到Hive中。

我们发现，通常被攻击的都是一些核心MySQL集群。经统计发现，这些集群单机最大QPS的9995线约5万次左右。rds-agent作为MySQL机器上的一个寄生进程，为了宿主稳定性，资源控制也极为重要。为了评估rds-agent在高QPS下的表现，我们用Sysbench对MySQL进行压测，观察在不同QPS下rds-agent抓取的数据丢失率和CPU消耗情况，从下面的压测数据来看结果比较糟糕：

如何在高QPS下保证较低的丢失率与CPU消耗？已经成为当前系统的一个亟待解决的难题与挑战。

3 分析及优化

下面主要介绍围绕丢失率与CPU消耗这