일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- playbook
- Solution Architect
- Cloud Bigtable
- Compute Engine
- Google Cloud Platorm
- AWS 자격증
- 리버스 프록시
- VPC
- 아마존웹서비스
- AWS Database
- Cloud Storage
- Cloud Datastore
- AWS Certificate
- 앤서블
- AWS Solution Architect
- kubernetes
- GKE
- Cloud SQL
- AWS
- Amazon Web Service
- gcp
- Reverse Proxy
- Cloud Spanner
- container
- Google Cloud
- Kubernetes Engine
- Google Cloud Platform
- ansible
- Google Cloud Platrofm
- Solution Architect Certificate
- Today
- Total
sungwony
[GCP] Google Cloud Plaform - Cloud Storage 본문
이 포스팅은 Coursera의 Google Cloud Platform Fundamentals:Core Infrastructure 강의를 요약 정리 한 것입니다.
모든 어플리케이션은 데이터를 저장한다. 이미 VM의 영구 디스크에 데이터를 저장할 수 있다는 것을 알고 있다. Google Cloud Platform에는 구조적, 비 구조적, 트랜잭션 및 관계형 데이터에 대한 요구를 충족시키기위한 다른 스토리지 옵션이 있다. 이 모듈에서는 Cloud Storage, Cloud SQL, Cloud Spanner, Cloud Data Store 및 Google Big Table과 같은 핵심 스토리지 옵션에 대해 설명한다. 응용 프로그램에 따라 이러한 서비스 중 하나 이상을 사용하여 작업을 수행 할 수 있다.
클라우드 저장소(Cloud Storage)
Google Cloud Storage에 대해 알아보자. object storage란 무엇인가? 이것은 데이터를 폴더 계층으로 저장하여 관리하는 file storage와는 다르다. 또한 운영체제가 disk에 덩어리(chunk)로 데이터를 저장하는 block storage와도 다르다. object storage란 여기서 저장하고, 내가 제공하는 임의의 바이트를 보관하고, 저장소에서 고유한 키를 사용하여 저장하도록 하는 것을 말한다. 이 고유한 키는 종종 URL 형태가 될 수 있는데 이것은 object storage가 웹 기술과 상호작용이 잘 이뤄진다는 것을 의미한다. 클라우드 저장소는 이런 방식으로 동작하고 완전하게 스칼라블(scalable, 확장축소시에도 난조가 없는)한 서비스이다. 즉 용량을 미리 프로바이저닝할 필요가 없다. 단지 object를 생성하면 높은 내구성과 고 가용성을 가지고 그것들을 저장할 수 있다.
클라우드 저장소의 쓰임은 다양하다. 웹사이트 컨텐츠 공급, 데이터를 압축 보관 및 복구, 엔드유저에 대용량 데이터 객체를 곧바로 다운로드 할수있게도 가능하다. 클라우드 저장소는 저장된 객체들이 각각 URL을 가지고 있기 때문에 파일 시스템이 아니다. 객체 각각은 파일과 같이 느껴지겠지만 엄밀히 파일 시스템은 아니다. 이용자는 Linux box에서 클라우드 저장소를 root 파일 시스템으로 사용하지 않는다. 대신 클라우스 저장소는 사용자가 생성하고 설정하고 storage object를 홀드하기 위해 사용하는 버킷(bucket)들로 구성된다. 이 storage object들은 불변하여 수정할수 없고 대신 새로운 버전을 생성할 수 있다. 클라우드 저장소는 항상 서버에 데이터를 디스크에 쓸 때 암호화한다. 또 기본적으로 데이터 전송시 HTTPS로 암호화 하여 전송한다.
데이터 전송에 대해 이야기 해보자. 이용자들은 클라우드 저장소에서 많은 양의 데이터를 간편하게 얻어올 수 있다. 일단 데이터가 클라우드 저장소에 존재한다면 다른 GCP의 저장소로 이동이 가능하다. 클라우드 저장소의 파일들은 버킷으로 이구성되어 있는데 버킷을 만들 때는 글로벌하게 고유한 이름을 부여하게 된다. 다음으로 버킷 및 버킷 내용이 저장되는 지리적 위치를 지정하고 기본 저장소 클래스를 선택한다. 이 때 유저에게 가장 지연이 적은 위치를 선택한다.
유저에 대해 말해보자. 객체와 버킷에 대한 접근을 제어하는 몇가지 방법이 있다. 주요한 목적은 Cloud IAM만으로는 충분하지 못하기 때문이다. Role은 프로젝트로부터 버킷, 그리고 객체에 유전된다. 보다 세밀한 조작이 필요한 경우에 ACL(Access control list)를 생성해서 이를 제어할 수 있다. ACL은 버킷과 객체에 대해 누가 접근할 수 있는지와 어떤 레벨의 접근 권한을 가지는지를 정의한다. 다음으로 객체 버저닝(versioning)라는 개념을 알아보자. 상위에 클라우드 저장소가 불변한다고 언급했다. 원한다면 버킷에 있는 객체의 버저닝 기능을 설정할 수 있다. 클라우드 저장소는 수정에 대한 이력을 보관할 수 있다. 즉, 버킷의 모든 객체는 오버라이딩 또는 삭제가 가능하고 또한 객체의 아카이브된 버전을 나열하거나, 객체를 이전 상태로 복원하거나, 필요에 따라 버전을 영구적으로 삭제가 가능하다. 만약 객체의 버저닝을 설정하지 않는경우 새로운 객체가 항상 오버라이딩한다. 또한 정크가 축적되는 것이 걱정된다면 클라우드 저장소가 제공하는 라이프사이클 관리 정책을 사용할 수 있다. 예를 들어 1년이 경과된 객체들을 삭제하게 설정할 수 있다.
클라우드 저장소(Cloud Storage) 상호작용
클라우드 저장소에는 Regional, Multi-regional, Nearline, Coldline 4가지 타입의 저장소가 존재한다. 어떻게 다른지 알아보자. Multi-regional과 Regional은 높은 퍼포먼스를 내는 객체 저장소이다. 반면에 Nearline과 Coldline은 백업과 이력을 위한 저장소이다. 모든 저장소 클래스는 cloud storage API를 사용하여 접근할 수 있다. Regional Storage는 데이터를 특정한 GCP 리전(region)에 저장한다. 예를들면 Asia East one 또는 US Central one과 같은 지역에 저장이 가능하다. 이는 Multi-regional 저장소에 비해 저렴하지만 안정성은 조금 덜하다. Multi-regional 저장소는 반면 비용은 조금 더 들지만 공급적인 안정성을 갖는다. 이것은 더 큰 범위의 지역을 선택한다. 예를드면 미국, 유럽, 아시아와 같은 지역을 선택할 수 있다. 또한 지리적으로 최소한 160키로미터 이상 떨어진 두 곳에 데이터를 저장한다. Multi-regional 저장소는 빈번하게 사용하는 데이터를 저장하는데 적합하다. 예를들어 웹 컨텐츠, 대화식 작업, 게임 데이터와 같은 데이터를 저장하기에 좋다. Regional 저장소의 경우 가상 머신 또는 쿠버네티스 엔진 클러스터와 같이 컴퓨팅 엔진과 근접한 데이터를 저장하기에 좋다.
Nearline 저장소는 가격이 저렴하고, 고도의 내구성을 요하는 서비스에서 접근 빈도가 떨어지는 데이터를 저장하기에 좋다. 이 저장소는 데이터의 읽기와 수정이 평균적으로 월 1회정도 이뤄질 때 regional 또는 Multi-regional 저장소에 비해 적합하다. 예를들어 월 1회정도의 데이터 저장과 분석이 이뤄지는 경우 Nearline 저장소가 효과적이다. Coldline 저장소는 연 1회정도의 데이터 접근이 이뤄질 경우에 가장 적절하다. Coldline은 조금은 유용성이 떨어진다. 최소 90일 이상 저장소를 유지해야하며 데이터 접근 단위 비용이 가장 비싸다. 그렇지만 Coldline의 경우 데이터 보관에 대한 비용이 가장 저렴하기 때문에 장기간 데이터를 보관하고 접근하지 않을 경우 가장 유리하다.
어떠한 데이터 저장소를 선택하는것과 무관하게 데이터를 저장소로부터 가지고 올 수 있는 다양한 방법이 존재한다. 가장 간편한 방법은 cloud SDK가 제공하는 클라우드 저장소 명령어인 gsutil을 활용하는 것이다. 또 크롬 브라우저를 사용한다면 단순히 GCP 콘솔에 데이터를 드래그앤 드랍하는 것도 가능하다. 하지만 만약 대용량(기가바이트 또는 테라바이트 단위의) 데이터를 업로드하기 위해서는 어떤 방법을 활용할 수 있을까? Google Cloud Platform은 이를 위해 온라인 스토리지 전송 서비스와 오프라인 전송 어플라이언스를 제공한다. 스토리지 전송 서비스 배치를 스케쥴링을 통해 다른 클라우드 저장소 지역 또는 HTTPS 엔드포인트의 다른 클라우드 제공자(provider)로 부터 클라우드 저장소로 이동시킬 수 있다. 전송 어플라이언스(장비)는 Google Cloud에서 임대할 수 있는 랙 가능한(rackable) 고용량의 스토리지 서버이다. 간단하게 네트워크로 연결하고 데이터와 함께 로드한 다음 데이터가 업로드 되는 장소로 전달할 수 있다. 이 서비스는 어플라이언스 하나당 1페타바이트의 데이터를 안전하게 전송할 수 있다.
이 밖에도 이 스토리지 옵션은 많은 Google 클라우드 플랫폼 제품 및 서비스와 긴밀하게 통합되므로 데이터를 클라우드 스토리지로 가져 오는 다른 방법이 있다. 예를 들어 Cloud SQL뿐만 아니라 BigQuery로부터(그리고 BigQuery로) 테이블을 가져오고 내보낼 수 있다. 그리고 App Engine 로그, 클라우드 데이터 저장소 백업, 이미지같이 App Engine 어플리케이션에서 활용된 오브젝트 및 즉시 실행 스크립트, 컴퓨터 엔진 이미지, 컴퓨트 엔진 어플리케이션에서 활용된 오브젝트까지도 저장이 가능하다. 즉, 클라우드 저장소는 클라우드로 이동되는 데이터를 위한 ingestion 포인트로 사용할 수 있고 데이터의 장기 보관장소로 활용할 수 있다.
'cloud & devops > google cloud' 카테고리의 다른 글
[GCP] Google Cloud Platform - Kubernetes, GKE (0) | 2019.10.19 |
---|---|
[GCP] Google Cloud Plaform - Container, Kubernetes, Kubernetes Engine (0) | 2019.10.18 |
[GCP] Google Cloud Plaform - Cloud Bigtable, Cloud SQL, Cloud Spanner, Cloud Datastore (0) | 2019.10.11 |
[GCP] Google Cloud Plaform - VPC, Compute Engine (0) | 2019.10.01 |
[GCP] Google Cloud Plaform - Intro (0) | 2019.09.29 |