Elastic 构建 Elastic Cloud Serverless 的历程

作者：来自 Elastic Elastic Cloud Serverless team

无状态架构，可根据你的数据、使用情况和性能需求自动扩展。

如何将像 Elasticsearch 这样有状态、对性能要求极高的系统变成无服务器架构？

在 Elastic，我们重新构想了一切 —— 从存储到编排 —— 以构建一个真正可信赖的无服务器平台。

Elastic Cloud Serverless 是一个完全托管的、云原生平台，旨在将 Elastic Stack 的强大功能带给开发者，同时免除运维负担。在这篇博客中，我们将介绍我们为什么要构建它、我们是如何设计架构的，以及在这个过程中学到了什么。

为什么选择无服务器架构？

多年来，客户的期望发生了巨大变化。用户不再希望操心基础设施管理的复杂性，比如容量规划、监控和扩展。他们更希望获得一个无缝体验，只需专注于自己的工作负载。这一不断发展的需求促使我们构建一个能减少运维负担、提供顺畅 SaaS 体验，并引入按使用计费模式的解决方案。通过免除客户手动配置和维护资源的需要，我们创建了一个能根据需求动态扩展、同时优化效率的平台。

重要里程碑

为满足客户需求，Elastic Cloud Serverless 正在快速扩展，并已于 2024 年 12 月在 AWS 上实现正式可用（GA），于 2025 年 4 月在 GCP 上正式发布，2025 年 6 月在 Azure 上正式发布。自那以后，我们已在 AWS 扩展到 4 个区域，在 GCP 扩展到 3 个区域，在 Azure 扩展到 1 个区域，并计划在这三大云服务提供商（cloud service providers -  CSP ）上进一步拓展更多区域。

重新思考架构：从有状态到无状态

Elastic Cloud Hosted（ECH）最初是构建为一个有状态系统，依赖本地基于 NVMe 的存储或托管磁盘来确保数据持久性。随着 Elastic Cloud 的全球扩展，我们看到一个机会，可以通过改进架构来更好地支持运维效率和长期增长。我们托管的方式在跨分布式环境管理持久状态方面虽然有效，但也带来了额外的运维复杂性，比如节点替换、维护、跨可用区冗余保障，以及扩展像索引和搜索这类计算密集型工作负载。

我们决定通过采用无状态架构来演进系统架构。关键的转变是将持久性存储从计算节点转移到云原生对象存储。这带来了多个好处：减少索引所需的基础设施负担、实现搜索与索引的解耦、消除复制需求，并通过利用 云服务提供商的内置冗余机制提升数据持久性。

转向对象存储

我们架构中的一个重大转变是使用云原生对象存储作为主要数据存储。ECH 最初是将数据存储在本地 NVMe SSD 或托管 SSD 磁盘上。然而，随着数据量的增长，如何高效扩展存储成为挑战。随后我们在 ECH 中引入了可搜索快照，使我们能够直接从对象存储中搜索数据，大幅降低了存储成本，但这还不够。

一个关键挑战是判断对象存储能否在保持 Elasticsearch 用户期望的性能水平下，处理高写入负载。通过严格的测试和实施，我们验证了对象存储能够满足大规模索引的需求。转向对象存储不仅消除了索引复制的需求，还减少了基础设施需求，并通过跨可用区的数据复制增强了持久性，确保了高可用性和弹性。

下面的图示展示了新的 “无状态” 架构与当前 “ECH” 架构的对比：

优化对象存储效率

虽然转向对象存储带来了运维和持久性的优势，但也引入了一个新挑战：对象存储的 API 成本。写入 Elasticsearch —— 特别是 translog 更新和刷新 —— 会直接转换为对象存储的 API 调用，在高写入或高刷新负载下，这些调用可能迅速且不可预测地增长。

为了解决这个问题，我们在每个节点上实现了 translog 缓冲机制，在写入对象存储之前合并写入操作，从而大大减少写入放大。同时，我们将刷新操作与对象存储写入解耦，刷新后的 segment 直接发送到搜索节点，并延迟持久化到对象存储。这一架构优化将刷新相关的对象存储 API 调用减少了两个数量级，同时没有影响数据持久性。更多细节可参考这篇博客文章。

选择 Kubernetes 作为编排工具

ECH 使用的是我们自研的容器编排器，同时也用于驱动 Elastic Cloud Enterprise（ECE）。由于 ECE 的开发早于 Kubernetes（K8s）的诞生，因此我们面临两个选择：扩展 ECE 来支持 serverless，或使用 K8s 来构建 serverless。随着 K8s 在行业内的快速普及以及其不断壮大的生态系统，我们决定在 Elastic Cloud Serverless 中，使用各 云服务提供商提供的托管 Kubernetes 服务，以契合我们的运维和扩展目标。

通过采用 Kubernetes，我们降低了运维复杂度，标准化了 API 以提升可扩展性，并为 Elastic Cloud 的长期创新奠定了基础。Kubernetes 让我们能够专注于更高价值的功能开发，而不是重复造轮子去实现容器编排。

CSP 托管 vs. 自管 Kubernetes

在向 Kubernetes 迁移的过程中，我们面临一个选择：是自己管理 Kubernetes 集群，还是使用 云服务提供商提供的托管 Kubernetes 服务。不同 CSP 的 Kubernetes 实现差异较大，但为了加快部署速度并降低运维负担，我们选择了在 AWS、GCP 和 Azure 上使用 CSP 托管的 Kubernetes 服务。这一做法让我们可以专注于应用构建和采纳行业最佳实践，而不必陷入 Kubernetes 集群管理的复杂性。

我们的关键需求包括：能在多个 CSP 上一致性地配置和管理 Kubernetes 集群；具备管理计算、存储和数据库的云无关 API；以及简化并具成本效益的运维方式。此外，通过选择 CSP 托管的 Kubernetes，我们还能够为 Crossplane 等开源项目做出贡献，在受益于其能力演进的同时，助力整个 Kubernetes 生态的发展。

网络挑战与选择 Cilium

在单个 Kubernetes 集群中运行数万个 pod 的大规模环境下，网络方案必须是云无关的，具备高性能、低延迟，并支持高级安全策略。我们选择了 Cilium —— 一种基于 eBPF 的现代解决方案 —— 来满足这些需求。最初我们计划在所有 CSP 上统一部署自管的 Cilium，但由于各云厂商实现存在差异，我们最终采用了混合方案：在支持的地方使用 CSP 原生的 Cilium 方案，在 AWS 上则维持自管部署。这种灵活性确保了我们在不增加不必要复杂性的前提下，满足性能与安全需求。

入口流量

对于入口流量，我们选择适配并继续使用我们在 ECH 中经过实战检验的现有代理。评估的重点不是我们是否能用现成方案替换代理，而是是否应该替换。

虽然标准的反向代理能提供基本功能，但缺少 ECH 代理已有的差异化特性。我们需要为入口流量过滤器、支持 AWS PrivateLink 和 Google Cloud Private Service Connect 以及符合 FIPS 标准的 TLS 终止构建扩展。此外，现有代理已通过所有相关的合规审计和渗透测试。

从头开始采用新方案将需要大量工作，却不会带来额外的客户价值。为 Kubernetes 适配我们的代理主要是更新服务端点分发的方式，核心的、经过充分测试的功能保持不变。这种做法带来多个优势：

• 确保客户可见的行为在 ECH 和 Kubernetes 之间保持一致。

• 团队能更高效地使用熟悉且理解深入的代码库，尤其是在实现新功能时，而这些新功能如果用现成方案则可能需要编写脚本或扩展。

• 我们能用同一代码库推进 ECH 和 Kubernetes 两个平台，因此一个环境的改进能同步带来另一个环境的提升。

• 支持团队能利用现有知识，降低新平台的学习曲线。

Kubernetes 配置层

在为 Elastic Cloud Serverless 选择 Kubernetes 之后，我们选用了 Crossplane 作为基础设施管理工具。Crossplane 是一个开源项目，扩展了 Kubernetes API，使得用户能够使用 Kubernetes 原生工具和实践来配置和管理云基础设施及服务。它允许用户从 Kubernetes 集群内部跨多个 云服务提供商 进行云资源的配置、管理和编排。这是通过利用自定义资源定义（CRD）来定义云资源，以及控制器来协调 Kubernetes 清单中指定的期望状态与多个 CSP 上云资源的实际状态实现的。利用 Kubernetes 的声明式配置和控制机制，Crossplane 提供了一种一致且可扩展的基础设施即代码管理方式。

Crossplane 使基础设施的管理和配置与服务部署使用相同的工具和方法。这包括利用 Kubernetes 资源、一致的 GitOps 架构和统一的可观测性工具。此外，开发者可以构建一个完整的基于 Kubernetes 的开发环境及其外围基础设施，完全镜像生产环境。只需创建一个 Kubernetes 资源，因为两个环境都是基于相同的底层代码生成的。

管理基础设施

统一层（unified layer）是面向运维人员的管理层，提供 Kubernetes 的 CRD，供服务所有者管理他们的 Kubernetes 集群。服务所有者可以定义包括 CSP、区域和类型（将在下一节解释）等参数。该层负责丰富运维人员的请求并将其转发到管理层。

管理层（management layer）作为统一层与 CSP API 之间的代理，将统一层的请求转换为 CSP 资源请求，并将状态报告回统一层。

在我们当前的架构中，每个环境中针对每个 CSP 维护两个管理 Kubernetes 集群。这种双集群方式主要有两个目的：第一，有效应对 Crossplane 可能出现的可扩展性问题；第二，更重要的是，可以将其中一个集群用作金丝雀环境（canary environment）。通过金丝雀部署策略，我们能对变更进行分阶段发布，从每个环境中较小且受控的子集开始，最大限度降低风险。

工作负载层（workload layer）包含所有运行用户交互应用的 Kubernetes 工作负载集群（如 Elasticsearch、Kibana、MIS 等）。

管理云容量：避免 “容量不足” 错误

常见的假设是云容量是无限的，但实际上， 云服务提供商会施加限制，可能导致 “容量不足” 错误。如果某个实例类型不可用，我们必须不断重试或切换到其他实例类型。

为了解决 Elastic Cloud Serverless 中的问题，我们实现了基于优先级的容量池，允许工作负载在必要时迁移到新的或其他容量池。此外，我们还投入主动容量规划，在需求激增前预留计算资源。这些机制确保了高可用性，同时优化资源利用率。

保持更新

Kubernetes 集群升级耗时较长。为简化流程，我们采用了全自动端到端的过程，只有无法自动解决的问题需要人工干预。内部测试完成并批准新 Kubernetes 版本后，我们进行集中配置。自动化系统随后开始对每个集群的控制平面进行升级，采用受控并发和特定顺序。之后，自定义 Kubernetes 控制器执行蓝绿部署升级节点池。尽管在此过程中客户的 pod 会迁移到不同的 K8s 节点，但项目的可用性和性能保持不变。

架构韧性

我们采用基于 cell 的架构，使我们能够提供可扩展且具韧性的服务。每个 Kubernetes 集群及其外围基础设施部署在独立的 CSP 账户中，以实现适当扩展、不受 CSP 限制影响，并提供最大安全性和隔离。每个工作负载是一个独立的 cell，负责系统的特定部分。各 cell 独立运行，实现隔离扩展和管理。该模块化设计最小化故障波及范围，方便针对性扩展，避免系统范围影响。为进一步减少潜在影响，我们在应用和底层基础设施上均采用金丝雀部署。

控制平面 vs. 数据平面：推送模型

控制平面（Control Plane）是面向用户的管理层。我们提供用户界面和 API，供用户管理他们的 Elastic Cloud Serverless 项目。在这里，用户可以创建新项目，控制谁能访问项目，并查看项目概览。

数据平面（Data Plane）是支撑 Elastic Cloud Serverless 项目的基础设施层，用户在使用项目时会与之交互。

我们面临的一个根本设计决策是全局控制平面应如何与数据平面的 Kubernetes 集群通信。我们考察了两种模型：

• 推送模型：控制平面主动将配置推送到各区域的 Kubernetes 集群。
• 拉取模型：各区域 Kubernetes 集群定期从控制平面拉取配置。

经过评估，我们采用了推送模型，因其简单、单向数据流，并且能在控制平面出现故障时使 Kubernetes 集群独立运行。该模型让我们保持了简洁的调度逻辑，同时降低了运维负担和故障恢复复杂度。

自动扩缩容：超越横向和纵向扩展

为了提供真正的无服务器体验，我们需要一种智能的自动扩缩容机制，能根据工作负载需求动态调整资源。我们的起点是基本的横向扩展，但很快发现不同服务有各自独特的扩展需求，有的需要更多计算资源，有的则需要更高内存分配。

我们通过构建自定义的自动扩缩容控制器来改进这一方法，实时分析针对具体工作负载的指标，实现响应快速且资源高效的动态扩缩容。因此，我们可以无缝地扩展 Elasticsearch 的索引层和搜索层操作，而不会对 Elasticsearch 进行过度预配置。该策略支持多维度 pod 自动扩缩容，使工作负载能基于 CPU、内存和自定义的工作负载生成指标，进行横向和纵向扩展。

对于 Elasticsearch 工作负载，我们使用专为无服务器设计的 Elasticsearch API，返回集群的关键指标。其工作流程是：推荐器建议某个层级所需的计算资源（副本数、内存和 CPU）及存储；映射器将这些建议转换为适用于容器的具体计算和存储配置。为了防止快速扩缩波动，稳定器对建议进行过滤。然后限制器执行资源的最小和最大约束。限制器的输出结合一些可选的限制策略后，用于修补 Kubernetes 部署。

这种分层的智能扩缩容策略确保了不同工作负载的性能和效率 —— 这是迈向真正无服务器平台的重要一步。

Elastic Cloud Serverless 为搜索层引入了细化的自动扩缩容能力，利用诸如增强数据窗口、搜索能力设置和搜索负载指标（包括线程池负载和队列负载）等输入信号。这些信号共同定义了基线配置，并根据客户的搜索使用模式触发动态扩缩容决策。想深入了解搜索层自动扩缩容，请阅读这篇博客文章。若想了解索引层自动扩缩容的工作原理，请查看这篇博客文章。

构建灵活的定价模型

无服务器计算的一个关键原则是让成本与实际使用量匹配。我们希望定价模型简单、灵活且透明。经过评估多种方案，我们设计了一个平衡核心解决方案中不同工作负载的模型：

• 可观测性和安全：基于数据摄取和保留量收费，采用分层定价

• Elasticsearch（搜索）：基于虚拟计算单元收费，涵盖摄取、搜索、机器学习和数据保留

这种方式为客户提供按使用付费的定价，带来更大灵活性和成本可预测性。

为了实现这一定价模型（在开发阶段经历多次迭代），我们需要一个可扩展且灵活的架构。最终，我们构建了一个支持分布式责任模型的管道，不同团队负责端到端流程中的不同组件。下面描述了该管道的两个主要部分：通过使用管道进行计量使用收集，以及通过计费管道进行账单计算。

使用管道

面向用户的组件如 Elasticsearch 和 Kibana 将计量的使用数据发送到运行在每个工作负载集群中的 usage-api 服务。该服务对数据进行一些丰富处理后放入队列。随后，usage-shipper 服务从队列拉取数据并转发到对象存储。为了在跨区域和 CSP 传输数据时保证管道的弹性，这种解耦架构是必要的，因为我们优先保证数据传递而非延迟。一旦数据到达对象存储，其他流程可以以只读方式访问，用于进一步转换或聚合（例如用于计费或分析）。

计费管道

使用记录存入对象存储后，计费管道会获取这些数据，并将其转换为 ECU（Elastic Consumption Units，Elastic 的与货币无关的计费单位）数量，作为计费依据。基本流程如下：

转换过程会从对象存储中获取计量使用记录，并将其转换为可实际计费的记录。这个过程包括单位转换（计量应用可能以字节为单位计量存储，但我们按 GB 计费）、过滤掉不计费的使用来源、将记录映射到具体产品（解析使用记录中的元数据，将使用量关联到有唯一价格的特定解决方案产品），然后将数据发送到 Elasticsearch 集群，供我们的计费引擎查询。转换阶段的目的是集中管理逻辑，将通用的计量使用记录转换成特定产品的可定价数量，从而避免将这些专门逻辑放在计量应用或计费引擎中，使二者保持简单且与产品无关。

计费引擎随后对这些可计费使用记录进行计价，这些记录包含映射到价格数据库中产品的标识符。基本流程是统计某一时间段内的使用量，并乘以产品价格计算 ECU（Elastic Consumption Units）。在某些情况下，还需基于整月累计使用量将使用分段，对应不同定价层级。为容忍上游流程延迟且不遗漏记录，计费以使用数据到达计费存储时为准，但价格按发生时间计算（避免对“晚到”的使用应用错误价格），这为计费过程提供了“自愈”能力。

最终计算出 ECU 后，我们评估任何附加费用（如支持费），并将其纳入计费计算，最终生成发票（由我们或云市场合作伙伴发送）。这最后一部分流程并非 Serverless 独有，由托管产品的同一系统处理。

总结

在多个 云服务提供商 上构建提供类似功能的基础设施平台是一项复杂挑战。平衡可靠性、可扩展性和成本效率需要不断迭代和权衡。不同 CSP 的 Kubernetes 实现差异显著，确保跨 CSP 一致的体验需要大量测试和定制。

此外，采用无服务器架构不仅是技术转型，更是文化转变。它要求从被动故障排查转向主动系统优化，优先自动化以减轻运维负担。我们的经验表明，成功构建无服务器平台不仅关乎架构决策，更关乎培养持续创新和改进的思维方式。

展望未来

无服务器领域的成功依赖于卓越的客户体验、主动优化运营以及持续平衡可靠性、可扩展性和成本效率。未来，我们将继续专注于为 Elastic Cloud Serverless 构建新功能，使无服务器成为所有人运行 Elasticsearch 的最佳选择。

搜索、安全和可观测性的未来已然到来，速度、规模和成本无一妥协。体验 Elastic Cloud Serverless 和 Search AI Lake，解锁数据的新机遇。了解更多无服务器可能性，或立即开始免费试用。

本文所述任何功能的发布和时间均由 Elastic 全权决定，尚未提供的功能可能不会按时或完全发布。

本文可能使用或引用第三方生成式 AI 工具，这些工具由各自所有者拥有和运营。Elastic 不控制第三方工具，也不对其内容、运营或使用负责，亦不对你使用这些工具可能产生的任何损失或损害承担责任。使用 AI 工具处理个人、敏感或机密信息时请谨慎。你提交的数据可能被用于 AI 训练或其他目的，不能保证信息安全或保密。请在使用任何生成式 AI 工具前，了解其隐私政策和使用条款。

Elastic、Elasticsearch 及相关商标为 Elasticsearch N.V. 在美国及其他国家的注册商标。其他公司和产品名称为其各自所有者的商标或注册商标。

原文：Elastic's journey to build Elastic Cloud Serverless | Elastic Blog