本文作者：清豆，阿里巴巴 Elasticsearch 高級開發工程師
簡介：
彈性伸縮幫助用戶根據定時/定量等策略，自動觸發資源auto scaling，最大程度保證業務服務質量，並儘可能的減少低峰期的資源使用成本及人力運維負擔。
行業痛點
自2017年商業化以來，阿里雲Elasticsearch已經快速發展了3個年頭，積累了大量的集群和業務。通過觀察線上幾千個集群的使用情況，我們發現大量的中高配集群存在資源浪費的現象。典型表現為一天24h中，僅有短短几個小時水位能夠達到50%以上，其它時段僅保持在20%左右甚至更低的水平；這樣就導致了大量的成本浪費。
而這個問題其實也很好理解。阿里雲 Elasticsearch 提供獨享性的 PaaS 實例，而大部分業務場景，類似直播、在線教育、物流等，本身就是有明顯的高低峰期的規律的。所以為穩妥起見，用戶在新購集群前，頭部的業務都是按照高峰期預估的峰值流量來評估整體的集群資源，以保證峰值情況下的服務質量；中長尾或內部業務則退而求其次，選擇使用單 Elasticsearch 集群做業務混部以節省成本。
如果有非預期的峰值流量到來，則需要人工手動在控制檯進行擴容。而往往此時業務已經受到了影響，止血的效率完全取決於運維人員的手速。如果再遇上 ECS 資源庫存不足，那真就是欲哭無淚。
對我們雲平臺來說，實現彈性伸縮能夠幫助用戶根據定時/定量等策略自動觸發資源的 Auto scaling，在最大程度保證業務服務質量的同時，儘可能的減少低峰期的資源使用成本，同時還減輕了人力運維的負擔。
為什麼是現在來做？
取決於以下四個原因
1、數據搬遷效率提升——TB級索引搬遷從“小時”級到“秒”級
在去年團隊推出了秒級彈性 Elasticsearch 計算存儲分離架構，從引擎的角度，根本性的解決了彈性擴縮面臨的最大問題：數據搬遷的效率問題。
原生ES引擎搬遷1TB索引耗時為小時級別，而云es計算存儲分離搬遷TB級索引只需5秒。這是因為計算存儲分離使得同一份數據能夠被多個 ECS 計算節點共享，所以 ES shard的搬遷只是一份元數據的改動，無需進行任何的索引網絡拷貝及磁盤io操作，從引擎的角度實現了秒級彈性的基礎能力。
2、Eyou智能運維繫統的成熟——分析用戶集群歷史流量規律，並作出規劃
Eyou 智能運維繫統不僅能夠幫助用戶計算高低峰期的資源需求，更能提前發現用戶業務指標的異常，在高峰期到來前提前把資源擴上去，交付更高質量的 Elasticsearch 服務。
3、對接了雲上 ElasticMonitor 服務——輸出高精度業務指標給管控平臺，對擴縮容中的異常針對性規避與優化
我們知道 Elasticsearch 原生自帶的 Metric 精度是比較粗的，這也是為什麼經常出現 Elasticsearch 服務抖動，卻查不到任何線索的原因。所以高精度的 Metric 讓我們更有底氣和實力去幫助用戶更好的做彈性這件事情。
4、更成熟的網絡方案——規避 ECS 庫存不足的問題
我們可以做到跨 AZ 去部署彈性服務，大大降低了庫存不足問題出現的概率，保證高峰期能夠買到充足的資源，而這一切對用戶都是透明的。
可以很直觀的看到，使用彈性伸縮後，大大節約了低峰期計算資源的消耗，在預留了buffer的前提下，總成本也很輕鬆的降低了近一倍。
從這個案例我們也能看出，彈性伸縮最適合的場景是高峰期時間短（8h以內），數據量不大（計算資源佔成本的大頭）的業務，對於成本的節省是最為友好的。
我們做了什麼事情？
獨立彈性角色組，保證易用性和靈活性
類似於資源組的概念，我們將彈性擴縮的能力對外暴露為實例內部的彈性角色組，與普通的數據節點角色並行存在。這個彈性組內的服務節點，我們會打上"elastic_type:data"標籤，以幫助用戶針對性的遷移彈性業務。用戶只需要配置"index.routing.allocation.require.elastic_type": "data"在索引setting上，即可將存量的索引遷移到彈性節點上來，最大程度的保證了易用性；相應的非彈性的業務，可以配置 "index.routing.allocation.exclude.elastic_type": "data"，來保證這部分業務不會遷移到彈性節點上來，實現業務的隔離，避免彈性節點變更對非彈性索引產生影響。
數據管理機制
針對搜索和數據庫加速場景，為提升服務的查詢吞吐，一般會選擇在計算資源橫向scaling的基礎上，同時增加索引的副本數；低峰期在縮掉計算資源的同時，相應也會把多餘的副本縮回去。所以這件事情我們也幫助用戶來完成，在配置彈性任務時，除了選擇高低峰期的計算節點需求，還可以選擇需要管理的業務索引，儘可能一站式的幫用戶把問題全部解決掉，減少用戶二次調整數據規模的負擔。
縮容安全保障機制
由於都是在線的集群，資源的縮容相對來說比較複雜。如何儘可能避免縮容導致的服務震盪是我們花了比較多精力來解決的事情，最終確定分別由資源和業務兩個維度的監控指標驅動，幫助我們做穩定的縮容保障。資源維度上，我們通過cpu、內存、磁盤資源的預估公式來計算目標節點能否放下全量的彈性索引，提前做好能否縮容成功的預判；業務維度上，通過隊列堆積、慢查詢比例等指標，智能探測到縮容過程中業務的服務震盪，有問題的話及時中止並回滾變更，保證兜底服務質量。
啟發式灰度變更機制
這部分話不多說，直接上圖
擴容過程
縮容過程：
未來展望
目前我們在公有云只開放了定時水平彈性的功能。後期我們會逐步向更加智能化的極致彈性方向演進，比如基於資源水位自動觸發彈性擴縮、基於歷史流量分析預測彈性需求、以及智能流控等功能都已經在規劃之中。
【阿里雲Elastic Stack】100%兼容開源ES，獨有9大能力，提供免費 X-pack服務（單節點價值$6000）
相關活動
更多折扣活動，請訪問阿里雲 Elasticsearch 官網
阿里雲 Elasticsearch 商業通用版，1核2G ,SSD 20G首月免費
阿里雲 Logstash 2核4G首月免費
