云监控 Barad 的云原生实践
赵轩，高级运维工程师, 腾讯云监控业务运维负责人。
腾讯云监控的 Barad 产品，为云产品提供高效、低成本的海量指标监控服务。 Barad 业务经过云原生能力建设以及容灾能力建设，业务已经实现了自研上云全量级容器化部署及多可用区容灾能力。
Barad 业务上云面临的难点和挑战
在降本增效的大背景下，腾讯云 云监控团队继续提升云原生成熟度，提升系统承载能力和降低单位成本，包括对 Barad 业务在容器化占比提升，跨 az 容灾能力建设，资源利用率优化这些方面，因 Barad 业务量级庞大，如何保障大量级数据的稳定处理以及单位成本的优化，这里都有着不小的挑战：
- 底层设备量级大，整体上云后并发，时延，稳定性保障
- 系统架构复杂，底层模块和旁路功能涉及 40+，迁移这类能力时的稳定性保障
- 海量上报数据实时计算，准确性和实时性的保障
- 业务迁移场景时告警时效性和可触达性的保障
- 大数据处理相关模块迁移上云的性能稳定性保障
- 接入业务多，适配场景众多，控制台使用稳定性保障
- 监控数据存储量级大，存储迁移的查询稳定性保障
整体架构：
关键优化动作和效果
针对这些难点我们进行了如下优化操作，包括:
- 基础业务迁移 TKE 容器化部署
- TKE+TKE Serverless 弹性调度能力提升
- flink 集群容器化建设
- ctsdb 双写并开启压缩能力
这里将 Barad 的业务调优动作对大家做以介绍，以便于大家针对自身业务特点进行相应的云原生渗透力提升以及容灾能力建设。
Barad 接入上报模块 TKE 容器化部署:
业务容器化拓扑结构：
Barad 业务的上报模块之前使用织云平台进行经典模式部署，该模式没有弹性调度能力以及资源容灾特性，根据业务现状，我们对上报服务进行 TKE 容器化部署，以解决集群弹性调度能力和多可用区容灾建设。
在使用 TKE 部署中业务同学需要保障在迁移过程中的数据稳定上报，因为 Barad 作为腾讯云基础监控业务，任何的改动都可能造成用户的监控数据丢失或断点，针对这个情况，Barad 在部署业务时多次进行小地域验证，保障数据切换的平稳过渡。
上云过程中，Barad 业务也遇到了很多瓶颈，在使用 TKE 集群时的并发能力保障上，这里针对集群机型，进行了特定的并发能力配置保障，在业务上报 clb 这里一并进行了带宽上限保障，以保证客户数据万无一失。
TKE 弹性调度能力部署
目前针对 Barad 业务稳定性提升，我们对部分用量伴随时间变化的服务开启和 HPA 弹性调度能力，在业务 CPU 用量占 limit 80% 时或并发数超过 90 万时进行多维度多条件弹性扩充 Pod 数量，保障业务运行中的量级突增，提升业务的可用性和稳定性。
TKE 跨 az 容灾能力建设
Barad 业务进行了多可用区资源置换操作，对 TKE 集群进行多可用区优化，实现了 Barad 业务的各地域 TKE 集群跨 az 容灾能力建设最终 Barad 上报由经典部署模式迁移至 TKE 集群部署，提升集群弹性扩充能力和负载上限，并具备了跨可用区调度能力。
TKE 集群优化效果
优化缩容必须确保服务稳定和未来可能突然增长造成影响，为此，这边做了两个监控分别监控资源和指标。
资源可视化监控:
集群节点利用率可视化监控:
TKE +TKE Serverless 弹性调度能力提升
TKE 容器化后除了上述的优点，也带来一些问题:
- 每个集群自备 CVM，无法共享资源，集群装箱率较低
- 预留资源应对业务突增扩缩容
- 跨 az 容灾人工运维成本较高
TKE+TKE Serverless 架构
基于上述问题，我们调研了弹性集群，具有高弹性、低成本、无需进行节点扩缩、按需使用，降低成本等优点。但是由于存量 TKE 集群迁移弹性集群工作量巨大，希望在 TKE 集群上直接获得上述能力。调研发现，TKE 的超级节点可以满足我们的需求，解决上述问题。为验证超级节点的可靠性，我们在多个小地域做验证，调度及服务稳定都符合预期。另外跨 az 容灾能力，相比之前使用 TKE 集群自备 CVM 的场景降低了跨 az 建设初期的运维成本。
超级节点相当于一个资源池，只要创建的私有网络有 IP，就可以自动调用跟 Pod 配置匹配的节点，再不用每个集群自备节点，达到资源复用的目的。不用每个集群预留 CVM 应对流量突增，降低成本。另外，可以使用多个可用区的私有网络达到自动调度到多个可用区节点，完成跨 az 容灾能力。
目前，我们已经开始了 TKE Serverless 弹性调度能力提升的部署模式，该模式在保障业务数据上报及处理稳定性的前提下，对集群弹性能力有了很大的提升。
flink 集群容器化建设及利用率提升
flink 容器化
针对于流计算 flink 集群的云原生渗透力提升，我们在今年上半年开始了 flink 集群容器化建设，该操作目前已实现 Barad 小地域全覆盖这些地域的整体架构实现了 100% 容器化建设，提高了流计算集群的弹性能力，
量级在中小量级 150cu(此数值为经验值，一般没有大型作业)以下的集群的隔离性能提升，无复用资源问题，小地域 ec 区可以降低整体配额 60%，消除管控机型预留问题。
在容器化之前，集群采用 EMR 模式，每个集群由管控节点+worker 节点组成，管控节点的构成分为 ClusterAdmin，Common，NameNode，DataNode 等节点构成。这些节点都是小机型(2U4G和4U8G)然而这些节点的数量和集群规模没有关系，每个集群至少都要这么些管控节点。（5个2U4G，6个4U8G）
而 TKE 集群的管控节点固定为3台（4U8G）。
模式 | CPU | 内存 | 其他 |
|---|---|---|---|
EMR | 34 | 68 | |
TKE | 12 | 24 | CDB节点做数据库，1CU2G |
以上是仅仅替换集群模式就可以节省 22 个 CU。150CU 下的集群数量有 30 个。则通过置换，可节省资源 630CU。
ps: 替换资源选择建议 16CU 的小核心机器。原因是每个节点固定会有两个 CU 被预留给 TKE 的管控信息通信。大于 16CU 可能就不灵活，而 8CU 的话 CU 实际工作的占比又太低。
flink 资源利用率提升
节点替换，腾笼换鸟
TKE 相对于 EMR 集群，其中一个特点是更强的隔离性，EMR 集群下内存隔离性能保证，但是 CPU 隔离性较弱。同一个机器下的作业，可以调度到分配之外的CPU(只要没有被使用的话)。这就会引入一个现象:EMR 集群下性能弹性空间会更大，CPU 利用率可以超过 100%。
而实际集群使用中，由于历史遗留和资源不足原因，我们用一些 CPU 内存不是1:4 标准配置的节点来搭建集群，比如 16U32G。就会更容易出现这种现象，因为这个节点会被看成 8U32G 来提供资源，那这样就会有 8U 对用户是不可见，于是就被闲置了。直到哪个作业超用，才会被使用上。
通过资源合理性替换我们可以将一些机器替换成 1:4 的机型。这样无效的 CU 就释放出去，可以达到成本降低的效果，前提条件是 CPU 不能超用。毕竟有些作业现在已经是 CPU 利用率超 100% 运行着。
共用冗余，合理布局
在容器化和缩容/替换 后，资源得到了充分利用，但是为了保证稳定性，针对我们 Barad 作业故障场景，我们还需要有一些临时备用的冗余空间额外拉起作业"补算"，如果缩的太厉害，可能补算作业无法运行。因此。对这种情况，各个地域缩容后的节点可以单独再起一个集群，平时低负载运行一些小型作业，需要补算时，会临时拿来进行离线补算。
此外，将大型作业，动辄 300CU 以上的作业，单独搭建集群运行。保证充分使用 CPU，也不用担心被其他作业的运行影响（EMR 的隔离现象）
计算型 or 内存型
在进行容器化改造和资源利用率提升操作时，我们发现影响稳定运行的，往往体现在某些资源不足。具体表现为内存或者 CPU。我们发现有些作业容易 OOM 的，CPU 可能还没有到 100%，而有些作业 CPU 已经接近 200%，内存还有大量空间。这两个作业对资源的依赖不同。前者可以称之为内存依赖型，后者则是计算依赖型。
在 TKE 集群使用时，如果作业想要充分利用 CPU 效率，那么可以对粒度进行调整。
举例，原来如果作业并行度为 10，默认情况下为 1CU。那么转成 TKE 时，并行度为5，taskmanager 规格替换成 2CU。总共 CPU 数量不变，但是性能表现却会更好。
flink 容灾调度
flink 集群目前已在云监控管控平台中集成 flink 集群批量异地拉起能力，可保障地域异常时流计算作业快速在其他地域拉起，保障业务数据完整性。
对于还未升级的集群，我们对空闲 CU 进行缩容调优，将利用率从 40.2% 提升至 55.4%
ctsdb 双写并开启压缩能力
Barad 使用 ctsdb 集群对海量数据进行存储和查询，ctsdb 数据库具有以下特点：
•分布式、可扩展、支持近实时数据搜索与分析的时序数据库
•高效读写、低成本存储、强大的聚合分析能力、实例监控以及数据查询结果可视化等功能
•多节点多副本的部署方式，保证数据高可用性和安全性
ctsdb 开启压缩能力
针对不断增加的业务存储量以及客户查询稳定性的需求，我们在保障客户数据完整的情况下，对各地域集群进行 es7 版本升级操作，开启压缩能力，优化集群存储总量，提升海量数据的承载能力，并优化资源利用率。
操作过程:
- 将 metric 表的副本数设置为 1，保障新创建的 index 有 1 个副本
- 将集群中副本数为 0 的 index 设置为1，避免因升级过程中的异常导致数据完整性缺失
- 删除 564 版本无用索引
- 在容灾集群预创建 index，避免因开启双写后批量创建 index 而影响了原集群的写入速度
- 开启双写，原集群与容灾集群同时写入，提供双重保险
- 升级操作，在双写运行 1 天后，对集群进行升级操作
- 完成升级后，关闭双写，开启压缩能力，后续数据写入时将被自动压缩
ctsdb 升级 es7 版本以后存储总量压缩 50%，并保障数据的完整性， 下图为开启压缩一个月后的存储量级变化情况：
在升级过程中我们使用多地域容灾集群进行双写，保障升级过程中的数据写入和查询的完整性，目前已完成国内各地域的升级操作。
ctsdb 容灾调度
目前我们在对 ctsdb 定制了全量级异地调度方案，每天定期在容灾集群对现有 metric 和 index 进行预创建操作，并在监控管控平台中集成了容灾双写能力开关，在业务异常时可以进行容灾调度，保障客户数据完整性。
Barad云原生实践总结
云监控 Barad 业务经历了为期半年的云原生渗透率提升，跨 az 容灾能力建设，资源利用率优化这些优化动作之后，云原生成熟度增长明显，且业务稳定性有了大幅提升。
下一步，为了进一步提升资源利用率以及动态弹性扩缩容能力，我们将继续推进业务基于 TKE Serverless 架构的落地问题解决和效果优化。
