Agent时代，静态容量规划注定失败！聊聊 Zilliz Cloud 的AutoScale设计
过去，规划容量时，我们习惯于依赖 CU 计算器去锚定一个理性的起点，但在AI时代，这种容量规划往往会变成流于形式的幻觉。
因为系统的未来负载，本质上是不可预测的。数据的无序增长、查询流量的瞬时海啸、写入吞吐的无预警突增，以及错综复杂的用户行为，这些变量交织在一起，构成了一个持续流动的混沌系统。
任何试图用静态估算来框定动态未来的尝试，都会给系统埋下隐患。
以Serving Workloads为例，单一的固定估算注定会以两种形式走向失效：
- 估算过低：集群在突发洪峰下承压，吞吐骤降，集群承压。
- 估算过高：为了所谓的安全感，长期保留大量闲置的计算资源，造成工程成本的巨大空转。
在这一背景下，我们推出了AutoScale，它的核心理念是：既然 “我们需要多少资源”式的问题已经失效，那么我们需要思考的是：“系统应该在怎样的安全框架内行使自适应的权利？”
因此，在AutoScale中，我们不再强求用户不断猜测未来的容量变化，而是通过AutoScale，让用户去定义宏观的边界，然后系统通过捕捉实时的底层信号，在用户定义的护栏之内，完成弹性扩缩容。
【传统范式：盲目预测】
用户的猜测 ──> 静态配置 ──> 面对无常流量 ──> 集群承压 或 资源空转
【AutoScale 范式：边界自适应】
用户掌控边界（Min/Max） ──> 系统观察实时信号 ──> 护栏内的微观自适应
如何理解AutoScale
要理解AutoScale，我们需要先理解在 Zilliz Cloud 的设计哲学中，Query CU 与 Replica 这两个概念。
| 问题 | 定义 | 核心观测信号 | 扩缩容动作 |
|---|---|---|---|
| 容量是否足够？ | Capacity 指每个服务副本的资源余量：它能否稳定承载数据量、内存、CPU、collection、partition 和写入增长。 | CU Capacity | 扩缩 Query CU |
| QPS 余量是否足够？ | Replica 是一个完全相同的服务副本。增加 Replica 可以创建更多服务通道，让查询流量被分摊。 | CU Computation | 扩缩 Replica |
通常来说，使用 Query CU 可以为每个服务副本提供更多容量。使用 Replica 可以增加更多服务副本，以提升查询吞吐和可用性。
| 流量模式 | 最佳应用场景 | 应对策略 | 典型工程实践 |
|---|---|---|---|
| 手动扩缩容 | 已知的一次性确定性变更 | 工程师直接操纵 Query CU 或 Replica | 大规模数据迁移、极限压力测试、计划内的重大版本发布 |
| 定时扩缩容 | 具有时间周期律的潮汐流量 | 在预设的时间窗口内，将集群精准推进至目标规模。 | 工作时间的高峰对抗、每周固定的批处理、营销活动的预热期 |
| 动态扩缩容 | 不可预测的、实时的需求 | 系统静默观察核心指标，在最小值和最大值边界内自适应。 | 业务爆发式增长、线上实时混沌流量、不可控的突发峰值 |
基于以上两个概念，我们可以组合出多种不同的扩缩容策略。
如何选择合适的扩缩容策略
通常来说，工作负载的变化方式有三种：可提前预知的、遵循固定周期的、持续波动的。
针对以上三种情况，Zilliz Cloud 支持多种扩缩容方式。
当负载的模式非常清晰时，手动与定时是最高效的手段；而当预测本身难以实现的时候，动态扩缩容更合适。
AutoScale背后的护栏哲学
动态自适应绝不是任由系统野蛮生长，它在设计之初就带着边界意识。我们可以重点关注三个指标：
- 最小值（Min）：为常态流量保留最基础的物理资源，避免过度缩容。
- 最大值（Max）：控制成本，并让扩缩容行为保持在预期范围内。
- 目标余量（Target Headroom）：在常态与极限之间的缓冲，既保留足够的性能缓冲，同时避免不必要的闲置资源。
在机制的底层：对于 Query CU，动态扩缩容会使用 CU Capacity 作为信号。对于 Replica，动态扩缩容使用 CU Computation 作为信号。具体触发窗口由产品定义，但底层逻辑其实就是持续承压就扩容，持续低使用率就缩容，策略边界保证整个过程可控。
AutoScale 在后台做了什么
AutoScale 是一个标准的闭环控制系统（Control Loop）。它通过指标观察工作负载，应用用户配置的策略，触发合适的扩缩容动作，并让集群回到健康的资源余量范围。
整个 AutoScale 决策循环如下：
- 信号感知 (Observe)：实时捕获核心指标。CU Capacity 显示容量压力。CU Computation 显示 QPS 压力。
- 策略裁决 (Apply Policy)：Min/Max 的边界、时间触发窗与目标余量共同决定是否需要扩缩容。
- 多维拓扑 (Scale Dimension)：Query CU 扩展每个服务副本的容量。Replica 增加服务通道。
- 回归稳态 (Healthy Headroom)：集群回到更安全的运行范围。
在扩缩容过程中，Zilliz Cloud 会执行资源检查并运行扩缩容任务。对于 Dedicated 集群，计费会在扩缩容任务成功完成后发生变化。因此，在任务仍在进行时，计费仍以之前的配置为准。
实操指南
在实际应用中，我们可以遵循以下原则
容量问题 → 观察 CU Capacity → 扩缩 Query CU。
QPS 问题 → 观察 CU Computation → 扩缩 Replica。
更具体的细节参考下表：
| 场景 | 建议 |
|---|---|
| 启动新的服务型工作负载 | 使用 CU 计算器和早期压测选择基线，然后围绕现实增长设置动态边界。 |
| 容量承压 | 观察 CU Capacity，并扩展 Query CU。如果工作负载持续增长，提高 Query CU 的最大值边界。 |
| QPS 承压 | 观察 CU Computation，并扩展 Replica。当大量并发查询竞争吞吐时，增加更多服务通道。 |
| 可预测的每日或每周峰值 | 使用定时扩缩容，在高峰到来前提前扩容，并在窗口结束后缩回。 |
| 流量全天变化 | 使用动态扩缩容，让集群在设定范围内自适应，而不是等待手动调整。 |
总而言之，最好的资源规划，从来都不是一个冰冷的、静止的数字。 它应该是一个演进的模型：能理解工作负载是受容量限制还是受 QPS 限制，然后选择正确的扩缩容维度，并为系统自适应定义安全边界。
AutoScale 的价值在于让服务型集群更容易运维，把资源规模决策移动到了更接近工作负载的位置，用户仍然控制范围，但更多的操作细节，可以交给系统处理这个范围内的变化。
Bill Chen
