中文字幕亚洲自拍,91天堂视频,在线看污视频

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

2022-05-15

662

成本降低40%、資源利用率提高20%的AI應用產品云原生容器化之路,ai云平臺解決方案AI應用云原生容器化降低40%成本，提高20%資源利用率的方法簡介為了滿足公有云SaaS場景下服務和模型快速迭代交付的需求，保證服務在不穩定、高并發情況下的高成功率，進一步提高資源利用率，AI應用產品中心進行了一系列的調研和實踐。本文......

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

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

簡介

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

背景和問題

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

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

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

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

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

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

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

用兩個實際例子來說明:

當升級發布時，我們需要首先從LB中刪除一個節點，并觀察在升級服務之前沒有流量進入該節點。升級完成后，手動測試服務是否成功，測試結果OK后再添加回LB。

客戶搞活動，提出了高并發的要求。如果當前的物理機/vm資源池不滿足，他們需要緊急向資源同學提出物理機需求。資源同學與機器協調后，我們需要手動重新初始化機器環境/網絡，然后執行上述操作1?；顒咏Y束后機器閑置，很容易浪費成本。

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

集裝箱化過程記錄

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

集裝箱化

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

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

提高了穩定性

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

1.呼叫量波動的服務由于頻繁的擴展和收縮而失敗。

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

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

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

靈活使用探針

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

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

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

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

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

篩選和適應大圖像

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

多集群部署

在使用TKEx的時候，我們經常會遇到因為整個集群資源不足，導致部署的工作負載無法擴展到指定的max值，一度非?？鄲?。

TKEx的同學也推薦我們在其他集群復制一個資源。當一個群集無法擴展時，另一個群集將充當備份。經過這次調整，我們的擴張成功率逐漸提高。

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

在一個地方資源不足的情況下使用多區域部署和LB時，LB一般會根據后端響應時間動態調整各個節點的權重，所以要注意以下兩點:

近距離訪問

根據上下游調整LB權重(比如上游業務部署在廣州，下游業務同時部署在南京和廣州，意味著南京和廣州的LB權重分別為130，100)

提高利用率

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

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

結果

目前我們的AI服務已經基本完成了容器化升級。成功率高，擴展快，歡迎掃碼體驗。