[Coursera] Google Cloud 소개

* Coursera, Getting Started with Google Kubernetes Engine 강의 내용입니다.

 

 Cloud Computing and Google Cloud 

 클라우드 컴퓨팅의 다섯 가지 기본 속성 

Google Cloud를 비롯한 퍼블릭 클라우드는 이렇게 작동한다.

• 첫째, 컴퓨팅 리소스가 주문형 및 셀프서비스 방식으로 제공됩니다 클라우드 컴퓨팅 고객은 자동 인터페이스를 사용하므로 사람의 개입 없이 필요한 처리 능력, 스토리지 네트워크를 확보할 수 있다.
• 둘째, 어디서나 네트워크를 통해 리소스에 액세스할 수 있다.
• 제공업체에서 대규모 풀의 리소스를 고객에게 할당하므로 고객은 규모의 경제가 주는 이점을 얻습니다 고객은 이러한 리소스의 정확한 물리적 위치를 파악하거나 신경 쓸 필요가 없습니다
• 리소스는 탄력적으로 공급됩니다 리소스가 추가로 필요하면 신속히 확보할 수 있고 적게 필요하면 축소할 수 있습니다
• 마지막으로 고객은 사용하거나 예약하는 만큼만 지불하면 됩니다 리소스 사용을 중단하면 지불도 중단됩니다

 

 GCP 서비스의 종류 

GCP는 다양한 서비스를 제공한다.

• 설계자와 개발자는 솔루션을 개발할 때 이러한 서비스를 선택할 수 있다. 대부분은 주문형 가상 머신처럼 이미 친숙한 클라우드 서비스이며 완전히 새로운 패러다임을 제시하는 클라우드 서비스도 있습니다
  • 그중 하나인 Google Kubernetes Engine(GKE)은 이 과정과 차후 과정에서 중점적으로 다룰 서비스이다.
• 사용자 대신 클라우드에서 코드를 실행해 달라는 요청을 수행하기 위해 GCP가 등장했다. GCP는 그 요청을 실행할 수 있는 여러 서비스를 제공하며 각 서비스는 다양한 사용자 선호도를 충족하기 위해 설계되었다. 각 서비스를 간략히 살펴본 뒤 상세히 비교해 보겠다.
  • 초보자에게 가장 친숙한 서비스는 Compute Engine일 것이다. Compute Engine은 클라우드에서 주문형 가상 머신을 실행하게 해 주는 Google Cloud Infrastructure-as-a-Service 솔루션입니다 유연성이 뛰어나 서버 인스턴스를 직접 관리하려는 사용자에게 적합하다.
  • 이와 달리 GKE는 Google이 관리하는 클라우드 환경에서 컨테이너화된 애플리케이션을 실행하며 사용자에게 관리 권한을 부여한다. 간략하게 컨테이너화는 이동성을 극대화하고 리소스를 효율적으로 사용할 수 있도록 코드를 패키지화하는 방식으로, Kubernetes는 컨테이너 내부에서 코드를 조정하는 방식으로 이해하면 된다.
  • App Engine은 GCP의 완전 관리형 Platform-as-a-Service 프레임워크이다. 즉 인프라에 대한 걱정 없이 클라우드에서 코드를 실행하는 방법을 뜻한다. 사용자는 코드에만 집중하고 프로비저닝과 리소스 관리는 Google이 담당하는 것이다.
  • Cloud Functions는 완전 서버리스 실행 환경 또는 Function-as-a-Service이다. 이벤트가 하루에 한 번 발생하든 1초에 수차례 발생하든 관계없이 이벤트에 응답하여 코드를 실행한다. Google이 알아서 리소스 규모를 조정하며 사용자는 코드 실행 기간에만 비용을 지불하면 된다.
• 여기서는 GKE를 중점적으로 살펴볼 것이다. GKE는 Compute Engine 기반 서비스이므로 Compute Engine도 함께 다룬다.

 

 GCP와 데이터베이스 

대부분 애플리케이션은 데이터베이스가 필요하다.

• 클라우드 애플리케이션을 구축한 사용자라면 Compute Engine 내 가상 머신에서 앱을 위한 데이터베이스를 설치하고 실행할 수 있다. 가상 머신을 시작한 다음 데이터 센터에서처럼 데이터베이스 엔진을 설치, 설정하면 되는 것이다.
• Google Kubernetes Engine에서도 데이터베이스 서버를 실행할 수 있다. 어느 방식이든 데이터베이스 관리와 지원은 사용자의 몫이다.
• Google의 완전 관리형 데이터베이스와 스토리지 서비스를 이용할 수도 있다. 이러한 서비스의 공통점은 데이터 저장에 수반되는 모든 업무를 줄여 준다는 것이다.
• GCP는 관계형 데이터베이스와 비관계형 데이터베이스 그리고 세계 규모의 객체 스토리지를 제공한다.
• GCP는 완전 관리형 및 빅데이터 머신러닝 서비스를 제공한다. 스토리지나 데이터베이스 서비스와 마찬가지로 직접 구축하고 구현할 수 있어서 일부 고객들이 이용하고 있다. 서비스의 형태로 제공되는 만큼 손쉽게 시작할 수 있고 일상적인 업무를 최소화할 수 있다.

 

 Resource Management 

 GCP 서비스와 배치 방식 

이 동영상에서는 GCP 서비스의 토폴로지를 안내하고 각 영역, 리전 및 전역 규모로 GCP 서비스가 배치된 방식을 살펴봅니다 또한 사용자가 사용하는 리소스를 조직, 폴더, 프로젝트를 통해 계층적으로 구성하고 액세스 제어와 결제를 관리하는 방법을 알아봅니다 

Google Cloud Platform이 제공하는 서비스의 이면에는 다양한 리소스가 존재한다. 물리적 서버와 하드 드라이브 같은 물리적 자산과 가상 머신이나 컨테이너 같은 가상 리소스가 있고 모두 Google의 글로벌 데이터 센터에서 관리된다.

• Google Cloud는 multi region, region, zone을 통해 리소스를 제공한다.
  • 멀티 리전은 전 세계를 크게 세 지역 아메리카, 유럽, 아시아 태평양으로 나눈다.
  • 이 3개의 multi region은 다시 region으로 나뉘는데 region은 같은 대륙 내에서 독립된 지리적 위치이다.
  • region 내에서는 네트워크 연결이 빠르다. 일반적으로 95번째 백분위수에서 1밀리초 미만의 왕복 네트워크 지연 시간을 갖는다.
  • region은 최종적으로 zone으로 나뉜다. zone이란 집중된 지리적 위치 내에 있는 GCP 리소스의 배포 위치를 뜻한다. 한 region 내에 위치한 데이터 센터가 곧 zone이라고 볼 수 있다.
  • 엄밀히 말하면 하나의 zone이 반드시 하나의 데이터 센터인 것은 아니다. 앞서 Compute Engine을 언급했는데 Compute Engine 가상 머신 인스턴스는 특정 zone 내에 위치한다. 그 zone이 사용 불가 상태가 되면 가상 머신과 워크로드 또한 사용할 수 없게 된다.
• GKE는 Compute Engine을 사용하므로 GKE Workload도 비슷한 영향을 받을 수 있다. 이 때 여러개의 zone에 애플리케이션을 배포하면 내결함성과 고가용성을 확보할 수 있다.

 

 Google Networks 

세계 각지의 Google 데이터 센터는 Google 네트워크를 통해 연결된다.

• 공개된 추정치에 의하면 Google 네트워크는 매일 전 세계 인터넷 트래픽의 40%를 담당하는데 이는 지구에서 가장 큰 네트워크이며 계속 성장하고 있다.
• Google 네트워크는 사용자 앱을 포함한 모든 애플리케이션에 최대 처리량과 최소 지연 시간을 제공하도록 설계되었다.
• Google 네트워크는 전 세계 90개 이상의 인터넷 교환 시설과 100개 이상의 접속 지점을 통해 공개 인터넷을 연결한다. 인터넷 사용자가 Google 리소스로 트래픽을 전송하면 Google은 지연 시간이 가장 낮은 에지 네트워크 위치에서 사용자의 요청에 응답한다. Google의 에지 캐싱 네트워크는 지연 시간을 최소화하도록 사용자 가까이에 콘텐츠를 배치한다. GKE를 비롯해 GCP에서 실행하는 애플리케이션도 이 에지 네트워크의 이점을 활용할 수 있다.

 

GCP 서비스와 리소스를 사용하면 리소스의 지리적 위치를 지정할 수 있다. 대부분의 경우에는 multi region level과 region level, zone level 중 어느 수준에서 지정할지도 결정할 수 있다.

• zone 리소스는 단일 zone 내에서 실행된다. 따라서 해당 zone을 사용할 수 없게 되면 리소스 역시 사용할 수 없다.
  • 간단한 예시로 Compute Engine 가상 머신 인스턴스와 영구 디스크를 들 수 있다. GKE의 구성요소의 하나인 '노드'도 zone 리소스에 해당한다.
• region 리소스는 하나의 region 내에 여러 zone에 걸쳐 실행된다. region 리소스를 사용하는 애플리케이션은 가용성을 높이기 위해 중복 배포될 수 있다. GCP 서비스인 Cloud Datastore도 이와 비슷하게 중복 방식을 통해 배포할 수 있다.
• 마지막으로 전역 리소스는 multi region을 통해 관리할 수 있다. 전역 리소스는 애플리케이션의 가용성을 극대화한다. 전역 리소스의 예시로는 HTTPS Load Balancer(부하 분산기)와 virtual private cloud 즉 VPC 네트워크를 들 수 있으며 GKE 사용자도 이 리소스를 활용할 수 있다.

 

 GCP Project 

사용자가 사용하는 GCP 리소스는 위치와 상관없이 프로젝트에 속해야 한다.

• 프로젝트란 항목을 구성하는 기본 수준으로 리소스 및 서비스를 생성, 사용할 때는 물론 결제, API, 권한 관리 시 기초가 된다.  리전과 영역이 GCP 리소스를 물리적으로 구성한다면 프로젝트는 논리적으로 구성한다고 할 수 있다.
• 프로젝트는 손쉽게 생성, 관리, 삭제가 가능하며 실수로 삭제할 경우 복구할 수도 있다.
• 각 프로젝트는 고유한 프로젝트 ID와 프로젝트 번호로 식별된다. 또 프로젝트 이름과 필터링을 위한 라벨을 정할 수 있다. 라벨은 변경할 수 있지만 프로젝트 ID와 프로젝트 번호는 고정된다.
• 프로젝트는 '폴더'라는 그룹으로 묶을 수 있다. 폴더를 사용하면 기업의 계층 구조를 반영하고 기업의 정책을 알맞은 수준에서 적용할 수 있다. 물론 폴더 내에 다른 폴더를 중첩할 수도 있다.
  • 예를 들어 부서별 폴더를 만든 다음 각 부서의 폴더 내에 부서를 구성하는 팀별로 하위 폴더를 만들 수 있다. 각 팀의 프로젝트는 팀별 폴더에 속하게 된다.
• 모든 폴더는 하나의 Organization에 포함된다. Organization은 GCP 리소스 계층 구조의 루트 노드이다.
• Organization이 없더라도 GCP를 사용할 수는 있지만 Organization은 무척 유용하다.
  • 조직을 이용해 기업 전반에 적용되는 정책을 설정할 수 있다.
  • 또한 폴더를 사용하려면 조직이 필요하다.
  • GCP 고객이라면 이미 조직이 있을텐데 그렇지 않다면 Google Cloud ID를 통해 무료로 만들 수 있다.
• Organization에는 고정 Organization ID와 변경할 수 있는 표시 이름이 있다.
• GCP 리소스 계층 구조는 Organization 내 여러 부서와 팀의 리소스를 관리할 수 있도록 도와준다. 신뢰 경계와 리소스 격리를 구현하는 계층 구조를 정의할 수도 있다.
  • 예를 들면 인사팀 직원에게 데이터베이스 서버 삭제 권한이 필요할까? 엔지니어에게 직원 급여 데이터베이스를 삭제할 권한이 있어야 할까? 둘 다 그렇지 않을 것이다.
• Cloud IAM이라고도 하는 Cloud Identity and Access Management는 사용자가 사용하는 모든 GCP 리소스에 세부적인 액세스 제어를 가능케 한다.
  • IAM 정책을 정의하면 리소스의 사용자 액세스 제어가 가능해진다.
  • 사용자가 선택한 수준에서 적용한 정책은 낮은 수준으로 상속된다.
    • 예컨대 조직 수준에서 IAM 정책을 적용했다면 해당 조직 내의 폴더, 프로젝트 리소스까지 정책이 모두 적용된다.
  • 계층 구조의 보다 낮은 수준에서 정책을 적용하면 추가 권한을 부여할 수 있다.
  • 반면, 결제는 프로젝트 수준에서 누적된다. 대부분의 GCP 고객이 가진 리소스 계층 구조는 인사 조직도와 비슷하며 프로젝트 결제는 비용 센터 구조와 비슷하다.
• 리소스 계층 구조가 중요한 이유는 GCP의 공유 보안 모델 때문이다. 온프레미스 인프라에 애플리케이션을 구축할 경우 사용자가 스택 전체의 보안을 책임져야 한다. 하드웨어와 하드웨어가 위치한 프레미스의 물리적 보안 디스크의 데이터 암호화, 네트워크 무결성 애플리케이션에 저장된 콘텐츠 보호까지도 포함한다.
  • 하지만 애플리케이션을 GCP로 이전하면 Google에서 하위 레이어의 보안을 담당한다. 하드웨어와 프레미스의 물리적 보안이나 디스크의 데이터 암호화 물리적 네트워크의 무결성 등을 포함한다.
  • Google은 규모가 큰 만큼 대부분의 고객이 자체적으로 구현할 수 있는 것보다 안전하게 이러한 레이어를 보호할 수 있다. 하지만 데이터 보안을 비롯한 보안 스택의 상위 레이어는 여전히 사용자의 책임이다.
  • Google이 제공하는 도구는 사용자가 이러한 레이어에서 정의하는 정책을 구현하는 데 도움을 준다. 앞서 살펴본 리소스 계층 구조는 이러한 도구 중 하나이며 Cloud IAM 역시 마찬가지다.

 

 Billing 

 청구 

결제에 대해 자세히 알아보겠다.

• GCP 결제는 GCP 프로젝트 수준에서 설정한다. GCP 프로젝트를 정의할 때 결제 계정을 연결해야 한다. 결제 계정에서 사용자는 지불 옵션을 비롯한 모든 결제 정보를 설정한다.
• 결제 계정은 하나 이상의 프로젝트에 연결할 수 있다. 결제 계정을 연결하지 않은 프로젝트는 무료 GCP 서비스만 사용 가능하다.
• 결제 계정은 매월 또는 기준액 도달 시 자동으로 청구 및 인보이스 되도록 설정할 수 있다.
• 결제 하위 계정을 설정하면 프로젝트 결제를 분리할 수 있다. GCP 서비스를 재판매하는 GCP 고객들은 재판매 고객별로 하위 계정을 사용하기도 한다. 
• GCP에서는 결제 관련 세 가지의 유용한 도구를 제공한다. 예산 및 알림, 결제 내보내기에서 보기 그리고 보고서 보기이다.
  • 결제 계정 수준 또는 프로젝트 수준에서 예산을 정의할 수 있고 알림을 설정하면 비용이 예산 한도에 근접했을 때 알림을 받을 수 있다.
    • 예를 들면 예산 한도가 2만 달러이고 알림을 90%로 설정했다면 비용이 기준액이나 1만 8천 달러에 도달했을 때 알림을 받게 된다. 알림에 대한 응답으로 웹훅이 호출되도록 설정할 수도 있으며 이 웹훅을 사용하여 결제 알림을 기반으로 자동화를 제어할 수 있다. 예를 들어 결제 알림이 발생하면 리소스를 종료시키는 스크립트를 트리거하거나 웹훅을 사용해 팀에 장애 신고를 제출할 수도 있다.
  • 결제 내보내기를 사용하면 외부 분석 검색이 손쉬운 곳에 결제 세부정보를 저장할 수 있다. BigQuery 데이터 세트나 Cloud Storage 버킷을 쓸 수 있는 것이다.
  • 보고서는 콘솔의 시각적 도구로 프로젝트 또는 서비스를 기준으로 지출을 모니터링할 수 있다.
• GCP에 구현된 할당량은 예기치 못한 추가적인 결제 청구를 제한한다. 할당량은 오류나 악성 공격으로 인해 리소스를 과소비하는 것을 방지하기 위해 설계되었으며 GCP 프로젝트 수준에서 적용된다.
  • 할당량에는 비율 할당량과 배정 할당량 두 가지 유형이 있다.
  • 비율 할당량은 특정 시점을 기준으로 재설정된다.
    • GKE 서비스는 기본적으로 GCP 프로젝트에서 API에 보내는 호출을 100초당 1천 건으로 제한하는 할당량을 구현하며 100초가 지나면 한도가 재설정된다.
    • 여기서 중요한 점은 GKE에서 실행되는 애플리케이션에서 받는 호출의 비율이 아닌 GKE 클러스터 자체에서 받는 호출을 제한하는 방식이라는 점이다. 일반적으로 그처럼 짧은 시간 안에 많은 호출을 보내는 일은 흔치 않으므로 할당량을 통해 오류성 행동을 차단하는 데 도움이 된다.
  • 배정 할당량은 프로젝트 내에서 보유할 수 있는 리소스 수를 제어한다. 배정 할당량은 시간이 지나도 재설정되지 않으므로 할당량이 넘지 않도록 리소스를 해제해야 한다.
    • 예를 들면 기본적으로 각 GCP 프로젝트는 VPC 네트워크 또는 virtual private cloud를 5개 이상 보유할 수 없도록 할당량이 적용된다.
• 이 할당량은 모든 프로젝트에 똑같이 적용되지 않는다. 모든 프로젝트가 같은 할당량으로 시작되지만 Google Cloud 지원팀에 요청하면 일부 프로젝트의 할당량을 늘릴 수 있다. 일부 할당량은 프로젝트 사용에 따라 자동으로 증가하기도 한다. 또 GCP Console을 사용해 일부 프로젝트의 할당량을 줄일 수도 있다.
  • 예를 들면 사용자가 사용을 엄격하게 제한하려는 경우이다. 모든 GCP 고객에게 고정되는 할당량도 일부 있다.
  • 어떤 경우든 GCP 할당량은 고객에게 혜택을 주는 한편 예기치 않은 사용량 급증을 줄여 GCP 사용자 커뮤니티를 보호하는 역할을 한다.

 

 Interacting with Google Cloud 

 GCP와 상호작용하는 방법 

이번에는 사용자가 GCP와 상호작용하는 방법을 살펴본다. GCP와 상호작용하는 방법은 네 가지입니다 Google Cloud Platform Console, Cloud Shell 및 Cloud SDK Cloud Console 모바일 앱, REST 기반 API이다.

• GCP Console은 웹 기반 그래픽 사용자 인터페이스로 GCP 리소스를 관리할 수 있다.
  • GCP 프로젝트와 리소스를 가시적으로 파악하기도 용이하다. 웹브라우저로 console.cloud.google.com에 접속하여 GCP Console에 로그인하면 된다. 왼쪽 상단의 탐색 메뉴 버튼을 통해 모든 GCP 서비스에 액세스할 수 있다.
• Google Cloud SDK를 다운로드하고 원하는 컴퓨터에 설치할 수도 있다.
• Cloud SDK는 Google Cloud Platform용 명령줄 도구 집합을 포함하며 특히 이 과정에서 자주 사용할 gcloud 및 kubernetes명령어가 포함되어 있다. gsutil 및 bq 유틸리티도 포함되어 있다. 이러한 도구는 대화형으로나 자동화 스크립트에서 사용할 수도 있다. 또한 다양한 프로그래밍 언어를 위한 클라이언트 라이브러리도 포함되어 있다.
• 사용 중인 머신에서 Cloud SDK 설치가 어려운 경우에는 Cloud Shell을 사용하면 브라우저에서 직접 명령줄을 통해 클라우드 리소스에 액세스할 수 있다. Cloud Shell을 사용하면 Cloud SDK 등의 도구를 로컬에 설치하지 않아도 손쉬운 프로젝트 및 리소스 관리가 가능한 것이다.  Cloud SDK, gcloud, kubectl 명령줄 도구와 그 외 유틸리티는 완전히 인증되어 있고 항상 최신 상태로 사용할 수 있다.
  • Cloud Shell은 어떻게 이것이 가능할까? 비용이 없는 Compute Engine 가상 머신 인스턴스를 사용해 빌드되었기 때문이다. GCP 사용자라면 Compute Engine을 하나씩은 보유하고 있다.
  • Cloud Shell 가상 머신은 단기적이기 때문에 사용자가 상호작용을 멈추면 작동을 중단하며 사용자가 Cloud Shell에 다시 진입하면 작동을 다시 시작한다. 따라서 Cloud Shell에서 프로덕션 웹 서버를 실행하지 않는 것이 나을 수 있다. 새 Cloud Shell 세션을 시작할 때마다 5GB의 영구 디스크 스토리지도 연결된다. 또한 웹 미리보기 기능이 탑재되어 있으며 GKE 리소스를 비롯한 GCP Console 프로젝트 및 리소스에 대한 액세스 인증도 기본적으로 제공한다.
• Cloud Shell 코드 편집기는 웹브라우저에서 Cloud Shell 환경 내 파일을 실시간으로 편집하는 도구이다. Cloud Shell 명령 프롬프트에서 텍스트 편집기를 사용할 수도 있다.
  • 이 도구는 코드 우선 애플리케이션 또는 컨테이너 기반 워크로드를 작업할 때 무척 편리하다. 변경사항을 다운로드, 업로드하지 않아도 간편하게 파일을 편집할 수 있기 때문이다.
• 마지막으로 iOS와 Android에서 사용할 수 있는 Cloud Console 모바일 앱이 있다. 모바일 앱이 제공하는 다양한 기능으로는 가상 머신 관리 가상 머신 로그 조회, 프로젝트의 최신 결제 정보 확인 예산을 초과하는 프로젝트에 대해 결제 알림 받기, 커스텀 그래프를 설정하여 CPU 사용량과 네트워크 사용량 초당 요청 수, 서버 오류와 같은 주요 항목 표시 등이 있다.