はじめまして！ambrサーバーサイドチームです！
メタバースのサーバーサイドの紹介記事って少ないですよね。本記事では先日のメタバースイベントから導入しているリアルタイム通信の新しいアーキテクチャについて紹介しております。ウェブサービス業界にいるけどメタバース業界に興味がある方、アーキテクチャの違いについて興味がある方など、ぜひ参考にしていただけたらと思います。
リアルタイム通信サーバーとは
まず始めにリアルタイム通信って何？という方もいらっしゃると思います。メタバースではプレイヤー同士の移動や手の動きといったデータをリアルタイムに同期していく必要があり、それを行うのがリアルタイム通信サーバーです。いわゆるゲームサーバーと呼ばれたり、Photonと呼ばれるエンジンおよびSaaSなどが有名ですね。
多くのユーザーからのアクセスにも耐えながらも高速な通信を実現していく必要があり、アプリケーションレベルでもアーキテクチャレベルでもしっかりと考えて開発していく必要があります。またリアルタイムの同期が不要で永続的に保存するデータについては別途サーバーが用意されており、リアルタイム通信サーバーとは一部分情報のやりとりなどを行っています。
利用技術について
今回利用している主要な技術はMagicOnionというgRPCのフレームワークとNATSというPubSub型メッセージングミドルウェアです。この２つの名前を聞いてピンと来た方もいらっしゃると思いますがその通りです、Cysharpさん、Cygamesさんのアーキテクチャを参考に開発しています。https://github.com/Cysharp/MagicOnionとhttps://github.com/Cysharp/AlterNatsのリポジトリのREADMEに基本的なことが詳細に書かれているのでぜひこちらもご参照ください。
ではなぜこのようなアーキテクチャを採択したのか本題に入っていこうと思います。
なぜMagicOnionを選んだのか
リアルタイム通信のためにクライアント側とサーバー側の両方で処理を書く必要がありますが、双方向な処理を書くとなると開発はどんどん複雑化していきます。そこでMagicOnionを利用することでどちらもC#を使って記述でき、C#のインタフェースの定義をクライアント側サーバー側で共有してそのままRPCとして利用できるため開発がしやすくなります。
さらにブロードキャストの仕組みやそれを制御するためのグループの機能があるため、メタバースにおける同一空間のプレイヤーの通信処理を簡潔に記述することができます。
ambrのクライアントサイドはUnityおよびC#で開発を行っていたため、実際に開発を効率的に進めることができました。またテストなどの関連ツールについても同様にC#で書くことができ、MagicOnionにはテストに便利な機能も備わっているためプロダクトコードだけでなく開発全般的に効果を発揮しました。
なぜNATSを選んだのか
高速なリアルタイム通信のためにクライアントはサーバーとコネクションを張り続ける必要がありますが、ここで問題となるのがスケーリングです。別プレイヤーにデータを送る必要がありますが、別々のインスタンスにコネクションが張られている場合は直接送れないので工夫が必要となります。クラウドがもっとも得意とする水平スケーリングの仕組みが活かしにくいわけです。
一般的には同じグループは同じインスタンスに繋げるように管理する方法とインスタンス間での情報のやりとりできるようにする方法の２つがありますが、ambrでは後者の方法で実装しています。
具体的にはMagicOnionサーバー同士をNATSサーバーを介することで情報のやりとりができるようにし、水平スケーリングでMagicOnionサーバーが増えた場合にもプレイヤー同士で通信をすることを可能としています。さらにNATSそのものもクラスター構成にできるため、こちらも水平スケーリングさせることができます。
特別なコネクションの管理をしなくてもよいので一般的なWebサービスで使われるオーケストレーションサービスをそのまま利用しやすく、インフラやCI/CDの構築についても効率的に開発可能となります。
リアルタイム通信サーバーを作ることで
このようにSaaSなどを利用せずに自前でリアルタイム通信サーバーを用意したことによって受けることができる恩恵がいくつかあります。
１つ目は何よりも最大接続人数を可変にできるところです。アプリケーションレベルおよびインフラレベルで変更することができるので、メタバースのユーザー体験として重要となる同一空間あたりの最大人数もフレキシブルに変更することが可能です。さらに接続先の空間に対してステートレスなので空間の移動も段階的なロジックを必要とせずにこちらもフレキシブルに扱うことが可能です。
２つ目はサーバーサイドでも処理をすることができるというところです。例えば距離によって通信を行わないようにするといったそういった制御をサーバー側でできること、独自のロジックを持たせた別のクラスターを繋げることでインタラクティブな機能を提供できるなど将来的に多くの拡張が可能となります。最近よく話題に上がるAIを利用したインタラクティブな機能などもこのような仕組みに組み込むことができるかもしれませんね。
課題につきましては、当たり前ですが自前実装なのでコードをしっかりと書いていかないといけないこと、インフラの管理をしっかりとやっていけないことですね。特にコード周りはアーキテクチャ面の制御とビジネスロジックのコードが混ざりやすいため注意が必要ですし、インフラ周りは構造上通信量が多くなってしまうので気を付ける必要があります。
最後に
今後もambrではリアルタイム通信サーバーを含めサーバーサイドの開発をどんどん進めていきます。メタバースにおける新しいユーザー体験のためにはクライアントだけでなくサーバーサイドだからできること、サーバーサイドでやるべきことが多くあると思っているからです。
ambrでは採用にも力を入れていますのでVRに興味がある方、メタバースに興味がある方、ぜひご応募お待ちしております！少しでもメタバース界隈の技術に興味を持っていただけたらそれだけでも嬉しいです！
