Netflix迁移Flink Autoscaler支撑超3万流式作业

Netflix正在把超过3万个流式作业迁移到开源Apache Flink Autoscaler，并已在多个AWS区域进行部署。此前采用的集群级自动扩缩容机制难以应对复杂有状态管道中不同算子处理负载差异较大的情况。Netflix称，某团队采用新方案后，Flink计算支出年化下降58%，每年节约约110万美元。

Netflix从2017年开始运行Apache Flink，并在2019年前后基于Mantis搭建了首套自动扩缩容系统。该系统通过Atlas读取集群层面的CPU、网络利用率、Kafka延迟、输入速率和消费速率等遥测数据，再统一调整TaskManager数量。过去，这套机制已在数千个管道中减少25%至45%的资源使用。

原方案的核心限制是决策粒度位于集群，而不是单个算子，因此同一作业内的所有算子只能共享一套扩缩容结果。对于包含分支、连接以及数TB状态数据的有状态管道而言，不同数据流环节的处理需求可能完全不同，统一调整资源容易造成部分算子资源不足、另一部分资源闲置。

开源Flink Autoscaler会利用运行中作业暴露的指标，结合吞吐量与忙碌时间估算各算子的实际处理速率，再沿作业图遍历，为每个顶点分别计算目标并行度。FLIP-271详细描述了这一方法，重点解决异构流式作业的自动扩缩容，以及有状态应用重新调整规模时的成本问题。

这套设计还吸收了DS2项目的研究成果。系统研究员Vasiliki Kalavri介绍，项目早期曾探索关键路径分析，后来改用实际处理速率作为更简单的基线。实践表明，这一方案虽然直观，却取得了较好效果，之后被纳入Flink自动扩缩容相关工作。

Netflix没有直接通过Flink Kubernetes Operator部署Autoscaler，而是将其接入内部控制平面：一个Spring Boot服务借助Temporal工作流隔离不同作业的扩缩容决策。Netflix同时改造了JobManager指标采集机制，使其可支持最多3000个子任务的作业，并加入服务端指标过滤、扩缩容时保留前向连接子图以及处理Sink回压的逻辑。

前向连接带来的并行度调整问题也曾在Apache Flink开发者讨论中出现。跨FORWARD连接修改并行度可能需要重新分配数据，Netflix因此选择让前向连接上的算子保持在一起。此外，已公开的FLINK-38538问题指出，繁忙算子可能会受到基于输出比率的扩缩容决策影响。

与KEDA等依赖外部指标或事件来调整工作负载的通用事件驱动扩缩容工具不同，Flink Autoscaler会依据内部数据流图和算子容量进行推理。Netflix当前将利用率目标设为0.45，低于Flink社区默认的0.7，目的是降低大型有状态作业过于频繁或激进地重新扩缩容的情况。后续Netflix计划把剩余内部自动扩缩容实例迁移到开源实现，并研究Flink 2的分离式状态架构，以降低重新扩缩容期间恢复状态的成本。