REALITYにおけるビデオ通話のための専用MCUサーバ運用法

REALITYにおけるビデオ通話のための  専用MCUサーバ運用法 REALITY株式会社サーバエンジニア　久山貴大

自己紹介  久山貴大  REALITY株式会社   サーバサイドエンジニア    主な開発領域  バックエンドの開発 
ビデオ通話機能のバックエンドのインフラ構築   2 

アジェンダサービス紹介  ビデオ通話機能  REALITYのリアルタイムコミュニケーション基盤  専用サーバの課題  Agonesとは  全体構成  まとめ  3 

サービス紹介  ビデオ通話機能  REALITYのリアルタイムコミュニケーション基盤  専用サーバの課題  Agonesとは  全体構成  まとめ  4 

スマホひとつでアバター作成、ライブ配信による交流やゲームまで楽しめる  スマホ向けメタバースアプリ  アバター  ライブ配信  コミュニケーション  ゲーム  ワールド  REALITYとは 5 

アバター  ライブ配信  コミュニケーション  ゲーム  ワールド  ビデオ通話機能  8 

ビデオ通話（ビデオチャット）機能  • 機能概要  ◦ アバターでリアルタイムにビデオ通話  ◦ 通話枠ごとの最大同時参加人数は8人    • 内部設計 
◦ 配信機能で使われていた、既存の  リアルタイムコミュニケーション基盤  をベースにしている  10 

コラボ配信機能  REALITYに元々配信機能の１つとして、  コラボ配信という  「複数の人で一緒に配信をする」機能がある  12 

コラボ配信機能  開発工数節約のため  ビデオ通話機能はこのコラボ配信機能を元にして作成した  13 

GKE  コラボ配信機能でのサーバ構造  14  アプリ  アプリケーションサーバ層  リアルタイム通信サーバ層  WebAPI   Server  WebSocket
  Server  HTTP通信  WebSocket通信  コラボ配信では、アプリは  • WebAPI Server   • WebSocket Server  の２つのサーバに接続する 

コラボ配信機能でのサーバ構造  15  アプリケーションサーバ層  WebAPI   Server  WebSocket   Server  HTTP通信 
WebSocket通信  WebAPI ServerはHTTP通信を行い、  通話開始処理やWebSocket Serverの  エンドポイント払い出しを行う  リアルタイム通信サーバ層  アプリ  GKE 

HTTP通信  アプリケーションサーバ層  WebAPI   Server  コラボ配信機能でのサーバ構造  16  WebSocket   Server 
WebSocket通信  アプリ  WebSocket ServerはWebSocket通信を行い、  アバターモーションや音声などの  リアルタイム性が求められるデータの  やりとりを行う  リアルタイム通信サーバ層  GKE 

コラボ配信機能でのサーバ構造  17  アプリケーションサーバ層  WebAPI   Server  WebSocket   Server  HTTP通信 
WebSocket通信  これらのサーバは全て  Google Kubernetes Engine(GKE)上で  動いている  アプリ  GKE  リアルタイム通信サーバ層 

WebSocket通信  モバイル端末で動くアプリのため、  WebSocket通信では可能な限り低遅延・低通信量を目指す必要がある    そのため、サーバや配信者側で動画データを生成するのではなく、  アバターのモーションデータ、音声データを送受信して  受信側で描画・再生を行う  19  配信側  リアルタイム 
通信サーバ  受信側  モーションデータ  音声  モーション  マイク入力  再生  描画  アバター  アバター 

モーションデータの受け渡し  モーションデータは  各クライアントから受け取ったデータを一本のストリーム上で  それぞれ受け手側に流している  リアルタイム  通信サーバ  クライアントB  モーションデータB  20 
クライアントA  クライアントC  モーションデータC  クライアントD  モーションデータD  モーションデータB  モーションデータC  モーションデータD  １つのストリームで  全部受け渡し 

音声データの受け渡し  しかし、音声データも同じように  それぞれのデータを送ると、  最大7人分の音声データが送られるため  回線に負荷がかかってしまう！  リアルタイム  通信サーバ  クライアントB  音声データB  21 
クライアントA  クライアントC  音声データC  クライアントD  音声データD  音声データB  音声データC  音声データD  高負荷！ 

音声データの受け渡し  音声データはサーバで合成して  １つの音声データにしてから  各クライアントに流す    このようなサーバを  MCU (Multipoint Control Unit)という 
リアルタイム  通信サーバ  クライアントB  音声データB  22  クライアントA  クライアントC  音声データC  クライアントD  合成音声データ  音声データD  データ量最大1/7 サーバで音声合成 

ビデオ通話機能のリアルタイム通信サーバの元である  コラボ配信機能では、１つのコラボ枠の参加者が  それぞれ接続するサーバは１つに限定されていなかった  既存機能（コラボ配信）の構成における問題  23  コラボ枠  参加者 A 参加者 B
参加者 C サーバ1  サーバ2  サーバ3 

各サーバはそれぞれ受け取った音声・モーションデータを  Redis経由で共有する必要があった  既存機能（コラボ配信）の構成における問題  コラボ枠  参加者 A 参加者 B 参加者 C
サーバ1  サーバ2  サーバ3  24  データA  データA  データB  データC  データB  データB  データA  データC  データC  データA  データB  データC 

さらに全てのサーバで  各参加者に対して個別に音声合成処理（重い）を行っていた  既存機能（コラボ配信）の構成における問題  コラボ枠  参加者 A 参加者 B 参加者 C
サーバ1  サーバ2  サーバ3  25  データB  データC  データA  データC  データA  データB  A+B合成音声作成  合成音声  合成音声  合成音声  A+C合成音声作成  B+C合成音声作成 

このコラボ配信の音声合成処理では、参加者が接続した各サーバで  接続したユーザ以外の音声データを  それぞれ加算する処理が行われている  音声合成処理  26  サーバ1  音声加算処理  計算量O(n)  音声データB  クライアントA 
音声データC  クライアントA用の  合成音声データ  音声データD  ・・・  サーバ2  音声加算処理  計算量O(n)  音声データA  クライアントB  音声データC  クライアントB用の  合成音声データ  音声データD  コラボの参加者それぞれに  この処理が行われる 

参加者がn人の場合、この音声加算処理１つ１つの計算量はO(n)    各参加者に対してこの処理が行われる（つまりn回）ため、  全体の計算量はO(n2)  音声合成処理  27  サーバ1  音声加算処理  計算量O(n)  音声データB 
クライアントA  音声データC  クライアントA用の  合成音声データ  音声データD  ・・・  サーバ2  音声加算処理  計算量O(n)  音声データA  クライアントB  音声データC  クライアントB用の  合成音声データ  音声データD  コラボの参加者それぞれに  この処理が行われる 

参加者が別々のサーバに接続するため、以下の問題がある  既存機能（コラボ配信）の構成における問題まとめ  コラボ枠  参加者 A 参加者 B 参加者 C
サーバ1  サーバ2  サーバ3  28  データB  データC  データA  データC  データA  データB  データA  データB  データC  • 音声・モーションデータをRedis経由で共有しなければならない  • 各参加者に対して、各サーバが個別に音声合成処理を行う  A+B合成音声作成  A+C合成音声作成  B+C合成音声作成 

コラボ配信では、参加者が最大４人までなので問題が許容できた    しかしビデオ通話では参加者が最大8人で  今後最大参加者数がさらに増える可能性も考慮する必要がある      なのでビデオ通話では  先ほどの２つの問題を解決しなければならない  ビデオ通話用の新たなサーバ構成  29 

ビデオ通話用の新たなサーバ構成  30  実は解決方法は単純 

ビデオ通話用の新たなサーバ構成  31  １つの枠の参加者を  全員同じサーバに接続させる    つまりビデオ通話１枠ごとに専用サーバを立てること  （ゲームにおいては、Delicated Game Serversとも呼ばれる） 

つまりこれを  ビデオ通話用の新たなサーバ構成  32  通話枠  参加者 A 参加者 B 参加者 C
サーバ1  サーバ2  サーバ3 

こう！  ビデオ通話用の新たなサーバ構成  通話枠  参加者 A 参加者 B 参加者 C 専用サーバ
33 

参加者全員が１つのサーバにデータを送るので  Redis経由でデータを共有する必要がなくなる  「データをRedis経由で共有」問題の解決  通話枠  参加者 A 参加者 B 参加者 C
34  データA  データB  データC  必要なデータは全て受け取っているので  Redisとの共有不要！  ＼さよなら…／  専用サーバ

参加者全員が１つのサーバにデータを送るので  Redis経由でデータを共有する必要がなくなる  「データをRedis経由で共有」問題の解決  通話枠  参加者 A 参加者 B 参加者 C
35  データA  データB  データC  必要なデータは全て受け取っているので  Redisとの共有不要！  専用サーバ

そして、「参加者ごとに音声合成」問題も、  参加者が全員１つのサーバに接続することで  計算量を大幅DOWNさせられる！  「参加者ごとに音声合成」問題の解決  36 

「参加者ごとに音声合成」問題の解決  37  サーバ1  音声加算処理  計算量O(n)  音声データB  クライアントA  音声データC  クライアントA用の  合成音声データ 
音声データD  ・・・  サーバ2  音声加算処理  計算量O(n)  音声データA  クライアントB  音声データC  クライアントB用の  合成音声データ  音声データD  コラボの参加者それぞれに  この処理が行われる  コラボ配信の構成だと、クライアントが接続するサーバが別れており  計算量 O(n2) の処理を行う必要があったが… 

リアルタイム通信サーバ  「参加者ごとに音声合成」問題の解決  38  音声データA  クライアントA  音声データB  音声データN  ・・・  音声減算処理  
音声減算処理   音声減算処理   全合成音声データ  ・・・  クライアントB  クライアントN  クライアントA  合成音声データ  クライアントB  合成音声データ  クライアントN  合成音声データ  １つのサーバに  全参加者が接続しているので、    音声合成の処理を効率化して  計算量 O(n) に減らすことができる  全音声加算処理 

リアルタイム通信サーバ  新しい音声合成処理  39  全音声加算処理  音声データA  クライアントA  音声データB  音声データN  ・・・  全合成音声データ 
・・・  クライアントB  クライアントN  クライアントA  合成音声データ  クライアントB  合成音声データ  クライアントN  合成音声データ  新しい音声合成処理では、    まず全参加者の音声を合成した  全合成音声データを作成  音声減算処理   音声減算処理   音声減算処理  

全音声加算処理 O(n)  全合成音声データを作るには    参加者それぞれの音声データを  順番に空音声データに加算していく    １つ１つの加算処理の計算量は O(1)   
なので、全音声加算処理の計算量は  O(1×n) = O(n)  全音声加算処理  40  空音声データ  音声データA  音声加算処理 O(1)   全合成音声データ  音声データB  ・・・  ・・・  音声加算処理 O(1)  

音声減算処理   音声減算処理   全合成音声データ  ・・・  クライアントB  クライアントN  クライアントA  合成音声データ  クライアントB  合成音声データ  クライアントN  合成音声データ  そして、全合成音声データから  各参加者の音声を減算して、  各クライアント用の合成音声を作成    この減算処理１つ１つは計算量O(1)    よって、  減算処理全体の計算量は O(n)  全音声加算処理 O(n) 

音声減算処理 O(1)  クライアントA用の  合成音声データを作るには    全合成音声データから  クライアントAの音声を減算する  音声減算処理  42  クライアントA 
全合成音声データ  音声データA  反転処理  (-1を掛けるだけ）  音声加算処理  クライアントA用  合成音声データ 

この処理は、音声データを反転させて  全合成音声データに加算するだけ    なので、１つの減算処理の  計算量は O(1)  音声減算処理  43  クライアントA  全合成音声データ 
音声減算処理 O(1)  音声データA  反転処理  (-1を掛けるだけ）  音声加算処理  クライアントA用  合成音声データ 

リアルタイム通信サーバ  音声減算処理全体の計算量  44  音声データA  クライアントA  音声データB  音声データN  ・・・  全合成音声データ  ・・・ 
クライアントB  クライアントN  クライアントA  合成音声データ  クライアントB  合成音声データ  クライアントN  合成音声データ  音声減算処理は、  各クライアントに対して  １回ずつ走るので    減算処理全体の計算量は    O(1×n) = O(n)  全音声加算処理 O(n)  音声減算処理   O(1)  音声減算処理   O(1)  音声減算処理   O(1) 

O(1)  音声減算処理   O(1)  音声減算処理   O(1)  全合成音声データ  ・・・  クライアントB  クライアントN  クライアントA  合成音声データ  クライアントB  合成音声データ  クライアントN  合成音声データ  よって、参加者n人に対する  音声合成の計算量は    O(n+n) = O(n)  全音声加算処理 O(n) 

専用サーバの作り方  46  というわけで、専用サーバを立てれば  より効率的にリアルタイム通信を処理できることがわかった 

専用サーバの作り方  48  でも、専用サーバって簡単には作れない 

専用サーバの作り方  49  ・クライアントからの接続のルーティング  ・スケールイン時の稼働中サーバの保護  解決しなければいけない課題は以下の２つ 

クライアントからの接続のルーティング  50  専用サーバでは、Kubernetesクラスタ上に  同じ機能を持った個別のサーバがいくつも立ち上がることになる  専用サーバ専用サーバ専用サーバ  Kubernetes クラスタ  

Kubernetes クラスタ   クライアントからの接続のルーティング  51  ビデオ通話に参加しているクライアントからの接続で、  正しい専用サーバーに適切にルーティングする必要がある  通話枠1  参加者 1-A
参加者 1-B 参加者 1-C 専用サーバ通話枠2  参加者 2-A 参加者 2-B 参加者 2-C 専用サーバその他の  専用サーバ  どれに接続すれば？  IPアドレスは？  ポートは？  >へ< 

参加者 1-B 参加者 1-C 専用サーバ通話枠2  参加者 2-A 参加者 2-B 参加者 2-C 専用サーバその他の  専用サーバ  適当に繋いじゃえ！  ！？  ！？  ！？ 

参加者 1-B 参加者 1-C 専用サーバ通話枠2  参加者 2-A 参加者 2-B 参加者 2-C 専用サーバ  その他の  専用サーバ  適当に繋いじゃえ！  ！？  ！？  ！？  爆発四散！ 

スケールイン時の稼働中サーバの保護  54  また、開催中のビデオ通話で使われている専用サーバが  Kubernetesのスケールインで削除されないように保護する必要がある  通話枠  参加者 A 参加者 B 参加者
C 専用サーバそれでね…  へぇ…  でもさぁ… 

C 専用サーバ Kubernetes シャットダウン  してくれ  それでね…  へぇ…  でもさぁ… 

C 専用サーバ Kubernetes シャットダウン  してくれ  シャットダウンします  ！？  ！？  ！？ 

C Kubernetes シャットダウン  してくれ  ！？  ！？  ！？ 

C Kubernetes シャットダウン  してくれ  ！？  ！？  ！？  爆発四散！ 

この２つの課題を解決する必要がある  そうならないように  59  ・クライアントからの接続のルーティング  ・スケールイン時の稼働中サーバの保護 

60  実は、これを解決する強力な助っ人が存在する 

61  そう、Agones ならね！ 

Agones とは  Ubisoft と Google が共同開発している  オープンソースのKubernetesライブラリ  63 

Fleet Agones とは  Agones System 専用サーバ GameServer 専用サーバ GameServer 専用サーバ
GameServer ・  ・  ・  クライアントは各専用サーバに   個別アクセス可能  agonesは各Podを管理   Kubernetes クラスタ 64  Kubernetesクラスタに導入することで専用サーバの  スケーリングとルーティングが提供される 

ビデオ通話でのAgonesの動き  65  Agonesはビデオ通話がはじまった時に、  専用サーバの一つを、その通話専用のサーバとして割り当てる  通話枠1  参加者 1-A 専用サーバ専用サーバその他の 
専用サーバ  通話を始めます！  ※実際はクライアントとAgonesは直接通信せず、   　APIサーバを通してやりとりが行われます  

ビデオ通話でのAgonesの動き  66  Agonesはビデオ通話がはじまった時に、  専用サーバの一つを、その通話専用のサーバとして割り当てる  通話枠1  参加者 1-A 通話枠１用の  専用サーバ専用サーバ
その他の  専用サーバ  通話を始めます！  君は通話枠１専用ね  了解  ※実際はクライアントとAgonesは直接通信せず、   　APIサーバを通してやりとりが行われます  

ビデオ通話でのAgonesの動き  67  そして、ビデオ通話の参加者に  その通話専用のサーバのIPアドレスとポートを教えてくれる  通話枠1  参加者 1-A 通話枠１用の  専用サーバ専用サーバ
その他の  専用サーバ  君がつなぐサーバの  IPとポートはね…  参加者 1-B 参加者 1-C ※実際はクライアントとAgonesは直接通信せず、   　APIサーバを通してやりとりが行われます  

Agonesによるルーティング  68  これにより、同じ通話の参加者は  割り当てられた同じ専用サーバに正しく接続できる  通話枠1  参加者 1-A 参加者 1-B 参加者
1-C 通話枠１用の  専用サーバ通話枠2  参加者 2-A 参加者 2-B 参加者 2-C 通話枠2用の  専用サーバその他の  専用サーバ 

Agonesによるスケールインからの保護  69  さらにAgonesは一度通話に割り当てたサーバを、  通話終了までスケールインによる削除から保護してくれる  通話枠1  参加者 A 参加者 B 参加者
C 通話枠１用の  専用サーバシャットダウン  してくれ  Kubernetes それでね…  へぇ…  でもさぁ… 

C ！！  Kubernetes それでね…  へぇ…  でもさぁ…  そのサーバは使用中なので  消しちゃダメ！  通話枠１用の  専用サーバ

C 別の使ってない  サーバを消すか…  Kubernetes それでね…  へぇ…  でもさぁ…  安心してビデオ通話を  続けてね！  通話枠１用の  専用サーバ

Agonesのまとめ  72  ・クライアントからの接続のルーティング  ・スケールイン時の稼働中サーバの保護  Agonesは専用サーバを作る時に発生する  という２つの課題を簡単に解決！ 

GKE (Kubernetes) アプリケーションサーバ層 Node Node Service Service Realtime Backend Server
Pod (GameServer) WebSocket Frontend Server Pod Agones WebAPI Server Pod Fleet FleetAutoScaler Deployment HPA HTTPS Load Balancer Management リアルタイムサーバ層 74  アプリケーションサーバ層全体構成  ここまでを踏まえた、ビデオ通話のサーバ構成は以下の通り 

Pod (GameServer) WebSocket Frontend Server Pod Agones WebAPI Server Pod Fleet FleetAutoScaler Deployment HPA HTTPS Load Balancer Management リアルタイムサーバ層 75  アプリケーションサーバ層全体構成  この３つのサーバについて詳しく説明 

Pod (GameServer) WebSocket Frontend Server Pod Agones WebAPI Server Pod Fleet FleetAutoScaler Deployment HPA HTTPS Load Balancer Management リアルタイムサーバ層 76  アプリケーションサーバ層 WebAPI Server 

WebAPI Server  GKE (Kubernetes) Node Node Service Realtime backend Server
Pod (GameServer) WebAPI Server Pod Agones HTTPS Load Balancer ビデオ通話の参加者は、ビデオ通話開始・参加時に  このサーバ経由で Agones に専用サーバを割り当ててもらう  77 

Pod (GameServer) WebSocket Frontend Server Pod Agones WebAPI Server Pod Fleet FleetAutoScaler Deployment HPA HTTPS Load Balancer Management リアルタイムサーバ層 78  アプリケーションサーバ層 Realtime Backend Server 

ここまで説明したビデオ通話用の専用MCUサーバ  Agonesによって管理されている  Realtime Backend Server  GKE (Kubernetes) Node Node Service
Realtime backend Server Pod (GameServer) WebSocket Frontend Server Pod Agones HTTPS Load Balancer 79 

Node Fleet Node Fleet Agones によるスケーリング  Realtime Backend Serverは Agonesによってスケーリングされる 
未使用のサーバが少なくなると、自動的にスケールアウトする  Fleet Autoscaler Fleet Autoscaler Realtime Backend Server GameServer (使用中) Realtime Backend Server GameServer (使用中) Realtime Backend Server GameServer (使用中) Realtime Backend Server GameServer (未使用) Realtime Backend Server GameServer (使用中) Realtime Backend Server GameServer (使用中) Realtime Backend Server GameServer (使用中) Realtime Backend Server GameServer (未使用) Realtime Backend Server GameServer (未使用) Realtime Backend Server GameServer (未使用) Realtime Backend Server GameServer (未使用) Realtime Backend Server GameServer (未使用) ①未使用の専用サーバの台数が   　少ないのを検知  ②新たに専用サーバを立ち上げて補充   80 

Pod (GameServer) WebSocket Frontend Server Pod Agones WebAPI Server Pod Fleet FleetAutoScaler Deployment HPA HTTPS Load Balancer Management リアルタイムサーバ層 81  アプリケーションサーバ層 WebSocket Frontend Server 

GKE (Kubernetes) Node WebSocket Frontend Server  Node Service Realtime Backend
Server Pod (GameServer) WebSocket Frontend Server Pod Agones WebAPI Server Pod HTTPS Load Balancer 通話参加者と Realtime Backend Server の通信を中継する  このサーバを中継することで、クライアント - サーバ間の  通信のセキュリティを担保しやすくなる  82 

WebSocket Frontend Server を経由するメリット  83  通話枠1  参加者 1-A 通話枠１用の  専用サーバ
その他の  専用サーバ  君がつなぐサーバの  IPとポートはね…  参加者 1-B 参加者 1-C ※実際はクライアントとAgonesは直接通信せず、   　APIサーバを通してやりとりが行われます   Agonesはビデオ通話の参加者に  その通話専用サーバのIPアドレスとポートを教えてくれるが… 

WebSocket Frontend Server を経由するメリット  84  通話枠1  参加者 1-A その他の  専用サーバ 
参加者 1-B 参加者 1-C XXX.XXX.XXX.XXX:7000  これをそのまま使って通信を行うと  専用サーバ側でIPv6シングルスタック環境に対応した  SSL終端処理を実装する必要があり大変  通話枠１用の  専用サーバ IPv6にしか  対応してないよ！  IPv6用の  処理が必要・・・ 

WebSocket Frontend Server を経由するメリット  85  しかし、通信を一度中継サーバを経由させて、  中継サーバにドメインを付与することによって  通話枠1  参加者 1-A
その他の  専用サーバ  参加者 1-B 参加者 1-C XXX.XXX.XXX.XXX:7000  通話枠１用の  専用サーバ中継サーバ tantan-websocket-outer.reality.app   Agonesは専用サーバのIPとポートを   参加者ではなく中継サーバに渡す 

WebSocket Frontend Server を経由するメリット  86  通話枠1  参加者 1-A その他の  専用サーバ 
参加者 1-B 参加者 1-C XXX.XXX.XXX.XXX:7000  クライアント - サーバ間の通信で  HTTPS Load Balancer を通せるようになり、簡単にWSS接続可能に   通話枠１用の  専用サーバ中継サーバ tantan-websocket-outer.reality.app   Agonesは専用サーバのIPとポートを   参加者ではなく中継サーバに渡す  HTTPS Load Balancer

Pod (GameServer) WebSocket Frontend Server Pod Agones WebAPI Server Pod Fleet FleetAutoScaler Deployment HPA HTTPS Load Balancer Management リアルタイムサーバ層 87  アプリケーションサーバ層全体構成 

まとめ  ・既存の機能を流用して、ビデオ通話機能を作成した    ・そのままだと、処理が重くなるため、専用サーバにすることに    ・専用サーバを作るためにAgonesを導入    ・専用サーバとクライアントの間に中継サーバをおくことで  　セキュリティを担保  89 

REALITYにおけるビデオ通話のための専用MCUサーバ運用法

REALITYにおけるビデオ通話のための専用MCUサーバ運用法

More Decks by gree_tech

Other Decks in Technology

Featured

Transcript