云原生时代的搜索服务算力管理

Posted 百度Geek说

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了云原生时代的搜索服务算力管理相关的知识,希望对你有一定的参考价值。

一、搜索服务算力管理综述

1.1 搜索算力管理的发展历程

算力管理的核心目标,是实现算力需求与算力资源的最优匹配。搜索服务算力管理的发展经历了以下3个阶段:

1)物理机部署阶段

2014年以前,搜索服务模块都是直接部署在物理机上。这时物理机的CPU、内存、SSD等大小相对统一,个别空闲的机器会手工选择一些模块进行混部;夜间用户流量低峰时候,会有BVC这样离线计算框架,支持离在线任务混部,实现资源充分利用。

2)半自动混部阶段

2014年~2018年间,搜索业务自研的PaaS实现了服务的半自动化的混部。半自动化体现于:混部策略由人工设计,执行过程为命令式,容量管理由人工维护。这个阶段,业务有项目上线,需要询问容量专员,某些模块的算力资源是否还有空闲,是否可以支持该项目消耗。对于大型项目,我们自研了全链路压测技术,支持精确容量压测,确保不出现系统级瓶颈。

3)云原生混部阶段

2018年之后,搜索业务将服务托管至公司云平台上,利用云平台对服务进行自动伸缩、自动混部。业务上线前,不再需要询问容量专员,直接在云平台提交扩容申请即可。这期间,我们把更重要的流量匹配到计算得更快的容器上,实现速度与成本兼顾。

1.2 搜索算力治理体系

搜索服务算力质量治理体系,分为两大部分:技术架构和运营体系。

1)技术架构

充分依托弹性容器实例、智能监控、Service Mesh等公司云平台提供的技术产品,实现quota的智能管理,达到算力需求与资源更好的匹配。

2)运营体系

成立委员会制度,通过委员会驱动成本和速度相关的优化、运作业务项目预算审批流程,在全局维度实现开源节流。

二、搜索服务算力管理的业务特色

2.1 面向全时段优化

在用户产品服务中,用户流量是潮汐波动的,夜间用户流量少了,利用率下降出现资源闲置,这时需要用云的思想重新考虑这个问题。

1)潮汐伸缩

云原生应用12要素中提到“通过进程模式进行扩展”,意思是我们云上的服务不应该是单点,而是由很多副本实例组成。低峰期并非利用率下降,而是需要的实例数减少了。所以,通过在夜间对实例缩容、白天高峰到来前扩容的潮汐方式,可以实现夜间账单的下降。

2)窗口迁移

云平台的本质之一是市场化:夜间供给大于需求时,容器单价下降,例如网约车价格。搜索业务基于cache技术进行内容失效预测,可提前在夜间算力更廉价时启动计算任务,用户在次日高峰期可获得相对较新的结果。这是通过计算任务时间窗口迁移,实现整体资源账单的优化。

2.2 同时段深挖算力空间

在相同的时间点,通过对整个搜索服务集群的计算任务分类,也存在可以挖掘优化的空间。具体任务类型包括:近线任务、异步任务、同步任务。

1)近线任务

在线计算需要控制复杂度以保障较低的响应延迟,我们可以把复杂计算后的“好结果”写入近线存储或者cache中,当用户在线查询相关请求时候,就可以得到更好的结果反馈。这个best effect方式,并不需要容器有特别高的稳定性,可以采用更廉价的可抢占式容器,来提供近线算力资源。

2)异步任务

应用cache可以加速服务响应、降低cache后端资源成本。完整的cache时效性可以分为三个级别:失效时立即更新;失效前在夜间提前更新;失效时立即发起更新,但不把更新结果同步用户,异步更新给cache。在第三种场景下,需要保证计算的效果,又不需立即返回,则可选用稳定性稍好、处理速度稍慢的容器。

3)同步任务

同步计算任务,需要立即计算结果并将结果返回给用户。例如搜索业务的索引服务,大部分是用分片方式提供服务的。但在大规模分布式场景下,分片多少会存在计算长尾,长尾分片可能索引了更复杂的文档,或是文档数量比平均值稍高。对于长尾分片,可以购买稳定性更好、速度更快、quota更大的容器;对于普通分片,计算复杂度相对较低,可购买quota相对较少的容器。实现容器的差异化采购。

三、搜索服务算力管理的关键技术

3.1 应用性能管理

1)性能曲线

容器规格的设置需要考虑很多因素。在搜索服务中,计算任务存在大量内存访问,减少实例数可以降低内存复制成本,同时单容器流量增加,带来内存访问压力增大,对性能影响是非线性的,传统模式下需要通过大量线下测试来观察。在云原生系统中,依托云原生监控机制,将模块的流量、响应时间、资源使用量关系充分关联,通过大规模样本聚合分析,可以得到更具统计意义的性能曲线。

2)vpa/hpa

性能曲线可以得到服务的基本性能模式,根据服务的任务类型(近线、异步、同步等)运行不同的quota管理策略,预测未来一段时间服务的理想资源quota,最后产出伸缩事件,触发PaaS进行调整。

3)流量缩容

性能优化项目上线后,会通过缩容释放资源。传统的方法,因线上稳定性要求,缩容需分批多次进行,效率低,且缩容到优化边界时偏于保守,优化的成果不能充分释放。在云上使用新方法,即基于Service Mesh的能力,将缩容改为切流,创建一个更小的调度集合,通过mesh切换和调度,大幅度缩短观察周期和修复耗时,可以更充分地把优化成果释放出来。

3.2 容器分档

1)静态分档

我们考虑这样一个场景,如下trace图,某个服务并行访问A、B两个下游,A的响应时间更长一些,所以提升A的性能可以缩短上层服务时间。但如果B中更快的容器(绿色)比A更多,则系统整体性能就不是最优的。这是通过增加A的快速容器让A算得更快,可以缩短整体响应时间。

2)动态分档

容器运行相同计算任务的速度,受宿主机硬件性能和硬件状态影响。根据宿主机的硬件性能对容器运行计算任务的速度进行划分,我们定义为静态分档;根据容器宿主机的硬件状态对容器运行计算任务的速度进行划分,我们定义为动态分档。如下图所示,部署在相同快速硬件型号上的A1~A4容器,A1容器因宿主机资源较空闲,计算速度更快。

3.3 算力分布

1)精细流量调度

完成分档后,可通过更精细的流量调度,高效使用不同分档的容器。我们将服务分为高速单元和低速单元,高速单元部署在快速容器上,低速单元部署在低速容器上。处理请求时,首先进行流量类型识别,高优流量路由到高速服务单元上,再预估请求的计算复杂度,把更复杂的计算发送到更快容器上,进一步提升请求的计算速度。

2)智能cache预充

通过cache技术,可以在时间上实现任务计算窗口迁移,从而更好地使用容器。日间高峰期,将请求收集到请求数据中心;在夜间低峰期,预测cache失效的请求发送到请求队列,经过请求代理重新计算更新cache,降低高峰期的流量。

四、总结

以上,回顾了搜索服务算力管理的发展历程,概览了运营+技术的治理体系,重点介绍了技术架构侧的近期业务特色工作,覆盖时间和空间两个方面。

时间方面,算力需求潮汐变化,传统的方法供给按最大值购买。而基于云原生技术,在低峰期可减少大量无效购买,增加适当购买廉价容器转移高峰计算量。

空间方面,未经梳理的梳理需求看似杂乱无章,传统的方法供给同样是按最大值购买;基于云原生技术,区分高低优先级的任务,用不同速度的容器来提供服务,可以达到更优的资源配置。

立足云原生时代,搜索服务算力管理会进一步应用更灵活、更丰富的控制手段,保持对算力需求和资源更优配置的不断追求。

推荐阅读:

百度小程序包流式下载安装优化

前端工程化之FaaS SSR方案

日志中台不重不丢实现浅谈

百度ToB垂类账号权限平台的设计与实践

视觉Transformer中的输入可视化方法

深入理解 WKWebView (渲染篇) —— DOM 树的构建

深入理解 WKWebView(入门篇)—— WebKit 源码调试与分析

以上是关于云原生时代的搜索服务算力管理的主要内容,如果未能解决你的问题,请参考以下文章

云原生时代,亚马逊云科技自研处理器Graviton2如何“量体裁衣”?

从SOA到微服务,企业分布式应用架构在云原生时代如何重塑

云原生时代的分布式文件系统是啥样的?

媒体声音|阿里云数据库:一站式全链路数据管理与服务,引领云原生2.0时代

媒体声音|阿里云数据库:一站式全链路数据管理与服务,引领云原生2.0时代

云原生时代的业务管理,一站式的“交钥匙”服务