개체 복제

복제를 사용하면 소스 버킷에서 같은 계정의 대상 버킷으로 개체를 자동으로 비동기식으로 복사하는 규칙을 정의할 수 있습니다. 또한 한 버킷에서 다른 계정의 다른 버킷으로 개체를 복사할 수도 있습니다.

복제의 개념

복제는 새로 만든 개체와 개체 업데이트를 소스 버킷에서 대상 버킷으로 복사합니다.

  • 새 개체 또는 기존 개체의 새 버전(복제 규칙이 버킷에 추가된 후에 생성된)만 대상 버킷에 복사됩니다. 기존 개체를 복사하여 복제된 새 버전을 만들어 복제할 수 있습니다.
  • 소스 개체의 메타데이터가 복제된 개체에 적용됩니다.
  • 두 버킷 간의 양방향 복제를 사용하려면 두 버킷 모두에서 규칙이 활성화되어 있어야 합니다.
  • 필터(접두사 및/또는 태그로 구성)를 사용하여 개체의 하위 집합에만 적용되도록 복제 규칙의 범위를 지정할 수 있습니다. 단일 정책에 여러 규칙을 정의할 수 있으며 이러한 규칙은 서로 다른 대상을 지정할 수 있습니다. 이러한 방식으로 동일한 버킷에 있는 여러 개체를 다른 대상에 복제할 수 있습니다.

왜 복제를 사용하나요?

  • 데이터 사본을 다른 지리적 위치의 버킷에 보관하세요.
  • 허용된 위치에만 복제본을 저장하는 복제 규칙을 정의하여 데이터 주권에 대한 규정 준수 규정을 충족하세요.
  • 복제는 마지막 수정 시간, 버전 ID 등과 같은 개체 메타데이터를 유지하므로 프로덕션 데이터와 테스트 데이터를 동기화 상태로 유지합니다.
  • 대상 버킷에 대해 다른 스토리지 클래스 및/또는 수명 주기 규칙을 정의하여 소스와 독립적으로 복제된 개체에 대한 스토리지 클래스 및 수명 주기 정책을 관리합니다. 마찬가지로 별도의 서비스 인스턴스 또는 IBM Cloud 계정의 버킷에 복제본을 저장하고 복제본에 대한 액세스를 독립적으로 제어할 수도 있습니다.

복제 시작하기

시작하기 위해 충족해야 하는 몇 가지 전제 조건은 다음과 같습니다:

  • 소스 버킷에서 Writer 또는 Manager 플랫폼 역할을 설정하거나 적절한 복제 작업(예: cloud-object-storage.bucket.put_replication)이 할당된 사용자 지정 역할을 설정합니다.
  • 대상 버킷에 액세스할 필요는 없지만 소스 버킷이 대상 버킷에 쓸 수 있도록 허용하는 새 IAM 정책을 만들 수 있는 충분한 플랫폼 역할이 있어야 합니다.
  • 대상 버킷에는 레거시 버킷 방화벽이 사용 설정되어 있지 않아야 하지만 컨텍스트 기반 제한을 사용할 수 있습니다.
  • SSE-C를 사용하여 암호화된 개체는 복제할 수 없지만, Key Protect 같은 관리형 암호화(SSE-KMS )는 복제와 완벽하게 호환됩니다.
  • 보관된 상태의 개체는 복제할 수 없습니다.
  • 소스 버킷과 대상 버킷이 서로 다른 IBM 계정에 있는 경우, 각 계정에서 버킷을 만들어야 합니다.
  • 소스 버킷과 대상 버킷 모두에서 버전 관리를 사용 설정합니다.

버전 관리가 복제를 위한 요구 사항이므로 불변 Object Storage 정책 로 구성된 버킷의 오브젝트는 복제할 수 없습니다.

하나의 IBM 계정 사용

동일한 IBM 계정의 버킷 간에 개체를 복제하려면 다음과 같이 하세요:

  1. 선택한 소스 버킷으로 이동한 후 구성 탭을 클릭합니다.
  2. 버킷 복제를 찾아서 복제 설정 버튼을 클릭합니다.
  3. 복제 소스를 선택하고 ‘다음’을 클릭합니다.
  4. 드롭다운 메뉴에서 인스턴스와 버킷을 선택합니다. 또는 라디오 버튼을 아니요로 전환하고 대상 버킷의 CRN에 붙여넣습니다.
  5. 권한 확인 버튼을 클릭합니다.

이제 소스 버킷 Writer 에 대상 버킷에 대한 권한을 부여해야 합니다. 이를 수행하는 방법에는 여러 가지가 있지만 가장 쉬운 방법은 IBM Cloud Shell 및 IBM Cloud CLI를 사용하는 것입니다.

  1. IBM Cloud Shell 새 창 또는 탭에서 열기를 클릭합니다.
  2. 개체 스토리지 콘솔에 표시된 IBM Cloud CLI 명령을 복사하여 새 셸에 붙여넣습니다.
  3. 버킷 구성 창 또는 탭으로 돌아가서 권한 확인 버튼을 다시 클릭합니다.

이제 복제 규칙을 만들겠습니다.

  1. 규칙 상태 라디오 버튼이 사용으로 설정되어 있는지 확인합니다.
  2. 규칙의 이름과 우선순위, 그리고 복제 규칙의 적용을 받는 개체를 제한할 접두사 또는 태그 필터를 지정합니다.
  3. 완료를 클릭하십시오.

다른 IBM 계정 사용

서로 다른 IBM 계정의 버킷 간에 개체를 복제하려면 다음과 같이 하세요:

  1. 대상 IBM 계정에 IAM 정책을 설정합니다. IAM 정책 만들기에 대한 자세한 내용은 IAM 정책이란 무엇이며 누가 정책을 할당할 수 있는지 참조하세요.
  2. 버킷 구성 페이지에서 CRN 형식의 계정 ID와 서비스 인스턴스 ID를 찾습니다.
  3. 대상 계정의 IBM Cloud UI에서 관리>접속**(IAM)을** 클릭합니다.
  4. 왼쪽 패널에서 인증을 클릭합니다.
  5. '생성'을 클릭하여 새로운 IAM 정책을 생성합니다.
  6. 서비스 권한 부여 페이지 구성을 부여합니다. 새 IAM 정책을 만든 후 이 페이지로 이동하게 됩니다.
  7. 다른 계정을 선택하고 소스 계정의 계정 ID를 입력합니다.
  8. 서비스 액세스 권한을 Cloud Object Storage.
  9. 액세스 범위에서 특정 리소스를 선택합니다.
  10. 소스 서비스 인스턴스를 선택하고 소스 버킷의 서비스 인스턴스 ID를 입력합니다.
  11. Target에서 소스 버킷 액세스를 위해 Cloud Object Storage 을 선택하여 소스 버킷 액세스를 선택합니다.
  12. 대상 범위에서 특정 리소스> 서비스** 인스턴스를 선택합니다.
  13. 드롭다운 메뉴에서 대상 계정의 서비스 인스턴스 ID를 선택합니다.
  14. 필요에 따라 객체 작성자 또는 작성자 역할을 선택합니다.

개체 작성자 역할은 복제를 활성화하는 데 충분합니다.

용어

소스 버킷: 복제 정책이 구성된 버킷입니다. 복제된 객체의 소스입니다.

대상 버킷: 대상 버킷: 소스 버킷 복제 정책에서 대상으로 정의된 버킷입니다. 복제된 객체의 대상입니다. '목적지' 버킷이라고도 합니다.

복제본: 복제: 소스 버킷에 대한 요청으로 인해 대상 버킷에 생성된 새 개체입니다.

복제란 무엇인가요?

CopyObject, PutObject 또는 CompleteMultipartUpload 를 통해 생성된 새 개체는 소스 버킷에서 대상 버킷으로 리플리케이트됩니다. 복제된 객체는 소스 객체에서 다음 메타데이터 필드를 상속합니다: Etag, Last Modified Time, Version ID, user-attributes, 및 Tags.

복제 정책에 의해 구성된 경우 삭제 마커가 복제됩니다.

버전 태그에 대한 업데이트는 소스 버킷에서 대상 버킷으로 리플리케이트됩니다.

다음은 복제되지 않습니다:

  • 수명 주기 이벤트에 의해 시작된 작업
  • 아카이브에 직접 기록된 개체
  • 아카이브 계층에서 복원된 개체
  • SSE-C를 통해 암호화된 개체
  • 오브젝트 ACL

비즈니스 연속성 및 재해 복구를 위한 복제 활용

복제는 장애 발생 시 서비스 연속성을 제공하는 데 사용할 수 있습니다:

  • 소스 버킷과 대상 버킷이 서로 다른 위치에 있는지 확인하세요.
  • 두 버킷 간에 최신 버전의 개체가 동기화되어 있는지 확인합니다. 다음과 같은 도구를 사용하면 Rclone ( rclone check 명령어)와 같은 도구는 명령줄에서 동기화를 확인하는 데 유용할 수 있습니다.
  • 서비스 중단이 발생하면 애플리케이션의 트래픽을 대상 버킷으로 리디렉션할 수 있습니다.

일관성 및 데이터 무결성

IBM Cloud Object Storage 은 모든 데이터 IO 작업에 대해 강력한 일관성을 제공하지만, 버킷 구성은 결국 일관성을 유지합니다. 버킷에서 처음으로 복제 규칙을 활성화한 후, 구성이 시스템 전체에 전파되고 새 개체가 복제되기 시작하려면 잠시 시간이 걸릴 수 있습니다.

오류 처리

복제 실패는 버킷 설정 오류, 서비스 중단, 대상 버킷에 대한 사용자의 조작 등(이에 국한되지 않음) 여러 가지 이유로 발생할 수 있습니다.

COS에는 복제 오류를 처리할 수 있는 내결함성이 내장되어 있습니다. 오류가 발생하면 COS는 최대 30일 동안 재시도할 수 있습니다. 재시도 빈도는 오류의 유형에 따라 달라질 수 있습니다. 예를 들어, 드물게 발생하는 I/O 오류로 인한 오류는 몇 시간 내에 재시도될 수 있는 반면, 사용자 버킷의 잘못된 구성으로 인한 오류는 하루에 한 번만 재시도될 수 있습니다. 오류가 30일 이내에 해결되지 않으면, 시스템에서 더 이상 자동으로 재시도하지 않습니다. 모든 장기 오류는 다음을 통해 나열할 수 있습니다. ListBucketReplicationFailures 를 통해 나열할 수 있습니다.

30일 이상 경과한 “오래된” 오류에 대해 재시도를 원할 경우, PutBucketReplicationFailureReattempt 를 사용하여 재시도를 트리거할 수 있습니다.

고장 원인

ListBucketReplicationFailures API 응답에서는 각 실패 요소마다 SyncFailureCause 가 제공되며, 여기에는 마지막으로 확인된 실패 원인이 명시되어 있습니다. 다음 표에는 가능한 원인이 설명되어 있습니다:

원인 설명
대상 버킷에서 버전 관리 기능이 비활성화되었습니다 대상 버킷에서 버전 관리가 활성화되어 있지 않습니다. 사용자가 복제 설정을 완료한 후 버전 관리를 중지한 것으로 보입니다.
대상 버킷에서 복제 작업이 허용되지 않습니다 COS 서비스는 사용자를 대신하여 대상 버킷을 수정할 권한이 없습니다. IAM에서 소스 버킷 리소스와 대상 버킷 리소스 간에 서비스 간 승인 권한이 여전히 설정되어 있는지 확인하십시오.
원격 버킷을 찾을 수 없습니다 대상 버킷을 찾을 수 없습니다. 사용자가 대상 버킷을 삭제했을 수 있습니다. 대상 버킷이 여전히 존재하는지 확인하십시오.
소스/원격 버킷을 찾을 수 없거나 비활성화되어 있습니다 버킷을 찾을 수 없거나 사용할 수 없는 상태입니다. 버킷이 아직 존재하는지 확인하세요. 그럴 경우 고객 지원팀에 문의해 주세요.
대상 객체를 찾을 수 없습니다 메타데이터 변경(예: 태그/객체 잠금)을 재현하려고 했으나, 대상 객체가 존재하지 않습니다. 변경 사항이 복제되기 전에 사용자가 대상 버킷에서 해당 객체를 삭제했을 가능성이 높습니다.
로컬 객체를 찾을 수 없습니다 복제를 시도하는 동안 소스 개체를 찾을 수 없습니다. 사용자가 해당 소스 객체를 작성하거나 수정한 직후에 삭제했을 가능성이 높습니다.
대상 버킷에서 객체 잠금 기능이 활성화되어 있지 않습니다 개체에 대한 Object Lock 설정을 복제하려고 했으나, 대상 버킷에서 Object Lock이 활성화되어 있지 않았습니다.
암호화 키가 비활성화되었거나 삭제되었습니다 COS가 Key Protect 에서 암호화 키를 가져오려고 시도했으나(소스 버킷에는 SSE-KP/SSE-HPCS가 구성되어 있음), 키가 삭제된 상태였습니다.
KMS 인스턴스 엔드포인트 정보가 누락되었습니다 암호화 키를 읽는 데 필요한 키 관리 서비스(KMS) 엔드포인트를 가져올 수 없습니다. 오류가 계속 발생하면 고객 지원팀에 문의하십시오.
KMS 엔드포인트 정보를 조회할 권한이 부족합니다 소스 버킷 리소스에는 암호화 키를 읽는 데 필요한 키 관리 서비스(KMS) 엔드포인트를 조회할 수 있는 권한이 없습니다. IAM 서비스 간 인증 정책을 확인해 보십시오.
내부 오류 복제를 방해하는 다양한 내부 문제. 고객 지원 문의

IAM 조치

복제와 관련된 새로운 IAM 작업이 있습니다.

IAM 조치 역할
cloud-object-storage.bucket.get_replication 관리자, 작성자, 독자
cloud-object-storage.bucket.put_replication 관리자, 작성자
cloud-object-storage.bucket.delete_replication 관리자, 작성자
cloud-object-storage.bucket.get_replication_failures 관리자, 작성자, 독자
cloud-object-storage.bucket.put_replication_reattempt 관리자, 작성자

Activity Tracker 이벤트

복제는 추가 이벤트를 생성합니다.

이벤트 조치 생성 시간: 설명
cloud-object-storage.bucket-replication.create 소스 버킷 사용자가 PutBucketReplication API 요청을 수행할 때
cloud-object-storage.bucket-replication.read 소스 버킷 사용자가 GetBucketReplication API 요청을 수행할 때
cloud-object-storage.bucket-replication.delete 소스 버킷 사용자가 DeleteBucketReplication API 요청을 수행할 때
cloud-object-storage.bucket-replication-failures.list 소스 버킷 사용자가 ListBucketReplicationFailures API 요청을 수행할 때
cloud-object-storage.bucket-replication-failures.update 소스 버킷 사용자가 PutReplicationFailureReattempt API 요청을 수행할 때
cloud-object-storage.object-replication.sync 소스 버킷 COS가 소스 버킷에서 객체를 복제할 때
cloud-object-storage.object-replication.create 대상 버킷 COS가 대상 버킷에 새로운 복제본 버전을 생성할 때
cloud-object-storage.object-replication.update 대상 버킷 COS가 대상 버킷의 기존 복제본에 대해 메타데이터 업데이트를 복제할 때
cloud-object-storage.object-replication.delete 대상 버킷 COS가 대상 버킷에서 삭제 마커를 복제할 때

cloud-object-storage.bucket-replication.create 이벤트의 경우 다음 필드는 추가 정보를 제공합니다.

필드 설명
requestData.replication.num_sync_remote_buckets 버킷 복제 규칙에 지정된 대상 버킷의 수입니다.
requestData.replication.failed_remote_sync 복제 검사에 실패한 버킷의 CRN입니다.

복제가 활성화되면 오브젝트에 대한 조작이 다음과 같은 추가 정보를 생성할 수 있습니다.

필드 설명
requestData.replication.replication_throttled 조절 메커니즘으로 인해 소스에서 오브젝트 복제가 지연되었는지 여부를 표시합니다.
requestData.replication.destination_bucket_id 대상 버킷의 CRN입니다.
requestData.replication.sync_type
- content 은 객체 데이터 모든 메타데이터가 대상에 기록되었음을 나타냅니다.
- tag 은 객체 태그가 복제되었음을 나타냅니다.
- retention 은 객체 잠금 보존 설정이 복제되었음을 나타냅니다.
- legal_hold 은 객체 잠금 법적 보존 설정이 복제되었음을 나타냅니다.
- delete 은 삭제 마커가 대상에 기록되었음을 나타냅니다.
responseData.replication.source_bucket_id 소스 버킷의 CRN입니다.
responseData.replication.result 가능한 값은 success, failure (서버 오류 표시), user (사용자 오류 표시) 입니다.
responseData.replication.message HTTP 응답 메시지(예: OK).

오브젝트가 소스에 기록될 때부터 대상에 기록될 때까지 오브젝트를 추적할 수 있습니다. 오브젝트 쓰기와 연관된 요청 ID를 검색하면 세 개의 이벤트가 표시됩니다.

  • 원래 PUT.
  • 소스의 동기화 요청입니다.
  • 대상의 PUT 요청입니다.

이 세 개의 누락 중 하나가 실패를 표시합니다.

사용량 및 계정

모든 복제본은 오브젝트 자체이며 다른 데이터와 마찬가지로 사용에 기여 합니다. 복제 프로세스에서 사용되는 대역폭은 청구되지 않지만 복제에 성공하면 청구 가능한 PUT, GETHEAD 요청이 발생합니다.

복제는 IBM Cloud Monitoring 에 사용할 추가 메트릭을 생성합니다:

  • ibm_cos_bucket_replication_sync_requests_issued
  • ibm_cos_bucket_replication_sync_requests_received

상호작용

버전화

복제를 사용하려면 버전화가 필수입니다. 소스 및 대상 버킷 모두에서 버전화를 사용으로 설정 하고 소스 버킷에서 복제를 구성한 후 다음 문제가 발생할 수 있습니다.

  • 소스 버킷에서 버전화를 사용 안함으로 설정하려고 시도하면 Object Storage 가 오류를 리턴합니다. 소스 버킷에서 버전화를 사용 안함으로 설정하기 전에 복제 구성을 제거해야 합니다.
  • 대상 버킷에서 버전화를 사용 안함으로 설정하면 복제가 실패합니다.

오브젝트 잠금

복제 기능이 활성화된 버킷에서는 객체 잠금 기능을 활성화할 수 있습니다. 소스 개체가 Object Lock(보존 및/또는 법적 보존 조치)과 함께 생성되거나, 기존 개체에 대해 Object Lock이 업데이트되는 경우, 해당 내용은 대상에 복제됩니다.

대상 버킷에서 Object Lock이 활성화된 경우에만 Object Lock을 복제할 수 있습니다. 따라서 소스 버킷에서 Object Lock이 활성화된 경우, 대상 버킷에서도 Object Lock을 활성화하는 것이 좋습니다.

아래 표는 소스 버킷과 대상 버킷의 오브젝트 잠금 구성이 서로 다를 때 나타나는 동작을 요약한 것입니다:

소스 객체 잠금 대상 객체 잠금 동작
사용 사용 소스의 모든 객체 잠금 상태가 대상에 복제됩니다.

소스 오브젝트가 Object Lock 없이 생성된 경우, 대상 버킷의 기본 보존 정책이 복제본에 적용될 수 있습니다.

객체 잠금 복제는 ‘ S3 ’의 모든 객체 잠금 제한 사항을 따릅니다. 예를 들어, 사용자가 대상에서 독자적으로 변경을 가한 경우, 컴플라이언스 모드에 있는 복제본의 보존 기간을 단축할 수는 없습니다.
비활성화 활성화 소스 개체에는 개체 잠금이 적용될 수 없으므로, 개체 잠금 상태는 소스에서 대상으로 절대 전파되지 않습니다.
대상 버킷에 기본 보존 기간이 설정되어 있는 경우, 새로 생성되는 복제본에 해당 설정이 적용됩니다.
사용 비활성화 Object Lock을 사용하여 생성된 소스 개체는 복제되지 않습니다. 이러한 실패 사례는 COS에 의해 재시도되며, 대상 버킷에서 객체 잠금이 활성화되면 복제될 수 있습니다. 기존 객체에 대한 객체 잠금 보존/법적 보존 조치 업데이트 역시 대상에서 객체 잠금이 활성화될 때까지 복제될 수 없습니다.

Object Lock을 적용하지 않고 생성된 소스 객체도 복제할 수 있습니다.

Key Protect 암호화

소스 오브젝트는 소스 버킷의 루트 키를 사용하여 암호화 되고 복제본은 대상 버킷의 루트 키를 사용하여 암호화됩니다.

라이프사이클 구성

대상 버킷에서 라이프사이클 정책이 사용으로 설정된 경우 라이프사이클 조치는 복제본이 대상 버킷에서 사용 가능하게 되는 시간이 아니라 소스에 있는 오브젝트의 원래 작성 시간을 기반으로 합니다.

불변 오브젝트 스토리지

버전화가 사용으로 설정된 버킷에서는 보존 정책을 사용할 수 없으며, 버전화는 복제 요구사항이므로 불변 Object Storage 가 사용으로 설정된 버킷에서 또는 버킷으로 오브젝트를 복제할 수 없습니다.

레거시 버킷 방화벽

IP 주소를 기반으로 액세스를 제한하기 위해 레거시 방화벽 을 사용하는 버킷은 복제를 사용할 수 없습니다. 오브젝트를 복제하는 백그라운드 서비스에 고정 IP 주소가 없고 방화벽을 통과할 수 없기 때문입니다.

대신 네트워크 정보를 기반으로 액세스를 제어하기 위해 컨텍스트 기반 제한사항을 사용 하는 것이 좋습니다.

Cloud Functions 및 Code Engine

복제 구성은 현재 Cloud Functions 에 대한 트리거 또는 Code Engine 이벤트를 제공하지 않지만 오브젝트 쓰기 및 삭제는 소스 및 대상 버킷 모두에 대해 Object:WriteObject:Delete 알림을 작성합니다. 이러한 이벤트는 이벤트가 동기화를 트리거했는지 또는 동기화에 의해 트리거되었는지 여부를 표시하는 notifications.replication_type 필드로 어노테이션이 작성됩니다.

기존 오브젝트 복제

복제 규칙은 규칙이 구성되어 버킷에 적용된 후에 작성된 오브젝트에 대해서만 작동할 수 있습니다. 복제해야 하는 버킷에 기존 오브젝트가 있는 경우 복제 프로세스는 오브젝트의 존재를 인식해야 합니다. 이는 PUT copy 조작을 사용하여 오브젝트를 자신에게 복사함으로써 쉽게 수행할 수 있습니다.

이 프로세스는 작성 시간소인을 포함하여 일부 오브젝트 메타데이터를 재설정합니다. 이는 라이프사이클 정책 및 작성 또는 수정 시간소인을 사용하는 기타 서비스 (예: 컨텐츠 전달 네트워크) 에 영향을 줍니다. 오브젝트 메타데이터 재설정으로 인해 발생할 수 있는 중단이 적절하게 처리되는지 확인하십시오.

프로세스에는 다음이 포함됩니다.

  1. 복제 규칙을 따라야 하는 버킷의 모든 오브젝트 목록 작성
  2. 해당 목록을 반복하여 소스가 요청의 대상과 동일한 각 오브젝트에서 PUT copy 조작을 수행합니다.

이 예는 PUT copy 요청으로 작성된 오브젝트의 새 버전만 복제합니다. 오브젝트의 모든 버전을 복제하려면 각 개별 버전도 복사해야 합니다.

다음 예제는 Python으로 작성되었지만 모든 프로그래밍 언어 또는 컨텍스트에서 알고리즘을 적용할 수 있습니다.

import os
import sys
import ibm_boto3
from ibm_botocore.config import Config

# Create client connection
cos = ibm_boto3.client("s3",
                       ibm_api_key_id=os.environ.get('IBMCLOUD_API_KEY'),
                       ibm_service_instance_id=os.environ['SERVICE_INSTANCE_ID'],
                       config=Config(signature_version="oauth"),
                       endpoint_url=os.environ['US_GEO']
                       )

# Define the bucket with existing objects for replication
bucket = os.environ['BUCKET']

def copy_in_place(BUCKET_NAME):
    print("Priming existing objects in " + bucket + " for replication...")

    paginator = cos.get_paginator('list_objects_v2')
    pages = paginator.paginate(Bucket=bucket)

    for page in pages:
        for obj in page['Contents']:
            key = obj['Key']
            print("  * Copying " + key + " in place...")
            try:
                headers = cos.head_object(
                    Bucket=bucket,
                    Key=key
                    )
                md = headers["Metadata"]
                cos.copy_object(
                    CopySource={
                        'Bucket': bucket,
                        'Key': key
                        },
                    Bucket=bucket,
                    Key=key,
                    TaggingDirective='COPY',
                    MetadataDirective='REPLACE',
                    Metadata=md
                    )
                print("    Success!")
            except Exception as e:
                print("    Unable to copy object: {0}".format(e))
    print("Existing objects in " + bucket + " are now subject to replication rules.")

copy_in_place(bucket)

REST API 예제

다음 예제는 사용하기 쉽도록 cURL 을 사용하여 표시됩니다. 환경 변수는 $BUCKET, $TOKEN$REGION 와 같은 사용자 특정 요소를 표시하는 데 사용됩니다. $REGION 에는 모든 네트워크 유형 스펙도 포함되므로 사설 네트워크를 사용하여 us-south 의 버킷에 요청을 전송하려면 변수를 private.us-south 로 설정해야 합니다.

버킷에서 복제 사용

복제 구성은 요청 본문에서 XML로 제공됩니다. 새 요청은 버킷에 있는 기존 복제 규칙을 겹쳐씁니다.

복제 구성은 하나 이상의 규칙을 포함해야 하며 최대 1,000개를 포함할 수 있습니다. 각 규칙은 소스 버킷의 오브젝트를 필터링하여 복제할 오브젝트의 서브세트를 식별합니다. 복제할 오브젝트의 추가 서브세트를 선택하려면 각 서브세트에 대한 규칙을 추가하십시오.

복제 규칙을 적용할 소스 버킷에 있는 오브젝트의 서브세트를 지정하려면 Filter 요소를 Rule 요소의 하위로 추가하십시오. 오브젝트 키 접두부, 하나 이상의 오브젝트 태그 또는 둘 다를 기반으로 오브젝트를 필터링할 수 있습니다. 구성에서 Filter 요소를 추가할 때 DeleteMarkerReplication, StatusPriority 요소도 추가해야 합니다.

선택적 헤더

선택적 헤더
헤더 유형 설명
Content-MD5 문자열 base64 는 페이로드의 128비트 MD5 해시 값을 인코딩했으며, 이는 전송 중에 페이로드가 변조되지 않았는지 확인하기 위한 무결성 검사 용도로 사용됩니다.
x-amz-checksum-crc32 문자열 이 헤더는 개체의 Base64 인코딩된 32비트 CRC32 체크섬입니다.
x-amz-checksum-crc32c 문자열 이 헤더는 개체의 Base64 인코딩된 32비트 CRC32C 체크섬입니다.
x-amz-checksum-crc64nvme 문자열 이 헤더는 개체의 Base64 인코딩된 64비트 CRC64NVME 체크섬입니다. CRC64NVME 체크섬은 항상 전체 객체 체크섬입니다.
x-amz-checksum-sha1 문자열 이 헤더는 개체의 Base64 인코딩된 160비트 SHA1 다이제스트입니다.
x-amz-checksum-sha256 문자열 이 헤더는 개체의 Base64 인코딩된 256비트 SHA256 다이제스트입니다.

페이로드의 무결성 검사로 Content-MD5 헤더 또는 checksum 헤더( x-amz-checksum-crc32, x-amz-checksum-crc32c, x-amz-checksum-crc64nvme, x-amz-checksum-sha1 또는 x-amz-checksum-sha256 포함)가 필요합니다. 요청 본문에 다음 스키마가 포함된 XML 블록이 있어야 합니다.

요소 유형 하위 상위 제한조건
ReplicationConfiguration 컨테이너 Rule 없음 한계 1.
Rule 컨테이너 ID, Status, Filter, DeleteMarkerReplication, Destination, Priority ReplicationConfiguration 한계 1000.
ID 문자열 없음 Rule (a-z,A-Z0-9)와 다음 기호들로 구성되어야 합니다: ! _ . * ' ( ) -
Destination 컨테이너 Bucket Rule 한계 1.
Bucket 문자열 없음 Destination 대상 버킷의 CRN입니다.
Priority 정수 없음 Rule 우선순위는 각 규칙과 연관됩니다. 업로드되는 오브젝트에 여러 규칙을 적용할 수 있는 경우가 있을 수 있습니다. 이러한 상황에서 오브젝트 스토리지는 해당 오브젝트를 복제할 때 우선순위가 더 높은 적용 가능한 규칙을 적용합니다. 따라서 오브젝트에 대해 일치할 수 있는 복제 정책의 규칙 수에 관계없이 단일 복제 규칙만 모든 오브젝트에 적용할 수 있습니다. 숫자가 높을수록 우선순위가 높습니다.
Status 문자열 없음 Rule 규칙이 활성화되어 있는지 여부를 지정합니다. 유효값은 Enabled 또는 Disabled입니다.
DeleteMarkerReplication 컨테이너 Status Rule 한계 1.
Status 문자열 없음 DeleteMarkerReplication 오브젝트 스토리지가 삭제 마커를 복제하는지 여부를 지정합니다. 유효값은 Enabled 또는 Disabled입니다.
Filter 문자열 Prefix, Tag, AND Rule 복제 규칙이 적용되는 오브젝트의 서브세트를 식별하는 필터입니다. Filter 는 정확히 하나의 Prefix, Tag 또는 And 하위 요소를 지정해야 합니다.
Prefix 문자열 없음 Filter 규칙이 적용되는 오브젝트의 서브세트를 식별하는 오브젝트 키 이름 접두부입니다.
Tag 문자열 없음 Filter 태그 키 및 값을 지정하기 위한 컨테이너입니다. 이 규칙은 태그 세트에 태그가 있는 오브젝트에만 적용됩니다.
And 문자열 없음 Filter 규칙 필터를 지정하기 위한 컨테이너입니다. 필터는 규칙이 적용되는 오브젝트의 서브세트를 결정합니다. 이 요소는 둘 이상의 필터를 지정하는 경우에만 필요합니다.
Key 문자열 없음 Tag 태그 키입니다.
Value 문자열 없음 Tag 태그 값입니다.

이 예는 새 오브젝트를 복제하지만 삭제 마커는 복제하지 않습니다.

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN' \
     -H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
     -H 'Content-Type: text/plain; charset=utf-8' \
     -d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
            <Rule>
              <ID>SimpleReplication</ID>
              <Priority>1</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Disabled</Status>
              </DeleteMarkerReplication>
              <Filter/>
              <Destination>
                <Bucket>$DESTINATION_CRN</Bucket>
              </Destination>
          	</Rule>
          </ReplicationConfiguration>'

이 예에서는 project_a/ 로 시작하는 키 (이름) 가 있는 오브젝트를 $DESTINATION_CRN_A 로 식별되는 버킷에 복제하고, project_b/ 로 시작하는 키 (이름) 가 있는 오브젝트를 $DESTINATION_CRN_B 로 식별되는 버킷에 복제하며, Client 키 및 ACME 값이 있는 오브젝트 태그가 있는 오브젝트를 $DESTINATION_CRN_C 로 식별되는 세 번째 버킷에 복제하고, 모든 경우에 삭제 마커를 복제합니다.

다음 네 개의 오브젝트가 소스 버킷에 추가된다고 가정하십시오. 아래에 설명된 대로 대상 버킷에 복제됩니다.

  1. project_a/foo.mp4
  2. project_a/bar.mp4
  3. project_b/baz.pdf
  4. project_b/acme.pdf 이 네 번째 오브젝트에는 Client 키 및 ACME 값이 있는 오브젝트 태그도 있습니다.

다음 규칙으로 인해 오브젝트 1및 2가 $DESTINATION_CRN_A 에 복제됩니다. 오브젝트 3이 $DESTINATION_CRN_B 에 복제됩니다. ID가 AcmeCorp 인 규칙이 ID가 ProjectB 인 규칙보다 높은 우선순위 값을 가지고 있고 두 규칙 모두에 대한 요구사항을 충족하는 동안에는 전자에만 종속되므로 오브젝트 4는 $DESTINATION_CRN_C 에만 복제됩니다.

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN' \
     -H 'Content-MD5: exuBoz2kFBykNwqu64JZuA==' \
     -H 'Content-Type: text/plain; charset=utf-8' \
     -d $'<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
            <Rule>
              <ID>ProjectA</ID>
              <Priority>10</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Prefix>project_a/</prefix>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_A</Bucket>
              </Destination>
          	</Rule>
            <Rule>
              <ID>ProjectB</ID>
              <Priority>5</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Prefix>project_b/</prefix>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_B</Bucket>
              </Destination>
          	</Rule>
            <Rule>
              <ID>AcmeCorp</ID>
              <Priority>20</Priority>
              <Status>Enabled</Status>
              <DeleteMarkerReplication>
                <Status>Enabled</Status>
              </DeleteMarkerReplication>
              <Filter>
                <Tag>
                  <Key>Client</Key>
                  <Value>ACME</Value>
                </Tag>
              </Filter>
              <Destination>
                <Bucket>$DESTINATION_CRN_C</Bucket>
              </Destination>
          	</Rule>
          </ReplicationConfiguration>'

성공적인 요청은 200 응답을 리턴합니다.

버킷의 복제 구성 보기

curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN'

이는 적절한 스키마가 있는 XML 응답 본문을 리턴합니다.

<ReplicationConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Rule>
    <ID>SimpleReplication</ID>
    <Status>ENABLED</Status>
    <DeleteMarkerReplication>
      <Status>DISABLED</Status>
    </DeleteMarkerReplication>
    <Destination>
      <Bucket>crn:v1:bluemix:public:cloud-object-storage:global:a/9978e07eXXXXXXXX66c89c428028654:ef1c725e-XXXX-4967-bcc1-734c03a2b846:bucket:replication-destination</Bucket>
    </Destination>
    <Priority>1</Priority>
    <Filter/>
  </Rule>
</ReplicationConfiguration>

버킷의 복제 구성을 삭제합니다

curl -X "DELETE" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?replication" \
     -H 'Authorization: bearer $TOKEN'

성공적인 요청은 204 응답을 리턴합니다.

버킷의 리플리케이션 실패 내역 나열

다음과 같은 예제 요청 curl

curl -X "GET" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-failures" \
     -H 'Authorization: bearer $TOKEN'

선택적 조회 매개변수

이름 유형 설명
인코딩 유형 문자열 객체 이름에 XML에서 지원하지 않는 유니코드 문자가 사용된 경우, 응답을 올바르게 인코딩하기 위해 이 매개변수를 url로 설정할 수 있습니다.
최대 키 수 문자열 응답에 표시되는 실패 건수를 제한합니다. 기본값 및 최대값은 1,000입니다.
첫 동기화 시도 일시 문자열 목록이 시작되어야 하는 타임스탬프를 역순으로 지정합니다. 이 시간은 복제가 처음 시작된 시점과 일치합니다 ( (항목 내의 필드). 따라서 이 목록에는 지정된 타임스탬프보다 오래된 모든 복제 오류가 포함됩니다.
연속 토큰 문자열 목록이 시작되어야 할 오류 시점을 역순으로 지정합니다. 이는 마지막 목록 조회 요청에서 반환된 항목 뒤에 더 많은 항목이 있을 경우, 페이지 분할을 위해 사용됩니다.

응답 예

<ListReplicationFailureResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <Name>example</Name>
    <FirstSyncAttemptedBefore>2025-12-15T00:00:00.000Z</FirstSyncAttemptedBefore>
    <MaxKeys>10</MaxKeys>
    <IsTruncated>false</IsTruncated>
    <EncodingType>false</EncodingType>
    <KeyCount>2</KeyCount>
    <Contents>
        <Key>test-obj+*1765434016787</Key>
        <VersionId>00000000-0000-0000-0000-019b0c114413</VersionId>
        <SyncType>Content</SyncType>
        <FirstSyncAttempted>2025-12-11T06:20:16.787Z</FirstSyncAttempted>
        <LastSyncAttempted>2025-12-11T06:20:16.787Z</LastSyncAttempted>
        <SyncFailureCause>Versioning disabled on destination bucket</SyncFailureCause>
    </Contents>
    <Contents>
        <Key>test-obj+*1765434016786</Key>
        <VersionId>00000000-0000-0000-0000-019b0c114412</VersionId>
        <SyncType>Content</SyncType>
        <FirstSyncAttempted>2025-12-11T06:20:16.786Z</FirstSyncAttempted>
        <LastSyncAttempted>2025-12-11T06:20:16.786Z</LastSyncAttempted>
        <SyncFailureCause>Replication operation not authorized on target bucket</SyncFailureCause>
    </Contents>
</ListReplicationFailureResult>

응답 요소

이름 유형 설명
ListReplicationFailureResult 컨테이너 루트 레벨 태그
Name 문자열 나열되고 있는 버킷의 이름입니다.
FirstSyncAttemptedBefore 문자열 ISO-8601 요청된 항목의 날짜-타임스탬프 ?first-sync-attempted-before
MaxKeys 숫자 이 상품에 대해 요청된 키의 최대 개수입니다.
IsTruncated 부울 현재 나열된 내용이 잘린 것인지(즉, 이 나열에서 반환된 마지막 요소 이후에 더 많은 실패 사례가 있는지). true 인 경우, NextContinuationToken 가 항상 제공됩니다.
EncodingType 문자열 이 상품 페이지에서 요청된 인코딩 유형입니다.
KeyCount 숫자 이 목록에서 반환된 오류 항목의 수입니다.
ContinuationToken 문자열 이 목록에 지정된 연속 토큰입니다.
NextContinuationToken 문자열 현재 목록이 잘린 경우, 페이징에 사용할 다음 연속 토큰입니다.

버킷에서 오래된 복제 실패에 대한 재시도 일정 설정

이 작업은 30일이 지나 시스템에 의해 더 이상 자동 재시도 대상이 되지 않는 “오래된” 오류를 포함하여, 모든 복제 오류에 대한 재시도를 예약합니다. 장기적인 복제 오류는 24시간 주기로 처리됩니다. 이 요청을 보내면, 다음 날 자정(GMT)부터 시작되는 주기 내에서 처리되지 않은 오류에 대한 재시도가 예약됩니다. 예를 들어, 2026-01-01T01:00:00Z 에서 요청이 발생하면, 이러한 오류가 처리되는 가장 빠른 시점은 2026-01-02T00:00:00Z 입니다. 요청이 성공하면 이 타임스탬프는 응답 헤더 x-ibm-replication-reattempt-scheduled-time 에도 포함됩니다. GMT 기준으로 같은 날에 도착하는 여러 요청(즉, 동일한 예약 시간이 지정되는 경우)은 이뎁포텐트합니다.

각 스테일 오류에 대해서는 최선을 다해 한 번씩 재시도됩니다. 즉, 해당 작업은 실행되지만 실행 시점에 대해서는 보장되지 않습니다.

다음과 같은 예제 요청 curl

curl -X "PUT" "https://$BUCKET.s3.$REGION.cloud-object-storage.appdomain.cloud/?ibm-replication-reattempt" \
     -H 'Authorization: bearer $TOKEN'

응답 예

HTTP/1.1 204 No Content
Connection: close
...
x-ibm-replication-reattempt-scheduled-time: Fri, 12 Dec 2025 00:00:00 GMT

SDK 예제

다음 예제에서는 오브젝트 버전화의 구현이 사용자 정의 엔드포인트의 설정을 허용하는 S3-compatible 라이브러리 또는 도구와 완전히 호환 가능해야 하지만 Python 및 Node.js용 IBM COS SDK를 사용합니다. 써드파티 도구를 사용하려면 AWS V4 서명을 계산하기 위한 HMAC 신임 정보가 필요합니다. HMAC 신임 정보에 대한 자세한 정보는 문서를 참조하십시오.

Python

Python 용 IBM COS SDK를 사용하여 버전화를 사용으로 설정하는 작업은 하위 레벨 클라이언트 구문을 사용하여 수행할 수 있습니다.

클라이언트 사용:

#!/usr/bin/env python3

import ibm_boto3
from ibm_botocore.config import Config
from ibm_botocore.exceptions import ClientError

# Define constants
API_KEY = os.environ.get('IBMCLOUD_API_KEY')
SERVICE_INSTANCE = os.environ.get('SERVICE_INSTANCE_ID')
ENDPOINT = os.environ.get('ENDPOINT')

BUCKET = "my-replication-bucket" # The bucket that will enable replication.

# Create resource client with configuration info pulled from environment variables.
cosClient = ibm_boto3.client("s3",
                         ibm_api_key_id=API_KEY,
                         ibm_service_instance_id=SERVICE_INSTANCE,
                         config=Config(signature_version="oauth"),
                         endpoint_url=ENDPOINT
                         )

response = cosClient.put_bucket_versioning(
    Bucket=BUCKET,
    ReplicationConfiguration={
        'Rules': [
            {
                'ID': 'string',
                'Priority': 123,
                'Filter': {
                    'Prefix': 'string',
                    'Tag': {
                        'Key': 'string',
                        'Value': 'string'
                    },
                    'And': {
                        'Prefix': 'string',
                        'Tags': [
                            {
                                'Key': 'string',
                                'Value': 'string'
                            },
                        ]
                    }
                },
                'Status': 'Enabled'|'Disabled',
                'Destination': {
                    'Bucket': 'string',
                },
                'DeleteMarkerReplication': {
                    'Status': 'Enabled'|'Disabled'
                }
            },
        ]
    }
)

동일한 클라이언트를 사용하여 오브젝트의 버전 나열:

resp = cosClient.list_object_versions(Prefix='some-prefix', Bucket=BUCKET)

Python API는 매우 유연하며 동일한 태스크를 수행하는 여러 가지 방법이 있습니다.

Node.js

IBM COS SDK for Node.js 를 사용하여 버전화 사용:

const IBM = require('ibm-cos-sdk');

var config = {
    endpoint: '<endpoint>',
    apiKeyId: '<api-key>',
    serviceInstanceId: '<resource-instance-id>',
};

var cos = new IBM.S3(config);

var params = {
  Bucket: 'STRING_VALUE', /* required */
  ReplicationConfiguration: { /* required */
    Role: 'STRING_VALUE', /* required */
    Rules: [ /* required */
      {
        Destination: { /* required */
          Bucket: 'STRING_VALUE', /* required */
        },
        Status: Enabled | Disabled, /* required */
        Filter: {
          And: {
            Prefix: 'STRING_VALUE',
            Tags: [
              {
                Key: 'STRING_VALUE', /* required */
                Value: 'STRING_VALUE' /* required */
              },
              /* more items */
            ]
          },
          Prefix: 'STRING_VALUE',
          Tag: {
            Key: 'STRING_VALUE', /* required */
            Value: 'STRING_VALUE' /* required */
          }
        },
        ID: 'STRING_VALUE',
        Prefix: 'STRING_VALUE',
        Priority: 'NUMBER_VALUE',
        }
      }
    ]
  },
  ContentMD5: 'STRING_VALUE',
};
cos.putBucketReplication(params, function(err, data) {
  if (err) console.log(err, err.stack); // an error occurred
  else     console.log(data);           // successful response
});