[Associate Cloud Engineer Study Guide] 정리 (1) - 클라우드 서비스 타입

Coursera강의가 Associate Cloud Engineer 자격을 위해 필요한 요건을 충분히 다루지 못한다는 생각이 계속 들어서 Associate Cloud Engineer Study Guide도 함께 보고 있습니다.

( Coursera 강의 정리 내용도 마저 정리해서 올리겠습니다 ACE 준비하는 분들 모두 파이팅입니다!)

 

영롱한 "Official" 가이드북

실제로 Associate Cloud Engineer Study Guide는 Associate Cloud Engineer 시험을 위해서 필요한 부분보다 좀 더 포괄적인 내용을 다루고 있어서 자격증이 목표라고 한다면 코세라 강의나 Cloud guru강의를 통해 빠르게 내용을 습득하고 practice exam을 많이 풀고 틀린 부분만 공식 문서를 통해 보충하는 것이 좋을 것 같습니다. 하지만, 그렇게 실제로 빠르게 자격증을 딴다고 Google Cloud Platform에 대해서 잘 이해하고 있냐고 자기 자신에게 되묻는다면 갸우뚱할 것 같습니다. 그래서 하나하나 깊게 GCP를 천천히 음미해보고자 합니다. 

 

자다가도 생각나는 GCP..

 

클라우드 서비스 타입에 대한 내용을 시작으로 하나씩 정리해나가겠습니다. 

 

클라우드 서비스의 타입

 

컴퓨트 리소스

퍼블릭 클라우드에는 다양한 형태의 컴퓨트 리소스가 존재합니다.

 

1. Virtual Machine (VM)

 VM은 컴퓨트 리소스의 가장 기본적인 단위이고 클라우드를 경험하기 위해 좋은 출발지가 될 수 있습니다. VM을 만들기 위해 인터넷 웹상의 콘솔을 이용하거나 command-line tool을 이용하여 VM을 만들 수 있습니다. 구글 클라우드 플랫폼에서는 다양한 수의 가상 CPU와 메모리 용량을 가지는 많은 종류의 사전에 정의된 VM을 제공하고 있습니다. 만약 이렇게 사전에 정의된 VM이 여러분의 요구를 충족시키지 못한다면, 사용자가 정의한 VM을 생성할 수도 있습니다. 

 VM을 만들었다면, 로그인하여 원하는 데로 VM을 관리할 수 있습니다. 파일 시스템을 정의하거나, 영구 저장소를 추가하거나, OS를 추가하거나, 추가 패키지를 설치하는 등의 활동도 가능합니다. 

 사용자는 VM에서 무엇을 실행시킬지, 어떤 사람이 이 VM에 접근할 수 있는지, VM을 언제 중지시킬 것인가를 결정합니다. 여러분이 관리하는 VM은 여러분이 직장 내에서 모든 관리자 권한을 가진 서버를 가지는 것과 같다고 생각하시면 됩니다. 

 당연하게도, 다른 OS와 애플리케이션에서 구동되는 여러 VM을 생성하는 것도 가능합니다. 그리고 GCP는 분산된 백엔드를 가지는 단일한 접근점을 제공하는 로드 밸런서 기능도 제공합니다. 이런 기능은 고가용성을 필요로 할 때 굉장히 유용할 수 있습니다. 예를 들어, 로드 밸런서는 VM 중 하나에서 오류가 났을 때, 그 VM으로 가던 부하는 클러스터 내의 다른 VM으로 전달되어 시스템 안전성을 높입니다. (그래서 로드 밸런서는 백엔드에 있는 서버가 잘 작동하는지 수시로 체크합니다.) 또한 Autoscaler는 부하에 따라 클러스터 내 VM의 수를 증가시키거나 감소시킬 수 있습니다. 이런 기능을 "Autoscaling"이라고 합니다. 이런 기능은 필요 이상으로 VM을 가동하지 않는 방식으로 비용을 관리할 수 있게 도와주며 부하가 갑자기 증가하더라도 충분한 컴퓨팅 능력으로 대응할 수 있게 보장해줍니다. 

 

로드 밸런서는 단일한 트래픽 input을 백엔드에 있는 서버로 분산시켜준다.

2. Managed Kubernetes Clusters 

 구글 클라우드 플랫폼은 여러분이 서버의 클러스터를 생성하고 관리하는데 필요한 모든 도구들을 제공해줍니다. 많은 클라우드 사용자들은 서버 클러스터를 구축하고 운영하는 것보다는 그들의 애플리케이션 개발에 집중하고 싶어 할 것입니다.  이런 사용자들에게 관리되는 클러스터(managed cluster)는 좋은 옵션이 될 수 있습니다. 

 관리되는 클러스터는 컨테이너를 이용합니다. "컨테이너"는 같은 서버 상에서 한 컨테이너 상에서 돌아가는 과정이 다른 컨테이너 상에서 돌아가는 과정과 격리되어 있는 가벼운 형태의 VM이라 생각하면 됩니다. 관리되는 클러스터 상에서, 사용자는 운용하고 싶은 서버의 수와 그 서버 내에서 구동하고 싶은 컨테이너의 수를 정의 내릴 수 있습니다. 그리고 사용자는 autoscaling parameter를 설정하여 구동되는 컨테이너 수를 최적화할 수 있습니다.  관리되는 클러스터에서는 컨테이너의 상태가 사용자를 위해 모니터링되며, 만약 컨테이너에 에러가 발생한다면 클러스터 관리 소프트웨어가 이것을 발견하고 다른 컨테이너를 새로 실행할 것입니다. 

 여러분이 다양한 마이크로 서비스에 의존하고 있는 애플리케이션을 구동할 필요가 있다면, 컨테이너는 좋은 옵션입니다. 여러분의 서비스는 컨테이너를 통해 배포되며 클러스터 관리 서비스가 모니터링, 네트워크, 그리고 보안 관리까지 처리할 것입니다. 

 

3. Serverless Computing

가상 머신(VM)과 관리형 쿠버네티스 클러스터(managed kubernetes cluster)는 모두 컴퓨팅 리소스를 정의하고 확장하기 위해 어느 정도의 노력이 필요합니다. 서버리스 컴퓨팅(Serverless computing)은 VM이나 쿠버네티스 클러스터를 설정할 필요가 없는 컴퓨팅 환경에서 개발자와 애플리케이션 관리자가 코드를 실행할 수 있게 해주는 방법입니다. 

 구글 클라우드 플랫폼은 두 가지 종류의 서버리스 컴퓨팅 옵션을 제공하고 있는데, App Engine과 Cloud Functions입니다. App Engine은 오랜 시간 실행되는 웹사이트 백엔드, POS 시스템, 사용자 비즈니스 애플리케이션과 같은 애플리케이션이나 컨테이너를 위해 사용됩니다. Cloud Functions은 파일을 업로드하거나, 메시지 큐로 메시지를 추가하는 것과 같이 이벤트에 답하는 코드를 구동시키기 위한 플랫폼입니다. 또한 Cloud Functions은 함수로 코딩된 짧은 프로세스를 실행하거나, VM이나, 관리된 클러스터 또는 App Engine 상에서 구동되어야 하는 좀 더 길게 구동하는 애플리케이션을 부를 때 효과적입니다. 

 

서버시르 컴퓨팅 리소스: App Engine, Cloud Functions

 

스토리지

퍼블릭 클라우드는 다양한 범위의 애플리케이션 요구사항에 대해 유용한 몇 가지 스토리지 옵션을 제공하고 있습니다. 

크게 아래와 같이 4가지로 분류할 수 있습니다.

1) Object Storage

2) File Storage

3) Block Storage

4) Caches

클라우드 서비스에 대한 기업 사용자들은 이러한 서비스를 혼합해서 사용할 것입니다. 

 

1. Object Storage

오브젝트 스토리지(Object storage)는 오브젝트 또는 blobs 형식 파일의 스토리지 사용을 관리하는 시스템입니다. 그러나 오브젝트나 blobs과 같은 파일은 기존의 파일 시스템이 아닌 버켓(bucket)이라는 곳에 그룹 지어집니다. 각각의 오브젝트는 보통 URL(Uniform Resource Locator)을 통해 개별적으로 접근 가능합니다. 오브젝트 스토리지는 서버에 부착된 SSD나 디스크 크기에 구해 받지 않습니다. 즉, 디스크 내 사용 가능한 공간에 대한 걱정 없이 오브젝트들을 업로드할 수 있습니다. 사용 리전에 장애가 발생했을 경우를 대비해 오브젝트의 복사본을 여러 다른 리전에 저장하여 가용성과 내구성을 증가시킬 수도 있습니다.

 오브젝트 스토리지의 또 다른 장점은 이것이 서버리스란 점입니다. VM을 만들 필요도 이것에 스토리지를 붙일 필요도 없습니다. Cloud Storage라고하는 Google Cloud Platform의 오브젝트 스토리지는 GCP에서 실행되는 서버와 인터넷에 연결된 다른 장치를 통해 액세스 할 수 있습니다. Cloud storage는 오브젝트 수준에서 접근 제어를 할 수 있으며, 이것이 cloud storage 사용자가 어떤 사용자가 오브젝트에 접근하고 업데이트할 수 있는지 선택할 수 있게 해 줍니다. 

 

2. File Storage

파일 스토리지(File storage) 서비스는 파일에 대해 계층적인 스토리지 시스템을 제공하며, 네트워크 공유된 파일 시스템을 제공합니다. 구글 클라우드 플랫폼은 Cloud Filestore라는 파일 스토리지 서비스를 가지고 있으며 이것은 Network File System(NFS) storage system에 기반을 두고 있습니다.  파일 스토리지는 파일에 대한 파일 접근이 필요한 OS를 요구하는 애플리케이션에 대해 적합합니다. 파일 스토리지 시스템은 파일 시스템을 특정 VM으로부터 분리시킵니다. 즉, 파일 시스템, 해당 디렉토리 및 파일은 해당 파일에 액세스 할 수 있는 VM 또는 응용 프로그램과 독립적으로 존재합니다.

 

3. Block Storage

블록 스토리지(Block Storage)는 블록(block)이라고 불리는 고정된 크기의 데이터 구조를 사용하여 데이터를 구조화합니다. 블록 스토리지는 보통 VM에 장착된 임시 디스크(Ephemeral disk) 또는 영구 디스크(Persistent disk)에서 주로 사용됩니다. 블록 스토리지 상에서, 여러분은 블록 스토리지의 상단에 파일 시스템을 설치할 수도 있으며, 블록들에 직접적으로 접근 가능한 애플리케이션을 실행할 수도 있습니다. 몇몇 관계형 데이터베이스는 파일 시스템을 통해 동작하기보다는, 직접적으로 블록들에 접근하도록 설계될 수 있습니다. 리눅스 파일 시스템에서, 4KB가 흔히 사용되는 블록의 사이즈입니다. 관계형 데이터베이스는 종종 블록에 직접적으로 쓰기를 하는데, 보통 4KB보다 큰 8KB이거나 이보다 큰 사이즈를 사용하게 됩니다. 영구 디스크이 경우 가상 서버로부터 분리되거나, 붙어있던 가상 서버가 중지되는 경우에도 데이터를 유지하고 저장할 수 있습니다. 그에 반해 임시 디스크의 경우 VM이 동작하는 시간 동안에만 데이터를 유지하고 저장할 수 있습니다. 그래서 임시 디스크의 경우에 운영 체제 관련 파일과 VM이 정지되었을 때 삭제되는 파일을 주로 저장하게 됩니다. 그리고 영구 디스크는 데이터가 VM과 독립적으로 블록 스토리지 장치 내에 존재하기 원할 때 사용될 수 있습니다. 

 

Object storage 역시 영구 디스크처럼 VM의 상태와 독립적으로 데이터를 저장하지만, os 또는 파일 시스템 수준의 접근을 지원하지 않습니다. 그리고 오브젝트 파일에 접근하기 위해 HTTP와 같은 더 높은 수준의 프로토콜을 사용해야 합니다. 또한 Object storage는 블록 스토리지보다 데이터를 검색하는데 더 오래 걸립니다. 

 

4. Caches 

캐시(Cache)는 데이터에 대해 빠른 접근을 유지하기 위한 인메모리 데이터 스토리지입니다. 데이터를 검색하기 위한 시간을 지연시간(latency)라고 하는데, 인메모리 스토리지의 경우 지연시간이 약 1000분의 1초보다(submilisecond) 더 작습니다. 

이를 비교하기 위해 다른 지연시간을 살펴보면,

* SSD로부터 4KB를 랜덤으로 읽기 위해서는 100 만분의 150초가 걸린다. 

* 메모리로부터 순서대로 1MB를 읽는데 100 만분의 250초가 걸린다.

* SSD로부터 1MB를 순서대로 읽는데 100 만분의 1,000초가 걸린다. (1000분의 1초)

* 디스크로부터 1MB를 순서대로 읽는데 1000분의 20초가 걸린다. 

 

즉, 만약 인메모리 캐시 상에 저장된 1MB의 데이터를 읽는다면, 1000분의 0.25초가 걸릴 것이지만 같은 데이터가 SSD에 저장되어 있다면 읽는데 4배의 시간이 걸릴 것입니다. 그리고 하드 디스크 드라이브에 저장된 같은 데이터를 읽는 경우에는 80배나 더 걸릴 것입니다. 

 

캐시는 빠르지만, 비싸고 휘발성이며 시스템에서 수정된 데이터가 캐시에 반영되지 않을 수도 있기 때문에 모든 경우에 캐시를 써서 빠르게 할 수는 없습니다. 

 

예를 들어 웹 어플리캐이션의 경우, 사용자는 웹 반응 속도에 대해 민감할 수 있습니다. 보통 웹 페이지의 콘텐츠는 데이터베이스를 쿼리 한 결과를 사용하여 생성합니다. 데이터베이스에 대한 쿼리가 만들어지면 데이터베이스 엔진은 디스크 상의 데이터를 살펴봅니다. 더 많은 사용자가 데이터베이스를 쿼리 할수록, 수행해야 할 쿼리 수도 늘어납니다. 그렇게 쿼리수가 늘어나면 큐에 쌓인 쿼리 수가 점차 늘어나서 데이터베이스가 다른 쿼리를 처리하기 전까지 다음 쿼리가 처리될 수 없기 때문에 큐가 점차 쌓이게 됩니다. 그렇게 된다면 웹 애플리케이션은 데이터베이스 쿼리 결과를 기다리느라 지연시간이 길어질 것입니다. 지연 시간을 줄이는 한 가지 방법은 데이터를 읽는 데 필요한 시간을 줄이는 것입니다. 그리고 이것은 하드 디스크를 더 빠른 SSD로 교체하는 것이지만 SSD를 사용해도 큐에 쿼리가 쌓인다면 다른 옵션은 캐시를 사용하는 것입니다. 쿼리 결과가 호출될 때, 이것들은 캐시에 저장됩니다. 다음번에 이 쿼리 결과가 필요할 때는, 데이터베이스에서 가져오는 것이 아니라 앞서 저장된 캐시에서 불러오게 되며 이것은 지연시간을 줄일 수 있습니다.   

 

네트워크

클라우드에서 작업할 때, 여러분은 여러분의 클라우드 리소스와 여러분의 온프레미스 시스템 사이의 네트워킹을 가지고 작업할 필요가 있을겁니다. 그리고 여러분이 여러분의 클라우드 환경에서 다중의 VM을 가지고 있을 때, 여러분은 적당한 때에 IP 주소를 관리할 필요가 있을지도 모릅니다. 네트워크에 접근 가능한 장치나 서비스를 가진 환경에서는 IP 주소를 필요로 합니다. 사실 GCP 상의 장치들은 내부 주소(internal address)와 외부 주소(external address)를 모두 가질 수 있습니다. 내부 주소는 오직 GCP 내부 네트워크 상에 있는 서비스에만 접근할 수 있습니다. 그리고 내부 GCP 네트워크는 가상 프라이빗 클라우드(virtual private cloud, VPC)로 정의됩니다. 외부 주소는 인터넷으로부터 접근 가능합니다. 그리고 외부 주소는 고정적(static)이거나 임시적(ephemeral) 일 수 있습니다. 고정 주소의 경우 오랫동안 단일 장치에 할당됩니다. 임시 외부 IP의 경우 VM에 할당됐다가 VM이 멈추면 해제됩니다. 

 

IP 주소를 할당하는 것과 더불어, 여러분은 여러분의 VPC내에 있는 VM이나 서브넷(subnetwork)에 대한 접근을 제어하기 위한 방화벽 규칙(firewall rule)을 설정할 필요가 있습니다. 예를 들어, 여러분은 데이터베이스 서버를 가지고 있는데 오직 여러분의 애플리케이션 서버만 그 데이버베이스에 쿼리할 수 있도록 접근을 제한하길 원한다고 생각해봅시다. 방화벽 규칙은 애플리케이션 서버나 애플리케이션 클러스터 앞단의 로드 밸런서의 IP 주소에 대해 들어가고 나가는 트래픽을 제한하기 위해 구성될 수 있습니다. 또한 여러분이 온프레미스 데이터 센터와 여러분의 VPC 사이에서 데이터와 네트워크 접근을 공유할 필요가 있다면, "peering"이라는 것들 중 하나를 사용하여 떨어진 네트워크를 연결시킬 수 있습니다.