ec2 탄력적 블록 저장소 볼륨에서 s3으로 400G의 파일을 복사하는 가장 빠른 방법은 무엇입니까?


21

탄력적 블록 저장소 볼륨에서 s3 버킷으로 400G의 파일을 복사해야합니다 ... 약 300k 파일 ~ 1Mb

s3cmds3fuse를 시도했지만 둘 다 정말 느립니다. s3cmd가 하루 종일 실행되어 복사가 완료되었다고 말했으며 버킷을 확인했을 때 아무 일도 일어나지 않았다고 생각합니다. s3cmd는 아무것도 불평하지 않았습니다)

S3Fuse가 다른 하루 종일 작업 중이며 10 % 미만의 파일을 복사했습니다 ...

더 나은 해결책이 있습니까?

물론 Linux (ubuntu 12.04)를 실행하고 있습니다.


2
많은 벤치 마크 (예 : 벤치 마크 )는 S3에 대한 처리량의 3 가지 결정 요소, 즉 1) 파일 크기 2) 병렬 스레드 수 및 3) 인스턴스 크기를 보여주었습니다. 64MB에서 128 개의 병렬 (동시) 1MB 객체 업로드는 m1.xlarge가 보유한 1Gbps 업 링크를 포화시키고 클러스터 컴퓨팅 (cc1.4xlarge) 인스턴스의 10Gbps 업 링크를 포화시켜야합니다. 이를 염두에두고 많은 스크립트가 있어야합니다 (예 : 스크립트 또는 s3cmd-modification)
cyberx86

1
s3-parallel-put이 트릭을 수행했습니다!
aseba

답변:


20

EC2에서 S3까지의 처리량을 결정하는 몇 가지 주요 요소가 있습니다.

  • 파일 크기-파일이 작을수록 더 많은 수의 요청과 더 많은 오버 헤드 및 전송이 필요합니다. 파일 크기가 EC2에서 발생했을 때의 이득은 256kB보다 큰 파일에서는 무시할 수 있습니다. (대기 시간이 긴 원격 위치에서 전송하면 1MiB와 2MiB 사이에서 계속 눈에 띄게 개선되는 경향이 있습니다).
  • 병렬 스레드 수-단일 업로드 스레드는 일반적으로 전체적으로 상당히 낮으며 종종 5MiB / s 미만입니다. 동시 스레드 수에 따라 처리량이 증가하고 64-128 스레드 사이에서 피크가 발생하는 경향이 있습니다. 더 큰 인스턴스는 더 많은 수의 동시 스레드를 처리 할 수 ​​있습니다.
  • 인스턴스 크기- 인스턴스 사양에 따라 더 큰 인스턴스에는 네트워크 대역폭에 대한 더 큰 (그리고 덜 가변적 인) 할당 및 일반적으로 네트워크에 연결된 임시 / EBS 디스크에서 읽는 것을 포함하여 I / O가 더 많은 전용 리소스가 있습니다. 각 카테고리의 숫자 값은 다음과 같습니다.
    • 매우 높음 : 이론적 : 10Gbps = 1250MB / s; 현실적 : 8.8Gbps = 1100MB / s
    • 높음 : 이론적 : 1Gbps = 125MB / s; 현실적 : 750Mbps = 95MB / s
    • 보통 : 이론적 : 250Mbps; 현실적 : 80Mbps = 10MB / s
    • 낮음 : 이론적 : 100Mbps; 현실적 : 10-15Mbps = 1-2MB / s

대량의 데이터를 전송하는 경우 처리량의 유효 이득 (> 10x)이 비용 차이 (2-3x)보다 크므로 클러스터 컴퓨팅 인스턴스를 사용하는 것이 경제적으로 실용적 일 수 있습니다.

위의 아이디어는 상당히 논리적이지만 (스레드 당 캡이 아닐 수도 있지만) 백업하는 벤치 마크를 찾는 것은 매우 쉽습니다. 하나 특히 자세한 하나를 찾을 수 있습니다 여기에 .

1MB 객체의 64 ~ 128 개의 병렬 (동시) 업로드를 사용하면 m1.xlarge에있는 1Gbps 업 링크가 포화되고 클러스터 컴퓨팅 (cc1.4xlarge) 인스턴스의 10Gbps 업 링크가 포화되어야합니다.

인스턴스 크기를 변경하기는 쉽지만 다른 두 가지 요소는 관리하기가 어려울 수 있습니다.

  • 파일 크기는 일반적으로 고정되어 있습니다. EC2에서 파일을 결합하여 S3에서 분할 할 수는 없습니다 (따라서 작은 파일에 대해서는 할 수있는 것이 많지 않습니다). 그러나 큰 파일은 EC2 측에서 분리하여 S3 측에서 재 조립할 수 있습니다 (S3의 멀티 파트 업로드 사용). 일반적으로 이것은 100MB보다 큰 파일에 유리합니다.
  • 병렬 스레드는 제공하기가 조금 더 어렵습니다. 가장 간단한 방법은 한 번에 여러 복사본을 실행하는 기존 업로드 스크립트에 대한 래퍼를 작성하는 것입니다. 더 나은 접근법은 API를 직접 사용하여 유사한 것을 달성합니다. 이 키는 병렬 요청이라는 점을 명심하면 다음과 같은 여러 가지 잠재적 인 스크립트를 찾는 것이 어렵지 않습니다.
    • s3cmd-modification- 이 기능을 추가했지만 몇 년 후에 업데이트되지 않은 s3cmd 초기 버전의 포크입니다.
    • s3-parallel-put- 잘 작동하는 합리적으로 최근의 파이썬 스크립트

8

따라서 많은 테스트를 거친 후 s3-parallel-put 은 트릭을 훌륭하게 수행했습니다. S3에 많은 파일을 업로드 해야하는 경우 분명히 해결책입니다. 의견 을 주신 cyberx86 에 감사드립니다 .


3
호기심으로, a) 400GB를 업로드하는 데 얼마나 걸렸습니까? b) 얼마나 많은 스레드를 사용하셨습니까? c) 어떤 인스턴스 크기를 사용하셨습니까?
cyberx86

1
@ Cyberx86 최근에 대규모 Ec2 인스턴스에서 s3-parallel-put을 사용했습니다. 나는 5 개의 스레드를 사용했으며 10.49 시간에 288.73GB를 복사했습니다.
Gortron


2

이를 위해 C # ( CopyFasterToS3 ) 에 최적화 된 콘솔 응용 프로그램을 작성했습니다 . 나는 EBS vol에 사용했는데, 제 경우에는 20Gb의 2 백만 개가 넘는 파일이있는 5 개의 폴더가있었습니다. 스크립트는 30 분 이내에 실행되었습니다.

에서는 이 문서 어떻게 병렬로 재귀 함수를 사용하여 나타내었다. 다른 언어로 번역 할 수 있습니다.

행운을 빕니다!


1

또한 s3funnel 이 있는데 아주 오래된 것 (2008 년)과 일부 공개 버그이지만 여전히 아마존 자체에 나와 있습니다 : amzn-lnk



1

s3cmd 대신 s3-cli 를 사용해보십시오 . s3cmd 대신 파일을 사용하여 s3 버킷에 파일을 업로드했으며 배포가 거의 17 분 (21-4 분) 단축되었습니다.

여기 링크가 있습니다 : https://github.com/andrewrk/node-s3-cli

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.