파일 시스템 전송 권장사항

이 페이지에서는 파일 시스템 전송 권장사항을 설명합니다.

성능 권장사항

다음은 전송 성능을 향상하기 위한 권장사항입니다.

전송 에이전트 성능을 최대로 높이세요.
일반적으로 크기가 100GB 이상인 대용량 데이터 코퍼스를 전송하여 성능을 평가하세요.

Storage Transfer Service는 대규모 처리량 최적화 서비스이므로 소규모 테스트 데이터 세트의 성능은 프로덕션에 있는 대규모 데이터 세트의 성능을 나타내지 않습니다.
개별 원본 폴더를 100만 개의 파일로 제한하세요. 수백만 개의 파일이 들어 있는 디렉터리로 인해 전체 전송 속도가 저하될 수 있습니다.
별도의 가상 머신(VM)에서 에이전트를 실행하면 리소스 소비를 보다 효과적으로 확장할 수 있습니다.
에이전트 머신의 네트워크 인터페이스 크기가 필요한 읽기/쓰기 대역폭에 맞게 조정되었는지 확인합니다.

예를 들어 20Gbps의 광역 통신망(WAN)을 완전히 활용하려면 에이전트 머신의 네트워크 인터페이스가 네트워크 파일 시스템에서 데이터를 읽기 위해 20Gbps를 지원하고, Cloud Storage로 데이터를 전송하기 위해 다른 20Gbps 또는 총 대역폭 40Gbps를 지원해야 합니다.
에이전트 머신의 CPU, 메모리, 네트워크를 모니터링하여 머신이 다른 워크로드로 인해 과부하되지 않도록 합니다. 머신이 과부하되면 성능에 부정적인 영향을 미칠 수 있습니다. 추천 메모리 및 CPU 수치는 에이전트 하드웨어 요구사항을 참조하세요.

멀티파트 업로드

POSIX 파일 시스템에서 Cloud Storage로 전송하거나 POSIX 파일 시스템 간에 전송하려면 멀티파트 업로드를 사용 설정하는 것이 좋습니다. 멀티파트 업로드에서는 큰 파일(>1GiB)을 작은 부분으로 나누고 해당 부분을 동시에 업로드하여 큰 파일이 포함된 전송의 속도를 최대 300% 높일 수 있습니다.

HDFS 및 S3 호환 파일 시스템은 멀티파트 업로드를 지원하지 않습니다.

멀티파트 업로드 사용 설정

멀티파트 업로드를 사용 설정하려면 다음 안내를 따르세요.

전송 에이전트를 승인하는 계정(사용자 계정 또는 서비스 계정)에 필요한 권한을 부여해야 합니다.
대상 또는 중간 버킷에 보존 정책 또는 객체 보존 조치가 없어야 합니다.

사용 설정하면 Storage Transfer Service에서 전송 속도가 개선될 가능성이 높은 경우 멀티파트 업로드를 자동으로 사용합니다.

멀티파트 객체 수명 주기 규칙 구성

Cloud Storage 객체 수명 주기 관리를 사용하여 미완료 멀티파트 업로드를 취소하고 관련 부분을 삭제할 수 있습니다. Cloud Storage 문서의 미완료 멀티파트 업로드 취소를 참조하세요.

age 값을 7일로 설정하는 것이 좋습니다.

멀티파트 업로드 중지

멀티파트 업로드를 중지하려면 docker run을 사용하여 전송 에이전트를 다시 설치하고 --enable-multipart=false를 전달합니다.

sudo docker run --ulimit memlock=64000000 -d --rm \
-v /usr/local/research:/usr/local/research \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT_ID \
--agent-pool=AGENT_POOL \
--creds-file=CREDENTIAL_FILE \
--hostname=$(hostname) \
--enable-multipart=false

다음을 바꿉니다.

PROJECT_ID: 전송을 호스팅하는 프로젝트 ID를 지정합니다.
CREDENTIAL_FILE: 전송 에이전트가 인증에 서비스 계정을 사용하는 경우 JSON 형식의 서비스 계정 사용자 인증 정보 파일 경로를 지정합니다.

또는 전송 에이전트(사용자 계정 또는 서비스 계정)를 승인하는 계정에서 필수 권한을 취소합니다.

전송 에이전트 성능 극대화

전송 성능은 다음 변수의 영향을 받습니다.

파일 시스템 기능
기본 하드웨어 제한사항

하드 드라이브 미디어 유형, 입력/출력 버스, 근거리 통신망(LAN) 연결은 모두 성능에 영향을 줍니다.
WAN 처리량 및 사용률

WAN의 속도가 느리거나 많이 소비되면 성능이 저하됩니다.
파일 특성

예를 들어 대용량 파일이 여러 개인 경우 네트워킹 오버헤드로 인해 작은 파일이 여러 개일 때보다 네트워크 처리량이 높습니다.

이러한 변수 때문에 실제 성능을 예측하거나 사용할 수 있는 최적의 에이전트 수를 제공할 수 없습니다.

전송 시 내결함성이 유지되도록 가능한 한 여러 머신에서 적어도 3개의 에이전트를 사용하는 것이 좋습니다. 전송이 동적으로 증가하면 전송이 실행되는 동안 전송 에이전트를 추가할 수 있습니다.

에이전트 추가의 영향을 관찰하고 사용자 환경에 가장 적합한 에이전트 수를 선택하려면 다음을 수행합니다.

실행하는 데 1시간 이상이 걸리는 대규모 전송을 시작합니다. 예를 들어 파일이 100,000개 이상 있고 총 크기가 100GB 이상인 전송을 시작합니다.
Cloud Monitoring을 사용하여 전체 에이전트 처리량을 관찰합니다.
처리량이 안정될 때까지 기다린 후 WAN 용량 또는 대역폭 한도로 인해 제한되는지 확인합니다.
WAN 용량이 포화 상태가 아니고 원하는 전송 한도에 도달하지 않은 경우 다른 에이전트를 추가합니다. 추가된 에이전트는 전송 처리량을 자동으로 늘립니다. 처리량이 Cloud Monitoring에서 안정화될 때까지 약 3분 정도 기다립니다.

3단계와 4단계를 반복하여 원하는 한도에 도달할 때까지 한 번에 하나의 에이전트를 추가합니다. 컴퓨팅, 파일 시스템, 네트워크 리소스를 사용할 수 있는 경우 에이전트 풀당 최대 100개의 에이전트를 동시에 실행할 수 있습니다.

원하는 한도에 도달하기 전에 아웃바운드 대역폭이 포화되는 경우 다음 중 하나를 수행할 수 있습니다.

에이전트를 추가했지만 처리량이 증가하고 WAN이 포화되지 않는다면 파일 시스템 처리량을 조사하세요. 드문 경우지만 파일 시스템 처리량이 포화되어 전송 성능을 향상할 수 없는 경우가 있습니다.

에이전트 이름 지정

에이전트 이름을 지정할 때는 다음을 수행하는 것이 좋습니다.

에이전트에 항상 호스트 이름을 포함합니다. 이렇게 하면 에이전트가 실행 중인 머신을 찾을 수 있습니다. --hostname=$(hostname)을 Docker run 명령어에 전달하는 것이 좋습니다.
모니터링 및 인프라 조직의 컨텍스트에서 에이전트를 식별하는 데 도움이 되는 에이전트 프리픽스 스키마를 선택합니다. 예를 들면 다음과 같습니다.
- 별도의 전송 프로젝트 세 개가 있으면 팀 이름을 에이전트에 포함할 수 있습니다. 예를 들면 logistics입니다.
- 서로 다른 두 데이터 센터에 서로 다른 전송 프로젝트 두 개를 실행할 경우 데이터 센터 이름을 에이전트 프리픽스에 포함할 수 있습니다. 예를 들면 omaha입니다.