作者
郭雲龍,騰訊雲高階工程師,目前就職於 CSIG 雲產品三部-AI 應用產品中心,現負責中心後臺業務框架開發。
導語
為了滿足 AI 能力在公有云 SaaS 場景下,服務和模型需要快速迭代交付的需求,保障服務在不穩定高併發時的高成功率,以及進一步提升資源利用率,AI 應用產品中心進行了一系列的調研與實踐,本篇將重點介紹團隊在容器化方面的實踐經驗。
背景和問題
公有云 AI SaaS 產品(如人臉融合)的一般服務流程為:C 端或 B 端客戶通過採集裝置採集影像、音視訊等,經由雲 API 等接入方式傳入,服務端利用強大的計算能力、充足的資源和相對成熟的演算法對客戶輸入的多媒體內容進行處理。
如上圖所示,對於一般流程來說,我們面臨著三個挑戰。
- 採集質量不穩定:由於採集裝置之間存在差異,採集到的質量也會存在差異,拿影像處理來說,大圖和小圖會給我們的服務帶來不同的壓力,有時服務會因為集中的大圖併發產生失敗。
- 短期、高併發需求多:我們的客戶會用我們的能力實現不同的玩法,使用人臉融合來進行遊戲活動宣傳就是一個很常見的運營手段,但是這種活動會給我們的服務帶來短期內的高併發壓力。
- 模型、服務迭代快:AI SaaS 服務的競爭非常激烈,經常會有客戶提出新的需求,加上演算法難免會有 badcase,所以我們的服務也要進行很頻繁的升級迭代。
我們再來看下我們容器化前的精簡架構(如上圖所示),物理機的開發部署大背景下,我們的邏輯服務不論是結構上還是基礎上都屬於大泥球模式,另外演算法服務也常有混布的現象存在。
這種架構也導致了忙時服務間搶佔資源的情況頻繁發生,影響服務成功率及耗時,導致我們沒有辦法很好的滿足客戶的需求;而閒時資源利用率非常低,容易造成資源浪費。
以兩個實際的例子來說明:
- 升級釋出時,我們需要先從LB中剔除一個節點,並在節點上觀察沒有流量進入後進行服務升級。升級完成後,人工對服務進行成功性檢測,檢測結果ok後再加回LB中。
- 客戶搞活動時提出高併發需求,如果當前物理機/vm資源池不滿足,需要向資源同學緊急提物理機需求,資源同學協調到機器後,我們需要人工對機器環境/網路重新初始化,然後執行上述1操作。待活動結束後機器閒置,易造成成本浪費。
為了更好的滿足客戶不斷迭代的需求,減輕研發的運維負擔,補齊彈效能力和接入高效的服務管控平臺對我們來說是迫切需要的。趁著公司推動上雲的時機,我們對架構元件進行了幾輪調研和優化。本文主要對容器化過程進行闡述。
容器化過程記錄
我們的容器化上雲到現在為止可以分為三步:容器化,穩定性提升和利用率提升。
容器化
這裡的容器化對映到業務上來說,除了將服務載體由物理機遷移到容器上,更主要是將原來的複雜邏輯解耦,微服務化。
如下圖所示,我們先對服務本身做了瘦身微服務化,另外借助於容器的能力,將原來混布的服務徹底分開。如何進行微服務化會因業務的不同存在差異,本篇對此不做贅述。
穩定性提升
在第一步容器化之後,我們很快享受到了飛一般的服務升級和擴容速度。同時對容器化比較淺顯的理解也給我們帶來了一些新的問題。
- 呼叫量波動較大的服務由於頻繁擴縮容導致業務失敗
- 一些客戶傳的大圖在低核容器上處理效率較低
- 叢集資源緊缺導致的容器無法按需擴容等。
對於上述三個問題,我們也分別找出了應對方案。
靈活使用探針
起初我們的服務都是沒有設定存活和就緒檢測(探針 )的,Prestop 給縮容時加上了一層保護,但是並不徹底,而且在擴容時難免會有服務失敗。
探針給我們提供了另一種強大的解決方式。一開始時,我們參照連結中的示例,進行簡單的埠檢查來判斷服務是否正常執行。後來我們發現了更多靈活的運用技巧和使用場景。以下列出幾個例子供大家參考以及發散出更多有趣實踐。
例子1:在一開始時大家經常遇到 LB Agent 啟動時獲取路由必然失敗的情況,我們可以使用就緒探針來進行 LB 的預載入(如下圖),即可達到 LB 獲取成功後標記服務啟動成功的效果。
例子2:由於一些低版本OS的例項存在弱口令的問題,大家需要把所有依賴舊版OS的映象全部升級,這個工作對我們來說是及其繁重的,於是我們同樣利用了探針,在容器標記服務啟動前把弱口令全部幹掉。
例子3:某個服務比較特殊,記憶體佔用經常波動,當記憶體小於某個值時,服務會偶現失敗,但是埠正常存活。這時我們可以使用 ConfigMap+python 指令碼來進行一些複雜的檢測:
針對大圖進行篩選適配
容器化後,我們發現某個演算法在接收到高解析度圖片時,服務成功率會出現波動,原因是演算法在對提特徵時會出現更多的消耗,這一現象在物理機上部署時被物理機核數多的優勢掩蓋住了,一旦到了核數較低的容器上就顯露了出來。為了解決這個問題,我們在上層邏輯中新增了大圖篩選功能(如下圖所示),如果檢測到是大圖,則走回物理機叢集(由於初始時 TKEx 提供最高規格容器核數為 8 核,後來才擴充支援了 24 核及以上),如果是一般圖片,則走容器叢集。
多叢集部署
在使用 TKEx 時,我們經常會碰到部署的 workload 會因為整體叢集資源不足的原因,無法擴容到指定的 max 值,一度非常苦惱。
TKEx 的同學也是推薦我們在其他的叢集複製一份資源,當一個叢集擴不出來時,另一個叢集充當備份角色。在這麼調整過後,我們的擴容成功率逐步上升。
後來又出現了整個地域的資源都比較緊缺的情況,於是我們把一些對時延不那麼敏感的服務進行了多地域部署(如下圖),最終將叢集資源不足的風險進一步降低。
當一地資源不足的情況下使用多地域部署以及 LB 時,一般 LB 都會根據後端響應時間動態調整各節點權重,所以我們應注意以下兩點:
- 關閉就近訪問
- 根據上下游調整 LB 權重(比如上游服務部署在廣州,下游同時部署了南京和廣州,這是南京和廣州的 LB 權重分別為130,100)
利用率提升
在進行過一輪穩定性提升之後,我們可以更加自信的利用彈效能力,利用率也有了顯著提升。不過依舊有兩個問題阻礙著我們的利用率更進一步。一個是有些服務模型大,啟動慢,流量突增時服務無法很及時的擴容出來,這時我們必須要提前佔用一些資源導致利用率提不上去。
針對第一個問題,我們挑選了部分流量有規律的服務。利用 TKE 提供的定時 HPA 能力,在已知流量高峰前定時進行一輪擴容。
成果
優化前 | 優化後 | |
---|---|---|
資源佔用 | 1500+CPU 物理機 ( 8w+ 核)800+GPU 物理機 (P4 1600 卡) | CPU 6w 核 T4 1000 卡 |
資源利用率 | 10% | 30% |
成本 | - | -40% |
服務成功率 | 99.9% | 99.95% |
服務擴容效率 | 小規模 (<2000核): 3 小時 大規模: 2天 | 小規模 (<2000核): 10分鐘 大規模: 6小時 |
服務升級效率 | 小規模 (<50例項): 6 小時 大規模: 2天 | 小規模 (<50例項): 30分鐘 大規模: 6小時 |
當前我們的 AI 服務已經基本完成容器化的升級。成功率高,擴容快,歡迎大家掃碼進行體驗。
關於我們
更多關於雲原生的案例和知識,可關注同名【騰訊雲原生】公眾號~
福利:公眾號後臺回覆【手冊】,可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊,掃碼關注同名公眾號,及時獲取更多幹貨!!