騰訊云最佳實踐 | 作業(yè)幫云原生成本優(yōu)化實踐

項目背景

作業(yè)幫教育科技（北京）有限公司成立于2015年，一直致力于用科技手段助力教育普惠，運用人工智能、大數(shù)據(jù)等前沿技術(shù)，為學生提供更高效的學習解決方案。隨著業(yè)務需求的發(fā)展，作業(yè)幫的IT系統(tǒng)面臨巨大挑戰(zhàn)，現(xiàn)有基礎平臺架構(gòu)已經(jīng)無法滿足快速增長的業(yè)務需求。業(yè)務對快速迭代、急速彈性、調(diào)用鏈追蹤、統(tǒng)一的監(jiān)控日志平臺、提升計算資源利用率等需求迫在眉睫。

2019年下半年，作業(yè)幫開始規(guī)劃并調(diào)研容器化解決方案。在此期間，騰訊云團隊和作業(yè)幫進行了多次深入的技術(shù)交流，同時作業(yè)幫也和騰訊云的其他容器客戶進行了充分交流溝通，多方面了解騰訊云原生技術(shù)和騰訊云的服務質(zhì)量，最終決定將其部分重要業(yè)務遷移到騰訊云容器服務TKE。

企業(yè)成本管控的常規(guī)做法是將各項計算、存儲、網(wǎng)絡資源歸口到具體業(yè)務單元，然后由系統(tǒng)運維、SRE、業(yè)務線研發(fā)以業(yè)務單元為視角綜合評估成本的合理性。常見的成本優(yōu)化點按照架構(gòu)層次從上往下，依次是以下幾個方面。

應用性能有待提升

對于企業(yè)主流使用的語言，如PHP、Golang從框架入手。應用框架的理論性能和實際業(yè)務的性能往往有很大gap，多為業(yè)務架構(gòu)缺陷或者數(shù)據(jù)存儲設計的不合理導致。同時應用框架隨著功能的不斷迭代和更高的要求，自身性能上也需要優(yōu)化。

對于一些占用資源比例較重，如超過10%的應用服務也是值得深入投入，其性能的提升能帶來更明顯的回報。

應用部署模式差，帶來計算資源的浪費

單應用服務機器負載率低

對于高并發(fā)業(yè)務，虛機下機器峰值負載常規(guī)在10%-20%，極限可提升到30%-40%。高流量業(yè)務一般代表著公司核心業(yè)務，一方面為了穩(wěn)定性的考慮，整體水位不能控制的過低。另一方面，為了應對一些突增流量，要預留一定buffer。低負載業(yè)務一般碎片化比較嚴重，而這些服務比較長尾，進而拉低了整體負載。

時間不均

互聯(lián)網(wǎng)業(yè)務普通有明顯的波峰波谷，波峰和波谷的實際資源使用量至少有一個數(shù)量級差距，且真正的最高峰只有不到一個小時。企業(yè)不得不為這一個小時的用量而付出一天的成本。

空間不均衡

一方面是在線集群波谷空閑了大量計算資源，另一方面是大數(shù)據(jù)離線計算需要大量計算資源。從整個公司視角來看，資源使用極不均衡。

資源性能有待提升

英特爾、英偉達每年都會有更強性能、更好性價比的硬件推出，云廠商也會有對應產(chǎn)品的發(fā)布。但是企業(yè)中業(yè)務線眾多，一個個去適配、驗證新機型，導致更換的周期往往要1-2年起。無法充分享受硬件帶來的成本優(yōu)化紅利。

解決方案

云原生給企業(yè)帶來一次技術(shù)重塑的機會。容器技術(shù)實現(xiàn)了資源和應用的解耦。業(yè)務研發(fā)和SRE關(guān)注Pod即可。底層計算資源由系統(tǒng)運維統(tǒng)一管理，對上層透明。Kubernetes研發(fā)優(yōu)化應用調(diào)度策略，實現(xiàn)計算利用率的最大化。

大幅提升應用性能

對公司主流的技術(shù)棧，深度優(yōu)化所對應的框架。通過使用更高內(nèi)核的運行態(tài)、使用Kubernetes原生的注冊發(fā)現(xiàn)機制、保持各類網(wǎng)絡連接等等，實現(xiàn)PHP應用43%的性能提升。

通過使用fluid，完成檢索服務計算和存儲的分離，極大提升了運維效率。過程中對內(nèi)存基帶的使用進行了優(yōu)化，帶來30%性能提升，節(jié)省萬核級別計算資源。

調(diào)度優(yōu)化，整體提升計算利用率

容器服務使用統(tǒng)一的集群，常態(tài)在40%左右，在保障業(yè)務穩(wěn)定的情況下極限可達60%。機器利用率大幅度提升。碎片化問題也得到徹底解決。

但中間過程是曲折的，和騰訊云一起攻克了一系列業(yè)界難題。

在2020年上半年我們完成了一塊核心業(yè)務的容器化之后，突然發(fā)現(xiàn)我們的運維成本居然增加了。原來在虛機模式下，運維在晚高峰的時候，只需要去做一些穩(wěn)定性的巡檢，其實并不需要有過多的一些運維動作。但容器化后，我們在晚高峰下需要不斷地對一些資源負載比較高的的去進行封鎖，然后把上面的一些比較重的Pod進行驅(qū)逐，為什么會這樣呢？就是我們分析了一下Kubernetes的原生調(diào)度器，還是以request進行調(diào)度。互聯(lián)網(wǎng)業(yè)務都會一個明顯的波峰波谷，在線教育的波峰波谷會更加劇烈，波峰波谷可能會有兩個數(shù)量級的一個差異。當研發(fā)在波谷的時候進行一次發(fā)布，這時候就會觸發(fā)容器的一次重新調(diào)度，比如像我這個服務有幾十個Pod的，可能會有十多個pod調(diào)度到一臺機器，因為這時候的機器的使用率很低，就是服務怎么調(diào)度其實都可以，但是到了晚高峰的時候，我的每一個pod資源的使用率就上來的，CPU使用高了，它的吞吐也高了，然后我這十個都在同一個機器上，我這臺機器就會出現(xiàn)一些資源的瓶頸?？梢钥闯鲈恼{(diào)度器只考慮了一些簡單的指標，同時也沒有考慮未來的一個變化。所以我們做了一個定義的調(diào)度器，將就是晚高峰的一些提前的情況進行了一些預測，以及融合了CPU、內(nèi)存、各種io的這些復雜指標都考慮進來做因子，同時就是我們也會定期的把歷史的數(shù)據(jù)進行大數(shù)據(jù)回歸更新策略。

GPU這塊它是一個比較相對貴的資源，我們調(diào)研了一些方案，主要推薦的方案是GPU虛擬化，但至少帶來15%的性能損耗，這個是我們沒法接受的。我們大多數(shù)的GPU服務是使用的各種資源是相對比較固定，所以我們基于算力和顯存去進行了一些策略的調(diào)度，其實也就是比較經(jīng)典的背包問題，同時夜間的話我們也會進行一下預測再重新調(diào)度，如果中間出現(xiàn)一些卡的一些故障，我們也會執(zhí)行轉(zhuǎn)移相關(guān)的策略。

當web業(yè)務的完成容器化改造之后，我們也把一些定時任務遷移到容器的平臺。這時候新的問題又來了，很多任務會涉及到密集的計算，容器本身其實并不是一個隔離的機制，還是在做CPU時間片的一個分配。這些計算密集的任務多多少少還是會對web的任務造成一定的影響。同時它也會占用主機的IP資源，node上的IP資源是有限的，定時任務調(diào)度上來之后就會分配IP，任務銷毀時IP資源也不會立刻銷毀，如果頻繁的把定時任務的pod的調(diào)度到主機群的節(jié)點上，就會導致主機群的web服務沒有足夠的IP資源。同時大規(guī)模的創(chuàng)建跟回收定時任務，也會觸發(fā)一些內(nèi)核的問題，就比如有些定時任務的內(nèi)存使用比較大，大規(guī)?；厥諘е孪萑雰?nèi)核態(tài)，hang住的時間比較長。這塊我們做的一些改造是這樣的，我們建立了三個池子，serverless、任務集群、主機群，我們優(yōu)先會把定時任務去調(diào)度到serverless上，如果調(diào)入失敗的話，再依次到任務集群、主集群，serverless并不是一種完全可靠的計算模式，對于他的使用我們這里引入了一種資源預占的方式，比較類似于金融領(lǐng)域為保證事務的兩階段提交，我們預先去申請相關(guān)的資源，當完成預占之后，我們再把真正的把任務調(diào)度過去。

在離線混部是工程界的就是一個比較經(jīng)典的課題。在線資源是有明顯的波峰波谷，波谷有大量的剩余計算資源。大數(shù)據(jù)離線使用了大量的一些資源，但多數(shù)的任務對計算的實時性并沒有那么強的要求，說必須在幾分鐘內(nèi)得到結(jié)果，幾個小時跑出來也可以。如果我在在線集群波谷時來跑大數(shù)據(jù)離線計算，大數(shù)據(jù)離線的資源就可以節(jié)省出來，這樣就可以達到一個雙贏的效果。但是它會面臨很多挑戰(zhàn)，就是其實很難做到資源的完整隔離，在線資源的穩(wěn)定性、延時都會受到影響。負責在線業(yè)務的同學也會有顧慮，就是我沒有得到很大的一個收益，然后還影響了我的業(yè)務。在內(nèi)核增加了新的一個調(diào)度器，在cfs和idle之間，把大數(shù)據(jù)的任務放到這種放到這類調(diào)度器上，然后就實現(xiàn)了CPU的避讓。在放量的過程中，我們也整體控制節(jié)奏，我們先在夜間在線服務沒什么量的時候來跑離線計算，然后跑相對比較穩(wěn)定之后，我們再在白天的波谷時間來跑大數(shù)據(jù)離線。又經(jīng)過一段時間穩(wěn)定之后，我們現(xiàn)在其實在晚高峰的時候，也在跑離線任務，只不過是控制在10%的CPU使用以內(nèi)。

使用新硬件，大幅提升單位計算的性價比

容器環(huán)境下集群底層計算資源使用有限數(shù)量的機型，做一些機型更換時減少了業(yè)務研發(fā)適配的成本，更換效率大幅度提升。

實踐價值

在多重舉措的合力推動下，作業(yè)幫容器化的收益顯著，同樣業(yè)務遷移前后，使用了HPA和在離線混合部署后，成本下降43%，穩(wěn)定性提升到99.995%，接口響應提升10%。由此，有效支持了作業(yè)幫業(yè)務的快速迭代，秒級急速擴縮容，服務運行態(tài)規(guī)范落地和統(tǒng)一的運維環(huán)境，多云的環(huán)境統(tǒng)一，提升服務可用性。這也便于云間相互自由遷徙，實現(xiàn)單云故障的應急預案，通過優(yōu)化資源碎片，在離線混合部署，自動擴縮容，整體成本進一步下降。