Load Test Report
AWS t3.small 환경에서 Mediasoup SFU 부하 테스트 결과.
- 테스트 일자: 2025-12-22 ~ 2025-12-23
- 테스트 플랫폼: Loadero (WebRTC 부하 테스트 SaaS)
- 분석 도구: 커스텀 트래픽 로거 + v8-profiler-next
1. 테스트 환경
1.1 서버 스펙
| 항목 | 사양 |
|---|
| 인스턴스 타입 | AWS EC2 t3.small (프리티어) |
| vCPU | 2 (버스트 가능, 크레딧 제한) |
| 메모리 | 2 GB |
| 네트워크 | 최대 5 Gbps (베이스라인 ~100 Mbps) |
| 미디어 서버 | Mediasoup v3 (SFU) |
1.2 테스트 환경 제약
Loadero HTTPS 요구사항으로 Cloudflare Tunnel 사용 (UDP 미지원 → RTP over TCP).
️ 이 보고서의 Jitter 수치는 TCP fallback 영향을 받은 결과입니다.
상세 환경 구성은 Load Testing Tools 참조.
1.3 테스트 시나리오
| 세션 | 참가자 수 | 비디오 스펙 | 지속 시간 |
|---|
| 1 | 10 명 | 1080P@30FPS | 664 초 |
| 2 | 2 명 | 480P@30FPS | 661 초 |
| 3 | 2 명 | 360P@30FPS | 662 초 |
| 4~11 | 30 명 (8 회) | 1080P@30FPS | 약 666 초 |
2. 테스트 결과
2.1 성능 지표 요약
| 세션 | 참가자 | 해상도 | CPU | Jitter | 패킷 손실 | RTT |
|---|
| 1 | 10 명 | 1080P | 50% | 2,144ms | 0% | 166ms |
| 2 | 2 명 | 480P | 9.6% | 378ms | 0% | 131ms |
| 3 | 2 명 | 360P | 7.4% | 158ms | 0% | 127ms |
2.2 해상도별 성능 비교
| 해상도 | Jitter | CPU | 상태 |
|---|
| 360P | 158ms | 7.4% | 안정 (추천) |
| 480P | 378ms | 9.6% | 양호 (주의) |
| 1080P | 2,144ms | 50% | 불안정 (위험) |
2.3 트래픽 통계
| 세션 | 총 수신 | 평균 속도 | 참가자당 수신 | Consumer 수 |
|---|
| 10 명/1080P | 34,388 MB | 434 Mbps | 43.4 Mbps | 176 개 |
| 2 명/480P | 8,441 MB | 107 Mbps | 53.6 Mbps | 4 개 |
| 2 명/360P | 8,614 MB | 109 Mbps | 54.6 Mbps | 4 개 |
3. 병목 분석
3.1 10 명 Vs 30 명 비교
| 지표 | 10 명 | 30 명 | 변화율 |
|---|
| CPU | 50% | 99% | +98% |
| Jitter | 2,144ms | 2,978ms | +39% |
| Consumer | 176 | 1,510 | +758% |
| 수신 트래픽 | 434 Mbps | 1,272 Mbps | +193% |
3.2 이중 병목 (Dual Bottleneck) 구조
발견: 참가자가 3 배 증가 (10→30 명) 했지만, Jitter 는 1.4 배만 증가
원인:
- Jitter 포화점 존재 - 약 2~3 초에서 포화됨
- 네트워크 병목이 CPU 병목을 가림
- 10 명: 네트워크 포화 (434 Mbps > 100 Mbps), CPU 여유 (50%)
- 30 명: 네트워크 + CPU 모두 포화, 하지만 Jitter 미미하게 증가
| 시나리오 | 1 차 병목 | 2 차 병목 | Jitter |
|---|
| 10 명 | 네트워크 (포화) | CPU (여유) | 2.1 초 |
| 30 명 | 네트워크 (포화) | CPU (포화) | 3.0 초 |
결론: 네트워크가 먼저 포화되면 CPU 병목의 영향이 제한적으로 나타남
3.3 Jitter 이상 원인
- 네트워크 대역폭 초과: 434 Mbps > t3.small 베이스라인 100 Mbps
- Consumer 폭발: 10 명 × 9 × 2(비디오 + 오디오) = 180 개 Consumer
- RTP over TCP: Cloudflare Tunnel 이 UDP 미지원
3.4 UDP Vs TCP 비교
| 항목 | UDP (일반 WebRTC) | TCP (이 테스트) |
|---|
| 패킷 손실 처리 | 스킵 | 재전송 대기 |
| 예상 Jitter | 50~500ms | 500~3000ms |
| HOL Blocking | 없음 | 있음 |
| 프로덕션 사용 | 추천 | 비추천 |
4. CPU 프로파일 분석
4.1 Node.js 프로파일 결과
| 세션 | Node.js Idle | 최대 지연 | High Delay (>5ms) |
|---|
| 10 명/1080P | 98.8% | 84ms | 148 회 |
| 2 명/480P | 99.9% | 80ms | 55 회 |
| 2 명/360P | 99.9% | 80ms | 71 회 |
4.2 분석 결론
- Node.js 시그널링 계층: Idle 98%+ 유지, 부하 없음
- 실제 부하 위치: Mediasoup C++ Worker 프로세스
- CPU 50% 의 의미: Worker 의 미디어 암호화/패킷 처리 부하
5. 결론
5.1 테스트 결과 요약
- t3.small 한계 확인: 10 인 1080P 에서 Jitter 2.1 초로 서비스 불가
- 2 인 360P 는 안정: Jitter 158ms, CPU 7.4%
- 병목 순서: 네트워크 대역폭 → CPU
5.2 배운 점
- SFU N² Consumer 문제: 10 명 → 176 개 Consumer
- 이중 병목 구조: 네트워크가 CPU 병목을 가림
- TCP vs UDP: 재전송 대기가 실시간 미디어에 치명적
- 데이터 기반 의사결정: 추측 → 측정 → 분석
서버 코드는 정상 작동하며, 하드웨어 한계가 주요 원인이었습니다.
6. 참고 자료
본 보고서는 2025-12-23 부하 테스트 결과를 기반으로 작성되었습니다.