Skype から WebRTC へ: Web を介したビデオコミュニケーションをどのように組織したか

ビデオコミュニケーションは、Vimbox プラットフォーム上で教師と生徒の間で行われる主なコミュニケーション方法です。 私たちはずっと前に Skype を諦め、いくつかのサードパーティ ソリューションを試しましたが、最終的には WebRTC と Janus ゲートウェイの組み合わせに落ち着きました。 しばらくの間、私たちはすべてに満足していましたが、それでもいくつかのマイナス面が現れ続けました。 その結果、別のビデオディレクションが作成されました。

私は、新しい方向性の責任者であるキリル・ロゴヴォイ氏に、Skyeng でのビデオコミュニケーションの進化、発見された問題、最終的に使用した解決策と松葉杖について話すよう依頼しました。 この記事が、Web アプリケーションを使用して自社でビデオを作成する企業にも役立つことを願っています。

歴史を少し

2017 年の夏、Skyeng 開発責任者の Sergey Safonov は Backend Conf で、どのようにして「Skype を放棄し、WebRTC を実装した」のかについて話しました。 興味のある方は、スピーチの録画をご覧いただけます。 リンク （約45分）、ここではその本質を簡単に説明します。

Skyeng School にとって、ビデオ通信は常に教師と生徒のコミュニケーションの優先手段でした。 当初は Skype が使用されていましたが、主にログが不足していたり​​、Web アプリケーションに直接統合できないなど、さまざまな理由から完全には満足のいくものではありませんでした。 そこで、私たちはあらゆる種類の実験を実施しました。

実際、ビデオコミュニケーションに対する私たちの要件はおよそ次のとおりでした。
- 安定性;
— レッスンあたりの料金が安い。
— レッスンを録音する。
— 誰がどのくらい話すかを追跡する（レッスン中に生徒が教師よりも多く話すことが私たちにとって重要です）。
— 線形スケーリング;
- UDP と TCP の両方を使用する機能。

最初に試みたのは、2013 年に Tokbox を実装することでした。 すべては良かったのですが、レッスンごとに 113 ルーブルと非常に高価であることが判明し、利益を食いつぶしてしまいました。

そして 2015 年に Voximplant が統合されました。 これは、誰がどのくらい話したかを追跡するために必要な機能であり、同時にソリューションははるかに安価でした。音声のみを録音した場合、レッスンごとに 20 ルーブルかかりました。 ただし、UDP 経由でのみ機能し、TCP に切り替えることはできませんでした。 しかし、約 40% の学生が最終的にそれを使用しました。

XNUMX 年後、独自の要件を持つ法人顧客が増え始めました。 たとえば、すべてがブラウザ経由で機能する必要がありますが、会社では http と https のみを開きます。 つまり、Skype や UDP はありません。 法人顧客＝お金なのでTokboxに戻ったが、価格の問題は解決しなかった。

ソリューション - WebRTC と Janus

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

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

2017 年の夏、メインサーバーのプロセッサーを占有しないように、80 台の Janus サーバーに加えて、録音された生のオーディオ ファイルとビデオ ファイルを処理するための追加サーバーを実行していました。 接続するとき、Janus サーバーは奇数と偶数の基準 (接続番号) に基づいて選択されます。 当時はこれで十分でした。私たちの感覚によれば、約 2 倍の安全マージンがあり、実装率は約 XNUMX でした。同時に、価格は XNUMX レッスンあたり約 XNUMX ルーブルに減額され、さらに開発とサポートが追加されました。

ビデオコミュニケーションの話に戻ります

私たちは問題をタイムリーに特定して修正するために、生徒や教師からのフィードバックを常に監視しています。 2018 年の夏までに、通話品質は苦情の中で断然第 XNUMX 位になりました。 一方で、これは他の欠点を克服することに成功したことを意味します。 一方で、早急に何かをする必要がありました。レッスンが中断されると、場合によっては次のパッケージの購入費用とともにその価値を失うリスクがあり、また、入門レッスンが中断されると、潜在的な顧客を失うリスクがあります。全く。

当時、ビデオコミュニケーションはまだMVPモードでした。 簡単に言えば、彼らはそれを立ち上げ、うまくいき、一度拡張し、その方法を理解しました。まあ、素晴らしいです。 機能する場合は、修正しないでください。 通信品質の問題を意図的に取り上げた人は誰もいませんでした。 XNUMX 月までに、これを継続できないことが明らかになり、WebRTC と Janus の何が問題なのかを解明するために別の方向性を打ち出しました。

インプットでは、MVP ソリューション、指標なし、目標なし、改善プロセスなし、一方で 7% の教師がコミュニケーションの質について不満を抱いている (学生に関するデータもなかった) という指示を受けました。

新しい方向性が進行中です

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

• 部門の責任者であり、主要な開発者でもあります。
• QA は、変更のテストを支援し、不安定な通信状態を作り出す新しい方法を探し、最前線から問題を報告します。
• アナリストは常に技術データのさまざまな相関関係を探し、ユーザーからのフィードバックの分析を改善し、実験の結果を確認します。
• プロダクト マネージャーは、全体的な方向性と実験のためのリソースの割り当てを支援します。
• XNUMX 人目の開発者は、プログラミングや関連タスクを手伝うことがよくあります。

まず、通信品質評価の変化を追跡する比較的信頼性の高い指標を設定しました (数日、数週間、数か月にわたる平均)。 当時、これらは教師からの成績でしたが、後に生徒からの成績が追加されました。 それから彼らは、何が間違って機能しているのかについて仮説を立て、それを修正し、ダイナミクスの変化を観察し始めました。 私たちは、簡単に実現できる成果を目指しました。たとえば、vp8 コーデックを vp9 に置き換えると、パフォーマンスが向上しました。 私たちは Janus の設定をいじったり、他の実験を行ったりしましたが、ほとんどの場合、何も起こりませんでした。

第 XNUMX 段階では、WebRTC はピアツーピア ソリューションであり、中間にサーバーを使用するという仮説が浮かび上がりました。 おそらく問題はここにあるのでしょうか？ 私たちは調査を開始し、これまでで最も重要な改善を発見しました。

その時点で、かなり愚かなアルゴリズムを使用してプールからサーバーが選択されました。各サーバーにはチャネルと電力に応じて独自の「重み」があり、最大の「重み」を持つサーバーにユーザーを送信しようとしました。ユーザーが地理的にどこにいたかに注意を払います。 その結果、サンクトペテルブルクの教師は、サンクトペテルブルクの Janus サーバー経由ではなく、モスクワ経由でシベリアの生徒と通信できるようになりました。

アルゴリズムが見直されました。現在、ユーザーがプラットフォームを開くと、Ajax を使用してユーザーからすべてのサーバーへの ping が収集されます。 接続を確立するとき、最小量の ping のペア (教師サーバーと生徒サーバー) を選択します。 ping が少ないということは、サーバーまでのネットワーク距離が短いことを意味します。 距離が短いほど、パケットが失われる可能性が低くなります。 パケットロスはビデオ通信における最大のマイナス要因です。 否定的な意見の割合は XNUMX か月で半分に減少しました (公平を期すために言うと、この時期に他の実験も実施されましたが、これが最も大きな影響を及ぼしたのはほぼ間違いありません)。

私たちは最近、もう 300 つの明白ではないものの明らかに重要なことを発見しました。それは、太いチャネル上に 420 台の強力な Janus サーバーを置く代わりに、帯域幅が狭い 300 台のシンプルなサーバーを使用する方が良いということです。 このことは、できるだけ多くの部屋 (通信セッション) を同時に詰め込むことを期待して強力なマシンを購入した後に明らかになりました。 サーバーには帯域幅の制限があり、これを正確に部屋の数に換算できます。たとえば、200 Mbit/s で開くことができる部屋の数がわかっています。 サーバー上で開いているルームが多すぎると、負荷が軽減されるまで新しいアクティビティにそのサーバーを選択するのを停止します。 強力なマシンを購入したら、そのマシンにチャネルを最大限にロードし、最終的には帯域幅ではなくプロセッサとメモリによって制限されるようにするという考えでした。 しかし、プロセッサ、メモリ、ディスクへの負荷がまだ限界からほど遠いにもかかわらず、一定数のルーム (XNUMX) が開かれると、テクニカル サポートに否定的な意見が届き始めることが判明しました。 どうやら、ヤヌスの内部で何かが悪化しているようです。おそらく、そこにもいくつかの制限があるでしょう。 私たちは実験を開始し、帯域幅制限を XNUMX Mbit/s から XNUMX Mbit/s に下げたところ、問題は解決しました。 今回、制限や特性が低い新しいサーバーを一度にXNUMX台購入しました。これにより、安定した通信品質の向上につながると考えています。 もちろん、私たちはそこで何が起こっているのか理解しようとしたわけではなく、松葉杖がすべてです。 私たちの弁護のために、その瞬間、差し迫った問題をできるだけ早く解決する必要があり、それをきれいに解決する必要がなかったとしましょう。 さらに、私たちにとって Janus は C で書かれたブラックボックスであり、それをいじるのは非常に高価です。

さて、その過程で次のことを行います。

• サーバーとクライアントの両方で、更新できるすべての依存関係を更新しました (これらも実験であり、結果を監視しました)。
• 特定のケースに関連する特定のバグ (接続が切断され、自動的に復元されなかった場合など) をすべて修正しました。
• 私たちは、ビデオ通信の分野で活動し、私たちの問題を熟知している企業と何度も会議を開きました。 私たちは役に立ちそうなことはすべて試しました。
• 最も多くの苦情が寄せられた教師のハードウェアとコミュニケーションの質に関する技術的なレビューを実施しました。

この実験とその後の変更により、教師間のコミュニケーションに対する不満は、7,1年2018月の2,5%から2019年XNUMX月にはXNUMX%に減少することができました。

次のステップ

Vimbox プラットフォームの安定化は、2019 年の当社の主要プロジェクトの XNUMX つです。 この勢いを維持し、苦情の上位にビデオ コミュニケーションが含まれなくなることを期待しています。 これらの苦情のかなりの部分がユーザーのコンピュータやインターネットの遅延に関連していることは理解していますが、この部分を特定し、残りを解決する必要があります。 それ以外は技術的な問題なので、なんとか対応できそうです。

最大の難点は、実際にどのレベルまで品質を向上させることが可能なのかが分からないことです。 この上限を見つけることが主なタスクです。 したがって、次の XNUMX つの実験が計画されました。

1. 戦闘状態で Janus 経由のビデオと通常の P2P を比較します。 この実験はすでに実施されており、私たちのソリューションと p2p の間に統計的に有意な差は見つかりませんでした。
2. ビデオ通信ソリューションのみで収益を上げている企業から（高価な）サービスを提供し、そこからのマイナスの量を既存のサービスと比較してみましょう。

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

さらに、日常的に解決できるタスクが数多くあります。

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

XNUMX 月以降、ビデオ コミュニケーションの方向性は Skyeng 内の本格的な別のプロジェクトとなり、Vimbox の一部だけでなく、独自の製品を扱っています。 これは、私たちが人材を探し始めていることを意味します。 フルタイムモードでビデオを操作する。 さて、いつものように 私たちはたくさんの良い人材を求めています.

そしてもちろん、私たちはビデオコミュニケーションに取り組む人々や企業との積極的なコミュニケーションを続けます。 私たちと経験を交換したい場合は、喜んでさせていただきます! コメント、ご連絡ください - 全員にお答えします。

出所： habr.com