GCP Fundamentals #4 - Storage in the Cloud

 

[코스정보]

 

Cloud Engineering with Google Cloud 전문 자격증 | Coursera

GCP 데이터베이스 종류

---

Cloud Storage

cloud storage(file system 아님)

• Object Storage : 객체 저장소에 저장하면서 고유 키로 지정된 저장된 객체들을 참조할 수 있다.
• unique key : URL 형태로 제공되는데 object storage 는 그래서 웹환경에 좋다.
• scalable : 필요 할 때마다 용량을 증가 시킬 수 있다.
• 어디 쓰이는가 : 웹사이트 컨텐츠 제공, 아카이브용 데이터 저장, 재해 복구용 백업, 엔드 유저를 위한 대용량 파일 배포
• 클라우드 스토리지는 그냥 파일시스템이 아니다.
  --> 각각의 객체(objects) 들은 URL 을 가지고 있기 때문이다.
• 파일(file)이란 이름을 객체를 설명하기 위해 사용해도 되지만 여전히 파일 시스템은 아니다.
• 스토리지 오브젝트는 수정할 수 없다. 수정 대신에 새로운 버전을 만든다.
• 항상 디스크에 쓰이기 전에 서버 사이드에서 암호화 된 후 저장된다. (공짜로)
• 기본 설정으로는 HTTPS를 사용한다.
• 클라우드 스토리지에 있는 데이터 들은 다른 GCP의 스토리지 서비스로 쉽게 이전이 가능하다.
• Cloud Storage Bucket 을 만들 때 이름은 globally unique 해야 한다.
• 버켓이 위치할 지리적 위치를 설정해줘야 한다.
  --> 유저를 위해 최소한의 레이턴시를 제공하는 위치로 설정해야 한다.

버킷 속성

• 유저가 object 와 bucket에 접근할 수 있는 권한을 설정 할 수 있는데 제일 쉬운 방법은 Cloud IAM 을 쓰는 것이다.
• Cloud IAM 은 프로젝트 단위에서 역할을 받아 bucket으로 상속된다.
• ACLs (Access Control Lists) : 상세하게 buckets 과 objects 접근 권한을 define 할 수 있다.
• ACL은 두가지 정보로 이루어 진다.
  1) who can perform the specified action : 누가 특정 action을 취할 수 있는가
  2) permission which defines what action can be performed : 어떤 action을 할 수 있는가 (read / write)
• object versioning 을 켜두면 자동으로 수정 내역을 기록한다.
• 지난 버전을 영구적으로 제거하거나 복원할 수 있다.
• object versioning 을 끄면 항상 새로운 버전이 예전 버전을 덮어쓰게된다.
• object versioning이 너무 쓸때없는 버전까지 저장해서 공간이 낭비될 걱정은 하지마라, lifecycle을 정해 줄 수 있다.
  예시) 1년 이상된 object는 삭제해라, 최근 버전 3개까지는 저장.

Cloud Storage Type

• 4가지 타입을 제공한다 : Regional, Multi-regional, Neraline, Coldline
• Multi-regional , Regional : 높은 성능의 object storage
• Nearline, Coldline : 백업, 아카이브용 스토리지
• 모든 타입의 스토리지는 cloud storage api 로 접근 가능하며 millisecond access time을 가진다.
• Regional : 특정 GCP 리전에 데이터를 저장할 수 있다. Multi-regional보다 비용이 낮은 대신 적은 데이터 중복(하나의 리전에만 데이터가 저장됨)을 제공한다. (less redundancy)
  --> compute engine, virtual machines, kubernetes engine cluster 처럼 data-intensive computation 에 사용한다.
• Multi-Regional : 여러 지역에 (최소 2개 이상의 160 킬로미터 이상 떨어진 곳) 저장된다.
  --> 자주 접속이 필요한 데이터들에게 적합하다.
  --> website content, interactive workload, mobile gaming application 에 사용된다.
• Nearline storage : Regional 보다 비용이 낮고 접속 빈도가 낮은 데이터를 오랜기간 저장하는데 적합하다. (한달에 한번정도의 빈도)
• Coldline storage : 제일 비용이 낮고 데이터 데이터 아카이브와 온라인 백업, 재해 복구용으로 적합하다. (일년에 한번 정도의 빈도)
  --> 90일 duration, 데이터 접속에 따른 비용 발생
• Availability
  1) Regional : 99.9%
  2) Multi-regional : 99.95%
  3) Neraline, Coldline : 99%
• Pricing : all classes cost per gigabtye of data stored per month
  1) Multi-regional : highest
  2) Coldline : lowest, higher fee thna nearline per gigabyte of data read
  3) Nearline : incurs an access fee per gigabyte of data read

data transfer to Cloud Storge

• 데이터를 클라우드 스토리지에 옮기는 방법
  1) gsutil : cloud SDK 클라우드 스토리지 명령어
  2) GCP console 드래그 앤 드롭
  3) 큰 용량(테라, 페타바이트) GCP 가 online storage transfer service + offline transfer appliance를 도와준다.
• transfer appliance : rackable, high-capacity storage server (GCP 에서 빌린다,)
  --> 한방에 안전하게 파일을 전송할 수 있다.
  --> 아직 베타버전이다.

relate GCP Services

• cloud storage 에서 다른 GCP 서비스로 integrate 하는 방법들도 많다.
  1) BigQuery, Cloud SQL 등으로 import, export 가능
  2) App Engine log, 이미지 도 저장할 수 있다.
  3) 클라우드 백업
• 클라우드 스토리지는 startup script, cmpute Engine image, objects used by cmpute engine applications 로 생성가능하다.
• 결론 ) 클라우드 스토리지는 클라우드로 데이터를 이동하기 위한 수집 지점이고 데이터의 장기 저장 위치이다.

---

• 클라우드 스토리지는 리눅스 가상 머신의 루트 파일 시스템으론 적합하지 않다.
• 클라우드 스토리지 객체가 있는 버킷의 특징으로는 기본 저장 클래스이고, unique 한 이름이며, 지정학적 위치를 가진다.
• coldline 스토리지는 낮은 비용으로 빈번하지 않은 데이터를 저장하는데 좋다.

---

Cloud Bigtable

Bigtable

• Cloud Bigtable : NoSQL database service
• NoSQL : NoSQL schema is more flexible than RDB schema
  --> 모든 row가 같은 column을 가질 필요가 없다. (sparsely populated) - 부분적으로 채워진다.
• GCP 가 표면을 관리해 주어 따로 설정을 할 필요가 없다.
• single look up key를 가진 데이터에 가장 적합하다.
• persistent hatch table이라고 생각해도 된다.
• 큰 용량을 데이터를 적은 레이턴시로 저장하는데 적합하다.
• 높은 입출력을 속도를 지원하고 operational 과 analytical 한 작업 둘다에 좋은 선택이다.
• HBase 라는 오픈소스 API 도 지원한다.(아파치 하둡 프로젝트의 네이티브 데이터베이스)
  --> HBase 와의 이식성이 뛰어나다.

why use cloud bigtable instead of Hbase

• 그럼 Hbase 를 쓰면되지 왜 BigTable을 쓸까?
  1) scalabilty : Hbase 와 달리 빅테이블은 리소스가 더 필요하면 machine 의 수만 늘리면 된다.
  2) administration 작업 : 업그레이드나 재시작같은 관리작업을 맡아준다.
  3) enctyped : 모든 데이터는 암호화 된다.
  4) IAM 을 통해 누가 권한을 가질지 설정할 수 있다.
  5) 구글의 코어 서비스인 검색, 분석, 지도, 지메일 등에서 쓰이는 디비다.(검증됬다?)

 

access pattern

• GCP환경의 일부로써 빅테이블은 다른 GCP 서비스들과 서드 파티 클라이언트와 상호작용이 가능하다.
• 어플리케이션 API 관점에서 볼때 빅테이블 데이터 들은 VM 이나 Hbase rest server, Hbase 클라이언트를 쓰는 java server 같은 데이터 서비스 레이어를 통해 read/write 될 수 있다.
• Cloud Dataflow Streaming, Spark Streaming, Storm 과 같은 프레임 워크를 통해 스트림 될 수도 있다.
• Hadoop map reduce, dataflow, spark 와 같은 batch 프로세스들을 통해 read/write 될 수 있다.

---

• 클라우드 빅테이블은 NoSQL 디비이고, NoSQL 은 데이터를 저장할 때 스키마를 강요하지 않는다.
• persistent hashTable 로 볼 수 도 있는데 특정 key를 가지고 데이터를 찾을 수 있기 때문이다.

---

Cloud SQL and Cloud Spanner

cloud sql

• RDB가 하는 역할에는 데이터 일관성도 있지만 transaction의 기능도 있다.
• transaction : 전부 바뀌거나 하나도 바뀌지 않거나
• RDB 는 세팅, 유지보수, 관리가 필요한데 이런 작업들을 쉽게 하고 보안에도 신경쓰고 싶다면 Cloud SQL 을 써라!
• MySQL 과 PostgreSQL 중 선택 할 수 있다.
• 둘다 베타이긴 하다.

 

cloud sql

• compute engine 안에 디비를 설치하여 쓰기도 하는데 왜 Cloud SQL 을 써야하지?
  
  1) read, failover 등등 위한 replica service를 제공한다.
  --> 자동으로 디비의 복제본을 multiple zone 에 만들어 서비스 한다.
  
  2) on-demand 나 scheduled back up을 지원한다.
  
  3) 수직(디비 타입), 수평(디비 갯수) 의 확장을 지원한다.
  
  4) 보안의 관점에서 Cloud SQL 인스턴스는 네트워크 방화벽을 포함한다. 데이터는 모든 과정에서 암호화 되어 전달된다.
  
  5) GCP 서비스와 다른 외부 서비스로 부터의 접근성이 좋다.
  --> compute engine에게 접속 권학을 줄 수 도 있다.
  
  6) SQL work bench와 같은 툴도제공한다.

 

cloud spanner

• Cloud SQL보다 좋은 scaleability가 필요하면 Cloud Spanner 을 사용해라
• transactional consisteny 지원한다.
• petabytes 의 용량을 지원한다.
• RDB인데 transaction consistency 와 global data and strong consistency 와 그냥 일반적인 케이스 때 Cloud spanner 를 쓰면 된다.

---

• Cloud Spanner 는 Cloud SQL 보다 높은 scaleability를 제공한다.
• Cloud SQL 은 MySQL 과 PostgreSQL 을 지원한다.
• Cloud Spanner 는 global scale 에서 transactional consistency를 제공한다.

---

Cloud Datastore

cloud Datastore

• 백엔드를 위한 NoSQL 디비이다.
• fully-managed-service 이다 : sharding, replication, 고가용성, auto scale 지원한다
• cloud bigtable 과 다르게 multiple database row transaction을 지원한다.

cloud datastore 의 장점

• 매일 한정된 작업이 공짜로 주어진다.
• sql query 같은 코드를 사용한다.

---

• 클라우드 빅테이블과 클라우드 데이터스토어는 둘다 확장성이 뛰어나며 NoSQL 형태의 데이터 베이스이다.
• 데이터 스토어는 매일 무료 quota 가 있으며 sql 쿼리문과 비슷한 코드를 사용한다.
• 클라우드 데이터 스토어는 앱 엔진과 컴퓨트 엔진 애플리케이션으로 확장될  수 있다.

---

Comparing storage options

비교 : 기술적 상세

• Cloud datastore : unstructured objects , transactions support, SQL-like queries 
  --> 테라바이트 단위까지 지원하며 엔티티 하나당 1 메가바이트의 unit size를 지원한다.
• Cloud bigtable : large amount of structured objects.
  --> 페타바이트 단위의 용량과 엔티티 하나당 10 메가바이트의 unit size와 row 당 100메가바이트의 용량을 지원한다.
• Clout Storage : 바뀌지 않는 10메가바이트 이상의 이미지나 동영상을 저장할 때 사용
  --> 페타바이트 단위의 용량과 객체 하나당 최대 5테라바이트의 용량을 지원한다.
• Cloud SQL : online transaction processing system 을 위한 SQL support 가 필요할 때
  --> 테라바이트 단위의 용량을 지원하며 복제본이 아닌 확장본이 필요할 경우 cloud spanner 을 쓰면 된다.
• Cloud Spanner : online transaction processing system 을 위한 SQL support 가 필요할 때, scaleability 가 필요할때
• BIgQuery : 빅데이터 분석과 interactive query 과 capabilities 를 위해 사용한다.

비교 : 실사용

• Cloud datastore : semi-structured application data that is used in app engine application
• Cloud bigtable : analytical data, heavy read/write event like AdTech, Financial, IoT data
• Clout Storage : structured and unstructured, binary or object data, image, large media files, backups
• Cloud SQL : web framworks, exsiting applications, storing user credentials and customer orders
• Cloud Spanner : large scale db applicatios (larger than two terabytes), finalcial trading, e-commerce
• BIgQuery : 빅데이터 분석과 interactive query 과 capabilities 를 위해 사용한다.

---

실습

Sign in | Qwiklabs

• 대용량 비디오 파일을 transcode 하는 어플리케이션을 위한 디비 : Cloud Storage
• 센서가 있는 디바이스를 통해 큰 데이터 흐름을 받아오기 위한 디비 : Cloud Bigtable
• Cloud Storage : immutable, new version overwrite, versioning
• free trails 가 있는 디비 : Cloud Datastore
• Nearline 과 Coldline 특징 : 데이터 들고올 때 비용이 발생한다, 저장 비용은 낮다.
• MySQL 처럼 쓸수 있는 RDB : Cloud SQL
• Strong transactional consistency, seamless scaling : Cloud Spanner
• ingestion point of data moved into Cloud, frequently long-term storage : Cloud Storage

---