Elasticsearch架构设计原则与反模式：为扩展性而设计

背景介绍

随着现代企业的不断发展，数据量呈现爆炸式增长，系统扩展性成为一个至关重要的课题。Elasticsearch 作为一个强大的分布式搜索和分析引擎，在应对大规模数据处理方面展现了其卓越的能力。然而，设计一个高效且可扩展的 Elasticsearch 集群并非易事，本文旨在通过分享一些扩展性设计原则和常见的反模式，帮助用户更好地构建和优化他们的 Elasticsearch 集群。

阅读指导

在我们与客户合作的过程中，发现很多用户在设计和部署 Elasticsearch 集群时，常常会遇到性能瓶颈和扩展性问题。本文总结了这些问题的成因，并提供了一些实际的解决方案和优化建议，旨在帮助用户避开常见的错误，提高集群的性能和稳定性。

通过阅读本文，读者将了解到：

1. 如何设计高效的 Elasticsearch 集群。
2. 常见的扩展性反模式及其解决方案。
3. 实际案例分析，帮助理解理论应用。

设计高效的 Elasticsearch 集群

当我们使用 Elasticsearch 时，通常会根据当前业务规模和负载进行预估。但随着业务规模持续增长，访问的用户量激增，我们需要在原有集群上进行两个主要的操作：升级和扩展。两个方面都很重要，对于扩展，扩展性原则是至关重要的指导方针。以下将每一个原则详细展开描述，帮助用户更全面地理解和应用这些原则。

扩展性原则

在设计 Elasticsearch 集群时，需要遵循一些基本的扩展性原则：

1. 数据工作负载（Data Workloads）：根据不同的数据工作负载（如 Ingest、Search 和 Store）配置相应的节点和资源。高 CPU 和 I/O 节点适用于高事件写入速率的场景，高内存和快速存储节点适用于低延迟查询，高密度存储节点适用于长期数据保留。
2. 工作负载隔离（Workload Isolation）：通过隔离不同类型的工作负载，可以简化扩展过程并提高资源利用率。
3. 分片策略（Shard Strategy）：确定合适的分片数量对于集群的可靠性至关重要。分片是工作 负载的主要分割单元，分片越相似，负载平衡就越容易实现。

以下图展示了一个典型的 Elasticsearch 集群架构，该架构根据数据热度将数据分为热数据、温数据和冷数据，并使用不同的节点角色来处理不同的数据工作负载：

Elasticsearch Cluster Architecture

数据工作负载（Data Workloads）

在设计和配置 Elasticsearch 集群时，理解和处理不同的数据工作负载是至关重要的。每种工作负载对资源的需求各不相同，需要相应地调整节点配置和资源分配。

Elasticsearch 集群通常需要处理三种主要的数据工作负载：Ingest、Search 和 Store。每种工作负载对资源的需求不同，需要相应地配置节点和资源。

数据工作负载的分类

我们可以通过以下三个主要的维度来分类和处理工作负载：计算（Compute）、内存（Memory）和存储（Storage）。

不同的复杂对资源的消耗侧重

写入密集型工作负载（Write-Heavy Workloads）

写入密集型工作负载通常涉及大量的数据写入操作，如时间序列数据、日志数据，并且通常需要进行 ETL处理（Pipelines）。这些工作负载的特点是每秒处理大量文档（Docs/sec）或每天处理大量数据（TB/day）。对于这类工作负载，计算资源（Compute）和存储资源（Storage）的配置尤为重要：

• 计算资源：写入密集型工作负载需要高性能的 CPU 来处理大量的数据写入和索引操作。配置具有强大处理能力的节点可以显著提高写入性能。
• 存储资源：高效的存储设备对于写入密集型工作负载至关重要。使用 NVMe SSD 等高性能存储设备可以提高数据写入和检索的速度，减少延迟。

读取或更新密集型工作负载（Read or Update-Heavy Workloads）

读取或更新密集型工作负载包括频繁的数据读取和更新操作，如实时查询、向量存储（Vector Store）、检测回溯（Detection Look-back）等。这类工作负载需要大量的内存资源来支持高频查询和数据更新：

• 内存资源：对于频繁的读取和更新操作，高内存配置是必不可少的。充足的内存可以缓存更多的数据，提高查询响应速度，减少查询延迟。
• 计算资源：虽然读取操作通常对计算资源的需求不如写入操作高，但复杂查询和更新操作仍然需要强大的计算能力来处理。

只读工作负载（Read-Only Workloads）

只读工作负载主要涉及数据的长时间保存和检索，如数据归档、快照和历史数据查询。这类工作负载的特点是数据写入频率低，但需要对大量历史数据进行高效的检索：

• 存储资源：只读工作负载对存储资源的需求最大。为了保持数据的可访问性，使用高密度存储设备（如 HDD）可以提供足够的存储容量，降低成本。
• 内存资源：尽管只读工作负载主要依赖存储资源，但适当的内存配置仍然有助于提高数据检索的速度，特别是在进行复杂查询时。

工作负载隔离（Workload Isolation）

工作负载隔离是提升 Elasticsearch 集群扩展性和资源利用率的重要策略。通过将不同类型的工作负载分离处理，我们可以更高效地管理资源，避免资源竞争和性能瓶颈。在工作负载隔离中，有三个主要的策略：分块（Chunk）、分组（Group）和分布（Distribute）。

工作负载隔离

分块（Chunk）

分块策略的核心是将大型工作负载划分为大小相似的部分，确保每个部分的工作量均衡。这种方法有助于在集群中实现更均匀的负载分布，提高资源利用率。具体来说，我们可以将索引、分片和连接等划分为多个相似大小的部分，以便于并行处理。

示例：假设我们有一个非常大的日志数据流，每天要处理数十亿条日志记录。通过将这个数据流分成多个分片，并将每个分片的数据量保持在相似的大小，可以更均衡地分配写入和查询负载，避免某个分片过载。

分组（Group）

分组策略通过将工作负载按类别进行分组，使其与资源对齐，达到规模经济的效果。具体方法是根据节点角色、数据层和流水线等，将相似的工作负载集中在一起处理。这种方式可以减少资源浪费，提高集群的整体效率。

示例：在一个安全监控系统中，我们可以将实时检测任务和历史数据存储任务分开，分别由专门的节点处理。实时检测任务需要快速响应，可以分配更多的 CPU 和内存资源；而历史数据存储任务则主要依赖存储资源，可以分配高密度存储节点。

分布（Distribute）

分布策略的目标是通过最少的分块数量来最大化每个工作单元的资源利用率。通过合理分配节点和代理，我们可以确保每个工作单元的负载尽可能均衡，从而提高整个系统的处理效率。

示例：在处理大规模搜索请求时，我们可以将搜索请求分配到多个搜索节点上，并通过 benchmark测试了解每个单元的处理上限，计算每个节点需分配的请求。通过这种方式，可以避免单个节点过载，提升整体搜索性能。

分片策略（Shard Strategy）

分片是 Elasticsearch 中工作负载的主要分割单元和平衡单元。为了确保集群的高效运行和负载均衡，分片策略的设计至关重要。以下是详细的分片策略设计指南：

分片的工作与平衡

在 Elasticsearch 中，分片不仅是工作的主要分割单元，也是实现负载平衡的关键。分片越相似，负载平衡就越容易实现。这意味着我们在创建分片时应尽量保持每个分片的大小和工作量相似，以便于系统能够更均衡地分配资源和处理请求。

需要注意的是，Elasticsearch 的响应速度取决于最慢的分片。因此，如果某个分片处理速度较慢，整个查询的响应时间都会受到影响。这就要求我们在设计分片策略时，尽量避免创建过大或过小的分片，以免影响整体性能。

高负载数据写入分片策略（High-Volume Ingest Sharding Strategy）

在高负载数据写入场景下，分片策略的设计需要特别注意以下几点：

1. 分片与热节点对齐：为了获得最佳性能，应将分片与热节点对齐。热节点处理高频数据写入，因此需要足够的分片来分担写入负载。
2. 分片数量计算：推荐的主分片数量计算公式是 num_shards = (hot_nodes - 1) / 2，并使用一个副本。这种配置能够在保证容错的同时，最大化吞吐量。
3. 动态调整模板：在集群扩展或缩减时，动态调整索引模板中的分片配置，以适应新的节点数量。这样可以确保在集群规模变化时，分片数量和分布能够及时调整，保持负载均衡。
4. 关注高事件率索引：对于事件率（EPS）较高的前 10 个索引，特别关注其分片策略。这些索引通常是系统负载的主要来源，优化其分片策略能够显著提升整体性能。
5. 避免单一索引热点：通过设置 total_shards_per_node: 1，可以防止某个索引的所有分片都集中在同一个节点上，避免出现单点过载的情况。
6. 分片滚动策略：建议在分片大小达到 30-40GB 时进行滚动。这种策略可以加快 force_merge 和快照的速度，减少维护开销。
7. 减少空分片和低负载分片：尽量减少空分片和低负载分片的数量，这些分片不仅浪费资源，还会影响集群性能。目标是将集群中的分片数量控制在 100,000 以下。

实际案例分析

通过分析多个实际案例，我们可以更好地理解和应用分片策略及其对集群性能的影响。以下是三个不同类型客户的集群配置及其性能表现。

大型银行（美国）

该银行在 Elasticsearch Service (ESS) 上托管了 6 个以上的集群。其参考集群配置如下：

• 总内存：约 5.8 TB RAM
• 分片总数：约 20,000 个
• 数据层：
  • 18 个热节点（每节点约 40 个分片）
  • 0 个温节点
  • 24 个冷节点（每节点约 100 个分片）
  • 56 个冻结节点（每节点约 300 个分片）
• 数据写入速率：400,000 EPS
  • 典型节点处理速率：约 15,000-20,000 EPS
  • 异常节点处理速率：约 10,000-15,000 EPS
• 每日数据处理量：约 30 TB

这个案例展示了高负载环境下，通过合理配置热节点和冷节点来实现高效的数据处理和存储。

大型安全管理服务提供商（美国）

该公司在 ESS 上托管了 7 个以上的集群。其参考集群配置如下：

• 总内存：约 5.1 TB RAM
• 分片总数：约 23,000 个
• 数据层：
  • 28 个热节点（每节点约 45 个分片）
  • 2 个温节点（每节点约 400 个分片，用于存储空分片和低负载分片）
  • 34 个冷节点（每节点约 30 个分片）
  • 24 个冻结节点（每节点约 825 个分片）
• 数据写入速率：240,000 EPS
  • 典型节点处理速率：约 9,000 EPS
  • 异常节点处理速率：约 4,000 EPS
• 每日数据处理量：约 13 TB

这个案例展示了在安全数据处理场景中，通过使用温节点来存储空分片和低负载分片，优化热节点和冷节点之间的平衡。

大型酒店机构（欧洲、中东和非洲）

该机构在 ESS 上托管了 12 个以上的集群。其参考集群配置如下：

• 总内存：约 4 TB RAM
• 分片总数：约 12,000 个
• 数据层：
  • 40 个热节点（每节点约 20-30 个分片）
  • 0 个温节点
  • 0 个冷节点
  • 10 个冻结节点（每节点约 1,100 个分片）
• 数据写入速率：180,000 EPS
  • 典型节点处理速率：约 4,000 EPS
  • 无异常节点

这个案例展示了在高数据写入环境下，通过配置大量热节点和冻结节点，确保数据的快速写入和长期存储。

实际案例分析总结

在分析了大型银行、大型安全管理服务提供商和大型酒店机构的实际案例后，我们可以总结出一些在大规模 Elasticsearch 集群设计中的关键经验和最佳实践。

案例总结要点

1. 低热节点分片数（Low hot node shard counts）：实际案例表明，保持较低的热节点分片数有助于提高集群的稳定性和重启速度。通过合理配置热节点的分片数量，可以确保在高负载数据写入和查询场景下，集群能够高效运行。
2. 温节点使用较少（Warm nodes are rarely used）：在大规模观测（o11y）和安全场景中，温节点的使用较少。温节点主要用于存储空分片和低负载分片，而大部分数据处理工作由热节点和冷节点完成。这样可以简化集群架构，并提高数据处理效率。
3. 无温节点优化强制合并（No warm nodes allows optimal force_merge）：没有温节点的配置使得在热节点上进行本地 NVMe 存储的强制合并（force_merge）操作更加高效。热节点能够快速处理大量数据写入，并通过强制合并优化存储和查询性能。
4. 冷节点保障本地存储（Cold nodes guarantee local storage）：冷节点确保了近期数据的本地存储，特别是用于机器学习（ML）和规则（rules）等应用场景。这种配置能够在确保数据持久性的同时，提高查询效率。
5. 过多冻结分片导致性能问题（Excessive frozen shard counts lead to slow search and restarts）：实际案例表明，过多的冻结分片会导致搜索和重启速度变慢。因此，在设计冻结分片策略时，需要平衡存储成本和查询性能，避免过度依赖冻结分片。
6. 多集群策略（Multi-cluster strategy）：在数据量超过 10 TB/天的场景中，多集群策略非常常见。通过将数据源或用户组划分到不同的集群，可以有效避免单个集群的过载问题，提高系统的可靠性和性能。

通过实际案例的分析，我们可以看到，不同类型的工作负载和业务需求需要不同的分片策略和节点配置。合理应用这些策略，能够显著提升 Elasticsearch 集群的性能和扩展性。希望这些案例分析能够为用户在设计和优化自己的 Elasticsearch 集群时提供有价值的参考和指导。

反模式分析：性能反模式总结

在设计和优化 Elasticsearch 集群时，除了需要了解基本的扩展性原则，理解和避免常见的性能反模式至关重要。就如同做编程，我们既要熟悉各种设计模式，也要了解各种编程中的坏味道。以下是一些常见的反模式以及它们对系统性能的影响和应对措施。

使用协调节点进行数据写入（Using Coordinating Nodes for Ingest）

通常来说，对于大规模集群，我们可以通过协调节点来进行查询的优化以降低数据节点的负载，避免因为复杂的查询而影响写入的吞吐。但往往因为疏于设计，在写入侧仍然把所有的流量首先导向协调节点：

使用协调节点进行数据写入

问题描述：

协调节点主要用于查询的分发和归整， 如果大量的查询也直接发送到协调节点，则会成为瓶颈，如图中场景

• 写入侧， 3 个 Logstash 节点，每个节点 16 个核心，单核处理 3,000 dps，总处理能力为 144,000 dps。
• 处理侧，10 个 data 节点，每个节点 32 个核心，单核处理 1,000 dps，总处理能力为 320,000 dps（包括副本）。

如果先把数据发送到协调节点，那么协调节点就会成为瓶颈点

解决方案：

避免使用协调节点进行数据写入，直接将数据写入处理节点（如热节点），以提高资源利用率和系统吞吐量。

直接将数据写入处理节点

在数据层之间集中工作负载（Concentrating Workloads Between Data Tiers）

图示：

Concentrating Workloads Between Data Tiers

问题描述：

在我们的一些常规架构设计中，我们可能会看到如下面的架构，我们可能在热层保留了 7 天的数据， 在温层保留了 14 天的数据，根据数据量来估算了温节点的大小

• 12 个热节点，每个节点 32 个核心，总容量 1.7 TB，处理总数据量 20.4 TB。
• 4 个温节点，每个节点 8 个核心，总容量 10 TB，处理总数据量 40 TB。

但这样的架构会存在如下问题：

• 性能瓶颈：温节点往往带来数据流瓶颈。例如，温节点的 I/O 性能较低，执行强制合并等操作会导致长时间的延迟。
• 不经济：温节点在成本效益方面往往不如热节点和冷节点。如果温节点未能提供足够的价值，可能会造成资源浪费和性能问题。
• 重启延迟：高分片密度的温节点在重启时需要较长时间来重新初始化所有分片，导致系统不可用时间延长。（索引在温层并非只读索引）

解决方案：

• 仅在必要时使用温节点：避免过多依赖温节点，确保其主要用于存储和处理低活动的分片。可以只架设热层和冷层，甚至只架设热层和冷冻层
• 如果必须保留温层，可以考虑在热层完成 force merge；对于非 top 10 繁忙的分片，无需进行 shrink

使用高分片数和小batch size（Using High Shard Counts with Small Batch Sizes）

图示：

问题描述：

高分片数和小批量写入会导致 IOPS 爆炸，严重影响存储系统性能。例如，Logstash 默认批量大小为 125 个文档，假设有 7 年的数据分布在 7 个索引中，每个索引有 50-100 个分片，总共有 500 个分片。结果是每个分片平均写入 0.25 个文档，导致平均每次写入只有一个文档的写入性能极低。

解决方案：

优化批量大小和分片策略，减少空分片和低负载分片的数量。确保每次写入操作尽可能地高效，避免过多小批量写入。

总结

设计一个高效且可扩展的 Elasticsearch 集群需要考虑多方面的因素，从分片策略到节点角色配置，再到工作负载隔离。通过避免常见的反模式，并遵循扩展性设计原则，可以显著提高集群的性能和稳定性。希望本文提供的原则和案例分析能够帮助用户更好地理解和应用 Elasticsearch 的扩展性设计。

参考文献

• Elasticsearch 官方文档
• Elasticsearch 官方博客

希望本文对您有所帮助！如果有任何问题或需要进一步的支持，请随时联系我们的技术团队。