[GCP] Google Cloud Plaform - VPC, Compute Engine

이 포스팅은 Coursera의 Google Cloud Platform Fundamentals:Core Infrastructure 강의를 요약 정리 한 것입니다.

---

클라우드에서 워크로드(workload)를 실행하는 방법 중 가장 친숙한 것은 가상머신(virtual machine)을 활용하는 방법이다. GCP의 Compute Engine을 사용하면 구글의 글로벌 인프라에서 가상 머신을 실행할 수 있다. 엔진은 구글의 가상 네트워킹에 중점을 둔다. 가상 머신의 장점 중 하나는 각각이 파워를 가지고 완전한 운영체제를 실행할 수 있다는 점이다.

 

각각의 본격적인 운영 체제의 일반성. 마치 물리적인 서버를 설치하듯 각각의 CPU 파워와 메모리, 저장소와 운영체제를 융통성있게 구성할 수 있다.

 

가상 사설 클라우드(VPC, Virtual Private Cloud)

 

VPC 네트워크는 GCP 리소스를 상호 연결하고 인터넷에 공급한다. VPC를 통해 네트워크를 분할(segment)하고 방화벽 규칙을 사용하여 인스턴스에 대한 엑세스를 제한하고 특정 경로로 트래픽을 전달하는 고정 경로를 만든다. VPC 네트워크에는 전역 범위(global scope)가 존재한다. 전 세계 모든 GCP 지역에 서브넷을 보유 할 수 있으며 서브넷은 region을 구성하는 zone에 걸쳐있을 수 있다. 이 아키텍처를 사용하면 전역 범위를 사용하여 고유 한 네트워크 레이아웃을 쉽게 정의 할 수 있다. 동일한 서브넷의 다른 영역에 리소스를 둘 수도 있으며 할당 된 IP 주소 범위를 확장하여 사용자 지정 네트워크에서 서브넷의 크기를 동적으로 늘릴 수 있다.

 

컴퓨팅 엔진(Compute Engine)

 

컴퓨팅 엔진을 사용하면 Google 인프라에서 가상 머신을 생성하고 실행할 수 있으며 빠르고 일관된 퍼포먼스를 내는 수천가지의 가상 CPU 시스템을 가동할 수 있다. VM을 생성하기 위해 GCP Console 또는 gcloud CLI 툴을 사용할 수 있고 VM으로 구글에서 제공하는 Linux와 Window Server 이미지뿐만 아니라 많은 실제 서버에서 이미지를 가져올 수도 있다. VM을 생성할 때는 머신 유형을 선택하고 메모리와 가상 CPU 수를 결정한다. 머신 러닝이나 데이터분석과 같은 워크로드가 있는 경우 많은 GCP Zone에서 GPU를 활용할 수 있다. 실제 컴퓨터에 디스크가 필요한 것처럼 VM도 디스크를 필요로 하는데 표준 또는 SSD의 두 가지 영구 저장소(persistent storage)를 선택할 수 있다. 만일 어플리케이션이 고성능의 스크레치 공간이 필요하다면 로컬 SSD를 연결할 수 있다. 그러나 영구적인 데이터는 다른 곳에 저장해야 한다. 로컬 SSD의 내용은 VM이 종료되기 전까지만 유효하다. 그렇기 때문에 다른 쪽이 영구 저장소라고 불린다. 다음으로 부팅 이미지(boot image)를 선택해야한다. 처음 부팅 할 때 소프트웨어 패키지를 설치하는 것과 같다. 이를 수행하는 GCP VM 시작 스크립트(startup script)를 전달하는 것이 일반적이다. 다른 종류의 메타 데이터도 전달이 가능하다. 일단 VM이 실행되면, 디스크로부터 스냅샷을 가져올 수 있다. 이것을 백업하거나 사용하여 VM을 마이그레이트 하는데 활용한다.

 

VPC의 중요한 기능

 

VPC에는 실제 네트워크와 같은 라우팅 테이블이 있다. 이것은 트래픽을 전달하는 데 사용된다. 심지어 외부 IP 주소가 없는 하위 네트워크 및 GCP 영역 간에도 VPC 라우팅 테이블이 내장되어 있으므로 라우터를 공급(provision)하거나 관리 할 필요가 없다. 또 한가지 GCP에서 공급과 관리할 필요가 없는 것이 있는데 바로 방화벽(firewall) 인스턴스이다. VPC는 글로벌 분산 방화벽을 제공한다. 들어오는 트래픽과 나가는 트래픽 모두에 대한 인스턴스 액세스를 제한하도록 제어 할 수 있다. 컴퓨팅 엔진 인스턴스에서 메타 데이터 태그로 방화벽 규칙을 정의 할 수 있다. 예를 들어 모든 웹 서버를 "web"으로 태깅하고 "web"이 태깅된 모든 VM에 대해 "80" 또는 "443" 포트에 대한 트래픽을 허용하도록 방화벽 규칙을 작성할 수 있다. 기억해야 할 것은 VPC는 GCP 프로젝트에 속해있다. 그러나 만일 회사의 몇몇 GCP 프로젝트와 VPC가 대화해야하는 경우라면 어떨까? 물론 이러한 경우도 가능하다. 두 VPC간에 트래픽을 교환 할 수 있도록 피어링 관계(peering relationship)를 설정하고 트래픽을 교환할 수 있다. 이것이 VPC Peering이다. 반면에 IAM의 모든 기능을 사용하려면 한 프로젝트에서 다른 프로젝트의 VPC와 상호 작용할 수 있는 사람과 대상을 제어해야 하는데 이것이 바로 공유 VPC이다. 클라우드 로드 밸런싱(Cloud Load Balancing)은 모든 트래픽에 대해 완전히 분산된 소프트웨어로 정의된 관리 서비스(software-defined managed service)이다. 그리고 로드 밸런서는 VM에서 실행되지 않기 때문에 확장 또는 관리에 대해 걱정할 필요가 없다. 모든 트래픽 앞에 클라우드 로드 밸런싱을 배치 할 수 있다. HTTP, HTTPS, TCL 및 SSL, UDP 어떤 트래픽도 가능하다. 클라우드 로드 밸런싱을 통해 단일 애니 캐스트(anycast) IP는 전 세계의 모든 백엔드 인스턴스에 대해 프론트앤드(frontend)한다. 이것은 일부 백엔드가 비정상일 때 트래픽을 전환하여주는 자동화된 multi-region failover을 포함한 cross-region 로드 밸런싱을 제공한다. 클라우드 로드 밸런싱은 사용자, 트래픽, 서버 장애, 네트워크 상태를 비롯한 관련 상황에 빠르게 대응한다.

 

만약 서비스에 대한 수요가 급증한다면 어떻게 해야할까? 런칭한 온라인 게임이 예상보다 더 큰 호응을 얻었다고 가정할 때 GCP에서는 소위 사전 경고와 같은 행위가 불필요하다. 만일 웹 어플리케이션에 대해 지역별 로드 밸런싱(cross regional load balancing)이 필요하다면 HTTPS 로드 밸런싱을 사용하면 된다. HTTP가 아닌 SSL(Secure Socket Layer) 트래픽의 경우 글로벌 SSL 프록시 로드 밸런서를 사용하면 된다. SSL을 사용하지 않는 다른 TCP 트래픽인 경우 글로벌 TCP 프록시 로드 밸런서를 사용한다. 이 두 프록시 서비스는 특정 포트 번호에서만 동작하고 TCP에서만 동작한다. 임의의 포트 번호에서 UDP 트래픽 또는 트래픽을 로드밸런싱 하려면 지역별 로드 밸런서를 사용하여 GCP 리전에서 로드 밸런싱이 가능하다. 마지막으로 이 모든 서비스의 공통점은 인터넷에서 Google 네트워크로 유입되는 트래픽을 위한 서비스라는 것이다. 그럼 프로젝트 내에서 트래픽 로드 밸런싱을 하려면 어떻게 해야할까? 이럴때는 내부 로드 밸런서(internal load balancer)를 사용하면 된다. 내부 로드 밸런서는 GCP 내부 IP address 트래픽을 허용하고 VM간의 로드 밸런싱을 수행한다. 

 

GCP는 서비스를 전 세계에서 쉽게 찾을수 있도록 클라우드 DNS를 제공한다. 이것은 Google과 동일한 인프라에서 실행되는 관리 형 DNS 서비스이다. 대기 시간이 짧고 가용성이 높으며 사용자로 하여금 애플리케이션과 서비스를 저비용으로 이용할 수 있도록 돕는다. 클라우드 DNS도 프로그래밍 가능하다. GCP 콘솔을 통해 수백만 개의 DNS zone과 레코드를 게시하고 관리할 수 있다. 

 

구글에는 엣지 캐시(edge cache)라는 글로벌 시스템이 있다. 이 시스템을 사용해서 컨텐츠 전달을 가속화할 수 있다. Google Cloud CDN을 사용하는 애플리케이션 고객은 네트워크 대기 시간을 크게 줄일 수 있다. 컨텐츠 출처에 따라 부하와 비용을 줄일 수 있다. HTTPS 로드 밸런싱을 설정하면 단순히 체크박스를 선택하는것 만드로 Cloud CDN 설정이 가능하다. 물론 다른 CDN도 많이 존재한다. 기존에 사용하고 있는 CDN 서비스가 존재할 경우 CDN 상호 연결 파트너 프로그램을 활용하여 지속적으로 사용할 수 있다.

 

GCP를 이용하는 많은 고객이 온프레미스 네트워크 등 다른 네트워크와 Google VPC를 연동하기를 원한다. 구글은 이런 경우에 많은 좋은 선택지를 제공한다. 고객들은 IPSEC 프로토콜을 사용하여 가상화된 개인 네트워크(Virtual Private Network)를 시작할 수 있다. 이를 다이나믹하게 하기 위해 Cloud Router라는 피처를 사용할 수 있다. Cloud Router는 다른 네트워크와 VPC의 라우팅 정보를 VPN을 통해 교환한다. 예를들어 Google VPC에 새로운 서브넷을 추가한다면 온프레미스 네트워크에서 자동으로 이 경로를 가져온다. 그러나 일부 고객은 보안 또는 대역폭 문제로 인해 인터넷을 사용하고 싶어하지 않는다. 이럴 때는 Direct Peering을 사용하여 구글과 피어링을 할 수 있다. 피어링은 라우터를 Google의 현재 위치 및 트래픽 교환과 동일한 공용 데이터 센터에 배치하는 것을 의미한다. 구글은 100개 이상의 포인트를 가지고 있다. 고객은 통신사 피어링 프로그램으로 파트너 계약을 맺을 수 있다. 단 피어링은 구글 서비스 수준의 계약이 제공되지는 않는다. 구글과 연동을 통해 최상의 가동 시간을 원하는 고객은 구글과 한개 이상의 개인적인 다이렉트 연결을 사용해 전용 연결을 맺는다. 이러한 연결에 Google 사양을 충족하는 토폴로지가있는 경우 최대 99.99 %의 SLA를 적용 할 수 있다. 이러한 연결은 VPN으로 백업하여 안정성을 향상시킬 수 있다.