支援創紀錄遊戲體驗的基礎架構

Roblox 有能力擴展，並支援上億名使用者一同在數百萬種獨特的體驗中玩遊戲，絕非單靠某一創新方式而成。 平台仰賴更廣泛的創新文化，以及認真做好公司內部的每一件小事。 這就是我們打造基礎架構的方式，目前這個基礎架構正為 Roblox 上打破流量紀錄的眾多體驗提供支援。 其中一項體驗 Grow a Garden，最近打破了最多玩家同時上線玩電玩遊戲的 金氏世界紀錄®，共計 2,160 萬名使用者同時上線玩遊戲。 Roblox 平台在此過程中持續刷新同時上線人數紀錄（近二十年來始終如此），最近的紀錄是超過 3,000 萬名玩家同時上線。

Roblox 為數百萬個由創作者打造的遊戲體驗建立與維護基礎架構時，面臨獨一無二的挑戰，其中包括 Dress to Impress、 Adopt Me 和 Dead Rails，這些體驗都需要創新的工程方法。 藉由在異常流量激增時擴充基礎架構，平台支援每小時更新數十次，並支援超過 3,000 萬名並行使用者。 此基礎架構必須支援驚群現象，亦即支援超過 2,100 萬名使用者同時加入單一體驗（且更新代碼來自獨立創作者）。 Roblox 工程師挑戰傳統智慧尋求創新解決方案，靈感來自我們的四個核心價值觀。

Roblox 工程師管理全球 24 個邊緣資料中心，這些資料中心負責執行遊戲伺服器。 使用者加入遊戲體驗時，系統會將他們匹配到最近的資料中心及中心內最合適的執行個體，盡量減少延遲情況。 我們還管理兩個規模更大的核心資料中心，執行集中式服務如網站、推薦演算法、安全篩選器、虛擬經濟和發佈平台，這些都是邊緣資料中心運作所需。 全球私人網路將所有邊緣資料中心與核心資料中心相互連結，邊緣資料中心作為防火牆，保護核心資料中心所執行的服務。

在理想世界中，我們的創作者無須考量容量問題，基礎架構對他們來說理應隱身在幕後運作。 創作者將遊戲體驗發佈到 Roblox 時，無論有多少玩家出現，我們的工作就是支援所需容量。 我們早期每年會針對未來一年或兩年規劃一次容量。 不過近年來，大受歡迎的遊戲體驗如 Dress to Impress、 Fisch、 Dead Rails 和 Grow a Garden，讓我們重新思考容量規劃的架構。

懷抱著保持遠見的價值觀，我們目前最多提前兩年預測容量需求，希冀在使用者需求與高效伺服器使用率之間取得平衡。 我們的規劃週期涵蓋資料中心收購、伺服器硬體更新與實體網路，並提前多年規劃新的資料中心，例如位於巴西的資料中心。 網路團隊也維護著「暗」容量預備資源，以確保網路線路發生中斷等問題時，仍能持續運作。

Roblox 目前的容量是根據兩年前所預測，當時我們無法預測數款遊戲體驗會在幾週內從無名小卒迅速竄紅。 預測容量當時，Grow a Garden 和 Dress to Impress 等熱門遊戲尚不存在，這些遊戲的同時上線玩家人數從 2025 年 4 月的 1,390 萬人飆升到 6 月的 3,060 萬人，增加了一倍以上。 舉例來說，在 2025 年 3 月，Dead Rails 的同時上線使用者激增至 100 萬人，用盡所有可用的 CPU 容量。

以這些爆紅類型遊戲體驗為師，我們轉而規劃更為靈活的週期。 為了持續支援 Roblox 上的玩家人數紀錄，工程團隊採用嚴格的每週規劃、測試及容量調整週期。 星期一專門用來審查事件，接著星期二則是進行容量規劃。 在一整週中，我們持續進行混沌測試。 星期四的工作重點是審查容量，以因應創作者事前預告即將推出的任何重大更新。 星期五則佈建額外的雲端資源，確保平台對於週末尖峰使用量做好萬全準備。 在一整週中，我們繼續發佈全新功能，並且不會限制所有工程師持續部署。

節流是電腦科學中非常普遍的概念， 卻也是電腦科學中最常遭到誤用和誤解的觀點。 新進工程師加入 Roblox 時，第一個解決方案通常包括：「如果我們能請創作者調整這項設定，或是放慢活動速度…」。 資深的 Roblox 工程師會耐心解釋公司尊重社群的價值觀，而不是告訴創作者該怎麼做。

舉例來說，數百萬玩家同時點擊開始遊戲時，大多數遊戲系統都有一個簡單的配對解決方案。 他們會限制加入的人數，讓玩家等待、跳過配對演算法將玩家送到隨機伺服器。 Roblox 則是反其道而行。 我們為大批同時湧入的玩家重新設計了整套配對系統。 在尖峰時段，這套系統每秒最多可評估 40 億個可能的加入組合。 多年前，我們設定了 10 秒內 1,000 萬人加入的目標，並持續朝著這個目標邁進。

為了避免因容量而受到節流限制，我們正嘗試雲端爆量，作為我們轉移到蜂巢式基礎架構的一步，以實現動態且運算效率高的擴充。 此架構會將使用者同時配對內部部署及雲端邊緣資料中心的運算單元，藉此處理尖峰需求。 我們正在努力建置全自動化啟動與關閉的雲端邊緣資料中心，完全抽象化設計便於進行配對演算法。

另一個範例則是我們的文字篩選系統，尖峰時段每秒可處理 250,000 個要求。 這個大型模型推論可以執行 25 萬個權杖，並且不斷擴展環境視窗。 加上操作環境中執行超過 300 個 AI 推論管道，Roblox 服務擁有者花費許多時間尋找 GPU 和 CPU 之間的理想推論設定檔組合。 即使在尖峰負載的情況下，Roblox 工程師為了尊重社群，也會優先考量創作者自由度與使用者安全性。

透過規劃，我們逐步加強容量與演算法，以期支援創作者最精彩的更新。 但我們必須確保這些系統時刻維持運作，即便處於最高峰或單一服務中斷的情況下亦然。 從 1,600 多個微服務的尖峰使用量中收集的資訊，有助於識別服務，以進一步進行壓力測試。

本著具體實踐的價值觀，我們每天都會挑選其中幾項服務，並限制操作容量。 我們觀察特性，並趕在週末前修正問題。 我們稱之為「星期二測試實際容量」(TACO)。 我們的可靠性團隊也會執行持續容量校正 (C3)。 每個工程團隊都會使用 C3 儀表板來預測和管理服務的 CPU 容量。 服務擁有者因此能夠不斷從上一個尖峰學習，以增加或減少下一個尖峰的容量。 我們也推出了一套系統，可追蹤 Roblox 核心引擎中新版本的呼叫模式。 這有助確保我們在更新期間做好更充分的準備。

即使有了萬全準備，我們偶爾仍會遇到流量模式的不可預測性，可能因單一服務或產品流程而導致平台當機的情況。 舉例來說，由於熱門更新的緣故，2 兆個事件分析管道可能會增加 30%。 此時便是我們的復原機制派上用場的時候，例如適應並行控制 (ACC)、斷路器和棄置重試便會開始啟動，以保護平台。 今年我們也建立了一個混沌測試平台，透過隨機注入故障、耗盡資源和隨機終止操作流程，進而強化基礎架構的彈性和可擴展性。

我們花了一整週的時間進行測試，並準備週末的大型更新。 但到了週末，我們還有工作要做。 在週末更新之前，Roblox 工程師攜手合作監控即將發生的變化，並預測剩餘的容量，根據需要佈建額外的雲端資源，透過虛擬邊緣資料中心容納數百萬名額外的玩家。

到了星期五，我們會決定是否需要透過雲端資源來增加額外容量。 這項流程為我們的混合雲端團隊提供了明確的方向，以提供足夠的額外容量來容納數百萬名額外的玩家。 我們的 24 個實體邊緣資料中心全天候持續運作，但經過所有測試後，我們可能會決定需要額外的邊緣資料中心。 我們無法在 12 小時內架設和堆疊伺服器，因此我們與雲端合作夥伴共同合作，建造多個虛擬邊緣資料中心。 我們在星期五進行測試，然後就可以準備迎接週末了。

本著勇於承擔的精神，每個人（包括我們的最高階主管）都會輪流待命，即使週末也不例外。 星期六當數千萬名使用者湧入時，往往會觸發上百個警示。 團隊會先提前解決這些警示，讓我們能夠在大型更新或平台達到高峰時處理挑戰。

正如達文西常說的：「心靈永遠不會因學習而精疲力竭」。每個高峰都激勵我們學習和發明新技術，讓我們的基礎架構更加可靠和順暢無礙。 我們的創作者會發佈或更新內容，透過無形基礎架構的魔力，數千萬名使用者幾乎即刻就能享受全新體驗。 衷心感謝創作者與使用者，讓我們不斷挑戰電腦科學的極限。