Engineering

Multitenancy 经济学原理探究

Aditya Jayaprakash May 13, 2025

在早期的 Blacksmith 创业阶段，那时我们还是一个努力奋斗的 YC startup，致力于构建一个用于 CI 工作负载的 serverless 云平台。为了预测利润，我们进行了模拟。我们认为只要有足够多的客户，就能实现盈利，并对此充满希望。但是，当时我们并没有任何实际数据来支撑我们的预测。

在我们发布产品大约六个月后，我偶然看到了 Marc Brooker 发表的一篇博客文章，内容是关于 multitenant 系统的经济学原理。这篇文章比我们脑海中那些尚未成型的想法更加简洁地阐述了我们想要做的事情。这篇文章给了我很大的启发，读完之后，我真的感觉 "哇！原来已经有人考虑过这个问题，而且是合理的"。现在，我们每分钟运行数千个作业，每月运行数百万个作业，看到这一切实际发生，并观察到这些理论在现实中奏效，真的令人兴奋。然而，人们仍然常常难以置信地问我们，我们到底是如何从这种模式中赚钱的？难道我们只是在烧掉 VC 的钱，而看不到任何回报吗？因此，为了让那些不相信的人和所有好奇的人了解内幕，让我们一起深入探讨一下 multitenancy 的经济学原理——以我们自己为例进行案例研究。

CI 与生产环境不同（这一点很重要）。

与生产环境的工作负载不同，CI 工作负载往往具有非常明显的峰值。在下面，我们绘制了一个客户在 24 小时窗口内的 CPU 利用率。当有人推送代码时，利用率会飙升，然后在两次推送之间降下来。

这位客户每次 git push 都会在 16 个 vCPU 的机器上运行 35 个作业，这意味着每次运行 CI 时都需要超过 500 个 vCPU。看到图表中像乔治·克鲁尼主演的经典电视剧《急诊室的故事》中病人生命体征一样变成一条直线了吗？由于他们的团队分布在美国和欧洲，所以在中间有 8 个小时的时间没有任何使用量。当有几个工程师同时推送代码时——比如五个人——他们突然需要 2,500 多个 vCPU。而且所有这些 CI 作业都是短期的。大多数 CI 作业完成得很快（相对而言），大约在 5 到 40 分钟之间。CI 工作负载的所有这些混乱的特性听起来可能像一场噩梦，但实际上它与我们围绕构建的 serverless 模型非常匹配，最重要的是，与我们的客户非常匹配。

为什么我们的 Serverless CI 模型有效。

从客户的角度考虑：如果你在高峰时需要 2,500 个 vCPU，那么自己购买和管理所有这些硬件将是疯狂的——尤其是在大多数时间里这些硬件都会处于空闲状态的情况下。但是借助 Blacksmith 的 serverless CI 云，你可以从我们的资源池中借用，并且只需为使用的部分付费。峰值、突发、混乱？没问题。

更重要的是，CI 流量具有高度可预测性。开发人员在工作时间内推送代码，而不是在凌晨 2 点或节假日周末。与某些生产工作负载不同，我们的服务器集群不必为黑色星期五式的流量激增做准备——这影响了我们构建它的很多方面。

我们的集群：它是什么样的，什么最重要。

我们拥有一批由数百个裸金属游戏 CPU 组成的集群，我们正在通过虚拟化来利用它们——当客户需要运行 CI 作业时，我们会使用 Firecracker 启动一个 microVM，一旦作业完成——砰！它就消失了。

我们的每台机器都有 32 个 vCPU，在整个集群中，我们在 us-west 和 eu-central 区域管理着数万个 vCPU。为了保持一致性和工作流程支持，我们将客户锁定在一个区域。

目前，我们以固定期限租赁这些机器。很快，我们将在数据中心安装它们。无论如何，这些机器都是固定成本——无论我们是否有客户，我们仍然需要为它们付费。因此，CI 成本优化游戏的关键在于利用率。如果它们几乎没被使用，我们的利润率就很低；如果它们被充分利用，我们就能赚钱。我们最关注的指标是平均集群利用率——而客户的混乱行为是我们的秘密武器。

一点混乱是糟糕的。很多混乱？简直完美。

假设我们只有一个客户——就是之前那个在高峰时需要 2,500 个 vCPU 的客户。我们需要大约 80 台机器来处理这个负载，但是在一天中的大部分时间里，这些机器只会闲置在那里。我们会赔钱。

现在，添加第二个时区相同的客户。他们的 CI 作业不会在完全相同的时间达到峰值，因此我们可能只需要 110 台机器来覆盖这两个客户，而不是需要 160 台机器 (80 + 80)。随着我们添加更多客户，这种效应会成倍增加。我们添加更多客户，所有随机的活动爆发开始融合在一起。

随着时间的推移，CI 作业开始表现得像一个泊松过程——随机、短暂的爆发分散在各个时间段。从远处看，曾经看起来像来自单个客户的尖锐峰值现在平滑成一种可预测的模式。我们服务的客户越多，每个单独的峰值看起来就越不强烈。简而言之：越混乱，对我们的业务就越有利。当对我们的业务更有利时，对客户也更有利——因为随着我们的服务器集群变得更繁忙，服务每个作业的成本就会下降。这让我们能够在保持低价的同时仍然经营可持续发展的业务。

这种设置的美妙之处在于，每个新客户实际上都使整个系统对每个人都更好。就像你在晚宴上说的那样，“人越多越热闹”，而且你真的是这么想的。更多客户 = 更多随机性 = 更平稳的整体运营。Multitenant 系统在更多用户的情况下运行得更好：利用率上升，而我们的服务成本下降。这意味着服务器集群上的增长的混乱只会提高成本节省和效率。你赢了。我们赢了。事实上，即使我们的服务器集群运行得很热也是一件好事。

集群运行热意味着更多钱。

由于无论如何我们都必须为固定的机器集群付费，因此我们的毛利率几乎完全取决于我们的机器有多繁忙。

基本上，我们的收入随着集群的平均利用率而增长。利用率和毛利率之间存在直接联系，而且不是线性的。

利用率的适度提高会导致盈利能力的巨大提高。一旦利用率很高，保持提高利润率的下一个主要手段就是降低购买机器的成本——而一天中的时间起着令人惊讶的重要作用。

谁在什么时间推送代码？

在周末，我们的集群的使用量只有平时的 1/5 左右。但是工作日呢？那才是真正的派对开始的时候。

我们的大多数客户都在美国，在欧洲也有相当一部分，在亚洲的比例正在缓慢增长。如下图所示，利用率在一天中的前 8 个小时保持较低水平。以下是详细信息（以 UTC 时间为准）：

我们看到的最大峰值出现在欧洲结束一天的工作，以及东海岸和西海岸同时工作的时候。美国以外的客户在低流量时段使用我们的集群——基本上是免费利用率。这提高了利润率，而我们不需要更多的机器。这就是最佳的 CI 成本优化。将其添加到看板上，又一次胜利。我们只需要扩展我们的集群以跟上美国的增长。就像时区影响客户的日常使用和我们对集群的思考方式一样，地理位置影响我们构建和扩展集群的位置。

区域经济学。

我们最初从 eu-central 中的一个区域开始，但是随着时间的推移，我们意识到我们需要在美国的第二个区域。这是由客户的要求驱动的，因为当你的 runner 在美国时，Docker push 到美国的容器注册表的速度甚至更快。此外，一些客户出于合规原因更喜欢将他们的代码保存在美国境内。起初，美国区域只有一个大客户，因此利润率和利用率都很一般。但是随着越来越多的人加入，随着利用率的提高，我们的数字看起来越来越好。

我们仍在努力优化我们的区域负载平衡，但是这篇文章已经太长了，这是以后的故事了。如果你看到了这里，感谢阅读。仍然在烧掉一些 VC 的钱，但是，嘿——由于 multitenancy 的强大功能，利润率看起来不错。如果你想帮助进一步提高利润率，请 try out Blacksmith。