macOS の Chrome で 1080p 60fps での USB カメラからの映像出力に対応していたので、試してみました。

まとめ

• AV1 すごい
• 1080p 60fps きれい

環境

• WebRTC SFU は WebRTC SFU Sora
• コーデックは AV1
• 解像度は 1080p (1920×1080)
• ビットレートは 2.5 Mbps
• カメラは ロジクール Webカメラ C980GR
• 回線はインターネット経由
• サーバは Vultr ベアメタル
• 送信、受信ともに mac mini (M1) の 103.0.5060.53

実際の挙動

百聞は一見にしかずということで。動画をどうぞ。

Gyazo がそもそも 30fps しか対応していないので、30fps になっています。

今後

AV1 の圧倒的なパワーを見せられた感じがある。安定して配信をするにはとにかくビットレートを下げていく必要がある。ただビットレートを下げると画質が下がる、画質が下がると体験が悪くなる。

だからといってビットレートを上げると回線が不安定になった途端、止まったりブロックノイズがでたりする。そのため安定して低ビットレートで高画質を実現できる AV1 は本当に強い。

最近販売された NVIDIA Jetson Orin では AV1 のハードウェアアクセラレーター (HWA) が搭載されており 4K 60fps までの映像を HWA を利用して実現できる。ビットレートもおそらく 10 Mbps 程度での実現になるだろう。

WebRTC においての AV1 は WebRTC を一段階上の世界へ押し上げる技術になると感じた。

自社 SaaS ではベアメタルサーバ + Ubuntu 20.04 LTS を採用しています。

このサーバは自社製品である常時接続向け配信サーバのミドルウェアを載せており「可能な限り再起動をしたくない」のですが、セキュリティパッチなどで再起動を求められるといろいろ悩ましく、運用コストもかかるため、 Ubuntu Livepatch Service を導入しました。

これは Ubuntu Advantage for Infrastructure を契約することで利用可能になります。利用しているのがベアメタルサーバなので、費用は物理サーバ向けの 1 台 225ドル/ 年です。

このサービスは再起動のコストを考えると、圧倒的にコスパが良いと判断しました。

これだけで、運用で「あー、パッチ当てて、再起動しないと、いつメンテするかな」というのが減らせます。

導入も恐ろしく簡単でびっくりしました。

$ sudo ua attach <token>

もしベアメタルを利用していて再起動をできるだけしたくないサーバを運用しているかたは導入を検討されてみると良いかもしれません。

零細 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 のような低遅延が重視される場合は同じノードに接続を集めるという処理が一番効果的です。時雨堂では低遅延でありつつ耐障害性を持たせるという仕組みを開発してきました。

今後も耐障害性を向上し、運用コストを減らし、低遅延を維持する製品を提供していきます。