트위치 시스템 디자인 300만 동시시청 파해치기

트위치 시스템 디자인 완전정복 | 300만 동시시청 비법 공개! 를 보고

참고한 아티클: 트위치 시스템 디자인 완전정복

1. 라이브 스트리밍은 어떻게 하는 거지?

전체 흐름을 먼저 정리하면 이렇다.

replication 과정은 내가 아는 그 데이터 정합성? 데이터를 안전하게 유지하기 위해서 필요한 것인가?

• 여러 storage에 저장하는 것.

맞다. replication은 같은 미디어 데이터를 여러 storage에 복사해 두는 것이고, 목적은 안정성(가용성, 내구성)이다.

특정 storage(혹은 데이터 센터)가 죽더라도 다른 복사본에서 계속 데이터를 내보낼 수 있어야 라이브 방송이 끊기지 않는다. “한 곳에만 두면 그 한 곳이 죽었을 때 방송 자체가 멈춘다”는 단일 장애점 문제를 피하기 위한 장치로 이해했다.

스트리머가 송출하는 미디어를 transcode하는 이유가 뭘까?

두 가지 이유로 이해했다.

• 포맷 변환: 송출에 쓰는 형식(RTMP)을 배포에 적합한 형식(HLS)으로 바꾼다.
• 화질(비트레이트) 변경 용이 - ABR: 스트리머는 보통 하나의 고화질 영상을 송출하지만, 시청자는 기기와 네트워크 상황이 제각각이다. 그래서 원본 하나를 여러 해상도/비트레이트 버전(1080p, 720p, 480p)으로 다시 인코딩해 둔다. 그래야 시청자 쪽에서 네트워크 상황에 맞는 화질로 자동 전환(Adaptive Bitrate)이 가능하다.

2. ingest 과정에서 스트리머는 Origin(데이터 센터)에 미디어를 송출하는 것이 아니라, PoP이라는 중간 다리 역할을 통해 Origin에 전달되는 형식

PoP이라는 중간다리 역할을 왜 뒀을까? PoP이 하는 역할이 정확히 뭐지?

PoP(Point of Presence)은 스트리머와 가까이 분산 배치된 입구라고 이해했다. 역할은 크게 이렇다.

• 스트리머는 가장 가까운 PoP에 연결한다. 멀리 있는 Origin에 직접 붙는 것보다 지연이 적고 연결이 안정적이다.
• PoP은 받은 미디어를 최적화된 내부 백본망을 통해 Origin으로 전달한다. “스트리머 ↔ Origin”의 불안정한 공용 인터넷 구간을 “스트리머 ↔ 가까운 PoP”으로 짧게 줄여주는 셈이다.

(자세한 PoP의 역할은 4. 질문에서 추가로 떠올랐다!)

3. Transcode 과정에서 RTMP를 HLS로 변환하게 된다

HLS(HTTP Live Streaming)으로 변환하는 이유는 알겠다.

• HTTP로 라이브 스트리밍을 가능하게 함
• 네트워크 상황에 맞은 화질로 자동 변경이 용이함
• 여러 조각(chunk)으로 나누니까 실시간 스트리밍에서 조각별로 계속 CDN에 뿌려 줄 수 있어서 라이브 스트리밍에 적합함 → 즉 Cache 하기 쉽게 만든다

근데 왜 송출할 때는 RTMP 형식으로 하는 것인가?

영상에 답이 나오지 않아 추가 학습이 필요했는데, 정리하면 “송출(1:1 push)”과 “배포(1:N pull)”의 요구사항이 다르기 때문으로 이해했다.

• RTMP(송출): 스트리머 → 서버로 하나의 연결을 계속 유지하며 밀어 넣는(push) 상황. RTMP는 TCP 기반의 지속 연결로 지연이 낮고, OBS 같은 인코더들이 표준처럼 지원한다. 끊김 없이 한 줄기로 올려보내기에 적합하다.
• HLS(배포): 서버 → 수많은 시청자에게 조각 단위로 내려주는(pull) 상황. HTTP 기반이라 CDN 캐싱·수평 확장에 유리하지만, 조각을 모아 내보내는 특성상 지연이 상대적으로 크다.

정리하면 올릴 때는 낮은 지연, 지속 연결이 중요하니 RTMP, 내릴 때는 대규모 캐싱, 확장이 중요하니 HLS라서 중간(transcode)에서 변환하는 구조다.

4. 데이터 센터(Origin)가 여러 개일 때 PoP은 하나의 Origin과 연결되는 것 같다

그러면 Edge(CDN)는 모든 데이터 센터에 특정 HLS 형식 미디어를 요청해야 하는 형식인 건가?

• 이것을 해결한다고 데이터 센터에 모든 데이터를 동기화하면 실시간 스트리밍에서 지연시간이 늘어날 것 같다고 생각.

내가 생각한 방식

1. 첫 시청자가 이 방송의 스트리밍을 시작함
2. 해당 시청자가 사용하는 CDN에서 한 번 모든 데이터 센터에 미디어 데이터를 요청
3. 없으면) 데이터 센터에서 무시 / 있으면) 데이터 제공 및 자기 자신(어느 Origin인지)을 같이 알려줌
4. 이를 CDN에서 기억했다가, 현재 방송은 그 데이터 센터한테만 요청

→ 즉 매번 모든 Origin에 브로드캐스트하지 않고, “이 방송 = 이 Origin”이라는 위치를 한 번 찾아 캐싱해서 이후엔 그 Origin에만 요청하는 방식.

그 데이터 센터가 죽으면? 그래도 상관없다고 생각한다. 스트리머는 계속 송출하고 있으니,

• 송출 측: PoP에서 다른 데이터 센터로 연결을 바꿔, 현재까지 못 보냈던 데이터를 새 Origin으로 보내면 된다.
• 시청 측: CDN이 기존 Origin에서 요청을 받지 못하면, 다시 모든 데이터 센터에 브로드캐스트해서 새 위치를 찾아 캐싱하면 된다.

→ 이래서 PoP이 있어야 하는 건가? Origin이 죽어도 스트리머는 PoP만 바라보고, 실제 Origin 재연결은 PoP이 처리한다는 점에서, 2번 질문(PoP의 역할)에 대한 답도 여기서 같이 맞춰진 것 같다.

AI에게 물어본 해답

내가 생각한 “브로드캐스트로 위치를 찾아 캐싱”하는 방향은 큰 그림에서는 맞지만, 실제 시스템은 매번 모든 Origin에 물어보지 않고 별도의 메타데이터 계층(Control Plane)으로 위치를 관리한다고 한다.

• 스트림 등록: 스트리머가 ingest를 시작하는 순간, “이 stream ID는 지금 어느 Origin/transcode 클러스터가 담당한다”는 정보가 중앙 레지스트리(서비스 디스커버리/코디네이터)에 기록된다.
• 조회(lookup): Edge(CDN)는 시청자 요청을 받으면 모든 데이터 센터에 브로드캐스트하는 대신, 레지스트리에 “이 방송 어디 있어?”를 한 번 질의해서 담당 Origin을 알아낸 뒤 그 Origin에만 미디어를 요청한다. 즉 브로드캐스트(O(N) 탐색)를 조회 한 번(O(1) 가까이)으로 줄인 것.
• 장애 대응: 담당 Origin이 죽으면, 스트리머의 송출은 PoP이 다른 Origin으로 재연결하고 레지스트리의 매핑이 새 Origin으로 갱신된다. Edge는 다음 조회 때 갱신된 위치를 받으므로, 내가 생각한 “다시 찾아서 캐싱”이 브로드캐스트가 아니라 레지스트리 재조회로 자연스럽게 처리된다.

결국 내 직관(위치를 한 번 찾아 기억)은 맞았고, 그 “찾기”를 브로드캐스트 대신 중앙 메타데이터 조회로 구현한다는 점이 핵심 차이였다.