支撐破紀錄體驗的基礎設施

Roblox 能夠擴展並支援數千萬用戶在數百萬種獨特體驗中共同遊玩，並非源自單一項創新。這是更廣泛的創新文化，以及全公司各處數千件小事都做得很好的總和。這就是我們如何建構出當前基礎設施，以支援 Roblox 上許多體驗所創下的破紀錄流量。 其中一款體驗《Grow a Garden》近期以 2,160 萬名玩家同時在線的成績，打破了金氏世界紀錄®「最多人同時遊玩的電玩遊戲」紀錄。在此過程中，Roblox 平台持續刷新最高同時在線人數紀錄（這已持續近二十年），最近更突破 3,000 萬名同時在線玩家。

在為數百萬個由創作者打造的體驗（包括《Dress to Impress》、《Adopt Me》和《Dead Rails》）建置與維護基礎架構時，Roblox 面臨獨特的挑戰，這需要創新的工程方法。 該平台憑藉能在突發流量高峰時自動擴展的基礎設施，支援每小時數十次更新及超過 3,000 萬名同時在線用戶。這套基礎設施必須能應對「雷霆之群」的極端情境——即超過 2,100 萬名用戶同時加入單一體驗（且更新程式碼來自獨立創作者）。Roblox 工程師透過挑戰傳統智慧來開創解決方案，這些方案皆源自我們的四大核心價值。

在理想情況下，我們的創作者不應需要考慮容量問題——基礎設施對他們而言應是隱形的，默默在幕後運作。當創作者將體驗發佈至 Roblox 時，無論有多少玩家參與，我們的任務就是提供所需的容量支援。 在早期，我們每年僅針對未來一至兩年的需求進行一次容量規劃。但近年來，隨著《Dress to Impress》、《Fisch》、《Dead Rails》和《Grow a Garden》等熱門體驗的成功，促使我們重新審視容量規劃的框架。

秉持著「長遠規劃」的價值觀，我們現在會提前長達兩年預測容量需求，在用戶需求與高效的伺服器利用率之間取得平衡。我們的規劃週期涵蓋資料中心擴建、伺服器硬體更新以及實體網路架構，例如位於巴西的新資料中心便是數年前便已開始規劃。網路團隊同時維持「暗容量」以確保系統運作不中斷，即使遭遇網路線路中斷等突發狀況也能持續運作。

Roblox 目前的容量是基於兩年前的預測所建置的，當時我們無法預見某些體驗能在數週內從默默無聞一躍成為爆紅現象。 諸如《Dress to Impress》和《Grow a Garden》這類熱門遊戲，曾協助將 Roblox 的峰值同時在線玩家數從 2025 年 4 月的 1,390 萬倍增至 6 月的 3,060 萬，但在這些容量預測制定之際，這些遊戲尚未問世。舉例來說，2025 年 3 月，《Dead Rails》的同時在線用戶數飆升至 100 萬，耗盡了所有可用的 CPU 運算能力。 

從這類人氣激增的案例中汲取教訓後，我們已轉向更敏捷的規劃週期。為了持續支援 Roblox 創紀錄的玩家數量，工程團隊採用嚴格的週期性規劃、測試與容量調整流程。週一專門用於事件檢討，週二則進行容量規劃。整個星期都會持續進行混亂測試。週四則專注於檢視創作者預告的任何大型更新所需的容量。 週五會預先配置額外的雲端資源，確保平台能應對週末的使用高峰。整週期間，我們持續推出全新功能，且不會限制所有工程師進行持續部署。 

流量控制是電腦科學中廣為接受的概念。但這卻是電腦科學中最常被誤用且誤解的控制手段。當新工程師加入 Roblox 時，他們的首個解決方案往往包含：「如果我們能告訴創作者調整這個設定，或是放慢他們的事件處理速度……」。資深 Roblox 工程師隨後會溫和地解釋我們尊重社群的價值觀，並說明我們不會告訴創作者該怎麼做。 

舉例來說，當數百萬玩家同時點擊「開始遊玩」時，多數遊戲系統會採取簡單的配對解決方案：限制加入人數、讓玩家等待，或是跳過配對演算法直接將玩家分配至隨機伺服器。但在 Roblox，我們採取截然不同的做法。我們重新設計了整個配對系統，以應對如雷鳴般湧入的玩家群。在高峰時段，此系統每秒可評估多達 40 億種可能的加入組合。 多年前，我們便設定了「10 秒內處理 1,000 萬次連線」的目標，並持續迭代以朝此目標邁進。

為避免因容量限制而實施流量限制，我們正將「雲端爆發（cloud bursting）」技術納入向蜂窩式基礎架構轉型的實驗中，藉此實現動態且運算高效的擴展。此架構透過將用戶同時匹配至本地端與雲端邊緣資料中心的「蜂窩單元」，來處理尖峰需求。 我們正致力於實現雲端邊緣資料中心的全自動部署與撤除，這些資料中心已針對配對演算法進行了完全抽象化。

另一個例子是我們的文字過濾系統，在高峰時段每秒可處理 250,000 次請求。這相當於一個大型模型推論，每秒處理 250,000 個語素，且語境視窗持續擴展。隨著生產環境中運行著超過 300 條 AI 推論管道，Roblox 的服務負責人投入大量時間，致力於在 GPU 與 CPU 之間尋找理想的推論配置組合。 即使在峰值負載下，Roblox 工程師仍秉持對社群的尊重，將創作者自由與使用者安全置於首位。

透過周詳規劃，我們建立起足以支援創作者最精彩更新的系統容量與演算法。但我們必須確保這些系統即使面對最大流量高峰或單一服務中斷，也能穩健運作。從超過 1,600 個微服務的尖峰使用量中蒐集的資訊，有助於識別出需要進行進一步壓力測試的服務。

秉持「務實執行」的核心價值，我們每天會挑選其中幾項服務，並在生產環境中限制其容量。我們觀察相關指標，並在週末前進行修正。我們將此稱為「實際容量測試」（TACO）週二。 我們的可靠性團隊同時執行「持續容量正確性」（C3）機制。各工程團隊透過 C3 儀表板預測並管理其服務的 CPU 容量，讓服務負責人能持續從前次流量高峰中汲取經驗，為下一次高峰調整容量。此外，我們還推出了一套系統，用於追蹤 Roblox 核心引擎在新版本發布時的呼叫模式，藉此確保在更新期間能更周全地做好準備。 

即便經過所有這些準備，我們偶爾仍會遇到因流量模式難以預測，導致單一服務或產品流程便可能使平台癱瘓的情況。例如，由於某項熱門更新，處理 2 兆次事件的分析管道流量可能會增加 30%。此時，我們的韌性機制（如自適應並發控制 (ACC)、斷路器及重試拋棄機制）便會啟動，以保護平台。 今年，我們還建置了一套混沌測試平台，透過在生產環境中隨機注入故障、耗盡資源以及隨機終止程序，來強化基礎架構的韌性與可擴展性。

我們整週都在測試並為這些大型週末更新做準備。但當週末來臨時，我們仍有工作待完成。在週末更新前，Roblox 工程師們會通力合作，監控即將發生的變更並預測剩餘容量，並視需要透過虛擬邊緣資料中心調配額外的雲端資源，以容納數百萬名額外的玩家。 

每週五，我們會決定是否需要透過雲端資源增加額外容量。這個流程為我們的混合雲團隊提供了明確的指引，使其能預先部署足夠的額外容量，以容納數百萬新增玩家。 我們的 24 座實體邊緣資料中心隨時都在運作，但在完成所有測試後，我們可能會決定需要額外的邊緣資料中心。由於不可能在 12 小時內完成伺服器的機架安裝與堆疊，因此我們會與雲端合作夥伴合作，建立多個虛擬邊緣資料中心。我們在週五對其進行測試，然後便準備好迎接週末的挑戰。 

秉持著真正負責任的精神，包括最高層主管在內，全體同仁皆輪流值班——即使在週末也不例外。每逢週六數百萬用戶的湧入，往往會觸發數百則警報。各團隊會預先解決這些警報，使我們能夠在重大更新或平台流量創下歷史新高時，從容應對各項挑戰。 

正如常被歸於列奧納多·達文西的名言：「學習永不耗盡心智。」每次流量高峰都激勵我們學習並發明新技術，使基礎設施更可靠且無形。當創作者發布或更新內容時，透過這無形基礎設施的魔力，數千萬用戶幾乎能立即享受全新的體驗。我們永遠感激創作者與用戶，是你們的挑戰促使我們不斷突破電腦科學的界限。