虛擬節點輕鬆應對 LOL S11 百萬併發流量——騰競體育的彈性容器實踐

騰訊雲原生發表於2021-12-07

作者

劉如夢,騰競體育研發工程師,擅長高併發、微服務治理、DevOps,主要負責電競服務平臺架構設計和基礎設施建設。

詹雪嬌,騰訊雲彈性容器服務EKS產品經理,主要負責 EKS 虛擬節點、容器例項相關的產品策劃。

業務介紹

自 2019 年,騰競整個電競賽事資料服務完全由騰訊雲 TKE 容器服務承載。騰競賽事資料開放平臺目前主要提供職業賽事資料的授權與查詢,隨著鬥魚、虎牙、企鵝、掌盟、微信直播、微博等平臺的相繼接入,平臺整體流量有了爆發式的增長。

此前 2021英雄聯盟全球總決賽(以下簡稱 S11) 期間更是創下了平臺流量新高,達到了百萬級 QPS、百億級呼叫量。面對電競賽事此類週期性強、併發高的業務場景,有效快速的自動擴縮容、提升資源利用率,是滿足業務高速發展、合理控制成本的關鍵所在。

這裡將介紹 LOL S11 賽事期間,騰競賽事資料開放平臺如何透過  虛擬節點彈性排程+VPC-CNI 架構,輕鬆應對爆發的百萬流量。

業務特性

電競賽事具備明顯的業務特性,其對服務的自動伸縮能力有非常高的要求。

  • 週期性

電競賽事具有明顯的週期性,比賽時段是流量高峰期,其餘時間流量驟減,流量相差數百倍,需要透過彈性擴縮能力,減少波谷時的冗餘資源,降低成本。

  • 高併發

比賽期間,服務需要承載百萬級 QPS,需要快速的擴容時間、及庫存充足的資源池。

  • 突增快

    比賽開始時,玩家開始大量湧入直播間,需要保證服務穩定性,避免突增流量過大引發叢集雪崩。

架構介紹

整體架構

叢集採用 Istio 作為服務網格框架進行微服務治理,流量經由多條 CLB(解決單條 CLB 頻寬上限)進入 Istio Ingress(直連Pod)後進行流量分發,依託於 Istio 的 Sidecar 模式,能夠對各服務之間進行非常精細化的流量管理,例如:灰度、限流、熔斷等等。

undefined

普通節點+虛擬節點

開啟 VPC-CNI 採用直連 Pod 模式後,叢集不再受 NodePort 網路轉發能力的限制,少量常規節點應對業務日常低負載場景,利用虛擬節點彈性擴縮容能力應對賽事期間業務超高負載場景。

undefined

DevOps

基於 Docker 的 CI/CD 服務,支援多環境(雲端、本地)、多叢集編排服務,滿足業務的不同部署需求。

undefined

彈性擴容方案演變

基於上述的業務特性,針對彈性擴容的方案,經歷了【手動擴容=>節點池=>虛擬節點】的一系列演變歷程,目前的彈性擴容方案可以完美滿足業務需求。

業務初期:手動擴容

業務初期,負載較低,根據業務特徵,手動擴縮容基本可以滿足需求。

由於手動擴縮容需要一定的時間視窗,因此需要放置一定數量的冗餘資源應對突增流量,資源利用率較低,只有6%左右。

業務發展中:節點池

隨著業務發展,週期性的高低峰流量特徵愈發明顯,面對高頻的擴縮容需求時,手動擴縮容不僅人力成本較高,而且無法避免人為失誤。

在突增流量速度較慢的場景下,節點池可以較好滿足業務需求,不過需配置伺服器,擴容速度較慢,冗餘資源仍存在,資源利用率較低。另外,縮容時對節點進行封鎖、驅逐等操作,不利於服務的穩定性。

業務高速發展:虛擬節點,秒級擴容,節省30%成本

業務高速發展階段,高低峰流量相差懸殊、併發逐漸增高、突增流量時間達到秒級,節點池的擴容速度不足以滿足業務需求,還有購置伺服器時庫存不足的風險。

虛擬節點是 TKE 提供的一種彈性排程能力,提供了近乎無限資源的擴容能力,可以直接將 Pod 排程至彈性容器服務 EKS 維護的雲上資源中,無需擴容節點。相比節點池,虛擬節點的擴容、縮容流程簡化了購買、初始化、退還伺服器的流程,大大提升了彈性的速度,儘可能降低在擴容流程中可能出現的失敗,使得彈性更快、更高效、更節省成本。

在彈性效率層面,虛擬節點可在數十秒內啟動數以百計的 Pod,能夠很好的應對 S11 這類高爆發業務場景。在成本層面,避免了普通節點由於無法完美分配 Pod 申請的資源而產生的 buffer 資源,節省了資源成本。

在此基礎上,我們結合業務側資料,採取自動化資源預熱的方式應對高頻的突增流量場景;運營類業務場景則需要和運營部門緊密結合做好手動擴容的準備。

網路轉發方案最佳化

存在的問題

叢集提供公網訪問入口時,預設情況下外部流量經由叢集節點 NodePort 轉發至叢集內部,當虛擬節點中部署的 Pod 數量較少,叢集整體負載較低時,該模式不會有網路轉發效能瓶頸。不過隨著部署在虛擬節點中的Pod數量增大,叢集整體負載升高,就需要新增更多的節點用於網路轉發,這與自動伸縮、快速擴容、降低成本的目標背道而 馳。

undefined

最佳化方案

開啟 VPC-CNI 後採用直連 Pod 模式,容器與節點分佈在同一網路平面,每個 Pod 分配有固定 IP,網路直接由 CLB 轉入 Istio Ingress,不再經由 NodePort 轉發,提高了網路轉發效率,叢集也不在需要網路轉發節點,大大提高了叢集的擴容能力。該模式下,叢集擴容上限受到叢集所分配網段可用 IP 數的限制,因此需要提前做好規劃,避免叢集擴容受限。

undefined

最終效果

透過虛擬節點和 VPC-CNI 模式下直連 Pod 的結合,目前叢集整體承載能力有了很大的提升,在成本控制方面也有了長足的進步。

秒級擴縮容

透過虛擬節點+K8s HPA 能力, 叢集可在數十秒內啟動數以百計的承載百萬級流量的Pod,可以輕鬆應對快速擴縮容需求。再結合業務側資料,自動化進行資源預熱,提升叢集抗突增流量能力。縮容時也不再需要對節點進行封鎖、驅逐等操作,提高了服務的穩定性。

百萬承載

VPC-CNI 直連 Pod 解決了 NodePort 流量轉發瓶頸的問題,加上虛擬節點近乎無限資源的擴容能力大大提高了叢集水平擴容的上限,像騰競賽事資料開放平臺這樣大量讀的場景能 輕鬆擴容至百萬乃至千萬級 QPS

降低成本

虛擬節點的高效擴縮容,配合 K8s 的 HPA 自動伸縮機制,減少了資源的準備和閒置時間,避免普通節點中的碎片化資源問題,有效的提高了資源利用率,最終 為業務節省了30%的成本

參考文件

容器服務 TKE: https://cloud.tencent.com/document/product/457/6759


虛擬節點概述: https://cloud.tencent.com/document/product/457/53027


彈性叢集: https://cloud.tencent.com/document/product/457/39804


VPC-CNI 模式介紹: https://cloud.tencent.com/document/product/457/50355

關於我們

更多關於雲原生的案例和知識,可關注同名【騰訊雲原生】公眾號~

福利:

①公眾號後臺回覆【手冊】,可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~

②公眾號後臺回覆【系列】,可獲得《15個系列100+篇超實用雲原生原創乾貨合集》,包含Kubernetes 降本增效、K8s 效能最佳化實踐、最佳實踐等系列。

③公眾號後臺回覆【白皮書】,可獲得《騰訊雲容器安全白皮書》&《降本之源-雲原生成本管理白皮書v1.0》


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69984638/viewspace-2846149/,如需轉載,請註明出處,否則將追究法律責任。

相關文章