📊 WebRTC Mesh ‐ 트래픽 계산

왜 트래픽을 계산하게 되었을까요? 🤔

저희는 최대 4명이 함께하는 소규모 게임 방에서 음성 통화를 제공하기 위해 WebRTC Mesh 방식을 선택했습니다.

이 방식을 선택한 이유는 다음과 같습니다:

1. 소규모 인원: 한 게임 방의 인원이 최대 4명으로 매우 적습니다.
2. 음성 데이터만 전송: 영상 없이 음성 데이터만 주고받기 때문에 대역폭 부담이 비교적 적습니다.
3. 서버 부담 최소화: 서버의 부하를 줄이고자 클라이언트 측에서 약간의 부담을 감수하기로 결정했습니다.

하지만 실제로 각 사용자가 부담해야 하는 업로드와 다운로드 트래픽이 어느 정도인지 정확하게 파악할 필요가 있었습니다.

이는 클라이언트 측 네트워크 부담을 예측하고, 서비스 품질을 보장하기 위함입니다. 😊

---

트래픽 상세 계산 🧮

1. 음성 데이터의 비트 전송률 계산

오디오 설정:

• 채널 수: 모노 (1채널)
• 샘플 레이트: 16,000Hz
• 샘플 크기: 16비트

원시 오디오 비트 전송률:

계산 단계	식	결과
비트 전송률 (raw)	샘플 레이트 × 샘플 크기 × 채널 수	16,000 Hz × 16 bits × 1 = 256,000 bps

하지만 WebRTC는 원시 오디오 데이터를 그대로 전송하지 않고, Opus 코덱을 사용하여 압축합니다.

Opus 코덱의 예상 비트 전송률:

• 16kHz 모노 음성의 경우 약 24kbps로 설정됩니다.

2. 패킷화 및 네트워크 오버헤드 고려

패킷화 간격:

• 일반적으로 20ms 프레임 크기를 사용합니다.
• 따라서 초당 50개의 패킷이 전송됩니다.

패킷당 오디오 페이로드 크기:

계산 단계	식	결과
페이로드 크기	24,000 bps ÷ 50	480 bits = 60 bytes

패킷당 네트워크 오버헤드:

• IP 헤더: 20바이트 (IPv4)
• UDP 헤더: 8바이트
• RTP 헤더: 12바이트
• 총 오버헤드: 40바이트

패킷당 총 크기:

계산 단계	식	결과
총 패킷 크기	오버헤드 + 페이로드	40 bytes + 60 bytes = 100 bytes

스트림당 총 비트 전송률:

계산 단계	식	결과
총 비트 전송률	100 bytes × 50 × 8	40,000 bps = 40 kbps

3. 사용자당 업로드 및 다운로드 트래픽 계산

4명의 사용자가 있을 때, 각 사용자는 다른 3명에게 자신의 음성 데이터를 전송하고, 다른 3명으로부터 음성 데이터를 수신합니다.

• 업로드 트래픽:

  계산 단계	식	결과
  업로드 트래픽	40 kbps × (4 - 1)	120 kbps

• 다운로드 트래픽:

  계산 단계	식	결과
  다운로드 트래픽	40 kbps × (4 - 1)	120 kbps

---

다른 서비스와의 트래픽 비교 📶

서비스	비트 전송률
음악 스트리밍	128kbps ~ 320kbps
유튜브 시청
- HD (720p)	1 ~ 3Mbps
- FHD (1080p)	3 ~ 7Mbps
- QHD (1440p)	7 ~ 13Mbps
- 4K (2160p)	15 ~ 25Mbps

저희의 음성 통화 서비스는 사용자당 업로드 120kbps, 다운로드 120kbps 정도의 트래픽을 사용합니다. 이는 음악 스트리밍과 비슷하거나 더 낮은 수준이며, 고화질 영상 스트리밍에 비하면 매우 적은 양입니다. 따라서 일반적인 네트워크 환경에서 큰 부담 없이 사용이 가능합니다. 🎧

---

한 방의 최대 사용자 수는 몇 명까지 가능할까요? 🤔

Mesh 방식에서는 각 사용자가 다른 모든 사용자와 직접 P2P 연결을 맺습니다. 따라서 사용자 수가 늘어날수록 각 사용자의 트래픽 부담은 증가합니다.

1. 트래픽 증가 패턴

• 각 사용자의 업로드/다운로드 트래픽은 다른 사용자 수에 비례합니다.

• 즉, n명의 사용자가 있을 때, 각 사용자의 업로드/다운로드 트래픽은:

  식	설명
  트래픽 = 스트림당 비트 전송률 × (n - 1)	사용자 수에 비례하여 트래픽 증가

2. 사용자 수에 따른 트래픽 계산

사용자 수 (n)	업로드 트래픽 (kbps)	다운로드 트래픽 (kbps)
2	40	40
3	80	80
4	120	120
5	160	160
6	200	200
7	240	240
8	280	280
9	320	320
10	360	360

3. 최대 사용자 수 결정

• 클라이언트 측 부담을 고려하여, 한 방의 최대 사용자 수는 10명 이하가 적절합니다.
• 10명일 경우, 각 사용자는 업로드/다운로드 360kbps를 부담하게 됩니다.
• 이는 여전히 음악 스트리밍 수준이며, 대부분의 네트워크 환경에서 수용 가능합니다.
• 그러나 빠른 게임 진행을 위해 저희는 최대 4명으로 제한하기로 결정했습니다.

---

왜 서버에서 처리하지 않을까요? 🖥️

트래픽이 적다면 서버에서 SFU 방식으로 처리해도 되지 않을까 생각하실 수 있습니다. 그러나 다음과 같은 이유로 Mesh 방식을 선택했습니다:

1. SFU 방식에서의 서버 트래픽 계산

SFU 방식에서는 서버가 모든 미디어 스트림을 중계합니다. 따라서 전체 사용자가 많아질수록 서버의 트래픽 부담이 커집니다.

• 방의 크기: 4명 (한 방의 최대 인원)
• 스트림당 비트 전송률: 40kbps
• 방의 수 (R): 전체 사용자 수(U)를 4로 나눈 값

방당 서버 트래픽 계산:

• 업로드 트래픽 (서버 수신):

  계산 단계	식	결과
  업로드 트래픽	사용자 수 × 스트림당 비트 전송률	4 × 40 kbps = 160 kbps

• 다운로드 트래픽 (서버 송신):

  계산 단계	식	결과
  다운로드 트래픽	사용자 수 × (사용자 수 - 1) × 스트림당 비트 전송률	4 × 3 × 40 kbps = 480 kbps

• 방당 총 서버 트래픽:

  계산 단계	식	결과
  방당 총 트래픽	업로드 트래픽 + 다운로드 트래픽	160 kbps + 480 kbps = 640 kbps

2. 전체 서버 트래픽 계산

• 전체 사용자 수 (U): 1,000명, 10,000명, 100,000명, 1,000,000명

총 서버 트래픽:

전체 사용자 수 (U)	계산 식	총 서버 트래픽
1,000명	160 kbps × 1,000	160,000 kbps = 160 Mbps
10,000명	160 kbps × 10,000	1,600,000 kbps = 1.6 Gbps
100,000명	160 kbps × 100,000	16,000,000 kbps = 16 Gbps
1,000,000명	160 kbps × 1,000,000	160,000,000 kbps = 160 Gbps

3. 결과 해석

• 서버 트래픽은 사용자 수에 비례하여 증가합니다.
• 만 명의 사용자만 되어도 서버는 1.6Gbps의 트래픽을 처리해야 합니다.
• 이는 서버 인프라와 비용 측면에서 적지 않은 부담이 됩니다.
• 또한, 네트워크 트래픽 외에도 CPU와 RAM 사용률도 비례하여 증가하게 되는 문제가 있습니다.

4. Mesh 방식의 장점

• 클라이언트 측 트래픽은 방의 크기에만 의존하며, 전체 사용자 수와 무관합니다.
• 서버 부담 최소화: 서버는 시그널링과 최소한의 통신만 처리하여, 대규모 사용자를 지원할 수 있습니다.

---

결론 🎯

저희는 소규모 인원이 참여하는 음성 통화 서비스에서 WebRTC Mesh 방식을 선택함으로써, 사용자 경험을 해치지 않으면서도 서버 트래픽 부담을 줄이는 효율적인 구조를 설계했습니다.

• 클라이언트 측: 부담하는 트래픽이 음악 스트리밍 수준으로 낮아, 일반적인 네트워크 환경에서 원활한 사용이 가능합니다.
• 서버 측: 트래픽 부담이 최소화되어, 많은 사용자가 동시에 접속하더라도 안정적인 서비스 제공이 가능합니다.

이를 통해 사용자들에게는 쾌적한 음성 통화 환경을, 서비스 측면에서는 적은 비용으로 안정성 높은 서버 환경을 제공할 수 있게 되었습니다. 😊