이 페이지에서는 API를 사용하여 사용자가 전송을 요청할 수 있도록 Amazon Simple Storage Service(Amazon S3)에서 Cloud Storage로 완전히 마이그레이션하는 방법을 설명합니다. 완전히 마이그레이션한 후에는 여러 프로젝트와 인증용 OAuth 2.0을 포함하여 Cloud Storage의 모든 기능을 사용할 수 있습니다.
Cloud Storage를 빠르게 시작하려면 현재 Amazon S3에서 사용하는 도구와 라이브러리를 조금만 변경하면 되는 단순 마이그레이션을 선택하면 됩니다.
Amazon S3에서 Cloud Storage로 마이그레이션
Amazon S3에서 Cloud Storage로 완전히 마이그레이션하려면 다음 단계를 완료해야 합니다.
- 기존
x-amz-*
헤더를x-goog-*
헤더로 변경합니다. - AWS 액세스제어 목록(ACL) XML을 Cloud Storage ACL XML로 변경합니다(액세스제어 목록(ACL) 생성 및 관리 참조).
- 요청에 x-goog-project-id 헤더를 설정합니다.
OAuth 2.0 인증에 설명된 대로 OAuth 2.0 인증을 설정합니다. 첫 번째 단계는 Google에 애플리케이션(요청을 실행하는 애플리케이션)을 등록하는 것입니다. OAuth 2.0을 사용하면
Authorization
헤더가 다음과 같이 표시됩니다.Authorization: Bearer OAUTH2_TOKEN
OAuth 2.0은 애플리케이션에 암호화 서명을 직접 요구하지 않고 보안에 SSL을 사용하므로 구현하기가 더 쉽습니다. OAuth를 사용하면 애플리케이션에서 사용자 계정과 연결된 데이터에 대한 액세스를 요청할 수 있으며 액세스 범위를 읽기 전용, 읽기-쓰기, 전체 제어를 포함한 여러 수준으로 지정할 수 있습니다. 자세한 내용은 Cloud Storage OAuth 2.0 범위 및 사용자 계정 사용자 인증 정보를 참조하세요.
액세스 제어
이 섹션에서는 Amazon S3에서 Cloud Storage로 이전하는 데 도움이 되는 액세스 제어의 몇 가지 예를 보여줍니다. Cloud Storage에서 액세스 제어의 개요는 액세스 제어를 참조하세요.
Cloud Storage에서는 버킷과 객체에 ACL을 적용하는 여러 가지 방법이 있습니다(액세스제어 목록(ACL) 생성 및 관리 참조). ACL을 지정하는 방법 중 2가지가 Amazon S3와 유사합니다.
acl
쿼리 문자열 매개변수를 사용하면 특정 범위에 ACL을 적용할 수 있습니다.x-goog-acl
요청 헤더를 사용하여 미리 준비된 ACL이라고도 하는 사전 정의된 ACL 적용
acl 쿼리 문자열 매개변수 사용하기
Amazon S3 요청에 사용할 때와 똑같은 방식으로 Cloud Storage 요청에 acl
쿼리 문자열 매개변수를 사용할 수 있습니다. acl
매개변수는 기존 객체, 기존 버킷, 생성하는 버킷에 ACL을 적용하기 위해 PUT
메서드와 함께 사용됩니다. PUT
요청에서 acl
쿼리 문자열 매개변수를 사용할 때 Cloud Storage ACL 구문을 사용하여 XML 문서를 요청 본문에 연결해야 합니다. XML 문서에는 버킷 또는 객체에 적용할 개별 ACL 항목이 들어 있습니다.
다음 예시에서는 acl
쿼리 문자열 매개변수를 사용하는 Amazon S3에 대한 PUT
요청을 보여줍니다. ACL은 요청 본문으로 보내는 XML 문서에 정의됩니다. PUT
요청은 my-travel-maps
라는 버킷에 있는 europe/france/paris.jpg
라는 객체의 ACL을 변경합니다. ACL은 jane@gmail.com에 FULL_CONTROL
권한을 부여합니다.
PUT europe/france/paris.jpg?acl HTTP/1.1 Host: my-travel-maps.s3.amazonaws.com Date: Wed, 06 Nov 2013 19:28:18 GMT Content-Length: 598 Content-Type: application/xml Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=4c45f25bb679fdab0de5a287625d6a143414728d93c9aeb9f4cc91c33a1c45fg <?xml version='1.0' encoding='utf-8'?> <AccessControlPolicy> <Owner> <ID>5a6557ba40f7c86496ffceae789fcd888abc1b62a7149873a0fe12c0f60a7d95</ID> <DisplayName>ownerEmail@example.com</DisplayName> </Owner> <AccessControlList> <Grant> <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser"> <ID>fd447671d60b979f78ee6fcec7b22afc80e6b26a4db16eed01afb8064047949b</ID> <DisplayName>jane@gmail.com</DisplayName> </Grantee> <Permission>FULL_CONTROL</Permission> </Grant> </AccessControlList> </AccessControlPolicy>
다음은 Cloud Storage에 대한 동일한 요청입니다.
PUT europe/france/paris.jpg?acl HTTP/1.1 Host: my-travel-maps.storage.googleapis.com Date: Wed, 06 Nov 2013 19:37:33 GMT Content-Length: 268 Content-Type: application/xml Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg <?xml version='1.0' encoding='utf-8'?> <AccessControlList> <Entries> <Entry> <Permission>FULL_CONTROL</Permission> <Scope type="UserByEmail"> <EmailAddress>jane@gmail.com</EmailAddress> </Scope> </Entry> </Entries> </AccessControlList>
Cloud Storage에서는 ACL XML 문서에 <Owner/>
요소가 필요하지 않습니다. 자세한 내용은 버킷 및 객체 소유권을 참조하세요.
acl
쿼리 문자열 매개변수를 GET
메서드와 함께 사용하여 버킷 및 객체 ACL을 검색할 수도 있습니다. ACL은 응답 본문에 연결된 XML 문서에 설명되어 있습니다. 객체 또는 버킷에서 ACL을 적용하거나 검색하려면 FULL_CONTROL
권한이 있어야 합니다.
확장 요청 헤더가 있는 ACL 적용
Amazon S3 요청에 x-amz-acl
헤더를 사용할 때와 똑같은 방법으로 Cloud Storage 요청에 x-goog-acl
헤더를 사용하여 버킷과 객체에 사전 정의된 ACL을 적용할 수 있습니다. 버킷이나 객체를 만들거나 업로드할 때 대개 x-goog-acl
(x-amz-acl
) 헤더를 사용하여 버킷이나 객체에 사전 정의된 ACL을 적용합니다. Cloud Storage의 사전 정의된 ACL은 비공개, 공개 읽기, 공개 읽기 및 쓰기 등을 포함하여 Amazon S3의 미리 준비된 ACL과 비슷합니다. Cloud Storage 사전 정의된 ACL의 목록은 사전 정의된 ACL을 참조하세요.
다음 예시에서는 Amazon S3에서 my-travel-maps
라는 버킷에 업로드되는 europe/france/paris.jpg
라는 객체에 public-read
ACL을 적용하는 PUT
객체 요청을 보여줍니다.
PUT europe/france/paris.jpg HTTP/1.1 Host: my-travel-maps.s3.amazonaws.com Date: Wed, 06 Nov 2013 20:48:42 GMT Content-Length: 888814 Content-Type: image/jpg x-amz-acl: public-read Authorization: AWS4-HMAC-SHA256 Credential=AWS-ACCESS-KEY/20131106/us-east-1/s3/aws4_request, SignedHeaders=content-length;content-type;date;host, Signature=808150c37dbd1b425b2398421d6fc3dd6d4942dfaae9e519fd5835aa62fd62ab <888814 bytes in entity body>
다음은 Cloud Storage에 대한 동일한 요청입니다.
PUT europe/france/paris.jpg HTTP/1.1 Host: my-travel-maps.storage.googleapis.com Date: Wed, 06 Nov 2013 20:49:57 GMT Content-Length: 888814 Content-Type: image/jpg x-goog-acl: public-read Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg <888814 bytes in entity body>
x-goog-acl
헤더를 사용하여 사전 정의된 ACL을 기존 버킷이나 객체에 적용할 수도 있습니다. 이를 위해서는 요청에 acl
쿼리 문자열 매개변수를 포함하지만 XML 문서는 포함하지 않습니다. 기존 버킷이나 객체에 사전 정의된 ACL을 적용하는 것은 한 사전 정의된 ACL에서 다른 사전 정의된 ACL로 변경하려 하거나 커스텀 ACL을 사전 정의된 ACL로 업데이트하려는 경우에 유용합니다. 예를 들어 다음 PUT
객체 요청은 my-travel-maps
라는 버킷에 있는 europe/france/paris.jpg
라는 객체에 사전 정의된 ACL private
을 적용합니다.
PUT europe/france/paris.jpg?acl HTTP/1.1 Host: my-travel-maps.storage.googleapis.com Date: Wed, 06 Nov 2013 00:26:36 GMT Content-Length: 0 x-goog-acl: private Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg <empty entity body>
ACL 관리에 대한 자세한 내용은 액세스제어 목록(ACL) 생성 및 관리를 참조하세요.
Amazon S3에서 Cloud Storage로 요청 메서드 마이그레이션
Cloud Storage는 버킷에서 데이터 읽기 및 쓰기에 Amazon S3와 동일한 표준 HTTP 요청 메서드를 지원합니다. 따라서 현재 Amazon S3에서 사용하는 대부분의 도구와 라이브러리가 Cloud Storage에서 그대로 작동합니다. Cloud Storage는 다음 요청 메서드를 지원합니다.
GET
에 대한 서비스 요청PUT
,GET
,DELETE
등 버킷 요청GET
,POST
,PUT
,HEAD
,DELETE
등 객체 요청
자세한 내용은 XML API 참조 메서드를 참조하세요. Cloud Storage에 요청을 보낼 때 필요 시 적절한 Cloud Storage 구문을 사용하도록 요청 본문을 변경해야 합니다. 예를 들어 버킷의 수명 주기 구성을 만들 때 Amazon S3 수명 주기 XML과 다른 Cloud Storage 수명 주기 XML을 사용합니다.
Cloud Storage XML API와 Amazon S3의 몇 가지 차이점은 다음과 같습니다.
Amazon S3 기능 | Cloud Storage XML API 기능 |
---|---|
멀티파트 업로드에서 고객 제공 암호화 키를 사용할 때 최종 요청에는 고객 제공 암호화 키가 포함되지 않습니다. | Cloud Storage XML API에서 최종 요청을 포함하여 멀티파트 업로드의 모든 요청에는 동일한 고객 제공 암호화 키를 제공해야 합니다. Cloud Storage가 요청이 업로드를 완료할 때까지 기다리는 동안 암호화 키 정보를 저장하지 않지만 완료된 객체의 체크섬을 계산하기 위해서는 키가 필요하기 때문에 이 요구사항이 있습니다. |
Amazon S3에서는 V4 서명을 사용하여 단위 분할 전송 인코딩을 사용하는 업로드를 인증할 수 있습니다. | 현재 Cloud Storage XML API에서는 단위 분할 전송 인코딩과 V4 서명을 동시에 사용할 수 없습니다. 일부 Amazon S3 도구에서는 서명과 함께 단위 분할 전송 인코딩을 기본으로 사용합니다. 이러한 경우 단위 분할 전송 인코딩을 중지해야 합니다. |
GET/POST 버킷 쿼리 문자열 매개변수:
|
대안:
|
다중 객체 삭제 POST/?delete |
Google Cloud 콘솔을 사용하여 객체 여러 개를 간편하게 삭제합니다. 또는 JSON API에서 클라이언트가 만드는 HTTP 연결 수를 줄이기 위한 일괄 요청 전송을 지원합니다. |
Amazon S3에서 Cloud Storage로 헤더 마이그레이션
Cloud Storage는 여러 표준 HTTP 헤더와 여러 커스텀(확장) HTTP 헤더를 사용합니다. Amazon S3에서 Cloud Storage로 전환하는 경우 아래 표와 같이 커스텀 Amazon S3 헤더를 해당 Cloud Storage 커스텀 헤더 또는 유사 기능으로 변환할 수 있습니다.
대부분의 Amazon S3 헤더에서 x-amz
프리픽스를 x-goog
로 바꾸기만 하면 됩니다.
Amazon S3 헤더 | Cloud Storage 헤더 |
---|---|
x-amz-storage-class |
x-goog-storage-class |
x-amz-acl |
x-goog-acl |
x-amz-date |
x-goog-date |
x-amz-meta-* |
x-goog-meta-* |
x-amz-copy-source |
x-goog-copy-source |
x-amz-metadata-directive |
x-goog-metadata-directive |
x-amz-copy-source-if-match |
x-goog-copy-source-if-match |
x-amz-copy-source-if-none-match |
x-goog-copy-source-if-none-match |
x-amz-copy-source-if-unmodified-since |
x-goog-copy-source-if-unmodified-since |
x-amz-copy-source-if-modified-since |
x-goog-copy-source-if-modified-since |
여러 헤더가 서로 다르거나 Cloud Storage에서 적용되지 않습니다.
Amazon S3 헤더 | Cloud Storage 헤더 |
---|---|
x-amz-server-side-encryption |
필수 항목이 아닙니다. Cloud Storage는 디스크에 기록하기 전에 모든 데이터를 자동으로 암호화합니다. 자세한 내용은 암호화를 참조하세요. |
x-amz-grant-* |
x-goog-acl (사전 정의된 ACL 값 포함) |
x-amz-mfa |
OAuth 2.0 인증을 사용합니다. |
x-amz-website-redirect-location , x-amz-copy-source-range |
해당 사항 없음 |
Cloud Storage 헤더에 대한 참조는 XML API의 HTTP 헤더 및 쿼리 문자열 매개변수를 참조하세요.
다음 단계
- Amazon S3에서 마이그레이션 계획
- Storage Transfer Service를 사용하여 Amazon S3 및 Microsoft Azure Blob Storage와 같은 외부 소스에서 Cloud Storage로 데이터 전송
- Cloud Storage 버킷을 Amazon S3와 동기화된 상태로 유지하기 위해 Amazon S3 이벤트 알림을 사용하는 이벤트 기반 전송 만들기