作者
郭云龍，騰訊云高級工程師，目前就職于 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 服務已經基本完成容器化的升級，成功率高，擴容快，歡迎大家掃碼進行體驗，
關于我們
更多關于云原生的案例和知識，可關注同名【騰訊云原生】公眾號~
福利：公眾號后臺回復【手冊】，可獲得《騰訊云原生路線圖手冊》&《騰訊云原生最佳實踐》~
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/302131.html
標籤：其他