버킷을 성공적으로 이전하려면 버킷 이전을 시작하기 전에 목표를 정의하고 버킷 사용량을 파악하세요. 다음 섹션에서는 주요 계획 단계를 설명합니다.
버킷 특성 분석
버킷 이전 시간을 추정하려면 다음 요소를 고려하여 버킷의 특성과 사용량을 분석하세요.
비활성 상태 바이트: 버킷에 저장된 총 데이터 양은 스토리지 비용과 전송 시간에 영향을 미칩니다.
복제: 버킷을 동기식 또는 비동기식으로 다른 리전으로 복제하면 데이터 가용성, 내구성, 비용에 영향을 미칩니다. 자세한 내용은 데이터 가용성 및 내구성을 참고하세요.
데이터 전송: 재배치 중에 버킷 외부로 전송된 데이터의 양은 데이터 전송 비용 계산에 영향을 미칩니다. 버킷의 데이터 전송 비용을 계산하려면 Cloud Storage 가격 책정을 참고하세요.
사용 패턴: 사용 패턴을 통해 버킷 활동 수준 또는 버킷의 사용량을 파악하면 이전 중에 예기치 않은 충돌을 방지하는 데 도움이 됩니다. 버킷의 사용 패턴을 파악하려면 로그를 분석하면 됩니다. 자세한 내용은 사용량 로그 및 스토리지 로그를 참고하세요.
버킷 쓰기 작업: 재배치 프로세스 중에 버킷 쓰기 작업이 자주 발생하면 비용과 기간이 늘어납니다. 객체가 버킷에 쓰이는 빈도를 알아보려면 Cloud Storage 모니터링 개요를 참고하세요.
이전 목표 정의
버킷 특성 분석을 토대로 버킷을 이동하는 이유를 파악합니다. 다음은 버킷을 이전하는 일반적인 목표입니다.
비용 관리: 비용이 더 저렴한 리전으로 이동하여 스토리지 비용을 줄이거나 데이터를 액세스 위치에 더 가깝게 이동하여 데이터 전송 비용을 최소화합니다. Cloud Storage 및 데이터 전송 비용을 계산하고 이를 다른 위치의 잠재적 비용과 비교해야 합니다. Cloud Storage 비용 계산에 관한 자세한 내용은 Cloud Storage 가격 책정을 참고하세요.
성능 개선: 버킷을 사용자 또는 애플리케이션에 더 가깝게 재배치하여 데이터 액세스 속도와 애플리케이션 성능을 개선합니다. 이렇게 하려면 성능이 중요한 지리적 지역을 파악하고 버킷을 재배치합니다.
안정성 개선: 이중 또는 다중 리전 구성을 사용하여 데이터 내구성과 재해 복구 기능을 개선합니다.
버킷 위치 결정
분석 및 목표에 따라 다음 옵션 중에서 이전할 버킷에 가장 적합한 스토리지 위치를 선택합니다.
단일 리전: 한 지리적 지역에 사용자가 집중된 애플리케이션에 비용 효율적인 단일 리전에 데이터를 저장합니다.
이중 리전: 동일한 대륙 내의 두 리전에 데이터의 두 사본을 유지하여 특정 지리적 지역 내에서 가용성과 재해 복구 기능을 개선합니다.
멀티 리전: 여러 리전에 데이터를 분산하여 가장 높은 수준의 가용성과 내구성을 제공합니다.
위치 선택에 관한 자세한 내용은 위치 선택 고려사항을 참고하세요.
이전 시간에 영향을 미치는 요인 이해하기
이전 시간에는 여러 요소가 영향을 미치며 이를 이해하면 필요한 시간을 추정하는 데 도움이 됩니다. 이러한 요소는 이전을 계획하고 예약하는 데 유용한 출발점이 되지만 실제 이전 시간은 예상 시간보다 길거나 짧을 수 있습니다. 따라서 이전을 예약할 때는 지연이 발생할 수 있으므로 버퍼 시간을 추가하세요. 다음 섹션에서는 이전 시간에 영향을 미치는 요인을 설명합니다.
이전 서비스 한도
다음 표에서는 이전 시간에 영향을 미치는 한도를 설명합니다.
| 요소 | 값 | 설명 |
|---|---|---|
| 작업당 최대 요청 비율 | 초당 객체 10,000개 |
서비스가 초당 처리할 수 있는 복사 요청 수입니다.
요청 빈도가 높을수록 더 많은 파일을 동시에 이동할 수 있습니다. 버킷에 작은 파일이 많으면 요청 빈도가 높을수록 이전 속도가 빨라집니다. 대용량 파일이 몇 개만 있는 경우 이 요소의 영향은 적습니다. |
| 프로젝트당 최대 전체 대역폭 | 10GBps |
소스 위치 내에서 단일 프로젝트의 데이터를 전송할 수 있는 최대 속도 또는 대역폭입니다. 동일한 프로젝트 내에서 여러 버킷을 이동하는 경우 버킷이 대역폭을 공유합니다.
대역폭이 높을수록 한 번에 더 많은 데이터를 전송할 수 있습니다. 요청 빈도가 높더라도 대역폭이 작으면 전체 전송 속도가 느려집니다. |
| 단일 객체당 최대 대역폭 | 8MBps |
단일 객체를 전송할 수 있는 최대 속도입니다.
단일 객체당 대역폭이 클수록 객체를 더 빠른 속도로 전송할 수 있습니다. 한 번에 하나의 객체를 이동하는 속도 제한입니다. 요청 빈도가 높고 버킷당 대역폭이 높더라도 개별 객체에 속도 제한이 있으면 전송하는 데 더 오래 걸릴 수 있습니다. |
이전 TTL(수명) 제한
효율적인 리소스 활용을 보장하고 재배치가 무한대로 실행되지 않도록 하기 위해 모든 버킷 재배치에 TTL (수명) 제한이 적용됩니다. TTL은 전체 이전 프로세스가 완료될 수 있는 최대 시간을 나타냅니다.
버킷 이전을 완료할 수 있는 최대 시간은 28일이며 여기에는 초기 사본, 증분 업데이트, 최종 동기화와 같은 이전 프로세스의 모든 단계가 포함됩니다.
이전 프로세스가 28일 TTL 한도를 초과하면 이전 작업이 실패합니다.
진행 중인 버킷 활동
이전 중에 새 객체를 계속 작성하거나 기존 객체를 삭제하거나 버킷의 객체를 업데이트하면 이러한 작업이 복사 요청과 리소스를 놓고 경쟁하게 되어 이전 프로세스가 느려질 수 있습니다.
수명 주기 규칙
특정 시간 후에 객체를 자동으로 삭제하거나 보관처리하는 등 버킷에 수명 주기 규칙이 구성된 경우 이러한 작업으로 인해 전체 이전 시간이 늘어납니다.
관리 허브 사용 설정
소스 위치와 대상 위치 모두에 관리 허브를 사용 설정해야 합니다. Google Cloud 리소스 계층 구조의 여러 수준에서 관리 허브를 사용 설정할 수 있습니다. 포함 및 제외 필터를 사용하여 관리 허브 요금제에 관련 버킷을 포함할 수도 있습니다. 자세한 내용은 관리 허브 사용 설정하기를 참고하세요.
다른 기능의 고려사항
버킷을 재배치하면 다른 Cloud Storage 기능과 다음과 같이 상호작용합니다.
소프트 삭제 사용 설정
버킷을 이전하려면 버킷에서 소프트 삭제를 사용 설정하고 보관 기간을 7일 이상으로 설정해야 합니다. 보관 기간은 소프트 삭제가 삭제된 객체를 영구 삭제하기 전에 보관하는 기간입니다. 소프트 삭제 보관 기간을 구성하는 방법에 관한 자세한 내용은 소프트 삭제 사용을 참고하세요.
할당량 및 한도 확인
할당량 및 클라우드 용량 평가는 특정 리전 또는 영역과 연결됩니다. 따라서 버킷을 새 위치로 이동할 때는 새 위치에 버킷의 데이터를 수용할 만큼 충분한 할당량이 있는지 확인해야 합니다. 할당량 및 한도에 대한 자세한 내용은 할당량 및 한도를 참고하세요.
버킷 이전 유형 결정
버킷을 이전할 때는 최종 동기화 단계에서 새 객체를 업데이트하거나 업로드할 수 없는 쓰기 다운타임 기간이 있을 수 있다는 점에 유의해야 합니다. 또한 이전 프로세스 중에 버킷 구성을 변경할 수 없습니다. 이전 시 다운타임이 발생하는지 확인하려면 이전 유형 결정을 참고하세요.
기존 버킷 태그 삭제
버킷 태그가 연결된 버킷은 재배치할 수 없습니다. 버킷을 이전하기 전에 모든 기존 태그를 삭제해야 합니다. 소스 버킷에서 삭제되는 태그가 액세스 제어에 사용되는 경우 버킷의 데이터가 안전하게 유지되도록 IAM 권한을 설정하는 다른 방법을 사용해야 합니다. 이렇게 하려면 다음 단계를 완료하세요.
태그 구성의 사본을 만들어 안전하게 저장합니다.
소스 버킷에서 기존 태그를 분리합니다.
기존 액세스 제어 규칙과 일치하도록 IAM 권한을 구성합니다.
버킷을 재배치한 후 재배치된 버킷에 기존 태그를 연결합니다.
기존 인벤토리 보고서 구성 저장
기존 인벤토리 보고서 구성은 이전 프로세스 중에 보존되지 않습니다. 이전 프로세스가 완료된 후에는 기존 인벤토리 보고서 구성을 다시 만들어야 하므로 이전 프로세스를 시작하기 전에 기존 인벤토리 보고서 구성을 수동으로 저장하는 것이 좋습니다. 인벤토리 보고서 구성 관리에 대한 자세한 내용은 인벤토리 보고서 구성 만들기 및 관리를 참고하세요.
다음 단계
- 버킷을 재배치하는 방법을 알아보세요.