こんにちは。サーバーエンジニアのユンです。
今回Mirrativは「コラボ配信」という機能を開発しました。他の配信者（最大３人）と音声でつながり、視聴者とも同時にコミュニケーションを楽しむことができる機能です。
現在のところ、一部の配信者さんにご利用いただき、さらなる機能改善を進めています。
もともと、Mirrativでは「コラボ通話」という配信者と視聴者が通話する機能があります。コラボ通話はWebRTCの機能を使っていて、iOS/Android側はlibwebrtcにパッチを当てたものを利用しています。またSTUN/TURNはTwilioを利用しています。
コラボ通話をしているときユーザーは配信者、コラボ通話者、視聴者の３種類に区別され、配信者とコラボ通話者はWebRTCで音声が双方向になり、お互いの声をWebRTCを通して送受信しています。コラボ通話者が２人以上の場合メッシュ状にP2P接続させています。視聴者はRTMPで配信者の画面映像、配信者のマイク入力により合成されたゲーム音＆配信者の声＆コラボ通話者の声を受信して視聴することができます。
今回はそのコラボ通話機能と配信機能を組み合わせてコラボ配信の機能を作りました。 通常の配信では配信者と視聴者が1対Nの関係性を持ち、映像と音声は配信者から視聴者への一方通行になっており、視聴者はコメントを通じてコミュニケーションを行っています。コラボ配信は自分の配信をしながら、他の配信者と（最大３人）音声でつながり、その配信者＆視聴をしている視聴者とコミュニケーションができます。 配信者同士＆その視聴者とコミュニケーションを取ることで配信中のコミュニケーションをもっと楽しむ、配信内容によっては一緒にゲームをプレイすることも可能になります。
この記事ではそのコラボ通話とコラボ配信の技術の中でクライアント/サーバー間の仕組み、そしてコラボ配信の実装時の工夫したところを中心にお話します。
ここから使う用語の定義
- 配信者 : 配信を行っているユーザー
- コラボ通話者 : 配信者とコラボ通話でつながっているユーザー
- コラボ配信者 : 配信者とコラボ配信でつながっているユーザー
- API Server : WebAPIを提供するサーバー
- Pub-Sub Server: リアルタイムメッセージ配信を提供するサーバー
コラボ通話がつながるまでのクライアント/サーバー間の仕組み
コラボを開始する際にコラボ通話者は配信者に対してAPI Serverにコラボ申請を送ります。API Server側はコラボ申請を受け取った時点で配信者↔コラボ通話者の関係性とコラボ状況（コラボ申請中）とコラボ通話用のPub-Sub Server情報（Pub-Sub Server接続用のキー）を作成してコラボ通話用のデータベースに保存します。
保存後API ServerではPub-Sub Serverを通してコラボ申請が届いたことを配信者に伝えて、配信者のアプリケーション側ではWebRTCClientの作成と承認したことをAPI Serverに送ります。API Serverでは承認したことをデータベースのコラボ通話用テーブル上にあるデータからコラボ状況を更新（承認）して、Pub-Sub Serverを通してコラボ通話者に承認情報を送り、Pub-Subからの承認情報を受信したコラボ通話者は同じくWebRTCClientを作成します。
また、配信者↔コラボ通話者でのWebRTCによるP2Pの接続が確立されたら、配信者側はAPI Serverにコラボ接続が完了してコラボが開始したことを送信します。
コラボ通話者を追加する場合
コラボ通話では配信者を含めて最大４人の視聴者までつなげることができます。それぞれがWebRTCで接続され、音声データのやりとりをしています。 それに備えてサーバー側は「コラボ通話がつながるまでのクライアント/サーバー間の仕組み」を行った後、既存につながってるコラボ通話者ともコラボをWebRTCで接続する処理を追加で行います。
コラボ通話者Aがもともと配信者とコラボ通話を行っていて、後からコラボ通話者Bがそこに加わるようなことになり、コラボ通話者Bは上のフローと同様に配信者とコラボを接続した後、その時点でコラボに接続しているユーザーの一覧（この場合はコラボ通話者Aのみ）をサーバーから取得し、コラボ通話者Aとの接続を行います。
コラボ配信がつながるまでのクライアント/サーバー間の仕組み
コラボ配信はコラボ通話機能と配信機能を組み合わせて作りました。その背景もあり、ユーザーがコラボ配信を申請するタイミングでは配信前の視聴者の可能性があるので、その場合は既存の配信処理もコラボ配信がつながるまで同時に進行する必要と、既存のコラボ通話と配信を区別する必要もありました。
それで、今回は視聴者がAPI Serverにコラボ申請を送る際にサーバー側でその申請がコラボ通話かコラボ配信かを区別するコラボタイプをパラメータに追加して、コラボタイプのパラメータがコラボ配信の場合に配信者↔コラボ通話者の関係性とコラボ状況（コラボ申請中）と情報（Pub-Subのキー）を作成してコラボ通話用に作られたデータベースに保存するとともに、配信を開始するための配信情報を作成およびデータベースに保存するようにしました。 また、レスポンスにはコラボ配信時に使用する配信情報を渡してWebRTCの接続処理までに配信開始処理を行うようにしています。
配信者とコラボ配信者のWebRTC接続の切断がしばしば発生
コラボ配信の実装後、動作確認時に配信者とコラボ配信者の間でWebRTCの接続が切断され、配信は続いているが、コラボ配信をしている配信者間の声が聞こえない問題が発生しました。 原因はコラボ配信を行ってる際にクラッシュなどでアプリケーションが異常終了をしたり通信環境の問題などでWebRTCの接続がなくなるが、データベース上ではコラボ開始状態から変化がないことが問題でした。
コラボ通話の場合、通話者は切断が起きた際にアプリケーション側でコラボ通話を終了させ、ユーザーがもう一回コラボ通話を申請することで再度開始するようにしていました。しかし、コラボ配信の場合はコラボ配信者側に視聴者が入っていることもあるので、コラボ通話のようにもう一回コラボ配信を行うように案内をすることは難しい状況でした。そのため、コラボ配信を終了させずにWebRTCの再接続をするフローを追加することにしました。 データベース上ではコラボ配信が開始している状態になっていたので、該当のユーザーのリストをクライアントに送り、そのリストの上にいるユーザーの中でWebRTCでの接続がされてないユーザーに対してWebRTCでの再接続処理＆クライアント/サーバー間での再接続処理を行うようにしました。
おわりに
今回はMirrativのコラボ通話とコラボ配信機能のクライアント/サーバー間の仕組みについてお話しました。
特にコラボ配信については、新しい体験を与える大きな規模の機能を０から実装するのではなく既存のユーザーが日頃よく使ってる機能の組み合わせで開発を行うことで、約2ヶ月で開発終了することができ、新しい体験をユーザーに提供することができました。
しかしながら、今のコラボ配信やコラボ通話をメッシュ状にP2P接続させる仕組みだと端末の負荷的にこれ以上参加者を増やせないため、さらなる品質の改善に向けてSFUの導入なども検討しています。
We are hiring!
このように新しい体験をユーザー提供し続けるミラティブではサーバーエンジニアを募集中です！
- ゲーム×ライブ配信サービスの開発をしたい
- サーバーシステムの基盤の整備をしたい といった方のご応募をお待ちしております！
