이 페이지에서는 버킷 이전, 이점, 사용 사례, 작동 방식, 제한사항을 간략히 설명합니다.
개요
Cloud Storage 버킷 재배치를 사용하면 지리적 위치 간에 버킷을 서버리스로 이전할 수 있습니다. 버킷 이전을 사용하면 다음 작업을 할 수 있습니다.
이름을 변경하거나 버킷 내 데이터를 수동으로 전송하지 않고도 기존 버킷을 한 위치에서 다른 위치로 이동할 수 있습니다.
워크로드의 Cloud Storage 구성을 Compute Engine과 조정하여 성능과 비용 효율성을 개선하세요.
이점
버킷 재배치의 이점은 다음과 같습니다.
간소화된 이전: 최소한의 운영 오버헤드로 버킷을 재배치할 수 있습니다. 복잡한 스크립팅이나 여러 단계의 프로세스가 필요하지 않습니다.
연속 작업: 읽기 작업의 다운타임이 없고 쓰기 작업의 다운타임이 최소화되어 이전 프로세스 전반에서 애플리케이션에 계속 액세스할 수 있습니다.
성능 향상: 동일한 리전 내에 Compute Engine 및 Cloud Storage 리소스를 함께 배치하면 지연 시간을 줄이고 성능을 향상할 수 있습니다.
메타데이터 보존: 버킷 재배치 프로세스에서 객체 메타데이터가 유지됩니다. 객체 메타데이터를 보존하면 버킷을 이동한 후에도 기존 애플리케이션 및 워크플로와 호환됩니다.
스토리지 클래스 구성: 자동 클래스를 비롯한 기존 Cloud Storage 클래스 설정을 유지할 수 있습니다. 스토리지 클래스를 보존하면 이전 후에도 비용 구조가 일관되게 유지됩니다.
버킷 이전을 사용해야 하는 이유는 무엇인가요?
다음은 버킷을 이전하는 몇 가지 사용 사례입니다.
데이터 전송 비용 절감: 데이터가 저장된 위치와 멀리 떨어진 위치에서 자주 액세스하는 경우 버킷을 액세스하는 위치와 가까운 위치로 이전하여 데이터 전송 비용을 줄일 수 있습니다. 예를 들어 데이터에 주로 유럽에서 액세스하지만 미국에 저장되어 있는 경우 버킷을 유럽 위치로 이동하여 비용을 줄일 수 있습니다.
성능 개선: 데이터를 Compute Engine에 더 가깝게 이동하여 애플리케이션의 속도와 응답을 개선할 수 있습니다. 예를 들어 애플리케이션이
us-central1에서 실행되지만 데이터가asia-east1에 있는 경우 버킷을us-central1로 재배치하여 지연 시간을 줄일 수 있습니다.회복력 향상: 지역 중단으로부터 중요한 데이터를 보호할 수 있습니다. 예를 들어 데이터가 단일 리전에 저장되어 있는 경우 가용성과 재해 복구를 위해 이중 또는 다중 리전 위치로 데이터를 이전할 수 있습니다.
이전 유형
버킷 이전 시 쓰기 다운타임이 발생하는지는 버킷의 소스 및 대상 위치에 따라 다릅니다. 위치가 이전 유형에 미치는 영향에 관한 자세한 내용은 버킷의 이전 유형 결정을 참고하세요. 버킷 재배치 유형에는 다음 두 가지가 있습니다.
쓰기 다운타임이 있는 버킷 이전: 쓰기 다운타임이 있는 버킷 이전에는 버킷 이전 프로세스 중에 객체 쓰기 작업을 실행할 수 없는 기간이 있습니다.
쓰기 다운타임 없이 버킷 이전: 쓰기 다운타임 없이 버킷을 이전하면 버킷 이전이 백그라운드에서 실행되는 동안 중단 없이 객체 쓰기 작업을 계속 실행할 수 있습니다.
다음 표에서는 쓰기 다운타임과 쓰기 다운타임이 없는 이전 유형 간의 중요한 차이점을 설명합니다.
| 사양 | 쓰기 다운타임이 있는 버킷 재배치 | 쓰기 다운타임 없이 버킷 재배치 |
|---|---|---|
| 쓰기 가능 여부 | 최종 동기화 단계에서 쓰기 작업을 실행할 수 없습니다. | 쓰기 작업이 중단되지 않습니다. |
| 사용자 참여도 | 사용자가 쓰기 다운타임 완료 단계를 시작해야 합니다. | 명시적인 최종화 단계는 필요하지 않습니다. |
| 성능 영향 | 최종 동기화 단계에서 버킷 내 객체를 쓰거나 업데이트할 수 없습니다. | 재배치 중에 객체 읽기 및 쓰기 지연 시간이 늘어날 수 있습니다. |
| 버킷 재배치 취소 | 쓰기 다운타임이 없는 이전보다 빠릅니다. | 취소는 즉시 이루어지지 않습니다. 객체를 백필해야 하므로 시간이 더 오래 걸릴 수 있습니다. |
| 기능 지원 | 쓰기 다운타임이 없는 이전보다 기능 지원이 적습니다. | 여러 파일 업로드, 보관 정책, Firebase, appspot과 같은 기능에 대한 제한사항 이러한 제한사항에 대한 자세한 내용은 제한사항을 참고하세요. |
버킷 이전 유형 결정
소스 및 대상 버킷 위치에 따라 이전 유형이 결정됩니다.
리전, 이중 리전 또는 멀티 리전 간에 버킷을 이전하면 버킷에 쓸 수 없는 다운타임이 발생합니다. 하지만 다음과 같은 경우에는 다운타임 없이 버킷을 이전할 수 있습니다.
두 위치가 동일한 멀티 리전 코드를 공유하는 경우 멀티 리전에서 구성 가능한 이중 리전으로 이전합니다.
두 위치가 동일한 멀티 리전 코드를 공유하는 경우 구성 가능한 이중 리전 간에 재배치합니다.
두 위치가 동일한 멀티 리전 코드를 공유하는 경우 구성 가능한 이중 리전에서 멀티 리전으로 이전합니다.
버킷 이전 프로세스 이해
버킷 재배치는 소스 버킷에서 대상 버킷으로 데이터를 이동하는 데 도움이 됩니다. 소스 버킷에는 이동하려는 데이터가 있고 대상 버킷에는 데이터를 이동하려는 위치가 있습니다.
다음 다이어그램은 버킷 이전 프로세스 흐름을 보여줍니다.
번호가 매겨진 단계는 다이어그램의 번호를 나타냅니다. 다이어그램은 다음 단계를 보여줍니다.
증분 데이터 복사: 증분 데이터 복사 단계는 소스 버킷에서 대상 버킷으로 데이터를 복사합니다. 버킷 메타데이터는 쓰기 잠겨 있어 이전 프로세스에 영향을 줄 수 있는 버킷 변경을 방지합니다. 하지만 버킷의 객체를 쓰고, 수정하고, 삭제할 수는 있습니다. 기간에 영향을 미치는 요소는 다음과 같습니다.
- 버킷 내에서 객체를 업데이트, 삭제 또는 추가하는 빈도는 복사 시간에 직접적인 영향을 미칩니다. 변화율이 높을수록 더 많은 시간이 필요합니다. 최대 객체 이동 속도
Rm, objects/second가 있습니다. 총N개의 객체와 업데이트 빈도R objects/second이면 복사 단계의 소요 시간은N / (Rm - R)초로 추정할 수 있습니다.
대용량 버킷의 경우 제한된 대역폭으로 인해 재배치 시간이 더 많이 필요합니다.
개별 객체의 크기는 복사 시간에 영향을 미칩니다. 대역폭 제약으로 인해 10GB 보다 큰 객체는 10GB 미만의 객체보다 전송하는 데 시간이 더 오래 걸립니다. 예를 들어 1TB 객체를 복사하는 데 하루가 걸립니다. 큰 객체를 0.1~1GB 크기의 작은 객체로 분할하는 것이 좋습니다.
증분 데이터 복사를 시작하는 방법에 관한 자세한 내용은 증분 데이터 복사 단계 시작을 참고하세요.
- 버킷 내에서 객체를 업데이트, 삭제 또는 추가하는 빈도는 복사 시간에 직접적인 영향을 미칩니다. 변화율이 높을수록 더 많은 시간이 필요합니다. 최대 객체 이동 속도
증분 데이터 복사 모니터링: 증분 데이터 복사 단계의 상태를 보려면 장기 실행 작업 목록을 정기적으로 확인하면 됩니다. 증분 데이터 복사 단계의 상태를 확인하는 방법에 관한 자세한 내용은 증분 데이터 복사 단계 모니터링을 참고하세요.
최종 동기화: 쓰기 다운타임이 있는 이전의 경우 증분 데이터 복사가 완료되면 최종 동기화 단계를 트리거해야 합니다. 마지막 동기화 단계에는 데이터 일관성을 보장하기 위해 버킷에 쓸 수 없는 기간이 포함됩니다. 최종 동기화 단계에는 다음 작업이 포함됩니다.
버킷이 일시적으로 쓰기 잠김 상태입니다. 따라서 이 기간에는 버킷 내의 객체를 쓰거나 업데이트할 수 없으므로 데이터 불일치가 방지됩니다.
증분 복사 단계 이후 버킷 내의 객체 데이터에 적용된 모든 변경사항은 대상 버킷에 복사되므로 이전된 버킷에 최신 데이터가 포함됩니다. 객체 복사가 완료되면 소스 버킷과 대상 버킷 간의 데이터 패리티를 보장하기 위해 비교가 실행됩니다. 데이터 비교 후 버킷의 위치가 업데이트되고 모든 요청이 새 위치로 리디렉션됩니다.
모든 데이터가 전송되고 확인되었으며 새 위치에서 버킷이 작동하면 쓰기 잠금이 삭제됩니다. 그런 다음 버킷에서 객체 쓰기 및 업데이트를 재개할 수 있습니다.
최종 동기화 단계를 시작하는 방법에 대한 자세한 내용은 최종 동기화 단계 시작하기를 참고하세요.
제한사항
버킷 이전 서비스는 프로젝트 내 동일한 위치에서 최대 5개의 동시 이전을 지원합니다.
다음 섹션에서는 쓰기 다운타임이 있는 이전과 쓰기 다운타임이 없는 이전에 적용되는 제한사항을 설명합니다.
쓰기 다운타임 제한이 있는 이전
쓰기 다운타임이 있는 이전에는 다음 섹션에 나열된 제한사항이 적용됩니다.
데이터 처리 제한사항
이전 중에 데이터를 처리할 때는 다음과 같은 제한사항이 적용됩니다.
- 테이블 손상: Apache Iceberg를 사용하는 BigLake 외부 테이블과 BigQuery 테이블이 손상되며 수동으로 다시 만들어야 합니다. 영향을 받는 테이블을 자동으로 감지할 수 없습니다.
자동 클래스 객체 처리: 자동 클래스는 액세스 패턴을 사용하여 객체를 액세스 수준이 더 낮은 스토리지 클래스로 전환할 시기를 결정합니다. 버킷 재배치 프로세스의 최종 동기화 중에 자동 클래스가 일시중지되고 객체가 사용량이 더 낮은 스토리지 클래스로 전환되지 않습니다. 최종 동기화가 완료되면 자동 클래스가 다시 시작됩니다.
Standard Storage 클래스의 객체는 다음과 같이 처리됩니다.
- Standard Storage 클래스 객체는 30일 동안 액세스할 수 없으며 그 후에야 Nearline Storage와 같은 더 낮은 클래스로 전환할 수 있습니다. Standard Storage 클래스의 객체가 재배치 중에 이동하면 액세스된 것처럼 취급됩니다. 따라서 이전 프로세스에서 액세스 불가 기간이 재설정되며, 이전 전에 객체가 Nearline Storage로 전환될 뻔한 경우에도 이전이 완료된 후 30일을 더 기다려야 합니다.
비표준 스토리지 클래스의 객체는 다음과 같이 처리됩니다.
Nearline Storage, Coldline Storage 또는 Archive Storage 스토리지 클래스의 객체를 재배치하는 것은 액세스로 간주되지 않습니다. 따라서 이러한 객체의 액세스 불가 기간은 영향을 받지 않습니다.
이전 중에 비표준 스토리지 클래스 버킷에서 객체를 읽거나 쓰면 객체가 Standard Storage와 같은 더 따뜻한 클래스로 자동 업그레이드되지 않으므로 이전 프로세스 중에 불필요한 스토리지 클래스 전환을 방지할 수 있습니다.
객체가 Nearline Storage에서 Coldline Storage로 다운그레이드되도록 예약된 경우 이전 프로세스가 일정을 방해하지 않습니다. 이전이 완료되면 다운그레이드가 계획대로 진행됩니다.
객체 크기 제한: 이전 객체 크기에는 2TB 제한이 적용됩니다.
지원되지 않는 기능
다음 기능을 사용하는 버킷은 재배치할 수 없습니다.
- 고객 관리 암호화 키 (CMEK) 또는 고객 제공 암호화 키 (CSEK)
- 잠긴 보관 정책
- 임시 보존 조치가 적용된 객체
- 멀티파트 업로드. 버킷 이전 프로세스를 시작하기 전에 완료되지 않은 다중 파일 업로드를 완료하거나 중단해야 합니다.
- 태그 이전 중에 태그를 추가하면 이전 프로세스가 실패하므로 권장하지 않습니다.
- Appspot 버킷 App Engine에서 만든 기본 버킷을 해결하기 위한 해결 방법으로 Container Registry를 Artifact Registry로 이전하는 것이 좋습니다.
- Firebase 버킷 Firebase와 연결된 버킷은 재배치할 수 없습니다.
운영 제한사항
쓰기 다운타임이 있는 버킷 이전에는 다음과 같은 운영 제한사항이 적용됩니다.
- 프로젝트 제한사항: 프로젝트 간에 버킷을 재배치할 수 없습니다.
- 재개 가능한 업로드: 진행 중인 재개 가능한 업로드는 데이터 손실을 방지하기 위해 최종 동기화 단계 전에 완료해야 합니다.
- 메타데이터 업데이트: 이전하는 동안에는 버킷의 메타데이터를 업데이트할 수 없습니다.
- 요청 비율 점진적 증가: 이전된 버킷에는 새로 만든 버킷과 동일한 요청 비율 점진적 증가 가이드라인이 적용됩니다.
쓰기 다운타임 제한 없이 이전
쓰기 다운타임 없이 버킷을 이전하는 방법에는 다음과 같은 제한사항이 있습니다.
- 멀티파트 업로드: 완료되지 않은 멀티파트 업로드는 지원되지 않으며 이전하기 전에 완료하거나 취소해야 합니다. 이전하는 동안 새 멀티파트 업로드가 차단됩니다.
- 보관 정책: 모든 보관 정책은 이전하기 전에 잠금 해제해야 합니다.
- Firebase 및 Appspot 버킷: Firebase 또는 Appspot과 연결된 버킷에는 재배치가 지원되지 않습니다.
- 진행률 업데이트: 이전 진행률 업데이트는 선형적이지 않을 수 있습니다.
지원되지 않는 리전
me-central1 리전에서는 소스 또는 대상 버킷의 버킷 재배치를 사용할 수 없습니다.