本篇演讲的主题是高性价比、智能日志更新关键技术解读由阿里云1s团队的贾新寓讲解。
今天演讲分为四个部分。首先回顾日志场景的核心痛点接着介绍日志分析形色问题的四大关键能力,随后介绍这些关键能力背后的关键技术,最后快速演示如何接入Serverless产品。
一、日志分析型Serverless 能力介绍
1. 核心痛点
众所周知ES在日志场景应用广泛大量的企业使用eo kefk作为其基础设施,公有云上和集团内部也有大量用户使用es。作为其日志分析引擎,在用户的长期沟通中,发现日志分析场景最为核心的痛点为性价比。其具体表现有以下四点:
一是资源成本高。为了存储海量的数据,保证安全的水位,承载突发的流量需要预留住大量的资源,造成成本居高不下。
第二是运维成本大。在海量场景下,索引下的副本有策略等非常复杂,尤其是在pb级的数据规模下,数百个节点的状态同步数10万个下载的索引搬迁。这些开源的es早已无法支持,因此团队需要投入大量人力来解决这些问题。
第三个是在严格限制成本的情况下,性能难以保证。
第四在稳定性上是一个很大的挑战。因为开源es读写相互影响,而且缺少熔断能力。在负载高时,比如cpu超过50%,处理能力断崖式下跌。造成用户一系列实际痛点问题。es自2017年上线以来,一直着力于解决此类问题。
2. 产品改善
2021年我们推出INdexing service通过读写分离以及写入持化,将写入能力提升了800%,并且实现了写入按流量计费,这让用户再也不用为写入性能担忧。在2022年,我们推出openstore这种存在分离架构,通过多级智能缓存机查询优化,实现了查询性能不下降的情况下存储成本降低70%,并且实现存储的按量付费。而在去年,我们基于前面积累的经验,在内部推出了logo这种serverless形态的这种日志产品,让用户无需复杂配置开箱即用,取得了非常好的效果。
所以在今年我们将这一产品推到工作云上,成为日志分析型Serverless来帮助云上的用户降本增效。接下来是我们内部的livehouse下取得的成绩。如图,之前的日志全观测方案将平均成本降低到51.44%,每月为公司节省了数百万元,其中在菜鸟某业务和高德某业务中更是下降了78.04%和64.86%,效果非常显著。
二、日志分析型Serverless 能力介绍
1.开箱即用
主要有四大关键能力。首先是开箱即用、兼容开源。这使得所有的api和sdk都和开源保持一致。用户无需任何代码改动,也不需要适配特殊的sdk,可直接使用,这样极大减低了用户的接入成本。
3. 高性能低成本
通过在日志分析场景和定制优化,大幅提升到单核的处理能力,又降低了存储的成本。第三是真正的按量付费。和之前的按量付费有很大差异,搜索版本上实现了按cpu用量付费,稍后将用数据给大家展示该版本带来的成本差异。第四个是智能调度免运维。在我们的serveless场景下,用户不仅不需要关心汲取运维以及数副本数,只需要关心数据保留天数,数据的自断类型即可。下面就一一为大家展示。首先是我们的开相机用能力。
大家可以看到左边的这幅图是KABALA。我们在我们日志分析,KDAS依旧可以用大家熟悉的PIBALA的api,然后包括一些kiting des 这种基础的es原声api来直接使用和开源eS5e。为了充分地兼容开源,并没有使用派克中的数据流I'm等策略,直接在原始锁影上进行拓展,让每个锁影都可以自己设置他的保留天数。第二个关键能力为高性能低成本。可以看到最左边的蓝色的是serverless中间是pass上的日志增强版,最右边是最佳实践下的开源自建。
可以看到日志增强版,比开源的最佳实践及生产提升两倍多。而seveless在单核注意能力上又比日式增强版提升了两倍多。整体比开源的最佳实践提升了4.5倍。而在压缩比上,更是从1.93提升到了5.8。这是在最佳实践下的开源自建才能达到1.93的效果。如果没有丰富的es优化经验,直接使用es就无法到达1.93,而是0.8,成本也会很高。
4. 按量付费
我们是真正的按CEO付费,而不是按流量付费。接下来讲解两者的区别。左边这幅图是在同样的遗迹流量下,因为表结构造成的不同带来的ceo消耗的差异。从最大的110ceo到最低的46ce相差将近24倍。也即按ceo付费比按流量付费可以节省将近50%的成本。而在今年除了存储和写入实现了按量付费,在查询上也实现了100%按实际用量付费。大家可以看一下,右边两幅图上面的是查询的ceo用量。下面的是qbs两个曲线是完全一致的。这说明用户是100%按他自己用量做付费。
5. 智能调度
最后是智能调度免运维的演示。这边三条线最底下的一条是用户的实际的ceo消耗中间的这一条是配合限制线最上面绿色的是我们的资源线。为了方便演示,我们把资源线设置到了一个上限120,大家在实际使用中,没有上限。大家可以看到在业务水位平稳增长的一个场景下,基本上是不可能遇到我们的配合线,整体的用户是透明无感的。除了在资源上的自动过多,我们会通过一些自动化手段来调整集群和所有的配置让索引始终运行在一个最佳的状态下。
三、关键技术解读
1、整体架构
在屏幕上的这幅图里,左边是数据面,右边是管控面,数据面是经典的三层模型,最上层为服务层。通过服务层带领请求分别到读写和原数据服务。最底下是共享存储。右边的管控面主要则是应用管控系统和智能运维系统。第一个特性开源兼容就是通过这一层服务层的包装来实现的。
(1)高性能低成本的引擎架构
通过读写分离和存在分离架构,索引只需构建1次,让本地存储也不再成为瓶颈,弹性成为可能。左上角是写服务,右上角是读服务,底层是存储服务,正如上图所说,通过网关层把读写服务,读写流量分别录留到读写服务上进行对应的计算,直接存储到openstore中, 而不是本地store。其次,优化了底层的数组机,我们将X86的数组机换成了倚天机型,这使得安全水位从30%提升到了50%,相当于资源利用率可以提升到66%。下面解释提高安全水位的原因。在图中,曲线的红色是倚天,而黄色的这个实线是X86,可以看到,当整体cpu超过4%时,在X86上性能会有急剧的退化,而在整个倚天上性能相对稳定。
(2)es内核优化
除却在架构上的优化,我们在es内核上也做了大量的优化。但是由于篇幅限制,给大家主要讲解四个优化。第一个是sourcedocvalue,即不存原文,当用户需要原文的时候,我们从docuvalue中获取原文,这样可以极大地减少存储空间,并且可以让写入速度更快。右上角这一幅则是定制化的分词器。因为es原生分词器为了通用性,会有非常多的冗余计算。我们可以针对日场景专门定制nanunas的分词器,通过这一特性,使其性能提升了20%。
接下来的左下角是指用xtd压缩替代es原身的压缩算法,并且通过定向路由机制,使得压缩率更高。而右边则是在一些特殊的缩影子段上,不存index只存ducuvalue包括在查询时通过不同过滤器进行快速减脂。通过一系列的优化,使得单位资源显著性能提升300%,存储减少70%。
(3)查询的大量优化
众所周知,在存站分离场景下,如何保证查询性能是一个很大的挑战,而我们通过并发查询,以空间换时间将多次io变成1次io将oss查询提速200%。左下角是kbala的discover页面,用过es的人可能知道当es数量很大的时候,比如达到百亿,这个页面需要很久才能刷出来,甚至十几分钟才能刷出来。我们针对这个场景做了一系列的定制优化查询策略,并且做了大量的查询点支分片类的并发查询,使得百亿数据检查提升十倍。使得百亿级的数据展示在10 秒内完成。
右下角的是应对查询稳定性做的查询慢查询自身性降级。我们重选了es的现成磁逻辑,引入到优先级队列,根据查询的历史情况,自动量慢查询降级避免快慢查询相互影响。正是这一系列从数组机到内核层面的一系列优化,让我们取得了单核能力比开源强4.5倍,压缩率强三倍的结果。
2.按量付费
大家注意左边的这副实据图,在es请求进来时,截止它对应的线程池,打上我们的应用标记,当它出去时,我们将有一个离线的任务做对应的统计,最终统计出每一个请求所消耗的cpu时间。右上角这幅图则是我们所有截取的截成尺的名字。大家可以看到,我们劫持了大量的现成池,但其实并不是所有的现成池,而由于我们不记系统开销,比如gc数据迁移,不会算给用户,由我们系统自行承担。这比机器的cpu节省至少20%的费用。
3.智能调度免运维。
我们主要分成两类的运维自动化运维。一是的资源调度,二是配置调优。而资源调度原理是基于ceo计算的能力,在es的rebelance的策略中引入ceo这一项通过es的rebelance可以保证各个节点的水位均衡。而储纳在es节点内部,在多个服务集训间,也会通过此方式来进行均衡,保证多个服务及群间的整体水位均衡。配置调优则是实时统计每一个节点的基本信息。比如它的ceo用量、内存用量、io用量、网络存储,占用的限流器的情况和现成的情况,做对应的决策以及评估索引和节点是否处在最佳的运行状态。如果可以调优,我们会自动进行调优。
四、快速入门
快速入门只需三步。第一步在控制台创建应用。第二步是填写基本的信息第三步等待1~2分钟,创建后里面会有用户名和antpoint用这些直接替换掉代码里原来写的es地址。在接入完成后,控制台就可以看到对应的监控。
以上是关于日志分析型四大核心能力及其背后的关键技术实现的分享。相信通过高性能、低成本,真正按量付费免运维的servence产品帮助大家有效降低日常性的成本。