티스토리 뷰
이번 포스팅에서는 Cloud Storage에 대해서 알아보겠습니다~
Cloud Storage
목차:
1. Bucket, Object, Access
2. Cloud Storage
Cloud Storage를 이해하기 위해 먼저 Bucket, Object, Access의 개념을 소개하겠습니다.
1. Bucket, Object(버킷, 객체)
1.1 Bucket(버킷)
-
모든 버킷은 프로젝트와 연결됩니다.
-
모든 버킷이 단일 Cloud Storage 네임스페이스에 상주하므로 전역에서 고유해야 합니다.(중첩될 수 없습니다.)
-
버킷 생성 시에 필요한 것
-
전역에 고유한 이름
-
콘텐츠가 저장되는 위치
-
기본 스토리지 클래스
-
-
버킷이 저장되는 위치는 end user의 대기시간이 최소화되는 위치로 선정해야 합니다.
1.2 Object(객체)
-
객체 데이터
-
Cloud Storage에 저장되는 파일입니다
-
Bucket의 Storage class를 상속합니다.
- Minimum size가 존재하지 않고 할당량에 맞게 조정할 수 있습니다.
-
-
객체 메타 데이터
-
key-value 값 형태에며 객체의 퀄리티를 설명합니다.
-
-
불변성
-
객체는 변경할 수 없지만 덮어쓰기나 삭제는 가능합니다.
-
그래서 새 버전을 만들어서 사용합니다.
-
-
보안성
-
데이터를 디스크에 쓰기 전에 서버 측의 데이터를 암호화합니다.
-
전송 중인 데이터는 https를 사용하여 암호화합니다.
-
서버 측 암호화
-
Cloud Storage가 데이터를 수신한 후 데이터를 디스크에 기록하여 저장하기 전에 수행되는 암호화입니다.
-
고객 제공 암호화 키
-
서버 측 암호화에 사용할 암호화 키를 직접 만들고 관리할 수 있습니다.
-
-
고객 관리 암호화 키
-
Cloud Key Management Service를 사용하여 암호화 키를 생성 및 관리할 수 있습니다.
-
-
-
클라이언트 측 암호화
-
데이터가 Cloud Storage로 전송되기 전에 수행되는 암호화입니다. 이러한 데이터는 이미 암호화된 상태로 Cloud Storage에 수신되지만 서버 측 암호화도 수행됩니다.
-
-
-
1.3 Access
1.3.1 Access contol
- 데이터에 접근하기 위해 다음을 사용할 수 있습니다.
-
gsutil command
-
JSON
-
XML APIs
- 프로젝트에 IAM을 사용하여 버킷을 볼 수있는 개별 사용자 또는 service account를 제어하고, 버킷의 객체를 나열하고, 버킷의 객체 이름을 보거나, 새 버킷을 만들 수 있습니다. 대부분의 경우 Cloud IAM이면 충분하며 역할은 프로젝트에서 버킷으로 상속됩니다.
- ACL(Access Control List)은 더 세밀한 조정을 제공합니다.
- 보다 세부적인 제어를 위해 singed URL은 버킷 또는 객체에 대한 시간 제한 액세스를 제공하는 암호화 키를 제공합니다. 마지막으로 singed policy 문서는 signed URL을 가진 사람이 어떤 종류의 파일을 업로드 할 수 있는지 결정하여 제어를 더욱 세분화합니다.
1.3.2 Access control lists(ACLs)
- ACL은 버킷과 객체에 액세스 할 수있는 사람과 이들이 가진 액세스 수준을 정의하는 데 사용할 수있는 메커니즘입니다.
- 버킷 또는 객체에 대해 생성 할 수있는 최대 ACL 항목 수는 100개입니다. 각 ACL은 하나 이상의 항목으로 구성되며 이러한 항목은 두 가지 정보로 구성됩니다.
-
지정된 작업을 수행 할 수있는 사용자를 정의하는 범위 (예 : , 특정 사용자 또는 사용자 그룹).
-
수행 할 수있는 작업 (예 : 읽기 또는 쓰기)을 정의하는 권한.
위 그림에서 allUsers 식별자는 Google 계정 유무에 관계없이 인터넷에있는 모든 사용자를 나타냅니다. 반대로 allAuthenticatedUsers 식별자는 Google 계정으로 인증 된 모든 사람을 나타냅니다.
1.3.3 Signed URLs
- 일부 응용 프로그램의 경우 리소스 액세스를 제어하기 위해 계정 기반 인증을 사용하는 대신 모든 사용자가 사용할 수있는 제한된 시간 액세스 토큰을 부여하는 것이 더 쉽고 효율적입니다. (예 : 사용자에게 Google 계정이 필요하지 않은 경우).
- Signed URL을 사용하면 Cloud Storage에 대해이 작업을 수행 할 수 있습니다. 특정 Cloud Storage 리소스에 대한 읽기 또는 쓰기 액세스 권한을 부여하고 액세스 만료시기를 지정하는 URL을 만듭니다. 해당 URL은 서비스 계정과 연결된 비공개 키를 사용하여 서명됩니다. 요청이 수신되면 Cloud Storage는 신뢰할 수있는 보안 주체 (이 경우 서비스 계정)를 대신하여 액세스 권한 부여 URL이 발급되었는지 확인하고 해당 계정에 대한 신뢰를 URL 소유자에게 위임합니다.
- Signed URL을 제공 한 후에는 제어 할 수 없습니다. 따라서 적절한 시간이 지나면 서명 된 URL이 만료되기를 기다려야 합니다.
1.4 객체와 버킷에 대한 접근을 통제하는 방법
-
IAM과 ACL은 동시에 작동합니다.
-
IAM(균일한 액세스 제어: 보통 추천되는 방식)
-
대부분 IAM만으로 충분합니다.
-
역할은 프로젝트 -> 버킷 -> 객체로 상속됩니다.
-
-
ACL(세분화된 엑세스 제어)
-
IAM보다 세밀한 제어는 ACL로 할 수 있습니다.
-
ACL의 구성 요소
-
작업을 수행하는 사용자(혹은 그룹) 범위
-
작업을 정의하는 권한(read / write)
-
-
1.4 객체 버전 관리 - 객체 버전 관리하는 법
Cloud Storage는 객체 버전을 식별하는 데 2가지 속성을 사용합니다.
-
객체 데이터의 버전을 식별합니다.
-
객체 메타데이터 버전을 식별합니다.
버킷에서 버전을 관리할 수 있습니다.
-
버전을 나열하기
-
이전 버전으로 복원하기
-
필요시 버전을 영구 삭제하기
-
클라우드 스토리지는 변경 기록을 보관합니다.
-
객체 버전을 설정하지 않으면 new는 항상 old를 재정의(override)합니다.
-
라이프사이클 정책도 제공합니다.
-
1년 동안 오래된 개체 삭제
-
특정 시점 이전에 생성된 개체 삭제
-
버전 관리가 활성화된 버킷의 각 개체의 최신 버전 3개만 유지
-
2. Cloud Storage
-
Google Cloud에 객체를 저장하는 서비스입니다. Cloud Storage is Binary Large Object Storage(BLOB)
-
객체란 모든 형식의 파일로 구성된 변경할 수 없는 데이터 조각입니다.
-
버킷에서 만들 수 있는 객체 수에는 제한이 없습니다.
-
객체는 버킷이라는 컨테이너에 저장합니다.
-
-
Cloud Storage의 모든 데이터는 프로젝트에 귀속됩니다.
-
Cloud Storage는 Unstructured Data에 적합합니다.
-
즉, Cloud Storage는 bucket의 collection입니다.
프로젝트를 만든 후 Cloud Stotage 버킷을 만들고, 버킷에 객체를 업로드하고, 버킷에서 객체를 다운로드할 수 있습니다. 또한 지정된 구성원 또는 웹사이트 호스팅과 같은 특정 사용 사례의 경우 공개 인터넷의 모든 사용자가 데이터에 액세스 가능하도록 권한을 부여할 수 있습니다.
2.1 Features of Cloud Storage
-
확장 가능한 관리형 서비스입니다.
-
용량을 미리 프로비저닝 할 필요 없습니다.
-
-
다향한 용도로 사용 가능합니다.
-
웹 사이트 콘텐츠 배포가 가능합니다.
-
재해복구 & 아카이브를 위한 저장이 가능합니다
-
직접 다운로드를 통해 End User에게 대용량 데이터 개체 배포가 가능합니다.
-
-
클라우드 스토리지 안의 각 개체는 URL이 있기 때문에 파일 시스템이 아닙니다.
2.2 Storage Classes and Location Types
- Cloud Storage는 다음과 같이 4개의 classes가 있습니다. Standard, Nearline, Coldline, Archive 자세한 설명은 아래에 있습니다.
- 그리고 각각의 Storage class는 3개의 location types을 가지고 있습니다. Multi-region, Dual-region, Region
-
Multi-region : 미국과 같이 두 개 이상의 지리적 장소가 포함 된 넓은 지리적 영역입니다.
-
Dual-region : 핀란드 및 네덜란드와 같은 특정 region 쌍입니다.
-
Region : 런던과 같은 특정 지리적 장소입니다.
- Standard Storage
자주 액세스하는 데이터 ("hot"데이터) 및 짧은 기간 동안 만 저장되는 데이터에 가장 적합합니다. 가장 비싼 스토리지 클래스이지만 최소 저장 기간과 검색 비용이 없습니다.
-
Region에서 사용되는 경우, Standard Storage는 데이터를 사용하는 Google Kubernetes Engine 클러스터 또는 Compute Engine 인스턴스와 동일한 위치에 데이터를 저장하는 데 적합합니다. 리소스를 함께 배치하면 데이터 집약적인 computation 성능을 극대화하고 네트워크 요금을 줄일 수 있습니다.
-
Dual-Region에서 사용하는 경우 연결된 지역 중 하나에있는 Google Cloud 제품에 액세스 할 때 여전히 최적화 된 성능을 얻을 수 있지만 지리적으로 분리 된 위치에 데이터를 저장하여 가용성이 향상됩니다.
-
Multi-Region에서 사용되는 경우 Standard Storage는 웹 사이트 콘텐츠 제공, 비디오 스트리밍, 대화 형 워크로드 실행 또는 모바일 및 게임 애플리케이션을 지원하는 데이터 제공과 같이 전 세계에서 액세스되는 데이터를 저장하는 데 적합합니다.
- Nearline Storage
데이터 백업, 롱테일 멀티미디어 콘텐츠 및 데이터 보관과 같이 자주 액세스하지 않는 데이터를 저장하기위한 저렴하고 내구성이 뛰어난 스토리지 서비스입니다. 약간 낮은 가용성, 30 일의 최소 저장 기간 및 데이터 액세스 비용이 낮은 미사용 스토리지 비용에 대해 허용되는 절충안 인 시나리오에서 Standard Storage보다 나은 선택입니다.
- Coldline Stoage
자주 액세스하지 않는 데이터를 저장하기위한 매우 저렴하고 내구성이 뛰어난 스토리지 서비스입니다. 약간 낮은 가용성, 90 일의 최소 저장 기간 및 높은 데이터 액세스 비용이 낮은 미사용 저장 비용에 대해 허용되는 절충안 인 시나리오에서 Standard Storage 또는 Nearline Storage보다 더 나은 선택입니다.
- Archive Storage
데이터 아카이브, 온라인 백업 및 재해 복구를위한 가장 저렴하고 내구성이 뛰어난 스토리지 서비스입니다. 다른 클라우드 제공 업체에서 제공하는 "Cold set"스토리지 서비스와 달리 귀하의 데이터는 몇 시간 또는 며칠이 아닌 밀리 초 이내에 사용할 수 있습니다. 다른 Cloud Storage 스토리지 클래스와 달리 Archive Storage에는 가용성 SLA가 없지만 일반적인 가용성은 Nearline Storage 및 Coldline Storage와 비슷합니다. 또한 데이터 액세스 및 운영 비용이 더 높을뿐만 아니라 최소 365 일 보관 기간이 있습니다. 아카이브 스토리지는 1 년에 한 번 미만으로 액세스하려는 데이터에 가장 적합한 선택입니다.
2.3 Changing defualt storage classes
- Object를 bucket에 업로드 할 때 객체에 대한 Stoage class를 지정하지 않는 한 객체에 버킷의 Storage class가 할당됩니다. 버킷의 default storage class를 변경할 수 있지만 location types을 Region에서 Multi-region/Dual-region으로 또는 그 반대로 변경할 수는 없습니다.
- object를 다른 bucket으로 이동하거나 object에 대한 URL을 변경하지 않고도 버킷에 이미있는 object의 Storage class를 변경할 수도 있습니다. 예를 들어 버킷에 보관하고 싶지만 자주 액세스하지 않을 것으로 예상되는 객체가있는 경우 객체 별 Strorage class를 설정하는 것이 유용합니다. 이 경우 특정 객체의 스토리지 클래스를 Nearline, Coldline 또는 Archive Storage로 변경하여 비용을 최소화 할 수 있습니다.
- 개체 검사는 비동기식 배치로 이루어 지므로 규칙이 즉시 적용되지 않을 수 있습니다. 또한 수명주기 구성에 대한 업데이트가 적용 되려면 최대 24 시간이 걸릴 수 있습니다. 즉, 수명주기 구성을 변경할 때 개체 수명주기 관리는 최대 24 시간 동안 이전 구성을 기반으로 작업을 계속 수행 할 수 있습니다.
2.4 Cloud Storage features
Customer-supplied encryption key(CSEK)
- 가상 머신에 영구 디스크를 연결할 때 고객이 제공 한 암호화 키입니다. 이를 통해 Cloud Storage에서도 사용할 수 있는 Google 관리 키 대신 자체 암호화 키를 제공 할 수 있습니다.
Object Lifecycle Management
- 객체를 자동으로 삭제하거나 보관할 수있는 객체 수명주기 관리를 제공합니다.
- 객체의 TTL (Time to Live) 설정, 이전 버전의 객체 보관, 비용 관리를위한 객체의 스토리지 클래스 '다운 그레이드'와 같은 일반적인 사용 사례를 지원하기 위해 Cloud Storage는 객체 수명주기 관리를 제공합니다.
- 수명주기 관리 구성을 버킷에 할당 할 수 있습니다. 구성은 버킷의 모든 객체에 적용되는 규칙 집합입니다. 따라서 객체가 규칙 중 하나의 기준을 충족하면 Cloud Storage는 객체에 대해 지정된 작업을 자동으로 수행합니다.
- 다음은 몇 가지 사용 사례입니다. 먼저, 1 년이 지난 객체의 스토리지 클래스를 Coldline Storage로 다운 그레이드합니다. 둘째, 특정 날짜 이전에 만든 개체를 삭제합니다. 그리고 세 번째로 버전 관리가 활성화 된 버킷에 각 객체의 최신 버전 3 개만 유지합니다.
Object Versioning
- 버킷에서 여러 버전의 객체를 유지할 수있는 객체 버전 관리입니다. 여러 파일 인 것처럼 버전에 대한 요금이 부과되므로 명심해야합니다.
- Cloud Storage에서 객체는 변경 불가능합니다. 즉, 업로드 된 객체는 스토리지 수명 내내 변경할 수 없습니다. 삭제되거나 덮어 쓴 객체의 검색을 지원하기 위해 Cloud Storage는 객체 버전 관리 기능을 제공합니다.
- 버킷에 대해 객체 버전 관리를 활성화 할 수 있습니다. 사용 설정되면 Cloud Storage는 객체의 라이브 버전을 덮어 쓰거나 삭제할 때마다 객체의 보관 된 버전을 만듭니다. 보관 된 버전은 개체의 이름을 유지하지만이 슬라이드에 g1에 의해 설명 된 것처럼 세대 번호로 고유하게 식별됩니다.
- 객체 버전 관리가 활성화되면 필요에 따라 객체의 보관 된 버전을 나열하거나 객체의 라이브 버전을 이전 상태로 복원하거나 보관 된 버전을 영구적으로 삭제할 수 있습니다. 언제든지 버킷에 대한 버전 관리를 켜거나 끌 수 있습니다. 버전 관리를 끄면 기존 객체 버전이 그대로 유지되고 버킷이 새 보관 된 객체 버전 누적을 중지합니다.
Object Versioning
- VM 디렉터리를 버킷과 동기화 할 수 있도록 디렉터리 동기화를 제공합니다.
Object Change Notification
- Object change notification은 감시 요청을 통해 객체가 업데이트되거나 버킷에 추가 될 때 애플리케이션에 알리는 데 사용할 수 있습니다.
- 감시 요청을 완료하면 새 알림 채널이 생성됩니다. 알림 채널은 버킷을 감시하는 애플리케이션에 알림 메시지를 보내는 수단입니다. 이 기록에서 지원되는 유일한 알림 채널 유형은 웹훅입니다.
- 알림 채널이 시작된 후 Cloud Storage는 객체가 버킷에서 추가, 업데이트 또는 제거 될 때마다 애플리케이션에 알립니다. 예를 들어 여기에 표시된대로 버킷에 새 사진을 추가하면 애플리케이션에 썸네일을 생성하라는 알림을 보낼 수 있습니다. 그러나 Pub / Sub 알림은 더 빠르고 유연하며 설정이 쉽고 비용 효율적이기 때문에 Cloud Storage 버킷의 객체 변경 사항을 추적하는 데 권장되는 방법입니다. Pub / Sub는 Google의 분산 실시간 메시징 서비스이며 애플리케이션 개발 과정에서 다룹니다.
Data Import
- Cloud Console을 사용하면 개별 파일을 버킷에 업로드 할 수 있습니다. 하지만 테라 바이트 또는 페타 바이트의 데이터를 업로드해야한다면 어떨까요? 이를 해결하는 서비스에는 Transfer Appliance, Storage Transfer Service, Offline Media Import 세 가지가 있습니다.
-
Transfer Appliance : Transfer Appliance는 비즈니스 운영을 중단하지 않고 대용량 데이터 (수백 테라 바이트에서 최대 1 페타 바이트까지)를 Google Cloud로 안전하게 마이그레이션하는 데 사용할 수있는 하드웨어 어플라이언스입니다.위 사진의 이미지는 전송 어플라이언스입니다.
-
Storage Transfer Service : Storage Transfer Service를 사용하면 온라인 데이터를 고성능으로 가져올 수 있습니다. 해당 데이터 소스는 다른 Cloud Storage 버킷, Amazon S3 버킷 또는 HTTP / HTTPS 위치 일 수 있습니다.
-
Offline Media Import : Offline Media Import는 물리적 미디어 (예 : 스토리지 어레이, 하드 디스크 드라이브, 테이프 및 USB 플래시 드라이브)가 데이터를 업로드하는 공급자에게 전송되는 타사 서비스입니다.
Google Cloud Platform -> Storage -> Transfer
Online Transfer
-
CLI 환경에서 gsutil
-
GUI 환경에서 Drag & Drop
-
예약/관리형 batch전송
-
다양한 곳에서 데이터를 Cloud Storage로 전송할 수 있습니다.
-
타 클라우드(AWS S3)
-
다른 Cloud Storage 리전
-
HTTPS endpoint
-
Transfer Appliance
-
오프라인 데이터 전송
-
빠르고 안전합니다.
-
대용량 데이터를 빠르고 안전하게 Cloud Storage에 올릴 때 좋습니다.
-
-
용도
-
Nearline / Coldline / Archive 같은 스토리지 클래스도 이동하는데 적합합니다.
-
온프레미스를 쓰고 있는 고객들이 클라우드 환경 테스트해보고 싶어 할 때
-
-
20TB를 초과하거나 업로드하는데 일주일 이상 걸리는 데이터의 경우에 Transfer Appliance가 권장합니다.
Strong consistency
- Cloud Storage에 객체를 업로드하고 성공 응답을 받으면 Google이 서비스를 제공하는 모든 위치에서 객체를 즉시 다운로드 및 메타 데이터 작업에 사용할 수 있습니다. 새 개체를 만들거나 기존 개체를 덮어 쓰는 경우에도 마찬가지입니다. 업로드는 Strong consistency여서 쓰기 후 읽기 또는 메타 데이터 업데이트 후 읽기 작업에 대해 404 not found 응답 또는 오래된 데이터를 수신하지 않습니다.
- Strong global consistency는 개체에 대한 삭제 작업으로도 확장됩니다. 삭제 요청이 성공이후 객체 또는 해당 메타 데이터를 즉시 다운로드하려고하면 404 Not Found 상태 코드가 표시됩니다. 삭제 작업이 성공한 후 개체가 더 이상 존재하지 않기 때문에 404 오류가 발생합니다.
- 버킷 목록은 Strong consistency됩니다. 예를 들어 버킷을 생성 한 다음 즉시 버킷 나열 작업을 수행하면 반환 된 버킷 목록에 새 버킷이 나타납니다.
- 객체 목록도 Strong consistency됩니다. 예를 들어 객체를 버킷에 업로드 한 다음 즉시 객체 나열 작업을 수행하면 새 객체가 반환 된 객체 목록에 나타납니다.
Choosing a storage class
위의 정리를 다 확인하셨다면 아래의 문제에 답해보세요~
1. Your Cloud Storage objects live in buckets. Which of these characteristics do you define on a per-bucket basis?
A default storage class
A geographic location
A globally-unique name
2. True or false: Cloud Storage is well suited to providing the root file system of a Linux virtual machine.
False(Cloud Storage is object storage rather than file storage. Compute Engine virtual machines use Persistent Disk storage to contain their file systems.)
3. Why would a customer consider the Coldline storage class?
To save money on storing infrequently accessed data.(Data stored in Coldline is billed at a low monthly storage rate, although a fee is assessed on retrievals.)
Cloud Storage를 실제 사용하실 때는 cloud.google.com/storage/docs/best-practices?hl=ko를 참고하시면 됩니다~
GCP를 통해 Cloud Storage를 실제 구축하는 방법도 다시 포스팅하겠습니다
참고 및 출처 : lifeoncloud.kr/gcp/gcp-docs/cloud-storage/lifeoncloud.kr/gcp/gcp-docs/cloud-storage/