Robloxの大規模マルチプレイヤーゲーム環境では、ユーザーがデータを読み書きする量と速度が、従来のキャッシュパターンを機能不全に陥らせるほどです。 静的データをキャッシュする標準的なウェブページでは、ユーザーは200ミリ秒の遅延に気づかないかもしれませんが、Robloxにおいてインタラクションデータやサーバーメタデータを取得する際の200ミリ秒の遅延は、ゲームプレイを停滞させ、シミュレートされたゲームの世界を混乱させる可能性があります。Robloxは、没入感を維持するためにミリ秒単位で取得しなければならない、予測不能で高速かつ一時的なデータからなるエコシステム上で動作しています。 

当社のキャッシュ層は、数百万人の同時接続ユーザーと永続ストレージの間に位置する巨大なショックアブソーバーとして機能するように設計されています。この層は、秒間13億8000万クエリ（QPS）というピーク負荷に対応し、単一の論理クラスターでも1億QPSを超える処理能力を発揮します。 本記事では、最大クラスターで前例のない10倍のトラフィック急増に対応しつつ、Redis®ノードの制限を超えてスケーリングし、膨大なスループットを実現するために、フェデレーテッド・キャッシング・サービスをどのように設計したかについて、その舞台裏をご紹介します。

業界の限界を超えたスケーリングで、増え続ける需要に応える

Robloxでは、キャッシュサービスはRedis®テクノロジーを基盤として構築されており、1つのRedis®クラスターは最大1,000ノードをサポートする可能性があります。しかし、実証上および業界で認められている限界値は、それよりはるかに低く、約400～500ノード程度です。¹ これは、Redis®の分散型Gossipプロトコルが、ノード間の通信を利用してヘルス状態、ステータス、およびシャードマッピングを共有するためです。 数百ノードを超えるクラスターでは、Gossipプロトコルによる通信がCPUやネットワークリソースを大幅に消費し始めます。各ノードは、増え続けるピアからのステータス更新を処理しなければならず、その結果、低遅延でデータを提供するという本来の業務からリソースが奪われてしまいます。このコントロールプレーンのオーバーヘッドは、システムの不安定化や予測不能なパフォーマンスを引き起こす可能性があるため、マネージドクラウドプロバイダーはノード数に制限を設けています。これは、信頼性を損なうことなく超えることのできない現実的な上限なのです。

しかし、この実用的な単一クラスタの制限では、Robloxのような規模で稼働するプラットフォームを支えるには不十分です。Robloxでは、最大のバックエンドサービスがピーク時に1つの論理Redis®クラスタに対して1億QPS以上を要求しており、これは3ヶ月前までの1,000万QPSから急増したものです。

このアーキテクチャ上の制約を克服するため、当社はフェデレーテッド・アーキテクチャを採用し、複数の小規模で独立したRedis®クラスタの前にクライアント・リバースプロキシを配置しました。予測可能なパフォーマンスを確保するため、クラスタあたり400ノードという制限を設けています。 

数千に及ぶアプリケーションやサービスの観点から見ると、クライアントリバースプロキシは、これらの分散したクラスターを単一で統一されたスケーラブルなキャッシュサービスとして提示します。このフェデレーションにより、Gossipプロトコルの制約を完全に回避し、単にフェデレーションにクラスターを追加するだけで、ほぼ無制限に水平スケーリングを行うことが可能になります。 現在、当社の最大規模の単一キャッシュ環境は6,000ノード以上のRedis®で構成されており、これらは15以上の独立したRedis®クラスタによって支えられています。このような規模は、このフェデレーションモデルによってのみ実現可能です。

3段階の移行プロセス

数百もの稼働中の本番クラスタを管理しながら、従来の構成からフェデレーテッドアーキテクチャへ移行することは、非常に大きな取り組みでした。2024年末時点で、これらのクラスタの多くはすでに400ノードという上限に近づいており、より大容量なモデルへの移行が急務となっていました。主な課題は、標準的なRedis®インスタンスが独立して動作し、他のクラスタを認識する機能を持たないため、移行中にデータをレプリケートするための独自の方法が必要だったことです。

この問題を解決するため、当社は、顧客の関与やアプリケーション側の変更を一切必要とせずにサービスを移行できるよう設計された、透過的な3段階の移行パイプラインを開発しました。

移行ワークフロー

1. デュアル書き込み：クライアントリバースプロキシを構成し、デュアル書き込みを実行させ、着信データを元のクラスタと新しいフェデレーテッド先の両方に同時に送信しました。
2. パリティと読み取りの切り替え：デュアル書き込みプロセスによって新しいクラスタに同一のデータが格納されると、すべてのデータには有効期限（TTL）が設定されているため、読み取りトラフィックをレガシークラスタから新しいフェデレーテッドアーキテクチャに移行しました。
3. 廃止：新しいクラスタの安定性を確認した後、元のクラスタへのすべての書き込み操作を停止し、そのクラスタを廃止しました。

これにより、最も重要なサービスを、単一の Redis® クラスタの限界をはるかに超える 6,000 ノード以上をサポートするフェデレーションモデルへ移行することに成功しました。 

Grow a Gardenの爆発的な成長への対応

2025年4月以降、我々は他のサービスではめったに遭遇しないほどの規模のキャパシティ課題に直面しました。その引き金となったのは、『Grow a Garden』の驚異的な成功でした。リリースからわずか数週間で、『Grow a Garden』はRobloxの記録だけでなく、同時接続ユーザー数（CCU）におけるゲーム業界の歴代記録をも塗り替え始めました。 わずか3ヶ月で、このゲームのユーザー数は、これまでの単一ゲームにおけるCCU記録である280万人を突破し、ピーク時には2,100万人以上に達しました。この爆発的な成長により、最大のRedis®クラスターへのトラフィックは10倍に、キャッシュシステム全体へのトラフィックは3倍に増加しました。

Robloxでは、自社データセンター内の物理サーバー上でキャッシュシステムを運用していますが、この前例のない成長は、当社の長期的なキャパシティ計画には含まれていませんでした。この急激なトラフィックの波を乗り切り、プラットフォームの安定性を維持するためには、信頼性を最優先しつつ、既存のサーバー群の効率を劇的に向上させる必要がありました。 

急増時の効率化

まず、最適化作業の優先順位を決定するため、システム内で最も影響の大きいボトルネックを特定する必要がありました。Roblox Cachingは、Redis®バックエンドノード用とEnvoy用の2つの異なるハードウェアプール上で稼働しています。当社のRedis®フリートは主にメモリ制約型であるのに対し、クライアントプロキシは演算処理制約型です。 

メモリ制約のあるRedis®フリートについては、物理マシングループ間でメモリ使用率のバランスをより適切に保つため、新しいスケジューリングポリシーを実装しました。また、メモリの断片化を軽減するためにコンテナサイズを微調整しました。 

CPU利用率を向上させるため、キャッシュシステムに対して以下の2つの主要な最適化を実施しました：

1. クライアントプロキシのオートスケーリング：計算リソースに制約のあるクライアントプロキシフリートに対し、オートスケーリングポリシーを調整しました。目標CPU値からの許容偏差を狭めることで、スケールアップのしきい値を変更することなく、ジョブの平均CPU使用率を向上させました。
2. 内部クラスタヘルスチェック：不要なハートビートを排除するために内部ヘルスチェックを最適化し、元の検出間隔を維持しつつ、計算リソースを節約しました。

これらの変更により、CPU利用率は約10%向上しました。最後に、cgroupによるコンテナレベルの分離を活用し、これら2つの全く異なるワークロードを同一のマシンプールに共置することで、全体的な容量要件を25%削減しました。

揺るぎない信頼性を実現するエンジニアリング

記録的な需要に対応するために全力を尽くしていた時期でも、信頼性は依然として最優先事項でした。 

エンドツーエンドの可観測性

まず、キャッシュシステムの包括的なエンドツーエンドのヘルスモニタリングを行うため、可観測性スタックに多額の投資を行い、潜在的な障害の把握に注力しました。リクエストのライフサイクル全体にわたってサーバー側の成功とクライアント側の障害を追跡することで、問題を迅速に検出して診断し、多くの場合、ユーザーへの影響を未然に防ぐことができました。 例えば、ホットキー検出機能を追加しました。これは、ライブトラフィックをサンプリングして、過度にアクセスされ、キャッシュ層に負荷をかけているデータを特定するものです。システムがホットキーを検知すると、サーバー側とクライアント側の両方で、これらのキーへのトラフィックをプロアクティブに制限し、システムの過負荷を防ぐことができます。

障害対応

この規模の分散システムでは、部分的な障害が発生することがあります。私たちは、こうした障害を適切に処理し、その影響を最小限に抑えるようシステムを設計しました。

• バッチリクエストにおける部分的な障害：バッチリクエストでの部分的な障害に対処できるよう、システムを再設計しました。以前は、シャード化されたバッチリクエスト内で1つのリクエストが失敗すると、バッチ全体が失敗していました。現在では、一部のキーの取得に失敗しても、リクエスト全体は成功するようになっています。
• ヘッド・オブ・ライン・ブロッキングの緩和：キャッシュシステムには高速性が求められます。わずかなネットワークの遅延でもリクエストが蓄積し、タイムアウトに至る現象（ヘッド・オブ・ライン・ブロッキング）が発生する可能性があります。単一の遅いリクエストが他のリクエストに影響を与えないよう、クライアント層とプロキシ層の両方に、インテリジェントなリトライメカニズムと接続プール戦略を実装しました。
• 障害および遅延の注入：耐障害性をテストするため、当社の障害注入フレームワークを使用して、本番環境に制御された障害（ノードの停止、ラックの停止、ネットワーク遅延、APIエラー）を定期的に注入しています。これらの条件下でのシステムの挙動を分析することで、弱点を事前に特定・修正し、継続的な信頼性を確保しています。

クライアント側の耐障害性

トラフィックの急激な増加によってキャッシュシステムが過負荷になるのを防ぐため、堅牢なクライアント側の障害耐性を実装しました。このメカニズムはアプリケーションレベルで動作し、単一のサービスがキャッシュリソースを独占できないようにします。

• フロー制御のためのレート制限：クライアントには送信トラフィックの総量に制限が設けられており、バックエンドサービスが処理可能な量を超えるリクエストが送信されないようになっています。この制限を超えた場合、リクエストはスロットリングされ、サービスが過負荷になるのを防ぎます。
• 再試行およびタイムアウト機構：当社のクライアントライブラリでは、タイムアウトや再試行予算など、慎重に調整された再試行機構を採用し、「サンダーリング・ハード（Thundering Herd）」現象を防いでいます。これにより、影響範囲を限定し、リソースを解放するとともに、無期限のハングや同時再試行によるシステムの過負荷を防止することで、システム全体の応答性を向上させています。

Robloxのキャッシュの未来

Robloxのキャッシュ導入の道のりは、各アプリケーション所有者が直接管理するベアメタルRedis®クラスタから始まり、その後、当社のキャッシュチームが管理するMemcachedクラスタへと移行し、最終的にはRedis®クラスタがマネージドサービスとして提供されるRedis®-as-a-serviceモデルへと移行しました。 このモデルは現在のスケールにおいて極めて有効であることが証明されていますが、Roblox のようなダイナミックなプラットフォームにおいては、サービスの効率性やリソースの分離という点で限界があることも認識しています。

プラットフォームの成長に伴い、当社はValKeyを基盤とした次世代のマルチテナント型キャッシュサービスに多額の投資を行う予定です。このアーキテクチャは、マルチテナント方式を通じて共通リソースを共有することでコストを大幅に削減しつつ、各テナントのデータ、リソース、および障害の分離を確保するように設計されています。私たちの目標は、Roblox上でますます大規模化する体験の需要に応えるため、キャッシュインフラのパフォーマンス、スケーラビリティ、信頼性、およびコスト効率を大幅に向上させることです。

謝辞： 

この成果はチーム一丸となって成し遂げたものです。多大な貢献をしてくれたチームメンバー、Utkarsh Singh、Karthick Ramachandran、Vineesha Kasireddy、Weiji Hu、Leon Gaoに感謝します。