作者：行疾
相信近期从事基础设施工作的各位，对 IT 成本治理，以及 FinOps 体系的概念已经有了一些认知。在 Google 近 5 年的热度趋势中，FinOps 的趋势也在持续上升。
在阿里云的同学与客户实际工作协同中，我们发现成本治理是几乎每位客户都存在的普适需求，特别是各位技术管理者重要的关注点之一。据 FinOps 基金会 2023 年的报告，有 43%、24%、17% 的公司，是由 CTO、CIO、CFO 直接指派 FinOps 团队向他汇报，只有 14% 的公司处于还未建立体系化的降本增效的 KPI。
根据 FinOps 基金会的报告，建设 FinOps 体系 Top 的痛点非常复杂，包括技术方面问题、如何驱动工程师进行优化、如何减少浪费的资源、如何在容器场景做成本报告分析；同时也存在管理等问题，比如如何让团队组织适应 FinOps 体系等等。
我们希望阿里云在提供产品功能的同时，也能正确真正地帮助我们的客户落地自己的 FinOps 体系，真正让客户降本增效。
在 2023 年云栖大会现场，我们有幸邀请到某头部科技型量化投资公司的云基础设施负责人，为我们提供基于阿里云容器服务成本套件 ACK FinOps 落地的云原生场景成本治理案例，帮助大家了解在容器场景下的企业成本治理现状、挑战，以及如何结合 ACK 成本套件产品功能构建云原生用户自己的 FinOps 体系。
容器场景成本治理挑战与实践
本次分享的企业是中国领先的以人工智能和机器学习为基础的科技型量化投资公司，使用了大量的 AI、大数据作业来辅助量化交易决策，需要大量弹性的算力的同时，也需要更好的实现成本的控制，通过 Kubernetes 将 AI、大数据、工作流等作业放在一个集群中分时、弹性运行。
以该企业为例，业务系统大致分为几类应用部署形态：
1. 稳定的系统应用
2. 不特定时间的按需任务
3. 测试开发环境的应用
这几类应用都会消耗基础计算资源，并产生成本。
目前该企业部分业务在使用阿里云容器服务 ACK 集群做容器化部署，通过 Kubernetes 进行量化交易的数据执行与决策，及阿里云 ACK FinOps 套件实现成本的洞察与分摊，经过治理后实现了近 30% 资源水位的提升。
在企业成本治理的实践过程中，该企业主要遇到规划难、分账难、管理难、优化难这 4 方面的挑战。
- 规划难
在进行成本治理方面工作时，首先遇到的挑战是按需任务、测试开发环境的容量规划问题。开发、测试应用在容器化部署架构下，实现快速迭代的同时，难以较准确地给出分配的资源量。过度分配资源会导致资源浪费，资源超售过度则会导致稳定性问题。
- 分账难
该企业的云基础设施每天为很多的上层应用提供服务，多个容器应用共享一个 K8s 集群。一个计算节点上可能运行多个 Pod，而且 Pod 可以弹性伸缩，在节点间动态迁移。多个业务应用混部在同一个池化的 K8s 集群中，难以把整个集群的账单分摊到应用和人。应用层与资源层计量计费在空间、时间等多个维度都无法做到一一对应，成本治理的复杂性业因此而来。
- 管理难
另外，由于各个应用的使用场景存在很大差别，每当找出闲置浪费的资源后，往往难以“爽快地”马上缩容下线资源，如何在优化资源成本浪费的同时保障业务的稳定性，一直是一个难以回答的问题。
- 优化难
容器化后是拥有各种丰富的成本优化手段，但“这样调低 request 资源分配水位后，是否影响业务？”，“现有的 HPA 弹性伸缩策略，是否能在业务真正需求资源时正确工作”，甚至于“我现在要下线的网络、存储资源是不是真的没人使用？”
云原生技术中例如弹性、混部、Serverless、超卖等技术都有各自适合的典型场景。如果使用不当，比如弹性配置错误，可能带来意想不到的资源浪费甚至稳定性问题。
如何解决分账难题
首先要面对分账难问题，理清花费在哪儿是最重要的工作。
站在 Infra 团队的视角，一直以来和上层业务、应用层的部门同事的协作工作方式都是：
当新业务需要上线、或老业务需要扩容时，业务部门会申请告诉我们他们“期望”使用多少的容量，为了保证业务稳定性，资源需求往往拍脑袋定义，且业务团队都希望申请冗余远远超过实际预期的资源量。
长此以往，集群的水位就会出现大量闲置。
由于业务是容器化混合部署的应用在同一集群中，应用的水位分布也往往呈现长尾效应，稳定的大规模应用往往经过重点优化已经有较高的资源利用率，但大量小规模应用使用大量闲置资源。
传统部署模型下的资源成本统计方式，是按业务使用的节点维度分析成本，但是在 K8s 场景下，业务使用的资源统一从资源池中调度，业务对资源浪费也隐藏在整个集群、节点的水位中难以发现。
要算清这本糊涂账，一定要把成本归因到具体某个业务应用，甚至是具体到某个人，才能推动真正地降本。怎么把成本归因到具体业务，首先需要精细化的监控数据，来看清业务对资源的使用情况。
阿里云 ACK 团队可以为企业提供详细的成本、资源观测数据，包括：
1. 每天每笔云上资源的真实花销成本账单
2. 每个容器部署的资源使用量、使用水位
部门、业务、个人这些业务层层级关系，该企业通过按集群的 namespace、不同工作负载、任务通过打特定 label 的方式，最终与具体 K8s 集群中的花费资源成本的 Pod 进行映射。最终通过结合阿里云 ACK 成本洞察数据的方式，可构建多个不同视角的成本资源监控大盘，包括：
1. 每天每笔不同云资源账单维度的监控大盘
2. 归因到业务应用/个人的监控大盘
由此，便于分析发现应用维度的浪费，如形成 Top 浪费的应用报表，进行数据驱动地成本优化推进。
面对成本管理难题
Infra 团队在推动降本增效时往往是无力的，更多需要推动跨团队的协作。
站在一个业务应用的上线过程来看协同关系，Infra 团队往往职责是接受上层业务层同事的需求，以及保证提供资源，这里的需求关系是从业务层到 Infra 层是至顶向下的。然而 Infra 团队与成本资源花销的距离是最近的，感知是最深切的，所以往往需要由 Infra 团队来推动成本治理，构建 FinOps 体系的建设。这里的路径在跨部门的协同关系上反而是至下而上反方向的。
Infra 团队就算找到对应的业务团队，推动他们缩容、下架掉闲置的云资源，往往由于没有数据驱动或对降本增效清晰的认识而难以开展工作，最终会导致极其低效的降本增效，白白浪费 Infra 团队工程师们宝贵的时间。
我们不妨换个思路拆解一下解决方案。首先需要明确，所有人都需要对降本增效负责，且需要划分清晰的责任范围。以该企业为例，业务协同主要分为三大类角色：
- 业务应用团队：负责业务应用的具体研发
- 业务平台团队：负责为业务应用提供通用业务能力
- Infra 团队：为以上团队提供基础设施
顺着成本治理的至下而上的路径，该企业划分了成本治理清晰的权责范围，以及通过构建不同视角的成本监控大盘构建统一的数据驱动成本洞察体系。
首先对成本资源感知距离最近的 Infra 团队：
拿数据说话，驱动业务团队优化。
通过集群的 overview 整体视角的监控大盘，从集群、各项云资源、节点等视角，界定确定性的浪费资源，以及通过对各集群资源使用的 breakdown 分析，找到成本问题的症结所在。
对于业务平台团队，从业务预算、Quota 层面驱动业务成本优化。
每个业务也需要从财务层面做成本治理，这里业务平台团队通过成本洞察的数据，结合财务的预算，形成统一的报表、监控。如预算超标，需要透传分配 Infra 团队根据 breakdown 数据，进行成本分析。
业务应用团队，需要选择科学可靠的成本优化手段。
作为应用的研发，使用业务平台、Infra 平台，他们是对业务、代码最了解的专家，也是需要平衡资源浪费与应用稳定性的最终负责人。在 FinOps 体系中，ACK 成本套件为他们提供应用视角的监控大盘，清晰观测自己应用资源、成本水位的同时，判断收敛后的资源水位是否合理，以及对自身业务变化规律来制定科学的弹性策略以满足动态资源的需求。
如何规划资源 & 成本
有了以上的分账、跨团队协作的解决方案后，我们来看规划难的问题。新业务上线需要规范流程，制定合理的容量规划。而新业务、跑批任务等，经过上线前压测，通过经验值或成本套件资源画像等只能推荐出科学的资源规格配置。
针对这个问题，在上线过程可以使用 ACK AHPA 等智能弹性策略来做到动态业务趋势的智能资源调整。
每个业务都不应该无限申请成本。把成本、资源归因到个人，同时也需要根据业务量、资源趋势制定财务预算，以及成本 Quota 计划。合理地进行成本控制。
部门、业务、个人的成本预算，应按应用使用比例分摊到集群中的应用部署、Pod。该企业的做法主要是通过 namespace、给容器副本打业务 label 的方式进行映射。最终预算与归因到对应业务后的实际成本花费进行比对。
成本控制方面也是通过 API 集成 ACK 成本洞察的成本数据后，细粒度到业务应用、个人来配置的成本超预算报警。
寻找稳定和成本间的平衡
最后，在真正进行资源优化过程中。平衡稳定性和成本浪费是非常重要的。
首先对于浪费发现，存在两部分浪费：
- 首先需要发现确定性的浪费。完全没有使用的网络 SLB、EIP 等资源，长期空闲的节点等，这些可以通过 ACK 限制资源检查找到这些确定性的浪费。
- 第二部分是非常普遍的，应用的资源浪费。虽然平均集群资源利用率经过优化达到了约 50%。由于是容器化混合部署的应用在同一集群中，应用的水位分布也往往呈现长尾效应，稳定的大规模应用往往经过重点优化已经有较高的资源利用率，但大量小规模应用使用大量闲置资源，隐藏在整个集群中难以发现。这里可以通过拉取 ACK 成本洞察的 Pod 维度的成本资源数据，归因浪费到具体应用/个人后，会使这些应用的碎片化浪费逐个暴露出来。
科学合理的 Quota 设置
对 K8s 有经验的使用者，对 K8s 资源分配量(Request)、资源限制(Limit)两个值应该会有深刻的理解。科学地配置工作负载的 Request 量可以帮助进行容量规划控制资源成本，Limit 资源限制则可以实现混部的超卖和保证应用的稳定性。
通过统一 K8s 集群上应用的 request、limit 设置规范，通过业务量压测、预估经验值，结合根据历史资源使用量的 ACK 资源画像智能推荐的 request、limit 值，该企业可以做到科学地为各个应用设置合理 Quota，平衡业务稳定性和成本浪费。
合理地使用弹性策略
HPA 很先进，但激进的 HPA 配置会导致应用不符合预期地扩缩、甚至导致业务稳定性；保守的 HPA 配置可能会导致还是会有大量闲置资源，起不到太多成本节省的效果。
云原生技术中例如通过业务指标进行 HPA、CronHPA 等都有各自适合的典型场景。在该企业中也有部分业务应用使用 HPA 策略。首先比较确定性的场景如周期性的业务，使用 CronHPA；同时，参考成本、资源监控数据优化阈值，通过HPA的历史数据，保证资源的流转效率。
在决定 HPA 的指标的选择上，该企业会先区分 CPU 密集型的业务还是内存密集型的业务，根据调度的关键资源指标作为 HPA 的决定值。在一些新的业务，没有能参考的资源指标场景，也在使用 ACK AHPA 智能 HPA 策略，形成动态智能的弹性扩缩。
整个成本治理工作是一个复杂且综合性的事务。经过近一年多，目前在 IT 成本上节省约 25% 的成本，超过月 10w+ 的成本节省，部分集群资源利用率从 20% 提升至 50%。
在整个实践的过程中，该企业也定义了资源流转效率指标，一个业务应用通过弹性扩缩对新资源的使用率，来反映一个应用对资源的浪费程度，资源流转效率越大代表越节约。目前经过IT成本治理，资源流转效率有了 20% 的提升。“我们也希望通过本次分享我们在 IT 成本治理方面的工作经验，帮助其他互联网金融客户等云上客户更好地建设 FinOps 体系。”
阿里云 ACK FinOps套件助力容器成本数字化治理
阿里云 ACK 团队希望提供真正能帮助用户在容器场景构建 FinOps 体系的产品能力。在深入沟通、了解企业对于容器成本治理的需求和问题后，我们总结出通用的三大 FinOps 治理流程：成本洞察、成本优化、以及成本控制。
在成本洞察中，ACK FinOp 套件提供多维度视角，帮助用户把集群中业务成本归因到组织和个人。成本洞察能力经过更多客户场景的打磨，推出更科学的分账算法，同时目前支持通过 API 让客户进行二次开发，以及如极氪汽车等多云场景我们支持多云成本适配器，帮助多云、IDC 机器混合等场景下成本治理保持统一。
在成本优化中，我们提供资源画像功能，智能推荐应用优化配置，并通过 Koordinator 在离线混部组件进一步提升资源利用率。以及提供 CronHPA、 AHPA 等丰富的自动弹性扩缩容策略。并提供智能资源浪费巡检。
在成本控制阶段，ACK 将提供成本洞察大盘周报功能，直接抄送成本周报至对应业务团队更能推进团队进行成本优化，并树立 FinOps 建设意识，提供费用趋势预测，帮助刚好地指定业务预算，最终进行成本控制。
看清成本、找出浪费，永远是成本治理的第一步。ACK 成本洞察功能帮助用户构建数据驱动的成本观测能力。
ACK 成本洞察功能提供开箱即用的集群成本大盘，实时计算出多维视角的集群应用成本账单，以及提供不同资源配型，如包年包月、抢占式节点的横向比较，以及推荐不同的节省策略。同时，下钻到应用层的应用视角成本大盘，提供对应用浪费资源程度的 Top 排序，清晰明了发现混部隐藏在集群中的应用浪费问题。
Infra 团队和上层应用团队需要按统一的口径进行成本分账。云原生场景架构复杂，不同应用形态也会在混部场景中对调度资源产生影响。ACK FinOps 提供独有的云原生容器场景成本分摊与估算模型，通过衡量应用对调度的影响大小，更科学合理地对应用成本进行拆分。
多数用户的应用可分为两种场景，如 JAVA、J2EE 部署的应用，多为内存密集型场景，如跑批的分布式计算任务，多为 CPU 密集型场景，此类场景，CPU 或内存、甚至 GPU，会作为集群调度的关键资源，决定应用是否能被调度。此场景我们推荐单资源分摊模型，按关键资源进行分账。
如一个典型场景，用户在 ACK 集群的 GPU 节点跑 spark 的跑批任务，GPU 资源是当前最影响调度的资源，所以该应用的成本，应该按当前应用运行时间内占用的 GPU 资源来拆分整个节点的成本。
混部场景的用户，作为云原生的深度用户，一个集群中会有内存密集型、CPU 密集型等多种应用混部，此时每种资源都决定调度策略，此时我们推出按资源调度水位计算的权重混合资源分摊模型，此模型计算一个应用应该分摊的成本，是由他所申请资源影响可调度资源的部分决定。
ACK 成本洞察可通过混合资源分摊模型，按每个应用对调度的影响，自动计算出合理的应用分账成本。
看清了成本浪费后，云原生容器场景下有复杂的架构体系，如何进行优化往往无从下手。
ACK FinOPs 成本套件梳理出 ACK 成本优化路径落地的最佳实践，帮助用户在同步场景选型不同的成本优化方案。如业务应用经常波动的场景，可以通过感知业务的波动，选择自动弹性策略、或通过混部场景的动态资源超卖等提高资源利用率。在不感知业务的情况下，可以检查是否已经是最优的资源配型等。
确定性的浪费是我们首要需要找出来并收敛掉的。
真实生产环境中，Infra 团队不敢轻易删除集群里的资源，在此 ACK 成本套件推出闲置资源巡检功能，帮助用户找出集群里确定性的闲置资源。这里通过找到处于未使用状态的资源，但在出账时却被计入本集群的成本的资源。
包括无业务应用使用的 云服务器 ECS、块存储、负载均衡 CLB 和弹性公网 IP 的闲置检查。
根据 FinOps 基金会的 2023 年报告，对云资源的更大利用率使用，以及如何驱动工程师团队采取优化措施是现在 FinOps 体系中最令人头疼的问题。
在容器场景混部、动态的应用环境下，ACK 资源画像功能可以提供基于应用历史数据的智能资源配置推荐功能。
千人千面，在容器场景下是一应用一画像。为每个应用智能推荐升降配策略。解决应用刚上线、或应用业务波动大，无法正确容量规划问题。资源画像的核心技术点在于提供同时平衡过冗余时的浪费且保证过度超卖的稳定性的推荐算法。我们的推荐算法主要考虑了以下 3 方面：
1. 使用多种资源维度进行统计，并使用类似分位数的统计方法区分应用突发峰值需求和日常资源需求。
2. 使用半衰期华东窗口模型，确保新的数据对算法模型的影响越大，越旧的数据对算法的影响越小。
3. 以及考虑了容器运行时状态，参考容器的 OOM 等运行状态，进一步提高推荐值的准确性以及保证稳定性。
用户为什么要云原生容器化，除了使用统一标准化的配置方式规范地使用云资源，更大程度也是为了享受集群池化的资源带来的资源利用率提升与系统稳定性的平衡。
HPA 弹性伸缩策略是 Kubernetes 技术生态对这一平衡的重要体现。ACK 容器服务提供丰富的 HPA 弹性策略，针对不同的场景。
- 标准的 HPA，主要解决的业务负载压力波动比较大时，需要人工根据监控来不断调整副本数的问题，实现自动扩缩容。
- VPA 垂直扩容 Pod 所在的节点，主要解决资源配额（Pod 的 CPU、内存的 limit/request）评估不准的问题。
- 非常实用的如上文企业面对的周期性波动的应用场景，使用 CronHPA，定时水平扩缩容。基于可预期的时间，提前规划扩缩容 Pod 数。主要解决在可预期的时间，资源不足的问题。
同时我们也提供一些领域垂直的弹性伸缩解决方案，如业务事件驱动的 Keda、以及 Serverless 场景支持如灰度发布等场景的 knative 等领域弹性伸缩解决方案。
HPA 的配置确实需要根据应用具体场景，如是否波动，来决定具体选择哪种 HPA 解决方案，以及关键指标应该如何选择等。很多同学看到这里就知难而退了，这里有太多的 HPA 策略，复杂的场景，难以规划的阈值参数，需要丰富的 K8s 经验。现在 ACK 推出 AHPA 智能弹性策略功能，解决这个问题，也让我们窥见了下一个阶段 HPA 弹性策略的新形态。
AHPA 通过收集应用 Pod 的历史数据，通过智能的周期检查+预测算法，结合 ACK 专业的 K8s 应用部署经验。
1. 通过资源提前预热，解决 HPA 弹出滞后性的问题。
2. AHPA 自动配置阈值，智能识别业务指标曲线，无需人工干预，自动弹性规划。
3. 支持配置弹性降级保护，快速兜底容错。
1. AHPA 使用资源提前预热的方法，根据智能算法提前预测将要发生的弹性对资源的需求，实时调整资源容量。正常客户的 HPA 拉起新的 Pod，需要经历如资源调度、拉取镜像、等待容器启动等耗时过程，AHPA 预热后解决客户弹性之后性的问题。
2. 通过历史数据的智能预测，无需人工干预，自动规划弹性策略、阈值，解决阈值配错、不好配的问题；以及 AHPA 与标准 HPA 相比，更合理阈值的配置也解决了弹性的滞后性问题。
3. 对突发的业务流量收缩，支持配置弹性降级保护措施，避免过保守的 HPA 策略不能降本增效，过激进的 HPA 策略面对突发情况时会影响业务稳定性。在提升资源使用率的同时，保障业务的稳定性。
希望通过我们的分享，能够帮助更多企业了解在容器场景下的企业成本治理现状、挑战，以及如何结合阿里云容器服务 ACK 成本套件产品功能，构建企业自己的云原生 FinOps 体系。
点击此处，了解 ACK 云原生 FinOps 套件功能和治理流程详情。
