使用 Apache Spark 和 Amazon EMR 优化 Threat Stack 的数据管道

Threat Stack 每天收集数百亿个事件，帮助客户了解他们的环境，识别不良活动，并增强他们的安全态势。 这些数据来自不同的操作系统、容器、云提供商API 和其他来源。 我们处理所有这些数据的效率越高，我们能为客户提供的价值就越大。

在这篇文章中，我提供了一些有关 Threat Stack 数据管道前后状态的背景信息，这使我们能够提高平台的稳定性并提高运营效率。

运营数据平台

Threat Stack 具有可扩展且强大的后端系统，可以高吞吐量处理数据，从而实现近乎实时的安全威胁检测。 为了支持这种详细的安全数据流，Threat Stack 平台被分解为许多专门的微服务。 随着客户群的增长，这种架构使我们的数据管道基础设施能够轻松地水平扩展，并通过在专用服务之间划分不同的数据处理职责来简化问题的故障排除。

Threat Stack 工程团队通常会在平台效率低下或潜在的可扩展性问题成为面向客户的问题之前解决它们。 此外，如果工程团队的成员半夜接到呼叫，我们会找出问题所在，提出扩展计划，并实施补救措施。 系统中断会造成巨大的人力和机会成本，使团队无法专注于能够为客户带来额外价值的新项目。 在 Threat Stack，我们认真对待系统健康及其与人类影响的相关性，并尽最大努力保持我们的工程团队健康和高效。

我们最新的投资领域之一是威胁堆栈数据平台，它使客户和内部用户能够以报告、分析和机器学习等令人兴奋的新方式利用安全遥测。

数据平台由存储层和一系列服务组成，这些服务提取、处理和使用存储的数据来支持各种分析并实现我们的数据可移植性功能。 借助 Threat Stack 数据可移植性，客户可以从我们的平台导出丰富的安全遥测数据，并将其加载到他们自己的系统中，例如用于 SIEM 的 Splunk、用于数据仓库的 Amazon Redshift 或用于深度存档的 Amazon S3 Glacier。 这些数据还能帮助我们的 Cloud SecOps Program℠ 中的安全分析师（他们全天候负责 SOC）监控客户环境并识别可疑活动模式。

为了本文的目的，我们将重点讨论数据平台的数据可移植性方面。 数据可移植性由多项服务操作，这些服务从数据平台检索和处理数据，并按组织和时间对其进行划分。 在目标 S3 存储桶中，数据按日期和组织标识符进行组织。

随着数据平台及其功能的使用率不断提高，我们需要重新设计后端的部分内容以支持威胁堆栈数据可移植性。 现在您对我们的工作方式和我们支持的功能有了一些了解，让我们来看看之前和之后平台的状态。

Spark 之前的威胁堆栈

之前的处理应用迭代使用了Apache Flink ，这是一个依赖于 RAM 的分布式处理引擎，用于批处理和流处理的状态计算。 之所以选择 Flink，是因为它已经为平台的其他部分提供了流数据和遥测聚合功能。 为了支持新功能，我们构建了一个运行单个作业的新的 Flink 集群，该集群将使用 Apache Kafka 主题、对事件进行分区并将其写入 S3。 最终，集群增长到超过一百个 Flink 任务管理器，并且需要大量的手动维护。 为了让您了解我们支持的处理规模，Threat Stack 的平台每秒处理 50 万个事件。 我们后端的所有服务都需要支持这个步伐。

在 Apache Flink 上运行的摄取集群经过多轮调整，包括阶段并行性设置、事件数据加盐以实现均匀平衡的工作负载，以及各种基础设施实例大小实验。 不幸的是，集群已经达到了一个临界点，对于我们的团队来说，运营成本变得越来越高，对我们的工程师和云提供商账单都造成了影响。

随着时间的推移，我们开始注意到一些反模式，其中之一就是级联工人故障。 当单个工作程序缺乏资源时，它最终会变得无响应，这导致其余节点处理来自 Apache Kafka 主题的更多消息。 然后，节点会逐渐缺乏资源。 虽然我们在系统中设计了冗余，但连锁故障事件会对性能产生不利影响，需要值班人员的手动干预。

顺便说一句，我应该指出，Apache YARN 并未用于管理集群资源。 Apache YARN 可以解决集群工作进程中的级联故障，但它无助于解决成本和服务效率问题。 归因于此提取服务的平台稳定性事件数量占每月总服务事件的 30%。

挑战的另一面是运行支持数据提取服务的基础设施所产生的成本。 这一项服务大约占了我们云提供商月费的25%。 它还对人类产生了很大的影响，让人们半夜醒来，降低他们完成正常工作的能力。 由于服务造成的维护和中断量很大，因此需要进行替换并力求实现及时性、可扩展性、成本效益和稳定性。

从 Flink 迁移到 Spark

我们回顾了需求，即能够将按组织划分的原始事件数据写入时间块，以准备发送到客户的 S3 存储桶。 我们不需要 Apache Flink 的状态处理特性，我们只需要一个简单的 ETL 管道。 我们的工程团队已经在我们架构的其他领域尝试了Apache Spark ，并看到了令人满意的结果。

我们决定将业务逻辑从 Apache Flink 移植到在Amazon EMR上运行的 Apache Spark。 这种转变使我们能够使用得到更好支持、更广泛采用的行业标准工具。 通过 EMR，我们开始使用 AWS 提供的 Hadoop S3 连接器，而不是免费的社区支持的实施。 通过切换到托管服务 EMR，而不是在内部运行我们自己的 Apache Flink 集群，消除了维持旧管道运行所涉及的大部分操作复杂性。 此外，新的 ETL 管道是无状态的，并且不依赖于导致旧管道无法检测到故障的检查点或中间写入。 此外，新管道以短暂、预定义的间隔运行离散作业，并且由于任何部分故障而完全重试整个批次。 与我们以前处理流数据的方式相比，处理对于我们的客户来说仍然是及时的，但现在 Spark 微批处理提供了额外的耐用性。