成本降低40%、資源利用率提高20%的AI應(yīng)用產(chǎn)品云原生容器化之路,ai云平臺解決方案-ESG跨境

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

AI應(yīng)用云原生容器化降低40%成本，提高20%資源利用率的方法

簡介

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

背景和問題

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

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

1.采集質(zhì)量不穩(wěn)定:由于采集設(shè)備的差異，采集的質(zhì)量也會有所不同。以圖像處理為例，大圖像和小圖像會給我們的服務(wù)帶來不同的壓力，有時服務(wù)會因為集中大圖像而失敗。

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

3.模型和服務(wù)的快速迭代:AI SaaS服務(wù)的競爭非常激烈，客戶經(jīng)常會提出新的要求。另外算法上難免會有badcase，所以我們的服務(wù)也不得不頻繁升級迭代。

讓我們來看看容器化之前我們的簡化架構(gòu)(如上圖所示)。在物理機(jī)開發(fā)部署的背景下，我們的邏輯服務(wù)無論是結(jié)構(gòu)還是基礎(chǔ)都屬于大泥球模式。此外，算法服務(wù)往往良莠不齊。

這種架構(gòu)也導(dǎo)致繁忙的服務(wù)之間頻繁的資源搶奪，影響服務(wù)成功率和耗時，導(dǎo)致我們無法很好的滿足客戶的需求；但是閑暇時間的資源利用率很低，容易造成資源浪費(fèi)。

用兩個實際例子來說明:

當(dāng)升級發(fā)布時，我們需要首先從LB中刪除一個節(jié)點(diǎn)，并觀察在升級服務(wù)之前沒有流量進(jìn)入該節(jié)點(diǎn)。升級完成后，手動測試服務(wù)是否成功，測試結(jié)果OK后再添加回LB。

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

為了更好地滿足客戶的迭代需求，減輕R&D運(yùn)維負(fù)擔(dān)，彌補(bǔ)靈活性，接入高效的業(yè)務(wù)管控平臺，這是我們迫切需要的。利用公司對云的推廣，我們對架構(gòu)組件進(jìn)行了多輪研究和優(yōu)化。本文主要闡述集裝箱化過程。

集裝箱化過程記錄

到目前為止，我們的容器化云可以分為三步:容器化、穩(wěn)定性提升、利用率提升。

集裝箱化

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

如下圖所示，我們先為服務(wù)本身做了一個瘦身微服務(wù)。此外，借助容器的容量，我們將原來的混合服務(wù)完全分離。如何進(jìn)行微服務(wù)會因服務(wù)不同而有所不同，本文不再贅述。

提高了穩(wěn)定性

在集裝箱化的第一步之后，我們很快享受到了飛行服務(wù)的升級和擴(kuò)張速度。同時，對集裝箱化的簡單理解也給我們帶來了一些新的問題。

1.呼叫量波動的服務(wù)由于頻繁的擴(kuò)展和收縮而失敗。

2.部分客戶大圖在低芯集裝箱上的處理效率較低。

3.由于群集資源不足，容器無法按需擴(kuò)展。

對于以上三個問題，我們也分別找出了解決方法。

靈活使用探針

起初，我們的所有服務(wù)都沒有提供生存和準(zhǔn)備狀態(tài)檢測(probe [2])。Prestop在擴(kuò)容的時候加了一層保護(hù)，但是不徹底，擴(kuò)容的時候服務(wù)失效是必然的。

探測器為我們提供了另一個強(qiáng)有力的解決方案。開始時，我們參考鏈接中的例子，進(jìn)行簡單的端口檢查，以確定服務(wù)是否正常運(yùn)行。后來我們發(fā)現(xiàn)了更靈活的應(yīng)用技巧和場景。下面舉幾個例子供大家參考，還有更有趣的做法。

例1:剛開始的時候，人們經(jīng)常會遇到LB Agent啟動時獲取路線不可避免的失敗。我們可以使用ready探針來預(yù)加載LB(如下圖所示)，這樣可以達(dá)到成功獲取LB后標(biāo)志服務(wù)成功啟動的效果。

例2:由于低版本操作系統(tǒng)的一些實例存在弱密碼問題，我們需要升級所有依賴于舊版本操作系統(tǒng)的映像。這個工作對我們來說是極其繁重的，所以在容器標(biāo)記服務(wù)啟動之前，我們也使用探針殺死所有弱密碼。

例3:某服務(wù)比較特殊，內(nèi)存使用情況波動頻繁。當(dāng)內(nèi)存小于某個值時，服務(wù)偶爾會失敗，但端口會正常存活。這時候我們可以用ConfigMap+python腳本來做一些復(fù)雜的檢測:

篩選和適應(yīng)大圖像

容器化后，我們發(fā)現(xiàn)一個算法在接收高分辨率圖片時服務(wù)成功率會有波動，因為算法在提取特征時會消耗更多。這種現(xiàn)象在物理機(jī)上部署時被物理機(jī)的核多的優(yōu)勢掩蓋了，一旦到了核少的容器就顯露出來了。為了解決這個問題，我們在上層邏輯中加入了大圖過濾的功能(如下圖所示)。如果檢測到是大圖，我們就回到物理機(jī)集群(由于TKEx最初提供的是8核的最高規(guī)格容器，后來擴(kuò)展到支持24核及以上)。如果是一般的圖，我們就去集裝箱集群。

多集群部署

在使用TKEx的時候，我們經(jīng)常會遇到因為整個集群資源不足，導(dǎo)致部署的工作負(fù)載無法擴(kuò)展到指定的max值，一度非常苦惱。

TKEx的同學(xué)也推薦我們在其他集群復(fù)制一個資源。當(dāng)一個群集無法擴(kuò)展時，另一個群集將充當(dāng)備份。經(jīng)過這次調(diào)整，我們的擴(kuò)張成功率逐漸提高。

后來整個地區(qū)出現(xiàn)資源短缺，我們就在多個地區(qū)部署了一些對延時不那么敏感的服務(wù)(如下圖)，最終進(jìn)一步降低了集群資源短缺的風(fēng)險。

在一個地方資源不足的情況下使用多區(qū)域部署和LB時，LB一般會根據(jù)后端響應(yīng)時間動態(tài)調(diào)整各個節(jié)點(diǎn)的權(quán)重，所以要注意以下兩點(diǎn):

近距離訪問

根據(jù)上下游調(diào)整LB權(quán)重(比如上游業(yè)務(wù)部署在廣州，下游業(yè)務(wù)同時部署在南京和廣州，意味著南京和廣州的LB權(quán)重分別為130，100)

提高利用率

經(jīng)過一輪穩(wěn)定性的提升，我們可以更加自信的利用我們的靈活性，利用率得到了顯著的提升。然而，還有兩個問題阻礙了我們的進(jìn)一步利用。一個是有些服務(wù)模型大，啟動慢，在流量突然增加的情況下，服務(wù)不能及時擴(kuò)展。這時候就得提前占用一些資源，導(dǎo)致利用率達(dá)不到。

針對第一個問題，我們選取了一些有固定流量的服務(wù)。利用TKE提供的定時HPA能力，在已知流量高峰前定期進(jìn)行一輪擴(kuò)容。

結(jié)果

目前我們的AI服務(wù)已經(jīng)基本完成了容器化升級。成功率高，擴(kuò)展快，歡迎掃碼體驗。

參考數(shù)據(jù)

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

[2]探測器:[https://kubernetes . io/docs/tasks/configurepodcontainer/configurelivenessreadinessstartupprobes/]

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。