[컴] Google cloud platform (GCP) 난잡 정리

google cloud platform



Google cloud platform (GCP) 난잡 정리

구글의 가격정책

  • 서버를 오래 띄워놓으면 할인율이 커진다.
  • vcpu 단위로 계약 한다. / vcpu 단위로 commit 을 매입?
  • preemptive use 에 대한 할인??
  • hour 단위보다 낮은 단위 , 분, 초 에 대한 과금도 가능

billing 정보 분석

  • Billing 정보를 BigQuery 로 export 로 받아 놓으면, 쿼리 를 통해서 정보를 자세하게 뽑아낼 수 있다.

BigQuery(빅쿼리) 과금

  • 읽어드리는 데이터 의 용량으로 과금이 된다.
  • select join 등 할 때 사용하는 데이터 의 양이 크면 큰돈
  • 슬롯 정액제 , 특정 슬롯을 구매하고, 그 안에서 계속 사용 가능

과금

  • GCP 는 나가는 traffic 에 대한 비용에 대해 과금한다. (서버에서 나가는)
  • 대륙간 region 을 이동하는 packet 에 대한 과금도 한다.(리전을 넘어가지 않는한 과금을 하지는 않는다.)
과금종류
  • Per-second billing
  • sustained use discounts
  • committed use discounts

Quota 이슈

  • 서비스 릴리즈 전에 quota 관련 test 필요
  • https://bespinglobal.qwiklabs.com/
    • 여기에서 구글 클라우드 관리 할 수 있게 이 베스핀 애들이 만들어 놨다고 함

quota 종류

  1. 확장 불가능한 qutoa
  2. 요청하면 확장을 할 수 있는 quota

google cloud platform 제품 및 서비스

vm instance

  • startup script 를 bucket 에 올려서 instance 를 띄울때마다 원하는 script 을 실행하게 할 수 있다.

GCP 접속 방법

  • Cloud platform Console
  • Cloud Shell and Cloud SDK (shell 은 GCP 접속하면 기본으로 하나 제공됨,CLI)
    • 보안 이슈로 막아야 하는 케이스 들이 있다 고 함...
  • Cloud Console Mobile App
  • Rest-based API

GCP 계층 구조

  • https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy?hl=ko
  • 베스핀 글로벌 사이트 에서 왼쪽 위 리스트에서 확인가능
  • 모든 리소스는 프로젝트 에 종속된다.
  • organization 아래 organization 은 불가능
  • 권한(IAM, 정책)은 상속된다. 상위 계층에 권한을 주면, 하위 구조에도 영향이 미친다
  • IAM 은 여러개의 permission 을 갖는 개체 , Role 이라 부르는 듯
    • predefined role 들이 존재한다. 이것을 수정해서 자신의 롤을 만들어도 된다.(primitive, predefined, cutom role 이 가능)

서비스 계정 Service Account

  • application 이 gcp 에 접근 하기 위한 계정(apache 의 nobody 계정 같은 느낌)
  • project 내에서 만들어진다.
  • 계층 구조에 있는 상속 이 동작하기 때문에, 프로젝트 위 폴더에서 사용하도록 서비스 계정 을 만들 수 있다???
  • 하지만 편리하게 관리하는 것은 프로젝트 별로 관리하는 것이 낫다?
  • 이건 그냥 auth key 같은 녀석인듯?

VPC

  • VPC 존재 , 아마존이랑 비슷한듯
  • VPC 는 하나의 LAN 이라고 보면 된다.
  • 여러 region 을 하나의 VPC 을 생성할 수 있다.
  • shared VPC 형식으로 네트워크 A 와 네트워크 B 사이에 A와 B 가 공유하는 네트워크 C 를 만들어 쓰기도 한다???

vm instance

리전 Region

  • 모든 리전에서 high-cpu 가 제공되진 않는다.?
  • 일본 홍콩이 비등 , 밀리세컨드 차이
    • 일본 : 도쿄, 오사카
    • 홍콩 : 레이턴시 가 제일 작다
  • 대만 : 동아시아 쪽 데이터 센터 규모 최고
  • 서울 리전은 내년초(2020) 에 계획되어 있다. 어느 레벨 까지 올지 모르겠음

HW 하드웨어

  • standard, SSD, local SSD 가 있는데,
  • local SSD 는 cache 로만 제공한다.
  • 동일단가 대비 disk 성능이 좋다
  • 용량을 늘리면 성능이 올라간다.
  • SSD 는 타사 대비 2배 ?

preemptible instance

  • 이녀석은 매우 저렴
  • preemptible instance 는 24시간 이후에 자동으로 삭제
  • 이녀석은 주위에 instance가 필요하면 가져가 버린다.
  • OS 에서 preemption 을 하는 것처럼 instance 가 GCP 에 의해 preemption 이 가능한 듯 하다. 그래서 구글 맘대로 가져가 버리고, 우리가 그것을 계속 차지 하고 있지 못한다.
  • 항상 ready 해야 하지 않고, 빠른 응답이 중요하지 않은 경우 쓰면 좋을 듯

migration

  • instance 는 짧게는 일주일 길게는 한달에 한번 migration 이 구글에 의해 일어난다.
  • gpu instance 를 활용해서 머신러닝 하는게 제일 저렴
  • gpu instance 는 live migration 시점에 서버를 내린다.(하드웨어 종속성이 커서 그렇다)
  • 다른 instance 는 그저 알람 하나를 주는 정도다.

load balancer

proxy

앞단에 google front engine 에 존재(gfe 가 proxy역할), 단일 ip 를 물고 있다.
proxy 기반 load balancer
  • global https
  • global ssl proxy
  • global tcp proxy

regional

도쿄 리전 을 만들고 리전에 위치한 프론트가 그 트래픽을 받아준다. 프록시를 통하지 않는다. 클라이언트 아이피가 직접 도달한다.
DSR 형태로 동작
그래서 리저널은 그냥 라우팅만 해주는 정도이다.(TCP/UDP 단에서 라우팅) 성능 저하가 없다.
특정한 정책을 넣거나, 자동 모니터 등을 제공하진 않는다.
  • regional
  • regional internal : 내부 L4 switch 라고 보면 된다.

DNS

  • 클라우드 DNS
  • internal dns service 도 제공

CDN

  • 대용량 스트리밍 관련 CDN도 제공
  • 백엔드로 붙일 수 있는게, global load balancer 에 대해서만 CDN활성화 가능
  • 버킷에 올라가 있는 것만 가능??
  • 타사대비 가격 경쟁력이 있다고 한다??

interconnect option , vpn

회사 내부 망과 gcp 와의 통신을 위한 여러 interconnect option 을 제공
특정 아이피에서 접속할 때 gcp에 접근할 때 빠르게 해준다.
  • direct peering: 구글이 직접 라우팅
  • carrier peering : 망사업자를 통해 지원 ?
서울 리전 이 들어오고 나야 가능? 하다고 함.
  • dedicated interconncet : 구글 데이터 센터에 직접 전용선을 붙이는 것, 데이터 센터가 인접할 수록 유리
  • partner interconnect : ISP 나 망사업자 를 통하는 방식

GCP web page 에서 instance 에 있는 ssh 버튼 으로 접속시

자세한 내용은 찾아봐야 할 듯
  • 구글의 ssh proxy 를 이용해서
  • 접속 하면서, 그때 키를 받아서 메타데이터를 업데이트 해서 접속?

클라우드 스토리지 Cloud Storage

  • 초당 수만번의 파일을 쓰거나 읽거나, 급격한 요청이 들어오면, 약간의 delay 가 발생할 수 있지만, - 실서버에서 큰 이슈가 된 적은 없다.
  • 퍼포먼스에서 문제는 없다.
  • 스토리지 레벨의 암호화는 되고 있다. 암호화를 할 때 별도의 키 를 세팅할 수 있다.
  • 대량의 데이터를 올릴 때는 그냥 데이터 센터에 보내면 자기내 들이 올리는 서비스 도 제공해 준다.
  • 클라우드 스토리지 파일들은 bucket 으로 구성된다.

Storage class

  • 멀티 리저널(multi regional), 리저널, Nearline, Coldline
  • 리저널은 차이가 없다.
백업용
  • Nearline, Coldline 은 저장용으로 적당
    • Nearline 은 한달에 한번 쓸때
    • Coldline 은 사고날때 쓰는 용도
  • 저장용량당 비용이 싸다. 대신 한번에 읽기 쓰기 할 때의 비용이 비싸다.

클라우드 SQL

  • MySQL, PostgresSQL 만 제공

Cloud BigTable

  • Cloud BigTable 은 NoSQL 에 의해 managed 된다.
  • 대량 처리에 특화된다.
  • 대량의 데이터 insert , select
  • 키 기반으로 빠른 결과 얻을 때
  • HBase API
  • instance 를 많이 늘릴 수록 빨라진다.
  • 클러스터의 노드 수가 많아 질 수록 속도가 올라간다.(반응성이 좋아진단 소린가?)

cloud spanner

  • 국내 게임사는 아직 선택 안했다.
  • 많이 비싸다
  • 자동 복사 가 가능
  • horizontally scalable RDBMS
  • global consistency 를 보장
  • 해외사례는 있지만, 국내 사례는 없다.

BigQuery

  • 대량의 데이터에 대한 query 등, 데이터 사이언스 쪽에서 필요
  • 다루는 data 양에 따라 과금된다. 결과가 아니라 과정에서 사용되는 data 양

Google Container Registry

  • 사설 컨테이너 저장소 를 제공해준다.

cloud source repository

  • 사설 git
  • 사용용량에 따라 가격

google kubernetes engine

  • 쿠버네티스 엔진 을 이용해서 구글에서 만든 컨테이너 만이 아니라, 로컬에 구성된 컨테이너도 같이 관리 할 수 있는 서비스를 제공을 시작했다.
  • gke 에서는 칼리코(Calico) 를 사용 하고 있다.
현재 클라우드의 인스턴스는 가격 이 중요한 차별점이다. 그래서 인스턴스에 대해서 차별화 에 대한 고민을 하지 않는다. 장애율만 낮으면 된다.
그래서 구글은 쿠버네티스 와 빅데이터 쪽을 차별화 하려하고 있다.

google app engine

  1. standard app engine
    • 자동 scaling
    • local file system 못 쓴다.
    • request 의 timeout 이 1분 (무조건)
    • 3rd party library 설치 제약
    • 신속한 auto scaling
    • flexible 보다 이게 더 비쌈
  2. flexible environment
    • instance 를 우리가 정하고, 여기에 node 를 띄울 수 있다.
    • instance 에 ssh 접속을 허용
    • auto scaling 이 빠르게 되지 않는다. (상당히 느리다)

Cloud Functions

  • aws lambda 같은 것
  • 사용된 computing 정도에 따라 가격

가능한 trigger

  • http request
  • 특정파일이 생길때 : log 가 발생할때 등
  • ...

Deployment Manager

  • instance 배포 등, 인프라 매니지먼트 서비스
  • .yaml 하나 만들어놓고, 한번에 deploy 하는 것
  • terraform 비슷한 서비스
  • api 도 제공

Stack Driver

  • 모니터링
  • 로깅
2개 를 위해 주로 사용
  • 디버그
  • 에러 리포팅
  • 트레이스
  • 프로파일링
에도 사용
  • 로그 저장소로 보면 된다.
  • 임계치가 넘으면 알람을 받을 수 있다.
  • 개인 로그등도 stack driver 로 보내서 모니터링을 할 수 있다.
  • 메트릭은 6주, 로그는 400일, 개인이 개인적으로 쌓은 로그는 1개월 보관
  • 특정 로그들을 받아서 필터링 해서 바로 원하는 곳으로 보낼 수 없다.

사용

pub /sub 에서 받아서 dataflow 에서 처리하고 big query 에 저장하는 식으로 사용

댓글 없음:

댓글 쓰기