はじめに
2019年10月24日、25日に中国の北京で開催されたRTC Conference 2019というビデオ通話やライブ配信に関わる開発者向けのカンファレンスに参加してきました。カンファレンスの概要については、agora.io RTC カンファレンス 2019 レポート #1に記載しています。
最終回の今回は、私が参加したセッションとセッション会場外の展示についてのレポートです。なお、agora.io RTC カンファレンス 2019 レポート #2でもセッションのレポートを記載しています。#2は、業界トレンドの変遷やAI × RTC をテーマとしたセッションが中心となっています。
セッションレポート
まずは私が参加したセッションのレポートを3つ記載します。今回は、システム構成・開発をテーマとしたセッションです。
WebRTCにおけるよくある間違いとその回避方法 [Big Front-end Application]
このセッションでは、BlogGeek.meというWebRTCに関するメディアの運営者であり、W3C WebRTCテクノロジーエバンジェリストでもあるTsahi Levent-Levi氏がはじめにWebRTCの概要について話した後、WebRTCにおけるよくある間違い7つとその回避方法について話しました。
WebRTCの概要については、WebRTCはWebブラウザをベースにした技術で、Java ScriptのAPIを利用したメディアエンジンであるという話をしました。また、WebRTCを構成する要素として、クライアント側はブラウザ、端末、サーバ側はアプリケーションサーバ、Signalingサーバ、メディアサーバ、STUN/TURNサーバを挙げました。
その後、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に限らず、システム開発全般において重要だと思いました。
写真1. 自身のWebRTC学習サービスを紹介するLevent-Levi氏
Kubernetesを利用したビデオストリーミングサーバの構築 [QoE and Architecture]
このセッションでは、データ保護に関するSaaSベンダーであるWishlifeのCTOであるLei Wang氏が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について書かれた記事がたくさんあったので、日本でも利用されている技術なのだと思います。
写真2. Kubernetesの概念を利用してサーバの構成図について説明するWang氏
Dockerを利用したグローバルマルチクラウドRTCフレームワークの作成 [QoE and Architecture]
このセッションでは、SignalWireのCTOであるEven McGee氏が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.ioと同じように映像音声やチャットを利用したアプリケーション用のAPIを提供するサービスのようです。また、SignalWireのアカウントを利用すれば、agora.ioなど他のRTCサービスも利用できることも最後に説明していました。
写真3. コンテナ化とDockerについて説明するMcGee氏
展示レポート
セッション会場の外では、agora.ioをはじめ、RTCに関するサービスを提供する各社が様々な展示をしていました。ここではその中から3つ紹介します。
全世界のagora.io利用状況 (Realtime)
Realtimeと呼ばれるagora.ioが提供する分析ツールのひとつです。全世界でのagora.ioのリアルタイムの利用状況を表示しています。こちらの写真は中国時間の10月25日16時53分に撮影しましたが、その時点の利用ユーザ数は、4万2千人ほどでした。Realtimeは2019年11月現在Beta版ですが、agora.ioユーザであれば、利用することができます。
なお、写真の上部に書いてあるAgora Analyticsは、agora.ioが提供する分析ツールの総称で、agora.ioは、このRealtimeをはじめ、様々な分析ツールを提供しています。
写真4. Realtime
顔認識技術のデモ
FaceUnityの技術を利用した顔認識技術のデモです。(agora.ioはFaceUnityの顔認識技術もサービスの一部として提供しています) 。水色の枠内に立ち、カメラの前を向いて3秒ほどすると、自動でその人の特徴を捉えたアイコンを生成します。
写真5. 顔認識技術のデモ
遠隔授業のデモ
中国では、遠隔教育も急速に成長している分野の一つのようです。こちらのサービスでは、資料共有やホワイトボード機能などを利用することができます。
なお、その後ろに見えるのは、ゲームセンターなどに置いてあるパンチングマシンです。初日にそれを使って遊んでいる人がたくさんいたせいか、2日目には撤去されていました。
写真6. 遠隔授業のデモ
まとめ
カンファレンスは大部分のセッションが中国語でおこなわれ、かつ私の前提知識が不足しているセッションも多かったので、内容を理解することに苦労しました。正直なところ内容をほとんど理解できなかったセッションもありました。ただ、英語でおこなわれたセッションやRTCの市場動向、WebRTC、Dockerなど比較的馴染みのあるセッションは聞いていて楽しかったです。
また、セッション中はほとんど理解ができなかったセッションもこうしてレポートを作成するにあたり、記録することのできた単語から色々と調べていくと、近年様々な研究がおこなわれている技術であることがわかりました。RTC業界といっても数多くの技術要素があり、他種多少な研究がされているのだと思いました。特に今話題のAIを映像・音声技術に取り入れられているという点は自分にとって新鮮でした。ただ、今回のセッションを聞いたうえでよく考えてみると、AIと映像・音声技術は相性のよい分野だと思いました。このように日々の業務に追われていると疎かになりがちなRTC業界のトレンドを知ることができたので、参加することができてよかったです。
今後もこのようなカンファレンスに積極的に参加して、知識を深め、日々の業務に活かしていきたいと思います。最後まで読んでいただきありがとうございました！
参照
Enroll to Advanced WebRTC Architecture Course
Concepts - Kubernetes
Kubernetes vs. Docker Swarm: What's the Difference? - The New Stack
