記録的な体験を支えるインフラ

Robloxが、数百万ものユニークな体験を通じて数千万人のユーザーが同時にプレイできるスケールとサポートを実現できたのは、単一のイノベーションによるものではありません。それは、広範なイノベーション文化と、社内で徹底的に行われてきた無数の細かな取り組みの総和なのです。こうして私たちは、現在Roblox上の多くの体験で記録的なトラフィックを支えているインフラを構築してきました。 その体験の一つである『Grow a Garden』は、最近、2,160万人のユーザーが同時にプレイし、ギネス世界記録®の「同時接続者数最多のビデオゲーム」を達成しました。その過程で、Robloxプラットフォームは（過去20年近くにわたりそうであったように）新たな同時接続者数のピーク記録を更新し続け、最近では3,000万人を超えました。

Robloxは、「Dress to Impress」、「Adopt Me」、「Dead Rails」など、クリエイターが制作した数百万もの体験のためのインフラを構築・維持する上で独自の課題に直面しており、革新的なエンジニアリング手法が求められています。 同プラットフォームは、予期せぬトラフィックの急増時にも拡張可能なインフラにより、毎時数十回のアップデートと3,000万人以上の同時接続ユーザーを支えています。このインフラは、2,100万人以上のユーザーが単一の体験に同時に参加する「サンダーリング・ハード（Thundering Herd）」と呼ばれる状況にも対応しなければなりません（なお、このアップデートコードは独立したクリエイターによって提供されたものです）。Robloxのエンジニアたちは、従来の常識に挑むことで革新的なソリューションを生み出しており、そのソリューションは当社の4つのコアバリューにインスパイアされたものです。

理想を言えば、クリエイターはキャパシティについて一切考える必要がないはずです。インフラは彼らには見えない形で、裏方で機能しているべきだからです。クリエイターがRobloxに体験を公開する際、私たちの役割は、どれだけ多くのプレイヤーが参加しようとも、必要なキャパシティを確保することです。 初期の頃は、1～2年先を見据えて年1回、キャパシティを計画していました。しかし近年、『Dress to Impress』、『Fisch』、『Dead Rails』、『Grow a Garden』といった成功した体験の登場により、キャパシティ計画の枠組みを見直すことになりました。

「長期的な視点を持つ」という当社の価値観に基づき、現在は最大2年先までの容量需要を予測し、ユーザーの需要とサーバーの効率的な稼働率のバランスを取っています。当社の計画サイクルには、データセンターの取得、サーバーハードウェアの更新、物理的なネットワーク構築が含まれており、ブラジルのような新しいデータセンターは数年先を見据えて計画されています。また、ネットワークチームは、ネットワークケーブルの切断などの問題が発生しても継続的な運用を確保できるよう、「ダーク」容量を維持しています。

Robloxが現在保有する容量は、2年前に策定された予測に基づいています。当時は、体験コンテンツが数週間のうちに無名から爆発的な人気を博すようになるとは予想できませんでした。 2025年4月の1,390万人から6月には3,060万人へと、Robloxのピーク同時接続者数を倍増させる一因となった『Dress to Impress』や『Grow a Garden』といった人気ゲームは、こうした容量予測が行われた時点では存在していませんでした。例えば、2025年3月には『Dead Rails』が100万人の同時接続者数を記録し、利用可能なCPU容量をすべて使い切りました。 

こうした人気急上昇の事例から学び、私たちはよりアジャイルな計画サイクルへと移行しました。Robloxにおける記録的なプレイヤー数を安定してサポートするため、エンジニアリングチームは計画、テスト、容量調整からなる厳格な週次サイクルを採用しています。月曜日はインシデントのレビューに充てられ、火曜日は容量計画を行います。週を通して継続的なカオステストが実施されます。木曜日は、クリエイターから予告されている大規模なアップデートに向けた容量の確認に重点を置きます。 金曜日には、週末のピーク利用に備えて追加のクラウドリソースをプロビジョニングします。週を通して、私たちは全く新しい機能をリリースし続けており、全エンジニアによる継続的デプロイメントを制限することはありません。 

スロットリングは、コンピュータサイエンスにおいて広く受け入れられている概念です。しかし、これはコンピュータサイエンスにおいて最も誤用され、誤解されている手段でもあります。Robloxに新しいエンジニアが入社すると、彼らの最初の解決策には往々にして、「クリエイターにこの設定を調整するよう指示したり、イベントの実行速度を落とすよう頼めれば…」といった内容が含まれます。すると、Robloxのベテランエンジニアたちは、コミュニティを尊重するという当社の価値観や、クリエイターに何をすべきかを指示しないという方針を、丁寧に説明します。 

例えば、多くのゲームシステムでは、数百万人のプレイヤーが同時に「プレイ」をクリックした際のマッチメイキングに対して、単純な解決策を採用しています。参加をスロットリングしたり、プレイヤーを待機させたり、あるいはマッチメイキングアルゴリズムをスキップしてランダムなサーバーに振り分けたりするのです。Robloxでは、その逆の方法を採っています。私たちは、殺到する膨大な数のプレイヤーに対応できるよう、マッチメイキングシステム全体を再設計しました。ピーク時には、このシステムは1秒あたり最大40億通りの参加組み合わせを評価します。 数年前、私たちは「10秒間で1,000万回の接続」という目標を掲げ、その達成に向けて改良を続けています。

容量不足による制限を回避するため、セルラーインフラへの移行の一環としてクラウドバーストを実験しており、これにより動的で計算効率の高いスケーリングが可能になります。このアーキテクチャは、ユーザーをオンプレミスとクラウドのエッジデータセンターセルの両方にマッチングさせることで、ピーク時の需要に対応します。 現在、マッチングアルゴリズム向けに完全に抽象化されたクラウドベースのエッジデータセンターの、完全自動化された立ち上げと撤収の実現に向けて取り組んでいます。

もう一つの例が、ピーク時には毎秒25万件のリクエストを処理するテキストフィルタリングシステムです。これは、絶えず拡大するコンテキストウィンドウで25万トークンを処理する大規模なモデル推論です。また、本番環境で300以上のAI推論パイプラインが稼働しているため、Robloxのサービスオーナーは、GPUとCPU間の推論プロファイルの最適な組み合わせを見つけるために多くの時間を費やしています。 ピーク時の負荷下であっても、Robloxのエンジニアはクリエイターの自由とユーザーの安全を最優先し、コミュニティを尊重しています。

計画に基づき、クリエイターによる最もエキサイティングな更新をサポートするための処理能力とアルゴリズムを構築しています。しかし、これらのシステムが、最大級のトラフィックピークや単一のサービス障害にも耐えられることを確実にしなければなりません。1,600以上のマイクロサービスにおけるピーク時の利用状況から収集した情報は、さらなるストレステストを行うべきサービスを特定するのに役立ちます。

「物事を成し遂げる」という私たちの価値観に忠実に、毎日いくつかのサービスを選び、本番環境での容量を意図的に制限しています。その挙動を観察し、週末までに修正を行います。私たちはこれを「TACO（Test Actual Capacity On）火曜日」と呼んでいます。 また、信頼性チームは「継続的キャパシティ・コレクティネス（C3）」も実施しています。各エンジニアリングチームはC3ダッシュボードを使用して、自チームのサービスのCPUキャパシティを予測・管理します。これにより、サービスオーナーは前回のピークから継続的に学び、次のピークに向けてキャパシティを増減させることができます。さらに、新リリースに向けたRobloxコアエンジンの呼び出しパターンを追跡するシステムも導入しました。これにより、アップデート時の準備をより万全なものにしています。 

こうした万全の準備を講じているにもかかわらず、トラフィックパターンの予測不可能性により、単一のサービスやプロダクトフローがプラットフォーム全体をダウンさせるような事態に、時折直面することがあります。例えば、人気のあるアップデートにより、2兆件のイベント分析パイプラインのトラフィックが30%増加する可能性があります。このような状況では、適応型同時実行制御（ACC）、サーキットブレーカー、リトライの抑制といったレジリエンスメカニズムが作動し、プラットフォームを保護します。 また今年、本番環境においてランダムに障害を注入したり、リソースを枯渇させたり、プロセスをランダムに終了させたりすることで、インフラの耐障害性とスケーラビリティを強化するためのカオステストプラットフォームを構築しました。

私たちは週末の大型アップデートに向けて、一週間かけてテストと準備に追われています。しかし、週末になってもまだやるべきことは残っています。週末のアップデートに先立ち、Robloxのエンジニアたちは協力して今後の変更点を監視し、残りの処理能力を予測します。そして、仮想エッジデータセンターを通じて数百万人の追加プレイヤーに対応できるよう、必要に応じてクラウドリソースを追加で確保します。 

金曜日には、クラウドリソースによる追加容量の確保が必要かどうかを判断します。このプロセスにより、ハイブリッドクラウドチームは、数百万人の追加プレイヤーに対応するための十分な余剰容量を確保するという明確な指針を得ることができます。 24か所の物理エッジデータセンターは常に稼働していますが、すべてのテストを終えた後、追加のエッジデータセンターが必要だと判断する場合もあります。12時間でサーバーをラックに設置して積み上げることは不可能なため、クラウドパートナーと協力して複数の仮想エッジデータセンターを構築します。金曜日にそれらをテストし、週末に備えます。 

責任を果たすという真の精神に基づき、最高経営陣を含む全員が、週末であっても当番制で待機しています。土曜日に数百万人のユーザーが殺到すると、しばしば数百件ものアラートが発生します。各チームはこれらのアラートを未然に解決することで、大規模なアップデートやプラットフォーム全体での過去最高トラフィック時における課題に対処できるようにしています。 

レオナルド・ダ・ヴィンチが語ったとされる言葉に、「学びは決して心を疲れさせない」というものがあります。こうしたピークのたびに、私たちはインフラをより信頼性が高く、かつ目に見えないものにするための新たな技術を学び、生み出すインスピレーションを得てきました。クリエイターがコンテンツを公開または更新すると、目に見えないインフラの魔法によって、数千万人のユーザーがほぼ即座に全く新しい体験を楽しみ始めます。コンピュータサイエンスの限界を押し広げるよう私たちに挑戦し続けてくれるクリエイターとユーザーの皆様に、私たちは心から感謝しています。