Skype에서 WebRTC까지: 웹을 통한 비디오 커뮤니케이션 구성 방법

비디오 커뮤니케이션은 Vimbox 플랫폼에서 교사와 학생 간의 주요 커뮤니케이션 방법입니다. 우리는 오래 전에 Skype를 포기하고 여러 타사 솔루션을 시도한 후 결국 WebRTC - Janus-gateway 조합에 정착했습니다. 한동안 우리는 모든 것에 만족했지만 여전히 몇 가지 부정적인 측면이 계속해서 나타났습니다. 이에 따라 별도의 영상 디렉션이 탄생하게 됐다.

나는 새로운 방향의 책임자인 Kirill Rogovoy에게 Skyeng의 비디오 커뮤니케이션의 진화, 발견된 문제, 우리가 궁극적으로 사용한 솔루션 및 목발에 대해 이야기하도록 요청했습니다. 이 기사가 웹 애플리케이션을 통해 자체적으로 비디오를 제작하는 회사에 도움이 되기를 바랍니다.

역사의 비트

2017년 여름, Skyeng 개발 책임자인 Sergey Safonov는 Backend Conf에서 우리가 "Skype를 포기하고 WebRTC를 구현"한 방법에 대해 이야기했습니다. 관심 있는 분들은 연설 녹음을 시청하실 수 있습니다. 링크 (~45분) 여기서는 그 본질을 간략하게 설명하겠습니다.

Skyeng School의 경우 영상 커뮤니케이션은 항상 교사와 학생 간의 의사소통을 위한 최우선 방법이었습니다. 처음에는 Skype를 사용했지만 주로 로그가 부족하고 웹 애플리케이션에 직접 통합할 수 없기 때문에 여러 가지 이유로 만족스럽지 못했습니다. 그래서 우리는 온갖 실험을 해봤습니다.

실제로 비디오 통신에 대한 우리의 요구 사항은 대략 다음과 같습니다.
- 안정성
— 수업당 저렴한 가격;
— 녹음 수업;
— 누가 얼마나 많이 말하는지 추적합니다(수업 중에 학생들이 교사보다 더 많이 말하는 것이 중요합니다).
- 선형 스케일링;
- UDP와 TCP를 모두 사용할 수 있습니다.

가장 먼저 시도한 것은 2013년에 Tokbox를 구현하는 것이었습니다. 모든 것이 좋았지 만 수업 당 113 루블이라는 매우 비싼 것으로 판명되었고 이익을 먹었습니다.

그러다가 2015년에 Voximplant가 통합되었습니다. 여기에 누가 얼마나 많이 말했는지 추적하는 데 필요한 기능이 있었고 동시에 솔루션은 훨씬 저렴했습니다. 오디오만 녹음하는 경우 레슨당 20루블의 비용이 듭니다. 그러나 UDP를 통해서만 작동했으며 TCP로 전환할 수 없었습니다. 그러나 약 40%의 학생들이 결국 이를 사용하게 되었습니다.

XNUMX년 후, 우리는 고유한 요구 사항을 가진 기업 고객을 확보하기 시작했습니다. 예를 들어, 모든 것이 브라우저를 통해 작동해야 하며 회사는 http와 https만 엽니다. 즉, Skype나 UDP가 없습니다. 기업고객=돈이라 톡박스로 돌아왔지만 가격 문제는 사라지지 않았다.

솔루션 - WebRTC 및 Janus

사용하기로 결정 PXNUMXP 비디오 통신을 위한 브라우저 플랫폼 WebRTC. 연결 설정, 스트림 인코딩 및 디코딩, 트랙 동기화, 네트워크 결함 처리를 통한 품질 관리를 담당합니다. 우리는 카메라와 마이크에서 스트림을 읽고, 비디오를 그리고, 연결을 관리하고, WebRTC 연결을 설정하고 스트림을 전송하고, 연결을 설정하기 위해 클라이언트 간에 신호 메시지를 전송해야 합니다(WebRTC 자체는 데이터 형식이지만 메커니즘 전송은 아님). 클라이언트가 NAT 뒤에 있으면 WebRTC는 STUN 서버를 연결하고, 이것이 도움이 되지 않으면 TURN 서버를 연결합니다.

불만 사항이 있을 경우 추가 분석을 위해 수업을 녹화하고 싶기 때문에 정기적인 P2P 연결만으로는 충분하지 않습니다. 따라서 우리는 릴레이를 통해 WebRTC 스트림을 보냅니다. Meetecho의 야누스 게이트웨이. 결과적으로 클라이언트는 서로의 주소를 알지 못하며 Janus 서버 주소만 볼 수 있습니다. 또한 신호 서버의 기능도 수행합니다. Janus에는 우리에게 필요한 많은 기능이 있습니다. 클라이언트가 UDP를 차단한 경우 자동으로 TCP로 전환합니다. UDP 및 TCP 스트림을 모두 기록할 수 있습니다. 확장 가능; 에코 테스트를 위한 플러그인도 내장되어 있습니다. 필요한 경우 Twilio의 STUN 및 TURN 서버가 자동으로 연결됩니다.

2017년 여름, 우리는 두 개의 Janus 서버를 실행했고, 기본 서버의 프로세서를 점유하지 않기 위해 녹음된 원시 오디오 및 비디오 파일을 처리하기 위한 추가 서버를 운영했습니다. 연결시 Janus 서버는 홀짝수(연결번호)로 선택되었습니다. 그 당시에는 이것으로 충분했고 우리 감정에 따르면 약 80배의 안전 마진을 제공했으며 구현 비율은 약 2이었습니다. 동시에 가격은 레슨당 ~XNUMX 루블과 개발 및 지원으로 인하되었습니다.

비디오 커뮤니케이션 주제로 돌아가기

우리는 적시에 문제를 식별하고 수정하기 위해 학생과 교사의 피드백을 지속적으로 모니터링합니다. 2018년 여름에는 통화 품질이 불만 사항 중 XNUMX위를 확고히 차지했습니다. 한편으로 이는 우리가 다른 단점을 성공적으로 극복했음을 의미합니다. 반면에 긴급하게 조치를 취해야 했습니다. 수업이 중단되면 다음 패키지 구매 비용과 함께 그 가치를 잃을 위험이 있으며, 입문 수업이 중단되면 잠재 고객을 잃을 위험이 있습니다. 전부.

그 당시 우리의 영상통화는 여전히 MVP 모드였습니다. 간단히 말해서, 그들은 그것을 출시했고, 효과가 있었고, 한 번 확장했고, 그것을 수행하는 방법을 이해했습니다. 음, 훌륭합니다. 작동한다면 고치지 마세요. 의사소통 품질 문제를 의도적으로 언급한 사람은 아무도 없습니다. XNUMX월이 되자 이것이 계속될 수 없다는 것이 분명해졌고, 우리는 WebRTC와 Janus의 문제점을 파악하기 위한 별도의 방향을 시작했습니다.

입력 시 다음과 같은 방향이 제시되었습니다. MVP 솔루션, 지표 없음, 목표 없음, 개선 프로세스 없음, 교사의 7%가 의사소통 품질에 대해 불평함(학생에 대한 데이터도 없음).

새로운 방향이 진행되고 있다

명령은 다음과 같습니다.

• 주요 개발자이기도 한 부서장입니다.
• QA는 변경 사항 테스트를 돕고, 불안정한 통신 조건을 만드는 새로운 방법을 찾고, 최전선에서 문제를 보고합니다.
• 분석가는 기술 데이터에서 다양한 상관관계를 지속적으로 찾고, 사용자 피드백 분석을 개선하며, 실험 결과를 확인합니다.
• 제품 관리자는 실험을 위한 전반적인 방향과 자원 할당을 돕습니다.
• 두 번째 개발자는 프로그래밍 및 관련 작업을 돕는 경우가 많습니다.

우선, 우리는 통신 품질 평가의 변화(일, 주, 월별 평균)를 추적하는 비교적 신뢰할 수 있는 측정 기준을 설정했습니다. 당시에는 교사의 성적이었고 나중에 학생의 성적이 추가되었습니다. 그런 다음 그들은 무엇이 잘못되었는지에 대한 가설을 세우고 이를 수정하고 역학의 변화를 살펴보기 시작했습니다. 우리는 쉬운 결과를 선택했습니다. 예를 들어 vp8 코덱을 vp9로 교체하면 성능이 향상되었습니다. 우리는 Janus 설정을 가지고 놀고 다른 실험을 수행하려고 시도했지만 대부분의 경우 아무 결과도 얻지 못했습니다.

두 번째 단계에서는 WebRTC가 PXNUMXP 솔루션이고 중간에 서버를 사용한다는 가설이 나타났습니다. 아마도 문제는 여기에 있을까요? 우리는 조사를 시작했고 지금까지 가장 중요한 개선 사항을 발견했습니다.

그 순간, 다소 어리석은 알고리즘을 사용하여 풀의 서버가 선택되었습니다. 각각은 채널과 전력에 따라 고유한 "가중치"를 갖고 있었고 우리는 사용자를 가장 큰 "가중치"를 가진 서버로 보내려고 했습니다. 사용자가 지리적으로 어디에 있는지 주의를 기울입니다. 결과적으로 상트페테르부르크의 교사는 상트페테르부르크의 Janus 서버를 통하지 않고 모스크바를 통해 시베리아 학생과 통신할 수 있었습니다.

알고리즘이 다시 작성되었습니다. 이제 사용자가 플랫폼을 열면 Ajax를 사용하여 해당 사용자로부터 모든 서버로의 핑을 수집합니다. 연결을 설정할 때 가장 적은 양의 핑 쌍(교사-서버 및 학생-서버)을 선택합니다. 핑이 적다는 것은 서버까지의 네트워크 거리가 줄어든다는 것을 의미합니다. 거리가 짧을수록 패킷 손실 가능성이 낮아집니다. 패킷 손실은 영상통신에 있어 가장 큰 부정적 요소입니다. 부정적인 비율은 XNUMX개월 만에 절반으로 줄었습니다. (공평하게 말하면 이 당시에 다른 실험도 수행되었지만 거의 확실히 이 실험이 가장 큰 영향을 미쳤습니다.)

우리는 최근 또 다른 분명하지 않지만 분명히 중요한 사실을 발견했습니다. 즉, 두꺼운 채널에 있는 하나의 강력한 Janus 서버 대신 더 얇은 대역폭을 가진 두 개의 간단한 서버를 갖는 것이 더 낫다는 것입니다. 이는 우리가 동시에 많은 공간(커뮤니케이션 세션)을 밀어넣기 위해 강력한 기계를 구입한 후에 분명해졌습니다. 서버에는 대역폭 제한이 있는데, 이를 룸 수로 정확하게 해석할 수 있습니다. 예를 들어 300Mbit/s에서 열 수 있는 룸 수를 알고 있습니다. 서버에 너무 많은 공간이 열려 있으면 부하가 줄어들 때까지 새로운 활동에 대한 공간 선택을 중단합니다. 강력한 시스템을 구입하면 채널을 최대로 로드하여 결국 대역폭이 아닌 프로세서와 메모리에 의해 제한된다는 아이디어였습니다. 그러나 특정 수의 열린 공간(420개) 이후에는 프로세서, 메모리 및 디스크의 부하가 여전히 한계와 거리가 멀다는 사실에도 불구하고 기술 지원에 부정적인 영향을 미치기 시작하는 것으로 나타났습니다. 분명히 Janus 내부에서 뭔가가 악화되고 있는 것 같습니다. 아마도 거기에도 몇 가지 제한 사항이 있을 것입니다. 우리는 실험을 시작하여 대역폭 제한을 300에서 200 Mbit/s로 낮추었고 문제는 사라졌습니다. 이제 우리는 한도와 특성이 낮은 새 서버 XNUMX대를 한꺼번에 구입했는데, 이것이 통신 품질의 안정적인 향상으로 이어질 것이라고 생각합니다. 물론 우리는 거기에서 무슨 일이 일어나고 있는지 알아내려고 노력하지 않았습니다. 목발이 전부입니다. 우리를 변호하기 위해 그 순간 긴급한 문제를 아름답게 해결하는 것이 아니라 가능한 한 빨리 해결해야 한다고 가정해 보겠습니다. 게다가 우리에게 Janus는 C로 작성된 블랙박스이기 때문에 이를 조작하는 데 비용이 매우 많이 듭니다.

그 과정에서 우리는:

• 서버와 클라이언트 모두에서 업데이트할 수 있는 모든 종속성을 업데이트했습니다(이 역시 실험이었으며 결과를 모니터링했습니다).
• 예를 들어 연결이 끊어지고 자동으로 복원되지 않는 경우와 같은 특정 사례와 관련된 식별된 모든 버그를 수정했습니다.
• 우리는 비디오 커뮤니케이션 분야에 종사하고 우리의 문제에 대해 잘 알고 있는 회사들과 많은 회의를 가졌습니다. 게임 스트리밍, 웹 세미나 조직; 우리는 우리에게 유용해 보이는 모든 것을 시도했습니다.
• 가장 많은 불만이 제기된 교사의 하드웨어 및 커뮤니케이션 품질에 대한 기술 검토를 수행했습니다.

실험과 그에 따른 변화를 통해 교사 간 소통에 대한 불만은 7,1년 2018월 2,5%에서 2019년 XNUMX월 XNUMX%로 줄어들었습니다.

다음 단계

Vimbox 플랫폼 안정화는 Vimbox의 2019년 주요 프로젝트 중 하나입니다. 우리는 추진력을 유지할 수 있고 더 이상 상위 불만 사항에서 영상 커뮤니케이션을 볼 수 없을 것이라는 큰 희망을 갖고 있습니다. 당사는 이러한 불만의 상당 부분이 사용자의 컴퓨터 및 인터넷 지연과 관련되어 있음을 알고 있지만, 이 부분을 판단하고 나머지를 해결해야 합니다. 다른 모든 것은 기술적인 문제이므로 우리가 대처할 수 있어야 할 것 같습니다.

가장 큰 어려움은 품질을 향상시키는 것이 실제로 어느 수준까지 가능한지 알 수 없다는 것입니다. 이 한도를 알아내는 것이 주요 작업입니다. 따라서 두 가지 실험이 계획되었습니다.

1. 전투 상황에서 Janus를 통한 비디오를 일반 p2p와 비교하십시오. 이 실험은 이미 수행되었으며, 우리 솔루션과 p2p 간에 통계적으로 유의미한 차이는 발견되지 않았습니다.
2. 영상통신 솔루션으로만 돈을 버는 기업의 (비싼) 서비스를 공급하고, 기존 기업과 부정적인 정도를 비교해보자.

이 두 가지 실험을 통해 우리는 달성 가능한 목표를 식별하고 이에 집중할 수 있습니다.

또한 정기적으로 해결할 수 있는 여러 가지 작업이 있습니다.

• 우리는 주관적인 리뷰 대신 커뮤니케이션 품질에 대한 기술적 지표를 만듭니다.
• 우리는 발생한 오류를 보다 정확하게 분석하고, 오류가 정확히 언제 어디서 발생했는지, 그리고 그 순간 관련 없어 보이는 이벤트가 무엇인지 이해하기 위해 보다 자세한 세션 로그를 만듭니다.
• 우리는 수업 전에 자동 연결 품질 테스트를 준비하고 고객의 하드웨어와 채널로 인해 발생하는 부정적인 정도를 줄이기 위해 클라이언트에게 수동으로 연결을 테스트할 수 있는 기회를 제공합니다.
• 다양한 패킷 손실 등 열악한 조건에서 더 많은 비디오 통신 부하 테스트를 개발하고 수행할 것입니다.
• 내결함성을 높이기 위해 문제가 발생할 경우 서버의 동작을 변경합니다.
• Skype처럼 연결에 문제가 있는 경우 사용자에게 경고하여 문제가 자신에게 있음을 이해할 수 있도록 합니다.

지난 XNUMX월부터 영상통신 방향은 스카이엥 내에서 본격적인 별도 프로젝트로 자리잡아 단순히 빔박스의 일부가 아닌 자체 제품을 다루게 됐다. 이는 우리가 사람들을 찾기 시작했다는 것을 의미합니다. 풀타임 모드로 비디오 작업하기. 글쎄, 언제나처럼 우리는 좋은 사람들을 많이 찾고 있습니다.

그리고 물론, 우리는 영상통신을 활용하는 사람들 및 기업들과 계속해서 적극적으로 소통하고 있습니다. 우리와 경험을 교환하고 싶다면 기꺼이 도와드리겠습니다! 댓글을 달고 연락하세요. 모두에게 답변해 드리겠습니다.

출처 : habr.com