트랜스코딩 서버 성능 테스트

[jeongmallro]

부하 테스트/모니터링 툴 선택하기

부하 테스트 툴

처음에는 네이버 오픈소스 nGrinder을 선택했으나, Java11까지만 지원하는 관계로 아파치 오픈소스 JMeter를 선택했다. 프로젝트에 Record, Switch 문 등등 Java11로 지원될 수 없는 코드가 많았기 때문이다. 또한 사용법 측면에서도 nGrinder은 스크립트를 Gradle 언어로 작성을 해줘야 했지만 (그렇게 어렵지는 않음) JMeter은 GUI로 값만 입력해서 스크립트를 쉽게 작성할 수 있었으므로 여러모로 JMeter가 편리했다.

모니터링 툴

• Spring Actuator: 시스템 및 스프링 서버의 리소스 등 메트릭 데이터 수집
• Prometheus: Spring Actuator로부터 메트릭 데이터를 시계열 데이터로 저장
  • Node Exporter: 시스템 리소스 모니터링
• Grafana: 데이터를 시각화

모니터링할 API 설명

동기로 진행되는 작업들

• HTTP로 받은 영상 로컬 서버에 저장
• FFprobe로 영상 분석

비동기로 진행되는 작업

• Job: FFmpeg으로 트랜스코딩 + S3에 업로드 + Redis 채널에 publish
• 비동기로 실행되면서 HTTP 응답은 바로 출력됨 (200 - 작업 요청을 잘 받았다는 의미)
• 따라서 HTTP 응답을 분석한 JMeter의 report의 중요도는 그닥 높지 않음

주의깊게 봐야 하는 지표

• 시스템 CPU 사용량 (Node Exporter)
• 시스템 메모리 사용량 (Node Exporter)
• 메서드 실행 시간 (Custom Metric)

트랜스코딩 설정 Thread 수: 5

부하 테스트 설정

업로드 영상 정보

• 크기: 45.3MB
• 길이: 2분 28초
• 해상도: 1920 x 1080 (1080p)

JMeter 스크립트 설정

• Thread 수 (동시에 호출 날리는 유저 수): 5
• Ramp-up period: 10
  • 너무 짧으면
    • 모든 사용자가 동시에 실행돼서 서버에 과부하가 걸릴 수 있음.
  • 너무 길면
    • 마지막 사용자가 시작하기도 전에 앞에 시작한 사용자가 끝나버릴 수 있음.
    • 그럼 테스트가 의미 없어질 수 있음.
  • 처음에는 Thread 수와 동일하게 하여 테스트 해보면서 수를 조정해나간다.

트랜스코딩 서버 스펙

미디어 트랜스코딩에 적합한 컴퓨팅 최적화 인스턴스 중 서울 리전에서 사용할 수 있는 가장 최신 버전의 인스턴스를 사용

c7g.2xlarge

• 스펙

  • 요금: 시간당 USD 0.289
  • vCPU: 8
  • CPU 아키텍처: ARM
  • 메모리: 16GiB

• 단건

  • 전체 실행시간: 111s
  • CPU 사용량: 1(metric), 최대 33.4%(AWS)
  • 메모리 사용량: 1.8GiB
  • 서버에 원본 영상 저장: 0.02s
  • FFprobe로 영상 분석 실행시간: 0.02s
  • FFmpeg으로 트랜스코딩 실행시간: 103s
  • S3에 업로드 실행시간: 6.9s

• JMeter 스크립트

  • 전체 실행시간: 391s ~ 최대 457s
  • CPU 사용량: 1(metric), 최대 100%(AWS)
  • 메모리 사용량: 6.9GiB
  • 서버에 원본 영상 저장: 0.02s ~ 최대 0.07s
  • FFprobe로 영상 분석 실행시간: 0.09s ~ 최대 0.2s
  • FFmpeg으로 트랜스코딩 실행시간: 384s ~ 최대 449s
  • S3에 업로드 실행시간: 6.7s ~ 최대 7.1s

c7i.2xlarge

• 스펙

  • 요금: 시간당 USD 0.357
  • vCPU: 8
  • CPU 아키텍처: x86
  • 메모리: 16GiB

• 단건

  • 전체 실행시간: 115s
  • CPU 사용량: 1(metric), 최대 35.2%(AWS)
  • 메모리 사용량: 1.9GiB
  • 서버에 원본 영상 저장: 0.02s
  • FFprobe로 영상 분석 실행시간: 0.02s
  • FFmpeg으로 트랜스코딩 실행시간: 106s
  • S3에 업로드 실행시간: 8.1s

• JMeter 스크립트

  • 전체 실행시간: 516s ~ 최대 545s
  • CPU 사용량: 1(metric), 최대 100%(AWS)
  • 메모리 사용량: 7.5GiB
  • 서버에 원본 영상 저장: 0.05s ~ 최대 0.1s
  • FFprobe로 영상 분석 실행시간: 0.09s ~ 최대 0.2s
  • FFmpeg으로 트랜스코딩 실행시간: 508s ~ 최대 539s
  • S3에 업로드 실행시간: 6.5s ~ 최대 7.38s

결과

미디어 트랜스코딩을 할 때는 ARM 아키텍처가 성능적으로나 비용적으로 뛰어나다.
특히 병렬 작업 시에 성능 차이가 크다.

단건 결과 비교

• c7g.2xlarge (ARM64)
  • 시간: 111S
  • 비용: 0.089USD
• c7i.2xlarge (x86_64)
  • 시간: 115S
  • 비용: 0.114USD

FFmpeg이 CPU를 많이 잡아먹기 때문에 결국 트랜스코딩 서버에서 멀티스레드로 작업하는 것에 한계가 있다고 느꼈다.
현재로서는 최적의 스레드 개수를 찾기 위해 스레드 설정을 달리하여 테스트해볼 필요성이 있다.
GPU 서버를 대상으로 테스트해보는 것도 유의미할 것이다.

[lsh2613]

엄청 고생하셨네요.
성능 결과를 보고나서 ARM과 x86이 왜 이런 성능 차이가 발생할까? 라는 의구심이 들어 저도 찾아봤습니다.

ARM은 스마트폰, 태블릿 등에 사용되기 떄문에 저전력에 중점을 두고, x86은 데스크탑, 랩탑 등에 사용되기 떄문에 상대적으로 전력 소비가 많기 때문에 일반적으로 성능은 x86이 높다고 합니다.
CPU를 많이 잡아 먹는 것은 그많은 연산이 많이 필요하다는 뜻으로 성능이 좋은 x86 보다 ARM이 더 빠른 것이 신기하네요.

물론 상대적인 성능이고 환경에 따라 달라질 수 있으니 절대적이진 않지만 어떤 이유인지 궁금하네요 ㅋㅋㅋㅋ

Apple 제품들이 주로 ARM 아키텍처를 따르고, 저희가 사용하는 HLS이 apple에서 개발된 스트리밍 프로토콜이라 그런 걸까요? 그렇다면 DASH를 사용하면 어떻게 될까 궁금해지네요..

[jeongmallro]

그리고 찾아보니까 스레드 개수에 따라 결과가 또 달라지는 것 같더라구요

스레딩 : 이 논의의 모든 데이터는 인코딩에 8개의 스레드를 사용한 결과입니다. 4개의 스레드만 사용했을 때 ARM 프로세서와 x86 프로세서의 속도 및 시간 성능이 유사한 것으로 나타났습니다. 즉, 인코딩 속도(또는 1분짜리 비디오의 인코딩 시간)는 ARM과 Intel x86 프로세서에서 비슷한 수준입니다. 하지만 ARM의 저렴한 가격 덕분에 ARM은 여전히 ​​경쟁력 있는 선택지입니다. 반면, 8개의 스레드를 사용하는 ARM 프로세서는 속도, 시간 성능, 그리고 가격 면에서 x86 프로세서보다 훨씬 뛰어납니다.
Video Encoding on ARM vs. Intel x86 – Which Is Better?

사실 제가 한 테스트도 단건은 차이가 얼마 안 나긴 해요! ARM이 더 성능이 좋게 나온 사례도 꽤 많습니다 ㅋㅋ 신기하네요

[lsh2613]

맞아요 ARM이 성능이 떨어진다는 것은 옛날(?) 이야기고 요즘엔 크게 차이 없다는 포스팅도 다수 있긴 하더라구요 ㅋㅋㅋㅋ