无状态（stateless）—— 解锁使用Elasticsearch的新方式
我们开始的地方
Elasticsearch的第一个版本于 2010 年作为分布式可扩展搜索引擎发布，允许用户快速搜索并获得关键见解。十二年的发展和超过 65,000 次提交后，Elasticsearch 继续为用户提供久经考验的解决方案，以解决各种搜索问题。得益于 1,500 多名贡献者（包括数百名 Elastic 全职员工）的努力，Elasticsearch 不断发展以应对搜索领域出现的新挑战。
在 Elasticsearch 生命周期的早期，当有人提出数据丢失问题时，Elastic 团队经历了多年的努力来重写集群协调系统，以确保确认的数据得到安全存储。当发现在大型集群中管理索引很麻烦时，Elastic 团队致力于实施完善的ILM 解决方案，通过允许用户预定义索引模式和生命周期操作来自动化这项工作。由于用户发现需要存储大量指标和时间序列数据，因此添加了更好的压缩等各种功能以减少数据大小。随着搜索大量冷数据的存储成本增加，我们投资于创建可搜索的快照作为一种直接在低成本对象存储上搜索用户数据的方法。
这些投资为 Elasticsearch 的下一次演进奠定了基础。随着云原生服务和新编排系统的增长，我们决定是时候发展 Elasticsearch 以改善使用云原生系统时的体验了。我们相信，这些变化为在云上运行 Elasticsearch 带来了运营、性能和成本改进的机会。
我们要去哪里——未来是stateless
运维或编排 Elasticsearch 时的主要挑战之一是它依赖于许多持久状态，因此它是一个有状态的系统。三个主要状态是事务日志、索引存储和集群元数据。这种状态意味着存储必须是持久的，并且在节点重新启动或替换期间不能丢失。
Elastic Cloud 上现有的 Elasticsearch 架构必须跨多个可用区复制索引，以在中断的情况下提供冗余。我们打算将这些数据的持久性从本地磁盘转移到对象存储，例如 AWS S3。通过依赖外部服务来存储这些数据，我们将不再需要索引复制，从而显着减少用于写吞吐的硬件资源。由于 AWS S3、GCP 云存储和 Azure Blob 存储等云对象存储具备跨可用区复制数据的特性，此架构还提供了非常高的持久性保证。而这点，在腾讯云Elasticsearch service上，我们也可以采用类似的方式，通过COS做到这个点。
将索引存储转移到外部服务中还将允许我们通过分离读写职责来重新构建 Elasticsearch。我们打算将架构简化为一个索引层和一个搜索层，而不是让主节点和副本节点同时处理这两种工作负载。分离这些工作负载将使它们能够独立扩展，并且选择更适合各自的用例的硬件资源。它还有助于解决搜索和索引负载可能相互影响的长期挑战。
在进行了数月的概念验证和实验阶段之后，我们确信这些对象存储服务能够满足我们对索引存储和集群元数据的设想。我们的测试和基准表明，这些存储服务可以满足我们在 Elastic Cloud 中看到的最大集群的高索引需求。此外，支持对象存储中的数据降低了索引成本，并允许简单地调整搜索性能。为了搜索数据，Elasticsearch 将使用久经考验的可搜索快照模型，其中数据永久保存在云原生对象存储中，本地磁盘用作频繁访问数据的缓存。
为了帮助区分，我们将现有模型描述为“节点到节点”复制的模型。在此模型的热层中，主分片和副本分片都执行相同的繁重工作来处理摄取和服务搜索请求。这些节点是“有状态的”，因为它们依靠本地磁盘来安全地保存它们托管的分片的数据。此外，主分片和副本分片不断通信以保持同步。他们通过将在主分片上执行的操作复制到副本分片来做到这一点，这意味着这些操作（主要是 CPU）的成本是针对每个指定的副本产生的。为摄取执行这项工作的相同分片和节点也为搜索请求提供服务，因此必须在考虑到这两种工作负载的情况下进行配置和扩展。
除了搜索和摄取之外，节点到节点复制模型中的分片还处理其他CPU密集型的任务，例如合并 Lucene 段。虽然这种设计有其优点，但根据我们多年来从客户那里学到的知识以及更广泛的云生态系统的发展，我们看到了很多机会。
新架构可实现许多即时和未来的改进，包括：
- 您可以显着提高相同硬件上的摄取吞吐量，或者以另一种方式看待它，显着提高相同摄取工作负载的效率。这种增加来自—— 每个副本不再需要执行重复的索引操作。CPU 密集型索引操作只需在摄入层上发生一次，然后将生成的段发送到对象存储。在那里，数据已准备好由搜索层按原来的方式提供服务。
- 您可以将计算与存储分开以简化集群拓扑。如今，Elasticsearch 拥有多个数据层（内容、热、温、冷和冻结）以及与其匹配硬件配置需求。Hot tier 用于近乎实时的搜索，frozen 用于不太频繁搜索的数据。虽然这些层级提供了价值，但它们也增加了复杂性。在新架构中，将不再需要数据层，从而简化了 Elasticsearch 的配置和操作。我们还将索引与搜索分开，这进一步降低了复杂性并允许我们独立扩展这两个工作负载。
- 通过减少必须存储在本地磁盘上的数据量，您可以体验到索引层存储成本的降低。目前，Elasticsearch 必须在热节点（主节点和副本）上存储完整的分片副本以用于索引目的。使用直接索引到对象存储的无状态方法，只需要一部分本地数据。而对于append only的日志场景，仅需要存储某些元数据就可以进行索引。这将显着减少索引所需的本地存储。
- 您可以降低与搜索查询相关的存储成本。通过使可搜索快照模型成为搜索数据的原生模式，与搜索查询相关的存储成本将显着降低。根据用户对搜索延迟的需求，Elasticsearch 将允许调整以增加对频繁请求数据的本地缓存。
基准测试 — 75% 的索引吞吐量提高
为了验证这种方法，我们实施了广泛的概念证明，其中数据仅在单个节点上建立索引，并且通过云对象存储实现复制。我们发现，通过消除将计算资源用于索引复制的需求，我们可以将索引吞吐量提高 75% 。此外，与索引数据并在本地写入数据的操作相比较，简单地从对象存储中提取数据所需要的CPU计算量将大大减少。这意味着搜索节点将能够完全将其 CPU 用于搜索。
这些性能测试是在一个两节点集群上针对所有三个主要公共云提供商（AWS、GCP 和 Azure）进行的。随着我们追求在生产环境中做到Stateless，我们打算继续建立更大的基准。
索引吞吐量
CPU使用率
通过Stateless来减少成本
Elastic Cloud 上的无状态架构将允许您减少索引开销、独立扩展摄取和搜索、简化数据层管理并加速操作，例如扩展或升级。这是 Elastic Cloud 平台实现重大现代化的第一个里程碑。在腾讯云的Elasticsearch Service上，我们也将按此技术方向演进。
成为我们Stateless愿景的一部分
有兴趣在其他人之前尝试此解决方案吗？您可以通过我们的社区Slack频道与我们联系。我们希望您的反馈有助于塑造我们新架构的方向。
