嘉賓 | 呂亞霖
編輯 | 張誠
本文整理自作業幫基礎架構研發團隊的負責人呂亞霖在WOT2024大會上的主題分享。
2024年6月21日-22日，以“智啟新紀，慧創萬物”為主題的“WOT全球技術創新大會2024·北京站”正式召開。在《云原生時代的成本優化》專場，來自作業幫基礎架構研發團隊的負責人呂亞霖帶來了《作業幫基于云原生的降本之路》的主題分享，詳細介紹了作業幫基礎架構如何基于云原生技術，在滿足業務快速迭代和穩定性基礎上，實現系統化周期性的成本降低。
以下內容，根據呂亞霖老師的演講實錄整理而來。
一、云原生降本背景和目標
在實現降本的過程中，大家普遍面臨來自于三種場景的挑戰：
場景一：短期運動化降低了成本，一年后成本反彈反而更高了；
場景二：通過舍棄穩定性來降低成本，遇到了大的事故，得不償失；
場景三：在大型復雜系統內，各個團隊降本往往聚焦自身一點，無法整體統籌，甚至把成本轉移給其他部門。
呂亞霖認為，通過合理的云原生架構來找到一條體系化持續的降低成本路線，這就是云原生降本的目標。
作業幫的技術現狀主要分為以下四個方面。
- 服務模塊：數千個業務模塊，數十萬計算核心，全球多云多地域多活；
- 多語言棧：golang、C++、python、node、java等；
- 場景多樣：工具化服務、教育類應用、智能硬件場景、AIGC場景；
- 團隊規模：擁有上千人的產研團隊。
呂亞霖表示，這四個方面是大多數具備相同體量公司目前的主要技術現狀，因此作業幫的云原生降本路線對大多數具有相同體量的公司有著一定的參考意義。
呂亞霖強調，云原生降本路線的關鍵點有兩點。一是要熟練掌握業務特征以及技術組件的各種特征，通過云原生架構來適配底層的基礎設施；二是基礎設施要向上反饋架構的適配性，盡量能夠滿足云原生架構，即業務、中間件和基礎設施都向云原生架構靠攏，實現雙向奔赴。
二、應用：流媒體和serverless的最佳組合
作業幫有一個比較典型的業務場景是流量的時間周期特別明顯，例如主要集中在下午3點、4點、5點這幾個小時內。開始的一瞬間，流量達到峰值，之后幾乎沒有流量。
呂亞霖表示，針對作業幫的業務特點，我們使用了Serverless的VNode節點開源方案進行了改造，在一個 Service中包括很多Node物理節點和虛擬節點，虛擬節點VNode可以看成是一個無限擴展的物理節點，這樣的方案使得在上層業務中看不到任何差異。因此，我們可以把VNode當成一個無限的擴展節點，它的Pod會橫向擴容到VNode上，當流量高峰到來時。正常的服務也能夠正常調用。
呂亞霖通過一組數據，展示了流媒體服務serverless架構成本優勢。
假設：包年包月服務器每小時成本為C，使用serverless每小時成本為1.5C。全部使用包年包月服務器的總成本為 C * 24 = 24C，serverless成本為1.5C * 5 + 10% * C* 19 = 8.4C。
最終得出的結論是，使用serverless可降低成本：(24C – 8.4C) / 24C = 65%。
雖然serverless能夠顯著降低成本，但在技術架構的改造過程中，也會面臨如下幾個方面的挑戰。
1.穩定性挑戰
作業幫采用了調度器和分流機制來解決這一挑戰。
在調度器方面，一是采用預測式擴縮容YHPA，預測業務流量高峰來臨前半個小時提前調度擴容；二是兜底擴縮機制DHPA，當預警流量進入，全量急速拉起全容量服務。
在資源保證方面，一是通過與廠商商談資源的預留，讓我們想要的資源不要快速釋放，確保一定的資源預留量。二是就近地域IDC分流，比如北京IDC需要一萬核，廠商只能提供八千核，差的兩千核容量就要分流給河北的IDC，這就需要直接在端上進行分流。當然，也可以通過直接采購云上SaaS產品，在端上進行自研和Saas產品分流。
2.觀測性挑戰
主要通過日志采集組件DS注入POD、追蹤組件上報collector、監控支持Prometheus、支持與kubelet通信，獲取運行POD的信息等技術來解決這一挑戰。
對于網絡挑戰，作業幫通過Serverless支持指定公網EIP進行解決。在安全挑戰上，作業幫通過注解的方式把安全組下放，快速啟動并通過底層sanbox復用進行解決。
三、基礎組件：服務觀測基礎組件的云原生架構改造
呂亞霖以日志服務為例，介紹了基礎服務成本之殤。
“假設每日產生1PB日志，存儲&檢索一個月的日志，需要多少成本。” 呂亞霖以一道數字題，介紹了日志服務的成本。他表示，如果使用ELK，只算ES的話，按照官方介紹測算寫入和查詢需要的算力，大概需要上百臺96C物理機器。在極端計算下只算磁盤成本，1TB磁盤需要350元/月，30PB則需要350*1000*30 = 1000萬/月。監控、日志追蹤同理。
呂亞霖表示，大部分互聯網企業，服務觀測成本占在線業務總體成本（不包含大數據）的15%，甚至更高。但是，只有在5%以下才是合理區間，因此有大量的優化空間。
在觀測體系的改造上，作業幫采用將容器產生的日志，通過輸出到logagent傳輸給Kafka，最終通過日志的存儲和檢索、日志監控、日志追蹤分發給大數據。大多數觀測數據來自于服務網格上報，例如每次過網格時就會把分布式追蹤的上下文報下來，但實際上網格是沒有覆蓋到底下的各種存儲、MySQL、Redis或者其他存儲，這類數據是通過解析日志上報上來的。
在檢索存儲系統的改造上，由于Ingester是一個訂閱Kafka系統，它會以塊（一個塊大概幾十兆）的形式寫到本地化存儲中，并且對塊上的pod信息、日期、服務建立索引。這時，它就會自動進行冷熱沉降，例如本地有一個7T存儲盤，它將預留80%，如果超過7T容量，就自動開始往對象存儲上沉降，并把最熱的數據放在本地，歷史數據放到對象存儲中。然后，在對象存儲中把超過30天的數據歸檔到冷存儲中。當需要查詢數據時，就會對下邊所屬的集群同樣發出Query請求，并通過數據找到這個塊所在的位置，對塊進行查詢。
呂亞霖表示，這并不是一個檢索系統，而是分布式計算系統。其優勢在于按塊存儲當數據寫入時吞吐量非常高，因此我們并不需要建立索引，只需要建立一個簡單的基于塊的索引信息就可以了。另外，由于采用了歸檔沉降，將超過30天的數據進行三級歸檔后進入冷存儲，冷存儲的成本就會比較低。進行數據查詢時，采用了全量的并發查詢，只需要通過簡單的命令就能夠能夠拿到結果。
通過日志云原生改造，作業幫將1%的數據存儲在本地盤，實現了0.35元/GB/月；5%的數據經過90%的壓縮后存儲在對象存儲中，實現了0.12元/GB/月；94%的數據經過90%的壓縮后存儲在深度歸檔存儲中，實現了0.03元/GB/月，參考自騰訊云廠商目錄價。
在監控云原生改造上，作業幫采用了Prometheus體系，通過將VictoriaMetrics替換到Prometheus內部的TSDB。除此之外，還在VictoriaMetrics之前加上了Remote-write組件，支持所有Prometheus遠程寫入，同時通過寫入一個VM標準集群和降準集群來進一步降低成本。通過改造，標準集群的高精度只會保留半年，降準可以保留到三年以上。
在分布式追蹤云原創改造過程中，作業幫使用CK替代ES，寫入提升了40%，CPU下降了80%，磁盤下降了50%。另外，還實現了服務網格、日志分析上報，業務無感全覆蓋全采集。
四、基礎設施多云多地域融合
在IT基礎設施中，使用GPU算力所帶來的成本非常高。呂亞霖以GPT-4為例，通過一組數據詳細介紹了GPU帶來的高算力成本。
以GPT-4當前的價格做一個簡單的估算，假設日活躍用戶達到1000萬DAU，5000token / DAU，并且不考慮其他的費用，每天產生的費用為：10M * 5000 tokens * $15 / 1M tokens = $75萬，非常昂貴。
另外，受用于大模型的GPU價格昂貴、以LLM為代表的大模型參數規模變大、業務場景下的推理算力利用率不足三個方面因素的影響，使用自有服務器的成本也比較高。
呂亞霖認為，容器化是解決高算力成本的基石。他表示，容器化能夠使資源透明地、快速地部署到各個IDC，打平計算、存儲、網絡等IaaS底層資源，實現資源的透明部署，并同時支持服務觀測、服務網格、服務注冊發現等上層服務的治理。
為了解決GPU高算力所帶來的成本問題，作業幫進行了GPU推理容器化的改造，并通過GPU算力網絡多地域的融合，實現了動態流量調度、傳輸協議自動切換、超高壓縮率、動態容量調度和密集部署，算力和顯存使用率提升30%。
演講最后，呂亞霖指出，在云原生成本優化中，要首先發現浪費，然后再制訂合理的成本優化方案。在成本優化時，要堅持自上而下，先易后難的原則。此外，要從平臺系統化、面向應用服務的成本中心、面向基礎架構的成本中心三個方面出發，要持續進行優化，才能更好地降低成本。
嘉賓介紹
呂亞霖，2019年加入作業幫，作業幫基礎架構-架構研發團隊負責人，主導了作業幫多云云原生架構演進，負責作業幫容器化建設、服務治理體系建設、多云建設、應用框架&中間件升級適配、服務穩定性保障。對容器化、微服務框架、服務治理、DevOps等有大量一線實踐。
