GCP 용어 정리

20.03.31 Google Cloud OnBoard 강의 내용을 기반으로 정리했습니다.
Instructor - Google Cloud APAC 박기택님

서버의 발전 동향

기존과 이후의 기술 발전

기존의 기술

물리적 서버

 

1. 유틸리제이션 문제가 컸다!

• 사용자가 가장 많을 때를 가정하고 서버 유지
• 평균적으로 서버의 5% ~ 10%밖에 사용하지 않음

2. 관리가 귀찮았다.

• 24시간 주 7일 서버실을 운영해 귀찮은 작업이 많았음

가상화의 등장

 

1. 물리적인 서버 + 운영체제 2~3개 + 어플리케이션 분리

• 서버를 효율적으로 사용해 유틸리제이션을 해결했다.
• 전문적으로 관리해주는 회사가 등장한다!

하지만 여전히 관리가 귀찮고 유틸리제이션이 크게 개선되지 않았음

 

 

서버리스의 등장

 

서버가 없는게 아니라 사용자 입장에서 보이지 않고 그저 사용만 하는 것

 

GCP 제품 중 BigQuery를 예로 이해해보자.

 

GCP에서 BigQuery 코드 예시

standardsql(시퀄)예시

SELECT FROM WHERE로 400GB정도를 처리하는데 7.7초가 걸렸다.

 

놀라야할 포인트

1. 굉장히 빨리 처리를 하였음!

2. 하드웨어에 대한 고려를 전혀 하지 않았음!(CPU, 메모리 등)

 

클라우드를 사용하면

• 서버를 구매하거나 CPU를 추가로 구매하는 등의 복잡한 일을 대신해둔다.
• 최대 1000개 정도의 VM이 실행되어 처리해줌

우리회사는 그렇게 큰 데이터를 다루지 않는데요?
4차 산업혁명에 따라 IT 자원이 증가해 거의 모든 회사에서 필요할 것이라고 생각한다!

 

클라우드 개념에 오해
하나의 HW 또는 SW라고 생각할 수 있는데 수많은 제품들이 있기 때문에
데이터 파이프라인을 만들거나 블록을 조립하듯 만들 수 있다!

 

1. GCP의 특징

• 고객 상황에 알맞은 서비스를 제공하는 GCP 컴퓨팅 아키텍처

   

  

  GCP 컴퓨팅 아키텍쳐

• 전세계 134개의 접속 지점과 13개의 해저 케이블에 투자했다
  전 세계적인 서비스에 GCP는 적합하다.
• GCP의 구성은 Region과 Zone으로 구성되어있다.
  멀티 리전 : 미국 - 한국
  리전 : europe-west2
  Zone : europe-west2-a, europe-west2-b, europe-west2-c

영역(Zone)

하나의 독립적인 서버가 존재하는 위치(데이터 센터)

 

리전(Region)

3개의 영역(zone)을 묶어 놓은 것

 

PoP

네트워크 상호간 또는 개별 네트워크에 대한 접속점 또는 접근점

GCP의 24개 Rigion과 134개의 PoP

전 세계에 24개의 리전이 존재한다.

서울에도 2020년 초에 3개의 zone이 위치한 region이 들어왔다!

[asia-northeast3]가 서울 region이다

 

• google은 환경보호에 앞장선다.
  • 2007년부터 탄소 중립성 100%를 유지하고있다.
  • 전세계적으로 재생 에너지를 가장 많이 구매하는 기업 중 하나이다.
  • ISO 14001 인증을 획득한 가장 최초의 데이터 센서이다.
• Google은 고객에게 유리한 가격 조건을 제시한다.
  
  • 분단위 증가분 결제 - 컴퓨팅, 데이터 처리, 기타 서비스
  • 지속 사용 할인 - 가상 머신을 한달에 25%이상 사용하는 경우 자동으로 적용
  • 약정 사용 할인 - 장기간 워크로드가 꾸준할 경우 비용 할인
  • 선점형 사용 할인 - 일시 중단될 수 있는 워크로드에 대한 비용 할인
  • 커스텀 VM 인스턴스 유형 - 애플리케이션에 필요한 리소스에만 지불
• 개방형 API 및 오픈소스

  

• 보안

  

• GCP의 서비스

  

  GCP는 100개 넘는 제품이 있다.

• 데이터에서 가치를 찾아내는 서비스를 제공하는컨 크게 4가지다!
  
  1. Compute
  2. Storage
  3. Big Data
  4. Machine Learning

2. CGP 리소스 계층 구조

만약 회사에서 GCP를 사용한다고 가정하면 organization(회사)을 만들어드리고 프로젝트를 관리 할 수 있게 해준다!

 

2-1. 리소스 계층 구조 수준에 따라 신뢰 경계정의

• 조직 구조에 따라 리소스를 그룹화
• 계층 구조 수준에 따라 신뢰 경계 및 리소스 격리가 설정

2-2. 모든 GCP 서비스는 프로젝트와 연결

• 리소스 및 할당량 사용량 추적
• 결제를 사용설정
• 권한 및 사용자 인증 정보를 관리
• 서비스 및 API를 사용 설정

2-3. 프로젝트에 사용되는 3가지 식별 속성

프로젝트 ID전역에서 고유사용자가 선택변경 불가능

프로젝트 ID	전역에서 고유	사용자가 선택	변경 불가능
프로젝트 이름	고유할 필요 없음	사용자가 선택	변경 불가능
프로젝트 번호	전역에서 고유	GCP 에서 선택	변경 불가능

2-4. GCP의 폴더관리

• 폴더로 한 조직내의 여러 프로젝트를 그룹화 할 수 있다.
• 폴더에는 프로젝트나 다른 폴더 또는 이 두가지가 모두 포함될 수 있다.
• 폴더를 사용해 정책을 할당할 수 있다.

2-5. 조직노드로 프로젝트 정리

2-6. IAM 리소스 계층 구조 예시

• 정책이 리소스에 설정 : 각 정책은 역할 및 역할 구성원 집합을 명시
• 상위 정책이 리소스에 상속 : 리소스 정책은 상위 리소스와 현재 리소스의 합집합 이다.
• 덜 제한적인 상위정책이 더 제한적인 리소스 정책을 재 정의

3. Identity and Access Management (IAM)

3-1. GCP IAM에서 정의하는 요소 3가지

• 누가
  
  1. Google 계정 Cloud ID 사용자 : test@gamil.com , test@example.com
  2. 서비스 계정 : test@project_id.iam.gserviceaccount.com
  3. google 그룹 : test@googlegroups.com
  4. cloudID 또는 G Suite 도메인 : example.com
• 무엇을
  IAM의 역할은 관련된 권한의 모음이다. 서비스 리소스 등에 대해 인스턴스 관리자 역할을 한다.
• 어느 리소스에
  계층 구조의 특정 항목에 대한 역할을 부여받은 사용자가 IAM이다.

 3-2. IAM의 3가지 역할

• 기본 역할
  
  • 프로젝트의 모든 GCP 서비스에 적용된다. [모든 리소스에]
  • 세분화 되지 않은 고정된 액세스 수준을 제공한다.

    소유자	구성원 초대 / 구성원 삭제 / 프로젝트 삭제 / 기타 ...
    편집자	애플리케이션 배포 / 코드 수정 / 서비스 구성 / 기타 ...
    뷰어	읽기 전용 액세스
    결제 관리자	결제 관리 / 관리자 추가 및 삭제

    한 프로젝트에 여러 소유자, 편집자, 뷰어, 결제 관리자가 있을 수 있다.

• 사전정의 역할
  
  • 프로젝트의 모든 GCP 서비스에 적용된다. [이 프로젝트, 폴더 or 조직의 Gompute Engine 리소스에]
  • 특정 서비스에 보다 세분화된 권한을 제공한다.

    

• 커스텀 역할
  
  • IAM 커스텀 역할 권한 집합을 정확하게 정의할 수 있다.

3-3. 서비스 계정

• 프로젝트에서 서버간 상호작용에 사용되는 ID 제공
• 서비스간 인증에 사용
• 리소스에서 사용하는 권한을 제어하는데 사용 : 이를 통해 애플리케이션이 인증된 최종 사용자 대신 작업을 수행할 수 있음
• 이메일 주소로 식별
  PROJECT_NUMBER-compute@developer.gserviceaccount.com
  PROJECT_ID@appspot.gserviceaccount.com
• 서비스 계정과 IAM
  • 키를 사용해 서비스 계정에 인증 : google에서 Compute Engine 및 App Engine의 키 관리
  • 서비스 계정에 사전 정의 또는 커스텀 IAM 역할 할당 가능

4. Cloud ID

• 무엇으로 GCP 관리 사용자를 관리하나요?
  
  • Gmail 계정 및 Google 그룹스
  • G Suite 도메인의 사용자 및 그룹
  • Cloud ID 도메인의 사용자 및 그룹
• 다른 기업 디렉터리가 있는 경우

5. Google Cloud Platform 과의 상호작용

GCP를 사용하는 4가지 방법

우리가 실습할 퀵랩은 실습 환경을 제공해준다!

 

5-1. GCP와 상호작용하는 4가지 방법

• Cloud Platform Console : 웹 사용자 인터페이스
  
  • 모든 프로젝트 데이터에 대한 중앙 관리형 콘솔
  • 개발자 도구 : Cloud Sourc Repositories (github 같은 것), Cloud shell, Test Lab (모바일 앱 테스트)
  • 제품 API에 액세스
  • 프로젝트 관리 및 생성
• Cloud Shell 및 Cloud SDK : 명령줄 인터페이스
  
  • SDK에 Cloud Platfrom 제품 및 서비스를 위한 CLI 도구 포함 : gcloud, gwutil(Cloud Storage), bq(BigQuery)
  • Docker 이미지로 제공
  • Cloud Shell을 통해 제공 : Compute Engine 인스턴스에서 실행되는 Cloud SDK의 컨테이너형 버전
• Cloud Console Mobile App : iOS및 Android
  
  • 가상 머신 및 데이터베이스 인스턴스 관리
  • Google App Engine에서 앱 관리
  • 결제 관리
  • 맞춤 설정 가능한 대시보드로 프로젝트 시각화
• REST 기반 API : 커스텀 애플리케이션
  
  • 제품 및 서비스에 프로그래매틱 액세스 : 일반적으로 JSON을 교환방식으로 사용 , 인증 및 승인에 OAuth 2.0 사용
  • Google Cloud Platform Console을 통해 사용 설정
  • 지출을 관리할 수 있도록 대부분의 API에 일일 할당량 및 요금(한도)이 적용됨 : 요청에 따라 할당 및 요금 상향 조정 가능

5-2. API 탐색기

 

• 브라우저를 사용하여 간편하게 Google API를 사용해볼 수 있는 대화형 도구
• 사용가능한 API 및 버전을 신속하게 탐색
• 각 API에서 사용 가능한 메서드 및 지원되는 매개 변수를 인라인 문서로 확인
• 실시간으로 메서드 요청을 실행하고 응답 확인
• 손쉽게 인증 및 승인된 API 호출 작성

5-3. Cloud 클라이언트 라이브러리

 

• 커뮤니티에서 소유하며 직접 개발한 클라이언트 라이브러리
• 예시 : Google API 클라이언트 라이브러리
  • 오픈 소스, 자동 생성, 다양한 언어 지원
    (Java, Python, Javascript, PHP, .NET, GO, Node.js, Ruby, Objective-C, Dart)

 

가상머신

6. VPC(Virtual Private Cloud) 네트워크

• 기존의 레거시와 다르게 하나의 라우터를 기반으로 전세계 컴퓨터를 하나의 네트워크로 연결 가능!

• 물리적으로는 멀어도 논리적으로는 하나의 네트워크를 만들 수 있음
  • 기존의 전통적인 네트워크에서는 불가능!
  • 앞서 설명한 케이블과 VM을 이용해서 Google VPC를 구현함
  • 기존의 인터넷선을 이용해서 external IP로 가면 라우터를 하나씩 거쳐서(하나의 홉씩) 가게돼서 느림

• 인터널 IP (VPC) 핀테스트를 해보면 세계의 노드 이하로 짧은시간안에 도착하는 것을 확인할 수 있음(유럽까지)
• VPC네트워크를 활용하면 안정적이고 빠르게 네트워크를 연결할 수 있음

이러한 네트워크를 기반으로 해서 VM을 설치할 수 있음!
고객이 서울이다 하면 서울리전으로 만들면 되고 미국이면 미국 리전에 VM을 만드는게 유리할 것 같다!

7. Compute Engine

• VM이름이 Compute Engine

• 수평확장과 수직확장이 뭘까요
• VM 하나로 서비스를 제공한다고 가정하면 (google.com이라고합시다)
  • 여러분의 고객이 몇 명 안되면 하나의 VM으로 서비스 제공이 가능함
  • 수요가 갑자기 많아지면 감당이안되겠죠?
  • 그래서 VM을 많이 만들면 수요가 없을 때는 VM공급 비용이 아깝죠
  • 그래서 자동확장(Autoscaling)기능을 제공합니다.

Clinet수에 맞게 탄력적으로 셧다운하거나 확장시켜 좋음

 

CPU 메모리 디스크

디스크에 저장했다가 메모리에 올렸다가 CPU로 왔다갔다 계산을 하는 원리가 있는데

요 아키텍쳐를 생각하면 뭔가 문제가있어요

클라이언트가 줄어들어서 스케일아웃시킬때는 고객의 데이터가 날라가겠죠?

이걸 어떻게 해결했냐면 컴퓻과 디스크를 분리시켰어요

CPU와 메모리만 셧다운 시키고 디스크와 메모리는 그대로 둡니다

 

이걸 구현하기가 엄청 힘들었어

메모리에서 CPU는 빠른데

디스크는 오래걸리죠 메모리 왔다갔다하는게

이걸 고민하다가 내린 결론이 이거였어요

스토리지랑 컴퓻 사이에

엄청많은 선을 가져다 놓았어요

 

 

8. 중요한 VPC 기능

• VCP 네트워크의 토폴로지 제어
  
  
  • 경로 테이블을 사용해 트래픽을 네트워크 안에서는 물론 서브넷 간에 전달
  • 방화벽을 사용해 네트워크 트래픽이 허용되는 항목을 제어
  • 공유 VPC를 사용해 네트워크 또는 개별 서브넷을 다른 GCP 프로젝트와 공유
  • VPC 피어링을 사용해 GCP 프로젝트의 네트워크의 상호연결
• 전역 Cloud Load Balancing으로 전 세계에 단일 프런트 엔드로 제공되는 애플리케이션
  
  
  • 사용자가 단일 글로벌 Anycast IP 주소를 사용
  • Google 백본을 통해 가장 가까운 접속 지점에서 사용자에게로 트래픽 전달
  • 부하를 기준으로 백엔드 선택
  • 정상 백엔드만 트래픽 수신
  • 가동 준비가 필요 없음
• Cloud DNS
  
  • 관리형 영역을 생성한 후 DNS 레코드를 추가, 편집, 삭제
  • RESTful API 또는 명령줄 인터페이스를 사용해 영역과 레코드를 프로그래매틱 방식으로 관리
• Cloud CDN (Content Delivery Network)
  
  
  • 전세계에 분산된 Google의 에지 캐시를 사용하여 콘텐츠를 사용자에게 가깝게 캐싱
  • 다른 CDN의 사용을 원하는 경우 CDN Interconnect 사용
• 다양한 상호 연결 옵션을 제공
  
  
  • VPN : VPN 터널을 통한 Gbps 단위의 연결 확보
  • 다이렉트 피어링 : 하이브리드 클라우드 워크로드를 위한 사용자와 Google간 비공개 연결
  • Dedicated Interconnect : Google 접속 지점에서 Google Cloud로 전달되는 프라이빗 클라우드 트래픽을 위한 N X 10G 전송 회로 연결
  • 이동통신사 피어링 : 서비스 제공업체의 대규모 파트너 네트워크를 통한 연결
  • Partner Interconnect : 지원되는 서비스 제공업체를 통한 온프레미스 네트워크 및 VPC 네트워크 간 연결
• 부하 분산 옵션 제품군을 제공하는 Google VPC

 

글로벌 HTTP(S)	글로벌 SSL 프록시	글로벌 TCP 프록시	리전	리전 내부
부하를 기준으로한 Layer 7 부하 분산	부하를 기준으로 한 HTTPS외 SSL 트래픽의 Layer 4 부하 분산	SSL외 TCP 트래픽의 Layer 4 부하 분산	모든 트래픽(TCP, UDP)의 부하 분산	VPC내 트래픽의 부하 분산
각종 URL을 다양한 백엔드에 라우팅 할 수 있음	특정 포트 번호에서 지원됨	특정 포트번호에서 지원됨	모든 포트번호에서 지원됨	다중 계층 애플리케이션의 내부 계층에 사용

9. GCP - 스토리지

10. Cloud Storage

• Cloud Storage의 특징
  
  
  • BLOB (binary large-object) 스토리지
  • 고성능 인터넷 규모 : 단순한 관리
  • 용량을 관리할 필요가 없음
  • 저장 데이터 암호화
  • 기본적으로 Google에서 엔드포인트로 전송 중인 데이터 암호화
  • 온라인 및 오프라인 가져오기 서비스 사용 가능
• Cloud Storage 파일은 버킷으로 구성
  

  

• Cloud Storage 등급 선택하기

  

• Cloud Stoarge로 데이터를 가져오는 3가지 방법
  
  
  
  • 온라인 전송 : 명령줄 도구 또는 드래그인 드롭을 사용한 자체 관리형 사본
  • Storage Transfor Service : 일정에 따른 관리형 일괄 전송
  • Transfer Appliance : 데이터를 안전하게 전송하는, 랙 장착 가능한 어플라이언스
• 다른 GCP 서비스와 함께 사용이 가능하다.
  

  

11. Cloud Bigtable

• Cloud Bigtable의 특징
  
  
  
  • 관리형 NoSQL
  • 테라바이트 규모의 애플리케이션을 위한 완전 관리형 NoSQL, 광폭 열 데이터베이스 서비스
  • HBase API로 액세스
  • 빅데이터, Hadoop 에코시스템과 기본적으로 호환
  • 복제 스토리지
  • 가동 여부와 관계없이 상시 데이터 암호화
  • 역할 기반 ACL
  • google Analytics, Gmail등의 주요 애플리케이션 실행
• Bigtable 액세스 패턴
  
  
  • Application API
    관리형 VM, HBase REST 서버, HBase 클라이언트를 사용하는 자바 서버와 같은 데이터 서비스 계층을 통해 Cloud Bigtable에서 데이터를 읽고 쓸 수 있다. 일반적으로 애플리케이션, 대시보드, 데이터 서비스에 데이터를 제공한다.
  • 스트리밍
    Cloud Dataflow Streaming, Spark Streaming, Storm과 같은 다양한 인기 스트림 처리 프레임워크를 통해 데이터를 스트리밍(이벤트별로 쓰기) 할 수 있다.
  • 일괄 처리
    Hadoop 맵 리듀스, Dataflow, Spark와 같은 일괄 프로세스를 통해 Cloud Bigtable에서 데이터를 읽고 쓸 수 있다. 요약 데이터 또는 새로 계산괸 데이터가 Cloud Bigtable 또는 다운스트림 데이터베이스에 다시 기록되는 경우가 많다.

 

12. Cloud SQL 및 Cloud Spanner

12-1. Cloud SQL

 

• Cloud SQL의 특징
  
  
  • 관리형 RDBMS
  • MySQL및 PostgreSQL 데이터베이스를 서비스로 제공
  • 자동 복제
  • 관리형 백업
  • 수직 확장 (읽기 및 쓰기)
  • 수평 확장 (읽기)
  • Google 보안
• 다른 GCP 서비스와 함께 사용 가능
  
  
  • Cloud SQL + App Engine
    표준 드라이버를 통해 Cloud SQL과 App Engine을 함께 사용할 수 있다.
    App Engine 애플리케이션을 따르도록 Cloud SQL인스턴스를 구성할 수 있다.
  • Cloud SQL + Compute Engine
    Compute Engine 인스턴스에서 외부 IP 주소를 사용하여 Cloud SQL 인스턴스에 액세스 하도록 승인할 수 있다.
    Cloud SQL 인스턴스를 선호 영역에 구성할 수 있다.
  • Cloud SQL + 외부 서비스
    Cloud SQL을 외부 애플리케이션 및 클라이언트와 함께 사용할 수 있다.
    표준 도구를 사용하여 데이터베이스를 관리할 수 있다.
    외부 읽기 복제본을 구성할 수 있다.

12-2. Cloud Spanner

 

• 수평으로 확장 가능한 RDBMS
• 자동 복제
• 강력한 전역 일관성
• 가용성이 높은 관리형 인스턴스
• SQL (ANSI 2011, 확장 포함)

13. Cloud Datastore

 

 

• 수평으로 확장 가능한 NoSQL DB
• 애플리케이션 백엔드용으로 설계된 NoSQL
• 완전 관리형 : 분산 아키텍처를 사용해 확장을 자동 관리
• 내장형 중복 기능
• ACID 트랜잭션 지원
• 스키마 없는 액세스 : 기본 데이터 구조를 고려할 필요 없음
• 로컬 개발 도구
• 무료 일일 할당량 포함
• RESTful 인터페이스를 통해 어디서나 액세스

14. 스토리지 옵션 비교

14-1. 기술 세부 정보

 Cloud DatastoreCloud StorageCloud BigtableCloud SQLCloud SpannerBigQuery

유형	NoSQL 문서	Blobstore	NoSQL 광폭 열	OLTP용 관계형 SQL	OLTP용 관계형 SQL	OLAP용 관계형 SQL
트랜잭션	O	X	단일 행	O	O	X
복잡한 쿼리	X	X	X	O	O	O
용량	TB+	PB+	PB+	10TB	PB	PB+
단위 크기	1MB/항목	-10MB/셀 -100MB/행	5TB/객체	DB엔진 결정	10.240MiB/행	10MB/행

14-2. 사용 사례

	Cloud Datastore	Cloud Storage	Cloud Bigtable	Cloud SQL	Cloud Spanner	BigQuery
유형	NoSQL 문서	Blobstore	NoSQL 광폭 열	OLTP용 관계형 SQL	OLTP용 관계형 SQL	OLAP용 관계형 SQL
권장용도	반구조화 애플리케이션 데이터, 내구성 높은 키-값 데이터	'플랫' 데이터, 집중적인 읽기 /쓰기, 이벤트, 분석 데이터	구조화 및 비구조화 바이너리 또는 객체 데이터	웹 프레임워크, 기존 애플리케이션	대규모 데이터 베이스 애플리케이션 (약 2TB이상)	대화형 쿼리, 오프라인 분석
사용사례	입문용, App Engine 애플리케이션	AdTech, 금융, IoT 데이터	이미지, 대용량 미디어 파일, 백업	사용자 인증 정보, 고객 주문	높은 I/O, 전역적인 일관성이 필요한 모든 경우	데이터 웨어하우스
단위크기	1MB/항목	-10MB/셀 -100MB/행	5TB/객체	DB엔진 결정	10.240MiB/행	10MB/행