본문 바로가기

Unity

[Unity] AssetBundle Parellel Download

0. 서두

모바일 게임이 미드코어를 넘어 하드코어로 진화함에 따라 그 덩치 역시 만만치 않게 커지게 되었다.
이미 1년전부터 A-RPG, MMORPG를 설치하면, 1기가가 훌쩍 뛰어넘는 경우를 흔치 않게 볼 수 있게 되었다.
 
상황이 이렇다보니, 압축된 애셋 번들을 적게는 400~500에서 많게는 600-700 MB 이상 배포를 해야되는데, (Funnel 분석을 해 보면)이 구간에서 적지 않은 유저들이 이탈된다. 네트워크가 좋은 나라에서는 그나마 괜찮은데, 그렇지 못한 Region에서는 이 문제의 심각성이 배가된다.
 
DL을 다운로드 받는 동안 유저가 이탈하지 않도록 꾸준히 방법론들을 시도하였는데, 이미 만화 또는 영상을 보여주는 것으로는 실질적으로 DL 이탈률을 낮추지 못함이 업계의 정설이다.
 
결국 핵심은 DL 크기를 작게 만들거나, DL을 빨리 받도록 하는 것.
즉, DL 다운로드의 절대적 시간을 최소한으로 하는 것 뿐인 것이다.
 

1. 순차 -> 병렬 방식

이전 프로젝트에서는 애셋번들을 취급할 때 WWW.LoadFromCacheOrDownload()를 사용하였고, 50개 가까이 되는 애셋 번들 파일을 하나씩 순차적으로 처리하는 방식을 사용하였다.
 
[1번 다운로드... => 1번 완료 => 2번 다운로드... => 2번 완료 => ... => 마지막 다운로드... => 마지막 완료]
 
유니티의 WWW는 비동기성을 띄며, 다운로드 관련 함수의 반환 객체를 가지고 Co-Routine을 돌며 진행 상황, 완료 여부 등을 체크할 수 있다.
그렇다. 꼭 한번에 하나씩만 Request를 보낼 필요가 없는 것이다.
이 성질을 이용하여 한번에 최대 4개의 Request를 유지하도록 구현을 변경하였으며, 대략의 구현론은 다음과 같다.
 
  1. 다운로드 해야 할 파일들을 대기큐에 쌓음.
  2. Update 또는 Update 성격의 Coroutine에서 동시 다운로드 숫자만큼 WWW.LoadFromCacheOrDownload 시도
  3. 4개 중 하나의 파일이 완료되면, 다시 하나의 파일을 시작시켜 4개의 다운로드가 계속 활성화되게 유지
  4. 모든 파일의 다운로드가 완료될 때까지 3번 반복.
 
핵심은 "로컬 네트워크 대역폭이 CDN의 Outbound 대역폭을 상회할 때 다운로드를 늘려 속도적 이득을 얻는 것" 인데, 결과는 성공적이었다. 일례로, 기가 네트워크 환경(거의 혼잡이 없는 상태)에서 테스트 했을 때, DL을 다운로드하는 시간이 1/3 이상으로 단축되었다.

 

물론, CDN의 outbound 대역폭보다 낮은 네트워크 환경을 가지는 환경에서는 얻는 이득이 없다.
 
이것을 적용했다 하여, 모든 서비스 지역에서 DL 다운로드 시간을 단축시켰다 말할 순 없지만, 한/미/일 등의 주요 매출 국가이면서 네트워크 환경이 좋은 곳에서는 분명 더 좋은 사용자 경험을 준다고 할 수 있다.