如何提升 Security Insights 的扫描效率
[Security Insights](https://developers.cloudflare.com/security/security-insights/) 为每个 Cloudflare 账户提供可行的安全建议。我们定期扫描所有账户、区域和 DNS 记录，以寻找潜在的安全风险和配置错误，但发现两个关键问题：一是扫描频率太低，仅每周或每两周进行一次，导致新出现的安全风险可能长达两周未被发现；二是许多免费计划账户需要手动选择开启自动扫描，结果很多账户根本没有进行扫描。随着自动化攻击加剧，检测安全配置错误的时间窗口越来越小，确保我们能够发现所有客户的安全问题对我们构建更好的互联网至关重要。
经过计算，若想提高扫描频率并为所有账户开启自动扫描，我们需要将平均扫描吞吐量提高约 10 倍，从每秒 10 次提升至 100 次。然而，我们的系统已经负载过重，数以百万计的事件正在排队等待处理，API 经常超时，进程经常崩溃。因此，我们必须修复系统并使其具备扩展能力。这就是我们如何将 Security Insights 的扫描吞吐量提高 10 倍以上，开启数百万客户的安全洞察，并将所有客户的扫描频率翻倍的故事。
## 如何进行安全洞察扫描
我们的自动安全扫描由调度器触发。当账户或区域到期需要扫描时，调度器会向 [Apache Kafka](https://blog.cloudflare.com/using-apache-kafka-to-process-1-trillion-messages/) 发布消息。这些消息会被分发到多个检查器，专门的 Go 微服务会扫描特定的资产或配置。每个消息都会将结果（发现的安全洞察）发送到我们的内部 API，然后将其存储在 Postgres 数据库中。
## 扩展架构
### 扩展 Kafka
Apache Kafka 并非严格意义上的队列，而是一个分区事件流。在每个分区内，消息必须按顺序消费和处理，这与典型队列的行为不同。因此，我们每个消费者组只能拥有一个活动消费者。这导致了两个后果：慢消息的处理将阻止消费者前进到下一条消息；每个检查器的消费者数量受分区数量的限制。虽然可以通过增加分区来扩展，但这会增加 Kafka 代理自身的资源使用。因此，我们首先提高代码和架构的效率，再考虑增加分区。
### 引入并行处理
尽管我们只能按顺序消费消息，但并没有限制我们同时消费多个消息。我们修改了检查器，以批量消费消息，在不同的 goroutine 中处理每条消息。这虽然在发生崩溃时需要重新处理批次中的消息，且会稍微增加内存使用，但在我们的情况下这是可以接受的。
### 避免前置阻塞
有些消息的处理时间明显长于其他消息。比如，一个账户或区域的资产数量相比另一个可能多得多。在最坏情况下，某些消息可能需要几分钟甚至几小时处理，而平均处理时间却是几秒或几毫秒。我们采用了将消费者组和检查器分为“慢车道”和“快车道”的简单方法。如果“快车道”检查器遇到慢消息，就跳过它，从而减小延迟。
## 数据库查询优化
每个发现的洞察都写入我们的 Postgres 数据库。最初我们使用每条洞察调用一次 API 的方式，这在洞察数量高达 500,000 时带来了大量的数据库往返和查询。我们尝试使用 Postgres 的批量插入标准 COPY 到临时表，但这导致系统表膨胀。最终我们采用混合方式：在问题数低于阈值时采用 UNNEST，高于时采用 COPY，这样在大数据量插入时既能快速插入，也能提供小规模数据更快的插入速度。
## 调查 API 超时
在扩展过程中，我们注意到了内部 API 的一些异常行为，例如请求触发客户端超时，许多检查器在处理单个 API 调用上花费了 20% 到 90% 的时间。所有这些问题源于延迟。由于我们的主数据库位于俄勒冈州波特兰，而 API 在波特兰和阿姆斯特丹之间活跃运行。即使光速传输，波特兰和阿姆斯特丹之间的往返延迟也会达到 50 毫秒。解决方案是将我们的 API 切换为 [主动-被动故障转移](https://developers.cloudflare.com/load-balancing/load-balancers/common-configurations/#active---passive-failover)，确保活跃 API 跟随主数据库，从而消除了延迟问题。
## 重新思考调度器
尽管我们扩展了 Kafka，优化了数据库查询，修复了 API，仍需确保扫描时间均匀分布。调度器并未很好地均匀分配扫描，触发的扫描数量时常会在短时间内激增。我们做了三项关键改动：
1. 区域独立于账户进行调度。
2. 随机化现有账户和区域的 last_scheduled_at 时间。
3. 引入自适应速率限制，确保在扫描频率变化时平滑过渡。
## 当前的进展
这些修复让我们每个检查器的 7 天移动平均吞吐量提高了 10 倍以上。现在，Security Insights 的吞吐量在高峰期达到了每秒 120 次，超出了我们的目标 10 倍提升。我们为所有免费账户和区域开启了自动扫描，并增加了扫描频率：免费账户每 7 天一次，专业和商业账户每 3 天一次，企业账户每日一次。由于系统的稳定性提高，我们有信心开发之前因负载限制而无法实现的新功能。
今天，所有 Cloudflare 计划的安全洞察默认开启。现在就登录 [Cloudflare 控制台](https://dash.cloudflare.com/?to=/:account/security-center) 查看并管理您的安全洞察。
---
原文链接：[点击查看](https://blog.cloudflare.com/scaling-security-scans/)
经过计算，若想提高扫描频率并为所有账户开启自动扫描，我们需要将平均扫描吞吐量提高约 10 倍，从每秒 10 次提升至 100 次。然而，我们的系统已经负载过重，数以百万计的事件正在排队等待处理，API 经常超时，进程经常崩溃。因此，我们必须修复系统并使其具备扩展能力。这就是我们如何将 Security Insights 的扫描吞吐量提高 10 倍以上，开启数百万客户的安全洞察，并将所有客户的扫描频率翻倍的故事。
## 如何进行安全洞察扫描
我们的自动安全扫描由调度器触发。当账户或区域到期需要扫描时，调度器会向 [Apache Kafka](https://blog.cloudflare.com/using-apache-kafka-to-process-1-trillion-messages/) 发布消息。这些消息会被分发到多个检查器，专门的 Go 微服务会扫描特定的资产或配置。每个消息都会将结果（发现的安全洞察）发送到我们的内部 API，然后将其存储在 Postgres 数据库中。
## 扩展架构
### 扩展 Kafka
Apache Kafka 并非严格意义上的队列，而是一个分区事件流。在每个分区内，消息必须按顺序消费和处理，这与典型队列的行为不同。因此，我们每个消费者组只能拥有一个活动消费者。这导致了两个后果：慢消息的处理将阻止消费者前进到下一条消息；每个检查器的消费者数量受分区数量的限制。虽然可以通过增加分区来扩展，但这会增加 Kafka 代理自身的资源使用。因此，我们首先提高代码和架构的效率，再考虑增加分区。
### 引入并行处理
尽管我们只能按顺序消费消息，但并没有限制我们同时消费多个消息。我们修改了检查器，以批量消费消息，在不同的 goroutine 中处理每条消息。这虽然在发生崩溃时需要重新处理批次中的消息，且会稍微增加内存使用，但在我们的情况下这是可以接受的。
### 避免前置阻塞
有些消息的处理时间明显长于其他消息。比如，一个账户或区域的资产数量相比另一个可能多得多。在最坏情况下，某些消息可能需要几分钟甚至几小时处理，而平均处理时间却是几秒或几毫秒。我们采用了将消费者组和检查器分为“慢车道”和“快车道”的简单方法。如果“快车道”检查器遇到慢消息，就跳过它，从而减小延迟。
## 数据库查询优化
每个发现的洞察都写入我们的 Postgres 数据库。最初我们使用每条洞察调用一次 API 的方式，这在洞察数量高达 500,000 时带来了大量的数据库往返和查询。我们尝试使用 Postgres 的批量插入标准 COPY 到临时表，但这导致系统表膨胀。最终我们采用混合方式：在问题数低于阈值时采用 UNNEST，高于时采用 COPY，这样在大数据量插入时既能快速插入，也能提供小规模数据更快的插入速度。
## 调查 API 超时
在扩展过程中，我们注意到了内部 API 的一些异常行为，例如请求触发客户端超时，许多检查器在处理单个 API 调用上花费了 20% 到 90% 的时间。所有这些问题源于延迟。由于我们的主数据库位于俄勒冈州波特兰，而 API 在波特兰和阿姆斯特丹之间活跃运行。即使光速传输，波特兰和阿姆斯特丹之间的往返延迟也会达到 50 毫秒。解决方案是将我们的 API 切换为 [主动-被动故障转移](https://developers.cloudflare.com/load-balancing/load-balancers/common-configurations/#active---passive-failover)，确保活跃 API 跟随主数据库，从而消除了延迟问题。
## 重新思考调度器
尽管我们扩展了 Kafka，优化了数据库查询，修复了 API，仍需确保扫描时间均匀分布。调度器并未很好地均匀分配扫描，触发的扫描数量时常会在短时间内激增。我们做了三项关键改动：
1. 区域独立于账户进行调度。
2. 随机化现有账户和区域的 last_scheduled_at 时间。
3. 引入自适应速率限制，确保在扫描频率变化时平滑过渡。
## 当前的进展
这些修复让我们每个检查器的 7 天移动平均吞吐量提高了 10 倍以上。现在，Security Insights 的吞吐量在高峰期达到了每秒 120 次，超出了我们的目标 10 倍提升。我们为所有免费账户和区域开启了自动扫描，并增加了扫描频率：免费账户每 7 天一次，专业和商业账户每 3 天一次，企业账户每日一次。由于系统的稳定性提高，我们有信心开发之前因负载限制而无法实现的新功能。
今天，所有 Cloudflare 计划的安全洞察默认开启。现在就登录 [Cloudflare 控制台](https://dash.cloudflare.com/?to=/:account/security-center) 查看并管理您的安全洞察。
---
原文链接：[点击查看](https://blog.cloudflare.com/scaling-security-scans/)
评论
暂无评论。