Robloxが1日2兆件のアナリティクスイベントを達成するまでの道のり

毎日、平均9,780万人のユーザー*がRobloxを訪れ、コミュニケーションを取り、創作し、共にプレイしています。これらのインタラクションにより、合計で2ペタバイトの分析イベントデータが生成されています。新しいスケーラブルな取り込みシステムのおかげで、私たちは最近、大きなマイルストーンを達成しました。現在、当社のシステムは1日あたり2兆件以上のイベントを処理しています。このシステムは、Robloxプラットフォームを支えるパーソナライゼーション、安全性、および経済性に関するアルゴリズムを可能にしています。

以前は、クラウドキューサービスがRobloxで生成された分析データを「events_hourly」と呼ばれる単一の論理テーブルに取り込んでいました。このテーブルは、日付、時間、およびweb、mobile、friendServiceなどの任意に定義されたタグによってパーティション化されていました。 当社のデータサイエンティストとエンジニアは、特定のイベントを専用のテーブルに抽出するためにスケジュールされたバッチジョブに依存していました。新しい分析イベントの作成と送信には、事前のスキーマ定義が不要でした。エンジニアは、抽出・変換・ロード（ETL）パイプラインの段階において、下流のテーブルスキーマを自ら制御していました。

この構成は柔軟性があり、エンジニアが迅速に対応できるものでしたが、課題も生じました。 

• イベントの量が増えるにつれ、日付、時間、タグだけでパーティション分けされた 2 兆行ものデータとのやり取りは、ますます非効率になっていきました。
• events_hourly テーブルでは 1 日の終わりに 6 時間の遅延が生じ、events_daily では 24 時間の遅延が生じるため、データパイプラインがブロックされる期間が生じました。 
• データセットレベルの権限、階層、保存期間、アラートの管理は、より複雑になりました。 
• イベントのドキュメント、履歴、所有権が欠落しており、データの有用性とトレーサビリティが低下していました。 
• クラウドキューサービスで構築された取り込みインフラストラクチャでは、23 Gbps のクラウド取り込みコストが発生していました。

従来のデータ分析では、多数のバッチパイプラインを介して単一の論理テーブルからデータを抽出する必要がありました。これは大規模で高性能なクエリを実行するために不可欠でしたが、同時に処理速度を低下させる要因にもなっていました。インジェストバックエンドサービスを使用してこれらのイベントを専用のテーブルにルーティングすることで、分析イベントにスキーマを付与し、宛先テーブルを事前に定義できるため、バッチ抽出パイプラインを排除できます。 

Robloxでは、分析イベントのスキーマ言語としてProtobuf（proto）を採用しました。protoとgRPCは当社が優先的に採用しているサービス構築フレームワークであるため、これは自然な選択でした。さらに、protoはカスタムオプションの定義に優れたサポートを提供しており、これを活用して、所有権、保持期間、生産性ソフトウェアチャネル、イベントスキーマなどの追加メタデータを収集しています。 

スキーマ言語を選択した後、スキーマが更新された際に何が起こるか、またどのような更新を許可すべきかを検討しました。公開されたスキーマを利用する下流の消費者を最大限にサポートするため、データチームはSchema Registryで説明されている「後方推移モード」を採用しました。このアプローチでは、フィールドの追加およびソフト削除が許可されます。これにより、下流の消費者との調整を必要とせずにスキーマの変更が可能になります。 

上記の例では、protoファイルを更新することでフィールドの追加や削除を行うことができます。

スキーマには多くの利点がありますが、事前にスキーマを必須とすることは作業の妨げとなります。データサイエンティストやエンジニアは、障害なく迅速に動き、反復作業を行う必要があります。これを支援するため、私たちは一元化されたスキーマリポジトリを導入し、スキーマの作成を可能な限り自動化・効率化するための一連のツールを構築しました。 

例えば、各スキーマに必要なメタデータが含まれており、Robloxの規約に準拠していることを検証するためのカスタムProtoリンターを構築しました。 また、イベントスキーマをHiveデータ定義言語に変換するProtoプラグインも構築しました。これにより、スキーマの作成や更新が行われるたびに、対応するHiveテーブルが常に同期された状態を維持できます。これらのツールはすべてCI/CDパイプラインに統合されており、プルリクエストが作成されると自動的に実行されます。これにより、エンジニアはスキーマの問題を早期に発見し、スキーマがマージされる前にテスト用Hiveテーブルでイベントを検証できるようになります。その結果、本番環境へのスキーマデプロイは、マージを行うのと同じくらい簡単になりました。 

開発者体験が合理化されたことを受け、インジェストパイプラインのどの段階でイベントをスキーマ化してProtoに変換すべきかを検討しました。イベントプロデューサーに対し、シリアライズされたProtoバイトを採用して送信するよう求めることは、複数のチームにまたがる大きな変更となります。課題に対処し、段階的に価値を提供するため、インジェストバックエンドサービスを更新して受信イベントをProtoに変換するようにし、スキーマ化の作業をイベントプロデューサーから切り離しました。 現在、変換されたイベントはParquetファイルに集約され、分散ストレージにアップロードされた後、個別のHiveテーブルとして登録されます。

次に、アナリティクスイベントの配信にかかるコストに焦点を当てました。以前は、データ取り込みのバックエンドはクラウドインフラストラクチャ上に構築されていました。 アナリティクスイベントはキューサービスに送信され、そこでバッファリングされた後、下流の処理や分析のために耐久性のあるクラウドストレージに保存されていました。クラウドキューサービスはサービスを簡素化し、透過的なスケーリングを可能にしてくれましたが、他のストリーミングジョブからの利用が難しく、コストも高くなっていました。この課題に対処するため、インジェストサービスをRobloxのデータセンター内に移行することを検討しました。 

当社の内部ストレージチームは、オープンソースの分散型イベントストリーミングプラットフォームをベースにした「Queue-as-a-Service（QaaS）」を構築していました。QaaSは、イベントが先入れ先出し（FIFO）の順序で処理され、短い保持期間後に削除されるため、アナリティクスイベントの取り込みに最適な代替手段となります。 Robloxでは、スキーマ化されたイベントごとに専用のトピックを作成し、パーティション数を調整することで大規模なイベントストリームに対応しています。また、データチームはQaaSからデータを取得し、Parquetファイルを生成して、耐久性のあるクラウドストレージにアップロードするための専用サービスも構築しました。

QaaSの導入と、Parquetファイルの生成・保存を行う専用サービスの構築により、データチームは6か月間にわたりシャドウライトを実施し、データの正確性とスケーラビリティの両方を検証しました。最終的に、徹底的なデータの完全性および整合性チェックを経て、旧来のクラウドキューサービスからの分析用イベント取り込みの移行に成功しました。これは大きなマイルストーンとなりました。 これにより、取り込みパスからクラウドリソースのコストを排除し、イベントの発生からデータレイクへの到達までのレイテンシを大幅に短縮しました。以前は3時間を目標とするサービスレベル契約（SLA）を設けていましたが、これを頻繁に下回っていました。現在では、平均15分という目標を安定して達成しています。 

これにより、エンジニアはQaaSからデータを取得し、スキーマ化されたイベントに対してリアルタイムのイベント処理パイプラインを構築することで、セキュリティ機能やリアルタイムのレコメンデーション機能を実現できます。また、同じスキーマ化フレームワークとQaaSによるデータ取り込みを活用した変更データキャプチャ（CDC）も導入し、データベースのフルダンプを大幅に削減しました。リアルタイム分析やイベントストリーミングから新たなユースケースの開拓に至るまで、私たちは革新を続け、大規模かつスマートで高速、かつコスト効率の高いデータシステムを構築し続けています。 

本プロジェクトへの多大な貢献に対し、Paul Mou氏に感謝申し上げます。

^{* 2025年3月31日終了の3ヶ月間時点。}