View
요즘 Public Cloud Provider들의 경쟁 열기가 뜨거운 것 같다. AWS가 독보적인 서비스 제공으로 시장을 장악하는 듯하더니 요즘은 MS Azure가 적극적인 마케팅의 결과로 빠르게 시장점유율이 증가하고 있다. 그리고 Google 또한 적극적으로 경쟁에 가세하기 시작했다. (https://www.channelpartnersonline.com/2019/02/07/azure-still-king-in-public-cloud-while-azure-grows-fastest-ibm-falls/)
몇 달 전 사내에서 GCP(Google Cloud Platform)에 대한 설명회가 열려 참석할 기회가 있었다. 사실 설명회 내용만 놓고 봐서는 AWS와 경쟁하기 위한 더 좋은 점을 찾지는 못하였다. 설명회에서 기업의 임직원들을 대상으로 수행하는 Google Cloud JAM이라는 프로그램을 신청하는 방법을 가이드해주었는데, Coursera와 Qwiklabs을 통해서 진행되는 강의였다. 이번 강의는 GCP와 함께 Kubernetes, GKE(Google Kubernetes Engine)에 대한 내용들이 제공이 되었는데 GCP뿐만 아니라 k8s에 대해서도 자세히 알 수 있는 좋은 기회였다. (https://sites.google.com/view/cloudstudyjamkr/home)
8월 1일부터 6주간 진행되는 강의를 모두 들으면 소정의 상품이 주어진다고 하는데, 해당 기간에 여름휴가가 겹쳐있는 만큼 평일/주말의 자투리 시간을 활용하여 열심히 듣고 정리하려고 한다. 강의에 대한 내용은 철저하게 나의 관심과 리마인드를 위한 목적으로 작성할 예정이다. 혹 누가 내용이 부실하거나 부정확한 내용에 대해서 알려준다면 그때 추가적으로 확인해서 공유하려 한다. 끝까지 잘 마칠 수 있길!!
GCP를 소개하는 처음 강의에서는 cloud computing과 GCP가 갖는 특징에 대해서 이야기 한다.
클라우드 컴퓨팅이 갖는 5가지 기본 요소(특징)이 존재한다.
1) On-Demand self-service
- 사람의 개입없이 필요에 따라서 원하는 리소스를 제공받을 수 있다.
2) Broad network access
- 이러한 리소스는 네트워크가 연결된 어느 곳에 서라도 접근이 가능하다. (물론, 보안정책을 설정할 수도 있다.)
3) Rapid elasticity
- 추가적인 리소스가 필요할 때 빠르고 유연하게 확장할 수 있다.
4) Resource pooling
- Cloud provider로부터 제공되는 리소스는 물리적으로 다른 고객과 공유될 수 있으며, 규모의 경제를 누릴 수 있다.
5) Measured service
- 사용량 단위로 비용을 지불한다.
GCP 에서 제공하는 Compute 서비스는 크게 4가지로 나눌 수 있다.
1) Compute Engine (IaaS)
- Cloud 환경에서 VM을 On-demand로 제공해주는 서비스. 이것은 단순히 google cloud를 통해 infra를 제공하는 것과 같다. 사용자가 유연하게 customizing 할 수 있지만 그와 함께 사용자가 직접 서버 인스턴스를 관리해야 한다.
2) Google Kubernetes Engine(GKE)
- Containerized application을 Cloud환경에서 수행시켜주며, 그 환경은 사용자가 제어할 수 있다. GKE 내부적으로 Compute Engine을 사용한다.
3) App Engine (PaaS)
- GCP에서 제공하는 fully managed server 프레임워크로 사용자가 관리할 요소가 없다. cloud 환경에서 사용자의 소스코드를 수행시켜주는데 infra에 대한 걱정을 전혀 할 필요 없이 단순히 code만 수행시키면 된다.
4) Cloud Functions (FaaS/serverless)
- 이것은 serverless 실행 환경을 제공하거나, 특정 기능을 수행하는 function 자체를 서비스로 제공한다.
이 서비스는 특정 event에 대한 응답으로 소스코드를 수행하거나 주기적으로 소스코드를 수행할 수 있다.
> Application을 수행하기 위해서는 데이터를 저장할 DB가 필수적으로 필요한데, 임시 데이터라고 한다면 Compute Engine 내부적으로 구성해도 되지만, 별도의 GCP Storage service를 사용하는 것이 유지보수 관점에서 더 안정적이다.
> GCP에서는 bigdata나 ML과 같은 특수한 workload를 처리하기 위한 서비스도 제공하고 있다.
> GCP에는 현재 아래와 같이 Region / Zone이 구성되어 있으며 Google의 전용선이 설치되어 있다.
> 아직 한국에는 region이 없기 때문에 HongKong, Singapore, Taiwan 등을 사용해야 겠다. (내키진 않지만, 필요하다면 빨간 섬나라 것도..)
> Resource에 따라서 zonal-level에서 제공되는 서비스와, regional-level에서 제공되는 서비스 그리고 golbal-level에서 제공되는 서비스가 있기 때문에 이것을 잘 고려하여 architecture를 설계해야 한다.
> Zonal resource는 하나의 zone에서만 수행될 수 있는 서비스로 만약 해당 zone에 장애가 발생한다면 해당 resource는 사용할 수 없게 된다. 따라서 해당 서비스는 HA를 고려하여 구성해야 한다.
> 모든 리소스는 project 단위로 제공이 되며, project는 고유한 ID와 number를 갖게 된다. project에 대해서 name을 부여하거나 label을 줄 수 있으며, 이것은 변경 가능하지만 poject ID와 project number는 변경이 불가능하다.
> Project는 folder에 속하고 folder는 다시 organization에 속하게 된다.
> Organization은 google cloud identity를 통해서 무료로 얻을 수 있는데, organization은 고정된 organization ID와 변경가능한 name을 갖는다.
> 이렇게 제공되는 계층구조는 사용자에 대한 access control을 보다 쉽게 해주는데, IAM 정책을 통해서 사용자 별로 access control을 수행할 수 있다. resource 단위로도 제어할 수 있으며 정책끼리 상속관계를 정의할 수도 있다.
> 만약 IAM 정책에 organization의 권한을 부여 받는다면, 해당 organization에 대한 모든 하위 권한을 갖게 되는 것이다.
> GCP 의 요금 청구는 project 단위로 이루어지는데 proejct를 정의할 때 요금을 청구할 계좌billing account 를 연계하게 되어 있다. 물론 하나의 계좌를 여러 project와도 연결시킬 수 있으며, 무료로 제공되는 GCP 서비스에 대해서는 어떠한 계좌도 연결할 필요가 없다.
> 연결된 계좌로부터 자동으로 비용이 청구될 수 있으며, 매달 송장이 처리되며, 요금에 대한 임계값 설정도 가능하다.
> 하나의 project를 분리하여 하위 계좌를 설정할 수도 있는데 일부 GCP 고객들이 GCP 서비스를 resell 할때 이러한 처리를 하기도 한다.
> 대부분의 고객들이 resource hierarchy를 사용하고 조직도와 유사한 형태로 project를 구성하기 때문에, 사내 시스템에서 사용하는 cost-center structure와 유사한 형태로 제공될 것이다.
청구 요금을 제어하는 방식에는 아래와 같다.
> 예산설정 및 알람 설정 : 예산을 설정하고 일정 사용량 이상 사용 시 알람을 설정할 수 있다.
> 청구요금 내보내기export : 요금에 대한 상세 데이터를 BigQuery 또는 file을 통해 볼 수 있도록 export 한다.
> 청구요금 레포트report : 실제 프로젝트 별로 얼마나 비용이 청구되는지 그래픽 하게 보여준다.
> Quotas 설정 : error 혹은 악의적인 공격을 막기 위해 resource 사용량에 대한 과도한 사용을 막아주도록 설계되었다. Quotas는 GCP project level 단위로 설정이 가능하다. quotas 에는 다음과 같이 2가지 타입이 존재한다.
1) Rate quota : 일정 주기(ex.월)를 갖고 resource에 대한 사용량을 제한한다.
2) Allocation quota : 별도의 주기를 갖지 않고 사용할 수 있는 resource의 최대 크기를 설정한다.
만약 GKE 클러스터에 rate quota가 설정되어 있는 경우 GKE에서 수행되는 app에 대한 limit이 아닌, GKE 클러스터 자체에 대한 설정임으로 주의해야 한다.
GCP와 통신하기 위한 방법으로 크게 4가지가 존재한다.
> GCP console : 웹GUI 기반으로 resource를 관리하고 명령을 실행시킨다. proejct와 resource 제어를 마우스 클릭 몇 번만으로 처리할 수 있다.
> Cloud SDK and Cloud shell : GCP를 제어할 수 있는 도구를 제공해준다. SDK는 gcloud, kubedctl, gsutil, bq 등의 명령을 제공하는데, Cloud shell는 내부적으로 cloud SDK가 설치된 Compute Engine을 사용한다. Cloud shell은 사용자의 권한에 따라 수행할 수 있는 명령어가 제한이 된다.
> Cloud Console mobile app : Compute Engine 인스턴스를 시작 정지, SSH작업을 할 수 있으며, 요금에 관한 정보를 얻을 수도 있다. 주로 알람이나 시각 데이터를 제공받기 위해서 사용된다.
> REST-based API : 별도의 custom application을 통해서 GCP를 제어할 수도 있다.
** 해당 글에 사용된 이미지 자료는 GCP 강의에서 제공되는 문서자료를 활용화였습니다.
저작권의 문제가 있는 경우 말씀해주시면 삭제하도록 하겠습니다.
'02.IT공부(간헐적취미) > CLOUD' 카테고리의 다른 글
| [GCP] 3 - Kubernetes Architecture (2) : Controllers (0) | 2019.08.16 |
|---|---|
| [GCP] 3 - Kubernetes Architecture (1) : Concepts (0) | 2019.08.13 |
| [GCP] 2 - Container and Kubernetes in GCP (0) | 2019.08.12 |
