?🏻 本文作者：木行、冰瞳、春草、堇華、玄同等

丨目錄：

· 寫在前面

· 新的探索

· 方案設計&落地

·??實驗

· 總結與展望

·?寫在最后

· 引用

在綠色計算的大背景下，算力使用將朝著更加高效和智能的方向持續演進。本文將介紹阿里媽媽展示廣告引擎在全局視角下優化算力分配的最新思考和實踐，歡迎留言一起討論。

阿里媽媽動態算力系列文章：

【2021】阿里媽媽展示廣告引擎新探索:邁向全局最優算力分配

【2020】動態算力起源-阿里媽媽展示廣告引擎的“柔性”變形之路https://www.infoq.cn/article/wEaIlWl7076Id2bQptAq

??寫在前面

在追求節能減排，降本增效，綠色技術的大趨勢下，充分利用好算力資源尤為重要，尤其是在阿里媽媽展示廣告引擎這種使用近百萬core的業務中。Transformers—動態算力的出發點就是利用好算力拿到更多業務收益(把算力分配給邊際收益大的服務)。從最初的起源[1]，到去年嘗試從全局視角去考慮算力的分配，建設了全鏈路RT分配[2]，動態算力始終圍繞著如何把算力用好，提升服務運行時效率這個核心持續演進。今年上半年繼續圍繞從全局視角出發優化算力的分配，而這一次主要圍繞機器自適應分配展開。另外令人非常興奮的是，不管是集團內還是集團外都有多個團隊開始投入到這個方向，如目前公開的具有代表性的美團外賣智能算力[3]，為該方向的建設提供了非常好的思路。

雖然動態算力去年在全鏈路RT分配上取得不錯的成果，但也存在一些問題。算力本質是計算量，由qps和單請求的計算邏輯決定。在實際觀測時，使用多少計算量是可以通過計算耗時RT乘以所用機器資源數估算，可見消耗的計算量由RT和機器資源共同決定。在實際調控中，有的場景RT調控空間非常有限(調不動)，如下圖(引擎中為了減少RT，有大量的并發場景)調用精排Rank服務：減少單隊列長度以及隊列數，RT下降比例小，但是卻能節省大量機器資源。

圖1.并發場景中RT調控空間有限

圖2集中體現了我們對算力，計算量，RT以及機器之間關系的理解，機器調配是動態算力技術體系中不可缺少的一部分。

圖2.算力分配中調配機器的重要性

一、新的探索

考慮到RT和機器資源同時調控的復雜性，這一期先在固定RT分配的情況下探索機器資源的調配方案。主要的目標是：希望在總機器資源固定時(日常流量qps較穩定,可以認為不變)，通過合理的調配廣告引擎全鏈路各服務間的機器，在業務效果rpm(業務效果可以是其他任何可量化的指標)和簡化機器運維成本等方面拿到收益。

1.1 核心思路

機器資源一定的情況下，統計不同服務在不同機器資源組合下的rpm數據，取rpm最大時的資源組合，然后進行資源調配。（注意：rpm跟qps無關，因此統計數據的時候假定qps不變化以簡化問題。）服務在不同機器下因為要保證服務不超時必然會導致降檔[1]，降檔也就意味著rpm下調。所以通過調配機器來實現檔位控制，而檔位又決定了效果，最終實現通過調配機器來實現對效果的控制。雖然原理看上去簡單，但是落地卻十分復雜，以下選擇實踐過程中我們遇到的幾個挑戰以及相應的解法來進行介紹。

1.2 關鍵挑戰

挑戰一：如何獲取單服務使用機器資源跟效果rpm之間的關系

每個服務的機器資源跟rpm之間的關系數據其實可以通過定期擴縮容演練獲得，但實操成本太高，也沒有辦法在線上進行操作，日常檔位(也即level)變化會直接影響大盤效果。如果是在線下壓測環境進行，需要維護單獨的一整套壓測環境，機器資源日常本來緊缺，無太多空閑資源給壓測環境。而且數十個服務，每個服務擴縮容驗證也比較麻煩，總之運維成本太高。那么如何高效又準確的得到服務機器資源跟rpm之間的關系呢？下面是我們的思考過程：

機器資源 <-> rpm近似cpu cores <-> rpm: 因為引擎絕大部分服務主要關注cpu資源，rank部分要考慮gpu和mem，本次僅考慮cpu cores。

已知level <-> rpm的關系，因為可以通過小流量開通設定檔位然后統計level <-> rpm的關系，所以問題轉為成求cpu cores<->level的關系。

考慮到：算力=計算量=RT*計算資源(cpu cores)，當level一定時，計算量一定。（注意qps是一定的）RT跟計算資源成反比。

當檔位上升帶來10%的計算量增加時，如果要保持RT不變，那么計算資源應該增長10%。而實際可以開小流量桶測量 level->計算量的關系，小流量上的計算量可以簡化為 RT(響應時間) * 并發數(1個并發對應1個計算實例)，以100檔的RT * 并發數記為1，當檔位變化時，可以計算得到計算量的相對變化率。通過這里轉化就可以得到level->機器資源的近似數據。比如Rank服務在75檔和100檔時的響應時間RT和并發數分別為(39.5ms, 7)，(40ms, 8)，并且線上Rank使用cpu cores為12萬核。用Rank(level)表示取特定檔位時對應的計算量，x表示rank level = 75時需要的近似cpu核數。

，然后結合校正方法對該數據進行優化(不同的服務可能不一樣，相同的服務在不同檔位時也可能需要增加校正系數)。

挑戰二：如何獲取多服務之間檔位組合跟效果rpm的關系，小桶測量數據稀疏問題如何解

因為機器調配涉及多個服務，檔位組合是叉乘關系(每個服務檔位的變化都會影響效果)。比如A，B和C三個服務，每個服務對應一層實驗，每個桶流量1%，那么一個組合只有100萬之一的流量，量小結論不置信，而且擴展性差，后面會加入更多服務，這導致數據稀疏問題非常嚴重。考慮到數據量，(統一時間拉太長也會有實效性問題，因此取最近3天數據)只支持直接測兩兩服務檔位組合的效果數據，如rpm(A=5,B=10)表示A取5檔，B取10檔時的rpm。那當有3個或者3個以上的服務時，檔位組合對應的效果數據如何測量？下面是我們基于條件概率的思想給的一個方案：

基于上下游兩兩檔位組合的效果數據推算出多服務的檔位組合效果，通過rpm(A,B)和rpm(B,C)推導出rpm(A,B,C)結合采樣點的實測數據試進行校正。如通過定義計算比值f：

針對兩個服務例子：

則有：

同理三個服務例子：

假定只考慮上下游服務間的影響，不考慮間接的影響。注意我們計算的是比例：

而

日常服務檔位未明確指定的則意味著檔位是100滿檔(動態算力日常絕大部分時間不降檔)。對比上述兩個公式的分子和分母，A檔位的變化會同向影響rpm(B=10,C=8)和rpm(B=10)，這里假定對二者的影響比例一樣。(實際中也可能會有一定影響，所以結合單點開桶rpm(A=5,B=10,C=8)進行微校正。)

那么A和C在統計上是獨立的，所以：

進一步有，

這樣就可以通過兩兩檔位組合rpm推算出三個及以上檔位組合的rpm數據，解決數據稀疏的問題。

在基于上述數據的基礎上，則可以實現最優機器分配(從資源池中擴縮機器或者定期調整機器分配)，比如：當前線上檔位(或資源組合)：(A=10, B=5, C=8) rpm=20(非真實值)。

目標：縮容50臺機器

組合1: (A=9, B = 5, C=8) rpm=19.8 機器節省45

組合2: (A=10, B = 4, C=7) rpm=19.7 機器節省50

組合3: (A=9, B = 5, C=6) rpm=19.6 機器節省50

最優組合2跟線上組合取diff，計算B和C各自縮容機器數如：15 + 35。

二、方案設計&落地

2.1 框架圖

圖3. 機器調配框架圖

2.2 核心模塊

2.2.1 離線數據計算介紹

基于在線服務中的日志(主要包括服務響應時間,并發數以及level等)，產出各服務機器，檔位和業務效果(rpm)之間的關系數據，產出邏輯請參考關鍵挑戰部分。

2.2.2 Ops管控動態擴縮容

各ops管控提供http訪問接口，通過調用這些接口實現對指定服務的quota查詢和更新，來實現最終的動態擴縮容。

2.2.3 動態算力的管控和視圖

1）管控負責提供人工管理機器調配的交互接口，包括機器調配目標，調控模式以及詳細的擴縮容推薦方案

2）視圖負責展示機器調配狀態以及最終效果對比展示

4. 容器分配調控中心ASController

負責基于離線產出的各服務(機器，檔位，rpm)的數據以及管控人工設定的要求(如縮容5000核cpu等)，選擇最優的各服務機器組合。然后根據ops管控返回當前線上服務真實機器數據，通過求差值，最后生成每個服務的具體擴縮容計劃同步到動態算力管控，人工確認后，則按照執行計劃通過ops提供的API對每個服務進行擴縮容操作。

2.3 落地功能

目前整個機器調配鏈路已經發布到線上，接入了包括檢索，粗排，精排和策略等多個核心服務。相關核心效率數據的計算也已經日常產出。下面對主要的一些數據和功能進行介紹：

2.3.1 相關效率數據展示

1）衡量服務邊際收益(rpm/萬核)的數據

圖4. 各服務算力使用邊際收益

2）檔位跟算力以及效果的關系圖

圖5. 服務在各業務場景下檔位,算力以及rpm關系

2.3.2 兩種觸發方式（rpm效果最優或者資源上下線）

1）效果最優，相同資源下，通過調配服務間的機器配比拿到更優的效果。如下圖：當有更優的組合，rpm比線上組合rpm大0.05時，則會自動生成新擴縮容方案。

圖6. 自動觸發模式

自動生成計劃，把機器從邊際收益低的服務挪動給邊際收益高的服務。

圖7. 自動觸發模式下生成的擴縮容報告

2）機器上下線，資源總量變化，擴容時會選擇把機器分配邊際收益最大的服務；縮容時會從邊際收益最低的服務下機器，盡量減少效果損失。如下圖在na630機房縮容4000核。

圖8. 人工設定擴縮容目標模式

生成擴縮容計劃，從邊際收益低的服務縮機器。

人工設定擴縮容目標模式下的報告

2.3.3 兩種使用模式

1）產出詳細的推薦報告方案，業務方參考進行機器調整

2）自動模式，交由動態算力自動完成線上機器調整

三、實驗

基于上述方案，我們針對App1和App2服務在線上進行實驗。以驗證理論計算出來的收益值跟實際是否一樣。也希望通過實驗，為進一步的精細化校正計算邏輯提供數據支持。本次實驗分為兩個實驗，具體如下：

3.1 實驗一：單服務檔位實驗

實驗內容：驗證購后場景的App1在50檔時的效果，理論計算中，相比100檔效果下跌0.6%~0.7%。

實驗方案：na61為BASE（無操作），na630為EXP（固定App1檔位為50）。

實驗結果

表1. 單服務檔位變化后效果變化情況

實驗分析

實驗打開前(對應20, 21兩天)，機房間對比平均rpm為+0.81%，實驗打開后(對應22, 23兩天)，機房間對比平均rpm為+1.54%，說明調正后效果為rpm+0.73%，符合理論計算值0.6%~0.7%。

3.2 實驗二：多服務檔位實驗

實驗內容：驗證首猜場景的(App1 100檔, App2 90檔)調整為(App1 80檔, App2 100檔)的對比效果，理論計算值為+3%左右。

實驗方案：ea119為BASE（App1 100檔, App2 90檔），ea120為EXP（App1 80檔, App2 100檔）。

實驗結果

表2. 多服務檔位變化后效果變化情況

實驗分析實驗打開前(對應21, 22, 23這3天)，機房間對比平均rpm為-0.48%，實驗打開后(對應26, 27, 28這3天)，機房間對比平均rpm為+3.02%，效果為rpm+3.5%，接近理論計算值+3%左右。

3.3 結論

（1）理論計算的檔位效果組合，在大流量下的實驗也基本符合預期。

（2）由于機房間的效果對比，不是完全的ABTest實驗，本身機房之間就存在效果上的波動（波動大約有1%）。但第二個實驗的兩個組合的效果差距在3%左右，降低了波動帶來的影響，其結論還是置信的。

（3）第二個實驗中，首猜場景的App1 90檔相比100檔，算力-6.3%。調配3.9%的算力給App2，保證App2的cpu水位不變。最終整體上，節省算力2.4%，且調控后rpm+3%。

四、總結與展望

現階段考慮到系統的穩定性和多團隊之間的資源池未拉通，線上使用模式是：產出容器分配推薦報告后，作為人工擴縮容的參考，然后進行局部調整(如機器資源不足時優先保障哪個服務的算力)。后續推進在保障系統穩定的前提下，讓調配更加精準以及資源池拉通，從更高的視角去優化機器資源的分配，在日常全面用起來。另外也在推進建設模擬環境，對度量的精準度進行優化。

4.1 總結

好的方面

（1）整個引擎鏈路涉及到多個服務分屬多個團隊，還有多套ops，但機器調配功能均可以調控。

（2）通過理論推演結合校正方法，可以通過較小的成本即可找到最優的機器配比。

不足的方面

（1）目前雖然整個機器調配功能已經上線，但只有精排，粗排和策略等服務接入，調控空間有限。后續還需要接入更多的服務，從更大的視角優化算力的分配。

（2）現在的擴縮容對level的影響是基于理論推算，但實際可能跟理論推算不一樣，而且還可能跟不同時段系統水位甚至不同業務場景有關，因此需要在未來實戰中進行不斷優化。

4.2 展望

本文是全鏈路機器自適應調配的階段性總結，Transformers將繼續推進接入更多服務以及在精細化度量上的探索，希望在機器調配這里拿到最終的業務收益以及探索算力，容量和效果之間的關系，用來指導系統的容量規劃。總之，動態算力會持續朝著使系統更加穩定，更加高效和智能的方向持續演進，讓在線引擎像變形金剛一樣動起來。

??寫在最后

我們是阿里媽媽廣告技術部工程技術引擎平臺團隊，致力于高效智能營銷引擎的打造。本文成果由包括廣告算法、業務引擎和引擎平臺等團隊共同完成。希望給從事相關工作的同學帶來一些幫助和啟發，也期待與大家多多交流。

引用

[1] 動態算力起源-阿里媽媽展示廣告引擎的“柔性”變形之路：https://www.infoq.cn/article/wEaIlWl7076Id2bQptAq

[2]?阿里媽媽展示廣告引擎新探索：邁向全局最優算力分配

[3] 美團外賣廣告智能算力的探索與實踐?

END

也許你還想看

丨新時期的阿里媽媽廣告引擎

丨廣告庫存管理系統性能優化實戰

丨面向數智營銷的 AI FAAS 解決方案

丨廣告深度學習計算：異構硬件加速實踐

丨廣告深度學習計算：召回算法和工程協同優化的若干經驗

關注「阿里媽媽技術」，了解更多~

喜歡要“分享”，好看要“點贊”?~

↓歡迎留言參與討論↓

總結

以上是生活随笔為你收集整理的阿里妈妈展示广告引擎动态算力再探索：面向业务收益的机器自适应调配的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。