Now in REALITY Tech #9 今後とりくむ技術課題

2021年9月2日 11:16

前回の記事で「ガチャ2万は爆死に入らない！」と社内のガチ勢に怒られました、漫喫です。

毎週担当者をローテーションしてREALITYの最新技術トピックをお届けする「Now in REALITY Tech」ですが、今回はちょっと未来にやる予定のことを書こうと思います。
「まだ仕様すら決まってないのにやるって言って大丈夫かよ...」と社内でザワザワすると思いますが、チームの優秀なエンジニアが全部達成してくれるはずなので全く心配しておりません！

1. アバター描画の軽量化

REALITYは今後2-3年かけてメタバースを開発していかなければなりません。どうやってメタバースを作っていくかは秘密ですが(というか絶賛議論中)、どんなものを作るにしても絶対解決しないといけない問題があります・・・。

それは「REALITYのアバター、高品質すぎる問題」です！

REALITYの良いところと言えば、アバターがとにかく可愛いことですが、より可愛くみせるために、12万ポリゴンの3Dモデルと90個の揺れものの使いながら、フェイストラッキングで表情を変えながら描画しております。(※数値はアバターによります)

これの何が問題かと言うと、メタバースなんだからアバターいっぱい出したいよね！ということが今のままだと実現できないのです。

ということでこのプロジェクトでは、たくさんのアバターを描画すべく負荷の軽減を頑張るプロジェクトです。

2. サーバーのマルチリージョン化

海底ケーブルって知ってますか？
世界中のアバター配信がいつでも楽しめるのも全てインターネットのおかげですが、海の底にあるケーブルを光の速度で情報が行き来するという物理的な仕組みを知ってましたか？
僕は大学のときに知ってかなり衝撃だったのを覚えてるので、意外と知名度低いのではと思ったり。

上の図が今存在する海底ケーブルを可視化した図なんすが、海底ケーブルの長さの合計は地球30周分なんですって！海の底に張り巡らせたケーブルのどこかがサメにかじられるだけで通信できなくなるんですって！
ロマンありませんか！？

脱線しました。。。

REALITYは現在日本のサーバーしかないため、例えばアメリカのユーザー同士がコラボで会話するとこうなります↓

↑無駄無駄ァ！！！こうでしょ↓

ということをやっていくプロジェクトになります。日本以外のサーバーも用意するということです。これによって配信時の遅延を減らすことができ、会話がよりスムーズにできるようになります。もちろん日本のユーザーと国外のユーザーがコラボする際は引き続き海底ケーブルを越えてもらう必要がありますが、多くのユーザーさんは同じ地域の方の配信を楽しんでいるので、その際に日本サーバーを経由しなくなるのはとても合理的ですよね。

3. 不正ユーザーの検出と制限

ありがたいことにREALITYはサービスとして順調に成長しており、ユーザーが増えた一方で悪いことをする方もチラホラ出てくるようになりました。具体的にどんなことがあったかは言いづらいのですが、不正利用の事例が新しくでる度に、どのユーザーが不正を行っているのかを調査し、その行為を制限するための対策を個別でする必要があります。

「REALITYも大きくなったな…」なんて言いながらサーバーエンジニアが個別対応していますが、今後も新たな事例が増えることは明らかですし、開発のリソースをそこに費やすのは非常に悔しいです。。。
我々は楽しんで使っているユーザーに価値を提供するために時間を使いたいのです！！

ということでこのプロジェクトは、できるだけ多くの不正利用を汎用的に検出/制限するための機能を作るのが目的となります。すごい曖昧なのでもう少し説明すると、ユーザーからのAPIの叩かれ方を色んな視点で監視し、不正な使われ方を検出したらAPIの利用に制限をかけることができる仕組みを検討しております。

4. Protocol Buffers対応

速いは正義！
過去の記事でも高速化のために色々と努力していることをご紹介しました。
(コレとかアレとかソレとか...)

下の図はとあるAPIの処理時間のProfiler情報ですが、Unmarshal(GoのJSONをデシリアライズ)が処理のほとんどを占めているのが分かります。

これは極端な例ですが(サイズが大きいとこうなる)、JSONではなくProtocol Buffersのバイナリフォーマットにすることによって処理時間と通信時間を減らすことがこのプロジェクトの目的です。もちろんメッセージ内容に大きく依存しますが、JSONとProtocol Buffersで比較してパース速度が10倍、通信サイズが1/4程度に抑えられたりします。

また、処理時間と通信時間だけを目的とするならMessagePackなどの選択肢もあり得ますが、Protocol Buffersのスキーマを定義できる特徴によって開発効率を上げられるはずと社内で検討していたこともあり、通信頻度が高いAPIに関してはProtocol Buffersに対応しようという結論になりました。

年内に終わるのか問題

上記の4つの課題は今年中に成果を出そうと現在計画進行中ですが、これ以外にも開発することがたくさんありすぎて、今年中に終わらせられるかが最近の僕の悩みです。。。

あー猫の手も借りたい。。。

ということで猫よりはエンジニアリングできるぞ！って方はぜひこちらのフォームから応募待ってます！！