[Supinfo][GCP] Google Cloud

1. VPC Networks

Google Cloud Virtual Private Cloud

• 전세계 단위로 동작하는 가상 네트워크
• 전역(Global) 단위 : 특정 region에 종속되지 않음
• Subnets은 지역(Region) 단위
• VPC는 기본적으로 서로 통신하지 X : Peering, VPN, Interconnect, Shared VPC로 연결 필요
• 같은 Subnet = 같은 Region : 같은 Region 안의 여러 Zone이 같은 서브넷을 공유
• 같은 VPC 안에 있으면 다른 Region이어도 서로 통신이 가능하지만, 같은 Region이어도 다른 VPC 면 인터넷을 통해서 통신해야된다

1) Subnet Creation Mode

• Custom Subnet Mode
  • 운영 환경에서 추천
  • 관리자가 Subnet을 직접 생성
  • IP 범위 겹침 방지
  • Firewall rules 없음
• Auto Subnet Mode
  • 테스트 환경에서 추천
  • 프로젝트 생성 시 생성되는 기본 VPC
  • 모든 Region에 /20 Subnet 자동 생성
  • Region 추가될 때마다 자동으로 Subnet 추가됨
  • 기본 Firewall rules 포함(TCP 22 등)

2) Shared VPC

한 조직 안에서 여러 프로젝트가 하나의 '중앙 VPC'를 공유하는 구조

• Host Project
  실제 VPC가 있는 프로젝트
  서브넷 생성 담당
• Service Projects
  애플리케이션이 배치되는 프로젝트
  네트워크 리소스는 중앙 팀에서 관리
  서브넷을 사용만 가능
• 목적
  회사 여러 팀이 동일 네트워크 정책을 써야 할 때
  기업 네트워크 구조 중앙화
  CIDR 충돌 방지
  보안 및 감사 중앙 집중
  대규모 기업, 팀 구조에 최적화
• 특징
  조직 내부에서만 작동
  네트워크 관리자는 Host Project만 관리
  Service Project는 VPC 수정 불가
  VM은 Service Project에 만들지만 Subnet은 Host Project에만 존재
• 보안 및 라우팅
  같은 VPC 내부이므로 전부 자동 라우팅
  firewall, routes 모두 한 네트워크이므로 관리 용이
• 시험 포인트
  서브넷 생성은 Host Project에서만 가능
  Service Project는 Subnet을 "사용"만 가능
  Shared VPC는 조직(Organization) 내부에서만 사용 가능
  Cross-organization 불가

3) VPC Network Peering

두 VPC 간 private IP 기반 통신 연결을 제공

• 목적
  빠르게 두 VPC를 private으로 연결
  네트워크를 합치지 않고도 통신 가능
  서로 다른 조직, 프로젝트 간 통신 가능
• 특징
  같은 Region일 필요 없음
  네트워크 간 격리된 상태에서 private 연결 -> 회계, 보안 분리를 유지하면서 통신 필요할 때 적합
  트랜짓(transit) 불가 : a-b, b-c 여도 a-c 통신 불가능
• 언제 사용?
  서로 다른 프로젝트 간 private 연결이 필요할 때
  SaaS 제공 업체와 private 연결이 필요할 때
  통합 네트워크는 필요 없지만 private 통신만 필요한 경우
• 시험 포인트
  peering은 양방향 설정 필요
  Firewall Rule 필요
  peering은 네트워크를 완전히 합치는 것이 X

4) Cloud VPN

VPN(IPsec)을 사용해 온프레미스 또는 외부 네트워크 ↔ GCP VPC를 안전하게 연결하는 서비스

• 목적
  온프레미스 <-> GCP 간 사설 통신
  외부 클라우드 <-> GCP 통신
  빠른 하이브리드 클라우드 구성
• 종류
  Classic VPN
  HA VPN(99.99% SLA)
• 특징
  Public internet 위에서 암호화된 터널
  1.5~3Gbps per tunnel
  여러 터널로 확장 가능 (ECMP)
• 언제 사용?
  온프레미스와 GCP를 빠르게 연결할 때
  기업 내부망과 GCP를 사설 통신으로 묶을 때
  Dedicated Interconnect 하기에는 비용/시간이 부족할 때
• 시험 포인트
  Cloud VPN은 인터넷을 사용 : public internet 위에서 IPsec 사용
  Cloud VPN은 사설 IP 연결 가능
  Classic VPN은 SLA 없음
  HA VPN은 SLA 99.99%
  VPN은 cross-organization도 가능

Q. In GCP, subnets are used mostly for IP addressing purposes.
GCP Subnet은 주로 VM에 내부 IP를 할당하기 위한 Pool(IP Range)을 제공하는 목적이 가장 크다.
GCP의 Subnet = 특정 Region에서 사용할 IP 주소 덩어리(CIDR Block)

cf) 온프레미스(On-premises)란?
조직 내부 건물(데이터센터, 서버실)에 하드웨어를 두고 직접 인프라를 관리·운영하는 방식

2. DNS

Domain Name System
도메인 이름을 IP 주소로 바꿔주는 시스템
예) www.google.com → 142.250.72.238
api.mycompany.com → 10.20.1.15
사람은 도메인이 기억하기 쉽고, 컴퓨터는 IP가 필요하므로 DNS가 둘 사이를 변환해주는 전화번호부 역할을 한다

GCP 내부에서 VM이 DNS 조회를 할 때 VM이 직접 DNS 서버를 설정하지 않는다
대신, 169.254.169.254 (Metadata Server) 이 주소가 자동으로 DNS Resolver 역할을 한다

• 왜 Metadata Server가 DNS Resolver?
  GCP가 VM에 내부 DNS 정보를 통제하기 쉽기 때문
  Internal DNS / Cloud DNS Private Zone 모두 여기로 라우팅됨
  VM에 공통된 DNS 구조 제공
  VM은 반드시 Metadata Server를 통해 DNS 요청을 한다

VM이 부팅되면 DHCP로 IP 주소와 함께 DNS 서버 주소(= Metadata Server)가 자동 제공된다
즉,따로 DNS 설정을 하지 않아도
GCP가 VM 네트워크 설정을 자동 구성
Internal DNS 및 Private Zone 조회 가능

1) Internal DNS

GCP가 VPC 내부에서 기본으로 제공하는 DNS 서비스
VM을 만들면 GCP가 자동으로 내부 DNS 이름을 만든다

• 특징
  같은 프로젝트, 같은 VPC 내부에서만 조회 가능 -> 다른 프로젝트나 다른 VPC에서는 Internal DNS 이름을 알 수 없음, 다른 VPC에서도 조회하려면 DNS Peering 필요
  Google이 자동 생성
  VM primary internal IP 기반
• 쓰는 이유
  VM끼리 IP가 아니라 이름으로 통신 가능
  VM IP가 바뀌어도 이름은 유지 (재생성 전까지)

2) Cloud DNS

Google Cloud가 제공하는 공식 DNS 서비스로 성능과 안정성이 매우 뛰어나다.

• Public DNS Zone
  인터넷 공개용 도메인
  예) www.mycompany.com
• Private DNS Zone
  GCP 내부 VPC에서만 보이는 도메인
  VPC 내부에서만 보이는 DNS 영역
  예) erp-back-end1.eu.local 10.10.0.100
  erp-back-end2.eu.local 10.10.0.101
  내부 전용 Application Load Balancer에도 사용
  GCP VPC는 Global이기 때문에 Private DNS Zone도 Global하게 적용된다
  : VPC 전체(여러 Region 포함)에서 동일하게 사용 가능
  : subnet이 어디 있든 같은 private zone 조회 가능
  같은 프로젝트, 같은 VPC에 속해있어야 조회 가능 -> 다른 VPC에서 조회하려면 DNS Peering 필요
• 특징
  완전 관리형
  고성능 (Google 글로벌 DNS 인프라)
  Anycast 기반
  100% SLA

3. Cloud CDN

CDN(Content Delivery Network)은 전 세계 여러 위치에 분산된 서버 네트워크를 이용해, 사용자에게 웹사이트, 이미지, 동영상 등 콘텐츠를 더 빠르고 안정적으로 전달하는 기술
반드시 Cloud Load Balancer 필요

• 기본 구성 요소
  - Origin Server (오리진 서버)
  원래 콘텐츠가 저장된 서버
  예: 웹사이트의 이미지, HTML, 동영상 등
  - Cache Server (캐시 서버)
  콘텐츠를 복제해서 저장하는 서버
  사용자가 요청하면 오리진 서버가 아니라 캐시 서버에서 콘텐츠를 전달

• CDN의 장점
  사용자 가까이에서 콘텐츠 제공 → 지연 시간(latency) 감소 → 빠른 웹/앱
  대역폭 절약 → 트래픽이 많은 사이트에 유리
  오리진 서버 부담 감소 → 서버 안정성 향상
  서버 네트워크가 분산되고 중복되어 가용성 증가

• 작동 방식
  - 사용자가 요청 → 가장 가까운 엣지 서버(Edge Server) 확인
  - 캐시 히트(Cache Hit)
  콘텐츠가 이미 캐시에 있음 → 바로 사용자에게 제공 → 빠름
  - 캐시 미스(Cache Miss)
  콘텐츠가 캐시에 없음 → 오리진 서버에서 가져와 캐시에 저장 후 제공

4. Connectivity

Hybrid Connectivity
온프레미스(On-prem 데이터센터), 다른 클라우드, GCP VPC 를 하나의 네트워크처럼 연결하는 전체 통신 구조
42 Regions, 127 Zones

POP이란?
Point of Presence
구글 네트워크 장비가 실제의 물리적 네트워크 시설에 설치된 위치

1) Public Internet VPN (IPsec VPN tunnel)

Encrypted tunnel to VPC networks through the public internet
인터넷 위에서 IPSEC VPN 터널로 사설 네트워크 연결
cloud에, cloud 끼리 연결하는 가장 빠른 방법
속도 1.5 ~ 3 Gbps per tunnel
static/dynamic (BGP) based VPN
비용 제일 저렴

2) Cloud Interconnect (전용 회선)

• Dedicated
  Dedicated, direct connection to VPC networks
  Higher bandwidth needs (10 Gbps or 100 Gbps per link)
• Partner
  Dedicated bandwidth, connection to VPC network through a service provider
  50 Mbps –10 Gbps per connection

3) Peering

5. Load Balancing

사용자 트래픽을 여러 백엔드 서버에 자동 분산하여 가용성·확장성·성능을 확보하는 서비스

• Layer 7 (Application LB)

• Layer 4 (Network LB)

6. Firewalls

VPC 네트워크 단위로 적용되는 상태 기반(Stateful) 분산 방화벽

• Ingress and Egress firewall (allow / deny rules)

• Stateful with Connection tracking

• Distributed: enforced on host => no choke points

• Flexible grouping mechanism for applications: tags,
  service accounts

• No support for dest IP match on ingress FW. no
  support for source IP match on egress FW

• Ingress
  외부 -> VM 들어오는 트래픽

• Egress
  VM -> 외부 나가는 트래픽

• 요소
  Direction : INGRESS / EGRESS
  Priority : 숫자 낮을수록 우선
  Target : 적용 대상 VM (Tag, SA)
  Source/Destination : IP 또는 subnet
  Allow/Deny : permit / 차단