S3 간 파일 업로드 시 옵션값 설정에 따른 속도차이 계산(S3 SYNC 성능 개선)

요즘 S3간 데이터 전송에 대한 연구를 좀 하고 있는데,

테스트하다보니 성능차이가 확실히 나는 옵션들이 있어서

공유를 해보려 한다.

Seoul 리전의 s3에서 오하이오 리전의 s3로의 파일 전송을 기준으로 테스트 했다.

---

 

테스트는 옵션을 설정하지 않은채로 aws s3 sync를 사용했을 때(이건 비공개)와,

아래 표와같이 옵션들을 설정해가면서 aws s3 sync의 속도를 비교해봤다.

물론 일시적인 네트워크 환경적인 변수와 표본이 굉장히 적기 때문에 정확한 값들은 아니지만,

대략적으로 속도 향상이 크게나는 옵션들은 확인할 수 있었다.

 

옵션에 대한 설명과 설정하는 방법은 아래 표와 같다.

aws configure set default.s3.max_concurrent_requests 30	한번에 처리 가능한 작업 수. 클수록 속도가 개선되지만, 그만큼 cpu 부하가 심해진다. multipart_threshold와 깊은 관계가 있다.
aws configure set default.s3.max_queue_size 10000	작업에 대한 최대 queue size이다. 클수록 속도를 개선시키지만 역시나 cpu 부하에 영향을 준다.
aws configure set default.s3.multipart_threshold 64MB	멀티파트를 사용시, 하나의 작업에 사이즈이다. 예를 들면, 1GB 파일을 멀티파트로 진행할 때 1GB를 64MB로 나눈 수만큼 동시 작업을 진행한다고 보면 된다. 그리고 그 값의 최대 값이 max_concurrent_requests이다.  1GB 기준 max_concurrent_requests가 10이라고 할때, 한번의 처리 가능한 작업은 64MB * 10해서 640MB이다. max_concurrent_requests와 값을 잘 조절해서 사용해야 최고의 성능을 뽑아낼 수 있다.
aws configure set default.s3.multipart_chunksize 16MB	멀티파트 사용시 한번에 처리하는 작업에서 남은 부분을 저장하는 사이즈 이다. 속도에 큰 영향을 주지는 않는것으로 보였다.
aws configure set default.s3.max_bandwidth 200MB/s	최대 대역폭이다. 당연히 클수록 좋지만, 작은 작업에 너무 많이 잡아먹고 있으면 다른 작업들의 속도가 저하되기에, 적당히 설정해야 한다. 속도에 직접적인 영향을 끼치는 중요한 요소이다.

 

---

 

아래는 테스트 결과이다.

물론 내 테스트 환경이 하드웨어적으로 그렇게 좋지 않고 VM내에서 테스트를 진행했기 때문에

실제 서버환경에서는 이것과 다른 결과가 나타날거다.

훨씬 더 좋은 성능의 옵션 설정이 가능하겠지..

테스트 목적 - s3 sync 성능 개선 테스트 방법 - s3 전송 옵션을 변경하여 테스트(1GB) max_concurrent_requests 20 max_queue_size 10000 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 50MB/s	max_concurrent_requests 20 max_queue_size 10000 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 100MB/s 위의 설정이 CPU 부하나 성능적으로 고려했을 때 가장 좋은 설정 값으로 보인다. 옵션 변경 전 서울 -> 오하이오 전송 시간 : 84초 옵션 변경 후 서울 -> 오하이오 전송 시간 : 47초 옵션 변경으로 44%의 성능 향상
	서울 -> ohio(1G)	결과
max_concurrent_requests 20 max_queue_size 10000 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 50MB/s	첫번째 : 68초 두번째 : 52초 세번째 : 63초	설정을 바꾸기 전과 대략 20~30초 정도의 속도가 향상됨
max_concurrent_requests 20 max_queue_size 10000 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 100MB/s	첫번째 : 51초 두번째 : 58초 세번째 : 47초	50MB보다 대략 10초 정도의 속도가 향상됨
max_concurrent_requests 20 max_queue_size 10000 multipart_threshold 64MB multipart_chunksize 32MB max_bandwidth 100MB/s	첫번째 : 61초 두번째 : 54초 세번째 : 58초	속도에 chunksize는 큰 영향을 끼치지 않는 부분 확인
max_concurrent_requests 80 max_queue_size 10000 multipart_threshold 16MB multipart_chunksize 16MB max_bandwidth 100MB/s	첫번째 : 44초 두번째 : 41초 세번째 : 58초	속도 개선은 확실하나 cpu 부하 심하다, CPU 부하로 인해 속도가 들쑥날쑥 한 것으로 보인다 사용 불가
max_concurrent_requests 40 max_queue_size 10000 multipart_threshold 32MB multipart_chunksize 16MB max_bandwidth 100MB/s	첫번째 : 52초 두번째 : 58초	성능도 위보다 떨어지고, cpu 부하도 많다. 사용 불가
max_concurrent_requests 20 max_queue_size 10000 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 200MB/s	첫번째 : 58초 두번째 : 54초	100MB랑 차이가 크게 없다. 100MB 이상은 의미없어 보인다
max_concurrent_requests 30 max_queue_size 5000 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 200MB/s	첫번째 : 89초	max_queue_size를 줄이면 속도가 크게 줄어든다
max_concurrent_requests 30 max_queue_size 10000 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 200MB/s	첫번째 : 49초 두번째 : 55초 세번째 : 70초	CPU 부하로 인해 속도가 들쑥날쑥 한 것으로 보인다