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

導(dǎo)語

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

背景和問題

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

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

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

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

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

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

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

以兩個(gè)實(shí)際的例子來說明：

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

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

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

容器化過程記錄

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

容器化

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

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

穩(wěn)定性提升

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

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

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

3.集群資源緊缺導(dǎo)致的容器無法按需擴(kuò)容等。

對(duì)于上述三個(gè)問題，我們也分別找出了應(yīng)對(duì)方案。

靈活使用探針

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

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

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

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

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

針對(duì)大圖進(jìn)行篩選適配

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

多集群部署

在使用TKEx時(shí)，我們經(jīng)常會(huì)碰到部署的workload會(huì)因?yàn)檎w集群資源不足的原因，無法擴(kuò)容到指定的max值，一度非?？鄲馈?/p>

TKEx的同學(xué)也是推薦我們?cè)谄渌募簭?fù)制一份資源，當(dāng)一個(gè)集群擴(kuò)不出來時(shí)，另一個(gè)集群充當(dāng)備份角色。在這么調(diào)整過后，我們的擴(kuò)容成功率逐步上升。

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

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

關(guān)閉就近訪問

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

利用率提升

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

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

成果

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

參考資料

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

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