印度游戲平臺Dream11如何伸縮擴展游戲中臺的？
獲得騰訊投資的Dream11平臺可以讓用戶創建由真實玩家組成的虛擬團隊，并允許他們根據實際游戲中玩家的數據表現來組織比賽。獲獎者將獲得積分獎勵，每場比賽都有參賽費。該平臺提供夢幻板球、足球、卡巴迪和NBA的比賽：
對于 1 億 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來運行性能測試，性能團隊根據用戶并發預測對業務功能的以下改進進行了認證。
- 性能指標和驗證：
- 定義應用延遲——為業務服務的可接受延遲
- 識別個人服務能力
- 基準計算和網絡吞吐量
- 識別應用程序的故障和飽和點
- 產生突然的尖峰和浪涌以識別對后端基礎設施的影響并識別架構中的級聯效應
- 測試基礎設施邊界，包括計算、網絡、API 限制和操作。
- 部署優化以減少配置時間
- 完全烘焙的 Amazon 機器映像 (AMI)，用于使用應用程序工件進行部署以實現更快的擴展
- 跨可用區配置多種計算實例類型（多樣化），減少容量挑戰
- Spot 實例的容量優化分配策略
- 成本優化確保 100% 資源在現場運行
- 在現場不可用的情況下通知失敗并啟用按需供應。
- 加權域名系統 (DNS) 記錄以支持 ELB 分片。
- 使用 Scaler 縮放關鍵時間
- Dream11 的 DevOps 和 SRE 團隊精心設計了一個平臺“Scaler”，它有助于根據并發預測和性能基準進行主動擴展。
- 基于與預測的并發性和趨勢相關的性能測試，系統被輸入不同的用戶并發塊和各自的基礎設施，以在比賽前、比賽中和比賽后跨微服務提供。
未來工作范圍
隨著架構的成熟，我們正在研究容器和數據存儲的預測性和計劃性擴展。我們還希望優化我們的基礎設施成本并實時擴展我們在 Dream11 平臺上看到的峰值。為實現這一目標，我們正在尋找有才華的工程師，他們熱衷于大規模解決基礎設施問題并為 Dream11 用戶提供出色的產品。
