GCP 이해하기

 

1. GCP 개요: 인프라

1.1. 네트워크

구글은 구글 자사의 클라우드 네트워크를 Asia Pacific, Americas, Europe/MiddleEast/Africa 세 개의 대륙 권역으로 나누어 관리하고 있다.

GCP의 각 권역은 여러 지역(Regions)으로 나누며, 각 지역은 복수(최소 3개 이상) 개의 영역(Zones)으로 구성된다.

각 지역들 간은 구글이 관리하는 네트워크 케이블로 직접 연결되어 단일 네트워크로 운용한다.

각 대륙간 네트워크 케이블은 각 지역별 접속지점(Point of presence 이하, Pop)과 직접 연결되며, Pop와 GCP Region이 연결되거나, Pop와 각 나라별 ISP와 연결된다.


북미 대륙의 버지니아와 유럽 대륙의 런던을 예시로, 물리적인 네트워크 연결의 흐름은 다음의 그림과 같다.

(GCP North Virginia "Region" - Pop - Landing station(미국쪽) - 해저케이블 - Landing station(영국쪽) - GCP London Region)


GCP의 Pop를 통한 클라우드 서비스와 최종 사용자 간의 네트워크 도달 방식과 경쟁 클라우드 플랫폼과의 비교는 다음 그림과 같다.

GCP와 타 클라우드플랫폼과의 연결 비교

이러한 구글 네트워크를 통한 트래픽의 양은 전세계 트래픽의 25% 이상을 차지하고 있으며, 해당 트래픽의 과반 이상이 구글의 Youtube 서비스에 의한 동영상 스트리밍 트래픽으로 알려져 있다.


1.2. 하드웨어와 보안

구글은 구글 자체의 서비스(Gmail, Youtube 등)와 클라우드 서비스를 직접 설계하거나 만든 하드웨어 장비와 인프라를 토대로 서비스하고 있다.


구글이 채택한 특수 목적용 장비와 인프라의 범위는, 구글 전용 데이터센터/네트워크/스토리지/서버 및 전용 칩(Google Titan Chip)에 이르기까지 클라우드 서비스 제공에 필요한 거의 모든 영역에 걸쳐 있다.


다음의 사진은 구글이 제공하는 Titan chipset과 암호화 처리에 사용되는 전용 chip(원 안)을 보여주고 있다.

Google Titan Chip


GCP의 보안 정책은 GCP를 구성/서비스하는 계층 별로 제공되며, 계층별 대표적 보안 정책은 다음의 표와 같다.

Layer Depth
Security Layer
대표적 보안 정책
6운영 보안침입 감지 시스템, 내부자 위험 최소화 기술, 직원 U2F 사용, 소프트웨어 개발 관행
5인터넷 통신Google Front End: DoS 보호
4스토리지저장되어 있는 고객 데이터/스토리지에 암호화 적용(100%)
3

사용자 ID

U2F를 지원하는 통합 신원 확인 서비스
2서비스 배포서비스간 통신 암호화
1하드웨어 인프라전용 하드웨어 설계 및 출처 관리, 안전한 부팅 스택, 물리적 보안


또한 다음의 그림과 같이, 클라우드 서비스의 관리 범위에 따라 보안에 따른 책임을 달리 정의하고 있다.

(파란색 영역: 고객이 직접 보안 관리/책임, 노란색 영역: 구글이 보안 관리/책임)



2. GCP 개요: 리소스

2.1. GCP 프로젝트와 리소스

GCP로 제공되는 클라우드 서비스는 '프로젝트'를 구성하여 제공하고 있으며, 이러한 '프로젝트'의 역할은 다음과 같다.

  1. 글로벌 리소스에 대한 Collections
    • 리소스 및 할당량 사용 추적
    • 서비스 및 API의 사용 여부 설정
    • 권한 및 사용자 인증 정보 관리
    • 결제 계정 사용
  2. 리소스 간 독립된 경계 제공
    • '프로젝트' 별로 확실하게 분리해서 구축, 사용
  3. 사용하는 모든 GCP의 서비스가 하나의 '프로젝트'에만 연결됨


GCP 프로젝트와 리소스


2.2. 리소스 계층 구조

GCP는 조직 구조에 따라 리소스를 폴더 및 프로젝트로 그룹화 할 수 있다.

이때, 최상위에 조직(Organization)이 위치하고, 바로 아래에 폴더(Folder), 그리고 폴더 별로 프로젝트를 두게 된다.

그림으로 표현하면, 다음과 같이, GCP의 계층 수준에 따라, 신뢰 경계 및 리소스가 독립적으로 설정된다.

리소스 계층구조 레벨


리소스는 실제 GCP 콘솔 상에서, 다음과 같은 형태로 확인 할 수 있다.


2.3. 조직(Organization)노드와 IAM(Id. Access Management)

2.3.1. 조직

조직 노드는 GCP 리소스의 최상위 루트 노드이다.

조직에 할당되는 대표적인 역할은 조직 관리자와 프로젝트 생성자 이다.

  • 조직 관리자: 모든 클라우드 리소스에 대한 포괄적 제어
  • 프로젝트 생성자: 세분화된 프로젝트의 생성과 제어

2.3.2. IAM

리소스의 계층 구조에 따라, 개별적인 보안 정책의 적용이 가능하며, 각 정책은 리소스 단위로 설정 된다.

  • 각 보안 정책은 역할과 역할 구성원 집합을 포함한다.

상위의 정책은 하위의 리소스에 상속되는 구조이다.

  • 리소스 정책은 상위 리소스와 현재 리소스 정책의 합집합

덜 제한적인 상위 정책이 더 제한적인 리소스 정책을 재정의(Overwrite)한다


다음의 그림은 이러한 리소스 계층 구조에 따른 IAM 정책의 상속 흐름을 보여준다.

각 IAM 정책과 ID는 GCP의 "Cloud ID 관리 콘솔" 서비스와 "Cloud Console IAM"을 통해 관리한다.

  • Cloud ID 관리 콘솔 : 사용자 및 인증을 관리 하는 경우 사용
  • Cloud Console IAM : 클라우드 리소스 권한을 부여하는 경우 사용


IAM에서의 역할(Roles)은 다음의 3가지 유형으로 나눈다.

  • 기본 역할(Primitive Roles): 모든 프로젝트 리소스에 적용되는 역할

  • 사전 정의된 역할(Predefined Roles): 그룹화된 권한 집합


  • 커스텀 역할(Custom Roles)



3. GCP 개요: GCP 접근과 사용

GCP는 다음의 4가지 방법으로 접근, 사용할 수 있다.

  • Cloud Platform Console: 웹 기반의 UI를 제공하는 웹 콘솔이다. 웹 브라우저로 사용가능하다.
  • Cloud Shell 및 Cloud SDK: 터미널을 이용하여 사용가능한, 명령줄 인터페이스(CLI)를 제공한다.
  • Cloud Console 모바일 앱: iOS와 Android 버전의 스마트폰을 통해 사용가능한 앱을 제공한다.
  • Restful API: 커스텀 애플리케이션에서 사용가능한 Rest API를 제공한다.


3.1. Google Cloud Platform Console

모든 프로젝트 데이터에 대한 중앙 관리형 콘솔이다. 웹으로 제공한다.

다음과 같은 개발자 도구가 추가로 제공된다.

  • Cloud Source Repositories
  • Cloud Shell
  • Test Lab: 모바일 앱 테스트

GCP 제품의 API를 조회할 수 있다.

웹 콘솔을 통해 프로젝트를 관리하거나 생성할 수 있다.


3.2. Cloud Console 모바일 앱

Google Cloud Console 모바일 앱은 다음의 기능을 제공하고 있다.

  • 가상 머신 및 데이터베이스의 인스턴스 관리
  • Google App Engine에서 앱 관리
  • 결제 관리
  • 맞춤 설정이 가능한 대시보드를 통해 프로젝트의 시각화


3.3. Google Cloud SDK

SDK는 Cloud Platform 제품과 서비스를 위한 CLI 도구를 포함하고 있다.

  • gcloud
  • gsutil (Cloud Storage 제어)
  • bq (BigQuery 서비스용)


Docker 이미지로도 제공된다.

  • Compute Engine 인스턴스에서 실행되는 Cloud SDK의 컨테이너식 버전


Cloud Shell을 통해서도 사용할 수 있다.


3.4. Restful API

GCP 제품과 서비스를 활용한 프로그래밍에 사용토록 제공된다.

  • 일반적으로 JSON을 데이터 교환 형식으로 사용
  • API 인증과 승인에 OAUTH 2.0 사용


Google Cloud Platform Console을 통해 사용 설정을 한다.


대부분의 API에 일일 할당량 및 요금 한도가 적용되며, 사용자의 요청에 따라 상향 조정이 가능하다.

  • 따라서, 사전에 계획된 용량 관리가 필요함


콘솔에서 제공되는 APIs Explorer에서 (미리) 사용해 볼 수 있다. APIs Explorer는 다음과 같은 특징과 기능을 제공한다.

  • 웹 브라우저를 통해 간편하게 사용할 수 있는 대화형 도구
  • 사용 가능한 API와 버전을 탐색할 수 있음
  • 각 API에서 사용 가능한 메소드 및 지원되는 매개변수를 인라인 문서로 확인
  • 실시간으로 메소드 요청을 실행하고 그에 따른 응답을 확인
  • 사전 인증/승인된 API를 손쉽게 호출 가능



댓글

댓글 쓰기

이 블로그의 인기 게시물

파일처리(한번에 모두읽기, 라인단위로 읽기, 쓰기, 리스트처리, 특정길이만큼 읽기)

이미지
텍스트 파일 한 번에 모두 읽기 (Utility 타입)   대용량 파일일 때는 메모리가 부족할 수 있으므로 ' 텍스트 파일 라인 단위로 읽어서 처리 ' 방식을 사용 public static String read(String filePath) throws IOException {        StringBuilder  stringBuilder;      FileReader     fileReader     = null ;      BufferedReader bufferedReader = null ;      try {          stringBuilder  = new StringBuilder();          fileReader     = new FileReader(filePath);          bufferedReader = new BufferedReader(fileReader);          String line;          while ((line = bufferedReader.readLine()) != null )            ...
자세한 내용 보기

AWS 가용성,확장성

이미지
1.  개요 On-Premise 환경과 마찬가지로 클라우드 환경 하에서 아키텍처 설계 시 연속성 있는 업무 서비스를 제공하기 위하여 시스템 인프라에 대한 고가용성을 고려하여야 한다. 일반적으로 고가용성 확보는 업무 서비스가 수행되는 인프라 구성요소 별로 존재하는 Single Point of Failure(이하 SPoF)를 제거하여, 특정 구성요소에 대한 장애 시 에도 정상 구성요소를 이용하여 정상적인 서비스가 수행되도록 구성하는 것이다.  그러나, On-Premise 환경에서는 초기 물리 장비 도입부터 고가용성을 고려하여 도입을 수행하고 이를 바탕으로 아키텍처 설계가 수행되지만, 이미 물리적인 인프라 환경이 구축되어있는 클라우드 환경의 경우 개별 구성요소에 대한 가용성은 일정 수준 이상 확보가 되어있다고 할 수 있다. 따라서, 클라우드 환경 내에서의 가용성 확보는 구성요소에 대한 가용성 확보보다는 전체 아키텍처 측면에서의 가용성 확보 설계를 중점적으로 수행하는 것이 바람직하다. 또한 가용성 확보 관점에서 클라우드 환경의 특징 중 하나인 [처리 용량을 자유롭게 확장 가능한 아키텍처]와 [장애 시 자동 복구 가능한 아키텍처]을 고려한 어플리케이션/DBMS 등의 설계를 수행하여야 한다. 본 가이드에서는 클라우드 환경 내의 SPoF 구간에 대하여 살펴보고 이를 해결할 수 있는 방안을 설명한다. 2.  가용성 확보 방안 2.1.  센터 On-Premise 환경에서 센터는 평상 시 서비스를 제공하는 주 센터와 주 센터 전체 장애 또는 주 센터에서 운영중인 주요 장비 장애 시 이를 대신하여 업무 처리를 할 수 있도록 하는 DR 센터로 운영 하는 경우가 일반적이다. 해당 센터 간에는 대부분 네트워크로 연결이 되어있으며, 주 센터에서 생성되고 변경되는 데이터에 대하여 실시간/근실시간 동기화를 수행하여 센터 장애 시에 가용성을 확보하고 있다.  클라우드 환경에서의 센터는 특히 본 가이드의 대상이 되는 AWS의 경우 앞서 설명한 바와 같...
자세한 내용 보기

Serverless computing 도입시 고려사항

이미지
  1.  공급업체 종속성 서버리스 컴퓨팅같은 PaaS 서비스는 공급업체 종속성 Vender Lock-in  을 피할 수 없다. PaaS 서비스를 사용하다가 다른 클라우드 업체나 On-Premise로 이전하는 것은 막대한 비용이 발생한다. 또한 서버리스 컴퓨팅 은 제공하는 업체별로 사용 방법이 다르고 트리거 서비스가 각 공급사 서비스별로 연계되지 않기에 멀티 클라우드 전략이 어렵다. 한 예로 AWS Kinesis 라는 데이터 스트림 서비스는 AWS Lambda 와 연결하여 사용하나 Azure Functions 나 Apache OpenWisky에는 연계할 수 없다. 또한 특정 국가에서는 시스템의 서버가 반드시 해당 국가에 위치해야 하는데 CSP의 데이터 센터는 모든 국가에 위치해있지는 않다. 이런 상황에서는 시스템 수출 시 서버리스 컴퓨팅 뿐만 아니라 다른 PaaS 서비스들도 직접 구현해야 할 상황이 발생할 수 있다. 공급업체 종속성을 피하려면 오픈소스 서버리스 컴퓨팅 플랫폼을 이용 해야 한다.  2.  공급업체 마다 상이한 SLA 서버리스 컴퓨팅의 장점 중 하나는 서버 설정 등의 관리를 공급업체에서 진행하는 것이다.  하지만 공급업체의 실수로 장애가 발생할 수 있다.  한 예로 AWS의 Lambda 서비스 초기엔 잘 사용하던 함수가 몇 시간 동안 동작하지 않은 적이 있었고 AWS의 최초 서비스인 S3도 2017년 2월에 장애가 발생하여 이에 연결된 Lambda가 동작하지 않은 적도 있었다. [1]  이런 상황에 대비가 필요하고 필요에 따라서 보상을 받기 위해 SLA나 이용약관을 확인해야 한다.  AWS Lambda는 SLA가 없어 AWS의 문제로 인해 장애가 발생해도 보상 받을 수 없다.  또한 AWS의 Lambda 서비스 이용 약관에는 “AWS Lambda에 업로드된 고객의 컨텐츠가3개월 간 실행되지 않으면 30일 전에 고지하고 삭제할 수 있으며 이에 대해 어떠한 책임도 ...
자세한 내용 보기