-
Notifications
You must be signed in to change notification settings - Fork 2
방송 녹화 시 CPU 과부하 문제를 해결해보자
Seungheon Han edited this page Dec 5, 2024
·
3 revisions


- 약 10명의 사용자가 방송을 송출할 경우 CPU 사용량이 약 20%까지 상승.
- 방송 중 녹화 작업을 시작하면 CPU 사용량이 급격히 상승하여 100%에 도달
- 녹화 영상 품질 저하: HLS로 변환하는 과정에서 CPU 과부하로 인해 패킷 손실 발생.
- 방송 송출 및 시청에 영향: CPU 사용량이 높아져 실시간 스트리밍 품질에도 부정적인 영향을 미침.
- FFmpeg로 WebM 영상을 HLS로 변환하는 작업은 실시간 인코딩이 필요하기 때문에 매우 높은 CPU 리소스를 요구
- 특히, 실시간으로 변환을 진행할 경우 CPU 사용량이 급격히 증가
- 현재 서비스의 주요 목적은 실시간 스트리밍이지 녹화 영상의 실시간 제공이 아님.
- 녹화 영상을 실시간으로 변환할 필요가 없기 때문에, 불필요하게 CPU 리소스를 낭비.
- 녹화 영상을 실시간으로 변환하지 않고, CPU 사용량이 안정된 시점에 변환을 진행하여 시스템 성능을 최적화.
- 녹화를 시작하면 HLS로 변환하지 않고, 원본 WebM 영상을 로컬 저장소에 우선 저장.
- 녹화 종료 시점에 변환 작업 요청을 큐(redis)에 저장.
- 요청 정보:
videoId
,title
,녹화 시간
,파일 경로
등.
- 주기적으로 CPU 사용량을 확인.
- CPU 사용량이 일정 수준 이하(예: 30%)일 때, 큐에서 하나씩 작업을 꺼내 HLS로 변환.
- 변환 작업 완료 시 HLS 파일을 Object Storage에 업로드.
- 이후 사용자에게 제공 가능.
- 녹화 시 CPU 과부하 문제 해결: 녹화 영상을 HLS로 변환하는 작업을 지연 처리함으로써 CPU 사용량을 효과적으로 제어.
- 방송 송출 중 CPU 사용량이 20% 수준으로 유지되어 안정적인 서비스 제공 가능.
- HLS 변환 작업이 지연 처리됨에 따라, 패킷 손실이 현저히 줄어들어 녹화 영상 품질이 개선됨.
- CPU 과부하로 인한 스트리밍 품질 저하 문제 해결.
- 방송 송출 및 시청에 영향을 미치지 않도록 안정적인 성능을 유지.
- 변환 작업을 큐로 관리함으로써 동시 사용자 수 증가에도 안정적으로 대응 가능.
- CPU 사용량 기반 스케줄링을 통해 효율적으로 리소스를 사용하며, 서비스 확장에도 유연하게 대처.

- Mediasoup 포트 매핑 문제
- swagger 같은 응답 코드에 다양한 응답 보여주기
- Sudo가 계속 비밀번호를 요청함
- Docker 이미지가 너무 크다
- Git action에서 도커 이미지 빌드 시간을 단축시켜보자
- Docker compose를 이용해서 메모리 사용률을 줄여보자
- 방송 녹화 시 CPU 과부하 문제를 해결해보자
- Release 브랜치? 너 필요해?
- 로딩이 너무 짧아…!
- NestJS ORM으로 무엇을 사용해야 할까?
- WebRTC를 이용한 1:N 스트리밍 서비스에서 시그널링 서버가 필요할까?
- 실시간 채팅 구현: 인메모리 방식을 선택한 이유
- MySQL 아키텍처 개선: DB 의존성 분리와 서버 역할 명확화
- 브라우저 창이 최소화되면 비디오 송출이 안된다…!
- Mediasoup 기본 개념
- DLTS와 Signaling
- Tell, Don't Ask (TDA) 원칙이란
- VPC(Virtual Private Cloud) 학습 정리
- 순환참조: A 서비스 ‐ B 서비스 vs. A 서비스 ‐ B 레포지토리
- Dto 메서드 전략
- WebRTC란?
- 자바스크립트 패키지 매니저(npm, yarn, pnpm)
- shadcn/ui을 이용해 UI 개발 생산성 높이기
- React 이벤트 핸들러 네이밍(on vs handle)
- React-router-dom의 createBrowserRouter을 사용해보기
- fetch vs axios