Categories
程式開發

Elasticsearch 實例管理在京東的使用場景及演進之路


Elasticsearch 是一個開源的分佈式 RElasticsearchTful 搜索引擎,作為一個分佈式、可擴展、實時的搜索與數據分析引擎,它可以快速存儲、搜索和分析大量數據。同時,Elasticsearch 也支持具有負責搜索功能和要求的應用程序的基礎引擎, 因此可以應用在很多不同的場景中。

Elasticsearch 在京東的使用場景

由於較高的性能和較低的使用門檻,京東內部有很多的場景都在使用 Elasticsearch。

2015 年 6 月,京東著手開發了 Elasticsearch 的託管平台——傑思 (JElasticsearch)。傑思平台主要負責 Elasticsearch 集群的部署、運行監控、數據遷移、權限管理、插件開發、集群升級等日常維護工作。

目前傑思平台管理的集群覆蓋了京東多條業務線,同時也覆蓋了很多應用場景:

補充關係型數據庫的結構化數據查詢

主要應用的業務是商品、促銷、優惠券、訂單、收銀台、物流、對賬、評論等大數據量查詢。此場景的核心訴求是高性能、穩定性和高可用性,部分場景會有檢索要求,通常用於加速關係型數據庫,業務系統通過 binlog 同步或業務雙寫完成數據同步。

全文檢索功能

主要的應用場景是應用、安全、風控、交易等操作日誌,以及京東部分品類商品搜索。此類日誌化場景對寫要求很高,查詢性能及高可用等要求相對較低,大的業務寫會達到數千萬 / 秒,存儲以 PB 為單位來計算。

這些場景對磁盤、內存有比較高的要求,因此,京東也做了相應優化,用於減少內存消耗,提升磁盤整體使用率,使用更廉價的磁盤來降低成本等等。

實時數據分析引擎,形成統計報表

主要應用的業務是物流單的各種分析、訂單數據分析、用戶畫像等。因為業務數據分析緯度較多,flink、storm 等流式分析對於某些報表場景不太適用,批處理實時性又成為問題,所以近實時分析的 Elasticsearch 就成為了這些業務的選擇。

Elasticsearch 實例管理在京東的使用場景及演進之路 1

Image1:Elasticsearch +ChubaoFS 支持京東商城應用場景

在應用Elasticsearch 的5 年時間中,京東從最初的幾個場景應用變成了覆蓋各條業務線,從最初的幾台機器變成了現在的上千機器和幾千集群的量級,運維壓力也隨之而來了。

目前,京東在日常運維 ELasticsearch 集群時,主要面臨以下幾個問題:

  • IO 讀寫不均​​勻,部分節點 IO 壓力非常大;

  • 冷數據節點存儲量受限制於單機的最大存儲;

  • close 後的索引節點故障無法進行 recovery,導致數據丟失的風險。

為了解決這些問題,京東應用了 ChubaoFS。 ChubaoFS 是京東自研的、為雲原生應用提供高性能、高可用、可擴展、 穩定性的分佈式文件系統,設計初衷是為了京東容器集群提供持久化存儲方案,同時也可作為通用雲存儲供業務方使用,幫助有狀態應用實現計算與存儲分離。

ChubaoFS 支持多種讀寫模型,支持多租戶,兼容 POSIX 語義和 S3 協議。 ChubaoFS 設計的每個pod 可以共享一個存儲卷,或者每個pod 一個存儲卷,當容器所在的物理機宕機後,容器的數據可以隨著容器被同時調度到其他宿主機上, 保障數據可靠存儲。

Elasticsearch 實例管理在京東的使用場景及演進之路 2

Image2: Elasticsearch+ChubaoFS=Decouping Compute from Storage

Elasticsearch 實例管理演進之路

京東的 Elasticsearch 實例管理也是一個不斷摸索、不斷爬坑的過程。

初始階段

最初,京東Elasticsearch 集群部署是完全沒有架構可言的,集群配置也都採用默認配置,一台物理機啟動多個Elasticsearch 進程,進程間完全共享服務器資源,不同業務之間使用集群進行隔離,這種形式使用服務器CPU 和內存得到了充分利用。

Elasticsearch 實例管理在京東的使用場景及演進之路 3

Image3:物理機部署

當系統運行了一段時間之後,這種部署方式的弊端開始顯現出了。

  • 實例容易受到其他節點的影響,重要業務抖動問題沒有有效方式避免。

  • 物理機內存被 cache 佔用,新創建實例啟動時耗時特別長。

  • 實例存儲受單機磁盤容量限制,數據遷移時有發生。

容器隔離階段

由於物理機直接部署 Elasticsearch,無法管理 CPU、內存,各個節點相互影響明顯,甚至會影響到穩定性。所以,針對上述情況,京東做出了改善方案——調研資源隔離方式。

當時比較主流的資源隔離方式有兩種,Docker 容器化和虛擬機。

2016 年時 Docker 容器化技術已成型,但虛擬技術比較成熟有大量工具、生態系統完善。相對於虛擬機的資源隔離,Docker 不需要實現硬件虛擬化,只是利用cgroup 對資源進行限制,實際使用的仍然是物理機的資源,所以在資源使用率方面效率更高,我們經過測試使用Docker 化後性能損失相對較小幾乎可以忽略。

Docker 是資源限制,啟動時不需要加載操作系統內核,可以毫秒級啟動。啟動對資源的消耗要低很多,可以做到快速的啟停。另外由於是資源限制類,只限制最大使用量而不隔離最小,這樣又可以做到虛擬化進行資源超買,提升資源使用率。

而在虛擬機的優勢方面,例如安全性,京東採用了內部資源共享平台,通過流程管理或內部其它設施來彌補。這樣一來,原本的完全資源隔離優勢,反而成為了內部系統資源最大化利用的劣勢。

因此,京東選擇了當時相對不太成熟的容器化部署方式,並進行了服務器上 Elasticsearcht 資源隔離:

Elasticsearch 實例管理在京東的使用場景及演進之路 4

Image4 Docker 部署圖

  1. 內存完全隔離
  • 數據 / 主數節點:默認按 jvm50%,預留一半給 Lucene 做 cache 使用。

  • 網關 / 主節點:內存容量 -2 做為 jvm 內存,預留 2G 給監控及其它服務。

  1. CPU 隔離
  • 重要業務直接綁定 CPU,完全避免資源搶占。

  • 一般業務通過調整 cpu-sharElasticsearch、cpu-period、cpu-quota 進行 CPU 比例分配。

  1. 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 不及本地磁盤。

Elasticsearch 實例管理在京東的使用場景及演進之路 5

Elasticsearch 實例管理在京東的使用場景及演進之路 6

Elasticsearch 實例管理在京東的使用場景及演進之路 7

Elasticsearch 實例管理在京東的使用場景及演進之路 8

目前使用效果

集成 ChubaoFS 之後,我們先是灰度運行了一段時間,效果表現良好之後,我們將京東日誌所有的 Elasticsearch 集群底層全部切換為 ChubaoFS。切換之後,我們在這些方面獲得了更好的效果:

  1. 節約資源

在採用 ChubaoFS 之前,我們使用了 500 台物理機器,並且每個機器平時大概有 80% 的磁盤 IO 能力處於閒置狀態。採用 ChubaoFS 之後,ChubaoFS 的集群規模約為 50 台,Elasticsearch 託管到公司的容器平台,實現彈性可擴展。

  1. 管理和運維更加簡單便捷

採用 ChubaoFS 之後,我們不用再擔心某個機器的硬盤故障,或者某個機器的讀寫負載不均衡的問題。

  1. GC 頻率明顯降低

由於 ChubaoFS 底層對文件作了副本支持,業務層 Elasticsearch 將副本置為 0,原先 segment 擠占堆內存導致 FullGC 現像明顯,接入 ChubaoFS 後,GC 頻率明顯降低。

參考資料

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

作者簡介

王行行,京東零售計算存儲平台架構部架構師,傑思平台 (京東 Elasticsearch) 團隊負責人,2015 年加入京東,目前主要負責京東商城智能監控平台底層、傑思平台等基礎設施建設。

張麗穎,CNCF Ambassador,京東零售計算存儲平台產品經理, 開源項目 ChubaoFS 的 contributor。