成本降低40%、資源利用率提高20%的 AI 應用產品雲原生容器化之路

作者

郭雲龍，騰訊雲高階工程師，目前就職於 CSIG 雲產品三部-AI 應用產品中心，現負責中心後臺業務框架開發。

導語

為了滿足 AI 能力在公有云 SaaS 場景下，服務和模型需要快速迭代交付的需求，保障服務在不穩定高併發時的高成功率，以及進一步提升資源利用率，AI 應用產品中心進行了一系列的調研與實踐，本篇將重點介紹團隊在容器化方面的實踐經驗。

背景和問題

公有云 AI SaaS 產品（如人臉融合)的一般服務流程為：C 端或 B 端客戶通過採集裝置採集影像、音視訊等，經由雲 API 等接入方式傳入，服務端利用強大的計算能力、充足的資源和相對成熟的演算法對客戶輸入的多媒體內容進行處理。

如上圖所示，對於一般流程來說，我們面臨著三個挑戰。

1. 採集質量不穩定：由於採集裝置之間存在差異，採集到的質量也會存在差異，拿影像處理來說，大圖和小圖會給我們的服務帶來不同的壓力，有時服務會因為集中的大圖併發產生失敗。
2. 短期、高併發需求多：我們的客戶會用我們的能力實現不同的玩法，使用人臉融合來進行遊戲活動宣傳就是一個很常見的運營手段，但是這種活動會給我們的服務帶來短期內的高併發壓力。
3. 模型、服務迭代快：AI SaaS 服務的競爭非常激烈，經常會有客戶提出新的需求，加上演算法難免會有 badcase，所以我們的服務也要進行很頻繁的升級迭代。

我們再來看下我們容器化前的精簡架構（如上圖所示），物理機的開發部署大背景下，我們的邏輯服務不論是結構上還是基礎上都屬於大泥球模式，另外演算法服務也常有混布的現象存在。

這種架構也導致了忙時服務間搶佔資源的情況頻繁發生，影響服務成功率及耗時，導致我們沒有辦法很好的滿足客戶的需求；而閒時資源利用率非常低，容易造成資源浪費。

以兩個實際的例子來說明：

1. 升級釋出時，我們需要先從LB中剔除一個節點，並在節點上觀察沒有流量進入後進行服務升級。升級完成後，人工對服務進行成功性檢測，檢測結果ok後再加回LB中。
2. 客戶搞活動時提出高併發需求，如果當前物理機/vm資源池不滿足，需要向資源同學緊急提物理機需求，資源同學協調到機器後，我們需要人工對機器環境/網路重新初始化，然後執行上述1操作。待活動結束後機器閒置，易造成成本浪費。

為了更好的滿足客戶不斷迭代的需求，減輕研發的運維負擔，補齊彈效能力和接入高效的服務管控平臺對我們來說是迫切需要的。趁著公司推動上雲的時機，我們對架構元件進行了幾輪調研和優化。本文主要對容器化過程進行闡述。

容器化過程記錄

我們的容器化上雲到現在為止可以分為三步：容器化，穩定性提升和利用率提升。

容器化

這裡的容器化對映到業務上來說，除了將服務載體由物理機遷移到容器上，更主要是將原來的複雜邏輯解耦，微服務化。

如下圖所示，我們先對服務本身做了瘦身微服務化，另外借助於容器的能力，將原來混布的服務徹底分開。如何進行微服務化會因業務的不同存在差異，本篇對此不做贅述。

穩定性提升

在第一步容器化之後，我們很快享受到了飛一般的服務升級和擴容速度。同時對容器化比較淺顯的理解也給我們帶來了一些新的問題。

1. 呼叫量波動較大的服務由於頻繁擴縮容導致業務失敗
2. 一些客戶傳的大圖在低核容器上處理效率較低
3. 叢集資源緊缺導致的容器無法按需擴容等。

對於上述三個問題，我們也分別找出了應對方案。

靈活使用探針

起初我們的服務都是沒有設定存活和就緒檢測（探針 ）的，Prestop 給縮容時加上了一層保護，但是並不徹底，而且在擴容時難免會有服務失敗。

探針給我們提供了另一種強大的解決方式。一開始時，我們參照連結中的示例，進行簡單的埠檢查來判斷服務是否正常執行。後來我們發現了更多靈活的運用技巧和使用場景。以下列出幾個例子供大家參考以及發散出更多有趣實踐。

例子1：在一開始時大家經常遇到 LB Agent 啟動時獲取路由必然失敗的情況，我們可以使用就緒探針來進行 LB 的預載入（如下圖），即可達到 LB 獲取成功後標記服務啟動成功的效果。

例子2：由於一些低版本OS的例項存在弱口令的問題，大家需要把所有依賴舊版OS的映象全部升級，這個工作對我們來說是及其繁重的，於是我們同樣利用了探針，在容器標記服務啟動前把弱口令全部幹掉。

例子3：某個服務比較特殊，記憶體佔用經常波動，當記憶體小於某個值時，服務會偶現失敗，但是埠正常存活。這時我們可以使用 ConfigMap+python 指令碼來進行一些複雜的檢測：

針對大圖進行篩選適配

容器化後，我們發現某個演算法在接收到高解析度圖片時，服務成功率會出現波動，原因是演算法在對提特徵時會出現更多的消耗，這一現象在物理機上部署時被物理機核數多的優勢掩蓋住了，一旦到了核數較低的容器上就顯露了出來。為了解決這個問題，我們在上層邏輯中新增了大圖篩選功能（如下圖所示），如果檢測到是大圖，則走回物理機叢集（由於初始時 TKEx 提供最高規格容器核數為 8 核，後來才擴充支援了 24 核及以上），如果是一般圖片，則走容器叢集。

多叢集部署

在使用 TKEx 時，我們經常會碰到部署的 workload 會因為整體叢集資源不足的原因，無法擴容到指定的 max 值，一度非常苦惱。

TKEx 的同學也是推薦我們在其他的叢集複製一份資源，當一個叢集擴不出來時，另一個叢集充當備份角色。在這麼調整過後，我們的擴容成功率逐步上升。

後來又出現了整個地域的資源都比較緊缺的情況，於是我們把一些對時延不那麼敏感的服務進行了多地域部署（如下圖），最終將叢集資源不足的風險進一步降低。

當一地資源不足的情況下使用多地域部署以及 LB 時，一般 LB 都會根據後端響應時間動態調整各節點權重，所以我們應注意以下兩點：

1. 關閉就近訪問
2. 根據上下游調整 LB 權重（比如上游服務部署在廣州，下游同時部署了南京和廣州，這是南京和廣州的 LB 權重分別為130，100）

利用率提升

在進行過一輪穩定性提升之後，我們可以更加自信的利用彈效能力，利用率也有了顯著提升。不過依舊有兩個問題阻礙著我們的利用率更進一步。一個是有些服務模型大，啟動慢，流量突增時服務無法很及時的擴容出來，這時我們必須要提前佔用一些資源導致利用率提不上去。

針對第一個問題，我們挑選了部分流量有規律的服務。利用 TKE 提供的定時 HPA 能力，在已知流量高峰前定時進行一輪擴容。

成果

當前我們的 AI 服務已經基本完成容器化的升級。成功率高，擴容快，歡迎大家掃碼進行體驗。

關於我們

更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~

福利：公眾號後臺回覆【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！