macOS の Chrome で 1080p 60fps での USB カメラからの映像出力に対応していたので、試してみました。
まとめ
- AV1 すごい
- 1080p 60fps きれい
環境
- WebRTC SFU は WebRTC SFU Sora
- コーデックは AV1
- 解像度は 1080p (1920×1080)
- ビットレートは 2.5 Mbps
- カメラは ロジクール We …
零細 IT パッケージメーカー経営視点での時雨堂のベンダーロックインについての考えをなんとなく書いておきたかったので書いてみます。特に目的はありません。雑な文章なので適当に読んでください。
ベンダーロックインとは
特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象のこと。Wikipedia から引用しました。自分の認識ともあってるので間違ってはいなさそうです。IT 企業で商用パッケージを採用するとほとんどの場合でベンダーロックインになるのは間違いないと思います。
むしろベンダーロックフリーな製品でビジネス的な競争力を作るのは難しいと思います。それができてる企業は本当にすごいです。
自社も間違いなくベンダーロックインさせる側です。ただ、できるだけベンダーロックインをさせないという手段もとっています。
ベンダーロックインさせつつ、逃げ道もつくる
時雨堂の製品である WebRTC SFU というリアルタイムな音声や映像、メッセージを配信するサーバー製品はオープンな規格である WebRTC を採用しつつも、規格として定義されていない部分についてはベンダーロックインになってしまいます。
この部分を自社では「ドキュメントで限りなく詳細に説明する」という手段をとっています。さらに、クライアント側の SDK はすべてオープンソースとして公開しています。つまり「時雨堂製品互換の製品を作る」と言うことが可能な状況を維持しています。
そんなこと言ったってやる企業いないでしょ？と思うかもしれません、私も思います。ただこれがいるんです。あるお客様で諸事情により特定の状況では弊社製品の採用が難しいと問題が発生しました。
ただ、お客様が開発していたシステムは時雨堂の製品にベンダーロックインしています。ここでお客様がとった判断は SDK はオープンソースだし、時雨堂製品の「開発しているシステムに必要な部分を実装したサーバーを開発する」といったものでした。私も SFU 開発アドバイザーとしてお手伝いに入り、お客様側で短期間で実際に動くものを作り上げました。
（この話を書く許可はいただいています）
これは仕様が不透明だったり SDK がオープンソースでなかったらとれない戦略だと思います。
ベンダーロックインを狙いつつも、仕様自体はオープンにしていくというのはありだと考えています。
お客様視点でのベンダーロックイン
実際、お客様からいろいろ話を聞いてみると「ベンダーロックイン」自体をネガティブに捉えているお客様はとても少ないように感じます。
技術がわかっている人ほど「ベンダーロックインされて長く付き合っていくべき」といった判断をされているようです。
むしろベンダーロックインフリーの製品（例えばオープンソース）を自分たちで維持するコストを天秤にかけてベンダーロックインされた方が良いとの意見が多いです。
そもそもオープンソース維持できるのであればベンダーを検討する必要もないわけですが。
ベンダーロックインする箇所を減らした製品
時雨堂の製品の場合は主にベンダーロックインする部分は認証の部分です。これは独自色が出やすいというのもあります。
それ以外の通信部分はそもそも「RFC のプロトコル仕様」にあわせなければいけないので、ベンダーロックはできません。できたとしたらただの独自プロトコルです。
時雨堂の製品で何か対応する場合でも可能な限りオープンな規格を採用しています。変なところで独自色がツヨイのは設定ファイルくらいでしょうか（INI 形式に近い key = value というシンプルな仕様にこだわっています)。
まとめ
顧客を逃がさないという点ではベンダーロックイン、つまり独自仕様、仕様非公開は最強です。一度導入してしまえば切り替えもかなり難しくなるでしょう。その機能に依存している製品であればなおさらです。
ただ「それで縛っている」というのが自分はかっこ悪く感じてしまうというのがあります。
それよりはできるだけオープンにしてそれでも使い続けてくれるお客様と仲良くしていきたいと思っています。
WebRTC のようなリアルタイム通信で求められるのは「一部のノードに問題が起きても利用し続けられる」事だと考えています。
そのため時雨堂では自社製品である WebRTC SFU Sora にクラスター機能を搭載し、一つのノードに障害が起きた場合でも再接続を行えばすぐにまた利用できるような仕組みを実現しています。
2022 年 6 月にリリース予定の次のバージョンでは、クラスター機能を改善し、より障害に強く、さらにクラスターの運用コストを下げる仕組みを入れています。
まとめ
- 起動したら自動でクラスターを構築し始める
- スプリットブレインが発生し、クラスターの全ノード数に対して、参加しているノードが半数未満になったサブクラスターはすべての接続を受け入れなくなる
- 過半数以上のノードが過半数未満のサブクラスターを自動で再参加させる
スプリットブレインについて
こちらがわかりやすいです。
https://docs.oracle.com/cd/E19787-01/820-6910/6ni73qiv8/index.html
クラスター機能
Sora のクラスター機能は「どのノードがどのチャネル（一般的にはルームや部屋）を担当するか」という情報をすべてのノードで共有しています。そのため、どのノードに繋ぎに行っても適切なノードに案内される仕組みが入っています。
またノードがどのチャネルを担当するかは、クラスターに参加しているノードそれぞれの同時接続数を確認し、空いているノードへ新規チャネルの担当を割り当てるため、負荷分散的な機能も含まれています。
クラスターの自動構築
今までのクラスター構築は手動でクラスターへの参加を行う必要がありましたが、次のリリースからはクラスターの構築を自動で行います。
仕組みとしては Sora の設定ファイルである sora.conf に、最初にクラスターの参加を試みるノード一覧を登録するだけです。
contact_node_name_list = sora1@192.0.2.1, sora2@192.0.2.2, sora3@192.0.2.3あとは Sora を起動させるだけで、これらのノードに自動でコンタクトを取りクラスターを構築します。
クラスターの分断（スプリットブレイン）発生時の挙動
クラスターで一番怖いのはスプリットブレインです。スプリットブレインとはクラスターがネットワーク切断などによりノードそれぞれが分断した状態になり、それぞれのノードが「相手のノードは死んだが自分は大丈夫」という状態になってしまう事です。
この状態が発生するとチャネル情報の共有がされていない状態になるため、複数のノードで同じチャネルが作られてしまい、サービスとしては破綻してしまいます。
これを回避するために Sora ではクラスターの分断が起きた際に「クラスターに参加しているノード数がもともとの半数未満になったサブクラスター」は「すべての接続を切断し、新規の接続を受け付けない」という仕組みを追加しました。
これにより、例えば 3 ノードで組んでいたクラスターが 2 と 1 に分かれてしまった場合、1 ノードの方は一切のリクエストを受け付けなくなります。そのためスプリットブレインが発生しなくなります。
ただ 3 ノードが 1 と 1 と 1 に分かれた時点で、サービス自体がすべて停止しますので、その場合は手動での復旧が必要になります。これを回避するにはクラスターのノード数を増やすことで発生確率を減らすことができます。
クラスター分断からの自動復旧
半数未満になったノードはすべての接続を切断し、すべての接続を受け入れなくしたタイミングから「自動でクラスターの再参加」を試みます。
クラスターに参加していた時に保持していた情報を利用し再度参加をしますが、このときに「過半数のノードが存在しているクラスター」へのみ参加を行います。この仕組みによりネットワークの分断が復旧さえすればクラスターも自動で復旧するようになっています。
WebRTC のような低遅延が重視される場合は同じノードに接続を集めるという処理が一番効果的です。時雨堂では低遅延でありつつ耐障害性を持たせるという仕組みを開発してきました。
今後も耐障害性を向上し、運用コストを減らし、低遅延を維持する製品を提供していきます。
