[Coursera] Google Cloud Associate Engineer Prepare - Week 3-1 (프로젝트와 계정)

Week 2에서 ACE가 무엇인지, 어떤 식으로 준비하면 좋을지에 대해 알아봤습니다.

 

아직 ACE가 무엇인지 모르시는 분이라면 Week 2를 참고하시기 바랍니다. 

 

일단 내용에 앞서, 스터디 플랜을 확장시키기 위해서 먼저 특정한 세션에 대한 사전 지식이 있는지 파악한다.

" 그 세션에 대해 경험이 있는가? " , " 이러한 기술을 특정한 비즈니스 업무나 요구사항을 만족시키기 위해 어떻게 적용할 수 있는지 알고 있는가?" 이러한 질문을 스스로에게 해보길 바란다. 그리고 이러한 질문에 대한 답을 스터디 플랜을 수정하는데 활용하라고 얘기하고 있다.  

팁을 꾸준히 알려준다. 두 번 세 번 ..

 

---

Week 3 에서는 아래와 같이 Cloud solution 환경을 세팅해보는 것에 관한 주제에 대해서 다뤄보겠습니다.

1) Cloud projects and accounts

2) Billing management

3) Command line interface

 

Module 3의 목차 

GCP를 한 번이라도 써보시거나 스터디잼을 해보시며 Qwiklab을 해보셨다면 아마 익숙한 제목일 것이라 생각합니다.

 

Section 1.1 시작

1.1.1 프로젝트 생성 ( Creating projects )

1.1.2 프로젝트 내의 사용자에 대해 사전에 정의된 IAM 역할을 할당하는 법 ( Assigning users to predefined IAM roles within a project )

 

조직 내의 리소스 구조의 계층

조직의 구조에 따라 리소스는 그룹 지어질 수 있으며 함께 관리될 수 있다. 

사용자는 프로젝트 내에서 GCP 리소스를 할당하거나 활성화하여 GCP 리소스를 사용할 수 있다. 

GCP 리소스를 이용하기 위한 가장 기본적인 단위는 프로젝트이다 그렇기 때문에 콘솔은 최소한 1개의 프로젝트를 가지고 있어야 한다. 프로젝트를 통해 아래와 같은 일을 할 수 있다.

 

* 리소스와 할당량의 사용량을 추적할 수 있다.

* 결제를 활성화할 수 있다.

* 권한(permissions)과 인증키(credentials)를 관리할 수 있다.

  (권한이라는 것은 읽기 전용, 쓰기 전용, 읽기 쓰기 모두 허용 등과 같은 리소스 접근 권한을 말한다.)

* 서비스와 APIs를 활성화할 수 있다. 

 

프로젝트 생성시 주의해야할 것 ( name 과  ID )

프로젝트 생성 시 Project ID와 Project name은 사용자가 설정할 수 있다. Project name은 고유한 이름이 아니더라도 상관없지만, Project ID는 전 세계적으로 유일한 이름을 사용해야 한다. 그리고 Project ID는 한 번 설정되면 변경할 수 없다.  Project number는 GCP에서 자동으로 할당해준다. ( Project number도 변경될 수 없다. )

 

 폴더(Folder)는 프로젝트와 정책(Policy)을 묶어주는데 꼭 폴더를 사용해야 하는 것은 아니다.  그러나 폴더를 이용하면 프로젝트를 관리하기 편하게 해 준다.

 

* 폴더는 다른 폴더, 프로젝트 그리고 둘 다 포함할 수 있다. 

* 폴더를 이용해서 접근 정책을 할당할 수 있다.

(폴더 별로 내부 프로젝트 및 폴더에 대한 접근 권한을 다르게 할 수 있다는 의미)

폴더가 꼭 필요한 것은 아니다.

처음 organization 노드를 만들면 (여기서는 example.com ) default 세팅으로 조직의 누구나 프로젝트를 생성하고 결제 계정을 생성할 수 있는 권한을 준다. 가장 좋은 방법은 새로운 organization 노드를 생성할 때, 조직 내의 누가 이러한 일에 대한 허용 권한을 가질지 미리 결정하는 것이다. 이러한 방법을 통해 조직 각 구성원들에게 맞는 역할을 좀 더 쉽게 배정할 수 있으며 좀 더 안전한 관리가 가능하게 만들 수 있다. 

 

GCP 내 권한은 상속 가능한데, 이 말은 계층 구조 상에서 하위에 있는 리소스는 상위 리소스의 권한을 그대로 포함할 수 있다는 의미이다. 

 

리소스 권한과 관련된 Policy 계층 구조

* Policy는 리소스에 대해 설정되며, 각각의 policy는 역할들과 그 역할에 대한 멤버에 대한 정보를 가지고 있다. 

* 자식 리소스는 부모 리소스로부터 policy를 상속한다. (그리고 이러한 상속된 policy는 제거될 수 없다.) 

* 자식 리소스에 부모 리소스의 policy보다 좀 더 엄격한 policy를 오버라이드 하여 적용 가능하다. 

 

GCP 내의 대표적인 세 가지 Role ( Custom Role은 살펴보지 않을 예정이다. )

 

먼저 Primitive Role에 대해 살펴보면 Primitive Role은 Owner, Editor, 그리고 Viewer로 구성된다. 

Primitive Role 대략도 ( Owner, Editor, Viewer, Billing administator )

* Owner :  Editor의 역할 + Role과 Permission을 관리할 수 있다. 

* Editor : Viwer의 역할 + 현재 상태의 변경이 가능하다.

* Viewer : 읽기만 가능

 

그러나, 민감한 데이터 등을 다루는 등 프로젝트에 여러 사람들이 함께 작업하다 보면 이런 기본 역할로는 충분하지 않을 수도 있다! 그래서 GCP IAM은 누가 어떤 리소스에 얼마큼의 권한을 가지는 지를 따로 정의할 수 있는 기능도 제공하고 있다. 

GCP IAM으로 유연한 권한 부여가 가능하다!

 

또한 GCP는 미리 정의된 역할(Predefined Role)을 제공하는데 이것은 특정 유형의 리소스에 대해 가능성이 있는 권한 목록을 제공해 범위를 좁힐 수 있도록 도와준다. 

사용할 가능성이 있는 권한 목록을 제공해주는 Predefined Role

예시 ) Compute Engine에 대한 Predefined Role

 

 

1.1.3 G Suite identities에 사용자 연결하기 ( Linking users to G Suite identities )

 

사용자와 그룹을 관리하기 위한 세 가지 방법

보통 GCP 사용자들은 Gmail 계정을 통해서 GCP 콘솔과 연동하는데, 이런 방식을 이용하면 Google Groups는 조직 내의 구성원들 중 같은 권한을 가진 사람들끼리 따로 모아줍니다. 그러나 이 방식은 누군가 조직을 나갔을 때, 조직의 구글 클라우드 자원에 대한 접근 권한을 중앙 집권적으로 처리할 수 없다는 단점이 있습니다. 이런 방법은 G Suite를 활용하여 해결 가능한데, G Suite를 사용하는 GCP 사용자는 그룹 내에서 G Suite 사용자들에 대한 GCP 정책을 설정할 수 있습니다. 

 

그러나, G Suite을 사용하지 않는다면 Cloud Identity를 사용하면 같은 기능을 이용할 수 있다! Cloud Identity는 Google Admin 콘솔을 이용하여 사용자와 그룹을 관리할 수 있게 해 준다. 

 

1.1.4 프로젝트 내에서 API 허용하기 ( Enabling APIs within projects )

새로운 계정을 만들고자 할 때, 프로젝트 상에서 개발하고, 모니터링하고, 보고하기 위해 필요한 APIs를 활성화하는 것도 중요한 일이다.

GCP를 사용하기 위한 4가지 방법 ( 여기서는 API만 다룰 예정 )

GCP를 구성하는 서비스는 사용자가 작성한 코드로 직접 제어할 수 있도록 API(Application Programming Interface)를 제공하고 있다. 이러한 API들은 RESTful(Representational State Transfer Pradigm)이라고 불린다. 

REST는 리소스를 이름으로 구별하여 해당 리소스의 상태(정보)를 주고 받는 것을 의미하고 JSON이나 XML을 통해 주로 주고받는다. 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나라고 생각하면 된다. 그리고 REST API는 REST 기반으로 서비스 API를 구현한 것이다. 

 

GCP 상 API는 RESTful API기반

GCP 콘솔에서는 APIs explorer라는 도구를 통해 사용 가능한 API에 대해 알아볼 수 있다.

그리고 다음과 같은 기능도 하는데,

 

APIs Explorer를 이용해 쉽게 API를 이용할 수 있다.

* APIs를 찾고 버전을 확인할 수 있다.

* 각각의 API에 대해 사용 가능한 메서드를 확인 할 수 있다. 

* 어떠 메서드에 대한 요청을 실행할 수 있고 그에 따른 반응을 확인할 수 있다.

* 증명되고 승인된 API call을 쉽게 만들 수 있다.

 

코드 내에서 API를 사용하고 싶을 때, 사용자를 좀 더 편하게 해 주기 위해 Google은 Client 라이브러리를 제공하고 있다!

그리고 이런 라이브러리는 두 종류로 나뉘는데,

(1) Cloud Client Libraries : API에 대한 추천되는 최신 버전의 라이브러리이다.

(2) Google API Client Libraries : Cloud Clinet Libraries가 가끔 지원하지 않는 서비스나 특징이 있는데 그럴 때 API Client Libraries를 사용할 수 있다. 일반성(generality)과 완전성(completeness)을 위해 고안되었다고 한다. 

 

API 사용을 쉽게 하기 위한 CCL과 GACL

1.1.5 하나 이상의 Stackdriver 계정 프로비저닝 하기 ( Provisioning one or more Stackdriver accounts )

서버와 서비스가 항상 유지되기 위해서는, 이것들의 성능과 안전성에 대해 지속적으로 모니터링해야 한다. 이러한 모니터링을 하기 위한 도구가 Stackdriver이다. 

 

Google Cloud 상의 강력한 모니터링 도구 : Stackdriver ! 

Stackdriver은 성능 지표, 로그 및 이벤트를 집계해주는 멀티 클라우드 모니터링 서비스이고 로깅 및 진단 서비스도 제공한다. 

 

Stackdriver log 특징

Stackdriver의 로그는 로그의 타입에 따라 저장되는 기간이 다르다는 특징을 가진다. 

Admin Activity audit 로그는 400일 동안,

Data Access audit 로그는 30일 동안 저장될 수 있다.

실제 stackdriver에 대해서 알고 싶다면 Qwiklab Quest를 통해 실제로 Stackdriver 계정을 프로비저닝하고 사용해보시기 바랍니다! 

 

정리하면, 

1. Project 생성시 프로젝트 이름과 ID를 설정해야 하며, 프로젝트 number는 자동 생성해준다.

2. 콘솔은 최소한 1개의 프로젝트를 가지고 있어야 한다.

3. 하위 계층 리소스는 상위 계층 리소스의 정책을 상속하며 삭제할 수 없다. 

4. 권한을 설정하기 위해 Primitive role, Predefined role, 그리고 Custom role을 이용할 수 있다. 

5. G suite을 이용한다면 G suite을 이용하여 조직 내 구성원들의 변화에 따른 권한 변경을 중앙집권적으로 간단하게 할 수 있다.  ( Cloud Identity의 Google Admin 콘솔을 이용해도 가능하다! )

6. APIs explorer를 통해 프로젝트 내 API를 관리할 수 있다. 

7. Stackdriver을 통해 GCP 내 많은 기능들에 대한 모니터링, 로깅, 진단을 할 수 있다.