프로덕션 전송 스크립팅

개요

대규모 프로덕션 작업(예: 매일 많은 데이터(GiB) 업로드 또는 다운로드)에서 gsutil을 사용하는 경우 성공적인 작업을 보장하기 위해 수행할 수 있는 작업이 많이 있습니다. 특히 이 섹션에서는 gsutil의 재개 가능한 전송 메커니즘에서 대규모 프로덕션 작업을 스크립팅하는 방법을 설명합니다.

재개 가능한 전송에 대한 배경 정보

먼저 gsutil의 재개 가능한 전송 메커니즘과 이 메커니즘에 따라 스크립트를 구현하여 안정적으로 작동하는 방법을 이해하는 것이 도움이 됩니다. gsutil은 모든 크기의 파일을 다운로드하거나 구성 가능한 임곗값(기본적으로 8MiB)보다 큰 파일을 업로드할 때 재개 가능한 전송 지원을 사용합니다. 전송이 간헐적인 네트워크 문제 등으로 인해 중간에 실패하는 경우 gsutil은 잘린 무작위 바이너리 지수 백오프 및 재시도 전략을 사용하여 기본적으로 10분 동안 최대 23회까지 전송을 재시도합니다. 전송이 각 시도에서 진행을 방해하지 않고 실패하는 경우, gsutil은 전송을 포기하지만 구성 가능한 위치에 'tracker' 파일을 보관합니다. 기본 위치는 ~/.gsutil/이며 파일 이름은 버킷 이름과 전송 중인 객체 이름의 SHA1 해시와 파일 이름의 마지막 16자의 조합입니다. 전송이 이러한 방식으로 실패하면 나중에(예를 들어 네트워킹 문제가 해결된 후) gsutil을 다시 실행할 수 있습니다. 재개 가능한 전송은 중단된 부분부터 다시 시작됩니다.

데이터 전송 작업 스크립팅

이 메커니즘에 따라 대규모 프로덕션 데이터 전송 작업을 스크립팅하려면 주기적으로 실행되고 아직 성공하지 않은 파일 전송을 확인하며 gsutil을 실행하여 전송을 복사하는 스크립트를 구현하면 됩니다. 다음은 이러한 유형의 스크립팅을 구현하는 방법에 대한 몇 가지 제안 사항입니다.

  1. 최대 10분 동안 23회 연속으로 아무 진전 없이 재개 가능한 전송이 실패하면 전송을 즉시 재시도를 수행하는 것은 효과가 없습니다. 보다 성공적인 전략은 30분마다 실행되고 실행해야 하는 전송을 결정한 후 전송을 실행하는 크론 작업을 갖는 것입니다. 네트워크에 간헐적인 문제가 발생하면 스크립트는 중단된 부분부터 다시 시작하고 네트워크 문제가 해결되면 전송이 성공합니다.

  2. 적시의 데이터 전송이 비즈니스에 크게 중요한 경우 몇 가지 네트워크 모니터링을 구현하는 것이 좋습니다. 예를 들어 몇 분마다 작은 다운로드를 시도하고 여러 시도가 연속으로(또는 요구사항에 따라 높은 빈도 또는 낮은 빈도로) 실패할 경우 알림을 보내는 작업을 구현하여 IT 직원이 문제를 즉시 조사할 수 있도록 합니다. 일반적으로 모니터링 구현 시 직원이 알림을 무시하도록 만드는 거짓양성 알림을 방지하기 위해 알림 임곗값을 실험해야 합니다.

  3. 전송할 파일을 결정하는 방법에는 여러 가지가 있습니다. 많은 객체(예: 수 십만 개 이상)가 포함된 버킷의 전체 목록을 가져오지 않는 것이 좋습니다. 한 가지 전략은 전송 프로세스를 나타내는 방식으로 객체 이름을 구조화하고 gsutil 프리픽스 와일드 카드를 사용하여 부분 버킷 목록을 요청하는 것입니다. 예를 들어 주기적 프로세스에서 오늘 날짜의 객체를 다운로드하는 경우 연-월-일-개체-ID 형식으로 객체의 이름을 지정한 다음 gsutil ls "gs://bucket/2011-09-27-*" 같은 명령어를 사용하여 오늘 날짜의 객체를 찾을 수 있습니다. gsutil ls "gs://bucket/*-2011-09-27" 같은 명령어를 사용하는 것보다 와일드 카드가 아닌 프리픽스를 사용하는 것이 더 효율적입니다. 뒤에 나온 명령어는 전체 버킷 목록을 요청한 후 gsutil에서 필터링합니다. 반면 앞에 나온 명령어는 Google Storage에 이름이 '*'까지의 모든 문자로 시작하는 객체의 하위 집합을 반환하도록 요청합니다.

    데이터 업로드의 경우 또 다른 기법으로 스크립트가 클라우드에 파일을 성공적으로 복사하면서 '처리 대상' 영역에서 '완료' 영역으로 로컬 파일을 옮길 수 있습니다. 다음과 같은 명령어를 사용하여 이 작업을 동시에 일괄 작업으로 수행할 수 있습니다.

    gsutil -m cp -r to_upload/subdir_$i gs://bucket/subdir_$i
    

    여기서 i는 셸 루프 변수입니다. 각 gsutil cp 명령어 다음에 셸 $status 변수가 0인지 확인하여 실패한 복사본이 있는지 감지한 후 영향을 받는 복사본을 다시 실행합니다.

    이 전략을 사용하면 파일 시스템에서 완료해야 하는 모든 작업을 추적합니다.

  4. 단일 버킷에 객체가 매우 많은 경우(예: 수 십만 개 이상) 버킷 목록을 사용하여 객체를 열거하는 대신 데이터베이스에서 객체를 추적하는 것이 좋습니다. 예를 들어 이 데이터베이스는 다운로드 상태를 추적할 수 있으므로 버킷 목록을 수행하는 대신 주기적 다운로드 스크립트로 데이터베이스를 로컬로 쿼리하여 다운로드해야 하는 객체를 결정할 수 있습니다.

  5. 전송이 실패한 후 부분적으로 다운로드된 임시 파일을 삭제하지 않도록 합니다. gsutil은 중단된 부분부터 다시 시작되어 데이터 무결성을 위해 다운로드된 최종 콘텐츠의 해시를 수행하므로 부분적으로 전송된 파일을 삭제하면 진행 상태가 사라지고 네트워크 사용량이 많아지게 됩니다.

  6. 네트워크 연결 속도가 빠르다면 gsutil -m(멀티 스레드/멀티 프로세스) 옵션을 사용하여 대량의 파일을 빠르게 전송할 수 있습니다. 그러나 일부 파일을 다운로드할 수 없는 경우 gsutil은 성공적으로 다운로드된 파일에 대해서는 추적하지 않습니다. 예를 들어 멀티 스레드 전송을 사용하여 100개의 파일을 다운로드했지만 3개 파일을 다운로드할 수 없는 경우 스크립팅 프로세스가 성공하지 못한 전송을 확인하고 다시 시도합니다. 앞에서 설명한 것처럼 이 경우에는 주기적 확인 및 실행 접근 방식이 적합합니다.

    동시 전송(gsutil -m)을 사용하는 경우 .boto 구성 파일의 parallel_thread_count 설정을 통해 사용 중인 스레드 수를 실험해 볼 수 있습니다. 기본적으로 gsutil은 Linux의 경우 10개의 스레드를 사용하고 다른 운영체제의 경우 24개의 스레드를 사용합니다. 네트워크 속도, 사용 가능한 메모리, CPU 로드 및 기타 조건에 따라 최적일 수도 있고 그렇지 않을 수도 있습니다. 스레드 수를 늘리거나 줄여 실험해보고 환경에 가장 적합한 스레드 수를 찾아보세요.