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

作者：百度Geek说

2022 年 4 月 28 日
本文字数：3002 字
阅读完需：约 10 分钟

导读：本文主要介绍百度搜索架构团队在服务算力管理方向的工程实践和相关经验，涉及服务与容器算力的“时间”“空间”话题。
全文 2970 字，预计阅读时间 9 分钟

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

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 容器因宿主机资源较空闲，计算速度更快。