Skip to content

StreamLive Failover는 어떻게 설계해야 하나 ​

라이브 방송에서 인코딩 파이프라인이 죽으면, 시청자 화면이 멈춥니다. 로그를 볼 시간도 없습니다 — 전화가 먼저 옵니다. Failover는 "장애가 났을 때 어떻게 전환할 것인가"의 문제이고, 라이브 인프라에서 가장 비용 대비 효과를 따져야 하는 설계 결정입니다.


들어가기 전에 ​

AWS MediaLive에는 Standard Channel이라는 개념이 있습니다. 하나의 채널 안에 Pipeline 0과 Pipeline 1이 내장되어 있고, 입력부터 출력까지 완전히 이중화됩니다. 한쪽이 죽으면 다른 쪽이 자동으로 이어받습니다. 과금은 당연히 2배입니다.

현재 StreamLive 문서 기준으로는 AWS MediaLive의 Standard Channel처럼 채널 안에서 두 파이프라인을 한 번에 감싸는 모델이 보이지 않습니다. 채널 하나 = 파이프라인 하나입니다. 이중화를 하려면 동일한 채널을 2개 만들어서 같은 입력을 동시에 넣고, 다운스트림에서 전환하는 구조를 직접 구성해야 합니다.

같은 목표(파이프라인 이중화), 다른 구현 방식입니다. AWS는 서비스가 알아서 해주고, Tencent Cloud는 사용자가 직접 설계합니다. 비용은 어차피 둘 다 2배입니다.


AWS MediaLive의 채널 구성 ​

Single Pipeline ​

입력 하나가 Pipeline 0 하나를 거쳐 출력 하나로 나가는 가장 단순한 구성입니다.

  • 파이프라인 1개. Failover 없음.
  • 비용: 1x
  • 장애 시: 서비스 중단

Standard Channel (Dual Pipeline) ​

입력 A와 입력 B가 각각 Pipeline 0과 Pipeline 1을 거쳐 출력 0과 출력 1을 만들고, AWS MediaPackage/CloudFront가 그중 정상인 쪽을 자동으로 선택합니다.

  • 파이프라인 2개가 하나의 채널 안에 내장
  • 입력도 2개 필요 (같은 소스를 2곳으로 전송)
  • 출력도 2개 생성 → 다운스트림(AWS MediaPackage)이 선택
  • 비용: 2x
  • 장애 시: 자동 전환. 시청자 인지 없음

Standard Channel의 Failover 동작 ​

감지 대상동작
입력 손실Input Failover Settings에 따라 대기 입력으로 전환
파이프라인 장애AWS MediaPackage가 정상 파이프라인의 출력을 자동 선택
출력 오류Pipeline별 독립. 한쪽 출력 실패가 다른 쪽에 영향 없음

핵심은 MediaLive가 "채널 레벨"에서 이중화를 관리한다는 점입니다. 사용자는 Standard Channel을 선택하기만 하면 됩니다.


StreamLive의 Failover 구성 ​

StreamLive에서는 AWS식 Standard Channel 모델을 그대로 쓰기 어렵기 때문에, 채널 2개 + 다운스트림 전환 로직으로 비슷한 효과를 구현하는 쪽이 현실적입니다.

기본 구조 ​

StreamLive 이중 채널 Failover 구조

구성 단계 ​

단계할 일
1동일한 설정으로 StreamLive 채널 2개 생성 (Channel A, Channel B)
2인코더에서 같은 소스를 두 채널에 동시 푸시
3두 채널의 Output을 StreamPackage의 같은 Channel에 Input으로 등록
4StreamPackage가 Input Failover 설정에 따라 활성 입력 선택

Failover 감지와 전환 ​

StreamPackage 측에서 입력 상태를 모니터링합니다:

감지 조건동작
Input A 스트림 끊김Input B로 자동 전환
Input A 복구설정에 따라 A로 복귀 또는 B 유지
양쪽 모두 끊김Slate(대기 화면) 또는 스트림 중단

전환 시 시청자 경험은 이렇습니다.

StreamLive Failover 상태 전환


Failover 시나리오별 동작 ​

시나리오 1: 인코더 → StreamLive 입력 끊김 ​

인코더에서 Channel A로 가는 입력이 끊기고, Channel B에는 정상적으로 입력이 들어가는 상황입니다.

  • Channel A의 출력이 멈춤
  • StreamPackage가 Input A의 스트림 부재를 감지
  • Input B(Channel B의 출력)로 전환
  • 전환 시간: 수초 (StreamPackage의 감지 주기에 따름)

시나리오 2: StreamLive 채널 자체 장애 ​

인코더는 Channel A와 Channel B 양쪽에 정상적으로 입력을 보내지만, Channel A 내부에서 장애가 나 출력이 나오지 않는 상황입니다.

  • 입력은 들어오지만 Channel A의 트랜스코딩/패키징이 실패
  • 결과는 시나리오 1과 동일 — StreamPackage 입장에서는 "입력이 안 오는 것"으로 보임
  • Input B로 자동 전환

시나리오 3: 인코더 소스 자체 장애 ​

인코더 자체에 소스가 들어오지 않아 Channel A와 Channel B 양쪽 모두에 입력이 끊기는 상황입니다.

  • 양쪽 모두 입력 없음
  • StreamPackage의 Slate(대기 화면) 출력 또는 스트림 중단
  • 이건 Failover로 해결 불가 — 소스 이중화가 별도로 필요

AWS MediaLive vs StreamLive Failover 비교 ​

항목AWS MediaLiveStreamLive
이중화 단위Standard Channel (내장)채널 2개 수동 구성
설정 복잡도채널 생성 시 "Standard" 선택채널 2개 + StreamPackage Input 2개 수동 연결
Failover 주체MediaLive + AWS MediaPackageStreamPackage (입력 모니터링)
전환 시간수초수초 (StreamPackage 감지 주기)
비용Standard = Single의 2배채널 2개 = 비용 2배
입력 FailoverInput Failover Settings (채널 내 자동 전환)채널 레벨에서는 불가. 인코더가 2곳에 동시 푸시
운영 부담낮음 (서비스가 관리)중간 (채널 2개 동기화 관리 필요)

실무 고려사항 ​

비용 ​

Failover = 비용 2배. 이건 어느 플랫폼이든 동일합니다. 차이는 "서비스가 알아서 해주느냐 / 직접 구성하느냐"일 뿐입니다.

StreamLive Failover 비용:
  Channel A 비용 + Channel B 비용 = 2x
  + StreamPackage Input 2개 (추가 비용 미미)

채널 동기화 ​

두 채널의 설정이 동일해야 합니다. 트랜스코딩 템플릿, 출력 포맷, ABR 래더가 한쪽만 다르면 전환 시 디코더 리셋이 발생할 수 있습니다.

실무에서 가장 흔한 실수: "Channel B를 나중에 만들었는데 트랜스코딩 템플릿을 업데이트 안 해서, 전환 시 해상도 래더가 달라 ABR 스위칭이 깨짐." 채널 설정 변경 시 양쪽 동시 업데이트를 강제하는 운영 프로세스가 필요합니다.

Failover 구성 시점 ​

상황권장
테스트/개발 환경Single Channel. 비용 절약
일반 라이브 (가끔 이벤트)Single Channel + 모니터링. 장애 시 수동 대응
상시 라이브 (24/7)Dual Channel. 사람이 항상 앉아있을 수 없으니 자동 전환 필수
대형 이벤트 (스포츠, 콘서트)Dual Channel + 소스 이중화 + 리전 이중화. 돈으로 안정성을 삽니다

마치며 ​

StreamLive의 Failover는 "서비스가 해주는" 게 아니라 "사용자가 설계하는" 것입니다. Standard Channel 하나면 끝나는 AWS와 달리, 채널 2개를 만들고 StreamPackage에서 전환 로직을 태우는 구조를 직접 잡아야 합니다.

귀찮지만 장점도 있습니다. AWS Standard Channel은 "동일 리전 내 이중화"만 지원하는데, StreamLive에서는 채널을 다른 리전에 각각 배치해서 크로스 리전 Failover도 구현할 수 있습니다. 구조가 열려있으니 자유도가 높습니다.

핵심은: Failover = 비용 2배. 이건 피할 수 없습니다. "2배를 내고 자동화를 살 것인가, 1배만 내고 장애 시 수동 대응할 것인가"가 진짜 비즈니스 결정입니다. 그리고 라이브에서 "수동 대응"이란, 새벽 3시에 전화받고 콘솔 열어서 스트림 확인하는 걸 의미합니다.

참고 자료 ​

基于 VitePress 构建 · 部署于腾讯云 EdgeOne Pages