VPC (Virtual Private Cloud networking)

VPC는 퍼블릭 클라우드 내에서 호스팅되는 안전하고, 독립적인 클라우드 컴퓨팅 모델이다. 코드 실행, 데이터 저장, 웹사이트 호스팅 등 여러 일반적인 작업들을 수행할 수 있지만 퍼블릭 클라우드 사업자가 직접 원격으로 호스팅한다. 이는 VPC가 퍼블릭 클라우드의 확장성(scalability)과 편의성에 프라이빗 클라우드의 데이터 격리라는 특징을 혼합한 것이라 볼 수 있다.

**Google Cloud Virtual Private Cloud(VPC)**는 Compute Engine 가상 머신(VM) 인스턴스, Kubernetes Engine 컨테이너, 그리고 App Engine Flexible 환경에 네트워킹 기능을 제공한다. 다시 말해, VPC 네트워크 없이는 VM 인스턴스, 컨테이너, App Engine 애플리케이션을 생성할 수 없다.

VPC 네트워크는 리소스들간의 연결과 인터넷으로의 연결을 지원한다. 여기에는 아래 작업들이 포함된다.

1. 네트워크를 분할(Segmenting Networks)
2. 방화벽 규칙(Firewall Rules)을 사용하여 인스턴스에 대한 접근을 제한
3. 특정 목적지로 트래픽을 전달하기 위한 정적 라우트(Static Routes) 생성 등

구글 클라우드 VPC 네트워크는 글로벌 네트워크이다. 또한 VPC 네트워크는 서브넷을 가질 수 있는데, 서브넷은 전체 네트워크에서 세분화된 네트워크 영역이다. 서브넷은 구글 클라우드 전 세계 어느 리전에서든 설정할 수 있다.

이러한 아키텍처를 기반으로 글로벌 범위를 가진 네트워크 구성을 쉽게 할 수 있다. 다른 Zone에 존재하는 리소스들도 동일 서브넷 내에 존재할 수 있다.

VPC 네트워크의 범위와 관련되어 AWS와 큰 차이가 발생하는데 이를 정리하면 아래와 같게 된다.

# AWS
[us-east-1 VPC] --- Peering --- [asia-northeast3 VPC]

# GCP
[Global VPC]
 ├─ us-central1 Subnet
 ├─ europe-west1 Subnet
 ├─ asia-northeast3 Subnet

AWS는 하나의 리전에 하나의 VPC를 배포할 수 있지만 GCP는 기본적으로 VPC가 글로벌 범위이기 때문에 서브넷 구성을 어떻게 하느냐에 따라 리소스들 간 프라이빗 연결을 새롭게 구성할 수 있게 된다.

글로벌 VPC상에서 서로 다른 리전에 각각 서브넷을 생성했다고 가정했을때, 서브넷 크기는 IP주소 범위를 어떻게 지정하느냐에 따라 커질 수 있다. 하지만 IP범위 확장은 가상 머신에 영향을 주지는 않는다.

서브넷에 할당할 수 있는 IP주소 갯수는 CIDR(Classless Inter-Domain Routing) 기법을 통해 표기할 수 있다. A.B.C.D/N 형식으로 표기한다. A.B.C.D는 네트워크 시작 주소를 나타내며 /N은 고정 비트 수로 N값이 클 수록 더 적게 IP 주소를 할당하게 된다.

할당 가능한 IP 수 = 2^(32 - N) - 예약된 IP (Google Cloud에서는 4개 예약됨)

Compute Engine

Compute Engine을 사용하면 가상머신을 생성하고 실행할 수 있다. 실제 서버 기기에 대한 투자 없이도 수천개의 가상 CPU들을 실행할 수 있다.

각 가상머신은 완전한 기능을 갖춘(full-fledged) OS의 성능과 기능을 포함한다. 이는 가상 머신을 실제 물리 서버처럼 직접 구성할 수 있다는 것을 의미한다.

1. 필요한 CPU 성능과 메모리 용량을 지정
2. 필요한 스토리지의 용량과 유형을 선택
3. 사용할 운영체제를 설정

가상 머신 인스턴스는 단독으로 생성하거나, 관리형 인스턴스 그룹(Managed Instance Group, MIG)을 구성하여 생성할 수 있다. 인스턴스 생성은 웹 기반 구글 클라우드 콘솔, 구글 클라우드 CLI, Compute Engine API를 통해 수행할 수 있다.

인스턴스는 구글에서 제공하는 리눅스와 윈도우 서버 이미지를 가지고 구동할 수 있고, 이러한 이미지들에 대해 직접 커스텀한 버전으로도 구동 가능하다. 뿐만 아니라 다른 OS 이미지를 직접 빌드하고 수행할 수도 있다.

Cloud 마켓플레이스를 이용하면 구글과 서드파티 공급업체가 제공하는 솔루션들을 활용할 수 있다. 소프트웨어, VM 인스턴스, 스토리지, 네트워크 설정 등을 직접 구성할 필요가 없다. 필요에 따라 배포 전에 세부 설정은 수정 가능하다. 대부분의 패키지는 클라우드 리소스 사용 요금 외에는 별도의 추가 요금이 필요하지 않다. (상업용 라이선스 소프트웨어 포함 시에는 별도 비용 청구)

스토리지 측면에서 높은 처리량(throughput)을 위해 특정 스토리지 옵션 / 머신 타입을 커스텀할 필요는 없다. 기본 설정으로도 충분히 높은 처리성능 및 Persistent Disk간의 높은 처리량이 제공되고, 이는 추가 비용없이 제공된다. 아래는 스토리지 옵션들이다.

1. Zonal Persistent Disk: 효율적이고 안정적인 Zone 단위 블록 스토리지
2. Regional Persistent Disk: 두개의 Zone에 복제되는 Region 블록 스토리지
3. Local SSD: 일시적(Transient) 로컬 블록 스토리지 / VM 종료시 데이터 소멸
4. Cloud Storage Buckets: 저렴한 객체 스토리지 / 파일 단위 저장
5. Filestore: 고성능 파일 스토리지 (NFS 기반 파일 시스템 제공)

일반적인 방법은 Persistent Disk를 인스턴스에 추가해서 사용하는 것이다.

NFS 파일 시스템 vs 블록 스토리지

1. NFS(Network File System) 기반 파일 시스템: 네트워크를 통해 접근할 수 있는 파일 시스템
   • 네트워크 상의 다른 서버에 있는 스토리지를 내 로컬 디스크처럼 사용할 수 있게 해주는 프로토콜
   • 서버 여러대가 동시에 공유된 스토리지를 사용해야 할 때 사용
   • 파일 단위 접근이 가능
2. 블록 스토리지 기반 파일 시스템: 데이터를 블록 단위로 저장하고 관리하는 파일 시스템
   • 디스크 전체를 OS가 마운트해서 사용
   • 특정 VM에만 연결 (일반적으로 1개 VM)
   • 블록 크기는 일반적으로 512바이트 / 4KB 등으로 설정. 디스크 및 스토리지 레벨에서 이미 결정되어 있음. 블록 크기가 클 수록 대용량 파일 처리에 유리하다. (작은 파일이 많으면 내부 단편화 발생)
   • 물리적인 디스크의 블록 크기와 포맷 시 지정하는 블록 크기가 달라도 파일 시스템 드라이버 레벨에서 파일 쓰기 작업을 조율하게 됨. (포맷 시 8KB, 물리적인 블록 크기가 4KB일때 - 4KB를 연속으로 쓰기 / 읽기)

마운트란, 스토리지를 운영체제 디렉토리 구조에 연결하는 것을 의미한다. (파일 시스템을 폴더처럼 사용할 수 있게 연결하는 작업)

Compute Engine pricing and billing

• VM 사용시 1초 단위 과금
• 한달 중 25%이상 비율로 실행되는 경우 분 단위 할인 자동 적용
• 커밋 사용 할인(Committed-use Discount): 1년 / 3년 사용 약정시 vCPU및 메모리 구매 금액을 최대 57%까지 할인 가능
• 프리엠티블 VM: 대용량 데이터셋을 분석하는 배치 작업처럼 실시간성이 필요하지 않으면 preemptible VM 선택 후 비용을 최대 90%까지 절약 가능
  • 구글 데이터센터에서 해당 리소스가 다른 곳에 필요할 경우 해당 VM을 중단할 수 있음
  • 최대 24시간까지 실행 가능
• 스팟 VM: 최대 실행시간 제한 없다는 차이점 외에 프리엠티블 VM과 동일함

프리엠티블 VM / 스팟 VM은 인스턴스가 언제든 중단될 수 있기 때문에 이에 대비한 안정적인 설계가 추가로 필요하다. (Checkpoint / Resumable Processing)

프리엠티블 VM은 최대 24시간으로 실행시간 설정을 해두어도 12시간이 지난 시점에 GCP에 의해 중단된 경우 중단 상태로 남게된다.

Scaling Virtual Machines

Compute Engine은 인스턴스에 대해 가장 적합한 머신 속성 선택이 가능하다. 더 나아가, 이를 유연하게 활용하기 위해 오토스케일링(Authscaling) 또한 제공된다. 부하(Load) 지표에 따라 VM 인스턴스를 자동으로 추가하거나 제거할 수 있다. 오토스케일링 동작을 위해서는 인입되는 트래픽을 VM간에 균등하게 분산하는 작업이 필요하다. 구글 VPC가 이를 위해 여러 종류의 로드 밸런싱 방식을 지원한다.

Compute Engine에는 대형 VM 구성도 가능하여 인메모리 DB나 CPU 집약적 분석 같은 작업도 가능하다. 하지만 일반적으로는 스케일 업보다는 스케일 아웃으로 인프라 구축을 시작한다.

• 스케일 업: 한 대의 머신의 성능을 키우는 것
  • 구조 단순
  • 데이터 공유 및 일관성
  • 무거운 워크로드 처리에 유리
  • 물리적 한계 / 비용 효율이 비선형적 / 장애 리스크
• 스케일 아웃: 머신 갯수를 늘려서 여러 대가 병렬로 작업을 처리하게 만드는 것
  • 확장성 뛰어남
  • 고가용성 구현, 장애 대응에 유리
  • 비용 효율
  • 아키텍처 복잡도 크고, 로드밸런서 필요

VM당 최대 CPU 수는 머신 패밀리에 따라 결정되고 사용자의 Quota 설정에 따른 제약도 받는다. (Zone마다 할당량이 다를 수 있음. Zone마다 가용 가능한 vCPU 갯수가 다를 수 있기 때문 - 다른 사용자들도 해당 Zone의 리소스를 사용할 수 있음)

What is Machine Family?

비슷한 성능 특성 / 사용 목적을 가진 머신 유형들의 그룹을 의미한다. 이러한 그룹이 존재하는 이유는 워크로드 특성에 따라 필요한 VM 사양이 다르기 때문이다.

1. CPU 성능이 중요한 워크로드
2. 메모리 용량이 중요한 워크로드
3. 저렴한 비용이 중요한 워크로드
4. 균형 잡힌 일반적인 성능의 워크로드

대표적인 머신 패밀리는 아래와 같다.

1. E2 - 저렴한 비용
2. N2 / N2D - CPU & 메모리 균형
3. C2 / C3 - 고성능 컴퓨팅 (CPU 중심)
4. M1 / M2 / M3 - 메모리 최적화
5. T2D - 비용 효율

Important VPC compatibilities(호환성)

물리적인 네트워크처럼 VPC 또한 라우팅 테이블을 갖는다. VPC 라우팅 테이블은 내장되어 있기 때문에 별도의 라우터를 직접 구성 및 배포하거나 관리할 필요가 없다. VPC 라우팅 테이블은 한 인스턴스에서 동일 네트워크의 다른 인스턴스, 서로 다른 서브넷, 서로 다른 Zone 간에 외부 IP주소 없이 트래픽을 전달할 때 사용한다.

또한 Google Cloud에서는 별도의 방화벽도 관리할 필요가 없다. VPC에서는 전역 분산형 방화벽을 제공하며 해당 방화벽을 통해 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 모두 제어할 수 있다. (인바운드 -> 외부에서 들어오는 트래픽, 아웃바운드 -> 외부로 나가는 트래픽)

**방화벽 규칙(Firewall Rules)**은 **Compute Engine 인스턴스에 적용된 네트워크 태그(Network Tags)**를 통해 정의할 수 있어서 매우 편리하다.

예를 들어 모든 웹 서버 인스턴스에 **“WEB”**이라는 태그를 달아두고, 포트 80(HTTP) 또는 443(HTTPS) 트래픽은 “WEB” 태그가 붙은 모든 VM 인스턴스에 허용하도록 방화벽 규칙을 설정할 수 있다. 이때 VM 인스턴스의 IP 주소가 무엇인지와는 관계없이 적용된다.

VPC는 리소스로서 프로젝트 하위 계층으로 존재하기 때문에, 프로젝트 간에 서로 다른 VPC들이 서로 통신하기 위해서는 VPC peering, Shared VPC와 같은 기법이 필요하다. (VPC는 리소스 단위로 분류되기 때문에 하나의 프로젝트에서 여러개 생성 가능)

1. VPC Peering: 두 VPC사이의 트래픽 교환 관계 확립
2. Shared VPC: 한 프로젝트의 VPC를 공유 - 해당 VPC를 사용하는 대상과 자격에 대한 엄격한 관리를 위해 사용

Cloud Load Balancing

Cloud Load Balancing은 완전히 분산된 소프트웨어 정의 관리형 서비스이다. 별도의 VM에서 돌지 않기 때문에 로드밸런서를 스케일링하거나 관리할 필요가 없다. Cloud Load Balancing은 트래픽 앞단에 배치할 수 있다. (HTTP(S), TCP, SSL traffic, UDP 트래픽 등)

크로스 리전 로드 밸런싱 기능도 제공한다. 백엔드가 unhealthy상태가 되는 경우 다른 리전으로 이전해준다. 트래픽 스파이크 발생 시에도 로드밸런서는 자동으로 확장된다. 트래픽 증가를 사전에 알리지 않아도 적절히 대응 가능하다. (Google의 글로벌 인프라에서 자동으로 리소스 확보 및 확장)

Google Cloud는 다양한 종류의 로드 밸런싱 솔루션을 제공한다. 이는 OSI 모델 계층과 제공 기능에 따라 분류가 가능하다.

1. Application Load Balancer
   • **Application Load Balancer는 OSI 모델의 7계층(Application Layer)**에서 동작합니다.
   • HTTP 및 HTTPS 트래픽 처리를 위해 설계되었으며, 웹 애플리케이션이나 **고급 기능(콘텐츠 기반 라우팅, SSL/TLS 종료)**이 필요한 서비스에 적합
   • Application Load Balancer는 **리버스 프록시(Reverse Proxy)**로 동작하여, 사용자가 정의한 규칙에 따라 들어오는 트래픽을 여러 백엔드 인스턴스로 분산
   • 매우 유연하게 구성할 수 있으며, 인터넷에 노출된 서비스(External) 또는 내부 애플리케이션(Internal) 모두에 사용 가능
2. Network Load Balancers (네트워크 로드 밸런서)
   • **Network Load Balancer는 OSI 모델의 4계층(Transport Layer)**에서 동작
   • TCP, UDP, 그 외 다양한 IP 프로토콜 트래픽을 효율적으로 처리
   1. Proxy Load Balancers (프록시형 네트워크 로드 밸런서)
      • 역시 **리버스 프록시(Reverse Proxy)**로 동작
      • 클라이언트 연결을 종료하고, 백엔드 서비스로 새로운 연결을 설정
      • 고급 트래픽 관리 기능을 제공하며, **온프레미스(데이터센터)**나 다양한 클라우드 환경의 백엔드와 연동 가능
   2. Passthrough Load Balancers (패스스루형 네트워크 로드 밸런서)
      • 프록시형과 달리, 트래픽을 수정하거나 연결을 종료하지 않음
      • 원본 트래픽(Source IP 포함)을 그대로 유지한 채로 백엔드로 직접 전달
      • 서버 직접 반환(Direct Server Return) 또는 다양한 IP 프로토콜을 처리해야 하는 애플리케이션에 적합

프록시는 클라이언트에서 외부 서버로의 트래픽을 감추기 위해 사용한다. 리버스 프록시는 클라이언트에서 백엔드 서버로 전달하는 트래픽을 적절히 처리하게 된다. 클라이언트가 프록시를 통해 서버에 접근하는지, 서버 쪽에서 프록시로 요청을 받아 백엔드 서버에 전달하는지에 따라 Forward / Reverse Proxy가 나뉘는 구조이다.

Cloud Domain Name Service

**DNS(도메인 이름 서비스)**는 인터넷의 호스트명(도메인 이름)을 IP 주소로 변환하는 역할을 한다. 쉽게 말해, 사용자가 www.example.com과 같은 주소를 입력하면, DNS가 이를 실제 서버의 IP 주소로 변환해 주는 것이다.

Google은 DNS 서비스를 운영하기 위해 매우 발전된 DNS 인프라를 구축하고 있다. Google은 이를 8.8.8.8 주소를 통해 누구나 사용할 수 있도록 개방하여 제공하고 있다.

구글 클라우드에서 구축한 어플리케이션의 인터넷 호스트명과 주소에 대해서는 어떨까? 이 경우 구글 클라우드의 Cloud DNS를 사용하여 호스트명 및 주소를 찾게 된다. 전 세계에서 해당 어플리케이션을 찾을 수 있도록 지원하는 관리형 DNS 서비스이다.

이 서비스는 구글과 동일한 인프라에서 실행되며 낮은 지연과 높은 가용성을 보장한다. 비용 효율적인 구조로 유저들에게 어플리케이션이 노출될 수 있도록 한다. Cloud DNS 도메인 정보가 중복되게 전세계에 분산되어 있어 유저는 가까운 DNS 서버 기준으로 응답을 받게 된다.

또한, Google Cloud Console, 명령줄 인터페이스(CLI), 또는 API를 통해 **수백만 개의 DNS 존(DNS Zones)과 레코드(DNS Records)**를 **게시(publish)**하고 관리할 수 있다.

1. DNS Zone: 하나의 도메인(또는 하위 도메인)의 DNS 레코드 집합 전체를 관리하는 논리적 단위. 폴더 / 관리 단위
2. DNS Records: DNS Zone 안에 포함되어 있는 개별 “도메인 이름 → 값 매핑” 정보. 그 안에 들어가는 설정 값들

[ DNS Zone: example.com ]
 ├── A record: example.com → 1.2.3.4
 ├── CNAME record: www.example.com → example.com
 ├── MX record: example.com → mail.example.com
 ├── TXT record: example.com → "some text"

SaaS기업, 대형 ISP가 자체 DNS 서비스를 운영하여 수십만 도메인 관리가 가능.

Cloud Content Delivery Network

구글은 엣지 캐시의 글로벌 시스템을 갖는다. 엣지캐시는 캐싱 서버(Cache Server)를 사용해 콘텐츠를 최종 사용자(End User)와 더 가까운 위치에 저장하는 기술이다.

Cloud CDN(Content Delivery Network)를 사용하면 어플리케이션에서의 컨텐츠 전송 속도를 가속화 할 수 있다. 이 말은 즉슨 유저들이 낮은 네트워크 레이턴시를 경험하고, 컨텐츠 원천 서버는 트래픽 부하가 줄어들어 안정성이 향상된다. 이를 통해 비용도 절감될 수 있다.

어플리케이션 로드 밸런서가 한번 세팅되면 Cloud CDN은 체크박스 하나로 쉽게 활성화 할 수 있다. 타사 CDN을 사용중이었더라도 구글 클라우드의 CDN Interconnect 파트너 프로그램 대상인 서비스였다면 그대로 사용 가능하다.

Connecting Networks to Google VPC

구글 VPC 네트워크는 다른 네트워크와 연결될 수 있다. 다른 네트워크란 온프레미스 네트워크(기업 내부 데이터센터 네트워크) 혹은 다른 환경을 (AWS, Azure 등) 의미한다. 이를 위해 여러 방법이 제공된다.

1. Cloud VPN(Virtual Private Network)
   • 터널 방식의 연결 구축
   • 연결을 동적으로 관리하고자 할 때는 Cloud Router를 사용
     • Cloud Router를 사용하여 다른 네트워크(예: 온프레미스 네트워크)와 Google VPC 간에 Border Gateway Protocol(BGP)을 사용하여 경로(Route) 정보 교환 가능
     • 이 방식을 통해 Google VPC에 새로운 서브넷(Subnet)을 추가했을 때, 온프레미스 네트워크에서도 자동으로 해당 서브넷에 대한 경로 정보가 업데이트되어 인식할 수 있게 됨
     • BGP 프로토콜을 통해 온프레미스와 Cloud Router 사이 세션이 구축되면, Google VPN 터널 + Cloud Router + 온프레미스 라우터가 모두 정상 동작하는 한 세션이 계속 유지됨. Cloud Router는 무료로 제공되는 인스턴스이고, VPN 유지에 의한 비용이 대부분이다.
2. Direct peering routes traffic through a Google PoP
   • 인터넷을 통해 네트워크를 연결하는 방법이 모든 상황에서 항상 최선의 선택은 아님. 그 이유는 보안상의 우려가 있을 수도 있고, 또는 대역폭(bandwidth)의 신뢰성 문제 때문일 수도 있음
   • **Google의 네트워크 거점(Point of Presence, PoP)**이 위치한 **공용 데이터센터(Public Datacenter)**에 자체 라우터(Router)를 배치하고, 이를 통해 Google 네트워크와 직접 트래픽을 교환하는 방식을 의미, 구글과 직접적인 계약 필요하고 Colocation 비용 추가
3. Carrier Peering
   • 구글 PoP에 직접 연결이 어려운 경우 Carrier Peering 프로그램에 참여한 **공인 서비스 파트너(Carrier/통신사)**와 계약을 맺어 Google 네트워크에 연결할 수 있다.
   • 고객의 온프레미스 네트워크에서 서비스 제공업체(통신사)의 네트워크를 통해 Google Workspace 및 몇몇 Google Cloud 제품들에 직접 액세스할 수 있습니다.
   • 구글의 공식 서비스 수준에서의 보장이 이루어지지 않기 때문에 통신사 품질에 의존적임
4. Deicated Interconnect (전용 회선)
   • Interconnection(네트워크 상호 연결)에서 최고 수준의 가용성이 중요한 경우 Google에 물리적이고 사설적인 연결을 구축할 수 있음
   • 장애 발생시 자동으로 Cloud VPN으로 전환하여 고가용성 확보
   • Dedicated Interconnect는 Google과 사설 전용 연결을 구성하여 최대 99.99% SLA 보장을 받을 수 있으며, VPN을 보완 구성함으로써 더욱 높은 수준의 연결 신뢰성을 확보할 수 있음
5. Partner Interconnect
   • 지원되는 서비스 제공업체(통신사/네트워크 파트너)를 통해, **온프레미스 네트워크와 Google Cloud의 VPC 네트워크 간 연결(Connectivity)**을 제공
   • Partner Interconnect는 온프레미스 네트워크와 Google VPC를 서비스 제공업체의 네트워크를 통해 연결하는 옵션으로, Dedicated Interconnect 대비 더 유연하게 구성 가능하고, 필요 시 99.99% SLA도 적용 가능하지만 Google은 Partner 제공 구간의 문제에 대해 책임지지 않음.
6. Cross-Cloud Interconnect
   • **Google Cloud와 다른 클라우드 서비스 제공업체(예: AWS, Azure 등) 간에 고대역폭(High-bandwidth)의 전용 연결(Dedicated Connectivity)**을 구축하도록 지원