記録的なバーチャル空間へのアクセス数に対応する社内インフラ

ロブロックス（Roblox）が事業規模を拡大し、何百万本ものユニークなバーチャル空間でプレイする何千万人規模のユーザーに対応できるのは、一つのイノベーションの結果ではありません。 それは、幅広いイノベーションを起こす社風と会社全体で行なってきた1000件もの小さな成功の積み重ねのおかげです。 ロブロックス上で多数のバーチャル空間の訪問数が新記録を樹立していますが、これに対応できる社内インフラを構築できたのはそのお陰です。 そのうちの一つのバーチャル空間、 『グロー・ア・ガーデン（Grow a Garden）』は、最近、同じタイミングでプレイしているユーザー数が2,160万人に達し、「同時接続プレイヤー数最多のビデオゲーム」として ギネス世界記録® を達成しました。 その過程で、ロブロックスのプラットフォームは（20年近くにわたり）ピーク時の同時接続数の新記録を更新し続け、直近では同時接続プレイヤー数が3000万人を超えました。

ロブロックスは、 『ドレス・トゥ・インプレス』、 『アダプト・ミー』、 『デッドレール』 を始めとするクリエーターが制作した何百万本ものバーチャル空間に対応した社内インフラを構築・維持するという、革新的なエンジニアリング手法が必要な比類のない課題に直面しています。 当社のプラットフォームは、1時間につき数十回のアップデート回数と3000万人以上の同時接続ユーザーに対応しつつ、予期しない訪問数の急増にも対応できる社内インフラを備えています。 この社内インフラは、2,100万人以上のユーザーが1本のバーチャル空間に同時に押し寄せるような状況に対応させなければなりません（しかも、アップデートのコードは独立したクリエーターが作成したものです）。 ロブロックスのエンジニアは、4つの核心となる当社の理念に触発されて、従来の常識に挑戦することで革新的な解決策を実行しています。

ロブロックスのエンジニアは、世界で24ヶ所のエッジデータセンターを管理し、ゲームサーバーを運営しています。 ユーザーがバーチャル空間に参加すると、最寄りのデータセンターで最適なインスタンスがマッチングされ、待機時間を最小限に抑えます。 また、エッジデータセンターが機能するために必要なウェブサイトやおすすめ機能、アルゴリズム、安全フィルタ、バーチャル経済活動、コンテンツ公開用プラットフォームなどの集中管理型サービスを運営する、より大規模な2ヶ所のコアデータセンターも管理しています。 世界規模のプライベートネットワークがすべてのエッジデータセンターとコアデータセンターを相互接続しており、エッジデータセンターはコアデータセンターで実行されているサービスを保護するファイアウォールの役割を果たしています。

クリエーターが容量を全く気にしないでもいいのが理想的な状況です。インフラはクリエーターの目に触れず、舞台裏で機能するべきです。 クリエーターがロブロックス上でバーチャル空間を公開するとき、当社の仕事は、プレイヤーが何人集まっても対応できる必要な容量を持たせることです。 初期の頃は、年に1回、1～2年先を見据えて容量のプランニングをしていました。 しかし近年では、 『ドレス・トゥ・インプレス』、 『フィッシュ』、 『デッドレール』、 『グロー・ア・ガーデン（Grow a Garden）』 などの成功を受けて、容量のプランニングの枠組みを見直すことになりました。

「長期的な視点を持つ」という当社の理念に沿って、現在では容量に関するニーズを最長2年先まで予測し、ユーザーの需要と効率的なサーバー利用のバランスを取っています。 当社のプランニングサイクルには、データセンターの確保、サーバー用ハードウェアのアップデート、物理的なネットワーク構築が含まれ、ブラジルのデータセンターのような新しいデータセンター創設は、数年先まで計画されています。 また、ネットワークチームは、ネットワークケーブルの断線などの問題が発生しても継続的な運用ができるよう、「余剰」の容量を維持しています。

現在のロブロックスの容量は、2年前の予測に基づいています。当時は、無名の状態から数週間で大人気作品になるバーチャル空間が出てくることを予測できませんでした。 『グロー・ア・ガーデン』や『ドレス・トゥ・インプレス』のような人気ゲームの同時接続プレイヤー数は、2025年4月の1,390万人から6月には3,060万人へと2倍以上に増えましたが、容量予測が行われたときにはこういったバーチャル空間は存在していませんでした。 例えば、2025年3月には、『デッドレール』の同時接続ユーザー数が100万人まで急増し、利用可能なCPU容量をすべて使い切ってしまいました。

当社は、このように爆発的に人気が急上昇した事例で学んだことを活かし、さらに柔軟で迅速なプランニングサイクルを取り入れました。 ロブロックスの記録的なプレイヤー数に継続的に対応するため、エンジニアリング部門では、厳格なプランニング、テスト、容量調整の工程を毎週、実施しています。 月曜日はインシデントレビューに充てられ、火曜日には容量プランニングが行われます。 一週間を通して、継続的にカオステストが実施されます。 木曜日は、クリエーターが計画している大規模アップデートに備えて、容量の見直しに集中します。 金曜日には、週末のピーク利用に備えて追加のクラウドリソースを設定・管理します。 1週間を通じて、全く新しい機能をリリースし続け、エンジニア全員による継続的デプロイができるようにしています。

「スロットリング」（訳注：操作が一定の速度でしか実行できないようにプロセスを減速すること）は、コンピュータサイエンスの分野ではかなり普及している概念です。 しかし、これはコンピュータサイエンスの中で最も誤用され、誤解されている手法です。 新人のエンジニアがロブロックスに入社すると、初期の解決策によく出てくるのが「クリエーターにこの設定を変更させて、イベントの頻度を下げるように言えば......」という発言です。 ベテランのロブロックスエンジニアは、コミュニティを尊重し、クリエーターに指図すべきではないことをやさしく説明するでしょう。

例えば、ほとんどのゲームシステムは何百万人ものプレイヤーが同時に「プレイ」ボタンをクリックした場合のマッチメイキングについて、単純な解決策を用意しています。 マッチメイキングのアルゴリズムを経ずに参加者のスロットリング処理をしたり、プレイヤーを待機させたり、ランダムなサーバーに送ったりします。 ロブロックスでは、真逆の対応をしています。 当社は、大勢のプレイヤーのためにマッチメイキングシステム全体を再設計しました。 ピーク時には、このシステムは1秒間に40億通りの組み合わせを評価します。 何年も前に、当社は10秒間に1,000万回の参加数を目標に設定し、その目標に向かって反復作業を続けています。

容量によるスロットリングを避けるため、 当社は 移動体通信ネットワーク への移行の一環としてクラウドバーストの実験を行っており、計算効率の高い動的な対応規模の拡大が可能になります。 この構造は、ユーザーを自社運用とクラウドエッジの両方のデータセンター施設にマッチングさせることで、ピーク需要に対応します。 当社はマッチメイキング・アルゴリズム用に完全に抽象化されたクラウドベースのエッジデータセンターの立ち上げと撤収の完全自動化を目指しています。

もうひとつの例は、ピーク時には毎秒25万件のリクエストを処理するテキストの伏字処理フィルタシステムです。 これは、常に拡大するコンテキストウィンドウで25万個のトークンを実行する大規模なモデル推論です。 300件以上のAI推論パイプライン が本番稼働しているロブロックスのサービス担当者は、GPUとCPUの理想的な推論プロファイルの組み合わせを見つけるために多大な時間を費やしています。 ピーク時の負荷があるときでも、ロブロックスのエンジニアはクリエーターの自由とユーザーの安全を優先し、コミュニティを尊重しています。

当社のプランニングでは、クリエーターによるエキサイティングなアップデート内容に対応するための容量とアルゴリズムの強化を図っています。 しかし、これらのシステムが最大ピーク時や単一サービスの停止に耐えられることを確認する必要があります。 1,600件以上のマイクロサービスのピーク時の使用から収集された情報は、負荷テストを行うべきサービスを特定するのに役立ちます。

当社の理念である 「物事を成し遂げる 」に沿って、毎日、このサービスのいくつかを取り上げて、本番環境でその能力に制約をかけています 属性を観察し、週末までに修正します。 当社では、これをこれを「火曜日のTACO（実負荷容量テスト）」と呼んでいます。 当社の信頼性チームは、継続的な容量適正化（C3）を実施しています。 各エンジニアリングチームはC3用のダッシュボードを使用して、サービスのCPU容量を予測・管理しています。 これにより、社内のサービス担当者は前のピーク時から継続的に学習し、次のピーク時に向けて容量を増減できようになります。 また、新しいリリース用にロブロックスのコアエンジンの呼び出しパターンを追跡するシステムも立ち上げました。 これにより、アップデートに向けた準備をさらに充実させられるようになりました。

このように準備をしてもアクセス数のパターンは予測不可能なため、単一サービスや製品フローがプラットフォームをダウンさせるというシナリオに遭遇することがあります。 例えば、 2兆件のイベント分析パイプライン では、人気のアップデート内容によってアクセス数が30%増加する可能性があります。 このような場合、適応型同時実行制御（ACC）、サーキットブレーカー、シェディング再試行などの回復メカニズムが働き、プラットフォームを保護します。 また、今年はカオステスト用プラットフォームを構築し、ランダムに障害を注入してリソースを枯渇させ、本番稼動中のプロセスをランダムに終了させることで、インフラの回復力と拡張性を強化しました。

一週間をテストに費やし、週末に行われる大規模アップデートに向けた準備をします。 しかし、週末になってもまだしなければならない作業があります。 週末に行われるアップデートに先立ち、ロブロックスのエンジニアは共同で今後のアップデートを監視し、残りの容量を予測し、仮想エッジデータセンターを通じて数百万人の追加プレイヤーに対応できるよう、必要に応じて追加のクラウドリソースを設定・管理します。

金曜日には、クラウドリソースによる容量追加の必要性を判断します。 この過程では、ハイブリッドクラウドチームに対して、数百万人の追加プレーヤーを収容するのに十分な追加容量を設ける明確な指示を与えます。 どの時点でも24ヶ所の物理的なエッジデータセンターは稼働していますが、テストがすべて終わった後、追加のエッジデータセンターが必要だと判断することもあります。 12時間でサーバーを効率的に配置する（ラック・アンド・スタック）方法はないので、クラウドパートナーと協力して複数の仮想エッジデータセンターを構築します。 金曜日にこれをテストして週末に備えます。

「責任を持つ」という当社の理念に沿って、トップレベルの役員を含む全員が、週末であってもオンコール対応を交代で担当しています。 土曜日に数百万人のユーザーが殺到すると、何百件もの警告が出ることがあります。 チームはこのような警告を先取りして解決することで、大規模なアップデートやプラットフォーム全体で史上最悪の事態が発生した場合でも対応できるようにしています。

レオナルド・ダ・ヴィンチが語ったとされる言葉に「学ぶことは決して心を疲弊させない」というものがあります。私たちはピーク時の体験に毎回、触発されています。インフラの信頼性をさらに高め、気にせずとも機能するものにするための新しい技術を学び、発明してきました。 クリエーターが公開やアップデートを行うと、目に見えないインフラの魔法によって、何千万人ものユーザーがまったく新しいバーチャル空間を瞬時に楽しめるようになります。 当社にコンピュータサイエンスの限界に挑戦するよう後押ししてくれたクリエーターとユーザーの皆さんには、いつまでも感謝します。