Cloud Storage 버킷 간의 전송

Storage Transfer Service를 사용하면 동일한 Google Cloud 프로젝트 내에 있는 Cloud Storage 버킷 간에 또는 서로 다른 프로젝트 간에 대량의 데이터를 전송할 수 있습니다.

버킷 마이그레이션은 여러 시나리오에서 유용합니다. 이를 사용하여 개별 프로젝트에서 데이터를 통합하거나, 데이터를 백업 위치로 이동하거나, 데이터 위치를 변경할 수 있습니다.

Storage Transfer Service를 사용하는 경우

Google Cloud는 Cloud Storage 버킷 간 데이터 전송을 위해 여러 옵션을 제공합니다. 다음 가이드라인이 권장됩니다.

  • 1TB 미만 전송: gsutil 또는 gcloud를 사용합니다. 자세한 내용은 버킷 이동 및 이름 바꾸기를 참조하세요.

  • 1TB 초과 전송: Storage Transfer Service를 사용합니다. Storage Transfer Service는 보안, 안정성, 성능을 즉시 제공하는 관리형 전송 옵션입니다. 스크립트를 최적화 및 유지보수하고 재시도를 처리할 필요가 없습니다.

이 가이드에서는 Storage Transfer Service를 사용하여 Cloud Storage 버킷 간에 데이터를 전송할 때의 권장사항에 대해 설명합니다.

전송 전략 정의

전송 전략은 상황의 복잡성에 따라 달라집니다. 계획에 다음 고려사항을 포함해야 합니다.

버킷 이름 선택

데이터를 다른 위치의 스토리지 버킷으로 이동하려면 다음 방법 중 하나를 선택합니다.

  • 새 버킷 이름. 애플리케이션이 다른 이름의 스토리지 버킷을 가리키도록 업데이트합니다.
  • 버킷 이름 유지. 현재 이름을 유지하려면 스토리지 버킷을 교체합니다. 즉, 애플리케이션을 업데이트할 필요가 없습니다.

두 방법 모두 다운타임을 계획하고 사용자에게 다운타임이 예정되어 있다는 적절한 알림을 제공해야 합니다. 어떤 선택이 가장 적합한지 이해하려면 다음 설명을 검토합니다.

새 버킷 이름

새로운 버킷 이름으로 현재 버킷을 사용하는 모든 코드와 서비스를 업데이트해야 합니다. 이를 수행하는 방법은 애플리케이션이 빌드 및 배포되는 방법에 따라 달라집니다.

일부 설정에서 이 방법을 사용하면 다운타임이 적지만 원활한 전환을 위해 더 많은 작업이 필요할 수 있습니다. 여기에는 다음 단계가 포함됩니다.

  1. 새 스토리지 버킷에 데이터를 복사합니다.
  2. 다운타임을 시작합니다.
  3. 새 버킷을 가리키도록 애플리케이션을 업데이트합니다.
  4. 모든 것이 예상대로 작동하고 모든 관련 시스템과 계정에 버킷에 대한 액세스 권한이 있는지 확인합니다.
  5. 원래 버킷을 삭제합니다.
  6. 다운타임을 종료합니다.

버킷 이름 유지

새 버킷 이름을 가리키도록 코드를 변경하지 않으려면 이 방법을 사용합니다. 여기에는 다음 단계가 포함됩니다.

  1. 임시 스토리지 버킷에 데이터를 복사합니다.
  2. 다운타임을 시작합니다.
  3. 원래 버킷을 삭제합니다.
  4. 원래 버킷과 동일한 이름으로 새 버킷을 만듭니다.
  5. 임시 버킷에서 새 버킷으로 데이터를 복사합니다.
  6. 임시 버킷을 삭제합니다.
  7. 모든 것이 예상대로 작동하고 모든 관련 시스템과 계정에 버킷에 대한 액세스 권한이 있는지 확인합니다.
  8. 다운타임을 종료합니다.

다운타임 최소화

Storage Transfer Service는 전송 중 소스 또는 대상 버킷에서 읽기 또는 쓰기를 잠그지 않습니다.

버킷에서 읽기/쓰기를 수동으로 잠그도록 선택한 경우 시드 및 동기화의 두 단계로 데이터를 전송하여 다운타임을 최소화할 수 있습니다.

  1. 시드 전송: 소스에서 읽기/쓰기를 잠그지 않고 대량 전송을 수행합니다.

  2. 동기화 전송: 첫 번째 실행이 완료된 후 소스 버킷에서 읽기/쓰기를 잠그고 다른 전송을 수행합니다. Storage Transfer Service 전송은 기본적으로 증분적으로 수행되므로, 이러한 두 번째 전송에서는 시드 전송 중 변경된 데이터만 전송됩니다.

전송 속도 최적화

전송 작업에 걸리는 시간을 예측할 때는 가능한 병목 현상을 고려해야 합니다. 예를 들어 소스에 수십억 개의 작은 파일이 포함된 경우 전송 속도는 QPS의 영향을 받을 것입니다. 객체 크기가 크면 대역폭이 병목 현상을 일으킬 수 있습니다.

대역폭 제한은 리전 수준에서 설정되며 모든 프로젝트 간에 공평하게 할당됩니다. 사용 가능한 대역폭이 충분하면 Storage Transfer Service가 전송 작업별로 초당 약 1,000개의 태스크를 완료할 수 있습니다. 이 경우 작업을 여러 개의 작은 전송 작업으로 분할해서 전송을 가속화할 수 있습니다. 예를 들어 특정 파일 전송을 위해 포함 및 제외 프리픽스를 사용할 수 있습니다.

위치, 스토리지 클래스, 암호화 키가 동일한 경우에는 Storage Transfer Service가 해당 바이트의 새 복사본을 만들지 않고, 소스 Blob을 가리키는 새 메타데이터 항목을 만듭니다. 따라서 대규모 코퍼스의 동일 위치 및 클래스 사본이 매우 빠르게 작성되고 QPS에만 영향을 받습니다.

또한 삭제는 메타데이터 전용 작업입니다. 이러한 전송에서 이를 여러 개의 작은 작업으로 분할하여 전송을 병렬화하면 속도가 늘어날 수 있습니다.

메타데이터 보존

다음 객체 메타데이터는 Storage Transfer Service를 사용하여 Cloud Storage 버킷 간에 데이터를 전송할 때 보존됩니다.

  • 사용자 생성 커스텀 메타데이터.
  • 캐시 관리, 콘텐츠 처리, 콘텐츠 유형, 커스텀 시간과 같은 Cloud Storage 고정 키 메타데이터 필드
  • 객체 크기
  • 세대 번호는 x-goog-reserved-source-generation 키가 있는 커스텀 메타데이터 필드로 보존되며, 나중에 수정하거나 삭제할 수 있습니다.

API를 사용하여 전송할 때 선택적으로 다음 메타데이터 필드를 보존할 수 있습니다.

  • ACL(acl)
  • 스토리지 클래스(storageClass)
  • CMEK(kmsKey)
  • 임시 보존(temporaryHold)
  • 객체 생성 시간(customTime)

자세한 내용은 TransferSpec API 참조를 확인하세요.

다음 메타데이터 필드는 보존되지 않습니다.

  • 최종 업데이트 시간(updated)
  • etag
  • componentCount

보존되면 객체 생성 시간이 커스텀 필드 customTime으로 저장됩니다. 객체의 updated 시간은 전송 시 재설정되므로 스토리지 클래스에 소요된 객체 시간도 재설정됩니다. 즉, 이전 삭제 요금 청구를 방지하려면 전송 후 Coldline Storage의 객체가 대상에서 90일 동안 다시 존재해야 합니다.

customTime을 사용하여 createTime 기반 수명 주기 정책을 적용할 수 있습니다. 기존 customTime 값을 덮어씁니다.

보존되는 항목과 보존되지 않는 항목에 대한 자세한 내용은 메타데이터 보존을 참조하세요.

버전 관리된 객체 처리

최신 버전은 물론 스토리지 객체의 모든 버전을 전송하려면 Storage Transfer Service의 매니페스트 기능과 함께 gcloud CLI 또는 REST API를 사용하여 데이터를 전송해야 합니다.

모든 객체 버전을 전송하려면 다음 안내를 따르세요.

  1. 버킷 객체를 나열하고 이를 JSON 파일에 복사합니다.

    gcloud storage ls --all-versions --recursive --json [SOURCE_BUCKET] > object-listing.json

    이 명령어는 일반적으로 초당 1,000개의 객체를 나열합니다.

  2. JSON 파일을 2개의 CSV 파일로 분할합니다. 한 파일은 최신이 아닌 버전을 포함하고, 다른 파일은 사용 중인 버전을 포함합니다.

    jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted") | not)) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > live-object-manifest.csv
jq -r '.[] | select( .type=="cloud_object" and (.metadata | has("timeDeleted"))) | [.metadata.name, .metadata.generation] | @csv' object-listing.json > non-current-object-manifest.csv

  3. 대상 버킷에서 객체 버전 관리를 사용 설정합니다.

  4. non-current-object-manifest.csv 매니페스트 파일을 transferManifest 필드 값으로 전달하여 최신이 아닌 버전을 먼저 전송합니다.

  5. 그런 후 live-object-manifest.csv를 매니페스트 파일로 지정해서 동일한 방법으로 사용 중인 버전을 전송합니다.

전송 옵션 구성

전송을 설정할 때 사용할 수 있는 몇 가지 옵션은 다음과 같습니다.

  • 로깅: Cloud Logging은 전송 상태 확인 및 추가적인 데이터 무결성 확인을 수행할 수 있도록 개별 객체에 대한 세부 로그를 제공합니다.

  • 필터링: 프리픽스를 포함하거나 제외하여 Storage Transfer Service가 작동하는 객체를 제한할 수 있습니다. 이 옵션을 사용하면 병렬 실행이 가능하도록 전송을 여러 개의 전송 작업으로 분할할 수 있습니다. 자세한 내용은 전송 속도 최적화를 참조하세요.

  • 전송 옵션: 대상 버킷에서 기존 항목을 덮어쓰거나, 대상에서 전송 집합에 존재하지 않는 객체를 삭제하거나, 소스에서 전송된 객체를 삭제하도록 전송을 구성할 수 있습니다.

데이터 전송

전송 전략을 정의한 후에는 전송 자체를 수행할 수 있습니다.

새 버킷 생성

전송을 시작하기 전에 스토리지 버킷을 만듭니다. 적절한 버킷 위치 선택을 위해서는 위치 고려사항을 참조하세요.

새 버킷을 만들 때는 일부 버킷 메타데이터를 복사해야 할 수 있습니다. 새 버킷에 동일한 설정을 적용할 수 있도록 소스 버킷의 메타데이터를 표시하는 방법은 버킷 메타데이터 가져오기를 참조하세요.

새 버킷에 객체 복사

Google Cloud 콘솔, gcloud CLI, REST API, 클라이언트 라이브러리를 사용하여 소스 버킷의 객체를 새 버킷으로 복사할 수 있습니다. 어떤 방법을 선택할지는 전송 전략에 따라 다릅니다.

다음 안내는 한 버킷에서 다른 버킷으로 객체를 전송하는 기본적인 사용 사례를 위한 것이므로, 필요에 맞게 수정해야 합니다.

전송 작업 이름에 개인 식별 정보(PII) 또는 보안 데이터와 같은 민감한 정보를 포함하지 마세요. 리소스 이름은 다른 Google Cloud 리소스의 이름으로 전파될 수 있으며 프로젝트 외부의 Google 내부 시스템에 노출될 수 있습니다.

Google Cloud 콘솔

Google Cloud 콘솔 내에서 Cloud Storage Transfer Service를 사용합니다.

  1. Google Cloud 콘솔에서 전송 페이지를 엽니다.

    전송 페이지 열기

  2. 전송 작업 만들기를 클릭합니다.

  3. 단계별 안내를 따르면서 각 단계를 마칠 때마다 다음 단계를 클릭합니다.

    • 시작하기: Google Cloud Storage를 소스 유형과 대상 유형으로 모두 사용합니다.

    • 소스 선택: 원하는 버킷 이름을 직접 입력하거나 둘러보기를 클릭하여 원하는 버킷을 찾아서 선택합니다.

    • 대상 선택: 원하는 버킷 이름을 직접 입력하거나 찾아보기를 클릭하여 원하는 버킷을 찾아서 선택합니다.

    • 설정 선택: 전송된 후 소스에서 파일 삭제 옵션을 선택합니다.

    • 예약 옵션: 이 섹션은 무시할 수 있습니다.

  4. 단계별 안내를 완료한 후 만들기를 클릭합니다.

    그러면 이전 버킷의 객체가 새 버킷으로 복사되는 프로세스가 시작됩니다. 이 과정은 다소 시간이 걸릴 수 있지만 만들기를 클릭한 후에는 Google Cloud Console에서 나갈 수 있습니다.

    전송 진행률을 보려면 다음 안내를 따르세요.

    Google Cloud 콘솔에서 전송 페이지를 엽니다.

    전송 페이지 열기

    Google Cloud 콘솔에서 실패한 Storage Transfer Service 작업에 대한 자세한 오류 정보를 가져오는 방법은 문제 해결을 참조하세요.

  5. 설정 중 전송 완료 후 소스 객체 삭제 체크박스를 선택한 경우에는 전송이 완료된 후 이전 버킷에서 객체를 삭제하기 위해 어떤 작업도 수행할 필요가 없습니다. 하지만 개별적으로 수행해야 하는 이전 버킷 삭제를 수행해야 할 수도 있습니다.

gcloud CLI

gcloud CLI 설치

아직 gcloud 명령줄 도구를 설치를 설치하지 않았다면 설치합니다.

그런 후 gcloud init를 호출해서 도구를 초기화하고 프로젝트 ID와 사용자 계정을 지정합니다. 자세한 내용은 Cloud SDK 초기화를 참조하세요.

gcloud init

대상 폴더에 서비스 계정 추가

전송을 만들려면 먼저 대상 버킷에 Storage Transfer Service 서비스 계정을 추가해야 합니다. 이렇게 하려면 gsutil iam ch를 사용합니다.

gsutil iam ch serviceAccount:project-12345678@storage-transfer-service.iam.gserviceaccount.com:roles/storage.admin gs://bucket_name

Google Cloud 콘솔 또는 API 사용에 대한 안내는 Cloud Storage 문서에서 IAM 권한 사용을 참조하세요.

전송 작업 만들기

새 전송 작업을 만들려면 gcloud transfer jobs create 명령어를 사용합니다. 일정 또는 --do-not-run이 지정되지 않은 한, 새 작업을 만들면 지정된 전송이 시작됩니다.

gcloud transfer jobs create SOURCE DESTINATION

각 항목의 의미는 다음과 같습니다.

  • SOURCE는 gs://BUCKET_NAME 형식의 이 전송에 대한 데이터 소스입니다.

  • DESTINATION은 gs://BUCKET_NAME 형식의 새 버킷입니다.

추가로 선택할 수 있는 옵션은 다음과 같습니다.

  • 작업 정보: --name 및 --description을 지정할 수 있습니다.

  • 일정: --schedule-starts, --schedule-repeats-every, --schedule-repeats-until, --do-not-run을 지정합니다.

  • 객체 조건: 조건을 사용해서 전송되는 객체를 결정합니다. 여기에는 --include-prefixes 및 --exclude-prefixes와 --include-modified-[before | after]-[absolute | relative]의 시간 기준 조건이 포함됩니다.

  • 전송 옵션: 대상 파일(--overwrite-when=different 또는 always)을 덮어쓸지 여부와 전송 중 또는 전송 후에 특정 파일을 삭제할지 여부(--delete-from=destination-if-unique 또는 source-after-transfer)를 지정하고, [보존할 메타데이터 값]메타데이터를 지정하며, 필요한 경우 전송된 객체에 스토리지 클래스를 설정할 수 있습니다(--custom-storage-class).

  • 알림: --notification-pubsub-topic, --notification-event-types, --notification-payload-format으로 Pub/Sub 전송 알림을 구성합니다.

모든 옵션을 보려면 gcloud transfer jobs create --help를 실행합니다.

예를 들어 프리픽스가 folder1인 모든 객체를 전송하려면 다음 안내를 따르세요.

gcloud transfer jobs create gs://old-bucket gs://new-bucket \
  --include-prefixes="folder1/"

REST

이 예시에서는 하나의 Cloud Storage 버킷에서 다른 Cloud Storage 버킷으로 파일을 이동하는 방법을 알아봅니다. 예를 들어 데이터를 다른 위치의 버킷으로 이동할 수 있습니다.

transferJobs create를 사용하는 요청:

POST https://storagetransfer.googleapis.com/v1/transferJobs
{
  "description": "YOUR DESCRIPTION",
  "status": "ENABLED",
  "projectId": "PROJECT_ID",
  "schedule": {
      "scheduleStartDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      },
      "startTimeOfDay": {
          "hours": 1,
          "minutes": 1
      },
      "scheduleEndDate": {
          "day": 1,
          "month": 1,
          "year": 2025
      }
  },
  "transferSpec": {
      "gcsDataSource": {
          "bucketName": "GCS_SOURCE_NAME"
      },
      "gcsDataSink": {
          "bucketName": "GCS_SINK_NAME"
      },
      "transferOptions": {
          "deleteObjectsFromSourceAfterTransfer": true
      }
  }
}

응답:

200 OK
{
  "transferJob": [
      {
          "creationTime": "2015-01-01T01:01:00.000000000Z",
          "description": "YOUR DESCRIPTION",
          "name": "transferJobs/JOB_ID",
          "status": "ENABLED",
          "lastModificationTime": "2015-01-01T01:01:00.000000000Z",
          "projectId": "PROJECT_ID",
          "schedule": {
              "scheduleStartDate": {
                  "day": 1,
                  "month": 1,
                  "year": 2015
              },
              "startTimeOfDay": {
                  "hours": 1,
                  "minutes": 1
              }
          },
          "transferSpec": {
              "gcsDataSource": {
                  "bucketName": "GCS_SOURCE_NAME",
              },
              "gcsDataSink": {
                  "bucketName": "GCS_NEARLINE_SINK_NAME"
              },
              "objectConditions": {
                  "minTimeElapsedSinceLastModification": "2592000.000s"
              },
              "transferOptions": {
                  "deleteObjectsFromSourceAfterTransfer": true
              }
          }
      }
  ]
}

클라이언트 라이브러리

이 예시에서는 하나의 Cloud Storage 버킷에서 다른 Cloud Storage 버킷으로 파일을 이동하는 방법을 알아봅니다. 예를 들어 데이터를 다른 위치의 버킷으로 복제할 수 있습니다.

Storage Transfer Service 클라이언트 라이브러리에 대한 자세한 내용은 Storage Transfer Service 클라이언트 라이브러리 시작하기를 참조하세요.

자바

이전 샘플을 찾고 계신가요? Storage Transfer Service 이전 가이드를 참조하세요. 

import com.google.protobuf.Duration;
import com.google.storagetransfer.v1.proto.StorageTransferServiceClient;
import com.google.storagetransfer.v1.proto.TransferProto.CreateTransferJobRequest;
import com.google.storagetransfer.v1.proto.TransferTypes.GcsData;
import com.google.storagetransfer.v1.proto.TransferTypes.ObjectConditions;
import com.google.storagetransfer.v1.proto.TransferTypes.Schedule;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferJob;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferJob.Status;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferOptions;
import com.google.storagetransfer.v1.proto.TransferTypes.TransferSpec;
import com.google.type.Date;
import com.google.type.TimeOfDay;
import java.io.IOException;
import java.util.Calendar;

public class TransferToNearline {
  /**
   * Creates a one-off transfer job that transfers objects in a standard GCS bucket that are more
   * than 30 days old to a Nearline GCS bucket.
   */
  public static void transferToNearline(
      String projectId,
      String jobDescription,
      String gcsSourceBucket,
      String gcsNearlineSinkBucket,
      long startDateTime)
      throws IOException {

    // Your Google Cloud Project ID
    // String projectId = "your-project-id";

    // A short description of this job
    // String jobDescription = "Sample transfer job of old objects to a Nearline GCS bucket.";

    // The name of the source GCS bucket to transfer data from
    // String gcsSourceBucket = "your-gcs-source-bucket";

    // The name of the Nearline GCS bucket to transfer old objects to
    // String gcsSinkBucket = "your-nearline-gcs-bucket";

    // What day and time in UTC to start the transfer, expressed as an epoch date timestamp.
    // If this is in the past relative to when the job is created, it will run the next day.
    // long startDateTime =
    //     new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse("2000-01-01 00:00:00").getTime();

    // Parse epoch timestamp into the model classes
    Calendar startCalendar = Calendar.getInstance();
    startCalendar.setTimeInMillis(startDateTime);
    // Note that this is a Date from the model class package, not a java.util.Date
    Date date =
        Date.newBuilder()
            .setYear(startCalendar.get(Calendar.YEAR))
            .setMonth(startCalendar.get(Calendar.MONTH) + 1)
            .setDay(startCalendar.get(Calendar.DAY_OF_MONTH))
            .build();
    TimeOfDay time =
        TimeOfDay.newBuilder()
            .setHours(startCalendar.get(Calendar.HOUR_OF_DAY))
            .setMinutes(startCalendar.get(Calendar.MINUTE))
            .setSeconds(startCalendar.get(Calendar.SECOND))
            .build();

    TransferJob transferJob =
        TransferJob.newBuilder()
            .setDescription(jobDescription)
            .setProjectId(projectId)
            .setTransferSpec(
                TransferSpec.newBuilder()
                    .setGcsDataSource(GcsData.newBuilder().setBucketName(gcsSourceBucket))
                    .setGcsDataSink(GcsData.newBuilder().setBucketName(gcsNearlineSinkBucket))
                    .setObjectConditions(
                        ObjectConditions.newBuilder()
                            .setMinTimeElapsedSinceLastModification(
                                Duration.newBuilder().setSeconds(2592000 /* 30 days */)))
                    .setTransferOptions(
                        TransferOptions.newBuilder().setDeleteObjectsFromSourceAfterTransfer(true)))
            .setSchedule(Schedule.newBuilder().setScheduleStartDate(date).setStartTimeOfDay(time))
            .setStatus(Status.ENABLED)
            .build();

    // Create a Transfer Service client
    StorageTransferServiceClient storageTransfer = StorageTransferServiceClient.create();

    // Create the transfer job
    TransferJob response =
        storageTransfer.createTransferJob(
            CreateTransferJobRequest.newBuilder().setTransferJob(transferJob).build());

    System.out.println("Created transfer job from standard bucket to Nearline bucket:");
    System.out.println(response.toString());
  }
}

Python

이전 샘플을 찾고 계신가요? Storage Transfer Service 이전 가이드를 참조하세요. 

from datetime import datetime

from google.cloud import storage_transfer
from google.protobuf.duration_pb2 import Duration

def create_daily_nearline_30_day_migration(
    project_id: str,
    description: str,
    source_bucket: str,
    sink_bucket: str,
    start_date: datetime,
):
    """Create a daily migration from a GCS bucket to a Nearline GCS bucket
    for objects untouched for 30 days."""

    client = storage_transfer.StorageTransferServiceClient()

    # The ID of the Google Cloud Platform Project that owns the job
    # project_id = 'my-project-id'

    # A useful description for your transfer job
    # description = 'My transfer job'

    # Google Cloud Storage source bucket name
    # source_bucket = 'my-gcs-source-bucket'

    # Google Cloud Storage destination bucket name
    # sink_bucket = 'my-gcs-destination-bucket'

    transfer_job_request = storage_transfer.CreateTransferJobRequest(
        {
            "transfer_job": {
                "project_id": project_id,
                "description": description,
                "status": storage_transfer.TransferJob.Status.ENABLED,
                "schedule": {
                    "schedule_start_date": {
                        "day": start_date.day,
                        "month": start_date.month,
                        "year": start_date.year,
                    }
                },
                "transfer_spec": {
                    "gcs_data_source": {
                        "bucket_name": source_bucket,
                    },
                    "gcs_data_sink": {
                        "bucket_name": sink_bucket,
                    },
                    "object_conditions": {
                        "min_time_elapsed_since_last_modification": Duration(
                            seconds=2592000  # 30 days
                        )
                    },
                    "transfer_options": {
                        "delete_objects_from_source_after_transfer": True
                    },
                },
            }
        }
    )

    result = client.create_transfer_job(transfer_job_request)
    print(f"Created transferJob: {result.name}")

복사된 객체 확인

전송이 완료되면 추가 데이터 무결성 검사를 수행하는 것이 좋습니다.

  • 체크섬 및 크기와 같은 객체의 메타데이터를 확인해서 객체가 올바르게 복사되었는지 확인합니다.

  • 올바른 객체 버전이 복사되었는지 확인합니다. Storage Transfer Service는 객체가 사본인지 확인할 수 있는 즉시 사용 가능한 옵션을 제공합니다. 로깅을 사용 설정한 경우 로그를 보고 해당 메타데이터 필드를 포함한 모든 객체가 성공적으로 복사되었는지 확인할 수 있습니다.

대상 버킷 사용 시작

마이그레이션이 완료되었고 확인된 후에는 대상 버킷 이름을 사용하도록 기존 애플리케이션 또는 워크로드를 업데이트합니다. Cloud 감사 로그에서 데이터 액세스 로그를 확인하여 객체 수정 및 읽기 작업이 올바르게 수행되는지 확인합니다.

원래 버킷 삭제

모든 것이 올바르게 작동하면 원래 버킷을 삭제합니다.

Storage Transfer Service는 작업 구성에서 deleteObjectsFromSourceAfterTransfer: true를 지정하거나 Google Cloud 콘솔에서 옵션을 선택하여 전송된 후 객체를 삭제하는 옵션을 제공합니다.

객체 삭제 예약

나중에 객체를 삭제하도록 예약하려면 예약된 전송 작업 및 deleteObjectsUniqueInSink = true 옵션을 조합해서 사용합니다.

전송 작업은 객체가 포함된 버킷에 빈 버킷을 전송하도록 설정해야 합니다. 그러면 Storage Transfer Service에 객체가 나열되고 삭제가 시작됩니다. 삭제는 메타데이터 전용 작업이므로, 전송 작업은 QPS에만 영향을 받습니다. 프로세스 속도를 높이기 위해서는 고유한 프리픽스 집합으로 작동하는 여러 작업으로 전송을 분할합니다.

또는 Google Cloud에서는 관리형 크론 작업 스케줄러가 제공됩니다. 자세한 내용은 Cloud Scheduler를 사용하여 Google Cloud STS 전송 작업 예약을 참조하세요.