SkypeからWebRTCへ：Webビデオ通信の編成方法

ビデオ通信は、教師と生徒がVimboxプラットフォームで通信する主な方法です。 私たちはずっと前にSkypeを放棄し、いくつかのサードパーティソリューションを試し、最終的にWebRTCの束であるJanus-gatewayに落ち着きました。 しばらくの間、すべてが順調でしたが、それでもいくつかのマイナス点が忍び寄ってきました。 その結果、別のビデオ方向が作成されました。

新しい方向の責任者であるキリル・ロゴヴォイに、スカイエンのビデオ通信の進化、最終的に適用した問題、解決策、松葉杖について話すように頼みました。 この記事が、Webアプリケーションを介して独自のビデオを作成している企業にも役立つことを願っています。

ちょっとした歴史

2017年の夏、Skyeng開発の責任者であるSergey SafonovがBackend Confで「Skypeを放棄してWebRTCを実装した方法」について話しました。 ご希望の方は、パフォーマンスの記録を参考までにご覧ください（約45分）が、ここではその本質を簡単に説明します。

Skyengにとって、ビデオコミュニケーションは常に優先的な教師と学生のコミュニケーションでした。 最初はSkypeが使用されていましたが、主にログがなく、Webアプリケーションに直接統合できないため、多くの理由でカテゴリに適していませんでした。 そのため、あらゆる種類の実験を実施しました。

実際、ビデオ通信の要件はおよそ次のとおりです。

-安定性;

-レッスンあたりの低価格。

-レッスンの記録。

-誰がどれだけ話しているかを追跡します（生徒が先生よりも教室でもっと話すことが重要です）。

-線形スケーリング。

-UDPとTCPの両方を使用する機能。

2013年の最初はTokboxの実装を試みました。 すべてがうまくいきましたが、非常に高価であることが判明しました-レッスンあたり113ルーブル-そして利益を食べました。

その後、2015年にVoximplantが統合されました。 ここに必要なトラッキング機能がありました。誰がどれだけ言ったのか、そして解決策はもっと安かったです：音だけが録音されていれば、レッスンあたり20ルーブルが出てきました。 ただし、UDPを介してのみ機能し、TCPへの切り替えはスキルではありませんでした。 ただし、最終的には、学生の約40％が使用しました。

1年後、企業のクライアントは特定の要件で登場し始めました。 たとえば、すべてがブラウザを介して機能する必要があります。会社ではhttpとhttpsのみが開いています。 つまり、SkypeとUDPはありません。 企業顧客はお金なので、Tokboxに戻りましたが、価格の問題は解消されていません。

ソリューション-WebRTCとJanus

彼らは、 ピアツーピアのビデオ通信WebRTCにブラウザプラットフォームを使用することにしました。 彼女は、接続の確立、ストリームのエンコードとデコード、トラックの同期と品質管理とネットワークの不具合の処理を担当しています。 私たちの側では、カメラとマイクからのストリームが読み取られ、ビデオが描画され、接続が確立され、WebRTC接続が確立され、ストリームがそれに送信されること、および接続を確立するためにクライアント間で信号メッセージが送信されることを確認する必要があります（WebRTC自体はデータ形式のみを説明しますが、メカニズムは説明しません送信）。 クライアントがNATの背後にある場合、WebRTCはSTUNサーバーを接続します。これが解決しない場合は、TURNサーバーを接続します。

苦情があった場合のさらなる分析のためにレッスンを記録したいので、通常のp2p接続では不十分です。 そのため、 MeetechoのJanus Gatewayリピーターを介してWebRTCストリームを送信します。 その結果、クライアントは互いのアドレスを知らず、Janusサーバーのアドレスのみが表示されます。 また、シグナルサーバーの機能も実行します。 Janusには必要な多くの機能があります。クライアントでUDPがブロックされている場合、自動的にTCPに切り替わります。 UDPとTCPの両方のストリームを記録できます。 スケーラブル; エコーテスト用の組み込みプラグインもあります。 必要に応じて、TwilioのSTUNサーバーとTURNサーバーが自動的に接続されます。

2017年の夏には、メインプロセッサを占有しないように、2つのJanusサーバーに加えて、記録された生のオーディオおよびビデオファイルを処理するための追加のサーバーがありました。 接続時に、Janusサーバーは偶奇ベース（接続番号）で選択されました。 当時、これで十分でした、私たちの感覚によると、それは約4倍の安全マージンを与え、実装率は約80でした。同時に、価格は1レッスンあたり2ルーブルに加えて、開発とサポートに下がりました。

ビデオ通話のトピックに戻る

生徒と教師からのフィードバックを常に監視して、問題をタイムリーに特定して停止します。 2018年の夏までに、苦情の中で最初に、コミュニケーションの質は自信を持って修正されました。 一方で、これは他の欠点にうまく対処できたことを意味します。 一方で、何かをする必要が緊急にありました。レッスンが失われた場合、コストを失うリスクがあり、時には次のパッケージを購入するコストも伴います。また、入門レッスンが失われた場合、潜在的なクライアントを完全に失います。

当時、ビデオ通信はまだMVPモードでした。 簡単に言えば、彼らはそれを起動し、動作し、一度スケーリングし、それを行う方法を理解しました-それは素晴らしいことです。 動作する場合は、修正しないでください。 通信品質の問題に意図的に対処した人はいませんでした。 8月までに、これはこれ以上続行できないことが明らかになり、WebRTCとJanusで何が起こっているのかを理解するために別の領域を立ち上げました。

入力時に、この指示を受けました：MVPソリューション、指標なし、目標なし、改善プロセスなし、教師の7％がコミュニケーションの質について不満を述べています（学生に関するデータもありませんでした）。

仕事のために新しい方向が取られます

コマンドは次のようになります。

• 方向の頭、彼は主な開発者です。
• QAは、変更をテストし、通信の不安定な状態を作り出す新しい方法を探し、最前線から問題を報告します。
• アナリストは常に技術データのさまざまな相関関係を探し、ユーザーフィードバックの分析を改善し、実験結果を確認します。
• 製品マネージャーは、実験のための一般的な指示とリソースの割り当てを支援します。
• プログラミング自体と関連タスクで、2人目の開発者がしばしば助けます。

まず、通信品質の評価の変化（平均日数、週数、月数）を追跡する比較的信頼できるメトリックを設定します。 当時、これらは教師からの評点であり、学生からの評点が追加されました。 それから、彼らは、ダイナミクスの変化を修正して見るために、機能していないものの仮説を立て始めました。 たとえば、vp8コーデックをvp9に置き換えて、パフォーマンスを改善しました。 ヤヌスの設定で遊んでみて、他の実験を行いました-ほとんどの場合、役に立ちませんでした。

2番目の段階では、仮説が現れました。WebRTCはピアツーピアソリューションであり、中間でサーバーを使用します。 おそらく問題はここにありますか？ 彼らは掘り始め、ここでこれまでで最も重要な改善を見つけました。

その時点で、プールからのサーバーはかなり愚かなアルゴリズムに従って選択されました。それぞれがチャネルとパワーに応じて独自の「重み」を持ち、「重み」が大きい場所にユーザーを送信しようとしました。 。 その結果、サンクトペテルブルクの教師は、サンクトペテルブルクにあるヤヌスのサーバーではなく、モスクワを介してシベリアの生徒とコミュニケーションを取ることができました。

アルゴリズムがやり直されました。ユーザーがプラットフォームを開いたときに、Ajaxを使用してプラットフォームからすべてのサーバーにpingを収集します。 接続を確立するときに、最小量のpingのペア（教師サーバーと学生サーバー）を選択します。 pingの削減-サーバーまでのネットワーク距離が短くなります。 距離の短縮-パケットを失う可能性が低くなります。 パケット損失は、ビデオ通話の最大のマイナス要因です。 2か月間のネガティブのシェアは半分に減少しました（公平に、この時点で他の実験も行われましたが、これはほとんど確実に最も影響を受けました）。

最近、私たちは別の非自明ですが、明らかに重要なことを発見しました：太いチャネル上の1つの強力なJanusサーバーの代わりに、2つはよりシンプルで帯域幅が良くなります。 できるだけ多くの部屋（通信セッション）を同時に詰めることを望んで強力なマシンを購入した後、それは判明しました。 サーバーには、部屋の数に正確に変換できる帯域幅の制限があります。たとえば、300 Mbpsでどれだけ開くことができるかはわかっています。 サーバー上で開かれているルームが多すぎると、負荷が減少するまで新しいアクティビティ用に選択を停止します。 アイデアは、強力なマシンを購入したら、チャネルを最大までロードして、最終的には帯域幅ではなくプロセッサとメモリに置かれるようにすることでした。 しかし、プロセッサ、メモリ、およびディスクの負荷がまだ制限から非常に離れているという事実にもかかわらず、一定数のオープンルーム（420）の後、ネガティブが技術サポートに飛び込み始めました。 どうやら、ヤヌスの内部で何かが悪化しているようです。おそらくいくつかの制限もあります。 彼らは実験を開始し、帯域幅の制限を300 Mbpsから200 Mbpsに引き下げ、問題はなくなりました。 現在、制限と特性が低い3台の新しいサーバーを一度に購入しました。これにより、通信品質の安定した改善につながると考えています。 もちろん、私たちはそこに何が問題なのか理解し始めませんでした、松葉杖は私たちのものでした。 私たちの弁護では、その瞬間、緊急の問題をできるだけ早く解決する必要があり、美しくそれをする必要はなかったと言います。 さらに、JanusはCで書かれたブラックボックスであり、掘り下げるのは非常に高価です。

さて、その過程で：

• サーバーとクライアントの両方で更新可能なすべての依存関係を更新しました（これらも実験であり、結果に従いました）。
• 特定のケースに関連する特定されたすべてのバグを修正しました。たとえば、接続が落ちて自動的に復元されなかった場合など。
• ビデオコミュニケーションの分野で働いており、私たちの問題に精通している企業と多くのミーティングを行いました。ゲームのストリーミング、ウェブセミナーの開催、 役に立つと思われるすべてをテストしました。
• 鉄と教師とのコミュニケーションの質の技術的レビューを実施し、そこから最も不満が寄せられました。

実験とその後の変更により、教師間のコミュニケーションに対する不満を2018年1月の7.1％から2019年1月の2.5％に減らすことができました。

次は何ですか

Vimboxプラットフォームの安定化は、2019年の同社の主要プロジェクトの1つです。 勢いを維持できるようになり、最重要な苦情にビデオコミュニケーションが表示されなくなることを期待しています。 これらの苦情の大部分はコンピューターの遅れとユーザーのインターネットに関連していることを理解していますが、この部分を特定し、他のすべてを解決する必要があります。 それ以外はすべて技術的な問題であり、それに対処できるはずです。

主な困難は、品質を改善することが一般的にどの程度現実的であるかわからないことです。 この上限の明確化が主なタスクです。 したがって、2つの実験が計画されました。

1. ヤヌス経由のビデオを戦闘中の通常のp2pと比較してください。 この実験はすでに実行されており、ソリューションとp2pの間に統計的に有意な違いは見つかりませんでした。
2. ビデオ通信ソリューションのみで収益を上げる企業から（高価な）サービスを提供し、それらからのネガティブの量を既存のものと比較します。

これら2つの実験により、達成可能な目標を決定し、それに集中することができます。

さらに、作業順序で解決される多くのタスクがあります。

• 主観的なレビューの代わりに、通信品質の技術的指標を作成します。
• 発生した誤動作をより正確に分析し、いつ、どこで発生したのか、一見無関係なイベントがその瞬間に発生したかを把握するために、より詳細なセッションログを作成します。
• レッスンの前にコミュニケーションの品質の自動テストを準備しています。また、クライアントが手動で接続をテストできるようにして、鉄とチャンネルに起因するマイナスの量を減らします。
• 劣悪な条件、可変パケット損失などでのビデオ通信のストレステストを開発し、実施します。
• 問題が発生した場合にサーバーの動作を変更して、フォールトトレランスを向上させます。
• 同じSkypeと同様に、接続に何か問題がある場合はユーザーに警告し、問題が自分の側にあることをユーザーが理解できるようにします。

4月以降、ビデオ通信の方向は、Skyeng内の本格的な独立したプロジェクトになり、Vimboxの一部ではなく、独自の製品に取り組んでいます。 そして、これは、フルタイムモードでビデオを扱う人々を探し始めていることを意味します 。 まあ、いつものように、 私たちはたくさんの良い人を探しています。

もちろん、私たちはビデオ通信を扱う人々や企業と積極的にコミュニケーションを続けています。 私たちと経験を交換したい場合、私たちは幸せになります！ コメント、連絡先-全員にお答えします。