MaaS 组件扩缩容
本指南说明如何扩展构成 Model as a Service (MaaS) 的各个组件:Gateway、Authorino、rate limiter,以及 Guardrail engine 和 shim。本指南基于长流 SSE 压测以及对组件数据平面行为的观测结果。
Gateway
Gateway 是一个受 CPU 约束的数据平面组件。其 CPU 利用率完全可以保持在较高水平:在 SSE 压测中,只要副本数和资源充足,较高的 CPU 利用率本身不会导致请求失败。应当预期并容忍较高的 CPU 使用率,并配置告警,避免产生误报。
当 Gateway 负载很高时,可通过增加副本数或 CPU 进行扩容。一个合理的初始告警点是:持续较高的 CPU 利用率同时伴随 SSE 行为退化,因此在决定扩容前,应将 CPU 与以下信号结合起来判断:
- HTTP 错误和非
200响应; - 未以
[DONE]结束的 SSE 流; - TTFT 和总流式时长增加;
- CPU throttling 和 Pod 重启。
Authorino
Authorino 对延迟非常敏感。其瓶颈不在于 CPU 利用率是否达到 100%,而在于 ext_authz 检查是否能在超时时间内完成。当 Authorino 排队请求或处理过慢时,即使 Authorino Pod 仍有 CPU 余量,Envoy 也可能因 ext_authz 超时返回 403。此场景下,典型的 Envoy 响应标志是 UAEX。
不要仅根据 CPU 来为 Authorino 设定规模。应监控授权延迟、请求排队情况和 ext_authz 超时,并在延迟或超时率上升时通过增加副本数进行横向扩展。
rate limiter
rate limiter 用于强制执行每个订阅的 token 配额。应根据实际请求速率和所使用的限速策略来配置其副本数和资源,并在预期流量模式下进行验证。
Guardrail engine 和 shim
Guardrail engine 使用 Python 实现。单个 engine 实例无法很好地利用多个 CPU 核心:在 SSE 压测中,分配了 1 CPU 的 engine Pod 并未被完全打满,而且为单个实例增加更多核心也没有提升并发吞吐量。经过验证的 Guardrail engine 扩展方式是增加 engine 副本数,同时将每个 engine Pod 保持为 1 CPU。
应根据 ext_proc 调用延迟、错误率和并发数来扩展 Guardrail ext_proc shim。
在哪里配置副本和资源
大多数 MaaS 组件都在 MaaS Tenant 上进行配置:
- Gateway:
spec.gatewayDeployment - Authorino:
spec.authorinoDeployment - Guardrail engine 和 shim:
spec.guardrails.engine和spec.guardrails.shim
全局 rate limiter(envoy-ratelimit)是个例外。它在安装 MaaS 的 AmlCluster 上进行配置,路径为 spec.values.maas.gateway.rateLimit。
engine.replicas 和 shim.replicas 字段控制 Guardrail engine 和 shim 的副本数。对于 Guardrail engine,请将每个 Pod 保持为 1 CPU,并通过增加 engine.replicas 来扩容。
示例 Tenant:
示例 AmlCluster rate-limit 配置: