본문 바로가기

1.관리 및 아키텍처

서버 동영상 처리 용량에 대해

서버 동영상 처리 용량에 대해

작성자: 박재성 (ospace114@empal.com) http://ospace.tistory.com

서버 동영상 처리 용량에 대해서 몇자 적어 보려한다.

서버에서 동영상 처리 용량을 계산하다고 하면, 보통 용량이 크기로 생각할 수 있다. 당연히 맞는 말이다. 그러나 동영상 처리에 있어서 이건 애매한 기준이 된다. 동영상은 크기 단위 보다는 시간 단위로 보는게 적절하다. 물론 개인 상황에 따라서 크기 단위를 더 중요시 될때도 있다.

여기서 고려할 상황은 상업적 목적으로 인코딩 서버를 구동하고 해당 서버의 처리 능력을 어떻게 확인하는게 좋을지 보는 것이다.

먼저 인코딩 테스트를 간략하게 해보자. 아래는 소스는 틀리고 결과를 같게하였다.
인코딩 환경은 그냥 쓰던 시스템에서 했으니 프로그램 이것 저것 깔린 상태에서 해서 시간이 조금 많이 걸렸을 것이다. 지금은 최소 시간을 보려는 것이 아니라 상대 비교를 하기 위한 것이기에 그냥 넘어가기로 한다.

[Source]
test1.avi  
Xvid 759Kbps 640x480 (24fps)/MP3  Stereo 22KHz 56kbps  

test2.mpg  
Mpeg 1229Kbps 352x240 (29.97fps)/LayerII 44Khz Stereo 224Kbps  

[Tool]
OS: Windows XP Pro 5.1.2600  
Encoding Tool: VirtualDub 1.6.15  
resize: 320x240 (Bicubic)  

[Target]
Duration: 3min  
Video: Xvid 600Kbps 24fps  
Audio: MP3 48Kbps 22KHz Stereo  

[Result]
test1.avi - 1min 19sec, 14,632,380B  
test2.avi - 2min 02sec, 14,611,204B  

[Enviroment]
Athlon 64 3200+/ 1GB RAM / RADEON X600 PRO  

결과를 동영상 소스 형태에 따라서 결과도 달라진다. 중요한 문제인다. 이로 인해 결과를 도출하기 힘들어진다. 그렇기에 최악과 최선의 결과가 생기게 된다.
즉, 최악의 경우 1분 19초에서 가장 빠르면 1분 10초 시간이 정해진다.
물론 더많은 샘플을 시험해봐야 알수 있지만...

단일 CPU의 동영상 처리 능력

그러면 현재 싱글 CPU에서 3분 동영상 만들기 위한 최선과 최악의 시간 간격이 구해진다.
하루 시간에 각 값을 나누면, 하루에 인코딩 가능한 파일 개수를 알 수 있다.

하루시간(분) / 최악시간(분) = 최악의 처리 개수
하루시간(분) / 최선시간(분) = 최선의 처리 개수

처리 시간 표시 방법

때에 따라서 이런 최악의 시간과 최선의 시간을 결과 동영상 시간 비율로 구할 수 있다.
앞의 예를 참조하면,

test1.avi인 경우
인코딩시간/결과재생시간 = 79초(1분 19초) / 180초(3분) = (약) 0.44 배

test2.avi인 경우
인코딩시간/결과재생시간 = 70초(1분 10초) / 180초(3분) = (약) 0.39 배

이렇게 하면, 결과 동영상이 5분인 경우 위의 비율로 계산 할 수 있다.

300초(5분) * 0.44 = 132초(2분 12초)

실제로 test1를 5분 인코딩 했을 경우, 2분 11초 정도 나왔다. 거의 비슷하게 나온다.

(이건 단순 인코딩 테이스에 의한 결과이기 때문에 정확히 검증된 이론은 아니다.)

이를 이용하면 파일 속성별 인코딩 시간 비율을 가지고 있으면 인코딩 시간에 따라서 하루 처리 가능한 인코딩 개수가 나온다.

결국 하루 처리 가능한 시간 비율 범위는 0.39~0.44가 된다고 볼 수 있다.

위는 결과 동영상이 XVid 코덱을 사용했다. 실제로 인터넷 상에서는 Window Media Player의 WMV 혹은 Flash Player의 FLV를 사용하기 때문에 해당 파일 포멧에 대한 재 측정이 필요한다.
그리고, 결과물 동영상 품질에 따라서 달라지기에 동영상 크기, 비트 레이트, 프레임수, 그리고 오디오에 대한 부분도 같이 고려해야 한다.

제공하려는 서비스와 환경에 맞게 이런 동영상 포멧을 정하는게 중요하다.

멀티 CPU인 경우

보통 서버는 여러 개의 CPU를 설치할 수 있다. 이런 환경에서 인코딩 성능은 어떻게 될까?
멀티 CPU의 성능을 최대한 끌어 올리려면 사용하는 인코딩 툴도 멀티 CPU를 지원해야된다.
이런 가정하에서 시험할 수있다.

본인이 이런 시스템 환경이 없기 때문에 실제 상의 결과를 보여 줄 수는 없고, 앞의 결과의 나의 지식을 동원한 가상의 결과와 조건들을 나열 할 수 밖에 없다.

조건1: 모든 CPU가 하나의 인코딩 작업에 집중해서 처리
조건2: 여러 인코딩 작업을 동시에하여 효율적으로 처리

첫번째 조건이야 그냥 테스트 하면된다. 문제는 두번째 조건이다. 만약 네개의 CPU를 가진 시스템에서 2개의 파일을 인코딩한다면, 조건 1과 2 중에서 어느게 더 효율적일까 하는 문제에서는 당연히 조건 1이 더 효율적일 수 있다.
그러나 파일 천개 가까이 된다면 어느 것이 더 좋을까하는 문제는 좀더 시험해봐야 한다.

조건 1은 앞의 싱글 CPU와 같은 환경이기 때문에 그래로 적용하면 무난하다.
그럼 조건 2를 고려해보자.

여러 인코딩 작업을 동시에..

멀티 CPU는 성능은 한당 단일 CPU 성능에 배수배가 되지 않는다. 특히 운영체제와 사용 프로그램, 그리고 CPU 종류에 따라서 그 결과는 천차만별이다.
그렇기에 현재 시스템 환경이 중요하다. 시스템 환경을 정확히 기록한 후에 다음 작업에 들어간다.

멀티 인코딩 작업을 하기 위해서 test1.avi 혹은 test2.avi 파일을 여러개 복재해서 준비한다.
예를 들어 test1.avi를 test1_1.avi, test1_2.avi, ..., test1_9.avi 등 과 같이 만들어 둔다.

이렇게 단일 파일로 테스트 하는 경우 파일 타입마다 렌더링 결과가 달라 지기 때문에 이를 구분하기 위한 것이다. 위와 같이 한 후에 동시에 작업을 2개, 3개, ... 한 단계씩 증가 시키면서 결과를 기록한다.

  • 작업 개수: 각 작업 인코딩 시간 기록; 인코딩 시간 비율

이렇게 하면 작업 개수별 인코딩 시간 비율이 나올 것이다.

계산 방법은 다음과 같다.

결과물 동영상 시간이 3분이라고 하고, 동영상 품질은 위의 조건과 같다면,

Step1) 동영상 파일 1개당 처리 시간을 구함

단일 작업 파일 한개 인코딩 시간 = 동영상 시간 * 처리비율
다중 작업 파일 한개 인코딩 시간 = 단일 작업 인코딩 시간 / 작업 개수
= (동영상 시간 * 처리비율) / 작업 개수
= 파일 한개 처리 시간

Step2) 동영상 하루당 처리 개수 구함

  • 처리 개수 = 하루시간 / 파일 한개 처리 시간

이렇게 해서 다중 CPU 서버 처리 성능을 계산 할 수 있다.
물론 최대/최소 성능을 계산 할 수 있을 것이다.

중요한 것은 환경마다 처리 결과가 달라지기 때문에 그 부분을 명확히 해야한다.

예)

실제적인 예가 없어서 바로 이해하기는 어려울 것이다. 일단 본인의 시스템 환경을 예로 들어서 살펴보자.

두가지 파일을 시험했는데, 각 인코딩 시간 비율은 0.44(test1.avi)와 0.39(test2.avi)이다.

먼저 동영상 파일 1개 처리 시간을 구해보자.

  • test1.avi 파일 한개 처리 시간 = ( 180초 * 0.44 ) / 1 개 = (약)80 초

  • test2.avi 파일 한개 처리 시간 = ( 180초 * 0.39 ) / 1 개 = 70.2 초

  • test1.avi 하루 처리 개수 = 86400초 / 80초 = 1080개

  • test2.avi 하루 처리 개수 = 86400초 / 70.2초 = 1231개

만약 test1.avi이 최악의 경우에 파일이고 test2.avi가 최선의 파일이라면,
현재 시스템의 처리 능력은 1080개 ~ 1231개가 된다.

덧글:
제가 작성한 내용이 모두에게 도움이 되었으면 합니다. 아직 부족하고 모르는 부분이 많지만, 많은 분들이 인터넷으로 올려주시는 내용이 많은 도움이 됩니다.
참고로 잘 모르거나, 문제가 있다 싶으면 가차없이 메일로 보내 주시거나 이곳에 올려주시면 빠른 시간? 내에 답변을 드리겠습니다.

반응형