停止项目大小调整，开始搜索层自动缩放！

作者：来自 Elastic Matteo Piergiovanni，John Verwolf

我们新的 serverless 产品的一个关键方面是允许用户部署和使用 Elastic，而无需管理底层项目节点。为了实现这一点，我们开发了搜索层自动扩展，这是一种根据我们将在本博客中深入探讨的大量参数动态选择节点大小和数量的策略。这项创新确保你不再需要担心资源配置不足或过度配置。

无论你处理的是波动的流量模式、意外的数据峰值还是逐渐增长，搜索层自动扩展都会根据搜索活动无缝地将分配的硬件动态调整到搜索层。自动扩展是按项目执行的，对最终用户完全透明。

简介

Elastic serverless 是 Elastic 推出的一款完全托管产品，它使你无需管理底层 Elastic 基础设施即可部署和使用 Elastic 产品，而是专注于最大限度地利用数据。

自我管理基础设施面临的挑战之一是应对客户不断变化的需求。在动态的数据管理世界中，灵活性和适应性至关重要，而传统的扩展方法往往不够完善，需要手动调整，这既耗时又不精确。借助搜索层自动扩展，我们的 serverless 产品会自动调整资源以实时满足你的工作负载需求。

本文中描述的自动扩展特定于 Elastic serverless 产品中的 Elasticsearch 项目类型。可观察性和安全性可能具有针对其独特要求量身定制的不同自动扩展机制。

在深入了解自动扩展的细节之前，还需要了解另一个重要信息，即我们如何管理数据以实现强大且可扩展的基础设施。我们使用 S3 作为主要事实来源，提供可靠且可扩展的存储。为了提高性能并减少延迟，搜索节点使用本地缓存来快速访问经常请求的数据，而无需反复从 S3 检索数据。S3 存储和搜索节点缓存的这种组合形成了一个高效的系统，确保持久存储和快速数据访问都能有效满足用户的需求。

搜索层自动扩展输入

为了演示自动扩展的工作原理，我们将深入研究用于做出扩展决策的各种指标。

在启动新的 serverless Elasticsearch 项目时，用户可以选择两个会影响自动扩展行为的参数：

• 增强窗口：定义搜索数据被视为增强的特定时间范围。
  • 增强数据：在增强窗口内的数据被归类为增强数据。所有在增强窗口范围内具有 @timestamp 的基于时间的文档以及所有非基于时间的文档都将属于增强数据类别。这种基于时间的分类允许系统在分配资源时优先考虑这些数据。
  • 非增强数据：增强窗口之外的数据被视为非增强数据。这些较旧的数据仍然可以访问，但与增强数据相比分配的资源较少。
• 搜索能力：控制分配给项目中增强数据的虚拟计算单元 (virtual compute units - VCU) 数量的范围。搜索能力可以设置为：
  • 成本效益：限制增强数据的可用缓存大小，优先考虑成本效益而不是性能。非常适合希望以低成本存储大量数据的客户。
  • 平衡：确保所有增强数据都有足够的缓存，以便更快地进行搜索。
  • 性能：提供更多资源，以更快地响应更大容量和更复杂的查询。

增强窗口将决定项目的增强数据和非增强数据量。

我们将项目的增强数据定义为增强窗口内的数据量。

增强数据的总大小以及所选搜索能力范围的下限将决定项目的基本硬件配置。这种方法比扩展到零（或接近零）更受欢迎，因为它有助于保持后续请求的可接受延迟。这是通过保留我们的缓存并确保 CPU 可立即用于处理传入请求来实现的。这种方法避免了与从 CSP（cloud server provider） 配置硬件相关的延迟，并确保系统随时准备及时处理传入请求。

请注意，基本配置可以通过提取更多数据而随时间推移而增加，如果时间序列数据超出增强窗口，则基本配置会减少。

这是自动扩展的第一部分，我们提供了一个基本硬件配置，可以随时间推移适应用户的提升数据。

基于负载的自动扩展

基于交互式数据的自动扩展只是难题的一部分。它不考虑传入搜索流量对搜索节点造成的负载。为此，我们引入了一个名为 “search load -搜索负载” 的新指标。搜索负载是处理当前搜索流量所需的物理资源量的度量。

搜索负载考虑了搜索流量在给定时间对节点造成的资源使用情况，因此允许动态自动扩展。

什么是搜索负载？

搜索负载（search load）是处理当前搜索流量所需的物理资源量的度量。我们将其报告为每个节点所需的处理器数量的度量。但是，这里有一些细微差别。

在扩展时，我们在具有设置值的 CPU、内存和磁盘的硬件配置之间上下移动。这些值根据给定的比率一起缩放。例如，为了获得更多 CPU，我们将扩展到具有更多内存和更多磁盘的硬件配置的节点。

搜索负载间接考虑了这些资源。它通过使用搜索线程在给定测量间隔内所花费的时间来做到这一点。如果线程在等待资源 (IO) 时阻塞，这也会增加线程的执行时间。如果除了排队之外，所有线程都 100% 利用率，则表示需要扩大规模。相反，如果没有排队并且搜索线程池的利用率低于 100%，则表示可以缩小规模。

如何计算搜索负载？

搜索负载由两个因素组成：

• 线程池负载：处理正在处理的搜索流量所需的处理器核心数。
• 队列负载：在可接受的时间范围内处理排队的搜索请求所需的处理器核心数。

为了描述如何计算搜索负载，我们将逐步介绍每个方面以解释基本原理。

我们将从描述线程池负载（Thread Pool Load）开始。首先，我们监控负责在采样间隔内处理搜索请求的线程的总执行时间，称为 totalThreadExecutionTime（总线程执行时间）。将此采样间隔的长度乘以处理器核心以确定最大 availableTime。为了获得 threadUtilization（线程利用率）百分比，我们将总线程执行时间除以这​​个 availableTime。

double availableTime = samplingInterval * processorCores;
double threadUtilization = totalThreadExecutionTime / availableTime;

例如，采样间隔为 1 秒的 4 核机器将有 4 秒的可用时间（4 核 * 1 秒）。如果总任务执行时间为 2 秒，则线程池利用率（hread pool utilization）为 50%（2 秒 / 4 秒 = 0.5）。

然后，我们将 threadUtilization 百分比乘以 numProcessors 以确定 processingsUsed，它衡量使用的处理器核心数。我们通过指数加权移动平均线（有利于最近添加的移动平均线）记录此值，以平滑小规模的活动突发。这会产生用于 threadPoolLoad 的值。

double processorsUsed = threadUtilization * numProcessors;
exponentialWeightedMovingAvg.add(processorUtilization);
double threadPoolLoad = exponentialWeightedMovingAvg.get();

接下来，我们将描述如何确定队列负载（Queue Load）。计算的核心是配置 maxTimeToClearQueue，它设置搜索请求可以排队的最大可接受时间范围。我们需要知道给定线程在此时间范围内可以执行多少个任务，因此我们将 maxTimeToClearQueue 除以搜索执行时间的指数加权移动平均值。接下来，我们将 searchQueueSize 除以此值，以确定在配置的时间范围内清除队列需要多少个线程。要将其转换为所需的处理器数量，我们将其乘以 processorsPerThread 的比率。这会产生用于 queueLoad 的值。

double taskPerThreadWithinSetTimeframe = maxTimeToClearQueue / ewmaTaskExecutionTime;
double queueThreadsNeeded = searchQueueSize / taskPerThreadWithinSetTimeframe;
double queueLoad = queueThreadsNeeded * processorsPerThread;

那么给定节点的搜索负载（Search Load ）就是 threadPoolLoad 和 queueLoad 的总和。

搜索负载报告

每个搜索节点都会定期向主节点发布负载读数。这将在设定的时间间隔后或检测到负载大幅变化时发生。

主节点会分别跟踪每个搜索节点的状态，并根据各种生命周期事件执行记账。添加/删除搜索节点时，主节点会添加或删除其各自的负载条目。

主节点还会报告每个条目的质量评级：Exact、Minimum 或 Missing。Exact 表示最近报告了该指标，而 Missing 则表示新节点尚未报告搜索负载。

当主节点在配置的时间段内未收到来自搜索负载的更新时（例如，如果某个节点暂时不可用），搜索负载质量被视为最低。当搜索节点的负载值考虑了不被视为未来工作的工作（例如下载随后将缓存的文件）时，质量也会报告为最低。

质量用于通知扩展决策。当任何节点的质量不准确时，我们不允许缩小规模。但是，无论质量评级如何，我们都允许扩大规模。

自动扩缩器 - Autoscaler

自动扩缩器是 Elastic serverless 的一个组件，旨在通过根据实时指标调整项目中节点的大小和数量来优化性能和成本。它监控来自 Elasticsearch 的指标，确定理想的硬件配置，并将配置应用于托管的 Kubernetes 基础架构。了解搜索层指标所涉及的输入和计算后，我们现在可以探索自动扩缩器如何利用这些数据来动态调整项目节点大小和数量，以实现最佳性能和成本效益。

自动扩缩器每 5 秒监控一次搜索层指标。当收到有关总交互式和非交互式数据大小的新指标以及搜索能力范围时，自动扩缩器将确定可能的硬件配置范围。这些配置的范围从最小到最大，由搜索能力范围定义。

然后，自动扩缩器使用 Elasticsearch 报告的搜索负载在可用范围内选择 “所需” 硬件配置，该配置至少具有与测量的搜索负载相匹配的处理器核心数量。

此所需配置可作为稳定阶段的输入，在此阶段，自动扩缩器将决定是否可以立即应用所选的扩缩方向；如果不能，则将其丢弃。缩减有一个 15 分钟的稳定窗口，这意味着需要 15 分钟的连续缩减事件才能发生缩减。扩大规模没有稳定期。扩展事件是非阻塞（non-blocking）的；因此，我们可以在后续操作仍在进行时继续做出扩展决策。对此的唯一限制由上述稳定窗口定义。

然后根据 Elasticsearch 中索引的最大副本数检查配置，以确保有足够的搜索节点来容纳所有配置的副本。

最后，将配置应用于托管的 Kubernetes 基础架构，该基础架构会相应地配置项目大小。

结论

搜索层自动扩展彻底改变了 Elasticsearch serverless 项目的管理。通过利用详细的指标，自动扩展器可确保项目始终保持最佳规模。借助无服务器，用户可以专注于业务需求，而不必担心管理基础设施或在工作负载发生变化时措手不及。

这种方法不仅可以在高需求期间提高性能，还可以在活动较少时降低成本，同时对最终用户完全透明。

因此，用户可以将更多精力放在核心活动上，而不必担心手动调整项目以满足不断变化的需求。这项创新标志着 Elasticsearch 在无服务器计算领域迈出了重要一步，使其既强大又易于使用。

试试看！

准备好自己尝试一下了吗？开始免费试用。
想要获得 Elastic 认证吗？了解下一期 Elasticsearch 工程师培训何时开始！

原文：Elasticsearch Serverless: Search tier autoscaling — Search Labs