带你了解：Elasticsearch Serverless 搜索层的自动扩展

我们新推出的无服务器产品的一个关键特点是，允许用户部署和使用 Elastic，而无需管理底层的项目节点。为此，我们开发了搜索层自动扩展策略，根据多个参数动态选择节点的大小和数量。这个创新确保了你不再需要担心资源的过度配置或不足配置问题。

无论你面临的是波动的流量模式、意外的数据峰值还是逐渐的增长，搜索层自动扩展都能根据搜索活动无缝调整分配的硬件。自动扩展是基于每个项目进行的，并且对终端用户完全透明。

简介

Elastic Serverless 是 Elastic 的一款完全托管产品，它使你能够在不管理底层 Elastic 基础设施的情况下，专注于从数据中提取最大价值。

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

本文描述的自动扩展特定于 Elastic 无服务器产品中的 Elasticsearch 项目类型。可观测性和安全性可能有不同的自动扩展机制，以满足其独特的需求。

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

搜索层自动扩展的输入

为了展示自动扩展如何工作，我们将深入探讨用于做出扩展决策的各种指标。

当启动一个新的无服务器 Elasticsearch 项目时，用户可以选择两个参数，这些参数将影响自动扩展的行为：

• 提升窗口：定义在特定时间范围内，搜索数据被认为是提升的。
  • 提升数据：在提升窗口内的数据被分类为提升数据。所有带有 @timestamp 的时间基数据和所有非时间基数据都属于提升数据类别。这种时间基分类使系统在分配资源时能够优先处理这些数据。
  • 非提升数据：在提升窗口外的数据被认为是非提升数据。这些旧数据仍然可以访问，但分配的资源较少。
• 搜索能力：控制项目中分配给提升数据的虚拟计算单元（VCU）数量的范围。搜索能力可以设置为：
  • 成本效益：限制提升数据的可用缓存大小，优先考虑成本效益而不是性能。适合希望以低成本存储大量数据的客户。
  • 平衡：确保所有提升数据都有足够的缓存，以实现更快的搜索。
  • 性能：提供更多资源，以更快响应更高数量和更复杂的查询。

提升窗口将决定项目中提升和非提升数据的数量。

我们将项目的提升数据定义为在提升窗口内的数据量。

提升数据的总大小以及所选搜索能力范围的下限将决定项目的基本硬件配置。这种方法优于缩减至零（或接近零），因为它有助于保持后续请求的可接受延迟。通过保留缓存并确保 CPU 能够立即处理传入的请求，这种方法避免了从 CSP 提供硬件所带来的延迟，并确保系统准备好及时处理传入的请求。

请注意，基本配置可以通过更多数据的摄取而增加，或者如果时间序列数据超出提升窗口而减少。

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

基于负载的自动扩展

基于交互数据的自动扩展只是其中的一部分。它没有考虑传入搜索流量对搜索节点的负载。为此，我们引入了一个新指标，称为 搜索负载。搜索负载是处理当前搜索流量所需的物理资源量的度量。

搜索负载考虑了搜索流量在给定时间对节点资源使用的影响，从而允许动态自动扩展响应。

什么是搜索负载？

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

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

搜索负载间接考虑了这些资源。它通过在给定测量间隔内搜索线程所花费的时间来实现。如果线程在等待资源（IO）时阻塞，这也会增加线程的执行时间。如果所有线程都被 100% 利用并且还有排队，这表明需要向上扩展。相反，如果没有排队且搜索线程池的利用率低于 100%，这表明可以向下扩展。

如何计算搜索负载？

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

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

为了描述搜索负载的计算方式，我们将逐步讲解每个方面以解释其基本原理。

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

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

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

然后，我们将 threadUtilization 百分比乘以 numProcessors 来确定 processorsUsed，即使用的处理器核心数量。我们通过指数加权移动平均（EWMA，一种更重视最近数据的移动平均）记录这个值，以平滑小的活动突发。这得到了用于 threadPoolLoad 的值。

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

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

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

给定节点的搜索负载是 threadPoolLoad 和 queueLoad 的总和。

搜索负载报告

每个搜索节点定期向主节点发布负载读数。这将每隔一个设定的时间间隔发生，或者如果检测到负载的重大变化，也会触发报告。

主节点分别跟踪每个搜索节点的状态，并响应各种生命周期事件进行簿记。当搜索节点被添加或删除时，主节点添加或删除相应的负载条目。

主节点还为每个条目报告质量评级：准确、最低或缺失。准确表示最近报告了该指标，而缺失则是在新节点尚未报告搜索负载时分配的。

当主节点在配置的时间段内没有从搜索负载接收到更新时，质量被认为是最低，例如，如果一个节点暂时不可用。质量也在搜索节点的负载值包含不被认为是未来工作的指示的工作（如下载将随后被缓存的文件）时报告为最低。

质量用于指导扩展决策。当任何节点的质量不准确时，我们不允许缩减。然而，无论质量评级如何，我们都允许扩展。

自动扩展器

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

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

然后，自动扩展器使用 Elasticsearch 报告的搜索负载，在可用范围内选择一个“理想”的硬件配置，该配置至少有足够的处理器核心来处理测量的搜索负载。

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

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

最后，将配置应用于托管的 Kubernetes 基础设施，根据需要调整项目大小。

结论

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

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

结果是，用户可以更多地专注于核心活动，而无需不断担心手动调整项目以满足不断变化的需求。这一创新标志着在使 Elasticsearch 在无服务器计算领域既强大又用户友好方面迈出了重要一步。