一、配景
1.1 配景先容
我们常常会收到客户反馈的标题，在业务高峰时容易出现分析查询慢和卡顿的环境。造成这种征象的原因是查询引擎(trino)在业务高峰时资源瓶颈,查询只能列队等候。也采取过增加资源的本领来缓解这一现状。但是由于架构的耦合性,很多步调部署相互依靠,扩展比较困难。在业务低谷时资源利用率非常低。
这种方式在一定程度上缓解了查询慢的标题,但是必要付出更多的人力和服务器成本。盼望通过架构的演进实现按需弹性资源,加强架构的扩展性。在提高查询效率的同时均衡服务器成本。
二、计划思绪
整体方案计划围绕Trino查询引擎资源瓶颈标题来睁开,而且必要兼顾到服务器成本。让Trino的架构具备资源弹性能力,在业务高峰时动态弹性扩资源，在资源负载低时释放资源。做到动态按需按量利用资源。
现有的部署方式是同一个节点可能会部署多个步调。同节点和跨节点的步调与步调之间又相互有依靠关系，这对于架构的扩展非常难。想要实现查询引擎的弹性能力，在架构上就必要做一些调整。这里借鉴了一些微服务架构的计划方法。单一职责原则,服务化计划，步调独立运维部署。
将Trino从原有的架构体系中分离出来,独立部署，独立维护和扩展。原有的架构通过设置切换即可利用到新的查询引擎的能力。新老查询引擎可以并存,按照架构实际利用效果渐渐将老的查询引擎缩减直至完全下线。
实现计算资源弹性有两种方式: 一种是直接利用云厂商的节点伸缩组计谋，另一种是利用容器服务的高效弹性伸缩能力
节点伸缩组的优势在于架构简单，部署和维护方便。可以和现有的架构风格很好的兼容和融合（都是接纳虚拟机的部署方式）。不足之处在于弹性的维度比较单一只支持CPU或内存的指标举行弹性伸缩。弹性效率不足大概必要3min30s左右才能弹性好资源。
弹性容器的云服务的优势在于可以无缝对接自动化CI/CD工具。可以更加细粒度,更多方式的对资源举行调度和控制。k8s的HPA也很方便的支持多种类型的监控数据作为弹性指标。而且弹性速度也很快约，可以较好的满足计算资源弹性需求。
在ToB的业务,服务器权限都在客户那边。我们通常只有比较有限的权限和访问路径去排查标题和更新升级维护业务系统版本。部署架构的简便性也是我们一个重要参考维度。Serverless模式比较符合我们的盼望。
弹性能力的计划大体方向是利用云厂商的Serverless容器服务作为根本办法。然后根据实际业务需求举行调整和计划。云原生的架构通常不是孤立的存在。在Trino从原有的架构体系中分离出来,利用云原生的方式重新计划，就必然必要把服务管理的内容给补全(服务网关,服务编排,监控,日志和设置等)。查询引擎云原生化才能真正有效运行起来。
三、实现落地
总体方案包括CI/CD，资源调度，服务管理和可观测性。篇幅有限就挑一些容易比较有代价模块来描述。
3.1 弹性容器资源
预期能通过自定义的监控数据作为弹性伸缩指标,在超过阈值时弹性资源副本,低于阈值时缩减资源数量。始终能确保资源是按需调度和分配的。
Kubernetes的HPA支持CPU,内存维度的监控数据作为弹性指标。但是对自定义弹性指标支持不太好。而我们的实际场景是必要根据一些特定的业务监控数据(例如 : 消息队列积压数,请求处理等候时间等)来触发扩缩。
我们利用Kubernetes API Aggregator的特性,支持将第三方的服务注册到Kubernetes API。如许就能实现直接通过Kubernetes API访问到外部服务。外部服务作为数据源,那就有了更好的机动性和扩展性了。具体落地时我们利用的是prometheus作为监控数据源,prometheus-adapeter作为扩展服务注册到Kubernetes API。整体逻辑架构图如下:
补充: 定时扩缩容(CronHPA)
我们利用了HPA和CronHPA相联合的方式,来应对不同的场景。负载缓慢增长的场景利用HPA根据业务指标举行控制。而在瞬时高负载场景下利用CronHPA,根据业务繁忙与空闲规律,提前自动调度好资源。在业务高峰之前扩资源,在业务空闲时释放资源。CronHPA极大缩短了应用冷启动时间。
3.2 服务接入
Kubernetes抽象了一层网络供pod相互访问,外部无法访问。外部想要访问Kubernetes通常会接纳NodePort、LoadBalancer和Ingress等方式。由于k8s Serverless云服务的特殊性,底层Kubernetes工作节点是封装屏蔽的。以是选择通过云服务LoadBalancer将所有的请求转发到ingress-nginx-controller。再通过 ingress设置具体的路由转发规则。
3.3 镜象仓库
在镜像仓库的计划也是履历三次改进,有很多标题也无法提前预判。基本上是在实际的标题和场景中一步一步迭代演进的。镜像仓库一直围绕办理的标题是包管国内和国外的客户获取镜像的过程稳定可靠。在计划时也盼望确保镜像同步和分发的划一性和统一管理。
阶段一: 能提供基本的镜像分发能力。
存在标题：
a) 外洋获取镜像非常慢
阶段二: 国内和外洋提供镜像分发能力,稳定运行了很长一段时间。
也袒露了两个标题:
a) 国内访问DockerHub服务 网络延时和不稳定,常常造成弹性容器无法顺利启动。
b) DockerHub 自身对镜像获取频次和速率有限制,超过阈值就会服务不相应。
阶段三: 国内和外洋提供稳定的镜像分发能力
a) DNS就近剖析,国内剖析到国内的镜像仓库,外洋剖析外洋的镜像仓库
b) 镜像优先推送到国内仓库,然后由国内镜像仓库同步到外洋和DockerHub
c) DockerHub依然保留作为备份,在非常时迅速切换利用
3.4 镜像加速
查询引擎Trino的镜像大概1.8G左右。在弹性资源后,获取镜像的过程非常耗时。从外部来看就会发现弹性应用一直处于等候状态。用户可能必要等候很久,弹性出来的服务都处于ready状态时,查询体验才会提升。
在调研计划镜像加速时,我们联合各自云厂商的服务能力。好比在阿里云上利用ImageCache CRD的方式做ECI的镜像缓存。
在腾讯云上有镜像缓存服务，不外必要手动在云控制台设置。这对于我们ToB的私有化部署的可能造成很多的不便。也是非常感谢腾讯云的何猛老师，在听说了我们的诉求后,迅速协调研发资源帮助推动CRD方式的镜像加速服务的上线。
AWS云平台比较特殊,k8s serverless 服务Fargate，有CPU规格限制。我们利用的是EKS弹性节点方式。弹性节点比弹性容器要慢非常多，大概2～3min才能处于可用状态。在和AWS共同探讨互助，决定接纳Bottlerocket的AMI,然后制作快照(提前将镜像缓存到快照)。然后利用Karpenter去管理和控制节点的弹性伸缩。弹性节点速度从3min左右 优化到55s左右。
3.5 节点组
业务场景和资源利用方式的不同，用同一种方式来管理。可能会造成资源调度的机动性不足,扩展难和资源浪费等标题。我们在计划时抽象一层节点组来管理不同类型的资源。节点组维度设置资费模式(包年包月/按量计费/Spot竞价实例)，资费规格,芯片架构和区域。整合了云平台中多种实例类型,根据应用的特性调度不同类型的资源。所有节点组都会被统一管理,根据业务场景、资源规模举行调整优化。在应用性能和服务器成本之间达成一个均衡。
(1) 多种实例规格型号混用
云厂商提供的资源规格非常丰富，但是要公道搭配和利用才能花更小的成本产生更大的代价。得益于Kubernetes的很强的兼容性和适配性。节点组可以让各种架构,厂商，规格，型号和版本的资源并存。不同的业务应用调度分配适合的资源类型。
好比有一些通例应用盼望利用x86的服务器,二另外一些查询型应用盼望利用ARM的服务器。盼望在同一套架构混合利用。通常来说ARM的服务器要比X86自制一些约10%。而另外一些对安全和性能要求苛刻的应用,可以独立分配适量的资源。
(2) 资费模式混合
同一套架构为不同类型和利用场景的资源设置差异化的资费模式。例如,常驻留资源利用包年包月,弹性资源利用按量计费模式。步调的不同特性也可以选择是否接纳Spot竞价模式。
(3) 多区域调度资源
同一个区域可能会出现特定型号资源存量不足，导致无法申请到资源。Trino云原生方案联合云服务功能打通各区域网络，将资源统一调度和利用整合到一个Kubernetes集群中。如许可以大幅提高资源申请成功率，确保在业务高峰时有充足的资源可供利用。
3.6 成本优化的思考
云厂商的资源利用资费模式有很多种类型(包年包月 / 按量计费 / Spot竞价实例 / 预留实例券 / 节省计划)。根据业务实际需求和场景综合利用可以节省比较多成本。
长驻留资源比较适合包年包月,弹性资源部门由于是按需只在高负载时利用尽可能的利用按量计费模式。但是假如有按量计费的时间每天超过8h，则必要重新计算成本。雷同资源规格和利用时长计算的资费成本，按量计费比包年包月要贵一些。假如业务运行实例是无状态且偶发的中断对业务的影响可以忽略，则可以利用Spot竞价实例模式。竞价计费模式通常比正常的资费要自制很多,最低可达1折。假如能利用好这种计费模式节省的服务器成本将相当可观。
利用节点组概念,来区分不同的资费类型。将不同的应用调度到不同的节点组。产生的资费也是按照不同节点组的实际利用环境来计算的。多种资源模式混合利用最大化的优化成本结构。
标题汇总
三、不足与盼望
目前的方案基本满足了大数据查询引擎资源弹性的诉求。不外也还面临着一些标题和挑战。
3.1 冷启动标题
Trino给现有的资源分配大查询使命,负载变高。新弹性出来的资源无法分摊本次计算压力。后续的查询使命才能分配到新资源。这会造成本次查询慢的标题依然没有很好的办理。目前也是盼望能实现按照资源利用汗青来猜测提前分配资源来缓解冷启动标题。
3.2 资源分配非常标题
k8s HPA频仍扩缩容造成,计费pod数量超过设置的Max最大值。这可能会造成资源浪费，很多扩充出来的资源利用率非常低。后续也会作力在资源更精确的控制上，确保资源的生命周期管理有序有效公道。
四、客户代价
在上线云原生方案后基本实现了在业务上实现了资源隔离,多业务并行运行相互不影响。也可以很方便的支持更多业务和个性化需求的扩展。云原生方案的弹性伸缩能力,可以包管按需利用资源。在月度硬件成本上下降了40%左右.服务的查询相应速度也提升50%左右。整个运维和管理过程也大大简化,方便后续的维护和管理。
五、后记
在架构的调研演进时，肯定会碰到各种各样的奇奇怪怪的标题。保持心态开放多和云厂商的技能职员保持密切的沟通，一个方案尽可能多的与不同的人讨论，避免认知盲区。很有可能针对某个场景的标题已经有了比较成熟和完备的办理方案了。而由于你没打仗过而接纳更费时费力的本领去应对。尽可能多的去验证实际测试，没上线、没测试验证，你永世不知道有多少坑在等着你。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
