印度遊戲平臺Dream11如何伸縮擴充套件他們的遊戲中臺？

banq發表於2021-08-22
遊戲套件

獲得騰訊投資的Dream11平臺可以讓使用者建立由真實玩家組成的虛擬團隊，並允許他們根據實際遊戲中玩家的資料表現來組織比賽。獲獎者將獲得積分獎勵，每場比賽都有參賽費。該平臺提供夢幻板球、足球、卡巴迪和NBA的比賽：
對於 1 億 Dream11 使用者來說，在我們的平臺上玩夢幻體育的刺激和興奮是無與倫比的。他們喜歡建立自己的團隊並與其他粉絲和朋友競爭！但是，從後端的角度來看，我們在 Dream11 的流量和參與度變化方面面臨著各種挑戰，主要是在比賽開始時間之前。為了確保應用程式在使用者流量高的關鍵時刻順利執行，作為一個團隊，我們提出了一個可擴充套件和可定製的解決方案。因此，我們能夠同時執行多場比賽，每秒高效處理數百萬個使用者請求，而不會影響他們玩夢幻體育的體驗。
我們如何管理 Dream11 平臺上這種在短時間內劇烈波動的流量變化？

印度遊戲平臺Dream11如何伸縮擴充套件他們的遊戲中臺？
架構支援：

  • 超過1億的使用者群
  • 使用者併發超過550萬
  • 邊緣服務的每分鐘請求數 (RPM) 超過 1 億
  • 超過 30K+ 的計算資源來支援峰值 IPL 流量
  • 超過 100 多個並行執行的微服務

一旦使用者開啟 Dream11 應用程式，他們的旅程通常會在主頁、巡迴賽、團隊和比賽頁面之間來回切換。因此，應用程式的負載會發生變化，相應地，邊緣層、其依賴服務和微服務必須擴充套件或擴充套件。
有趣的是，使用者併發性可能會在事件之間或比賽之後上升或下降，並且根據每年使用者的增長來預測它可能具有挑戰性。
讓我們還考慮在比賽前、比賽中和比賽後在平臺上產生尖峰的不受控制的變數。這些是，
  • 使用者興趣取決於比賽和球員在現實生活中的受歡迎程度，這會影響 RPM 的大小。
  • 特定於比賽的事件，例如拋球、小隊公告、由使用者釋出小隊公告的團隊建立，以及中間時段的事件，例如小門倒下、擊中六分球、帽子戲法、突圍事件和其他不可預測的因素（例如下雨）。

 

自動擴充套件為何不起作用？
就基礎設施而言，自動縮放有幾個限制。它的配置時間不夠快，無法在關鍵事件期間支援使用者的計算需求！海嘯流量期間的大量使用者需要較短的配置時間來跟上峰值，並且可能不適合有構建時間並讓使用者等待。

  • 節點的現貨Spot 可用性有限且競爭激烈——尤其是在關鍵時間！
  • 如果要考慮 Dream11 的規模，此時步進Step縮放也可能不起作用，因為它僅限於一定數量的節點
  • 基於資源的可用性重新平衡或重新安排跨可用區 (AZ) 的節點數量可能會進一步增加與時間有關的供應成本。

傳統應用程式負載均衡器 (CLB/ALB) 的限制
  • 根據吞吐量建立負載均衡器分片，因為負載均衡器上生成的請求數量有限制。為了基於使用者併發性獲得更高的吞吐量，需要建立分片並根據服務路由對其進行管理。
  • 必須對 ELB 進行預熱以應對突然的流量激增。

雲控制平面（雲提供商）的限制
  • 此外，我們的雲提供商的功能也有限制。應用程式介面 (API) 呼叫率因業務而異，在分配資源時需要考慮這一點
  • 由於供應的資源數量眾多，控制檯操作很繁重。
  • 擴充套件到 100 多個微服務的運營開銷。

  

解決方案：預測 - 主動擴充套件

  • 我們自產的併發預測模型

我們在 Dream11 的資料科學團隊在嘗試了具有 100 個特徵的多個模型後，開發了一個使用 XGboost 模式預測使用者併發的模型，以預測 Dream11 平臺上的每小時併發。
我們首先透過一個線性模型執行每個匹配的後設資料，該模型給出匹配的層級。比賽等級是比賽受歡迎程度的指標變數。
然後根據相似匹配的過去併發對匹配層進行分類（按高併發或最需要的優先）。
然後模型迭代多個特徵來預測特定匹配的併發性。這些可以是每小時的特徵，例如該小時（及其周圍的小時）按層級匹配的數量、前幾小時/天的活躍使用者、平均交易規模等。所有這些資料都經過標準化處理，可以照顧到Dream11 的指數增長。
最重要的是，我們需要一個合適的成本敏感的損失函式，沒有預測不足的選項。總的來說，我們擁有超過 200 個變數和比資料科學更多的資料藝術性，使得 XGBoost 模型可以在非常有限的超引數調整下工作。
正如我們的資料科學團隊所相信的，“錯誤分析 >>>> 超引數調整”。
  • 效能測試和遊戲日

根據提供併發估計的預測模型，效能團隊舉行“比賽日”以基準基礎設施容量以及基於過去比賽的分解趨勢。
使用的效能測試框架是Torque
基礎設施配置框架：Playground（觀看此空間瞭解更多資訊）
使用 Playground 配置基礎設施和Torque來執行效能測試，效能團隊根據使用者併發預測對業務功能的以下改進進行了認證。
  • 效能指標和驗證：

  1. 定義應用延遲——為業務服務的可接受延遲
  2. 識別個人服務能力
  3. 基準計算和網路吞吐量
  4. 識別應用程式的故障和飽和點
  5. 產生突然的尖峰和浪湧以識別對後端基礎設施的影響並識別架構中的級聯效應
  6. 測試基礎設施邊界，包括計算、網路、API 限制和操作。

  • 部署最佳化以減少配置時間

  1. 完全烘焙的 Amazon 機器映像 (AMI)，用於使用應用程式工件進行部署以實現更快的擴充套件
  2. 跨可用區配置多種計算例項型別（多樣化），減少容量挑戰
  3. Spot 例項的容量最佳化分配策略
  4. 成本最佳化確保 100% 資源在現場執行
  5. 在現場不可用的情況下通知失敗並啟用按需供應。
  6. 加權域名系統 (DNS) 記錄以支援 ELB 分片。

  • 使用 Scaler 縮放關鍵時間

  1. Dream11 的 DevOps 和 SRE 團隊精心設計了一個平臺“Scaler”，它有助於根據併發預測和效能基準進行主動擴充套件。
  2. 基於與預測的併發性和趨勢相關的效能測試，系統被輸入不同的使用者併發塊和各自的基礎設施，以在比賽前、比賽中和比賽後跨微服務提供。

 

未來工作範圍
隨著架構的成熟，我們正在研究容器和資料儲存的預測性和計劃性擴充套件。我們還希望最佳化我們的基礎設施成本並實時擴充套件我們在 Dream11 平臺上看到的峰值。為實現這一目標，我們正在尋找有才華的工程師，他們熱衷於大規模解決基礎設施問題併為 Dream11 使用者提供出色的產品。
 

相關文章