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 종류
- 확장 불가능한 qutoa
- 요청하면 확장을 할 수 있는 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 가 제공되진 않는다.?
- 일본 홍콩이 비등 , 밀리세컨드 차이
- 일본 : 도쿄, 오사카
- 홍콩 : 레이턴시 가 제일 작다
- 대만 : 동아시아 쪽 데이터 센터 규모 최고
- 서울 리전이 들어왔다.
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
- standard app engine
- 자동 scaling
- local file system 못 쓴다.
- request 의 timeout 이 1분 (무조건)
- 3rd party library 설치 제약
- 신속한 auto scaling
- flexible 보다 이게 더 비쌈
- 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
- 모니터링
- 로깅
- 디버그
- 에러 리포팅
- 트레이스
- 프로파일링
- 로그 저장소로 보면 된다.
- 임계치가 넘으면 알람을 받을 수 있다.
- 개인 로그등도 stack driver 로 보내서 모니터링을 할 수 있다.
- 메트릭은 6주, 로그는 400일, 개인이 개인적으로 쌓은 로그는 1개월 보관
- 특정 로그들을 받아서 필터링 해서 바로 원하는 곳으로 보낼 수 없다.
댓글 없음:
댓글 쓰기