当前位置：网站首页>阿里超大规模 Flink 集群运维体系介绍

阿里超大规模 Flink 集群运维体系介绍

2022-04-21 14:54:00 【Apache Flink】

▼ 关注「Apache Flink」，获取更多技术干货 ▼

摘要：本文整理自阿里云实时计算高级运维专家王华 (尚付) 在 Flink Forward Asia 2021 生产实践专场的演讲。主要内容包括：

演进历史和运维挑战
集群运维 Flink Cluster
应用运维 Flink Job

Tips： 点击 「阅读原 文」查看原文视频 & 演讲PDF～

一、演进历史和运维挑战

阿里的实时计算经历了近 10 年的快速发展，总体来说可以分成三大时代：

1.0 时代：2013 年到 2017 年，三大实时计算引擎并存。大家熟悉的 Jstorm 和 Blink 当时都还叫做流式计算。
2.0 时代：2017 年集团合并了三大实时计算引擎，Blink 凭借着出色的性能、高效的吞吐成为唯一的实时计算引擎，实现了大一统。在接下来的 4 年里，集团所有实时计算业务全部迁移到 Blink，阿里的实时计算业务经历了最飞速的增长，平台规模体量也从千级别增长到万级别，实时计算 all on Blink。
3.0 时代：随着前两年阿里收购了德国 Flink 母公司，阿里中国和德国团队联手打造了基于云原生新底座、搭载 Flink 开源新引擎的 VVP 新平台。在 2021 年双 11，VVP 新平台以大幅度的性能提升平稳支撑了双 11，宣告着阿里实时计算进入了全新的 3.0 时代。

目前，阿里的实时计算已经拥有了几百万核算力，几万台物理机，几万个作业，真正形成了一个超大规模的实时计算平台。而且在业务飞速发展过程中，平台整体的架构从云下的 Hadoop Flink 正在全面往云原生 K8s 加 Flink 大规模演进中。

面对这样一个实时计算的庞然大物，运维也随着时代变迁面临了不同的挑战：

第一阶段是平台运维，核心是帮助 SRE 解决超大规模体量的平台运维，也就是 Flink Cluster 集群运维的难题；
第二阶段是应用运维，核心是帮助集群上大量的实时计算用户解决应用侧 Flink 作业运维复杂的难题；
第三阶段是随着 3.0 时代的到来，集群底座全面云原生化，全域数据也随着云原生而标准化，运维能力如何向云原生和智能化快速演进和提升，成为我们新的挑战。

二、集群运维 Flink Cluster

一方面，Flink 平台上运行着一个非常典型的业务，就是双 11 大促当天 GMV 媒体成交翻牌器，也就是家喻户晓的成交额大屏，这个业务对于稳定性要求非常高。除了 GMV 翻牌器，Flink 还承载了阿里内部全部重要的实时计算业务，包括阿里妈妈、广告计量计费、搜索推荐、机器学习平台等核心电商业务的实时场景。这些实时场景既重要又实时敏感，稳定性是第一大挑战。
另一方面，由于平台规模体量巨大，涉及到几万台独享机器，多地域的部署，平台体量增长带来的平台复杂部署度的增加，所以局部异常又会成为常态，这是对稳定性的第二大挑战。

业务重要又敏感、平台规模体量大且架构复杂，面临这样的双重挑战，如何去维护集群的稳定性是一大难题。

一开始 Flink 集群是用故障数来度量稳定性的，但实际上粒度很低，因为有很多未达到故障时长标准的稳定性异常是没有办法在最终的故障数中体现的，导致稳定性存在着盲区。后面我们就打造了几套基于分钟级可用率的 SLA 可用率来度量整个集群的稳定性。

SLI 是用来计算 SLA 的黄金指标，它代表着 Flink Cluster 的可用性，因为集群是一个虚拟的逻辑概念，所以我们定义了 Flink 作业状态来代表 SLI。Flink 作业状态本身非常复杂，但是我们可以简单抽象出三种状态：调度中、运行正常、运行异常，每个作业都能计算出这三种状态，然后汇聚到集群层面形成作业的比例，一旦异常的比例超过某个阈值，就代表集群不可用，从而度量出 SLI 再算出全年的不可用时长。

最终 SLA 的可用率度量可以表示成一个简单的数学公式，SLA 可用率 = SLA 异常数 * SLA 平均每次异常时长，来实现分钟级可用率精细度量衡集群稳定性。

有了精细的量化，接下来就是提升的路径，也可以从上述公式入手去优化两个因子：分别是既做好稳定性的预防，来减少 SLA 次数；同时也做好了 SLA 的快速恢复，缩短 SLA 时长，最终提升整体的可用率。

首先是 SLA 异常预防部分，关键的思路是做好集群的巡检，主动发现异常隐患，及时消灭隐患，从而减少 SLA 异常的次数。

导致 SLA 异常隐患有哪些？比如一堆超大作业突然启动，导致集群几百台机器 load 打高或者磁盘打满，引发大量作业心跳超时；再比如说某一个 Flink 版本存在重大的稳定性问题或缺陷，影响了线上近千个作业。这些看上去很冷门的故障场景，实际上在一个超大规模的集群里和丰富的业务场景形态下几乎每天都在发生，这是平台发展到一定规模必然会出现的挑战。而且集群规模越大，越容易出现蝴蝶效应，影响面往往更大。此外，每次集群异常定位的复杂度和耗时都非常久，如何去消灭这些 SLA 异常？

我们的思路是打造一个 Flink Cluster 的异常自愈服务，通过定期扫描线上全量作业的行为数据比如作业的延时、Failover、反压，然后对这些海量数据做异常分析和决策找到隐患。总的来说可以分为两大类异常：

一类是由于用户侧自身作业行为导致的，通知用户去更改相应的作业，比如资源配置不合理导致 OOM、作业反压导致延迟等；
另一类异常是由于平台侧问题版本导致的，平台侧会进行大规模的主动升级来消灭这些问题版本。

最终在平台侧和用户侧双管齐下，形成 SLA 异常自愈的闭环，从而减少 SLA 异常次数。

在异常自愈服务里，其实最复杂的是背后规则的识别和决策。经过大量的积累，我们沉淀了几十种业务侧最高频的异常规则和治理方案，来全自动化地识别和消灭之前 “看不见” 的隐患，真正做到稳定性预防。

根据 SLA 异常的公式，除了预防来减少 SLA 次数，另外一个手段就是缩短 SLA 发生后的异常时长。

挑战在于线上一个集群就有近万个作业，但凡是集群级的故障都表现为定位困难、恢复时间久，再加上集群数量众多、分布广，故障的概率又增大，两者叠加，一年发生几次故障几乎就成了常态，稳定性整体很被动。我们需要转被动为主动，如果能在故障场景将业务的快速切流做到集群级的容灾能力，SLA异常恢复不仅能够缩短，而且还能增加其确定性。

容灾体系主要分成三部分：

第一，是往哪里切，实时计算对于网络的要求都是毫秒级，跨城有几十个毫秒肯定无法满足实时的要求。所以在平台侧部署架构上做了计算同城双机房部署，两两容灾，互为主备切流布局，解决了故障场景有地方可切。
第二，资源容量是有限的，平台这么大的体量不可能有容灾资源做预算，所以就需要做取舍。取高优先级的业务舍低优先级的业务，如何区分优先级？平台根据业务的场景建立了一套 Flink 作业的优先级标准，并配套着从申请到治理到整改，降级推出全过程的自动化管理体系，在业务侧精细化地区分优先级，确保真正高优业务的质和量。在资源有限的条件下，重保高优业务，以实现资源换资源。
最后一步是最复杂的，如何透明切走作业。核心的思路是复用存储，保证计算透明切换来确保业务的无感。

Flink 作业都是长生命周期的，带着 state 中间计算结果。首先要在集群的部署架构上做到计算和存储集群在物理部署上分离。计算集群出现故障时，比如基础设施出现异常等，可以通过切流将所有 Flink 作业平迁到另外一个灾备集群，但是 state 存储还是指向老的存储集群，就可以从原来的 state 点位恢复来实现真正透明的迁移，对用户做到无感。

除了日常的稳定性以外，双 11 更是稳定性的一场大考。Flink 双 11 的专项保障可以总结为 4 大块 8 个字，分别是压测、限流、降级、热点。每一块背后我们都沉淀了一套成熟的保障体系。

第一块压测指的是压测平台，首先提供给用户将生产到影子作业一键克隆的能力，其次还会提供大量大规模精准的造压、控压、稳压能力，并提供作业自动化性能的调优，以及最后一步生产一键上线全自动化的一站式压测解决方案。
第二块降级指的是降级平台，因为在大促 0 点峰值，需要将低优先级的业务快速降级来实现水位的合理控制。
第三块限流，还有一部分中优或高优业务，在大促状态不允许降级，但是能接受短时间的延迟，所以平台还基于 Linux 内核的 Cgroup 实现了作业 Pod 资源的隔离和限制，从而达到作业粒度计算精准限流的效果。
第四块是热点机器，也是大促最复杂的点。从集群层面看，集群卖出的资源和用户使用的资源是存在差异的，比如 1 个 Flink 作业申请了 10 个 CPU，而实际使用了 5 个 CPU，还有波峰波谷会导致集群层面水位不均衡。

上图第一个图显示，集群调度层面所有机器资源水位非常平均，CPU 和内存几乎在一条线上。但实际运行在集群上的所有机器的物理水位却参差不齐，因为调度是不感知物理使用的，所以随着集群水位不断提升，比如大促零点峰值的到来，集群的热点机器就会往更高去平移，某些机器在某一维度的资源会达到性能的瓶颈比如 CPU 使用了 95% 或者更高，从而就导致了热点机器。

而在分布式系统里，所有机上的业务是有状态并且有关联的，局部的热点机器不仅会影响集群稳定性，还会成为集群性能提升的瓶颈、造成成本浪费，也就是说，热点机器会是集群稳定性和水位提升的短板。

热点机器的解决是一个很棘手的问题，一般需要经历 4 个过程：

第一步是发现热点机器，包括热点机器的 CPU、内存、网络、磁盘，难点在于热点机器的阈值是来自 SRE 线上丰富的经验。
第二步是分析，我们做了一系列的机器诊断工具来定位热点的进程，包括 CPU 到进程、IO 到进程，难点在于要求用户对于 Linux 整个系统的原理有深入的理解和分析。
第三步是业务的决策和策略，从热点机器进程关联到业务的数据做决策，不同的优先级能接受的策略是不一样的。
最后一步，才是真正的解决热点机器，低优先级通过降级或均衡，中高优先级则通过径流来实现热点机器的下降。

这个过程背后涉及的东西包括对业务的理解比如优先级、资源、配置画像，对调度的原理的理解比如资源的分配策略、调度的策略，以及对系统内核的深度排查分析，还有业务的经验和策略 —— 到底是限流还是降级。这样全链路的界定和分析决策是一个非常复杂的技术难题。

我们正在做的是将热点机器的完整解决方案全部沉淀下来，打造一个基于 K8s 云原生的 Flink Cluster AutoPilot 来实现热点机器的全自动化自愈。

从部署形态上来看，AutoPilot 的服务是基于 K8s 进行全托管，按集群维度进行轻量化的部署，通过配置文件来方便地管理和运维。而执行阶段则是由 K8s 来保证面向终态，保证最终一致性。从 AutoPilot 的技术能力上来看，它是通过将热点机器的全面度分析流程抽象成 6 个阶段，包括热点机器的定义、感知、分析、决策、执行及全过程的可观测性，来实现整个热点机器全自动化自愈和高可观测性，提升集群的稳定性以及降低成本。

在过去的几年里，围绕着运维稳定、成本、效率三大核心价值，SRE 在 Flink Cluster 超大规模集群运维上沉淀了大量运维能力和更好的运维平台。但是随着云原生化大浪潮的到来，运维能力如何基于云原生变得更标准化，运维的交互界面、操作模式、执行模式以及运维过程的可观测性如何建立更加统一的标准，都会成为我们未来的重点发展方向。Flink Cluster AutoPilot 会成为云原生下新技术的载体，来承载运维体系的不断演进和升级。

三、应用运维 Flink Job

伴随着实时计算的大趋势，Flink 的用户和作业数经历了飞速增长，现在平台上的作业数已经达到了几万个。但是众所周知 Flink 作业的运维是一个非常复杂的问题，列举一些日常用户最高频的咨询，比如为什么我的作业启动慢，为什么 Failover，为什么反压，为什么延时，如何调整资源配置来减少成本？这些看似简单的问题其实都非常复杂。

Flink 的作业运维难点有两个方面：一方面是分布式系统全链路组件很多，依赖很复杂。另一方面是 Flink 自身尤其是涉及到 RunTime 层面时，原理很复杂。所以我们希望将我们自身丰富的运维知识，包括对系统全链路的调用流程，各个组件工作原理的深入理解，也包括日常和双 11 大促中丰富的排查问题的经验，以及优秀的排查思路，全部转化为数据和规则算法，沉淀为运维产品功能。

这个产品主要有两个功能，一个是 Flink Job Adviser，用来发现和诊断作业的异常；另一个是 Flink Job Operator，用来修复作业的异常。两者配套一起来解决 Flink 作业运维的难题。

上图是 Flink Job Adviser 最终呈现给用户的效果。用户只需输入作业名或链接，@一个机器人，就会调用 Adviser 服务。

比如 Case1，作业由于资源不足无法启动，Adviser 会给出诊断结果，是由于某个作业资源不足，并附上改进建议，让用户去控制台扩容对应的资源数量。

比如 Case2，用户的某一个作业 failover了，他想知道为什么。通过全域数据的关联，Adviser 给出的结果是由于平台侧机器下线或硬件故障自愈导致的，建议用户无需做任何操作，等待自动化的恢复即可。

再比如 Case3，由于用户作业内存配置不合理，频繁出现 OOM 导致 failover。Adviser 就会建议用户去调整对应计算节点的内存配置，避免新的 failover。

Filnk job Adviser 背后还有几十种针对复杂场景的异常诊断能力，构成了一个庞大的经验决策树。它不仅能够定位正在发生的异常，还有能力预防异常，主要由三部分组成：

事前部分，通过作业的运行指标和系统的全域事件来做预测，提前发现风险隐患，达到预防的效果，比如有作业发现的 failover 或者版本有问题等，这些异常还没有真正影响作业，通过体检能够发现这些问题。
事中部分，针对作业运行的全生命周期做诊断，包括启停类的问题，比如启动报错、启动慢、停止报错等，还包括运行起来性能不足、延时以及运行过程报错、数据一致性、准确性等问题。
事后部分，支持用户对于历史作业做全量的回溯。比如说想看昨天半夜 failover 的原因。

在决策树的具体实现里，选择了几个典型的、有复杂度的节点来进行分享。

第一个是作业全生命周期状态检查，一个作业从控制台提交到资源分配，再到运行环境、依赖下载，再到 Top 的创建，到上下游的加载，最后数据处理，整个链路是一个非常复杂的流程，Adviser 就是把关键节点的耗时和全量的事件统一收集起来进行分析，最终能够做到在作业任何状态做异常诊断和定位。
第二个是作业运行态性能类的问题，主要针对各类实时监控指标做异常检测，或通过经验值、域值的判断来发现和分析异常。比如作业延时了，那就通过节点找到反压所在的节点，再找到 TM 所在的节点，然后分析机器异常，最后发现可能是某台机器 load 高。以此形成整个链路证据链的推导，做到关联下钻分析，定位到真实的根因。
第三个就是最高频的问题，作业在运行过程中有报错。核心的思路是收集各个组件的日志，比如提交的日志、调度的日志、failover 和有 JM 和 TM 的日志，将这些海量的异常日志通过日志聚类的算法，包括自然语言处理和实际提取，来将一些非结构化的日志变成结构化的数据，再合并同类项进行压缩，最后由 SRE 和研发来进行原因标注和建议，形成一套完善的专家经验。