Elasticsearch 实例管理在京东的使用场景及演进之路

Elasticsearch 是一个开源的分布式 RElasticsearchTful 搜索引擎，作为一个分布式、可扩展、实时的搜索与数据分析引擎，它可以快速存储、搜索和分析大量数据。同时，Elasticsearch 也支持具有负责搜索功能和要求的应用程序的基础引擎， 因此可以应用在很多不同的场景中。

1Elasticsearch 在京东的使用场景

由于较高的性能和较低的使用门槛，京东内部有很多的场景都在使用 Elasticsearch。

2015 年 6 月，京东着手开发了 Elasticsearch 的托管平台——杰思 (JElasticsearch)。杰思平台主要负责 Elasticsearch 集群的部署、运行监控、数据迁移、权限管理、插件开发、集群升级等日常维护工作。

目前杰思平台管理的集群覆盖了京东多条业务线，同时也覆盖了很多应用场景：

补充关系型数据库的结构化数据查询

主要应用的业务是商品、促销、优惠券、订单、收银台、物流、对账、评论等大数据量查询。此场景的核心诉求是高性能、稳定性和高可用性，部分场景会有检索要求，通常用于加速关系型数据库，业务系统通过 binlog 同步或业务双写完成数据同步。

全文检索功能

主要的应用场景是应用、安全、风控、交易等操作日志，以及京东部分品类商品搜索。此类日志化场景对写要求很高，查询性能及高可用等要求相对较低，大的业务写会达到数千万 / 秒，存储以 PB 为单位来计算。

这些场景对磁盘、内存有比较高的要求，因此，京东也做了相应优化，用于减少内存消耗，提升磁盘整体使用率，使用更廉价的磁盘来降低成本等等。

实时数据分析引擎，形成统计报表

主要应用的业务是物流单的各种分析、订单数据分析、用户画像等。因为业务数据分析纬度较多，flink、storm 等流式分析对于某些报表场景不太适用，批处理实时性又成为问题，所以近实时分析的 Elasticsearch 就成为了这些业务的选择。

Image1：Elasticsearch +ChubaoFS 支持京东商城应用场景

在应用 Elasticsearch 的 5 年时间中，京东从最初的几个场景应用变成了覆盖各条业务线，从最初的几台机器变成了现在的上千机器和几千集群的量级，运维压力也随之而来了。

目前，京东在日常运维 ELasticsearch 集群时，主要面临以下几个问题：

• IO 读写不均匀，部分节点 IO 压力非常大；

• 冷数据节点存储量受限制于单机的最大存储；

• close 后的索引节点故障无法进行 recovery，导致数据丢失的风险。

为了解决这些问题，京东应用了 ChubaoFS。ChubaoFS 是京东自研的、为云原生应用提供高性能、高可用、可扩展、 稳定性的分布式文件系统，设计初衷是为了京东容器集群提供持久化存储方案，同时也可作为通用云存储供业务方使用，帮助有状态应用实现计算与存储分离。

ChubaoFS 支持多种读写模型，支持多租户，兼容 POSIX 语义和 S3 协议。ChubaoFS 设计的每个 pod 可以共享一个存储卷，或者每个 pod 一个存储卷，当容器所在的物理机宕机后，容器的数据可以随着容器被同时调度到其他宿主机上， 保障数据可靠存储。

Image2: Elasticsearch+ChubaoFS=Decouping Compute from Storage

2Elasticsearch 实例管理演进之路

京东的 Elasticsearch 实例管理也是一个不断摸索、不断爬坑的过程。

初始阶段

最初，京东 Elasticsearch 集群部署是完全没有架构可言的，集群配置也都采用默认配置，一台物理机启动多个 Elasticsearch 进程，进程间完全共享服务器资源，不同业务之间使用集群进行隔离，这种形式使用服务器 CPU 和内存得到了充分利用。

Image3：物理机部署

当系统运行了一段时间之后，这种部署方式的弊端开始显现出了。

• 实例容易受到其他节点的影响，重要业务抖动问题没有有效方式避免。

• 物理机内存被 cache 占用，新创建实例启动时耗时特别长。

• 实例存储受单机磁盘容量限制，数据迁移时有发生。

容器隔离阶段

由于物理机直接部署 Elasticsearch，无法管理 CPU、内存，各个节点相互影响明显，甚至会影响到稳定性。所以，针对上述情况，京东做出了改善方案——调研资源隔离方式。

当时比较主流的资源隔离方式有两种，Docker 容器化和虚拟机。

2016 年时 Docker 容器化技术已成型，但虚拟技术比较成熟有大量工具、生态系统完善。相对于虚拟机的资源隔离，Docker 不需要实现硬件虚拟化，只是利用 cgroup 对资源进行限制，实际使用的仍然是物理机的资源，所以在资源使用率方面效率更高，我们经过测试使用 Docker 化后性能损失相对较小几乎可以忽略。

Docker 是资源限制，启动时不需要加载操作系统内核，可以毫秒级启动。启动对资源的消耗要低很多，可以做到快速的启停。另外由于是资源限制类，只限制最大使用量而不隔离最小，这样又可以做到虚拟化进行资源超买，提升资源使用率。

而在虚拟机的优势方面，例如安全性，京东采用了内部资源共享平台，通过流程管理或内部其它设施来弥补。这样一来，原本的完全资源隔离优势，反而成为了内部系统资源最大化利用的劣势。

因此，京东选择了当时相对不太成熟的容器化部署方式，并进行了服务器上 Elasticsearcht 资源隔离：

Image4 Docker 部署图

 1. 内存完全隔离

• 数据 / 主数节点：默认按 jvm50%，预留一半给 Lucene 做 cache 使用。

• 网关 / 主节点：内存容量 -2 做为 jvm 内存，预留 2G 给监控及其它服务。

 2. CPU 隔离

• 重要业务直接绑定 CPU，完全避免资源抢占。

• 一般业务通过调整 cpu-sharElasticsearch、cpu-period、cpu-quota 进行 CPU 比例分配。

 3. IO 隔离

• 由于生产环境机器的多样性，磁盘 IO 本身差别很大，另外对 IO 的限制会造成 Elasticsearch 读写性能严重下降，出于只针对内部业务的考虑，京东并未对 IO 进行隔离。

• 通过简单的容器隔离，CPU 抢占现象明显改善。内存完全隔离之后，生产环境中节点之间相互影响很少发生 (IO 差的机器会有 IO 争用)，部署方式改造产生了应用的收益。

无状态实例阶段

随着业务的不断增长，集群数量及消耗的服务器资源成比例上升，京东 Elasticsearch 实例上升为上万个，维护的集群快速增长为上千个，集群规模从几个到几十个不等。

但是整体资源的利用率却相对较低，磁盘使用率仅为 28% 左右，日常平均读写 IO 在 10~20M/ 秒（日志分区 IO 在 60-100M / 秒）。造成资源浪费的原因是集群规模普遍较小，为保证突发情况下，读写请求对 IO 的要求，我们一般会为集群分配较为富余的资源，物理机分配的容器也会控制在一定量级。

我们做个假设，如果大量的服务器 IO 都可以共享，那么某个集群突发请求对 IO 的影响其实可以忽略的。基于这种假设以及对提高磁盘使用率的迫切需要，我们考虑引入了公司内部部署的 ChubaoFS 作为存储，将 Elasticsearch 作为无状态的实例进行存储计算分离。

得益于 ChubaoFS 是为大规模容器集群挂载而设计的通用文件系统，我们几乎是零成本接入的，只需在物理机上安装相应的客户端，就可以将 ChubaoFS 当成本地文件系统来用。集成之后我们对 ChubaoFS 的性能进行了一系列对比。

我们使用 elasticsearch benchmark 测试工具 Elasticsearchrally 分别对 Elasticsearch 使用本地磁盘和 ChubaoFS 进行 benchmark 测试，测试使用了 7 个 elasticsearch 节点，50 个 shard。

Elasticsearchrally 测试参数如下：

Elasticsearchrally --pipeline=benchmark-only \--track=pmc \
--track-
params="number_of_replicas:${REPLICA_COUNT},number_of_shards:${SHARD_COUNT}" \--target-hosts=${TAR GET_HOSTS} \--report-file=${report_file}

其中 REPLICA_COUNT 0、1、2 分别 代表不同的副本数；SHARD_COUNT 为 50。

从测试结果可以看出，Elasticsearch 集成 ChubaoFS 之后，在不同副本数情况下， index benchmark 性能和本地磁盘差距在 110%~120% 左右，仅有略微的下降；merge benchmark 性能在 replica > 0 时，Elasticsearch 使用 ChubaoFS 优于本地磁盘。refrElasticsearchh 和 flush benchmark 性能 ChubaoFS 不及本地磁盘。

3目前使用效果

集成 ChubaoFS 之后，我们先是灰度运行了一段时间，效果表现良好之后，我们将京东日志所有的 Elasticsearch 集群底层全部切换为 ChubaoFS。切换之后，我们在这些方面获得了更好的效果：

1. 节约资源

在采用 ChubaoFS 之前，我们使用了 500 台物理机器，并且每个机器平时大概有 80% 的磁盘 IO 能力处于闲置状态。采用 ChubaoFS 之后，ChubaoFS 的集群规模约为 50 台，Elasticsearch 托管到公司的容器平台，实现弹性可扩展。

2.  管理和运维更加简单便捷

采用 ChubaoFS 之后，我们不用再担心某个机器的硬盘故障，或者某个机器的读写负载不均衡的问题。

3. GC 频率明显降低

由于 ChubaoFS 底层对文件作了副本支持，业务层 Elasticsearch 将副本置为 0，原先 segment 挤占堆内存导致 FullGC 现象明显，接入 ChubaoFS 后，GC 频率明显降低。

4参考资料

ChubaoFS 京东开源云原生应用分布式文件系统

https://github.com/chubaofs/chubaofs

ChubaoFS 网站：

https://www.chubao.io/

ChubaoFS 设计相关论文，收录在 ACM SIGMOD 2019

CFS: A Distributed File System for Large Scale Container Platforms.

https://dl.acm.org/citation.cfm?doid=3299869.3314046  

文档

https://chubaofs.readthedocs.io/zh_CN/latElasticsearcht/

https://chubaofs.readthedocs.io/en/latElasticsearcht/

ChubaoFS 社区交流：

Twitter：@ChubaoFS

Mailing list: [email protected]

Slack: chubaofs.slack.com

5作者简介

王行行，京东零售计算存储平台架构部架构师，杰思平台 (京东 Elasticsearch) 团队负责人，2015 年加入京东，目前主要负责京东商城智能监控平台底层、杰思平台等基础设施建设。

张丽颖，CNCF Ambassador，京东零售计算存储平台产品经理， 开源项目 ChubaoFS 的 contributor。