成本降低40%、資源利用率提高20%的AI應用產(chǎn)品云原生容器化之路

導語

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

背景和問題

公有云AI SaaS產(chǎn)品（如人臉融合[1])的一般服務(wù)流程為：C端或B端客戶通過采集設(shè)備采集圖像、音視頻等，經(jīng)由云API等接入方式傳入，服務(wù)端利用強大的計算能力、充足的資源和相對成熟的算法對客戶輸入的多媒體內(nèi)容進行處理。

如上圖所示，對于一般流程來說，我們面臨著三個挑戰(zhàn)。

1.采集質(zhì)量不穩(wěn)定：由于采集設(shè)備之間存在差異，采集到的質(zhì)量也會存在差異，拿圖像處理來說，大圖和小圖會給我們的服務(wù)帶來不同的壓力，有時服務(wù)會因為集中的大圖并發(fā)產(chǎn)生失敗。

2.短期、高并發(fā)需求多：我們的客戶會用我們的能力實現(xiàn)不同的玩法，使用人臉融合來進行游戲活動宣傳就是一個很常見的運營手段，但是這種活動會給我們的服務(wù)帶來短期內(nèi)的高并發(fā)壓力。

3.模型、服務(wù)迭代快：AI SaaS服務(wù)的競爭非常激烈，經(jīng)常會有客戶提出新的需求，加上算法難免會有badcase，所以我們的服務(wù)也要進行很頻繁的升級迭代。

我們再來看下我們?nèi)萜骰暗木喖軜?gòu)（如上圖所示），物理機的開發(fā)部署大背景下，我們的邏輯服務(wù)不論是結(jié)構(gòu)上還是基礎(chǔ)上都屬于大泥球模式，另外算法服務(wù)也常有混布的現(xiàn)象存在。

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

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

升級發(fā)布時，我們需要先從LB中剔除一個節(jié)點，并在節(jié)點上觀察沒有流量進入后進行服務(wù)升級。升級完成后，人工對服務(wù)進行成功性檢測，檢測結(jié)果OK后再加回LB中。

客戶搞活動時提出高并發(fā)需求，如果當前物理機/vm資源池不滿足，需要向資源同學緊急提物理機需求，資源同學協(xié)調(diào)到機器后，我們需要人工對機器環(huán)境/網(wǎng)絡(luò)重新初始化，然后執(zhí)行上述1操作。待活動結(jié)束后機器閑置，易造成成本浪費。

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

容器化過程記錄

我們的容器化上云到現(xiàn)在為止可以分為三步：容器化，穩(wěn)定性提升和利用率提升。

容器化

這里的容器化映射到業(yè)務(wù)上來說，除了將服務(wù)載體由物理機遷移到容器上，更主要是將原來的復雜邏輯解耦，微服務(wù)化。

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

穩(wěn)定性提升

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

1.調(diào)用量波動較大的服務(wù)由于頻繁擴縮容導致業(yè)務(wù)失敗

2.一些客戶傳的大圖在低核容器上處理效率較低

3.集群資源緊缺導致的容器無法按需擴容等。

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

靈活使用探針

起初我們的服務(wù)都是沒有設(shè)置存活和就緒檢測（探針[2]）的，Prestop給縮容時加上了一層保護，但是并不徹底，而且在擴容時難免會有服務(wù)失敗。

探針給我們提供了另一種強大的解決方式。一開始時，我們參照鏈接中的示例，進行簡單的端口檢查來判斷服務(wù)是否正常運行。后來我們發(fā)現(xiàn)了更多靈活的運用技巧和使用場景。以下列出幾個例子供大家參考以及發(fā)散出更多有趣實踐。

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

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

例子3：某個服務(wù)比較特殊，內(nèi)存占用經(jīng)常波動，當內(nèi)存小于某個值時，服務(wù)會偶現(xiàn)失敗，但是端口正常存活。這時我們可以使用ConfigMap+python腳本來進行一些復雜的檢測：

針對大圖進行篩選適配

容器化后，我們發(fā)現(xiàn)某個算法在接收到高分辨率圖片時，服務(wù)成功率會出現(xiàn)波動，原因是算法在對提特征時會出現(xiàn)更多的消耗，這一現(xiàn)象在物理機上部署時被物理機核數(shù)多的優(yōu)勢掩蓋住了，一旦到了核數(shù)較低的容器上就顯露了出來。為了解決這個問題，我們在上層邏輯中新增了大圖篩選功能（如下圖所示），如果檢測到是大圖，則走回物理機集群（由于初始時TKEx提供最高規(guī)格容器核數(shù)為8核，后來才擴充支持了24核及以上），如果是一般圖片，則走容器集群。

多集群部署

在使用TKEx時，我們經(jīng)常會碰到部署的workload會因為整體集群資源不足的原因，無法擴容到指定的max值，一度非?？鄲?。

TKEx的同學也是推薦我們在其他的集群復制一份資源，當一個集群擴不出來時，另一個集群充當備份角色。在這么調(diào)整過后，我們的擴容成功率逐步上升。

后來又出現(xiàn)了整個地域的資源都比較緊缺的情況，于是我們把一些對時延不那么敏感的服務(wù)進行了多地域部署（如下圖），最終將集群資源不足的風險進一步降低。

當一地資源不足的情況下使用多地域部署以及LB時，一般LB都會根據(jù)后端響應時間動態(tài)調(diào)整各節(jié)點權(quán)重，所以我們應注意以下兩點：

關(guān)閉就近訪問

根據(jù)上下游調(diào)整LB權(quán)重（比如上游服務(wù)部署在廣州，下游同時部署了南京和廣州，這是南京和廣州的LB權(quán)重分別為130，100）

利用率提升

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

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

成果

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

參考資料

[1]人臉融合:【https://cloud.tencent.com/product/facefusion】

[2]探針:【https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/】