自托管 DefectDojo Pro 的硬件规模规划 (Pro)

为 DefectDojo 部署确定规模，归根结底取决于两个问题：您要保存多少数据，以及同时有多少人在使用它。本页针对这两个问题给出了起点建议。

请将以下内容视为一般性指导，而非规格说明。这些数字有意偏向保守，并假设该部署在进行日常分诊的同时，还会定期导入扫描结果。您自己的数字会随着产品使用方式的不同而变化，因此在配置任何资源之前，请先阅读表格下方的说明。

规格以通用的 vCPU 和内存数字给出，因此适用于任何云服务商或本地硬件。应用节点方面的建议假设使用 Kubernetes。如果您在单台主机上运行 Docker Compose，请使用相同的总量。

规模规划表#

您在某个区间内具体落在哪个位置，取决于您的工作负载。如果有哪些因素会让您升到更高档位中的任何一项适用于您，请从该区间的较高端开始考虑。

500M 这一行是远端的一个参考点，而不是对上方规律的延续，因此不要在它与 10M 档位之间进行插值。介于这两者之间的部署需要单独进行规模规划。它还假设了一些仅靠硬件本身无法解决的工作，相关内容在超大规模部署中介绍。

如何解读这些数字#

数据库内存比数据库 CPU 更重要#

DefectDojo 会在您的发现项上运行大量聚合型查询。只要工作集及其索引能够由内存提供服务，这些查询就能保持较快速度，而一旦数据库开始访问磁盘，性能就会迅速下降。如果必须二选一，请优先购买内存而不是核心数。上表也体现了这一点：内存在各档位之间大致翻倍，而 CPU 数量的增长要缓慢得多。

应用节点的规模取决于用户数，而非发现项数量#

表中的并发用户数假设数据量较小的团队规模也较小。这一假设经常不成立。如果您持有 20 万条发现项，但同时有 100 人在界面中操作，请按用户数来规划应用层，同时让数据库保持在您的发现项数量所对应的档位。这两者是独立扩展的。

表格远端有一个例外。导入和去重运行在应用层而非数据库中，因此一旦数据集大到足以让这部分工作占主导，节点数量就会跟随导入量而非用户数变化。这也是为什么 500M 这一行的节点数远高于其用户数单独所能推算出的水平。

节点形态是灵活的#

无论您提供的是几个大节点还是更多的小节点，Kubernetes 都会分摊负载，因此上面的节点数量只是一种可行的安排，而不是硬性要求。有两点值得坚持：至少保留两个节点，以免丢失一个节点就导致应用宕机；并避免使用小于 2 vCPU / 8 GB 的节点，以便各个 pod 能够顺利调度。

存储#

请按每百万条发现项 20–30 GB 数据库存储进行规划。您在该区间内的具体位置取决于每条发现项挂载了多少附加内容。较长的描述和较多的端点数量会将您推向区间上限。发现项行数据本身只占其中一小部分，大部分空间用于索引以及挂在每条发现项上的关联表，因此仅按行数据来估算规模会严重不足。

直到 10M 档位为止，每一档都能容纳在几百 GB 的通用型 SSD 之内。相较于存储用尽的代价，存储本身是廉价的，因此请按照您预计一年后所处的规模来配置，而不是按照当前的规模。如果您的服务商提供存储自动扩容功能，请启用它。

500M 这一行按 2.5 TB 规划。这一数字假设实时数据集受到主动管理，较旧的发现项会从热路径中归档移出，而不是无限累积。如果简单套用上面按百万条计算的比率，一个未经管理的 500M 部署所需的存储量会高出好几倍。如果您正朝这一规模发展，请将归档策略视为规模规划的一部分，而不是留待日后再解决的问题。

在这一规模下，存储不仅需要关注容量，还需要关注吞吐量。一旦工作集不再能完全放入内存，通用型卷的默认基线 IOPS 会比容量更早成为瓶颈。

媒体存储是独立的，通常规模也小得多。它用于存放上传的制品，例如屏幕截图和风险接受文档，因此请根据您自己的上传习惯来规划其规模。

有哪些因素会让您升到更高档位#

发现项数量是最主要的指标，但有几项因素会让您比仅凭数量推算所得出的结论更早地需要升级规模。

• 导入量与导入频率。 频繁到达的大型扫描结果，尤其是多个同时到达时，会对数据库和异步工作节点都造成持续负载。每次构建都进行导入的 CI 流水线通常是主要原因。
• 去重。 去重会将新导入的发现项与您已有的发现项进行比对。您持有的发现项越多、去重配置的范围越广，每次导入所需的工作量就越大。
• 报告与仪表板。 指标视图和大型报告生成都是读密集型操作，对数据库的压力大于日常分诊工作。
• API 流量。 轮询或拉取大量结果集的集成会增加并发负载，而这部分负载不会体现在您的交互式用户数中。
• 数据保留。 永久保留所有数据的部署会按部就班地升入下一档位。归档或删除旧数据可以让您在当前档位停留更长时间。

超大规模部署#

超过 10M 档位后，硬件不再是全部答案。有两点会发生变化。

起决定作用的瓶颈会从读取转向写入。去重会将每一条新导入的发现项与您已有的数据进行比对，因此导入成本会随着背后数据集规模的增长而增加。在表格的顶端档位，这通常是您最先遇到的瓶颈，早于用户在界面中察觉到的任何问题。当初造就如此庞大数据集的导入量通常仍在持续运行，因此这一成本是持续产生的，而不是一次性的。

内存数字假设热数据集保持较小规模。一个部署主要处理近期的发现项，而基本不触碰较旧的发现项，这正是数据库能够持有远超其内存容量的数据、同时仍保持良好性能的原因。如果您的访问模式真正地分散在整个数据集上，您需要的内存将超过表中所列的数字，而超过某个临界点后，任何单个实例都无法满足需求。

这两个方面都指向同一项工作。在这一规模下，对分区处理并将冷数据从实时数据集中归档移出，比再增加一点 vCPU 更为重要，而繁重的报告工作应放在只读副本上，而不是主库上。请将这项工作与硬件规划一并考虑，而不是事后再补，并在配置资源之前先与我们沟通。

如有疑虑，向上取整#

这里给出的数字本身已经偏向保守，而配置偏大一档的代价，要远小于偏小一档的代价。尤其是数据库内存压力，一旦出现问题就不会平缓地退化——性能会一直保持良好，直到突然崩溃。

日后增加应用容量很简单，只需添加节点即可。而调整数据库规模通常意味着停机，因此这一项才是最值得一开始就规划正确的。

问题或支持#

以上都是起点建议，而不是上限。如果您的部署处于表格的顶端档位，或者您的工作负载与这里的假设并不相符，请在配置资源之前与我们沟通。请联系您的客户代表，或发送邮件至 。