SFU 확장 구조 — 단일 노드 용량과 Cascading

"화상회의는 100명까지 되던데, 라이브 방송은 어떻게 10만 명이 보나요? 같은 WebRTC 아닌가요?". RTC 아키텍처를 검토하는 자리에서 자주 나오는 질문입니다. 답부터 말하면 — 둘은 같은 WebRTC라도 토폴로지가 다르고, 100명과 10만 명은 애초에 다른 메커니즘으로 푼다는 것입니다.

이 글은 그 경계를 처음부터 끝까지 정리합니다. P2P 풀메시가 왜 몇 명에서 무너지는지, SFU가 왜 저지연인지, 단일 SFU 노드가 몇 명에서 한계에 닿는지, 그리고 그 한계를 넘는 Cascading과 — 더 큰 규모에서는 아예 라이브 스트리밍(HLS/CDN)으로 갈아타는 분기점까지.

0. 핵심 명제 — "실시간 양방향"과 "대규모 단방향"은 다른 문제다

컨퍼런스와 방송은 발행자 수·구독 관계·상호작용 요구가 다르다. SFU는 보통 미디어 payload를 트랜스코딩하지 않고 선택적으로 전달하지만 transport를 종단하고 RTP header를 재작성할 수 있다. 단일 노드 용량과 end-to-end latency는 워크로드·구현·하드웨어로 측정해야 한다.

흔한 오해와 정정:

1. 출발점 — P2P(Mesh)는 왜 몇 명에서 무너지나

가장 단순한 구조는 서버 없이 참가자끼리 직접 연결하는 P2P 풀메시(Full Mesh) 입니다. 2명이라면 완벽합니다. 문제는 인원이 늘 때입니다.

풀메시 — 모두가 모두와 직접 연결

   A ─────── B
   │ ╲     ╱ │
   │   ╲ ╱   │
   │   ╱ ╲   │
   │ ╱     ╲ │
   D ─────── C

연결 수 = N×(N-1)/2
각 참가자의 업로드 전송량 = 같은 인코딩을 각 peer에 N-1번 전송할 수 있음
각 참가자의 다운로드 = (N-1)개 스트림

여기서 핵심은 각자가 자기 영상을 (N-1)번 복제해서 올린다는 점입니다. 서버가 없으니 분배를 대신해 줄 주체가 없습니다.

인원별 업로드 부하 산수

가정: 한 스트림당 720p ≈ 1.5 Mbps 업링크.

다운로드도 동일하게 (N-1)개가 들어오지만, 가정용 회선은 보통 다운로드가 업로드보다 훨씬 큽니다. 그래서 풀메시의 진짜 병목은 업링크입니다. 각 클라이언트의 CPU도 (N-1)개를 동시에 인코딩(또는 시뮬캐스트)하느라 같이 무너집니다.

풀메시의 실용 범위는 비트레이트, 참가자 수, 기기와 네트워크에 따라 달라집니다. 고정된 참가자 수 기준 대신 목표 기기와 회선으로 테스트합니다.

P2P가 NAT/방화벽 때문에 연결 자체가 안 되는 문제는 별개 주제입니다 (#8 참고). 여기서는 "연결이 되더라도 부하 때문에 안 된다"는 이야기입니다.

2. SFU — "복제 분배"를 서버에 떠넘긴다

SFU(Selective Forwarding Unit) 는 중앙에 서버를 한 대 두고, 각 참가자가 자기 영상을 서버에만 한 번 올리면, 서버가 그걸 다른 참가자들에게 복제·분배하는 구조입니다.

SFU — 각자는 서버와만 연결

        ┌─────────┐
   A ──→│         │──→ B,C,D 에게 A 영상 분배
   B ──→│   SFU   │──→ A,C,D 에게 B 영상 분배
   C ──→│ (서버)  │──→ A,B,D 에게 C 영상 분배
   D ──→│         │──→ A,B,C 에게 D 영상 분배
        └─────────┘

각 참가자의 업로드 = 1개 스트림 (서버로 1번만)
각 참가자의 다운로드 = (N-1)개 스트림 (서버에서)
서버의 아웃바운드 = N × (N-1) 스트림

클라이언트 부하 비교 — 업로드가 1개로 고정된다

핵심은 부하의 이동입니다. SFU에서는 발행 업로드가 구독자 수에 직접 비례하지 않습니다. 다만 simulcast/SVC 레이어, 수신 구독 수와 signaling 상태는 회의 규모에 따라 달라집니다.

정정 (다운로드는 여전히 N에 비례): SFU가 풀메시 문제를 다 해결하진 않습니다. 각 참가자가 받는 다운스트림은 여전히 (N-1)개입니다. 100명이면 99개 스트림을 받아야 하므로, 실무에서는 화면에 보이는 일부만 큰 해상도로 받고 나머지는 작은 해상도(시뮬캐스트/SVC)로 받거나 끄는 식으로 다운링크를 관리합니다.

3. SFU vs MCU — 저지연의 근거는 "포워딩만 한다"

SFU는 보통 media payload를 디코딩·재인코딩하지 않고 선택적으로 전달합니다. 각 hop의 transport와 보안을 종단하고 SSRC·sequence number 같은 RTP header를 재작성할 수 있으므로 패킷 전체가 그대로인 것은 아닙니다. 반면 MCU는 여러 스트림을 디코딩·합성·재인코딩할 수 있습니다.

SFU — 포워딩만 (Selective Forwarding)
   [A의 패킷] → SFU → [그대로] → B,C,D
   - RTP 패킷 수준에서 동작
   - 디코딩 X, 합성 X, 재인코딩 X (재암호화는 함)
   - CPU 부하 ∝ 패킷 레이트 (비트레이트와 거의 무관)
   - 인코딩 지연 0, 세대 손실(generational loss) 없음
   - 결과: 트랜스코딩을 피할 수 있지만 전체 지연·화질은 종단 파이프라인에 좌우

🔴 MCU — 합성 (Mixing / Transcoding)
   [A,B,C,D 패킷] → MCU → 디코딩 → 한 화면에 합성 → 재인코딩 → 통합 스트림
   - CPU 집약적 (참가자마다 디코딩+인코딩)
   - 트랜스코딩 지연 추가
   - 재인코딩으로 화질 세대 손실 발생
   - 장점: 수신측은 스트림 1개만 받으면 됨 (저사양 단말/믹스 녹화에 유리)

비교 매트릭스

비유하면, SFU는 우편물을 뜯어보지 않고 그대로 라벨만 보고 분류·전달하는 우체국이고, MCU는 여러 편지를 다 읽고 한 장에 요약해서 다시 쓰는 비서입니다. 우체국은 빠르고 싸지만 받는 사람이 여러 통을 받고, 비서는 한 통으로 정리해주지만 느리고 비쌉니다. 기술적 실체로 환원하면 — SFU는 RTP 페이로드를 건드리지 않아 디코더/인코더를 거치지 않으니 지연과 CPU가 작고, MCU는 디코드→믹스→인코드 파이프라인을 타므로 그 반대입니다.

4. 코덱 협상 — SFU가 포워딩만 하려면 양끝 코덱이 맞아야 한다

SFU가 "디코딩 없이 포워딩만" 하려면 전제가 있습니다 — 송신자가 인코딩한 코덱을 수신자가 디코딩할 수 있어야 합니다. SFU는 트랜스코딩을 안 하므로 코덱을 바꿔주지 못합니다. 이 합의가 SDP(Session Description Protocol) 협상입니다.

       Offer (내가 보낼/받을 수 있는 코덱 목록)
   A ───────────────────────────────────────→ SFU
       Answer (교집합으로 확정된 코덱)
   A ←───────────────────────────────────────── SFU

SDP 예 (요약):
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 AV1/90000
   → 양끝이 공통으로 지원하는 코덱(payload type)만 살아남음

핵심 제약

SFU는 publisher와 각 subscriber의 capability를 바탕으로 전달 가능한 트랙을 선택합니다. Simulcast는 일반적으로 같은 코덱의 여러 spatial/quality encoding을 보내는 기술이지 여러 코덱 동시 송출의 동의어가 아닙니다. 코덱 교집합이 없으면 별도 publisher encoding 또는 transcoder가 필요합니다.

5. 단일 SFU 노드의 한계 — 아웃바운드 산수

SFU 한 대가 감당할 수 있는 인원에는 명확한 천장이 있습니다. 그 천장의 1차 요인이 아웃바운드 대역폭입니다.

컨퍼런스(모두가 모두를 봄): 아웃바운드 = N × (N-1)

모든 참가자가 서로를 보는 회의라면, 서버가 내보내는 총 스트림 수는 N × (N-1)로 제곱에 가깝게 증가합니다.

서버 아웃바운드 스트림 = N × (N-1)
스트림당 1.5 Mbps 가정

100명이 전원 카메라를 켜고 서로를 보는 시나리오는 단일 노드 기준 이미 15 Gbps에 육박합니다. 그래서 실무 컨퍼런스는 "전원이 전원을 풀해상도로 본다"를 절대 허용하지 않고, 활성 발화자 몇 명만 큰 해상도 + 나머지는 썸네일/오디오만으로 다운링크를 줄입니다.

방송형(1명 → N명): 아웃바운드 = N

반대로 1명이 송출하고 N명이 보는 구조라면 아웃바운드는 N에 선형 비례합니다.

(이 표는 1.5 Mbps 단일 송출 예시의 선형 산수입니다. 어느 시점에 단일 노드에서 클러스터로 전환할지는 하드웨어와 워크로드 부하 테스트로 정합니다.)

단일 노드의 현실적 천장

단일 SFU 용량은 참가자 수만으로 정해지지 않습니다. 발행 트랙 수, 구독 수, 비트레이트, 패킷률, transport encryption, retransmission, 운영체제와 하드웨어가 함께 결정합니다. 출처와 조건이 없는 범용 용량 수치를 쓰지 않고 구축 대상 워크로드로 부하 테스트합니다.

이 천장에 닿으면 선택지는 두 가지입니다 — (1) 더 큰 서버로 수직 확장(한계 명확), (2) 여러 SFU를 묶는 Cascading으로 수평 확장.

6. Cascading — SFU를 묶어 수만 명으로

Cascading(캐스케이딩) 은 지역별로 여러 SFU를 배치하고, 서버 간 고대역폭·저지연 링크로 필요한 트래픽만 릴레이해 단일 노드 한계를 넘는 표준 아키텍처입니다.

단일 SFU (용량은 워크로드 테스트로 결정)

           ┌──────┐
   많은 ──→│ SFU  │──→ 많은
   참가자   └──────┘    참가자
            (한 대에 다 몰림 → 천장)


Cascading (지역 SFU + 서버 간 릴레이)

  [서울 참가자들]        [도쿄 참가자들]        [LA 참가자들]
       │                     │                    │
       ↓ (가까운 엣지)        ↓                    ↓
  ┌──────────┐  inter-SFU ┌──────────┐ inter-SFU ┌──────────┐
  │ SFU 서울 │←──릴레이──→ │ SFU 도쿄 │←──릴레이──→│ SFU LA   │
  └──────────┘  (전용링크) └──────────┘ (전용링크) └──────────┘
       │                     │                    │
   각 참가자는 "가장 가까운 엣지"에만 연결
   타 리전 참가자 영상은 SFU끼리 필요한 것만 1번씩 릴레이

Cascading의 핵심 이득

예: A(서울) 영상을 도쿄의 100명이 봐야 한다

단일 SFU(서울)에 도쿄 구독자들이 직접 붙으면:
   - 서울 SFU가 도쿄로 100개 스트림을 각각 송출 (장거리 × 100)
   - 서울→도쿄 국제 구간에 같은 영상이 100번 흐름

Cascading:
   - 서울 SFU → 도쿄 SFU 로 A 영상을 1번만 릴레이
   - 도쿄 SFU가 도쿄 내부 100명에게 분배
   - 장거리 국제 구간 트래픽 = 100분의 1

즉 Cascading은 같은 스트림을 장거리 구간에서 반복 전송하는 양을 줄일 수 있습니다. 참가자가 어느 엣지에 붙는지, 실제 확장 규모와 지연은 라우팅 정책과 구독 그래프, 배포 용량에 따라 달라집니다.

추가 지연은 얼마나?

서버 간 relay hop은 전파·큐잉·처리 지연을 추가합니다. 전용 링크 사용 여부와 추가 지연은 배포 환경마다 다르므로 수십 ms로 고정하지 않고 실제 지역 조합에서 측정합니다.

Cascading의 도전 과제

Agora의 SD-RTN을 특정 cascading SFU 구현으로 단정할 공개 근거는 없습니다. 공식 페이지가 공개한 네트워크·라우팅 설명 범위에서 평가합니다 (#43 참고).

7. 단방향 대규모 배포라면 HLS/CDN도 검토한다

Cascading은 SFU를 여러 지역과 노드로 확장하는 한 방법입니다. 단방향 라이브에서 연결별 상호작용이 필요하지 않다면 HLS/CDN의 캐시 모델도 함께 비교합니다.

구조의 근본 차이

WebRTC SFU/Cascading — 상태 기반(stateful) 연결
   - 시청자마다 개별 RTC 세션(연결·암호화·혼잡제어 상태 유지)
   - 양방향·인터랙티브, 지연은 종단 경로로 측정
   - 서버가 연결 수만큼 상태를 가짐 → 비싸고 확장 한계 명확

HLS/CDN — 캐시 가능한 HTTP 미디어 배포
   - 영상을 작은 세그먼트 파일로 쪼개 m3u8 플레이리스트로 나열
   - 시청자는 그냥 HTTP로 파일을 주기적으로 다운로드 (CDN 캐시 활용)
   - 캐시 가능한 세그먼트는 CDN으로 확장하기 유리하지만 origin·인증·DRM·playlist에는 상태가 있을 수 있음
   - 대가: 지연이 큼

HLS 라이브의 동작 (RFC 8216)

인코더 → 세그먼트(예: 6초짜리 .ts/.m4s) 계속 생성
       → 미디어 플레이리스트(m3u8)에 #EXTINF로 새 세그먼트 append
       → #EXT-X-MEDIA-SEQUENCE 번호 단조 증가
플레이어 → 주기적으로 m3u8 재요청 → 새 세그먼트 감지 → HTTP로 다운로드

HLS 지연은 segment/part 생성, playlist 갱신, CDN, player start position과 buffer 정책의 합입니다. RFC 8216의 3 × target duration 규칙은 live playlist 시작 위치에 대한 안전 조건이지 플레이어가 항상 세 세그먼트를 전부 다운로드해야 한다는 뜻이 아닙니다. 고정 지연값 대신 사용하는 서비스·플레이어의 latency mode를 측정합니다.

라이브 트랜스코딩 vs VOD 트랜스코딩 (AWS 예)

대규모 라이브에서는 보통 여러 화질(ABR)을 동시에 만들어 CDN으로 내보냅니다. 이때 쓰는 서비스가 "라이브용"인지 "파일용"인지 구분이 필요합니다.

정정 (ABR "단일 인코더 동시 인코딩"은 구현 의존): "하나의 인코더 인스턴스가 1080p/720p/480p를 동시 병렬 인코딩한다"는 표현은 부분적으로만 맞습니다. 정확히는 단일 소스로부터 여러 해상도 렌디션을 병렬로 생성하는 것을 지원하는 것이며, 실제로 단일 인스턴스가 모든 렌디션을 동시에 처리하는지는 구현·벤더·리소스에 따라 다릅니다. 일반적으로 각 해상도는 분리된 트랜스코딩 작업으로 처리되고, VOD는 배치, 라이브는 병렬 처리가 가능하되 아키텍처 세부는 벤더별로 상이합니다. ABR 래더·키프레임 동기화 산수는 #38을 참고하세요.

8. 규모·지연으로 보는 토폴로지 의사결정

┌────────────────────────────────────────────────────────────┐
│ Q1. 양방향 실시간 인터랙션(대화)이 필요한가?               │
│   NO (단방향 시청) → Q4 (HLS/CDN 검토)                     │
│   YES → Q2                                                  │
├────────────────────────────────────────────────────────────┤
│ Q2. 발행 트랙·구독 그래프와 클라이언트 업링크는 어떤가?    │
│   소수 참가자·충분한 업링크 → P2P 후보                     │
│   서버 중계·구독 제어 필요 → SFU 후보                      │
│   단일 노드 부하 한계 초과 → SFU 클러스터/relay 검토       │
├────────────────────────────────────────────────────────────┤
│ Q3. 글로벌 분산 사용자인가?                                 │
│   YES → 지역 엣지 SFU + relay 경로 검토                    │
│   NO  → 단일 리전과 다중 노드를 부하·장애 요구로 결정      │
├────────────────────────────────────────────────────────────┤
│ Q4. 단방향 시청이며 세그먼트 기반 지연을 허용하는가?       │
│   YES → HLS/CDN의 캐시 배포 검토                           │
│   "저지연 + 대규모" 둘 다 → LL-HLS 또는 WebRTC 대규모 설계 │
└────────────────────────────────────────────────────────────┘

규모대별 요약 카드

트레이드오프: WebRTC는 연결별 상태와 낮은 지연·상호작용을, HLS/CDN은 캐시 가능한 배포를 중심으로 설계합니다. 낮은 지연과 큰 규모를 함께 요구할수록 용량 계획과 운영 복잡도가 커집니다.

9. 한 장 요약 — 암기 카드

P2P 풀메시 = 클라이언트가 복제 분배
SFU        = 서버가 선택적으로 포워딩
SFU relay  = 여러 SFU 사이에 필요한 스트림 전달
HLS/CDN    = 캐시 가능한 미디어 파일 배포

10. 한 줄 결론

토폴로지는 참가자 수 하나가 아니라 발행자 수, subscription graph, 목표 지연, 상호작용, 기기와 네트워크로 결정한다. SFU 용량과 cascading 추가 지연은 구축 대상 워크로드로 검증하고, 대규모 단방향 시청은 HLS/CDN의 캐시 확장성을 함께 비교한다.

관련 글

• #43 Agora 자체 코덱 vs Web SDK, SD-RTN, FEC — Agora가 공개한 SD-RTN 제품 범위
• #40 라이브 스트리밍 프로토콜 선택 — HLS / LL-HLS / WebRTC — 수십만 시청자에서 HLS/CDN으로 넘어가는 분기점
• #8 왜 P2P가 막히는가? — NAT, STUN, TURN — P2P가 연결 자체에서 막히는 별개 문제
• #28 H.264 Profile·인코더 옵션·비트레이트의 현실 — SFU 포워딩의 전제인 코덱 협상 깊게 보기
• #38 ABR Ladder와 키프레임 동기화 — HLS/CDN의 다해상도 렌디션 산수

참고 자료

• RFC 8216 — HTTP Live Streaming (HLS) — m3u8 플레이리스트·EXT-X-MEDIA-SEQUENCE·#EXTINF 표준
• RFC 7667 — RTP Topologies — SFU를 포함한 RTP middlebox topology
• LiveKit SFU internals — SFU 구현 내부
• AWS Elemental MediaLive features — 라이브 인코딩 서비스
• AWS Elemental MediaConvert — 파일 기반 VOD 트랜스코딩
• Enabling Low-Latency HLS (Apple) — LL-HLS 저지연