本文由阿里雲社群直播整理而來。
講師：
洪陽，阿里雲產品專家
和阿里雲技術專家，志宸
全鏈路雲上Elasticsearch——阿里雲Elasticsearch一站式雲託管服務
到今天為止我們在雲上已經有Elasticsearch、Kibana、Logstash和Beats, 生態下的全部開源的組件。同時，相較於開源的ELK生態下的組件和功能來說，還提供了其他的自研插件，或者是增強型的，或者是基於內核的優化能力，來保證大家在使用ElasticStack這個生態內的功能時有更好的體驗，更強的穩定性和更高的性能，更讓大家覺得滿意的性價比。
其中包括向量檢索日誌增強版的內核，阿里達摩院提供的中文分詞器，跟Elastic的官方所簽約戰略合作所得到這個X-pack的商業插件，基於雲端的容災能力，幫助提升es集群運維效率的智能運維功能，可視化的運維窗口，以及Kibana的一些插件，比如說Query builder的插件或者打標的插件。
今天這個話題主要是聊一聊我們日誌場景下的這個增強版內核的一些功能和特性。
01.日誌場景的“痛心處” ——日誌場景中用ELK哪些問題要人命？
日誌場景是大家在使用ELK過程中，比較多的一個場景，讓我們來看一下它有哪些痛點問題。
天下烏鴉一般黑 ——大家的痛點都是趨同的
這裡羅列了大家常會遇到的幾個問題：
第一個是高併發的寫入，在日誌場景中通常會有非常大的寫入，而Elasticsearch在寫入過程中，需要寫入主分片又會同步到備份片，並且在這個過程中還會去寫這個trace log之類的，開銷比較大，通常它在支持這個高併發寫入的時候，對於機器CPU和l/O的開銷是比較高的；
第二個是存儲成本比較高，日誌場景中通常會涉及到海量數據庫，通常我們遇到的都是TB級起步，甚至有些會到達PB級。同時在這麼大數據量的前提下，除了寫入主分片之外，還需要保留一份副本，那麼這個時候它的存儲成本壓力就更加大了。
第三個是這個時序分析性能差的問題，因為es的查詢是按所有的segment都會去查，做比較大範圍的range時，和比較複雜的聚合時，它的查詢範圍太大，性能瓶頸就會突顯出來。
第四個是時常會遇到可伸縮性的問題，因為日誌通常隨著業務的變化會有峰值、均值、谷值，它們之間的差異是非常大的。通常我們需要為了支持這個峰值流量，把機器堆的非常多，但是低峰值的時候，就會造成很嚴重的資源浪費，所以，解決可伸縮性的問題也是日常比較大的課題。
流量“峰值”vs流量“低谷” ——要麼資源不夠，要麼資源浪費 我要如何優化集群配置
下面我們來看一個伸縮性案例。我們有一個用戶，早高峰兩小時的查詢和寫入是其他時間段的5倍，造成了大部分的時間資源浪費的情況，並且該用戶的數據量非常大，所以在正常的情況下去做彈性擴縮容會存在數據遷移慢的問題，就沒有辦法去有效的實施，並且包含了副本，存儲成本和高併發的寫入都會存在問題。
為了解決用戶場景上述提到的這些痛點問題，我們做了es內核的增強版，專門針對日常場景進行成本和穩定性的這個優化。
02.日誌“大殺器”技術解讀 ——增強版Es技術解讀
通過計算速度分離來解決用戶的這個痛點問題，分離的前提是所有結點的存儲都基於NFS的共享存儲。
計算存儲分離架構 ——核心技術剖析
我們可以看到，數據流的寫入請求，會先寫到主分片，寫入到共享存儲，然後nrt segment會拷貝到臨時目錄，那麼主和備去讀的就不同了。主讀的是commit segment a和nrt segment b，副本讀的就是a和b’。計算存儲分離的核心思想其實就是下圖右邊列的這五個點：
第一點是最重要的，索引分片一寫多讀。數據只會保留一份，存儲成本和寫入成本會更加低，寫入性能就會大大的提高。
第二點是依賴雲存儲保證數據的可靠性。CPI的底層具備了三副本的冗餘機制，對於業務是透明的，所以能夠保證數據不丟，並且阿里雲針對極端情況下，也會有分鐘級的OSS自動備份機制，能提供數據的備份，進一步保證數據的可靠性。
第三點是狀態與索引分離。
第四點是通過IO fence機制來保證數據一致性。
第五點是內存物理複製降低主備的可見延遲，主備可見延遲叢分鐘級降到毫秒級。
日誌場景的“棘手”問題 ——用戶痛點分析
基於上述的架構大家可能會產生的一些疑問，副本在不寫實時索引的情況下怎麼保證數據的時效性呢？其實我們為了解決這個問題，設計了物理複製的狀態機，利用lucene框架實現了主副之間的數據同步。主shard在refresh期間會生成全量meta快照。第二點是segment merge完成後，大的merge後的segment不會去做這segment同步，會直接把它fsync到共享存儲來避免一個大文件的拷貝。第三個是主備延遲可效性在通過一系列的優化之後達到了毫秒級。
03.能力堪比“大宗師”——日誌增強版vs純開源版本
想必大家剛才聽完上述介紹之後，對於阿里雲增強日誌場景下增強版的elastic search內核有了一定的瞭解。為了方便進一步的瞭解，日誌場景增強版的內核和純開源的版本去做一個對比。為了方便大家理解，我們用真實的案例基於售價和一些性能指標來給大家一個相對來說直觀點的概念。
同樣性能比價格 ——來源於真實的POC數據
下面說的這兩個場景案例其實都是來源於真實的POC的相關數據，第一個是我們同樣的性能要求，或者說同樣的一個性能表現，來橫向對比一下價格。這個數據是來源於真實的我們的客戶數據，要求是希望Elasticsearch集群的吞吐，寫入存儲是500M Bps，寫入量是450000 docs/s。基於這樣要求，分別用純開源的Elastic search版本和阿里雲日場景增強版的Elastic search做了一個配置規劃。用純開源，其實是用25臺16c 64GB的高配機器，增強版用12臺就夠了。同樣配置50TB存儲介質，配置不同的協調節點，純開源是五臺，增強版是三臺，專有節點機器數比較少，所以專有節點的數量和配置也不用那麼高。所以相對來說純開源版本基於阿里雲Elastic search，大概價格是15萬一個月，阿里雲日誌場景的增強版es的原價是11萬一個月，最近會有一個年末的折扣活動，折扣活動之後大概就是69000多一個月，相對於用原價作比較我們節約的費用其實是非常可觀的。
同樣需求比ROI ——來源於真實的POC數據
另外一個也是一個客戶的真實場景，類似的需求，我們來對比一下ROI。客戶這固定預算是受限的不超過5萬，他希望能夠做數據容災，數據量大，我們幫他規劃了這個基於開源的Elasticsearch集群配置跟阿里雲日誌場景下的增強版的集群配置。大家可以看到左和右的不同，性能方面經過實測，基於純開源版本的配置，費用已經到49000，跟增強版的配置相比其費用折扣後只需要28000，性能是要優越於純開源版本的，併發寫入場景下等。性能更優越，成本更便宜。
過人之處有哪些 ——內修心法，外練強力
總結來說，阿里雲基於日誌場景，對於Elasticsearch做了優化之後，有哪些過人之處呢？主要就是三點：
第一點就是我們存儲的成本節約百分之百，大家回顧去想一想，上文提到的，多個replica映射主shard跟主shard映射同一份物理存儲介質，所以一旦有replica之後並且replica越多，節約的成本會越高，如果replica是1相當於砍了一半，replica是2成本節約了2/3，所以我們存儲的成本是大大降低的，並且支持更大的內存磁盤比。因為對內存的限制，所以其實內存磁盤比是相對來說比較固化，如果你的磁盤比內存高太多，比如說64GB的內存配一個幾十TB的磁盤，這個磁盤是用不掉的，在正常的這個開源的es內核裡，增強版會有更多的內存磁盤比。
第二點，是寫入性能會有大大提升，實際壓測使用性能相對於開源提升至少100%，在計算上避免了物理寫副本的多次CPU或者是IO的開銷來節約了資源，來提升了寫入的性能。
第三點，所有的邏輯存儲與物理存儲不是一一映射的，在做擴縮容的時候，不需要實際意義上去搬遷每一個數據節點裡面的數據，可以做到秒級的彈性擴縮容。這個在真實場景下面是對大家很有幫助的，舉一個簡單的例子，業務上面有一些波峰波谷很明顯的業務場景，遊戲、直播、類似於餐飲等的固定週期，晚上是高峰，寒暑假是高峰，或者是飯點的時候是高峰，大量的日誌寫入會給集群非常大的壓力，平時日誌寫入量不大，集群壓力沒有多少，空閒了很多。正常來說呢，大家可能會滿足峰值的壓力會預留些機器，在平時時間段其實資源是浪費的，阿里雲日誌增強版就非常好去解決了這個問題。到了峰值的時候快速把機身彈起來，然後峰值過了把資源釋放，回到我均值情況下和集群配置的份額和水位，很大一部分錢都是可以被節約下來的，這個是從成本的角度去考慮，幫助大家節省了非常多的費用上的消耗，開源版Elasticsearch完不成的事情，阿里雲日誌增強版可以去做。
接下來介紹一下最佳的用武之地，最佳場景，什麼時候這個日場景的增強版內核可以被用到呢，或者說大家這個時候就選它，會有比較好的ROI，就是投入產出比。
04.最佳用武之地 ——日誌增強版應用場景
首先第一個就是有非常多日誌的時候，基於之前的介紹日誌量大，併發寫入的性能會高，日誌量很大，用副本的時候存儲會更便宜等，這些都基於一個原則，就是我不願意為這麼大的日誌量支付非常高額的存儲成本，以及支撐併發寫入時資源上的消耗成本，所以海量日誌的時候大家可以去選擇它，TB級10TB 100TB甚至更多；
第二個是增量日誌的併發寫入性能要求很高的時候，比如說峰值寫入100000dos時，如果大家現在正在用開源的ELK去搭建自己的監控運維或者是日誌系統的時候，都會有這樣的痛點，一旦併發量上去，集群的負載均衡是很麻煩的，很容易被打爆，很容易集群就飄紅了，這個是很危險的；
第三個是對於數據有一定容災要求的時候，副本數，至少是一點的時候，如果沒有這個副本的時候，我只是存了一份數據，那這個時候其實存儲成本開銷可能還是比普通的ssd還是貴點，但一旦有副本，那就是100%存儲費用的降低。
什麼時候應該用？ ——阿里雲專家推薦
介紹完這個比較寬泛的概念之再用一個真實的案例給大家去介紹。大家都知道阿里雲其有很多條業務線，舉一個阿里雲內部有搜索業務線的真實案例。搜索會有很多集團內的客戶，集團外的客戶，甚至有搜索之外的產品，或者說認為他是客戶，就是業務線，他們會去使用各種各樣的底層服務，那我們會對他們做一系列的監控，就是各種各樣的底層服務會有各種各樣的複雜的Metric，做大量的聚合，做dashboard，保證這些業務不受影響。做monitor，相伴而生的就一定會有告警了，這樣的一套監控和報警的平臺，內部網監控和告警的平臺底層所使用的就是量身定製的日誌場景下的增強版的es內核。
下圖是其中一個集群的解讀，Metric Beats採集大量的數據，通過Gateway向Elasticsearch集群去發送，大概寫入量是40w docs/s，一些數據是熱數據，一些數據是冷數據，不能把所有的數據全都放到同樣的配置，出於成本的角度考慮，做冷熱切分的配置，為了數據容災將數據定時自動快照到OSS裡面，這套服務在阿里雲內部已經正在使用，對外提供一模一樣的能力供大家去選擇。大概盤算一下，用開源的Elasticsearch做同樣的事情，它的費用是一倍之多，費用至少是節約了50%，不僅是存儲更便宜，持續Metric場景為了聚合的效率更高阿里雲的內核也做了優化。基於開源的，為了達到性能，要去做更多的data log冗餘，保證內存跟CPU的性能是足夠的。
最佳實踐案例 ——真實客戶案例
05.年末大促 ——日誌增強版的新用戶折扣
最後給大家介紹增強版對於我們新客戶是有折扣的，從2020年的1月1日開始到3月31日結束，首月年付六折，三個月有75的折扣，今年的1月上旬推出，Metric Beats等一系列服務，在經過授權的前提下把這些Beats一鍵裝載到您的ecs裡面，採集一些esc裡面的metric，與Logstash配合使用的話，Logstash2核4G首月是免費試用的，我們一直會有這個1核2G首月免費的試用活動，感興趣的朋友們可以去體驗一下阿里雲Elasticsearch，到底有什麼過人之處。