本文整理自阿里巴巴高級技術專家郭健美(花名:希伯)在Java相關行業會議的分享,主要介紹阿里大規模數據中心性能監控與分析的挑戰與實踐,希望對你有所啟發。
大家好,很高興有機會與 Java 社區的開發者交流。我的研究領域在軟體工程,主要集中在系統配置和性能方面。軟體工程一個比較常見的活動是找 bug,當然找 bug 很重要,但後來也發現,即便 bug-free 的程序也會被人配置錯,所以就衍生出了軟體配置問題。
很多軟體需要配置化,比如 Java 程序或 JVM 啟動時可以配置很多參數。通過配置,一套軟體可以靈活地提供各種定製化的功能,同時,這些配置也會對軟體整體性能產生不同的影響。當然這些還在軟體配置方面,來了阿里以後,我有機會把這方面工作擴展到了硬體,會更多地結合硬體比如 CPU,來看系統的配置變更和升級改造對性能、可靠性以及業務上線效果的影響。今天主要談談我在這方面的一點工作。
當然這是從業務層面去看數據,技術同學會比較關注右邊的數據,17年雙十一的交易峯值達到 32.5 萬筆/秒、支付峯值達到 25.6 萬筆/秒。對於企業來說,這麼高的峯值性能意味著什麼?意味著成本!我們之所以關注性能,就是希望通過持續的技術創新,不斷地提高性能、同時節省成本。
底層是上百萬臺機器相連的大規模數據中心,這些機器的硬體架構不同、分佈地點也不同,甚至分佈在世界各地。中間這部分我們稱之為中臺,最貼近上層應用的是資料庫、存儲、中間件以及計算平臺,然後是資源調度、集羣管理和容器,再下面是系統軟體,包括操作系統、JVM 和虛擬化等。
中臺這部分的產品是銜接社區與企業的紐帶。這兩年阿里開源了很多產品,比如 Dubbo、PouchContainer 等,可以看出阿里非常重視開源社區,也非常重視跟開發者對話。現在很多人都在講開源社區和生態,外面也有各種各樣的論壇,但是像今天這樣與開發者直接對話的活動並不是那麼多,而推動社區發展最終還是要依賴開發者。
這樣大規模的基礎架構服務於整個阿里經濟體。從業務層面,我們可以看到 253 億美金的銷售額、32.5 萬筆交易/秒這樣的指標。然而,這些業務指標如何分解下來、落到基礎架構的各個部分就非常複雜了。比如,我們在做 Java 中間件或 JVM 開發時,都會做性能評估。
大部分技術團隊開發產品後都會有個性能提升指標,比如降低了 20% 的 CPU 利用率,然而這些單個產品的性能提升放到整個交易鏈路、整個數據中心裏面,佔比多少?對數據中心整體性能提升貢獻多少?這個問題很複雜,涉及面很廣,包括複雜關聯的軟體架構和各種異構的硬體。後面會提到我們在這方面的一些思考和工作。
大家也知道,18年阿里入選並連任了 JCP EC(Java Community Process - Executive Committee) 職位,有效期兩年,這對整個 Java 開發者社區、尤其是國內的 Java 生態都是一件大事。但是,不是每個人都瞭解這件事的影響。記得之前碰到一位同仁,提到 JCP EC 對阿里這種大業務量的公司是有幫助,對小公司就沒意義了。
其實不是這樣的,參選 JCP EC 的時候,大公司、小公司以及一些社區開發者都有投票資格,小公司或開發者有一票,大公司也只有一票,地位是一樣的。很多國外的小公司更願意參與到社區活動,為什麼?
舉個簡單例子,由於業務需要,你在 JVM 8 上做了一個特性,費了很大的力氣開發調試完成、業務上線成功,結果社區推薦升級到 JVM11 上,這時你可能又需要把該特性在 JVM 11 上重新開發調試一遍,可能還要多踩一些新的坑,這顯然增加了開發代價、拉長了上線週期。但如果你能影響社區標準的制定呢?你可以提出將該特性融入社區下一個發布版本,有機會使得你的開發工作成為社區標準,也可以藉助社區力量完善該特性,這樣既提高了技術影響力也減少了開發成本,還是很有意義的。
這些基準測試有必要性,因為我們需要一個簡單、可復現的方式來衡量性能。但基準測試也有侷限性,因為每一次基準測試都有其限定的運行環境和軟硬體配置,這些配置設定對性能的影響可能很大,同時這些軟硬體配置是否符合企業需求、是否具有代表性,都是需要考慮的問題。
阿里的數據中心裡有上萬種不同的業務應用,也有上百萬臺分佈在世界各地的不同伺服器。當我們考慮在數據中心裡升級改造軟體或硬體時,一個關鍵問題是小規模基準測試的效果是否能擴展到數據中心裡複雜的線上生產環境?
舉個例子,我們開發了 JVM 的一個新特性,在 SPECjbb2015 的基準測試中看到了不錯的性能收益,但到線上生產環境灰度測試的時候,發現該特性可以提升一個 Java 應用的性能、但會降低另一個 Java 應用的性能。同時,我們也可能發現即便對同一個 Java 應用,在不同硬體上得到的性能結果大不相同。這些情況普遍存在,但我們不可能針對每個應用、每種硬體都跑一遍測試,因而需要一個系統化方法來估計該特性對各種應用和硬體的整體性能影響。
對數據中心來說,評估每個軟體或硬體升級的整體性能影響非常重要。比如,「雙11」的銷售額和交易峯值,業務層面可能主要關心這兩個指標,那麼這兩個指標翻一倍的時候我們需要買多少臺新機器?需要多買一倍的機器麼?這是衡量技術能力提升的一個手段,也是體現「新技術」對「新商業」影響的一個途徑。我們提出了很多技術創新手段,也發現了很多性能提升的機會,但需要從業務上也能看出來。
然後,我們會針對軟體或硬體的升級改造做線上評估,即 Evaluation。比如,硬體廠商推出了一個新硬體,他們自己肯定會做一堆評測,得到一組比較好的性能數據,但剛才也提到了,這些評測和數據都是在特定場景下跑出來的,這些場景是否適合用戶的特定需求?
沒有直接的答案。通常,用戶也不會讓硬體廠商到其業務環境裏去跑評測。這時候就需要用戶自己拿這個新硬體做灰度測試。當然灰度規模越大評測越準確,但線上環境都直接關聯業務,為了降低風險,實際中通常都是從幾十臺甚至幾臺、到上百臺、上千臺的逐步灰度。SPEED 平臺要解決的一個問題就是即便在灰度規模很小時也能做一個較好的估計,這會節約非常多的成本。
隨著灰度規模增大,平臺會不斷提高性能分析質量,進而輔助用戶決策,即 Decision。這裡的決策不光是判斷要不要升級新硬體或新版軟體,而且需要對軟硬體全棧的性能有一個很好的理解,明白什麼樣的軟硬體架構更適合目標應用場景,這樣可以考慮軟硬體優化定製的方向。
比如,Intel 的 CPU 從 Broadwell 到 Skylake,其架構改動很大,但這個改動的直接效果是什麼?Intel 只能從基準測試中給答案,但用戶可能根據自己的應用場景給出自己的答案,從而提出定製化需求,這對成本有很大影響。
最後是 Validation,就是通常規模化上線後的效果來驗證上述方法是否合理,同時改進方法和平臺。
在 SPEED 平臺裏,我們也提出了一個全局性能指標,叫資源使用效率 RUE。基本思想很簡單,就是衡量每個單位 Work Done 所消耗的資源。這裡的 Work Done 可以是電商裏完成的一個 Query,也可以是大數據處理裏的一個 Task。而資源主要涵蓋四大類:CPU、內存、存儲和網路。通常我們會主要關注 CPU 或內存,因為目前這兩部分消費了伺服器大部分的成本。
RUE 的思路提供了一個多角度全面衡量性能的方法。舉個例子,業務方反映某臺機器上應用的 response time 升高了,這時登錄到機器上也看到 load 和 CPU 利用率都升高了。這時候你可能開始緊張了,擔心出了一個故障,而且很可能是由於剛剛上線的一個新特性造成的。
然而,這時候應該去看下 QPS 指標,如果 QPS 也升高了,那麼也許是合理的,因為使用更多資源完成了更多的工作,而且這個資源使用效率的提升可能就是由新特性帶來的。所以,性能需要多角度全面地衡量,否則可能會造成不合理的評價,錯失真正的性能優化機會。
這樣,理想情況下 CPU 利用率達到 100% 就可以充分利用資源了,是否可以這樣簡單地理解 CPU 利用率和數據中心的性能呢?肯定不行。就像剛才說的,數據中心除了 CPU,還有內存、存儲和網路資源,機器數量減半可能很多應用都跑不起來了。
再舉個例子,某個技術團隊升級了其負責的軟體版本以後,通過線上測試看到平均 CPU 利用率下降了 10%,因而聲明性能提升了 10%。這個聲明沒有錯,但我們更關心性能提升以後是否能節省成本,比如性能提升了 10%,是否可以把該應用涉及的 10% 的機器關掉?這時候性能就不應該只看 CPU 利用率,而應該再看看對吞吐量的影響。
所以,系統性能和各種性能指標,可能大家都熟悉也都在用,但還需要更全面地去理解。
來看最上面一張圖,這裡有兩個物理核,沒有打開超線程,兩邊 CPU 資源都用滿了,所以從任務管理器報出的整臺機器平均 CPU 利用率是 100%。左下角的圖也是兩個物理核,打開了超線程,每個物理核上有一個 hardware thread 被用滿了,整臺機器平均 CPU 利用率是 50%。
再看右下角的圖,也是兩個物理核,也打開了超線程,有一個物理核的兩個hardware threads 都被用滿了,整臺機器平均 CPU 利用率也是 50%。左下角和右下角的 CPU 使用情況完全不同,但是如果我們只是採集整機平均 CPU 利用率,看到的數據是一樣的!
所以,做性能數據分析時,不要只是想著數據處理和計算,還應該注意這些數據是怎麼採集的,否則可能會得到一些誤導性的結果。
數據中心裡的硬體異構性是性能分析的一大挑戰,也是性能優化的一個方向。比如這裡左邊的 Broadwell 架構,是 Intel 過去幾年伺服器 CPU 的主流架構,近幾年在推右邊的 Skylake 架構,包含最新的 Cascade Lake CPU。Intel 在這兩個架構上做了很大的改動,比如,Broadwell 下訪問內存還是保持多年的環狀方式,而到了 Skylake 改為網格狀方式。
再比如,L2 Cache 到了Skylake 上擴大了四倍,通常來說這可以提高 L2 Cache 的命中率,但是 cache 越大也不代表性能就一定好,因為維護 cache coherence 會帶來額外的開銷。這些改動有利有弊,但我們需要衡量利和弊對整體性能的影響,同時結合成本來考慮是否需要將數據中心的伺服器都升級到 Skylake。
瞭解硬體的差異還是很有必要的,因為這些差異可能影響所有在其上運行的應用,並且成為硬體優化定製的方向。
從軟體架構角度看,大促主會場和購物車兩個應用就形成了優惠券應用的兩個入口,入口不同對於優惠券應用本身的調用路徑不同,性能影響也就不同。
所以,在分析優惠券應用的整體性能時需要考慮其在電商業務裏的各種錯綜複雜的架構關聯和調用路徑。像這種複雜多樣的業務場景和調用路徑是很難在基準測試中完全復現的,這也是為什麼我們需要做線上性能評估。
假設還用前面的例子,比如 App 就是優惠券應用,在大促的時候上線了一個新特性 S,灰度測試的機器佔比為 1%,那麼根據 RUE 指標,該特性可以提升性能 8%,挺不錯的結果。但是如果優惠券應用有三個不同的分組,分組假設就是關聯剛才提到的不同入口應用,那麼從每個分組看,該特性都降低了應用的性能。
同樣一組數據、同樣的性能評估指標,通過整體聚集分析得到的結果與通過各部分單獨分析得到的結果正好相反,這就是辛普森悖論。既然是悖論,說明有時候應該看總體評估結果,有時間應該看部分評估結果。在這個例子裡面,我們選擇看部分評估、也就是分組上的評估結果,所以看起來這個新特性造成了性能下降,應該繼續修改並優化性能。
所以,數據中心裡的性能分析還要預防各種可能的數據分析陷阱,否則可能會嚴重誤導決策。
其實,我覺得每個開發者都可以思考一下,我們不光要做功能開發,還要考慮所開發功能的性能影響,尤其是對數據中心的整體性能影響。比如,JVM 的 GC 開發,社區裏比較關心 GC 暫停時間,但這個指標與 Java 應用的 response time 以及所消耗的 CPU 資源是什麼關係,我們也可以有所考慮。
本文作者:郭健美
原文鏈接
更多技術乾貨敬請關注云棲社區知乎機構號:阿里云云棲社區 - 知乎
本文來自雲棲社區合作夥伴「 阿里技術」,如需轉載請聯繫原作者。