WebRTCはP2Pでサーバーレスか
WebRTCを少しでも学んだ事のある人はご存じかと思いますが。インターネット越しで通信しようとするとWebRTCは完全にサーバレスと言うわけではありません。
WebRTCを構成しようとすると下記のように幾つかサーバーが必要になります。
シグナリングサーバ
接続情報が含まれるSDPやCnadidateと呼称されるメッセージの交換に利用するサーバです。
これは双方のクライアントからアクセス可能なサーバである必要があります。
STUNサーバ
NAT配下に存在する機器がNAT機器に割り当てられているIPと自分に割り当てられているPortを知るために必要になります。同じNAT機器の配下やグローバルIPをクライアントが持っているなどの例外を除き、ほとんどの場合でSTUNが無ければ繋がりません。
TURNサーバ
P2P接続が出来ない一部の環境において、通信を中継するために必要になります。グローバルIPを持っているTURNサーバがクライアントにIPとPortを貸し出すような仕組みです。個人向けの場合には必要になる事は少ないです。しかし、法人。特に日本の大企業の相手場合には高確率で必要になります。
WebRTCでサーバレスにするには
隣接した端末がBluetoothやRFIDなどで接続情報を交換できて、かつ双方がIPアドレスで通信可能な場合においてはサーバーレスが実現可能です。実際にやっているのは時々見ます。
ビデオチャットのサービスでP2Pを利用できるか
ビデオチャットの場合は数人であれば可能でしょう。これはクライアントPCの性能やクライアント間のネットワーク品質に依存します。現実的なラインとしては4-5人程度と個人的には考えています。
スマートフォンがクライアントの場合にはもっと少なく2-3人程度にする必要があると思います。
音声のみの場合
PCに対する要求性能やネットワークに対する要求速度が大きく下がります。必然的に処理可能な人数は増えます。
ビジネスとして
正直言って難しいと思います。使えて1on1では無いでしょうか。
複数人の接続の場合は下記のようなフルメッシュ通信となります。
この通信においては A<->B 間は繋がるのに B<->C 間が繋がらないという状況が発生するのですが、これら個々の通信経路は千差万別ですので問い合わせをうけても原因特定の難易度が非常に高くなります。
動画配信においてサーバ台数を減らせるか
これは一部の用途においては可能です。WebRTCのデータ通信であるDataChannelをつかい、HLSの動画セグメントをクライアント間で融通することでCDNのような状態とすることで送り元のサーバ転送量を減らすというテクニックがあります。
実際にこれを実現してビジネスにしている例としては
- Mist Technologies 社の MistCDN
- Peer5
が挙げられます。
問題点
しかし、ぱっと思いつく大きな問題点として下記が挙げられます
クライアントの転送量が増加する
視聴しているクライアントはセグメントを融通するアップストリーム通信が必要になります。転送量に関わらず定額の回線であれば問題になりませんが、スマートフォンなどで転送量に制限のある携帯電話回線を利用している場合はユーザーが自分が視聴しているファイルサイズ以上の転送量が消費されるため、当然反感を買う可能性があります。
融通し合う相手がいなければ成立しない
同じタイミングで同じ動画を見ている人がいなければ、融通し合う事ができません。多くの人が同じ動画を同じタイミングで見ている場合には強力ですが。違うタイミングで見ていたり違う動画を見ている場合にはあまり効果は期待できません。ですので、Youtubeやニコニコ動画などの大量の動画から選択的に視聴するサイトには適用しにくい技術となります。
これ以外にも技術的に難しい問題点は複数あります。しかしながら、遅延が発生しても構わない形態のライブ放送であれば非常に有効な技術とも言えます。
まとめ
結論としてWebRTCのP2Pをビジネスで利用できるのは一部の用途に限られることとなります。有償サービスとして提供しようとするとWebRTCのサポートコストはネットワーク環境の影響が大きい分、大変なものとなります。
1on1でP2P利用とする場合でも片側は自社の管轄ネットワークにするなど、可能な限り接続環境を限定したいところです。そう考えるとサーバ経由になるTURNのみやMCU/SFUは経路が限定しやすいためサポートコストを抑えるメリットがありますね。