버킷 재배치 (original) (raw)

이 문서에서는 Cloud Storage 버킷 재배치를 통해 지리적 위치 간에 버킷을 서버리스로 재배치하는 방법을 설명합니다. 버킷 재배치를 사용하면 버킷의 이름을 변경하거나 버킷 내 데이터를 수동으로 전송하지 않고도 기존 버킷을 한 위치에서 다른 위치로 이동할 수 있습니다.

재배치 프로세스를 시작하기 전에 버킷 재배치를 계획하여 중단을 최소화하세요. 재배치를 실행하는 방법에 대한 안내는 버킷 재배치를 참조하세요.

이점

버킷 재배치의 이점은 다음과 같습니다.

간소화된 마이그레이션: 최소한의 운영 오버헤드로 버킷을 재배치할 수 있습니다. 복잡한 스크립팅이나 여러 단계의 프로세스가 필요하지 않습니다.
연속 작업: 읽기 작업의 다운타임이 없고 쓰기 작업의 다운타임이 최소화되어 재배치 프로세스 전반에서 애플리케이션에 계속 액세스할 수 있습니다.
성능 향상: 동일한 리전 내에 Compute Engine 및 Cloud Storage 리소스를 함께 배치하면 지연 시간을 줄이고 성능을 향상할 수 있습니다.
메타데이터 보존: 버킷 재배치 프로세스에서 객체 메타데이터가 유지됩니다. 객체 메타데이터를 보존하면 버킷을 이동한 후에도 기존 애플리케이션 및 워크플로와 호환됩니다.
스토리지 클래스 구성: 자동 클래스를 비롯한 기존 Cloud Storage 클래스 설정을 유지할 수 있습니다. 스토리지 클래스를 보존하면 재배치 후에도 비용 구조가 일관되게 유지됩니다.

사용 사례

다음은 버킷을 재배치하여 달성할 수 있는 사용 사례입니다.

데이터 전송 비용 절감: 버킷의 데이터에 액세스하는 워크로드에 더 가까운 위치로 버킷을 재배치하여 데이터 전송 비용을 절감합니다. 예를 들어 데이터가 미국에 저장되어 있고 주로 유럽에서 액세스하는 경우 버킷을 유럽 위치로 이동하여 데이터 전송 비용을 줄일 수 있습니다.
성능 개선: 데이터를 Compute Engine 워크로드에 더 가깝게 이동하여 애플리케이션의 속도와 응답을 개선할 수 있습니다. 예를 들어 애플리케이션이 us-central1에서 실행되지만 데이터가 asia-east1에 있는 경우 버킷을 us-central1로 재배치하여 지연 시간을 줄일 수 있습니다.
복원력 향상: 리전별 서비스 중단으로부터 중요한 데이터를 보호할 수 있습니다. 예를 들어 데이터가 단일 리전에 저장되어 있는 경우 가용성과 재해 복구를 위해 이중 리전 또는 멀티 리전으로 데이터를 재배치할 수 있습니다.

재배치 유형

버킷 재배치에는 두 가지 유형이 있습니다.

쓰기 다운타임이 있는 버킷 재배치: 쓰기 다운타임이 있는 버킷 재배치에는 버킷 재배치 프로세스 중에 객체 쓰기 작업을 실행할 수 없는 기간이 있습니다.
쓰기 다운타임 없이 버킷 재배치: 쓰기 다운타임 없이 버킷을 재배치하면 버킷 재배치가 백그라운드에서 실행되는 동안 중단 없이 객체 쓰기 작업을 계속 실행할 수 있습니다.

버킷의 소스 및 대상 위치에 따라 버킷 재배치 시 쓰기 다운타임이 발생하는지 여부가 결정됩니다. 다음 표에서는 버킷의 위치가 재배치 중 쓰기 다운타임에 미치는 영향을 보여줍니다. 여기에는 다운타임이 있는 재배치와 다운타임이 없는 재배치 간의 차이점도 포함됩니다.

사양	쓰기 다운타임이 있는 버킷 재배치	쓰기 다운타임이 없는 버킷 재배치
버킷 위치	다음 위치 간에 버킷을 재배치하면 다운타임이 발생합니다. 리전이중 리전멀티 리전멀티 리전 및 사전 정의된 이중 리전두 위치의 멀티 리전 코드가 다른 경우 멀티 리전 및 구성 가능한 이중 리전	다음 위치 간에 버킷을 재배치할 때 두 위치가 동일한 멀티 리전 코드를 공유하는 경우 다운타임이 발생하지 않습니다. 구성 가능한 이중 리전멀티 리전 및 구성 가능한 이중 리전
쓰기 가능 여부	마지막 동기화 단계에서는 쓰기 작업을 실행할 수 없습니다.	이전하는 동안 쓰기 작업은 중단 없이 계속됩니다. 참고: 쓰기 다운타임이 없는 정책 변경은 진행 중인 재개 가능한 업로드가 먼저 완료되기를 기다려야 하므로 완료하는 데 최소 7일이 걸립니다.
사용자 참여	쓰기 다운타임 완료 단계를 시작해야 합니다.	명시적인 완료 단계는 필요하지 않습니다.
성능 영향	최종 동기화 단계에서는 버킷에 객체를 쓰거나 업데이트할 수 없습니다.	재배치 중에 객체 읽기 및 쓰기 지연 시간이 늘어날 수 있습니다.
버킷 재배치 취소	쓰기 다운타임 없는 재배치보다 빠릅니다.	취소는 즉시 이루어지지 않으며 객체를 백필해야 하므로 시간이 더 걸릴 수 있습니다.
기능 지원	쓰기 다운타임 없는 재배치보다 기능 지원이 적습니다. 지원되지 않는 기능에 관한 자세한 내용은 지원되지 않는 기능을 참고하세요.	멀티파트 업로드, 보관 정책, Firebase, appspot과 같은 기능에는 제한사항이 있습니다. 제한사항에 관한 자세한 내용은 제한사항을 참고하세요.
최소 재배치 기간	없음	7일

버킷 재배치 프로세스 이해

버킷 재배치는 소스 버킷에서 대상 버킷으로 데이터를 이동하는 데 도움이 됩니다. 소스 버킷에는 이동하려는 데이터가 있고 대상 버킷에는 데이터를 이동하려는 위치가 있습니다.

다음 다이어그램은 버킷 재배치 프로세스 흐름을 보여줍니다.

그림 1. 버킷 재배치 프로세스 흐름(확대하려면 클릭)

* 최종 동기화는 쓰기 다운타임이 있는 재배치에만 필요합니다.

다음 표에는 세 가지 기본 단계와 각 단계의 설명이 나와 있습니다.

단계	설명
테스트 실행 수행(선택사항)	실제 데이터 전송이 시작되기 전에 잠재적인 문제를 식별하기 위해 버킷 재배치 프로세스를 시뮬레이션합니다.
재배치 단계 시작하기	소스 버킷에서 대상 버킷으로 데이터를 복사합니다. 버킷 메타데이터는 쓰기가 잠겨 있어 재배치 프로세스에 영향을 줄 수 있는 버킷 변경을 방지합니다. 하지만 버킷의 객체를 쓰고, 수정하고, 삭제할 수는 있습니다. 기간에 영향을 미치는 요인은 다음과 같습니다. 버킷 내에서 객체를 업데이트, 삭제 또는 추가하는 빈도는 복사 시간에 직접적인 영향을 미칩니다. 변화율이 높을수록 더 많은 시간이 필요합니다. 최대 객체 이동 속도 `Rm, objects/second`가 있습니다. 총 객체 수가 `N`이고 업데이트 빈도가 `R objects/second`이면 복사 단계의 소요 시간은 `N / (Rm - R)`초로 추정할 수 있습니다.대용량 버킷의 경우 제한된 대역폭으로 인해 재배치 시간이 더 많이 필요합니다. 개별 객체의 크기는 복사 시간에 영향을 미칩니다. 대역폭 제약으로 인해 10GB 보다 큰 객체는 10GB 미만의 객체보다 전송하는 데 더 오랜 시간이 걸립니다. 예를 들어 1TB 객체를 복사하는 데는 하루가 걸립니다.
최종 동기화 단계 시작(쓰기 다운타임이 있는 재배치에만 필요)	최종 동기화를 시작하면 버킷이 쓰기 잠금됩니다. 따라서 이 기간에는 버킷 내의 객체를 쓰거나 업데이트할 수 없으므로 데이터 불일치가 방지됩니다. 하지만 버킷에서 계속 읽을 수 있습니다.모든 데이터가 전송되고 확인되었으며 새 위치에서 버킷이 작동하면 쓰기 잠금이 자동으로 삭제됩니다. 그런 다음 버킷에서 객체 쓰기 및 업데이트를 재개할 수 있습니다.

제한사항

버킷 재배치 서비스는 프로젝트 내 동일한 위치에서 최대 5개의 동시 재배치를 지원합니다.

다음 섹션에서는 쓰기 다운타임이 있는 재배치와 쓰기 다운타임이 없는 재배치에 적용되는 제한사항을 설명합니다.

쓰기 다운타임이 있는 재배치 제한사항

쓰기 다운타임이 있는 재배치에는 다음 섹션에 나열된 제한사항이 적용됩니다.

데이터 처리 제한사항

재배치 중에 데이터를 처리할 때는 다음과 같은 제한사항이 적용됩니다.

테이블 손상: Apache Iceberg를 사용하는 BigLake 외부 테이블과 BigQuery 테이블이 손상되며 수동으로 다시 만들어야 합니다. 영향을 받는 테이블을 자동으로 감지할 수 없습니다.
자동 클래스 객체 처리: 자동 클래스는 액세스 패턴을 사용하여 객체를 사용률이 낮은 스토리지 클래스로 전환할 시기를 결정합니다. 버킷 재배치 프로세스의 최종 동기화 중에는 자동 클래스가 일시중지되고 객체가 사용률이 낮은 스토리지 클래스로 전환되지 않습니다. 최종 동기화가 완료되면 자동 클래스가 다시 시작됩니다.
- Standard Storage 클래스의 객체는 다음과 같이 처리됩니다.
  * Standard Storage 클래스 객체는 30일 동안 액세스할 수 없으며 그 후에야 Nearline Storage와 같은 사용률이 낮은 클래스로 전환할 수 있습니다. Standard Storage 클래스의 객체가 재배치 중에 이동하면 액세스된 것처럼 취급됩니다. 따라서 재배치 프로세스에서 액세스 불가 기간이 재설정되며, 이전 전에 객체가 Nearline Storage로 전환될 뻔한 경우에도 재배치가 완료된 후 30일을 더 기다려야 합니다.
- 비표준 스토리지 클래스의 객체는 다음과 같이 처리됩니다.
  * Nearline Storage, Coldline Storage 또는 Archive Storage 스토리지 클래스의 객체를 재배치하는 것은 액세스로 간주되지 않습니다. 따라서 이러한 객체의 액세스 불가 기간은 영향을 받지 않습니다.
  * 버킷을 재배치할 때 Nearline Storage, Coldline Storage 또는 Archive Storage와 같은 비표준 스토리지 클래스가 있는 버킷의 객체에 자주 액세스하면 버킷이 사용률이 높은 스토리지 클래스로 자동 전환되지 않습니다. 예를 들어 객체에 자주 액세스하더라도 버킷이 Archive Storage에서 Coldline Storage로 또는 Coldline Storage에서 Standard Storage로 자동으로 전환되지 않습니다. 이 동작은 이전 중에 자동 스토리지 클래스 전환을 방지합니다.
  * 객체가 Nearline Storage에서 Coldline Storage로 이동하는 등 사용률이 낮은 스토리지 클래스로 예약된 경우 재배치 프로세스는 일정에 영향을 미치지 않습니다. 재배치가 완료되면 전환이 계획대로 진행됩니다.
객체 크기 제한: 재배치 객체 크기에는 2TB 제한이 적용됩니다.

멀티파트 업로드

멀티파트 업로드는 상태(완료, 진행 중, 재배치 중에 시작됨)와 관계없이 쓰기 다운타임이 있는 버킷 재배치에 지원되지 않습니다. 이전하려는 버킷에서 멀티파트 업로드를 완료한 경우 멀티파트 메서드를 사용하지 않고 객체를 다시 업로드하고 멀티파트 업로드를 삭제해야 합니다. 그렇지 않으면 이전이 실패합니다. 쓰기 다운타임이 있는 버킷 재배치 중에 멀티파트 업로드를 사용하여 객체를 업로드하면 FAILED_PRECONDITION 오류가 발생합니다.

지원되지 않는 기능

다음 기능을 사용하는 버킷은 재배치할 수 없습니다.

고객 관리 암호화 키(CMEK) 또는 고객 제공 암호화 키(CSEK)
잠긴 보관 정책
임시 보존이 적용된 객체
계층적 네임스페이스가 사용 설정된 버킷
태그. 재배치 중에 태그를 추가하면 재배치 프로세스가 실패하므로 권장하지 않습니다.
Anywhere Cache. 버킷 재배치 프로세스 중에 Anywhere Cache를 사용 설정할 수 있지만 최종 동기화 단계가 완료되지 않습니다.
Appspot 버킷. App Engine에서 만든 기본 버킷을 해결하기 위한 방법으로 Container Registry를 Artifact Registry로 마이그레이션하는 것이 좋습니다.
Firebase 버킷. Firebase와 연결된 버킷은 재배치할 수 없습니다.

운영 제한사항

쓰기 다운타임이 있는 버킷 재배치에는 다음과 같은 작업 제한사항이 적용됩니다.

프로젝트 제한사항: 프로젝트 간에 버킷을 재배치할 수 없습니다.
재개 가능한 업로드: 진행 중인 재개 가능한 업로드는 데이터 손실을 방지하기 위해 최종 동기화 단계 전에 완료해야 합니다.
메타데이터 업데이트: 재배치 중에 버킷의 메타데이터를 업데이트할 수 없습니다.
요청 비율 증가: 재배치된 버킷에는 새로 만든 버킷과 동일한 요청 비율 증가 가이드라인이 적용됩니다.

쓰기 다운타임이 없는 재배치 제한사항

쓰기 다운타임 없이 버킷을 재배치하는 방법에는 다음과 같은 제한사항이 있습니다.

보관 정책: 모든 보관 정책은 재배치하기 전에 잠금 해제해야 합니다.
Firebase 및 Appspot 버킷: Firebase 또는 Appspot과 연결된 버킷에는 재배치가 지원되지 않습니다.
진행률 업데이트: 재배치 진행률 업데이트는 선형적이지 않을 수 있습니다.
멀티파트 업로드: 버킷 재배치 중에는 완료된 멀티파트 업로드만 지원됩니다. 진행 중인 멀티파트 업로드는 버킷 재배치 중에 객체에 대해 지원되지 않으며 버킷 재배치 전에 완료하거나 취소해야 합니다. 멀티파트 메서드를 사용하지 않고 객체를 다시 업로드해야 합니다. 버킷 재배치 중에 멀티파트 업로드를 사용하여 객체를 업로드하면 FAILED_PRECONDITION 오류가 발생합니다.

지원되지 않는 위치

다음 위치에서는 소스 및 대상 버킷의 버킷 재배치가 지원되지 않습니다.

위치 유형	지원되지 않는 위치
리전	ME-CENTRAL1ME-WEST1

가격 책정

버킷 재배치와 관련된 가격 책정에 관한 자세한 내용은 Cloud Storage 가격 책정을 참고하세요.

다음 단계

버킷 재배치를 계획하는 방법 알아보기
버킷을 재배치하는 방법 알아보기