RTC 2019 @北京　参加レポート - 3

#SDK

2020.03.06

はじめに

2019年10月24日、25日に中国(北京)で開催されたRTC 2019というビデオ通話やライブ配信に関わる開発者向けのカンファレンスに参加してきました。カンファレンスの概要については、RTC 2019 @北京参加レポート - 1に記載しています。

目次［非表示］［表示］

最終回の今回は、筆者が参加したセッションとセッション会場外の展示内容ついてのレポートです。

なお、RTC 2019 @北京参加レポート - 2でもセッションのレポートを記載しています。こちらは業界トレンドの変遷やAI × RTC をテーマとしたセッションが中心となっています。

セッションレポート

まずは筆者が参加したセッションのレポートを3点お伝えします。今回は、開発・システム構成をテーマとしたセッションです。

Kubernetesを使った映像配信サーバー [QoE and Architecture]

このセッションでは、Lei Wang氏（データ保護に関するSaaSベンダーであるWishlifeのCTO）がKubernetesの概要を説明した後、それを利用した映像ストリーミングサーバの構築方法について話しました。

Kubernetesとは、Googleによって開発されたコンテナ化したアプリケーションのデプロイやスケーリング、管理を自動的におこなうためのオープンソースのシステムです。オーケストレーション基盤 (オーケストレーションツール) とも呼ばれているようです。本番環境では、複数のコンテナを動かすことが一般的です。言い換えると、コンテナ単体では、本格的なシステムを運用することは難しいです。しかしながら、各コンテナは独立をしていて、お互いを認識しません。そのため、そうした複数のコンテナを管理するためのツールがKubernetesです。

その後、Wang氏は、Kubernetesを理解するためには、Cluster、Node、Pod、Service、Ingress Controller、Persistent Volume、Persistent Volume Claimという7つの基本概念について理解する必要があると話しました。これらの基本概念については、Kuberbetesのドキュメントで解説されています。そして、これらの概念を用いてKubernetesを利用した映像ストリーミングサーバの構築方法について説明しました。また、それに加えて、複雑なKubernetesを利用したアプリケーションを定義、インストール、アップグレードする際には、Helmというパッケージマネージャ (パッケージ管理システム) が役に立つと話しました。

つまり、複数のコンテナのインフラ管理するための基盤 (ツール) がKubernetesであり、その基盤の上で、Kubernetesをアプリケーションのように扱うことができるシステムがHelmということになると思います。多くの概念が登場したため、それらの関係性の理解に苦労しましたが、コンテナ技術の普及に伴い、それに付随する新しい技術が生まれ、活用されているのだと思いました。Qiitaでも、KubernetesやHelmについて書かれた記事がたくさんあったので、日本でも利用されている技術なのだと思います。

[Kubernetesの概念を利用してサーバの構成図について説明するWang氏]

Dockerを使ったRTCフレームワークについて [QoE and Architecture]

このセッションでは、Even McGee氏（SignalWireのCTO）がDockerとその管理ツールであるDocker Swarmの概要を説明し、グローバル・マルチクラウド・RTCフレームワークの作成において重要な点について話しました。その後、自社サービスであるSignalWireについて紹介しました。

Dockerとは、コンテナ型の仮想環境を作成、共有、実行するためのプラットフォームです。 McGee氏もコンテナの説明でよくされるようにコンテナの利点として、軽量で高速に起動、停止できることを挙げていました。

また、先ほどのセッションで登場したKubernetesと同じようなコンテナ管理ツールとして、Docker Swarmについて紹介しました。こちらは、Docker社によって開発されたコンテナ管理ツールです。なお、こちらの記事では、KubernetesとDocker Swamについて比較しています。こちらの記事によると、Kubernetesはより複雑な管理が可能であり、Docker Swamはシンプルで構築が容易という点が特徴のようです。

そして、グローバルマルチクラウドRTCフレームワークの作成において重要な点を3つ挙げました。1つ目は、マスターとなるノード (管理コンポーネント) は、近くに配置するが、それぞれのリージョンやプロバイダは別にすることです。なお、McGee氏は、複数のクラウドプロバイダを利用することの利点として、サービスが世界中で利用できることも挙げました。つまり、1つのプロバイダでは、サービス提供できる範囲が限られるが、複数利用すれば、世界中をカバーすることができるということです。次に2つ目は、クラスタ (Docker Swarmの管理対象全体) のログを注視することです。そして3つ目は、クラウド間、サーバ間の通信を暗号化することです。

上記の点の多くは、聞き馴染みのあることでしたが、複数のクラウドプロバイダを利用することで、世界中にサービスを提供するという指摘は、筆者にとってはスケールの大きい話で新鮮でした。

その後は、自社サービスであるSignalWireの紹介しました。 McGee氏の話やサービスサイトを一読したところ、SignalWireもAgoraと同じように映像音声やチャットを利用したアプリケーション用のAPIを提供するサービスのようです。また、SignalWireのアカウントを利用すれば、Agoraなど他のRTCサービスも利用できることも最後に説明していました。

[コンテナ化とDockerについて説明するMcGee氏]

WebRTCでのありがちな誤用と対処法 [Big Front-end Application]

このセッションでは、BlogGeek.meというWebRTCに関するメディアの運営者であり、W3C WebRTCテクノロジーエバンジェリストでもあるTsahi Levent-Levi氏がはじめにWebRTCの概要について話した後、WebRTCにおけるよくある間違い7つとその回避方法について話しました。

WebRTCの概要については、WebRTCはWebブラウザをベースにした技術で、Java ScriptのAPIを利用したメディアエンジンであるという話をしました。また、WebRTCを構成する要素として、クライアント側はブラウザ、端末、サーバ側はアプリケーションサーバ、STUN/TURNサーバ、Signalingサーバ、メディアサーバを挙げました。

その後、WebRTCにおけるよくある間違い7つとその回避方法について話しました。まず1つ目の間違いは、NAT越えに関する間違いです。Levent-Levi氏は、公開されている (パブリックな) 無償のSTUN/TURNサーバを使うべきではないと主張しました。常に正常に利用できる保証がなく、世界中で広く利用されており、セキュリティリスクも高いからとのことです。

2つ目は、誤ったSignalingのフレームワークを選択することです。おそらくこの指摘は、GitHub等で公開されているコードをコピー&ペーストして利用することに対して、注意を促しているのだと思います。peerjsやEasyRTCなど無償で利用することのできるWebRTCのサンプルコードは数多くあります。ただ、これらのコードは必ずしも管理が行き届いているとは限りません。そのため、自身のサービスの要件を確認したうえで、自分自身でコードのメンテナンスをすることが大切になります。

3つ目は、ローカル環境のみでテストをすることです。多くのサービスでは、実際にそのサービス利用する際は、FWの外に出て、インターネット経由で利用することになります。インターネット経由となると、ローカル環境では発生しなかった問題が発生する可能性もあります。

4つ目は、セキュリティ設定を無視、または忘れることです。ただ、Levent-Levi氏は、WebRTCという技術自体は安全であると言っていました。動画の送信では、SRTP (Secure Real-time Transport Protocol) というプロトコルを利用して、メッセージの暗号化や認証を実施しています。暗号鍵の交換はDTLS (Datagram Transport Layer Security) を通して実施されます。また、Signalingの送信では、HTTPS、もしくはWSS (Web Socket Secure) が利用されます。

Levent-Levi氏が指摘するWebRTCを利用したサービスを提供するうえで重要なセキュリティにおける点とは、アプリケーションロジックやTURNサーバへのアクセス設定、メディアサーバのリソース調整、WebRTCのリリース (アップデート) を注視し続けることです。

5つ目は、統計情報やログを収集しないことです。WebRTCはその技術の特性上、常に全てを自分自身でコントロールできるとは限りません。例えば、利用デバイス、各ユーザのネットワーク状態、ブラウザの自動アップデートなどに起因する問題はサービス提供者自身でコントロールすることが難しいです。しかしながら、サービスユーザから見ると、これらが原因で発生した問題もサービス提供者に原因があると思われてしまうことも多々あります。そのため、問題を分析し、解決に導くためにも必要なデータは収集するべきです。

6つ目は、短期的視点しか持たないことです。一般的にブラウザは6から8週間のサイクルでアップデートが発生します。アップデート内容によっては、セキュリティパッチが含まれていたり、ブラウザの仕様が変更することもあります。サービスを開発する際は、サービスを完成させることだけではなく、その後のメンテナンスについても考慮することも重要です。
　そして最後の7つ目は、WebRTCについて理解が足りていないことです。Levent-Levi氏は、その解決策として自身の運営するBlogGeek.meで、WebRTCについて学習することを勧めていました。ちなみにLevent-Levi氏が紹介したサービスでは、1回20分程度のレッスンが40以上あるようです。

このセッションを通して、WebRTCという技術は便利ですが、自分自身でコントロールできない要素も多い技術で、注意するべき点が多い技術であると改めて感じました。また、自分自身でコードのメンテナンスを実施することやセキュリティに対して注意を払うことなどの指摘は、WebRTCに限らず、システム開発全般において重要だと思いました。

[自身のWebRTC学習サービスを紹介するLevent-Levi氏]

展示レポート

セッション会場の外では、Agoraをはじめ、RTCに関するサービスを提供する各社が色々な展示をしていました。ここではその中から3つ紹介します。

デモ：リアルタイム3Dアバター

FaceUnityの技術を利用した顔認識技術のデモです。(AgoraはFaceUnityの顔認識技術もサービスの一部として提供しています) 。水色の枠内に立ち、カメラの前を向いて約3秒。自動でその人の特徴を捉えたアイコンを生成します。

[顔認識技術のデモ]

デモ：オンライン教育

中国では、遠隔教育も急速に成長している分野の一つのようです。資料共有やホワイトボード機能などを本サービスで利用することができます。

ちなみに、その後ろに見えるのは、ゲームセンターなどに置いてあるパンチングマシンです。初日に楽しむ人がたくさんいたせいか、2日目には撤去されていました。

[遠隔授業のデモ]

全世界のAgora利用状況 (Realtime)

RealtimeはAgoraが提供する分析ツールのひとつです。全世界でのAgoraのリアルタイムの利用状況を表示しています。こちらの写真は中国時間の10月25日16時53分に撮影しました。その時点の利用ユーザ数は、約4万2千人でした。Realtime（2019年11月現在Beta版）はAgoraユーザであれば、利用可能です。

なお、写真の上部に書いてあるAgora Analyticsは、Agoraが提供する分析ツールの総称で、Agoraは、このRealtimeをはじめ、様々な分析ツールを提供しています。

[Realtime]

まとめ

カンファレンスは大部分のセッションが中国語でおこなわれ、かつ筆者の前提知識が不足しているセッションも多かったので、内容を理解することに苦労しました。正直なところ内容をほとんど理解できなかったセッションもありました。ただ、英語でおこなわれたセッションやRTCの市場動向、WebRTC、Dockerなど比較的馴染みのあるセッションは聞いていて楽しかったです。

また、セッション中はほとんど理解ができなかったセッションも本レポートを作成し、記録することのできた単語から色々と調べていくと、近年様々な研究がおこなわれている技術であることがわかりました。RTC業界といっても数多くの技術要素があり、様々な研究がされているのだと思いました。特に今話題のAIを映像・音声技術に取り入れられているという点は筆者にとって新鮮でした。ただ、今回のセッションを聞いたうえでよく考えてみると、AIと映像・音声技術は相性のよい分野だと思いました。日々の業務に追われていると疎かになりがちなRTC業界のトレンドを知ることができたので、参加することができてよかったです。

今後もこのようなカンファレンスに積極的に参加して、知識を深め、日々の業務に活かしていきたいと思います。最後まで読んでいただきありがとうございました！