13. Getting Started with Cloud KMS
Cloud KMS
Data States
- Data at rest: 장치에 저장되어있거나 백업
- Data in motion: 네트워크를 통해 이동 중
- Data in use: 데이터가 사용중(RAM)
Encryption(암호화)
- Symmetric Key Encryption: 암호화 복호화를 같은 키를 사용한다. -> 키의 보관, 공유에 어려움이 있음(보안상)
- Asymmetric Key Encryption: 비대칭키를 사용. 공용키로 암호화, 개인키로 복호화.
Cloud KMS
Create and manage cryptographic keys(symmetric and asymmetric)
Integrates with almost all GCP services that need data encryption:
- Google-managed key: No configuration required(GCP에서 알아서 관리)
- Customer-managed key: Use key from KMS(KMS를 통해 직접 관리)
- Customer-supplied key: Provide your own key(온프레미스에서 사용하던 키 제공)
Blcok storage, File storage
하드 디스크 저장소 타입: Block storage
동료들과 파일 공유: File Storage
Block storage
1개의 블록 스토리지는 1개의 가상 서버나 1개의 가상 컴퓨터에 연결될 수 있다.(예외: 읽기 전용 블록 스토리지는 여러 가상 서버를 부착할 수 있다.)
여러 블록 스토리지가 한 개의 서버에 연결될 수는 있다.
File storage
미디어 워크플로우 같은 경우에는 비디오 편집 같은 프로세스를 지원하기 위해 거대한 공유 저장소가 필요할 수 있다.
GCP - Block Storage and File Storage
-
Block Storage:
- Persistent Disks: Network Block Storage
- Zonal: Data replicated in one zone
- Regional: Data replicated in multiple zone
- Local SSDs: Local Block Storage
-
File Storage:
- Filestore: High performance file storage
로컬 SSD
- VM호스트에 물리적으로 연결된다.
- 따라서 낮은 대기 지연시간을 가진다. (임시 정보 저장에 유용: 캐시, 임시 데이터, 스크래치 파일 등)
- 하지만 인스턴스가 지속될 때만 유지된다.
- 자동으로 암호화 되지만 암호키를 가질 수는 없다.(구글에서 관리)
- 다른 VM인스턴스에 연결 불가능
영구 디스크
- 프로비전된 용량
- 매우 유연하다: 필요할 때마다 크기 변경 가능
- VM 인스턴스에서 분리 후 다른 VM과 연결 가능
- 가상 컴퓨터에 뭔가를 연결하거나 자신의 사용자 지정 데이터베이스를 실행하고 싶을 때 사용
Persistent Disks - Snapshots
- 영구 디스크의 시간 백업에 불과
- 스냅 샷도 스케쥴링 가능하다.(자동 삭제도 가능)
- 백업 내구성을 올릴 수 있음
- 프로젝트끼리 공유 가능
- 스냅샷 -> 이미지 -> 디스크
- 스냅샷과 스냅샷 스케쥴은 따로 생성한다. 스냅샷 설정에서 추후에 스케쥴을 선택
Machine Images
이미지는 부트 영구 디스크만 포함했었다.
머신 이미지는 VM 인스턴스로부터 만들어진 모든 것들을 포함한다.
Cloud Filestore
- Shared cloud file storage:
- Supports NFSv3 protocol
- Provisioned Capacity
- Suitable for high performance workloads:
- Up to 320TB with throughput of 16GB/s and 480K IOPS
- Support HDD and SDD
- Use cases: file share, media workflows and content management
- 구글 클라우드 엔진, 구글 쿠버네티스 엔진과 연결해서 사용 가능
Cloud Storage
-
Most popular, very flexible & inexpensive storage service
- Serverless: Autoscaling and infinite scale(저장할 양을 정할 필요가 없다. 자동으로 스케일이 조정된다. -> 서버리스)
-
Store large objects using a key-value approach (키-값으로 저장, 부분 업데이트 불가능)
-
Provides REST API to access and modify objects
- gcloud 대신에 gsutil사 사용, 클라이언트 라이브러리로 클라우드 저장소에 요청가능(C++, java, python...)
-
Store all file types - text, binary, backup & archives:
- 미디어 파일, 아카이브, 어플리케이션 패키지, 로그 등
- 데이터베이스 백업
- 온프레미스 -> 클라우드 마이그레이션
Cloud Storage - Objects and Buckets
- Objects are stored in buckets
- 먼저 버킷을 생성하고 key-value를 통해 객체를 업로드한다.
- 버킷이름은 글로벌로 유니크하다.
- url제약조건을 따른다.
- Each object is identified by a unique key
- Max object size is 5TB
Cloud Storage - Storage Classes
- 객체의 액세스 요구에 따라 비용을 최적화하도록 도와준다.(적게 사용하는 파일은 비용이 낮도록)
- Standard/Nearline storage/Coldline storage/Archive storage에서 선택이 가능하다.
Object Versioning
- 실수로 객체를 삭제했을 때 버킷에서 버전관리를 통해 이전 객체를 복원할 수 있다.
- 버킷레벨에서 가능하며 on/off 가능하다.
- 가장 최신 버전: 라이브 버전
- 비용절감을 위해 이전 버전 삭제가 필요하다.
Object Lifecycle Management
- 오랫동안 사용하지 않는 객체들을 이동(업데이트 주기가 긴 저장소 클래스)시키거나 삭제
- 클라우드 저장소를 자동화를 통해 비용을 절감시켜줌
Encryption
-
기본적으로 데이터는 서버 측에서 암호화 된다.
-
사용자가 할 수 있는 암호화에는 서버 쪽 암호화/클라이언트 쪽 암호화 2가지가 존재한다.
-
클라이언트 쪽 암호화(선택): 미리 암호화를 시킨 후에 Cloud Storage로 보냄, 따라서 구글이 알 수 있는 게 없다.
-
서버 쪽 암호화(필수): Cloud Storage에 의존해 암호화를 하는 경우
- Google-managed: Default(No configuration needed)
- Customer-managed: Keys managed by customer in Cloud KMS
- Customer-supplied: Customer supplies the keys with every GCS operation
- Cloud Storage does NOT store the key
- Customer is responsible for storing and using it when making API calls
Compliance Needs(Retention policy)
-
변하면 안되는 객체(삭제 및 수정 불가능)에 대한 규제나 규율을 지정
-
버킷을 만들 때에 설정가능하고 추후에도 가능
-
중간에 만들면 기존에 있는 객체들도 자동으로 적용된다.
-
리텐션 기간은 감소할 수 없다.(초기 설정 1달이면 수정은 그 이상만 가능)
-
모든 객체가 리텐션 기간을 벗어나기 전까지 버킷을 삭제할 수 없다.
Transferring data to cloud
- Gsutil or API: 1테라바이트 이하의 데이터를 단순 전송하는 경우
- Transfer Service: 1TB이상이거나 다른 클라우드(AWS S3, Azure...)에서 전송하는 경우
- Transfer Appliance: 전송이 일주일 이상 걸리거나 20TB이상의 데이터 전송하는 경우
Command Line - gsutil
16. Authentication in Google Cloud with Cloud IAM
IAM
- 클라우드에는 많은 리소스가 있다.
- 또한 많은 아이덴티티가 있다. (사람, 응용 프로그램)
클라우드에서 사용자를 어떻게 식별할지, 접근 가능한 리소스를 어떻게 구성하는지, 어떤 행동이 허용되는지에 대해서 구글 클라우드 플랫폼은 ID와 엑세스 관리에서 IAM을 제공
Cloud Identity and Access Management(IAM)
- Authentication(인증): 맞는 사용자인지 확인
- Authorization(권한): 맞는 액세스를 가지고 있는지 확인
- Identities(정체성): GCP User/ Group of GCP Users/ Application running in your data center/Unauthenticated users
IAM - Roles
roles: viewer인 경우 list, get이 거의 전부임
roles: owner인 경우 다양한 액션이 있음(e.g. approve, create, delete)
IAM - Policy
Roles로 권한의 조합을 만들면 바로 Identity에게 적용시키는 것이 아니라 Policy를 거쳐서 적용(Binding)
Service Accounts
VM 상에의 응용 프로그램이 GCP내의 모든 리소스에 액세스가 필요할 때마다 액세스를 제공하는 방법은 Service Account(서비스 계정)을 통해서이다.
Service Account는 email address로 식별되고 연결된 암호는 전혀 없다.
Service Account에서 자주 사용되는 두 가지 유형
- 특정 서비스에서 디폴트로 생성되는 Default service account
- 사용자가 직접 만든 User Managed
Use case
ACL(Access Control Lists)
IAM은 버킷뷰어를 주면 버킷 내의 모든 object를 확인할 수 있다. -> 특정 object만 볼 수 있도록 권한을 주려면 ACL을 사용
IAM을 우선적으로 사용하고 특정 object에 대해서만 ACL을 사용
Signed URL
구글 계정 필요없이 제한 시간동안 object에 권한을 줄 때 사용
Static website
웹사이트 이름과 버킷 이름이 같아야한다.
Database
Database - Snapshots
리전이 다운되면 해당 리전 데이터베이스를 사용할 수 없게 된다 -> snapshot
하지만 스냅샷을 찍으면 느려질 수 있음, 1시간 단위로 스냅샷을 찍기 때문에 1시간 데이터는 손실됨
Database - Standby
동기화 데이터베이스를 구축함
Database Terminology: RTO and RPO
How do we measure how quickly we can recover from failure?
- RPO(Recovery Point Objective): Maximum acceptable period of data loss
- RTO(Recovery Time Objective): Maximum acceptable downtime
즉 RTO는 몇 분만에 다시 복구시킬 수 있는지, RPO는 스냅샷을 몇 시간 배치로 찍는지
Relational Databases
- Predefined schema with tables and relationships
Relational Database - OLTP(Online Transaction Processing)
Applications where large number of users make large number of small transactions(small data reads, updates and deletes)
온라인 거래 처리
많은 사람이 작은 거래를 이용 (ex.은행 거래)
-
Use cases: Most traditional applications, ERP, CRM, e-commerce, banking applications
-
Popular databases: MySQL, Oracle, SQL Server etc
-
Recommended Google Managed Services
- Cloud SQL: Support PostgreSQL, MySQL, and SQL Server for regional relational databases (upto a few TBs)
- Cloud Spanner: Unlimited scale(multiple PBs) and 99.999% availability for global applications with horizontal scaling
Relational Database - OLAP(Online Analytics Processing)
Applicaions allowing users to analyze petabytes of data
Example: Reporting applicaions, Data warehouses, Business intelligence applications, Analytics systems
- Recommended GCP Managed Service
- BigQuery: Petabye-scale distributed data warehouse
OLAP vs OLTP
-
OLAP and OLTP use similar data structures
-
But very different approach in how data is stored
-
OLTP databases use row storage
- 각 테이블은 행별로 저장된다.
- 작은 거래를 처리하는데 아주 효율적이다.
-
OLAP databases use columnar storage
- 각 테이블은 열별로 저장소를 사용한다.
- 압축력이 높다. - 각 열에는 비슷한 데이터가 저장되기 때문
- 데이터를 훨씬 쉽게 배포할 수 있다. - 클러스터 사용 가능(across multiple nodes)
NoSQL Databases
New approach to building your databases
- No SQL = not only SQL
- Flexible schema
- Structure data the way your application needs it
- Let the schema evolve with time
- Horizontally scale to petabytes of data with millions of TPS
NoSQL은 관계형보다 일관성이 강하지 않다. 대부분은 SQL을 지원하지 않고 확장성과 고성능을 달성하기 위해 이것을 서로 교환한다.
- Recommended GCP Managed Service
- Cloud Firestore(Datastore)
- Cloud BigTable
Cloud Firestore(Datastore) vs Cloud BigTable
-
Cloud Datastore: Managed serverless NoSQL document database
- ACID 트랜잭션, SQL-like queries, indexes 제공
-
Cloud BigTable: Managed, scalable NoSQL wide column database
- Not serverless(You need to create instances)
- Recommend for data size > 10 Teradyte to several Petabytes
- 큰 분석, 운영에서 사용
- 다중 행 트랜젝션을 지원하지 않기 때문에 트랜잭션 워크로드에선 추천되지 않음
In-memory Databases
- 메모리에서 데이터를 가져오는 것은 디스크에서 가져오는 것보다 훨씬 빠르다.
- 지연 시간을 줄임
- 캐시나 세션 관리에 사용
- Recommended GCP Managed Service
Cloud SQL
-
완전히 관리되는 관계형 데이터베이스 서비스
-
MySQL, PostgreSQL, SQL Server 제공
-
Regional Service이며 고가용성 제공(99.95%)
-
SSD, HDD로 사용 가능
-
416dml RAM, 30TB의 데이터 저장소
-
증가하는 데이터가 있는 어플리케이션, 글로벌, 큰 데이터 양에는 Cloud Spanner 사용(매우 비쌈)
Cloud SQL - Features
- 자동 암호화(tables/backups)
- 고가용성/실패조치
- 읽기 작업을 위한 읽기 복제본을 만들 수 있다.
- 가동 중지 시간 없이 저장소 증가가 자동으로 가능하다.
- 특정 시점까지 회복할 수 있다.
Cloud SQL Best PracticesA
Cloud Spanner
- 완전히 관리되고, 관계형 데이터베이스이며, global제공, 매우 고가용성(99.999%)
- 중요 관계형 워크로드가 있다면 클라우드 스패너 사용.
- 읽고 쓰기를 수평으로 확장.
Cloud Datastore and Firestore
Datastore: Highly scalable NoSQL Document Database
- 자동으로 스케일과 파티션이 늘어남
- 트랜잭션, 인덱스, GQL을 지원함
- 유연한 스키마가 필요
- Kind > Entitiy
Cloud BigTable
- Petabyte scale, wide column NoSQL DB(HBase API compatible)
- 방대한 양의 분석을 위해 만들어짐(IOT 스트림, 분석, 시계열 etc)
- 단일 행 트랜잭션만 제공
- NOT serverless: You need to create a server instance(Use SSD or HDD)
- 인스턴스를 만든 후에 테이블을 만들어야 함
- 다중 노드에서 수평으로 확장할 수 있다. 빅테이블 클러스터에 여러 개의 노드를 추가할 수 있고 가동 중지 시간 없이 자동으로 클러스터 크기 조정을 할 수 있다.
- CANNOT export data using cloud console or gcloud: 자바를 사용해야함, HBase command 사용가능
빅테이블은 Wide Column Database이다.
각 테이블은 key/value map으로 정렬되어있다. 컬럼 패밀리, 컬럼 이름으로 접근 가능
빅테이블은 IOT데이터나 시계열 데이터 분석에 유용하다.
클러스터를 만들 때마다 노드의 수를 결정해야 한다.
Design Cloud BigTable