[Google Cloud Platform 기초] Virtual Private Cloud (VPC) Network의 능력

1. Routing table

물리적인 네트워크처럼 VPC도 라우팅 테이블이 있습니다. 라우팅 테이블은 같은 네트워크에서 두 인스턴스 사이의 선방향 트래픽을 보는 데에 사용됩니다. Sub-network나 GCP zone 사이에서 외부 IP 주소를 요구하지 않습니다. VPC 라우팅 테이블이 구축되면, 사용자가 제공하거나 관리하지 않아도 됩니다. 또한, 방화벽 인스턴스도 마찬가지입니다.

 

2. Firewall

VPC는 전 세계적으로 분배된 방화벽을 제공합니다. 인스턴스에 양방향 접근을 엄격히 제어할 수 있습니다. 방화벽 규칙을 compute engine 인스턴스의 metadata tage 측면에서 정의할 수 있습니다. 예를 들어, 웹 서비스를 'web"으로 태그 하고, IP 주소에 상관없이 80번과 443번 트래픽이 VM에 'web' 태그로 들어오도록 방화벽 규칙을 정할 수 있습니다.  

 

3. Peering relationship

여러 GCP 프로젝트와 VPC 사이에 상호 교환도 가능합니다. 두 VPC 사이에 peering 관계를 설정해 트래픽을 교환할 수 있습니다. 반면에, 누가, 무엇이 한 프로젝트에서 다른 프로젝트의 VPC와 교류하는 것을 IAM으로 제어하려면 shared VPC를 사용해야 합니다.

 

4. Cloud Load Balancing

한 순간에 4개의 VM으로 제공하다 다른 땐, 40개로 제공하는 application은 End user들이 어떻게 사용할 수 있을까요? Cloud Load Balancing으로 해결할 수 있습니다. Cloud Load Balancing은 사용자의 모든 트래픽을 소프트웨어로 정의해 완전히 분배합니다. Load balancer는 VM에서 실행되지 않기에 관리나 scaling 할 필요가 없습니다. HTTP, HTTPS, TCP, SSL, UDP 트래픽 앞에 붙이기만 하면 됩니다. 그러면 하나의 anycast IP가 전 세계에 region에서 모든 backend 인스턴스를 사용할 수 있도록 합니다.

 

자동적으로 multi-region으로 대체할 수 있는 Cross-region load balancing도 제공합니다. Backend가 불안정하면 트래픽을 분할하여 이동시키는 방법입니다. Cloud load balancing은 사용자, 트래픽, backend 상황, 네트워크 상태 그리고 다른 연관된 상태에 영향을 받습니다. 만약, 수요가 갑자기 증가한다면, pre-warning을 이용할 수 있습니다.

 

웹에 대한 cross regional load balancing이 필요하다면, HTTPS load blancing을 사용합니다. HTTP는 Secure Socket layer 트래픽이 아니기에 global SSL proxy load balancer를 사용합니다. 다른 TCP 트래픽이 Secure Socket layer을 사용하지 않는다면, global TCP proxy load balancer를 사용합니다. 이 두 프록시 서비스는 특정 포트 번호와 TCP에서만 작동합니다. UDP나 다른 포트 번호에서 사용하려면 regional load balancer를 이용해 GCP region을 오가며 load balance를 할 수 있습니다. 프로젝트 안에서 load balance를 하는 방법은 internal load balancer를 사용하는 것입니다. GCP internal IP 주소를 허락하고 Compute engine VM 사이에서 이것을 load balance를 합니다.

 

5. Cloud DNS

가장 유명한 Google 서비스는, 8.8.8.8로 public domain name service를 제공하는 것입니다. DNS는 인터넷 호스트 이름을 주소로 변경합니다. GCP에서는 Cloud DNS를 이용해 Google과 같은 인프라에서 DNS 서비스를 관리합니다.

 

Cloud DNS는 낮은 대기 시간과 높은 유용성, 비용 효율적인 방법으로 end user에게 서비스를 제공합니다. Cloud DNS도 프로그래밍이 가능하며, DNS 정보는 쓸모없는 위치에서 제공됩니다. 다수의 DNS zone에서 출시하고 관리할 수 있고, GCP console, command line linterface, API를 이용해 기록할 수 있습니다.

 

6. Google Cloud CDN

Edge caches에 대한 전 세계적 시스템을 갖추고 있습니다. Google Cloud CDN을 이용해 application에서 content 전송을 가속화합니다. 이 덕에 end user는 낮은 네트워크 대기시간을, content는 줄어든 load를 경험하고 사용자는 비용을 절약할 수 있습니다. HTTPS load balancing을 설정하면, 체크박스로 Cloud CDN을 이용할 수 있습니다.

 

7. Cloud Router

On-premise와 같은 다른 네트워크를 VPC에 연결하고 싶어 하는 사용자들이 많습니다. 이런 사용자들은, IPSEC protocol을 이용해 인터넷으로 Virtual Private Network connection을 사용합니다. 이것을 동적으로 사용하기 위해서 Cloud Router를 사용합니다. Cloud Router는 다른 네트워크와 Google VCP가 VPN에서 Border Gateway Protocol을 사용해 라우트 정보를 교환할 수 있도록 합니다. 예를 들어, 새로운 subnet을 VCP에 더하면 on-premises 네트워크가 자동적으로 라우트를 얻습니다.

 

8. Direct Peering

보안이나 믿을 수 있는 bandwidth를 이용하고 싶어 인터넷을 사용하지 않는 사용자는 Direct Peering을 이용합니다. Peering은 인터넷 접속 포인트와 트래픽을 교환하기 위해 동일한 public data center에 라우터를 놓는 것을 말합니다. 인터넷 접속 포인트에 없다고 하더라도, carrier peering program으로 파트너와 연결할 수 있습니다.

 

Peering의 불리한 점은, Google service level agreement에 포함되지 않는다는 것입니다. Google과의 가장 높은 가동시간(uptime)을 원하는 사용자는 Dedicated Interconnect를 사용해야 합니다. 이것으로 Google과 하나 이상의 direct private connections을 할 수 있습니다. 이 연결이 Google의 사양에 만족하는 특정 위성 배치라면, 99.99% SLA로 커버할 수 있습니다. VPN하에선 더 높은 신뢰도를 가질 수 있습니다.