Ayame という WebRTC P2P 向けのシグナリングサーバを公開して 1 年過ぎて、色々わかったことがあるので、まとめて、さらに今後どうしていくかを書いていきます。
前提
時雨堂では Ayame をビジネスに繋げるきは全くありません。あくまで「WebRTC で P2P」をできる限り使いやすく、簡単にしていくという思いがあります。
また得られた情報をできるだけアウトプットすることで、 WebRTC 界隈への貢献をしていきたいとも思っています。閉じた世界で自分たちだけが利益を得るというのはその市場を狭めてしまうと考えているからです。
利益は WebRTC SFU であげる前提です。P2P が好き、WebRTC が広まって欲しいという気持ちで WebRTC P2P 向けシグナリングサーバを公開しています。
WebRTC P2P はビジネスとして難しい
WebRTC P2P 向けのシグナリングサーバに関してビジネス的な相談は 1 件も来たことがありません。もともと WebRTC SFU な会社というのがあるのかもしれませんが、それにしても来ません。
まぁそもそも特定の技術に詳しいからご飯が食べれるほど甘い世界ではないのですが … 。
ここでは実際に開発、運用して学んだことを書いていきます。
誰にでもできる
シグナリングサーバの仕組みって難しくありません。3 日くらい勉強するだけで動くものであれば誰でも作れます。
つまり「マネがしやすい」です。もしうまく言っても誰もが簡単に実現可能ですし、自前で作ることができてしまいます。
なのでシグナリングサービスではビジネスはできません。それ以外の付随の何かを提供する必要があります。
TURN 運用がめんどくさすぎる
TURN がなければまぁいいんですが、ビジネスでやって TURN なしはありえないので、自前で TURN 運用をする必要があります。TURN サーバをスケールさせるのはロードバランスくらいしか方法がないので、これまためんどくさいです。
TURN とシグナリング、両方のサーバを運用するのめんどくさすぎます。さらに TURN は UDP / TCP / TLS の 3 つあるわけで … やってられません。
サポートコストが高すぎる
P2P なので「お客様環境」にめちゃくちゃ依存します。そんなの解析するってのは無理な話です。「ポート開けてください」からはじまりますが、殆どの場合は「お客様のお客様環境」という状況だと思います。
それのサポートなんかお金いくらもらってもしんどいです。さらにお金がないから「P2P」を選択している可能性が高いので、まぁつまりそゆことです。
SDK メンテコストが高すぎる
Web SDK だけでも複数ブラウザ対応をする必要があるのに、iOS / Andorid というモバイルだけでなく、 Unity や Windows といった環境への対応を考える必要があります。「使ってもらう」ためには SDK が必須です。
この SDK の費用コストって馬鹿にできません。
さらに libwebrtc は 6 週間単位で上がっていくわけです、それに追従するとなると … 。
やってみて失敗した事
Ayame は色々やってみましたが、うまく行かなかったのもたくさんあります。いくつか抜粋して書いていきます。
あきらかな検証不足
Ayame 本体や SDK の検証が甘く、色々バグが出てしまい実際に使っていただいた方々に迷惑をおかけしてしまいました。これは本当に申し訳ないと思っています。
最新版はガッツリ検証を行ったものですのでご安心いただければと思います。
Go にこだわりすぎた
汎用的な言語で開発し、皆が気軽にカスタマイズできるようにと思っていましたが、別にそこは求められていませんでした。
商用で使えるレベルとは言えなかった
商用でも利用可能なものを目指すと言っておりましたが、バグの多さ、挙動の不安定さから残念ながら商用レベルとは言えないものを提供していたのは、大変申し訳なかったと思っています。
特にログ周りや運用に関する仕組みはボロボロだったのは反省しています。
iOS / Android / Unity SDK にこだわりすぎた
こだわりすぎたことにより、結果的に全て正式にリリースできませんでした。今後はこれらの SDK が使いたい場合は Sora を使ってもらうという方針に切り替えました。無料で維持できる内容をきっちりと決めてやるべきでした。
ユーザが本当に欲しかったもの
ビジネスでは難しいですが、継続するためにどうしていくかというのを色々考えて取り組んできました。ただ想定と現実が違うのもありましたので、それをまとめていきます。
WebRTC シグナリングの仕様
一番の以外さはこれです。シンプルなシグナリングの仕様さえあれば、 Ayame を使わず自分で作ることができます。
つまり「こんな感じの仕様で商用レベルで使えるよ」という保証がある仕様が公開されているのが重要だったと感じています。
無料で使える WebRTC シグナリングサービス
無料で使えて、落ちなくて安定しているサービスがほしいのです。機能は重要ではありません。WebRTC P2P に求められているのは繋がってすぐ動くことです。追加の機能が欲しい人達はそもそも P2P を検討しません。
1:1 でしか使えないという制限をかけているにもかかわらず、多くのユーザに使ってもらえています。
これは間違いなく、無料で、安定して使えていることが理由です。
無料で使える WebRTC シグナリングパッケージ
OSS で公開していますが、結局使えることが重要なので別に OSS でなくても、無料でパッケージとして公開されていれば良さそうです。
とはいえ、もちろん OSS で公開していきますが … 。
無料で使える SDK
これも一緒です。特に iOS / Android や Unity で使いたい人は使えなければ諦めるか、お金で解決するか、自分でがんばります。そこは WebRTC P2P のターゲット層ではありません。Web SDK があれば十分といことがわかりました。
無料で使えて、メンテナンスされ続けていくもの
結果的には、無料で使えて、メンテナンスされて行ってれば特に不満はなさそうという事がわかりました。
多機能である必要もなく、iOS や Android の SDK がある必要もありませんでした。大事なのは「最低限を簡単に実現できること」だったことがよくわかりました。
また「最低限以外がやりたければお金を出せば良い」というのがあるのも重要というのがわかりました。
今後
最低限の機能ではあるが、無料で使えて、安定しており、メンテナンスされていくサービスとサーバと SDK を提供していきたいと考えています。
シグナリング仕様の明確化
一番想定していたのと異なったのは「シグナリングの仕様」を資料化して公開したことで、それを読んでオレオレクライアントを作ったりしはじめたことです。
安定して稼働しているサーバの仕様が公開されるというのはなかなか良いっぽいので、これはもっと名確認していったりしようと思っています。
ブラウザとモバイルの SDK は Web 版と React Native 版のみに絞る
Web SDK 以外にはモバイル向けとして React Native SDK を提供していく予定です。これは自社で React Native 向け WebRTC ライブラリを開発しているという理由が一番の理由です。
CLI 向けの SDKの検討
Python と Go の SDK を検討しています。これは aiortc と Pion を使った Ayame 向け SDK です。主に CLI から利用してもらうことを想定しています。
シグナリングサーバの開発言語を Go から Erlang/OTP へ
別に Go で書かれていることは重要ではないことがわかったので、時雨堂が得意とする Erlang/OTP で開発予定です。
パッケージ化して、展開して起動さえできれば特に問題がないと判断しました。Go 版も当面は並行して維持していきます。
1:1 での利用の強みを活かす
Ayame は 1:1 に特化しています。そのため DataChannel が生きると考えています。そこは強みとして育てていく予定です。Python や Go の SDK を提供しようと考えているのもそれが理由です。
WebRTC Stats API への対応
callstats.io という素敵な企業があるのですが、それの劣化版みたいなものを提供しようと考えています。もちろん無料です。
やろうとしているのは Ayame ユーザの統計情報をサーバ側に溜め込んで、それを公開していくというものです。主に TURN の利用率やコーデック利用率などですね。色々取れるのでやっていきたいです。
TURN 統計情報
TURN の統計情報もガッツリとっていきたいと考えています。今は coturn を使っていますが、もっとガッツリ統計がとりたいので、ちょっと自作の TURN サーバを開発するのもありか？と思っています。こちらはクローズドソースでいく予定なので、ご了承ください。
他にも出てきたら追記していきます。
