重点聚焦!【ES三周年】浅谈Elasticsearch Serverless设计与选择
2023-02-17 01:06:22
最近，云上许多数据存储和分析应用，如MongoDB、Kafka、AstraDB、ClickHouse、DynamoDB等都提供了Serverless模式。这些应用通过Serverless平台，使用者可以轻松部署和管理应用程序，并以最小的成本使用云资源。
(资料图片)
Serverless之所以成为一个热潮，其原因在于这种模式对于云上的应用供应商和用户来说都提供了极大的好处：
减少成本通过Serverless模式，供应商可以节省大量的服务器管理和维护费用。同时，用户只需在使用时付费，而不是预付服务器租赁费用，从而大大降低了成本。灵活性增强通过Serverless模式，用户可以随时在云上部署、扩展和缩减应用。用户不再需要担心服务器管理和维护，可以更加专注于自己的业务。提高可靠性通过Serverless模式，供应商可以提供高可靠性的服务，通过自动扩展和冗余机制，确保应用始终保持可用。而Elasticsearch作为一个被广泛使用的搜索引擎，与其他的数据存储和分析应用一样，用户在成本、稳定性、灵活性上对Elasticsearch服务有很高的要求，相对于已经有的PaaS服务，越来越多的用户期望的是一个完全托管的体验，希望能从管理软件和操作系统版本、管理部署拓扑结构、管理容量和资源大小、应用低级配置（如某个线程池的大小）、管理高可用性、备份和持续的集群操作以及监测健康状况的负担中解放出来。
我们期望Serverless的Elasticsearch service能够处理资源配置，尽可能地自动适应支持用户的工作负载，自动从故障中恢复，加密数据，管理软件升级，执行备份，并执行一个完全管理的服务所需的其他任务。
所以，本文旨在介绍如何设计一个Elasticsearch Serverless应用，并通过探讨一些指导性的原则, 帮助我们理解Elasticsearch Serverless应用应该具备哪些特性，并以此作为我们选择Elasticsearch Serverless的评估参考项。
在设计Elasticsearch serverless应用时，我们需要保证serverless应用不会降低一个PaaS产品所能提供给用户的体验，并且应该尽可能的强化与改进，包括：
可扩展性：Serverless应用必须具有良好的可扩展性，以应对不断增长的数据量和请求量。可用性：应用必须在任何时候都可以对外提供服务，确保高可用性。灵活性：用户必须能够根据自己的需求来调整资源配置，而不需要进行任何繁琐的操作。效率：应用必须在最短的时间内处理请求，提供最快的响应速度。安全性：应用必须具有良好的安全性，以保护用户的数据不被非法访问。在这个基础上，Elasticsearch serverless还应该具备以下特性：
缩放到零，按需计费。Serverless应用的核心优势在于用户只需在使用时付费，而不是预付服务器租赁费用。对于没有占用的资源，Serverless应该能够将其“释放”（共享），并且不对用户收取费用对现在集群模式进行抽象、屏蔽与隔离。具体来说，就是对于Elasticsearch上的集群、节点、索引、分片等概念进行抽象与屏蔽。提供类似“项目”，“空间”等概念，隐藏物理部署，并让用户可以组织相关的资源分组（例如dashboard、可视化和索引等）保留核心API，兼容Elastic生态。在Serverless上，大多数控制部署和Elasticsearch集群的物理性的API需要对用户屏蔽（例如cluster API, node lifecycle API, cloud deployment management APIs），但需要保留索引和搜索的核心API功能，尽可能地让用户能从Elastic Stack广泛的生态系统和强大的社区用例中受益。明确的Serverless的主流使用场景。Elasticsearch serverless并非适用于所有场景，一些高度定制化，或者对集群性能有极致要求，有超高吞吐的场景更适合使用专有集群。Elasticsearch serverless不应该过度承诺，而应该在使用说明中，给用户指明合适的用例，或者不适合的场景。提供场景化的方案。Elasticsearch作为一个通用搜索引擎和数据分析工具，相对于其他工具最大的不同是，其广泛的应用于多种场景，如搜索、企业搜索、日志分析、用户行为分析、全观测，安全分析等各种不同场景。而在不同场景下，Elasticsearch，以及整个Elastic Stack在部署拓扑结构、容量和资源大小配置、应用低级配置、数据类型与管理等方面都有不同，Serverless应该为用户提供对应的场景选择，并根据最佳实践，配置场景对应所需的底层配置和管理。提供完整的Elastic Stack的Serverless。这是对场景化方案的延续，特别是对于用于企业搜索、日志分析、全观测性、安全的场景，类似于像采集模块的集中管理软件、机器学习节点、数据处理软件、APM拨测软件等，也应该提供Serverless模式，并且能够在界面上完成Serverless应用的端到端的配置。提供平衡成本与性能的杠杆。Serverless虽然为用户屏蔽及代管了操作和管理层面的许多细节。但不意味着用户不再需要针对自己的情况进行调整。Serverless应用应该抽象出调节性的配置功能，比如，在日志场景中，可以选择数据分层存储的数据留存时间、所使用的存储介质，或者选择在可能的数据洪峰来临时，优先保证吞吐而是账单。对于搜索场景，可以选择“普通，”“快”，“极快”，“多”，“极多”等条件，来描述对延迟与并发的要求，以方便调节，以便在短期或长期上调整，获得更大的缓存层以及更多的副本。与已有的Elasticsearch集群协同。虽然Elasticsearch Serverless很难与已有的自建或云上托管的Elasticsearch集群100%兼容，但至少在数据迁移以及跨集群查询（CCS）、跨集群复制（CCR）上能够对接上，以减少使用上的摩擦。上面，我们列举了一个设计良好的Elasticsearch serverless应该具备的特性。通过了解这些特性，我们能够更好的从整体上了解及评估各个云厂商提供的Elasticsearch serverless。但当我们讨论如何选择时，将会有更多的考虑因素，这里也将进行探讨选择的指导原则，而重点会落在用户体验上。
在上文提到的Elasticsearch Serverless设计考虑因素会是功能清单的基础。我们可以在电子表格中列举所有考虑条件和考虑项，并进行全面的测试，确保业务正常运行的同时，也验证Serverless提供的基础功能是有效的，而非只是宣传博眼球。根据测试的结果，进行打分比较，最终打出一个可以比较的客观的评估分数用于选择。一般流程如下：
创建表枚举您定义的所有条件确定每个标准的权重评估并测试所有候选Elasticsearch Serverless服务的每个标准将您对该标准的评估乘以分配的权重，从而生成每个厂商的标准分数总结各个Elasticsearch Serverless所有标准的分数当然，功能记分卡不会直接确定最终的选择。我们还需要考虑功能之外的因素。
Elasticsearch serverless相对于自建集群和PaaS托管集群会更复杂，同时，因为对API进行了删减，向用户隐藏了物理架构，日志、指标等细节，会使得Elasticsearch serverless更像是一个黑盒产品，其最终的呈现有可能会超出我们原先对于Elasticsearch的理解。因此，一个具备更好可观测性的Elasticsearch serverless产品会是更好的选择。
目前大多数的Elasticsearch serverless都不提供集群的日志和指标信息，以至于我们无法在服务器端及时发现可能的错误和异常。因此需要进行比较详细的测试和POC。在测试中，我们需要验证每一个API的功能，特别是对接口的在过压情况下的反应，是否出现了服务响应错误，响应过慢，无响应。一个好的serverless服务，会在控制台上提供主动的异常告知，同时，在客户端，会返回表述清楚的错误状态码和解释。
相对于可以看到源码，自己完全掌控部署和管理的自建及云上Elasticsearch集群，Elasticsearch Serverless更加需要详尽的文档。特别是考虑到前面提到的可观测性的问题，测试中异常不可见的问题，越是详尽文档，越能帮助我们快速的解决问题。特别是serverless服务应该是一项自助式的服务。“自助式”代表着我们可以没有供应商参与的情况下自己构建所需的服务。一方面，这依赖于产品在易用性上的设计，另一方面，则是依赖产品的文档，通过文档的指引，或构建服务或解决问题。
仅目前来看，大多数的Elasticsearch serverless的文档都差强人意，但用户还是可以自己判断哪家的文档写得有诚意的。
大多数Serverless用户，在初始选择Serverless的时候都是非常谨慎的。通常用户会从较小规模开始，然后不断增长。通过在这个评估的初始阶段提供出色的体验，好的Elasticsearch serverless将留住更多的这些用户，并促使他们更多的与服务一起成长。
因此，Elasticsearch serverless成功的关键将不是比拼谁推出得早，而是一场用户体验的比拼。谁提供的Serverless服务更加人性，更加经济，更加弹性，更容易运维，更能满足用户的需求，谁就将在这个竞争中获得优势。
