1.映像・音声送受信の技術選定

映像・音声の送受信は最も重要なポイントになります。2022年5月現在ではWebRTCとHLSが基本的な技術になります。

基本的な技術

WebRTC

WebRTCはデバイス同志がP2P通信を行う事で、ビデオ通話やファイル共有等を実現できます。特徴としては低遅延があげられますが、環境によってはその恩恵を受けられない場合もあります。複数人の同時接続による端末負荷、FireWallによる接続ブロックなどが考えられます。

HLS

HLSは映像・音声を数秒毎のファイル(tsファイル)に分割し、プレイリストファイル(.m3u8ファイル)に従って再生します。受信の通信はすべてHTTPで実行されます。又、CDNも利用できるので膨大な同時接続人数でも対応できます。デメリットは遅延秒数が大きい為、リアルタイム性が失われる点です。

PaaSの活用

前述の通り基本的な配信技術ではいくつかの課題があります。特徴的なアプリケーションとしてコラボ配信を構築しようとすると、WebRTCとHLSを組み合わせる必要がでてきます。それぞれの技術調査やインフラの選定・メンテナンス、デバイス側のアップデート対応等開発時から運用時まで課題が積み上がっていきます。技術的に難易度が高い部分に関しては、特化したPaaSを活用するのもおすすめです。

Agora.io

Agora.ioは映像・音声の送受信技術を提供するPaaS(Platform as a Service)で、クライアント側のSDKと映像・音声の送受信のインフラが準備されています。低遅延で大規模な同時接続に対応でき、開発から運用まで工数の削減が実現できます。SaaS(Software as a Service)ではないのでUI/UXや付随する機能は開発会社にて実装する必要があります。iOSアプリケーションやAndroidアプリケーション用のSDKも提供しているのでWebアプリケーションとモバイルアプリケーションの双方向通信も可能です。

又、日本語での技術サポートも充実しているのも特徴の１つです。ビデオ通話・ライブ配信アプリケーションを長年開発・運用してきたV-CUBEのノウハウをもってサポートします。

2.対応させる利用端末や環境の明確化

ビデオ通話・ライブ配信アプリケーションの構築時にターゲットとなる利用端末を明確にする事は非常に重要です。開発が進んで完成が近い時に思わぬ落とし穴に落ちるケースがあります。最悪な場合、0から作り直す必要が出てきます。

落とし穴の例

(1)ブラウザ問題

日本国内の企業ではいまだにIEが現役で利用されているケースもあります。

WebRTCを用いたビデオ通話ではIEで動作させる事ができません。その他にもブラウザのバージョンが低い場合に動作しない場合もあります。

映像コーデックに目を向けると、Safari12.1未満はVP8非対応であったり、一部の廉価版AndroidのChromeはH.264に非対応となってます。本格的な実装の前にターゲットとなるブラウザでの動作を確認してから実装に取り掛かったほうが良いです。

(2)画面共有機能

Webアプリケーションでは画面共有機能の活用も多くあります。実装も簡単にできますが、2022年5月現在ではデスクトップPCのブラウザのみ対応となっています。モバイル端末でのブラウザは画面共有が開始できません(受信は可能)。Safariについては13以上が必須となっています。

モバイル端末で画面共有を実現するにはiOS、Androidアプリケーション化が必要となってきます。

Agora.ioではサンプルコードもGithubで公開されています。 又、デスクトップの音声共有は2022年5月現在Chromeのみ対応となっております。

(3)FireWallやWebプロキシ

企業内ネットワークや施設のインターネット環境はFireWallやWebプロキシで通信が制限されている場合があります。開発環境で問題なく動作していたアプリケーションも、いざ実運用の環境に投入して動作しないというケースもあります。特にWebRTCでは様々なプロトコルを利用しますので、ネットワーク管理者との調整が発生する事もあります。このような問題に対応するには、開発初期段階のプロトタイプレベルのアプリケーションで実利用の環境において通信テストを推奨します。

その際、通信が正常に動作しない場合は、PaaSやSDK提供者ではなく、該当環境のネットワーク管理者(情報シス)にトラブルシューティングを依頼するとスムーズに問題解決します。(PaaS提供者は必要なポートやプロトコルの開示までが責任範囲となり、個別のネットワーク機器の設定はネットワーク管理者の責任範囲になります）

実際、ネットワーク管理を外部に委託している場合は、即時対応というのが難しい場合もあり、サービス開始の大幅な遅延も起こりうるので非常に重要な検討事項となります。

補足になりますが、Agora.ioではネットワーク機器の制限を緩和できるオプションも用意されています。

(4)通信品質

日本国内においては、固定回線、モバイル回線共に高速化が進んでいます。高画質の動画でもスムーズに再生できる環境が多いですが、特定の環境では帯域不足が発生する場合もあります。

• １つのルーターに同時に多くの人が集中的にアクセスする環境
• 前日までの利用量に対する携帯キャリアの通信制限
• 一部の海外拠点

帯域に懸念がある環境では映像の画質を下げる、フレームレートを下げるといった対応方法が考えられます。どちらを下げるかは提供するサービスの要件によって異なってきます。

その他にもABR(アダプティブビットレート)やDualStream(通常画質・低画質の同時配信)を活用し、最低限音声だけでもクリアに届けるという対応方法もあります。

例えば、ビデオ通話会議では映像は少し荒くても音声さえクリアであれば、問題無いというケースもあります。 その他にも発話している人の映像だけを取得するというような細かいチューニングも面白いかもしれません。

3.配信端末(配信環境)の負荷問題

配信端末側のアプリケーションは非常に重要です。ライブ配信やコラボ配信で視聴者を1万人集めても配信端末1台に問題が発生したら1万人全員が視聴できず、そこまでにかけたコストや時間がすべて水の泡になってしまいます。テストの際には問題が発生せず、想像もしなかった時点から急激に負荷がスパイクして配信端末がクラッシュするという可能性もあります。

代表的な設計ミスは

• すべてのチャットコメントをリアルタイムに受け付けてレンダリング処理をする
• 端末スペック以上の映像をキャプチャ＆送信する
• 不十分な帯域やネットワークの制限
• 端末の熱

等があります。 チャットは欠かせない機能ですが、1万人のチャットを同時に受け付ける必要性はあまりありません。読み切る事が難しいからです。一旦サーバー側でチャットコメントをプールして少しづつ取得したり、別端末で受け取ってそちらで内容を確認するという方法もあります。

盛り上がりを演出したいのであれば、イイねやハートのカウントを表示するという手もあります。 配信端末のスペックも重要です。テストの時には想定される端末のスペックを把握し問題なく動作する事を事前に確認しておくのが大切です。

一部の配信拠点ではネットワークの品質が不明確な場合もあります。FireWallやWebプロキシの存在、他者とネットワークが共有されている、パケットロスや帯域等の品質に左右されるという事もあるので可能な限り事前の配信テストを実施し、いざとなれば現地でのアプリケーション側のチューニングというのも頭に入れておいたほうが良いかもしれません。

機能面ですべてをクリアしていても、思いがけない問題発生の原因として端末の熱暴走があります。配信数十分の間で問題がなくても、時間が経つにつれ、熱がこもってきて十分な性能が出ない場合もあります。長時間配信をする場合はスタンバイ用の配信端末を用意したり、物理的に冷却できるようなガジェットを用意しておくのもおすすめです。長時間配信においてはバッテリー切れ(端末本体や、bluetoothマイク等)にも注意が必要です。

4.ライブ配信開始前後のアクセス集中問題

基本的にライブ配信は何かしらのWebページにアクセス(もしくはWebAPIを叩いて)視聴画面にたどり着きます。平常時ではスペックの低いサーバーで捌けていたアクセスが、ライブ配信開始の前後10分くらいにスパイク的にアクセスが集中して負荷が急上昇する場合があります。Webサーバーの負荷やDBサーバーの負荷が主な原因になります。特に前述の通り、配信者に対するアクセスは100%確実に実施できる必要があります。

Webサーバー側に問題があれば、スケールアウト・アップの自動化(無駄なコストを削減する為、集中する時間帯のみ実施がおすすめ)や、最低限配信者がアクセスするサーバーを別途用意するという手法が考えられます。

DBサーバーがボトルネックであれば、クエリ数を減らしたり、視聴遷移に必要な情報だけを格納した分散型メモリキャッシュシステムを用意するという手法が考えられます。

Webサーバーの同時受付セッション数<DBサーバーの同時受付セッション数という設定も重要になります。

問題が発生し、アプリケーションを修正する時間がない！という緊急時に、少し力技になりますが、負荷軽減の為に視聴者の何割かをランダムで「アクセスが集中しています。もう少しお待ちください。」というページに飛ばしてしまい、負荷が下がるのを待つという裏技も検討してみてはいかがでしょうか。

5.問題発生時に対する調査の仕込み

これまでのような十分な対策を施しても問題は発生します。アプリケーションのバグだけではなく、ユーザー側の環境によって引き起こされる問題もあります。

サービスの内容によっては事後に問題の原因報告が必要であったり、次回に向けて改善・改修が必要になる場合もあります。開発者がリアルタイムに問題発生現場に出向くのは現実的ではありません。Webアプリケーションであればconsoleログ、iOS、Androidアプリケーションであればログ出力したものを収集できる仕組みを導入しておけば何が問題であったか特定できるケースもあります。例えば処理のステップ事にログを吐き出しておけばどこで止まったか等が把握でき、対処すべき範囲を絞り込めます。

ユーザーのネットワークに起因するような問題は特に特定が困難です。どのような手法でログを取れば良いか頭を抱えてしまいます。Agora.ioではこのようなラストワンマイルの問題を可視化できるツールも提供されています。PaaSやクラウドサービスの選定時で問題の可視化が可能になるツールは注目すべき点になります。

最後に

これまで5つの注意点を記載しました。その他にも多くの注意点があります。

このような役立つTipsを今後も情報発信していきます。

多くのサービス、アプリケーションがリリースされていく事を願っています。