<div id="readability-page-1" class="page"><div itemprop="articleBody">
    <p>안녕하세요, 하이퍼커넥트 Media Lab의 Media Server Team에서 Media Server Engineer로 일하고 있는 Simon.Y 입니다.</p>

<p>저희 Media Server Team은 “사람들이 제약 없이 모여서 소통할 수 있도록 안정적인 연결을 제공하고 미디어 품질을 높이기 위해 노력한다”는 미션을 가지고 있습니다.
이 목표 아래, 대규모 실시간 스트리밍 서비스를 지원하는 미디어 서버를 개발하고, 전 세계에 위치한 미디어 서버 인프라를 운영하고 있습니다.
지난 글(<a href="https://hyperconnect.github.io/2022/12/30/introduction-to-media-server.html">글로벌 라이브 스트리밍을 지탱하는 하이퍼커넥트 미디어 서버 인프라를 소개합니다</a>)에서는 WebRTC 기반 글로벌 라이브 스트리밍을 제공하기 위한 Media Server Team의 미디어 서버 인프라의 구성을 구체적으로 설명드렸습니다.</p>

<p>하이퍼커넥트에서는 다년간 축적한 영상 커뮤니케이션 및 라이브 스트리밍 기술을 여러 프로덕트에서 활용해왔습니다.
1:1 영상 통화 기술은 아자르(Azar) 서비스에서 활용되고 있고, 지난 글에서 언급했던 1:N 라이브 스트리밍 기술은 아자르 내 아자르 라이브(Azar Live) 서비스에서 활용되고 있습니다.
뿐만 아니라 저희는 N:N 그룹 통화 기술도 개발하여 다양한 곳에서 활용하고 있습니다.</p>

<p>혹시 여러분께서는 수십 명의 사용자가 동시에 소통할 수 있는 그룹 통화(그룹콜) 서비스를 제공하는 서버는 어떻게 구성되어 있는지 생각해보신 적이 있나요?
라이브 스트리밍 서비스에서는 호스트 한 명의 미디어를 다수의 시청자들에게 안정적으로 전달하는 것이 중요합니다.
이때 사용자는 미디어 서버 인프라와 연결되어 미디어를 보내거나(호스트) 받기만 하면 됩니다(시청자).
반면, 그룹콜 서비스에서는 참여자가 자신의 미디어를 다른 참여자들에게 전달할 뿐만 아니라, 모든 참여자의 미디어를 안정적으로 수신하는 것도 매우 중요합니다.</p>

<p>이번 글에서는 하이퍼커넥트의 그룹 통화 서비스를 뒷받침하고 있는 그룹콜 미디어 서버 인프라를 소개하고자 합니다.</p>

<figure>
  <img data-action="zoom" src="https://hyperconnect.github.io/assets/2024-09-25-introduction-to-groupcall-media-server/01-pairs.jpg" alt="그림 1. 하이퍼커넥트는 페어스(Pairs)에 2022년 8월부터 그룹 통화 서비스를 제공하고 있습니다.">
  <figcaption>그림 1. <a href="https://hyperconnect.com/ko/company/news/62f4afb09ccec1003d7df0a2/" target="_blank">하이퍼커넥트는 페어스(Pairs)에 2022년 7월부터 그룹 통화 서비스를 제공하고 있습니다.</a></figcaption>
</figure>

<h2 id="라이브-스트리밍-인프라로-그룹콜-서비스를-구현할-수-있을까">라이브 스트리밍 인프라로 그룹콜 서비스를 구현할 수 있을까?</h2>

<p>여러분께서는 아자르에서 멀티게스트 라이브를 보신 적이 있나요?
아자르 멀티게스트 라이브에서는 호스트를 포함해 최대 5명의 참여자가 동시에 소통하며 라이브의 재미를 더하고 있습니다.
그렇다면 이 방식으로 그룹콜 서비스를 구현하면 별도의 그룹콜 미디어 서버 인프라를 만들 필요가 없지 않을까요?
아자르 라이브의 멀티게스트 기능을 통해 라이브 스트리밍 미디어 서버 인프라를 간단하게 설명하고, 왜 그룹콜 미디어 서버 인프라가 필요한지 알아보겠습니다.</p>

<figure>
  <img data-action="zoom" src="https://hyperconnect.github.io/assets/2024-09-25-introduction-to-groupcall-media-server/02-azarlive.png" alt="그림 2. 아자르 라이브의 멀티게스트 기능">
  <figcaption>그림 2. 아자르 라이브의 <a href="https://help.azarlive.com/hc/ko/articles/18182084164249-%EB%A9%80%ED%8B%B0%EA%B2%8C%EC%8A%A4%ED%8A%B8-%EA%B8%B0%EB%8A%A5" target="_blank">멀티게스트 기능</a></figcaption>
</figure>

<p>아자르 라이브에서는 호스트 1명과 게스트 4명, 최대 5명이 동시에 소통하고, 여러 시청자들이 이 장면을 실시간으로 시청할 수 있는 멀티게스트 기능을 지원하고 있습니다.
이해를 돕기 위해 Alice, Bob, Charlie, David가 멀티게스트 라이브를 진행 중인 상황을 가정해 봅시다.</p>

<figure>
  <img data-action="zoom" src="https://hyperconnect.github.io/assets/2024-09-25-introduction-to-groupcall-media-server/03-livestreaming.png" alt="그림 3. 라이브 스트리밍 미디어 서버 인프라의 관점에서 살펴본 아자르 라이브 멀티게스트 기능">
  <figcaption>그림 3. 라이브 스트리밍 미디어 서버 인프라의 관점에서 살펴본 아자르 라이브 멀티게스트 기능</figcaption>
</figure>

<p>멀티게스트 기능을 라이브 스트리밍 미디어 서버 인프라의 관점에서 보면, 참여자를 모두 호스트이자 시청자로 구현한 것이라 볼 수 있습니다.
예를 들어, Alice는 자신의 방송을 위해 미디어 서버 인프라와 연결되어 있고, 다른 참여자들인 Bob, Charlie, David와 소통하기 위해 각각 미디어 서버 인프라와 별도의 연결을 맺어 그들의 방송을 시청하고 있는 것입니다.
즉, 멀티게스트 라이브 참여자들은 자신이 방송하는 PeerConnection 1개와 다른 참여자들의 방송을 시청하는 PeerConnection 3개, 총 4개의 PeerConnection을 유지하는 셈입니다.
시청자들 또한 4개의 PeerConnection을 맺어서 Alice, Bob, Charlie, David의 방송을 각각 보고 있습니다.</p>

<p>하이퍼커넥트의 그룹 통화 서비스에서는 방 하나에 최대 50명의 참여자가 자유롭게 참가하거나 퇴장하면서 WebRTC 연결을 통해 모든 참여자의 영상과 음성을 실시간으로 주고받을 수 있어야 합니다.
만약 50명의 참여자가 멀티게스트 방식처럼 그룹콜을 진행한다면, 각 참여자들은 미디어 서버 인프라와 50개의 PeerConnection을 맺어야 합니다.
이는 각 참여자의 단말에 네트워크 연결 관점에서 상당한 부담을 줄 수 밖에 없습니다.
그렇다면 이 문제를 어떻게 해결할 수 있을까요?</p>

<h2 id="그룹콜-미디어-서버의-기본-구조">그룹콜 미디어 서버의 기본 구조</h2>

<p>컴퓨터에서 동영상을 재생할 때는 비디오 트랙과 오디오 트랙을 동시에 처리합니다.
WebRTC에서도 PeerConnection을 통해 비디오 트랙과 오디오 트랙을 각각 전송한 뒤, 이를 맞춰서 화면에 출력함으로써 동영상이 재생됩니다.
또 WebRTC는 하나의 PeerConnection에 여러 개의 비디오와 오디오 트랙을 추가할 수 있어, 여러 영상을 동시에 전송하는 것이 가능합니다.
더 나아가 PeerConnection은 트랙별로 송수신 방향을 설정할 수 있기 때문에, 하나의 연결로 미디어 송신과 수신을 동시에 처리할 수 있습니다.
이러한 WebRTC의 기능을 활용한다면 앞서 언급한 PeerConnection이 너무 많아지는 문제를 효과적으로 해결할 수 있습니다.
PeerConnection 설정 방법은 아래 참고자료의 RFC 메모<a href="#참고자료">[1, 2, 3]</a>를 참조하시면 좋을 것 같습니다.</p>

<figure>
  <img data-action="zoom" src="https://hyperconnect.github.io/assets/2024-09-25-introduction-to-groupcall-media-server/04-groupcall.png" alt="그림 4. 그룹콜 미디어 서버의 기본적인 구조">
  <figcaption>그림 4. 그룹콜 미디어 서버의 기본적인 구조</figcaption>
</figure>

<p>그림 4는 하나의 PeerConnection으로 송수신을 처리하는 그룹콜 미디어 서버의 구조를 보여줍니다.
이를 그룹 관리 관점과 참여자 관점에서 설명하겠습니다.</p>

<p>라이브 스트리밍 미디어 서버와는 달리, 그룹콜 미디어 서버에는 여러 명의 참여자가 모일 수 있는 그룹이라는 개념이 존재합니다.
또한 그룹콜 미디어 서버는 참여자가 없는 빈 그룹을 허용합니다.
따라서 그룹콜 미디어 서버를 호출하는 외부 API 서버가 그룹콜 미디어 서버의 REST API를 호출해 그룹을 명시적으로 생성(그림 4 ⓐ)합니다.
REST API 요청을 받은 그룹콜 미디어 서버는 세션 관리 모듈에서 그룹을 생성하고, 응답으로 그룹 ID를 반환(그림 4 ⓑ)합니다.</p>

<p>그룹에는 라이브 스트리밍 미디어 서버와는 다른 Router라는 것이 있습니다.
Router는 참여자들로부터 미디어를 수신하고, 필요한 미디어만 선택해 송신하는 역할을 합니다.
예를 들어, Router는 Alice의 미디어를 수신하고 Alice에게는 자신을 제외한 다른 참여자 Bob, Charlie, David의 미디어만 송신합니다.</p>

<p>이제 Alice가 그룹에 참가하여 그룹콜을 진행하는 과정을 설명하겠습니다.
먼저 Alice는 그룹 ID X를 제공하며 그룹콜 미디어 서버와 시그널링을 수행합니다(그림 4 ①).
그룹콜 미디어 서버는 시그널링을 수행하면서 Alice를 그룹 X의 참여자로 추가하고(그림 4 ②), 그룹 X에 송수신 Peer를 생성합니다(그림 4 ③).
송수신 Peer는 Alice의 미디어를 수신해 Router로 전달할 준비를 하고, Router는 Alice를 제외한 Bob, Charlie, David의 미디어를 송수신 Peer로 전달할 준비를 마칩니다(그림 4 ④).
마지막으로, Alice와 송수신 Peer 사이에 PeerConnection을 맺어 미디어 송수신을 시작합니다(그림 4 ⑤).
이를 통해 Alice는 하나의 PeerConnection으로 자신의 미디어를 송신하고 동시에 다른 사람들의 미디어를 수신할 수 있게 됩니다.</p>

<p>한편, Alice가 그룹에 참가하면 새로운 비디오와 오디오 트랙이 추가되므로 PeerConnection의 미디어 정보가 변경됩니다.
따라서 기존에 그룹에 있던 Bob, Charlie, David은 다시 한 번 시그널링을 수행하는 재협상(renegotiation) 과정을 통해 Alice의 영상을 시청할 수 있습니다(그림 4 ⑥).</p>

<p>이와 같은 구조로 그룹콜 미디어 서버를 설계하면, PeerConnection이 많아지는 문제를 효과적으로 해결하면서도 안정적인 그룹콜 서비스를 제공할 수 있습니다.</p>

<h2 id="그룹콜-미디어-서버-인프라의-수평-확장">그룹콜 미디어 서버 인프라의 수평 확장</h2>

<p>하이퍼커넥트는 최대 50명의 참여자가 자유롭게 참가하고 퇴장할 수 있는 그룹콜 서비스를 제공합니다.
하지만 앞서 살펴본 구조로 그룹콜 미디어 서버를 운영하게 되면, 로드밸런싱과 수평 확장에 어려움이 생깁니다.
이는 참여자 수가 늘어날수로 서버의 컴퓨팅 및 네트워크 부하가 선형이 아닌 참가자 수의 제곱에 비례해 증가하기 때문입니다.</p>

<p>예를 들어, 3명의 참여자 Alice, Bob, Charlie이 있는 그룹에서 서버의 부하를 계산해 보겠습니다.
Router는 Alice, Bob, Charlie로부터 각각 미디어를 수신하고, Alice에게는 Bob과 Charlie의 미디어를, Bob에게는 Alice와 Charlie의 미디어를, Charlie에게는 Alice와 Bob의 미디어를 송신합니다.
이때 Router의 수신 부하는 3, 송신 부하는 3*(3-1)=6이므로, 총 부하는 3의 제곱인 9가 됩니다.
이 부하는 서버가 처리해야 하는 계산량이자 네트워크 트래픽을 의미합니다.</p>

<p>만약 David이 그룹에 참가하게 되면 Router는 4명의 미디어를 수신하고, 각 참여자에게 4*(4-1)=12의 미디어를 송신해야 합니다. 따라서 총 부하는 4의 제곱인 16으로 증가합니다.
참여자가 50명으로 늘어난다면, 총 부하는 50의 제곱인 2,500이 됩니다.
설명을 단순화하기 위해 각 참여자가 하나의 미디어만 송신하고 수신한다고 가정했지만, 실제로는 simulcast가 동작해 여러 종류의 비디오 스트림이 전송되므로 부하와 트래픽 계산은 더 복잡합니다.</p>

<p>그룹콜 미디어 서버를 여러 대 띄워서 수평확장한다면, 로드밸런싱은 어떻게 해야 할까요?
한 그룹에 최대 50명이 들어온다고 가정하고 로드밸런싱을 수행하면, 서버의 사용률이 매우 낮아져 비용 효율이 떨어집니다.
반대로 한 그룹 당 4명 정도만 들어온다고 가정한다면, 운 나쁘게 50명 그룹이 한 서버에 몰리면 서버가 과부하되어 문제가 발생할 수 있습니다.
따라서 그룹 내 참여자의 증감을 예측할 수 없는 상황에서 앞서 설명한 그룹콜 미디어 서버의 구조로는 효율적인 로드밸런싱이 어렵습니다.</p>

<figure>
  <img data-action="zoom" src="https://hyperconnect.github.io/assets/2024-09-25-introduction-to-groupcall-media-server/05-origin-edge-groupcall.png" alt="그림 5. 하이퍼커넥트 그룹콜 미디어 서버 인프라의 구조">
  <figcaption>그림 5. 하이퍼커넥트 그룹콜 미디어 서버 인프라의 구조</figcaption>
</figure>

<p>Media Server Team은 이 문제를 하나의 그룹을 분할해 여러 서버로 배치하는 방식으로 해결하고자 했습니다.
수년간 운영한 라이브 스트리밍 미디어 서버 인프라에서 힌트를 얻어, 그림 5와 같이 그룹콜 미디어 서버 인프라를 개발하였습니다.
그룹콜 미디어 서버는 Origin 미디어 서버와 Edge 미디어 서버로 나누어집니다.
참여자는 2개의 PeerConnection을 맺는데, 하나는 Origin 미디어 서버와 연결해 미디어 송신용으로 사용하고, 다른 하나는 Edge 미디어 서버와 연결해 미디어 수신용으로 이용합니다.</p>

<p>이 구조는 라이브 스트리밍 미디어 서버 인프라와 유사하게 작동합니다.
Origin 미디어 서버는 수신 Peer로 참여자의 미디어를 수신하며, 그룹 ID를 함께 저장합니다.
Edge 미디어 서버는 해당 그룹 ID를 가진 모든 Origin 서버로부터 모든 참여자들의 미디어를 릴레이 받아 송신 Peer로 송신합니다.</p>

<p>라이브 스트리밍 미디어 서버 인프라에서의 동작에 대비하여 설명해보겠습니다.
참여자 수가 N일 때, Origin 미디어 서버에서의 동작은 N명의 호스트가 증가한 것으로 볼 수 있고, Edge 미디어 서버는 (N-1)명의 호스트 방송을 시청하는 N명의 시청자가 추가된 것과 같습니다.
전체 부하는 기존과 큰 차이가 없지만, 그룹을 여러 Origin과 Edge 미디어 서버로 분산함으로서 개별 서버의 부하를 줄이고 효과적인 로드밸런싱을 수행할 수 있습니다.</p>

<h2 id="그룹콜-인프라와-라이브-스트리밍-인프라의-통합">그룹콜 인프라와 라이브 스트리밍 인프라의 통합</h2>

<p>그룹콜 미디어 서버 인프라와 라이브 스트리밍 미디어 서버 인프라가 별도로 운영될 경우, 오토 스케일링이 설정되어 있더라도 각 서비스의 이용률에 따라 일부 서버 자원이 효율적으로 사용되지 못하고 낭비될 수 있습니다.
앞서 설명한 것처럼, 그룹콜 미디어 서버 인프라는 라이브 스트리밍 인프라와 유사한 구조를 가지고 있습니다.
따라서 두 인프라를 하나로 통합해 운영하면 서버 자원을 훨씬 효율적으로 활용할 수 있습니다.</p>

<p>Media Server Team은 그룹콜 미디어 서버 인프라와 라이브 스트리밍 미디어 서버 인프라를 통합하기 위해, 무중단 운영 환경에서 대대적인 리팩토링을 진행했습니다.
그룹콜과 라이브 스트리밍은 비슷해 보이지만, 실제로 통합하는 작업은 결코 간단하지 않았습니다.
수년간 “호스트는 1명”이라는 전제를 바탕으로 설계된 라이브 스트리밍 인프라에, 다수의 호스트가 있을 수 있다는 요구사항을 반영하는 작업부터 시작했습니다.
또한, 미디어 서버에 의존하는 레코딩 서비스 등 여러 인프라를 수정해야 했으며, WebRTC 표준이 제정되기 전 사실상의 표준(de facto)이있던 Plan B 호환성을 코어 엔진에 반영하는 작업도 필요했습니다.
이 과정에서 Media Probe라는 미디어 서버 인프라 통합 테스트 도구를 개발하고, 지표 수집 및 운영 대시보드를 새롭게 설계해 보다 안정적인 운영 환경을 구축했습니다.
최종적으로 SRE팀의 도움을 받아 별도로 운영되고 있던 그룹콜과 라이브 스트리밍 인프라를 하나로 통합했습니다.
현재는 모든 서비스를 하나의 미디어 서버 인프라에서 운영하고 있습니다.</p>

<p>현재 통합된 미디어 서버 인프라는 라이브 스트리밍 서비스와 그룹콜 서비스를 모두 지원하고 있으며, 아직 상용화되지는 않았지만, 그룹 참여자의 방송을 다수의 시청자가 실시간으로 시청할 수 있는 컨퍼런스 서비스도 내부적으로 지원하고 있습니다.</p>

<h2 id="마치며">마치며</h2>

<p>이번 글에서는 하이퍼커넥트의 그룹 통화 서비스를 뒷받침하는 그룹콜 미디어 서버 인프라의 구조를 자세히 살펴보았습니다.
그룹콜 미디어 서버 인프라는 WebRTC 기술을 기반으로 Origin-Edge 구조로 설계되어, 고객사에 다양한 가치를 전달하고 있습니다.
현재 1:N 환경의 라이브 스트리밍 서비스와 N:N 환경의 그룹콜 서비스는 하나의 미디어 서버 인프라로 통합되어 운영되고 있습니다.
Media Server Team에서는 보다 다양한 유즈케이스를 지원하기 위해 여러 프로토콜을 지원하며, 미디어 서버 인프라를 지속적으로 개선하고 연구하고 있습니다.
기회가 된다면 Media Server Team의 또 다른 이야기를 전해드리겠다는 인사와 함께, 이 글을 마치겠습니다.</p>

<h2 id="참고자료">참고자료</h2>

<ol>
  <li><a href="https://datatracker.ietf.org/doc/html/rfc9429">RFC 9429 - JavaScript Session Establishment Protocol (JSEP)</a></li>
  <li><a href="https://datatracker.ietf.org/doc/html/rfc8866">RFC 8866 - SDP: Session Description Protocol</a></li>
  <li><a href="https://datatracker.ietf.org/doc/html/rfc7478">RFC 7478 - Web Real-Time Communication Use Cases and Requirements</a></li>
</ol>

  </div></div>

Hyperconnect Tech Blog

안녕하세요, 하이퍼커넥트 Media Lab의 Media Server Team에서 Media Server Engineer로 일하고 있는 Simon.Y 입니다.
저희 Media Server Team은 “사람들이 제약 없이 모여서 소통할 수 있도록 안정적인 연결을 제공하고 미디어 품질을 높이기 위해 노력한다”는 미션을 가지고 있습니다.
이 목표 아래, 대규모 실시간 스트리밍 서비스를 지원하는 미디어 서버를 개발하고, 전 세계에 위치한 미디어 서버 인프라를 운영하고 있습니다.
지난 글(글로벌 라이브 스트리밍을 지탱하는 하이퍼커넥트 미디어 서버 인프라를 소개합니다)에서는 WebRTC 기반 글로벌 라이브 스트리밍을 제공하기 위한 Media Server Team의 미디어 서버 인프라의 구성을 구체적으로 설명드렸습니다.
하이퍼커넥트에서는 다년간 축적한 영상 커뮤니케이션 및 라이브 스트리밍 기술을 여러 프로덕트에서 활용해왔습니다.
1:1 영상 통화 기술은 아자르(Azar) 서비스에서 활용되고 있고, 지난 글에서 언급했던 1:N 라이브 스트리밍 기술은 아자르 내 아자르 라이브(Azar Live) 서비스에서 활용되고 있습니다.
뿐만 아니라 저희는 N:N 그룹 통화 기술도 개발하여 다양한 곳에서 활용하고 있습니다.
혹시 여러분께서는 수십 명의 사용자가 동시에 소통할 수 있는 그룹 통화(그룹콜) 서비스를 제공하는 서버는 어떻게 구성되어 있는지 생각해보신 적이 있나요?
라이브 스트리밍 서비스에서는 호스트 한 명의 미디어를 다수의 시청자들에게 안정적으로 전달하는 것이 중요합니다.
이때 사용자는 미디어 서버 인프라와 연결되어 미디어를 보내거나(호스트) 받기만 하면 됩니다(시청자).
반면, 그룹콜 서비스에서는 참여자가 자신의 미디어를 다른 참여자들에게 전달할 뿐만 아니라, 모든 참여자의 미디어를 안정적으로 수신하는 것도 매우 중요합니다.
이번 글에서는 하이퍼커넥트의 그룹 통화 서비스를 뒷받침하고 있는 그룹콜 미디어 서버 인프라를 소개하고자 합니다.
라이브 스트리밍 인프라로 그룹콜 서비스를 구현할 수 있을까?
여러분께서는 아자르에서 멀티게스트 라이브를 보신 적이 있나요?
아자르 멀티게스트 라이브에서는 호스트를 포함해 최대 5명의 참여자가 동시에 소통하며 라이브의 재미를 더하고 있습니다.
그렇다면 이 방식으로 그룹콜 서비스를 구현하면 별도의 그룹콜 미디어 서버 인프라를 만들 필요가 없지 않을까요?
아자르 라이브의 멀티게스트 기능을 통해 라이브 스트리밍 미디어 서버 인프라를 간단하게 설명하고, 왜 그룹콜 미디어 서버 인프라가 필요한지 알아보겠습니다.
아자르 라이브에서는 호스트 1명과 게스트 4명, 최대 5명이 동시에 소통하고, 여러 시청자들이 이 장면을 실시간으로 시청할 수 있는 멀티게스트 기능을 지원하고 있습니다.
이해를 돕기 위해 Alice, Bob, Charlie, David가 멀티게스트 라이브를 진행 중인 상황을 가정해 봅시다.
멀티게스트 기능을 라이브 스트리밍 미디어 서버 인프라의 관점에서 보면, 참여자를 모두 호스트이자 시청자로 구현한 것이라 볼 수 있습니다.
예를 들어, Alice는 자신의 방송을 위해 미디어 서버 인프라와 연결되어 있고, 다른 참여자들인 Bob, Charlie, David와 소통하기 위해 각각 미디어 서버 인프라와 별도의 연결을 맺어 그들의 방송을 시청하고 있는 것입니다.
즉, 멀티게스트 라이브 참여자들은 자신이 방송하는 PeerConnection 1개와 다른 참여자들의 방송을 시청하는 PeerConnection 3개, 총 4개의 PeerConnection을 유지하는 셈입니다.
시청자들 또한 4개의 PeerConnection을 맺어서 Alice, Bob, Charlie, David의 방송을 각각 보고 있습니다.
하이퍼커넥트의 그룹 통화 서비스에서는 방 하나에 최대 50명의 참여자가 자유롭게 참가하거나 퇴장하면서 WebRTC 연결을 통해 모든 참여자의 영상과 음성을 실시간으로 주고받을 수 있어야 합니다.
만약 50명의 참여자가 멀티게스트 방식처럼 그룹콜을 진행한다면, 각 참여자들은 미디어 서버 인프라와 50개의 PeerConnection을 맺어야 합니다.
이는 각 참여자의 단말에 네트워크 연결 관점에서 상당한 부담을 줄 수 밖에 없습니다.
그렇다면 이 문제를 어떻게 해결할 수 있을까요?
그룹콜 미디어 서버의 기본 구조
컴퓨터에서 동영상을 재생할 때는 비디오 트랙과 오디오 트랙을 동시에 처리합니다.
WebRTC에서도 PeerConnection을 통해 비디오 트랙과 오디오 트랙을 각각 전송한 뒤, 이를 맞춰서 화면에 출력함으로써 동영상이 재생됩니다.
또 WebRTC는 하나의 PeerConnection에 여러 개의 비디오와 오디오 트랙을 추가할 수 있어, 여러 영상을 동시에 전송하는 것이 가능합니다.
더 나아가 PeerConnection은 트랙별로 송수신 방향을 설정할 수 있기 때문에, 하나의 연결로 미디어 송신과 수신을 동시에 처리할 수 있습니다.
이러한 WebRTC의 기능을 활용한다면 앞서 언급한 PeerConnection이 너무 많아지는 문제를 효과적으로 해결할 수 있습니다.
PeerConnection 설정 방법은 아래 참고자료의 RFC 메모[1, 2, 3]를 참조하시면 좋을 것 같습니다.
그림 4는 하나의 PeerConnection으로 송수신을 처리하는 그룹콜 미디어 서버의 구조를 보여줍니다.
이를 그룹 관리 관점과 참여자 관점에서 설명하겠습니다.
라이브 스트리밍 미디어 서버와는 달리, 그룹콜 미디어 서버에는 여러 명의 참여자가 모일 수 있는 그룹이라는 개념이 존재합니다.
또한 그룹콜 미디어 서버는 참여자가 없는 빈 그룹을 허용합니다.
따라서 그룹콜 미디어 서버를 호출하는 외부 API 서버가 그룹콜 미디어 서버의 REST API를 호출해 그룹을 명시적으로 생성(그림 4 ⓐ)합니다.
REST API 요청을 받은 그룹콜 미디어 서버는 세션 관리 모듈에서 그룹을 생성하고, 응답으로 그룹 ID를 반환(그림 4 ⓑ)합니다.
그룹에는 라이브 스트리밍 미디어 서버와는 다른 Router라는 것이 있습니다.
Router는 참여자들로부터 미디어를 수신하고, 필요한 미디어만 선택해 송신하는 역할을 합니다.
예를 들어, Router는 Alice의 미디어를 수신하고 Alice에게는 자신을 제외한 다른 참여자 Bob, Charlie, David의 미디어만 송신합니다.
이제 Alice가 그룹에 참가하여 그룹콜을 진행하는 과정을 설명하겠습니다.
먼저 Alice는 그룹 ID X를 제공하며 그룹콜 미디어 서버와 시그널링을 수행합니다(그림 4 ①).
그룹콜 미디어 서버는 시그널링을 수행하면서 Alice를 그룹 X의 참여자로 추가하고(그림 4 ②), 그룹 X에 송수신 Peer를 생성합니다(그림 4 ③).
송수신 Peer는 Alice의 미디어를 수신해 Router로 전달할 준비를 하고, Router는 Alice를 제외한 Bob, Charlie, David의 미디어를 송수신 Peer로 전달할 준비를 마칩니다(그림 4 ④).
마지막으로, Alice와 송수신 Peer 사이에 PeerConnection을 맺어 미디어 송수신을 시작합니다(그림 4 ⑤).
이를 통해 Alice는 하나의 PeerConnection으로 자신의 미디어를 송신하고 동시에 다른 사람들의 미디어를 수신할 수 있게 됩니다.
한편, Alice가 그룹에 참가하면 새로운 비디오와 오디오 트랙이 추가되므로 PeerConnection의 미디어 정보가 변경됩니다.
따라서 기존에 그룹에 있던 Bob, Charlie, David은 다시 한 번 시그널링을 수행하는 재협상(renegotiation) 과정을 통해 Alice의 영상을 시청할 수 있습니다(그림 4 ⑥).
이와 같은 구조로 그룹콜 미디어 서버를 설계하면, PeerConnection이 많아지는 문제를 효과적으로 해결하면서도 안정적인 그룹콜 서비스를 제공할 수 있습니다.
그룹콜 미디어 서버 인프라의 수평 확장
하이퍼커넥트는 최대 50명의 참여자가 자유롭게 참가하고 퇴장할 수 있는 그룹콜 서비스를 제공합니다.
하지만 앞서 살펴본 구조로 그룹콜 미디어 서버를 운영하게 되면, 로드밸런싱과 수평 확장에 어려움이 생깁니다.
이는 참여자 수가 늘어날수로 서버의 컴퓨팅 및 네트워크 부하가 선형이 아닌 참가자 수의 제곱에 비례해 증가하기 때문입니다.
예를 들어, 3명의 참여자 Alice, Bob, Charlie이 있는 그룹에서 서버의 부하를 계산해 보겠습니다.
Router는 Alice, Bob, Charlie로부터 각각 미디어를 수신하고, Alice에게는 Bob과 Charlie의 미디어를, Bob에게는 Alice와 Charlie의 미디어를, Charlie에게는 Alice와 Bob의 미디어를 송신합니다.
이때 Router의 수신 부하는 3, 송신 부하는 3*(3-1)=6이므로, 총 부하는 3의 제곱인 9가 됩니다.
이 부하는 서버가 처리해야 하는 계산량이자 네트워크 트래픽을 의미합니다.
만약 David이 그룹에 참가하게 되면 Router는 4명의 미디어를 수신하고, 각 참여자에게 4*(4-1)=12의 미디어를 송신해야 합니다. 따라서 총 부하는 4의 제곱인 16으로 증가합니다.
참여자가 50명으로 늘어난다면, 총 부하는 50의 제곱인 2,500이 됩니다.
설명을 단순화하기 위해 각 참여자가 하나의 미디어만 송신하고 수신한다고 가정했지만, 실제로는 simulcast가 동작해 여러 종류의 비디오 스트림이 전송되므로 부하와 트래픽 계산은 더 복잡합니다.
그룹콜 미디어 서버를 여러 대 띄워서 수평확장한다면, 로드밸런싱은 어떻게 해야 할까요?
한 그룹에 최대 50명이 들어온다고 가정하고 로드밸런싱을 수행하면, 서버의 사용률이 매우 낮아져 비용 효율이 떨어집니다.
반대로 한 그룹 당 4명 정도만 들어온다고 가정한다면, 운 나쁘게 50명 그룹이 한 서버에 몰리면 서버가 과부하되어 문제가 발생할 수 있습니다.
따라서 그룹 내 참여자의 증감을 예측할 수 없는 상황에서 앞서 설명한 그룹콜 미디어 서버의 구조로는 효율적인 로드밸런싱이 어렵습니다.
Media Server Team은 이 문제를 하나의 그룹을 분할해 여러 서버로 배치하는 방식으로 해결하고자 했습니다.
수년간 운영한 라이브 스트리밍 미디어 서버 인프라에서 힌트를 얻어, 그림 5와 같이 그룹콜 미디어 서버 인프라를 개발하였습니다.
그룹콜 미디어 서버는 Origin 미디어 서버와 Edge 미디어 서버로 나누어집니다.
참여자는 2개의 PeerConnection을 맺는데, 하나는 Origin 미디어 서버와 연결해 미디어 송신용으로 사용하고, 다른 하나는 Edge 미디어 서버와 연결해 미디어 수신용으로 이용합니다.
이 구조는 라이브 스트리밍 미디어 서버 인프라와 유사하게 작동합니다.
Origin 미디어 서버는 수신 Peer로 참여자의 미디어를 수신하며, 그룹 ID를 함께 저장합니다.
Edge 미디어 서버는 해당 그룹 ID를 가진 모든 Origin 서버로부터 모든 참여자들의 미디어를 릴레이 받아 송신 Peer로 송신합니다.
라이브 스트리밍 미디어 서버 인프라에서의 동작에 대비하여 설명해보겠습니다.
참여자 수가 N일 때, Origin 미디어 서버에서의 동작은 N명의 호스트가 증가한 것으로 볼 수 있고, Edge 미디어 서버는 (N-1)명의 호스트 방송을 시청하는 N명의 시청자가 추가된 것과 같습니다.
전체 부하는 기존과 큰 차이가 없지만, 그룹을 여러 Origin과 Edge 미디어 서버로 분산함으로서 개별 서버의 부하를 줄이고 효과적인 로드밸런싱을 수행할 수 있습니다.
그룹콜 인프라와 라이브 스트리밍 인프라의 통합
그룹콜 미디어 서버 인프라와 라이브 스트리밍 미디어 서버 인프라가 별도로 운영될 경우, 오토 스케일링이 설정되어 있더라도 각 서비스의 이용률에 따라 일부 서버 자원이 효율적으로 사용되지 못하고 낭비될 수 있습니다.
앞서 설명한 것처럼, 그룹콜 미디어 서버 인프라는 라이브 스트리밍 인프라와 유사한 구조를 가지고 있습니다.
따라서 두 인프라를 하나로 통합해 운영하면 서버 자원을 훨씬 효율적으로 활용할 수 있습니다.
Media Server Team은 그룹콜 미디어 서버 인프라와 라이브 스트리밍 미디어 서버 인프라를 통합하기 위해, 무중단 운영 환경에서 대대적인 리팩토링을 진행했습니다.
그룹콜과 라이브 스트리밍은 비슷해 보이지만, 실제로 통합하는 작업은 결코 간단하지 않았습니다.
수년간 “호스트는 1명”이라는 전제를 바탕으로 설계된 라이브 스트리밍 인프라에, 다수의 호스트가 있을 수 있다는 요구사항을 반영하는 작업부터 시작했습니다.
또한, 미디어 서버에 의존하는 레코딩 서비스 등 여러 인프라를 수정해야 했으며, WebRTC 표준이 제정되기 전 사실상의 표준(de facto)이있던 Plan B 호환성을 코어 엔진에 반영하는 작업도 필요했습니다.
이 과정에서 Media Probe라는 미디어 서버 인프라 통합 테스트 도구를 개발하고, 지표 수집 및 운영 대시보드를 새롭게 설계해 보다 안정적인 운영 환경을 구축했습니다.
최종적으로 SRE팀의 도움을 받아 별도로 운영되고 있던 그룹콜과 라이브 스트리밍 인프라를 하나로 통합했습니다.
현재는 모든 서비스를 하나의 미디어 서버 인프라에서 운영하고 있습니다.
현재 통합된 미디어 서버 인프라는 라이브 스트리밍 서비스와 그룹콜 서비스를 모두 지원하고 있으며, 아직 상용화되지는 않았지만, 그룹 참여자의 방송을 다수의 시청자가 실시간으로 시청할 수 있는 컨퍼런스 서비스도 내부적으로 지원하고 있습니다.
마치며
이번 글에서는 하이퍼커넥트의 그룹 통화 서비스를 뒷받침하는 그룹콜 미디어 서버 인프라의 구조를 자세히 살펴보았습니다.
그룹콜 미디어 서버 인프라는 WebRTC 기술을 기반으로 Origin-Edge 구조로 설계되어, 고객사에 다양한 가치를 전달하고 있습니다.
현재 1:N 환경의 라이브 스트리밍 서비스와 N:N 환경의 그룹콜 서비스는 하나의 미디어 서버 인프라로 통합되어 운영되고 있습니다.
Media Server Team에서는 보다 다양한 유즈케이스를 지원하기 위해 여러 프로토콜을 지원하며, 미디어 서버 인프라를 지속적으로 개선하고 연구하고 있습니다.
기회가 된다면 Media Server Team의 또 다른 이야기를 전해드리겠다는 인사와 함께, 이 글을 마치겠습니다.
참고자료
RFC 9429 - JavaScript Session Establishment Protocol (JSEP)
RFC 8866 - SDP: Session Description Protocol
RFC 7478 - Web Real-Time Communication Use Cases and Requirements

하이퍼커넥트 그룹콜 미디어 서버 인프라를 소개합니다

댓글