VPC 네트워크 개요

Virtual Private Cloud(VPC) 네트워크는 Andromeda를 사용하여 Google의 프로덕션 네트워크 내에서 구현되는 물리적 네트워크의 가상 버전입니다. VPC 네트워크는 다음을 제공합니다.

  • Compute Engine 가상 머신(VM) 인스턴스에 대한 연결을 제공하며 여기에는 Google Kubernetes Engine(GKE) 클러스터, App Engine 가변형 환경 인스턴스 및 Compute Engine VM에 내장된 기타 Google Cloud 제품이 포함됩니다.
  • 내부 HTTP(S) 부하 분산을 위한 기본 내부 TCP/UDP 부하 분산 및 프록시 시스템을 제공합니다.
  • Cloud VPN 터널 및 Cloud Interconnect 연결을 사용하여 온프레미스 네트워크에 연결합니다.
  • Google Cloud 외부 부하 분산기에서 백엔드로 트래픽을 배포합니다.

프로젝트에는 여러 VPC 네트워크가 포함될 수 있습니다. 이를 금지하는 조직 정책을 만들지 않는 한, 새 프로젝트는 각 리전에 하나의 서브네트워크(서브넷)가 있는 기본 네트워크(자동 모드 VPC 네트워크)로 시작됩니다.

사양

VPC 네트워크에는 다음과 같은 특징이 있습니다.

  • VPC 네트워크는 연결된 라우터와 방화벽 규칙을 포함하여 전역 리소스입니다. VPC 네트워크는 특정 리전 또는 영역과 연결되지 않습니다.

  • 서브넷은 리전 리소스입니다. 각 서브넷은 IP 주소 범위를 정의합니다.

  • 인스턴스에서 송수신되는 트래픽은 네트워크 방화벽 규칙으로 제어할 수 있습니다. 규칙은 VM 자체에서 구현되므로 VM에서 나가거나 도착할 때만 트래픽을 제어하고 로깅할 수 있습니다.

  • VPC 네트워크 내의 리소스는 관련 네트워크 방화벽 규칙에 따라 내부(비공개) IPv4 주소를 사용하여 서로 통신할 수 있습니다. 자세한 내용은 네트워크 내 통신을 참조하세요.

  • 내부 IP 주소가 있는 인스턴스는 Google API 및 서비스와 통신할 수 있습니다. 자세한 내용은 서비스 비공개 액세스 옵션을 참조하세요.

  • Identity and Access Management(IAM) 역할을 사용하여 네트워크 관리를 보호할 수 있습니다.

  • 조직에서는 공유 VPC를 사용하여 VPC 네트워크를 공용 호스트 프로젝트에 유지할 수 있습니다. 동일한 조직의 다른 프로젝트에서 승인된 IAM 구성원은 공유 VPC 네트워크의 서브넷을 사용하는 리소스를 만들 수 있습니다.

  • VPC 네트워크 피어링을 사용하여 VPC 네트워크를 다른 프로젝트 또는 조직의 다른 VPC 네트워크에 연결할 수 있습니다.

  • Cloud VPN이나 Cloud Interconnect를 사용하여 하이브리드 환경에서 VPC 네트워크를 안전하게 연결할 수 있습니다.

  • VPC 네트워크는 Cloud VPN, Cloud NAT, Cloud Interconnect의 트래픽, 부하 분산프로토콜 전달을 위한 전달 규칙을 제외한 GRE 트래픽(베타)을 지원합니다. GRE를 통해 Secure Access Service Edge(SASE) 및 SD-WAN과 같은 서비스를 사용할 수 있습니다.

  • VPC 네트워크는 IPv4 유니캐스트 트래픽만 지원합니다. 네트워크 브로드캐스트, 멀티캐스트 또는 IPv6 트래픽을 지원하지 않습니다. VPC 네트워크의 VM은 IPv4 대상으로만 보내고 IPv4 소스로부터는 트래픽을 받기만 합니다. 그러나 전역 부하 분산기에 IPv6 주소를 만들 수는 있습니다.

네트워크 및 서브넷 용어

용어 서브넷서브네트워크는 동의어입니다. Google Cloud Console, gcloud 명령어, API 문서에서는 서로 바꿔서 사용됩니다.

서브넷은 (VPC) 네트워크와 같지 않습니다. 네트워크 및 서브넷은 Google Cloud에서 서로 다른 객체 유형입니다.

네트워크 및 서브넷

각 VPC 네트워크는 서브넷이라는 하나 이상의 유용한 IP 범위 파티션으로 구성됩니다. 각 서브넷은 리전과 연결됩니다. VPC 네트워크에는 IP 주소 범위가 연결되어 있지 않습니다. IP 범위는 서브넷에 대해 정의됩니다.

네트워크를 사용하려면 네트워크에 한 개 이상의 서브넷이 있어야 합니다. 자동 모드 VPC 네트워크는 각 리전에 자동으로 서브넷을 만듭니다. 커스텀 모드 VPC 네트워크는 서브넷 없이 시작되므로 서브넷 만들기를 전적으로 제어할 수 있습니다. 한 리전에 두 개 이상의 서브넷을 만들 수 있습니다. 자동 모드와 커스텀 모드 VPC 네트워크의 차이점에 대한 자세한 내용은 VPC 네트워크 유형을 참조하세요.

Google Cloud에서 리소스를 만들 때 네트워크와 서브넷을 선택합니다. 인스턴스 템플릿 이외의 리소스를 만들 때는 영역 또는 리전도 선택합니다. 영역을 선택하면 상위 리전도 암시적으로 선택됩니다. 서브넷은 리전 객체이므로 리소스에 선택한 리전에 따라 리소스에서 사용할 수 있는 서브넷이 결정됩니다.

  • 인스턴스를 만드는 프로세스에는 영역, 네트워크, 서브넷을 선택하는 과정이 포함됩니다. 선택 가능한 서브넷은 선택된 리전의 서브넷으로 제한됩니다. Google Cloud는 서브넷의 사용 가능한 주소 범위에 있는 IP 주소 하나를 인스턴스에 할당합니다.

  • 관리형 인스턴스 그룹을 만드는 프로세스에는 그룹 유형에 따라 영역 또는 리전을 선택하고 인스턴스 템플릿을 선택하는 과정이 포함됩니다. 정의된 서브넷의 리전이 관리형 인스턴스 그룹에 선택된 리전과 동일한 인스턴스 템플릿만 선택할 수 있습니다.

    • 인스턴스 템플릿은 전역 리소스입니다. 인스턴스 템플릿을 만드는 프로세스에는 네트워크 및 서브넷을 선택하는 과정이 포함됩니다. 자동 모드 VPC 네트워크를 선택하면 자동 서브넷을 지정하여 템플릿을 사용할 관리형 인스턴스 그룹의 선택된 리전에서 사용 가능한 서브넷 선택이 연기되도록 할 수 있습니다. 자동 모드 VPC 네트워크는 정의에 따라 모든 리전에서 서브넷을 가집니다.
  • Kubernetes 컨테이너 클러스터를 만드는 프로세스에는 영역 또는 리전(클러스터 유형에 따름), 네트워크, 서브넷을 선택하는 과정이 포함됩니다. 선택 가능한 서브넷은 선택된 리전의 서브넷으로 제한됩니다.

서브넷 생성 모드

Google Cloud는 서브넷 생성 모드에 따라 결정되는 두 가지 유형의 VPC 네트워크를 제공합니다.

  • 자동 모드 VPC 네트워크가 만들어질 때 네트워크 내의 각 리전에서 하나의 서브넷이 자동으로 만들어집니다. 자동으로 생성되는 이러한 서브넷은 10.128.0.0/9 CIDR 블록에 속하는 사전 정의된 IP 범위 집합을 사용합니다. 새 Google Cloud 리전을 사용할 수 있게 되면 이 블록의 IP 범위를 사용하여 리전의 새 서브넷이 자동으로 자동 모드 VPC 네트워크에 추가됩니다. 자동으로 생성되는 서브넷 외에도, 자동 모드 VPC 네트워크의 선택한 리전에 10.128.0.0/9 이외의 IP 범위를 사용하여 수동으로 서브넷을 더 추가할 수 있습니다.

  • 커스텀 모드 VPC 네트워크가 만들어질 때는 서브넷이 자동으로 만들어지지 않습니다. 이 네트워크 유형에서는 개발자가 서브넷과 IP 범위를 완전히 제어할 수 있습니다. 직접 지정한 IP 범위를 사용하여 선택한 리전에 만들 서브넷을 결정합니다.

자동 모드에서 커스텀 모드로 VPC 네트워크를 전환할 수 있습니다. 이는 편도 변환입니다. 커스텀 모드 VPC 네트워크는 자동 모드 VPC 네트워크로 변경할 수 없습니다. 필요에 맞는 네트워크 유형을 결정하려면 자동 모드 VPC 네트워크에 대한 고려 사항을 참조하세요.

기본 네트워크

명시적으로 중지하지 않는 한, 각각의 새 프로젝트는 기본 네트워크로 시작합니다. 기본 네트워크는 방화벽 규칙이 사전 지정된 자동 모드 VPC 네트워크입니다.

compute.skipDefaultNetworkCreation 제약조건으로 조직 정책을 만들면 기본 네트워크 생성을 중지할 수 있습니다. 이 정책을 상속하는 프로젝트에는 기본 네트워크가 없습니다.

자동 모드 VPC 네트워크에 대한 고려사항

자동 모드 VPC 네트워크는 쉽게 설정하고 사용할 수 있으며 다음과 같은 속성을 가진 사용 사례에 적합합니다.

  • 각 리전에 서브넷이 자동 생성되는 편이 유용합니다.

  • 서브넷의 사전 정의된 IP 범위가 다른 용도로(예: 온프레미스 리소스를 위한 Cloud VPN 연결) 사용할 IP 범위와 겹치지 않습니다.

커스텀 모드 VPC 네트워크는 더 유연하고 프로덕션에 더 적합합니다. 다음 속성은 커스텀 모드 VPC 네트워크가 권장되거나 필요한 사용 사례를 나타냅니다.

  • 각 리전에 하나의 서브넷을 자동으로 만들 필요가 없습니다.

  • 새 리전을 사용할 수 있을 때 새 서브넷이 자동으로 만들어지면 수동으로 만들어진 서브넷 또는 정적 경로에 사용되는 IP 주소와 겹치거나 전체적인 네트워크 계획에 차질이 발생할 수 있습니다.

  • 사용되는 리전과 IP 주소 범위를 포함하여 VPC 네트워크에 만들어지는 서브넷의 모든 부분을 직접 제어해야 합니다.

  • VPC 네트워크 피어링 또는 Cloud VPN을 사용하여 VPC 네트워크에 연결할 계획입니다. 모든 자동 모드 VPC 네트워크의 서브넷은 동일한 사전 정의된 IP 주소 범위를 사용하므로 자동 모드 VPC 네트워크를 상호 연결할 수 없습니다.

서브넷 범위

서브넷을 만들 때 서브넷의 기본 IP 주소 범위를 정의해야 합니다. VM 인스턴스, 내부 부하 분산기, 내부 프로토콜 전달 등의 리소스에 대한 기본 내부 주소는 서브넷의 기본 범위에서 가져옵니다. 원하는 경우 별칭 IP 범위에서만 사용되는 보조 IP 주소 범위를 서브넷에 추가할 수 있습니다. 하지만 서브넷의 기본 또는 보조 범위에서 인스턴스의 별칭 IP 범위를 구성할 수 있습니다.

VPC 네트워크의 모든 서브넷에 대한 각 기본 또는 보조 IP 범위는 고유한 유효 CIDR 블록이어야 합니다. 정의할 수 있는 보조 IP 범위 수는 네트워크별 한도를 참조하세요.

서브넷에 사전 정의된 연속 CIDR 블록을 구성할 필요는 없지만 원하면 그렇게 할 수 있습니다. 예를 들어 자동 모드 VPC 네트워크는 사전 정의된 자동 모드 IP 범위에 속하는 서브넷을 만듭니다.

자세한 내용은 서브넷 작업을 참조하세요.

유효한 범위

서브넷의 기본 및 보조 IP 주소 범위는 리전별 내부 IP 주소입니다. 다음 표에서는 유효한 범위를 설명합니다.

범위 설명
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
비공개 IP 주소 RFC 1918
100.64.0.0/10 공유 주소 공간 RFC 6598
192.0.0.0/24 IETF 프로토콜 할당 RFC 6890
192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)
문서 RFC 5737
192.88.99.0/24 IPv6-IPv4 릴레이(지원 중단됨) RFC 7526
198.18.0.0/15 벤치마크 테스트 RFC 2544
240.0.0.0/4

RFC 5735RFC 1112에 명시된 대로 향후 사용을 위해 예약됨(클래스 E)

일부 운영체제는 이 범위의 사용을 지원하지 않으므로 이 범위를 사용하는 서브넷을 만들기 전에 OS가 이를 지원하는지 확인합니다.

비공개적으로 재사용되는 공개 IP 주소 이 표에 나열된 RFC 범위에 속하지 않고 제한된 집합에 속하지 않는 IP 주소를 포함합니다. 이러한 주소를 서브넷 범위로 사용하면 Google Cloud가 이 범위로 트래픽을 공개적으로 라우팅하지 않습니다.

VPC 네트워킹 피어링의 경우 공개 IP 주소에 대한 서브넷 경로가 자동으로 교환되지 않습니다. 서브넷 경로가 자동으로 내보내지지 않지만 이를 사용하기 위해서는 경로를 가져오도록 피어 네트워크가 명시적으로 구성되어 있어야 합니다.

서브넷 범위에는 다음과 같은 제약이 있습니다.

  • 서브넷 범위는 제한된 범위와 일치하거나, 이보다 좁거나 넓을 수 없습니다. 예를 들어 169.0.0.0/8은 제한된 범위인 링크-로컬 범위 169.254.0.0/16(RFC 3927)와 겹치기 때문에 유효한 서브넷 범위가 아닙니다.

  • 서브넷 범위는 RFC 범위(이전 표 설명 참조) 및 비공개적으로 사용되는 공개 IP 주소 범위를 포함할 수 없습니다. 예를 들어 172.16.0.0/10은 RFC 1918 및 공개 IP 주소와 겹치기 때문에 유효한 서브넷 범위가 아닙니다.

  • 서브넷 범위는 여러 RFC 범위를 포함할 수 없습니다. 예를 들어 192.0.0.0/8192.168.0.0/16(RFC 1918) 및 192.0.0.0/24(RFC 6890)를 모두 포함하기 때문에 유효한 서브넷 범위가 아닙니다. 하지만 192.0.0.0/16192.0.0.0/24가 각각 포함된 서로 다른 기본 범위를 포함하는 서브넷 2개를 만들 수 있습니다. 또는 둘 중 하나를 보조 범위로 만들 경우 동일 서브넷에서 두 범위를 모두 사용할 수 있습니다.

제한된 범위

다음 표에 설명된 대로 제한된 범위에는 Google 공개 IP 주소 및 일반적으로 예약되는 RFC 범위가 포함됩니다. 이러한 범위는 서브넷 범위로 사용될 수 없습니다.

범위 설명
Google Cloud 넷블록을 포함한 Google API 및 서비스용 공개 IP 주소 이 IP 주소는 https://gstatic.com/ipranges/goog.txt에서 찾을 수 있습니다.
199.36.153.4/30199.36.153.8/30 비공개 Google 액세스 특정 가상 IP 주소
0.0.0.0/8 현재(로컬) 네트워크 RFC 1122
127.0.0.0/8 로컬 호스트 RFC 1122
169.254.0.0/16 링크-로컬 RFC 3927
224.0.0.0/4 멀티캐스트(클래스 D) RFC 5771
255.255.255.255/32 제한된 브로드캐스트 대상 주소 RFC 8190RFC 919

서브넷의 예약된 IP 주소

모든 서브넷은 기본 IP 범위에 4개의 예약된 IP 주소가 있습니다. 보조 IP 범위에는 예약된 IP 주소가 없습니다.

예약된 IP 주소 설명 예시
네트워크 서브넷의 기본 IP 범위에서 첫 번째 주소 10.1.2.0/2410.1.2.0
기본 게이트웨이 서브넷의 기본 IP 범위에서 두 번째 주소 10.1.2.0/2410.1.2.1
끝에서 두 번째 주소 나중에 사용할 수 있도록 Google Cloud가 예약한 서브넷의 기본 IP 범위에서 끝에서 두 번째 주소 10.1.2.0/2410.1.2.254
브로드캐스트 서브넷의 기본 IP 범위에서 마지막 주소 10.1.2.0/2410.1.2.255

자동 모드 IP 범위

이 표에서는 자동 모드 VPC 네트워크에서 자동으로 만들어진 서브넷의 IP 범위를 확인할 수 있습니다. 이러한 서브넷의 IP 범위는 10.128.0.0/9 CIDR 블록 내에 포함됩니다. 자동 모드 VPC 네트워크는 만들어지는 시점에 리전당 하나의 서브넷으로 구축되며 새 리전에서 자동으로 새 서브넷을 받습니다. 따라서 10.128.0.0/9의 미사용 부분은 이후 Google Cloud에서 사용할 수 있도록 예약됩니다.

리전 IP 범위(CIDR) 기본 게이트웨이 사용 가능한 주소(포함)
asia-east1 10.140.0.0/20 10.140.0.1 10.140.0.2 ~ 10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 10.170.0.2 ~ 10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 10.146.0.2 ~ 10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2 ~ 10.174.15.253
asia-northeast3 10.178.0.0/20 10.178.0.1 10.178.0.2 to 10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2 ~ 10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2~10.148.15.253
asia-southeast2 10.184.0.0/20 10.184.0.1 10.184.0.2~10.184.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2 ~ 10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 10.166.0.2 ~ 10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 10.132.0.2 ~ 10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 10.154.0.2 ~ 10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 10.156.0.2 ~ 10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 10.164.0.2 ~ 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 ~ 10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2 ~ 10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2 ~ 10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 10.128.0.2 ~ 10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 10.142.0.2 ~ 10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 10.150.0.2 ~ 10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 10.138.0.2 ~ 10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 10.168.0.2 ~ 10.168.15.253
us-west3 10.180.0.0/20 10.180.0.1 10.180.0.2 ~ 10.180.15.253
us-west4 10.182.0.0/20 10.182.0.1 10.182.0.2 ~ 10.182.15.253

경로 및 방화벽 규칙

경로

경로란 인스턴스에서 나가는 패킷(이그레스 트래픽)의 경로를 나타냅니다. Google Cloud의 경로는 시스템 생성 경로와 커스텀 경로라는 두 가지 카테고리로 나뉩니다.

모든 새로운 네트워크는 두 가지 유형의 시스템 생성 경로로 시작합니다.

  • 기본 경로는 트래픽이 VPC 네트워크에서 나가는 경로를 정의합니다. 이 경로는 인터넷 액세스 요구사항을 충족하는 VM에 일반적인 인터넷 액세스 기능을 제공합니다. 또한 비공개 Google 액세스의 일반적인 경로도 제공합니다.

  • 서브넷과 연결된 각 IP 범위에 대해 서브넷 경로가 하나씩 생성됩니다. 모든 서브넷에는 기본 IP 범위에 대한 서브넷 경로가 하나 이상 있으며, 서브넷에 보조 IP 범위를 추가하면 서브넷에 대한 추가 서브넷 경로가 생성됩니다. 서브넷 경로는 트래픽이 서브넷을 사용하는 VM에 도달하는 경로를 정의합니다. 서브넷 경로는 수동으로 삭제할 수 없습니다.

커스텀 경로는 직접 만든 정적 경로 또는 하나 이상의 Cloud Router에서 자동으로 관리하는 동적 경로입니다. 자세한 내용은 커스텀 경로를 참조하세요.

Google Cloud의 라우팅에 대한 자세한 내용은 경로 개요를 참조하세요.

동적 라우팅 모드

각 VPC 네트워크에는 연결된 동적 라우팅 모드가 있으며, 이 모드는 모든 Cloud Router의 동작을 제어합니다. Cloud Router는 VPC 네트워크로 가는 경로를 공유하고, 사용자가 Cloud VPN 터널(동적 라우팅 사용), Dedicated Interconnect 또는 Partner Interconnect를 사용하여 VPC 네트워크를 다른 네트워크에 연결할 때 연결된 네트워크에서 커스텀 동적 경로를 학습합니다.

  • 리전별 동적 라우팅은 기본값입니다. 이 모드에서 VPC 네트워크의 지정된 Cloud Router에 의해 학습된 온프레미스 리소스 경로는 Cloud Router와 동일한 리전의 서브넷에만 적용됩니다. 커스텀 공지로 수정하지 않는 한, 각 Cloud Router는 리전의 서브넷 경로를 온프레미스 대응 라우터와만 공유합니다.

  • 전역 동적 라우팅은 네트워크의 모든 Cloud Router의 동작을 변경하여 온프레미스 리소스로 연결되는 학습된 경로를 리전에 관계없이 VPC 네트워크의 모든 서브넷에서 사용할 수 있도록 합니다. 커스텀 공지로 수정하지 않는 한, 각 Cloud Router는 VPC 네트워크의 모든 서브넷 경로를 온프레미스 대응 라우터와 공유합니다.

Cloud Router가 공유하는 경로 집합을 커스텀할 수 있는 방법은 커스텀 공지를 참조하세요.

동적 라우팅 모드는 VPC 네트워크를 만들거나 수정할 때 설정할 수 있습니다. 동적 라우팅 모드를 리전에서 전역으로, 또는 그 반대로 제한 없이 변경할 수 있습니다. 자세한 내용은 동적 라우팅 모드 변경을 참조하세요.

방화벽 규칙

방화벽 규칙은 네트워크에서 나가는(이그레스) 트래픽과 들어오는(인그레스) 트래픽 모두에 적용됩니다. 방화벽 규칙은 VM 인스턴스 간의 통신을 포함하여 전적으로 네트워크 내에서 이루어지는 트래픽도 제어합니다.

모든 VPC 네트워크에는 두 가지 묵시적인 방화벽 규칙이 있습니다. 하나는 모든 이그레스 트래픽을 허용하는 묵시적 규칙이고, 다른 하나는 모든 인그레스 트래픽을 거부하는 묵시적 규칙입니다. 묵시적 규칙은 삭제할 수는 없지만 직접 재정의할 수는 있습니다. Google Cloud는 방화벽 규칙에 관계없이 항상 일부 트래픽을 차단합니다. 자세한 내용은 차단된 트래픽을 참조하세요.

어떤 방화벽 규칙이 특정 연결을 허용하거나 거부하는지를 모니터링하려면 방화벽 규칙 로깅을 참조하세요.

커뮤니케이션 및 액세스

네트워크 내 통신

시스템 생성 서브넷 경로는 내부(비공개) IP 주소를 사용하여 네트워크 내의 인스턴스 간에 트래픽을 전송하기 위한 경로를 정의합니다. 모든 네트워크에는 인그레스 트래픽에 적용되는 묵시적 거부 방화벽 규칙이 있으므로 인스턴스 간 통신을 위해서는 적절한 방화벽 규칙도 구성해야 합니다.

기본 네트워크를 제외하고 인스턴스 간 통신을 허용하려면 우선순위가 더 높은 인그레스 방화벽 규칙을 명시적으로 만들어야 합니다. 기본 네트워크에는 네트워크 내에서 인스턴스 간 통신을 허용하는 default-allow-internal 규칙을 포함하여 묵시적 규칙 외에도 여러 가지 방화벽 규칙이 포함되어 있습니다. 기본 네트워크에는 RDP 및 SSH와 같은 프로토콜을 허용하는 인그레스 규칙도 있습니다.

기본 네트워크에 제공되는 규칙은 Cloud Console을 사용하여 만드는 새 자동 모드 VPC 네트워크에 적용할 수 있는 옵션으로도 제공됩니다.

인터넷 액세스 요구사항

인스턴스에서 발신 인터넷 액세스 권한을 가지려면 다음 기준을 충족해야 합니다.

  • 네트워크에 대상 IP 범위가 최대한 포괄적인(0.0.0.0/0) 유효한 커스텀 경로나 기본 인터넷 게이트웨이 경로가 있어야 합니다. 이 경로는 인터넷 경로를 정의합니다. 자세한 내용은 경로를 참조하세요.

  • 방화벽 규칙이 인스턴스의 이그레스 트래픽을 허용해야 합니다. 우선순위가 더 높은 규칙에 의해 재정의되지 않는 한 이그레스 트래픽에 적용되는 묵시적 허용 규칙은 모든 인스턴스에서 발신되는 트래픽을 허용합니다.

  • 다음 중 하나에 해당해야 합니다.

    • 인스턴스에 외부 IP 주소가 있어야 합니다. 인스턴스를 만들 때 또는 인스턴스를 만든 후 인스턴스에 외부 IP 주소를 할당할 수 있습니다.

    • 인스턴스는 정적 0.0.0.0/0 경로의 대상인 Cloud NAT 또는 인스턴스 기반 프록시를 사용할 수 있어야 합니다.

App Engine용 통신 및 액세스

VPC 방화벽 규칙은 Compute Engine VM과 같이 VPC 네트워크에서 실행하는 리소스에 적용됩니다. App Engine 인스턴스의 경우 방화벽 규칙은 다음과 같이 작동합니다.

  • App Engine 표준 환경: App Engine 방화벽 규칙만 인그레스 트래픽에 적용됩니다. App Engine 표준 환경 인스턴스는 VPC 네트워크 내에서 실행되지 않으므로 VPC 방화벽 규칙이 적용되지 않습니다.

  • App Engine 가변형 환경: App Engine 및 VPC 방화벽 규칙이 인그레스 트래픽에 적용됩니다. 인바운드 트래픽은 두 유형의 방화벽 규칙 모두에서 허용되는 경우에만 허용됩니다. 아웃바운드 트래픽의 경우 VPC 방화벽 규칙이 적용됩니다.

App Engine 인스턴스에 대한 액세스를 제어하는 방법에 대한 자세한 내용은 앱 보안을 참조하세요.

외부 IP 주소에 대한 Traceroute

내부적인 이유로 Google Cloud는 Google 네트워크에서 다음 홉을 통과하는 패킷의 TTL 카운터를 증가시킵니다. 일부 홉에서는 TTL이 만료되지 않으므로 traceroutemtr 같은 도구에서 불완전한 결과를 제공할 수 있습니다. 다음과 같은 경우 Google 네트워크 내부와 외부에 있는 홉이 숨겨질 수 있습니다.

  • Compute Engine 인스턴스에서 다른 Google Cloud 리소스의 외부 IP 주소나 인터넷의 목적지를 포함한 외부 IP 주소로 패킷을 보낼 때

  • Compute Engine 인스턴스 또는 다른 Google Cloud 리소스와 연결된 외부 IP 주소로 패킷을 보낼 때

숨겨진 홉 수는 인스턴스의 네트워크 서비스 등급, 리전, 기타 요인에 따라 다릅니다. 몇 개의 홉만 있는 경우에는 모두 숨겨져 있을 수 있습니다. traceroute 또는 mtr 결과에서 홉이 누락되었다고 아웃바운드 트래픽이 삭제된 것은 아닙니다.

이 동작에 대한 해결 방법은 없습니다. VM과 연결된 외부 IP 주소에 연결되는 타사 모니터링을 구성하는 경우 이 점을 고려해야 합니다.

이그레스 처리량 한도

네트워크 처리량 정보는 네트워크 대역폭 섹션에서 확인할 수 있습니다.

패킷 크기

패킷 크기에 대한 정보는 최대 전송 단위(MTU) 섹션에 있습니다.

VPC 네트워크 예시

다음 예시에서는 두 리전에 3개의 서브넷이 있는 커스텀 모드 VPC 네트워크를 보여줍니다.

VPC 네트워크 예시(확대하려면 클릭)
VPC 네트워크 예시(확대하려면 클릭)
  • Subnet1은 us-west1 리전에서 10.240.0.0/24로 정의됩니다.
    • us-west1-a 영역의 두 개 VM 인스턴스가 이 서브넷에 있습니다. 두 개의 IP 주소는 모두 subnet1의 가용 주소 범위에 속합니다.
  • Subnet2는 us-east1 리전에서 192.168.1.0/24로 정의됩니다.
    • us-east1-a 영역의 두 개 VM 인스턴스가 이 서브넷에 있습니다. 두 개의 IP 주소는 모두 subnet2의 가용 주소 범위에 속합니다.
  • Subnet3도 us-east1 리전에서 10.2.0.0/16으로 정의됩니다.
    • us-east1-a 영역의 VM 인스턴스 하나와 us-east1-b 영역의 두 번째 인스턴스는 각각 subnet3에 있으며 사용 가능한 범위에서 IP 주소를 수신합니다. 서브넷은 리전 리소스이므로 인스턴스는 네트워크 인터페이스가 각자의 영역이 포함된 동일한 리전의 서브넷과 연결되도록 할 수 있습니다.

최대 전송 단위

VPC 네트워크의 기본 최대 전송 단위(MTU)1460바이트입니다. 하지만 VPC 네트워크의 MTU를 1500바이트로 구성할 수 있습니다.

MTU는 헤더와 데이터를 포함하여 네트워크 계층 프로토콜에서 지원되는 최대 패킷 크기(바이트)를 의미합니다. Google Cloud에서는 각 VPC 네트워크의 MTU를 설정하며, 해당 네트워크를 사용하는 VM 인스턴스도 해당 MTU를 인터페이스에 사용하도록 구성해야 합니다. VM이 DHCP를 사용하여 IP 주소를 요청하면 네트워크의 MTU 설정이 VM에 전달됩니다. DHCP 옵션 26에는 네트워크의 MTU가 포함됩니다.

MTU는 UDP 및 TCP 트래픽에 모두 영향을 미칩니다.

  • UDP 패킷이 대상에서 수신할 수 있는 것보다 크거나 대상 경로의 일부 네트워크 링크에서 최대 MTU를 초과하는 경우 Don't-Fragment 플래그를 설정하면 패킷이 삭제됩니다. 삭제되면 Fragmentation-Needed 유형의 ICMP 패킷이 발신자에게 다시 전송됩니다. PMTUD를 참조하세요.
  • UDP 패킷이 대상에서 수신할 수 있는 것보다 크거나 대상 경로의 일부 네트워크 링크에서 최대 MTU를 초과하는 경우 Don't-Fragment 플래그를 설정하지 않으면 일반적으로 패킷이 단편화됩니다. 이러한 단편화는 불일치가 감지된 경우에 수행되며, MTU보다 큰 패킷이 전송된 경우 중간 라우터 또는 발신자 자체의 문제일 수 있습니다.
  • TCP는 연결 설정 중에 최대 세그먼트 크기(MSS)를 협상합니다. 그런 다음 패킷이 두 연결 엔드포인트의 더 작은 MTU 크기로 세분화됩니다.

VM 및 MTU 설정

Google 제공 OS 이미지를 기반으로 하는 Linux VM은 생성 시 인터페이스 MTU를 VPC 네트워크의 MTU로 자동으로 설정합니다. VM에 여러 네트워크 인터페이스가 있는 경우 각 인터페이스는 연결된 네트워크의 MTU로 설정됩니다. VM이 실행 중인 VPC의 MTU를 변경할 경우 해당 VM을 중지한 후 다시 시작하여 새 MTU를 다시 시작해야 합니다. VM이 다시 시작되면 변경된 네트워크 MTU가 DHCP에서 해당 VM으로 전달됩니다.

Windows VM은 시작 시 VPC 네트워크의 MTU를 사용하도록 인터페이스를 자동으로 구성하지 않습니다. 대신 Google 제공 OS 이미지를 기반으로 하는 Windows VM이 고정 MTU인 1460으로 구성됩니다. 각 Windows VM에서 다음 명령어를 실행하여 MTU를 설정합니다. netsh interface ipv4 set subinterface NAME mtu=1500 store=persistent

커스텀 이미지를 사용하는 VM의 MTU 설정을 확인합니다. VPC 네트워크의 MTU를 따를 수도 있지만 그러면 MTU가 고정 값으로 설정될 수도 있습니다.

예기치 않은 네트워크 연결을 최소화하기 위해 Google Cloud는 다음 절차에 따라 VPC 네트워크의 MTU를 변경할 것을 권장합니다.

  1. VPC 네트워크의 모든 VM을 중지합니다.
  2. VPC 네트워크의 MTU를 변경합니다.
  3. VPC 네트워크의 모든 VM을 시작합니다. Google 게스트 환경이 있는 Linux VM과 DHCP 옵션 26을 사용하여 MTU를 설정하는 VM은 시작 시 MTU를 올바르게 설정합니다.
  4. 모든 Windows VM과 고정 MTU 구성을 사용하는 VM이 새 MTU 값을 사용하도록 구성합니다.

다른 MTU 네트워크로 서비스 마이그레이션

기존 네트워크의 MTU를 변경하는 대신 새 네트워크의 새 VM으로 서비스를 마이그레이션할 수도 있습니다. 이 경우 마이그레이션 중에 모든 VM에서 액세스해야 하는 서버(예: 데이터베이스 서버)가 있을 수 있습니다. 그런 경우에는 다음과 같은 일반적인 접근 방식으로 원활하게 마이그레이션할 수 있습니다.

  1. 새 MTU로 새 네트워크를 만듭니다.
  2. 새 네트워크에 필요한 방화벽 규칙 및 경로를 만듭니다.
  3. 이전 네트워크에 여러 네트워크 인터페이스가 있는 VM을 만듭니다. 한 인터페이스는 새 MTU를 사용하여 새 네트워크에 연결하고 다른 인터페이스는 이전 MTU를 사용하여 이전 네트워크에 연결합니다.
  4. 이 새 VM을 기존 VM의 보조 서버로 구성합니다.
  5. 기본 서버를 보조 서버로 장애 조치합니다.
  6. 새 네트워크에 새 VM을 만듭니다. VM을 처음부터 새로 만들거나, 기존 이미지를 사용하여 만들거나, 기존 VM의 스냅샷을 만들고 이를 통해 새 영구 디스크를 채우는 방식으로 만들 수 있습니다.
  7. 운영 서버를 사용하도록 이러한 VM을 구성합니다.
  8. 트래픽을 새 VM으로 마이그레이션합니다.
  9. 이전 네트워크를 삭제하려는 경우 새 네트워크에 새 서버를 만들고 기존 서버와 동기화한 후 새 서버로 장애 조치합니다.
  10. 이전 서버 및 이전 네트워크를 삭제합니다.

MTU 불일치 결과

일치하지 않는 MTU는 MTU 설정이 다른 2개의 통신 VM 인스턴스로 정의됩니다. 이로 인해 간혹 연결 문제가 발생할 수 있습니다. 구체적인 사례로는 인스턴스를 라우터로 사용하고 VM 내에서 Kubernetes를 사용하는 경우가 있습니다.

대부분의 경우 MTU가 서로 다른 인스턴스 간에 설정되는 TCP 연결은 MSS 협상으로 인해 성공하며, 연결의 양쪽 끝단은 두 MTU 중 적은 것을 사용하는 데 동의합니다.

피어링된 VPC 네트워크 간의 MTU 차이점

VPC 네트워크 피어링이 네트워크의 MTU 간 차이점을 처리하는 방법에 대한 자세한 내용은 MTU 고려사항을 참조하세요.

Cloud VPN과의 MTU 차이점

Cloud VPN 및 MTU에 대한 자세한 내용은 터널 MTU를 참조하세요.

Cloud Interconnect와의 MTU 차이점

Cloud Interconnect의 현재 MTU는 1,440입니다.

통신 VM의 MTU가 1500인 경우 MSS 클램핑이 TCP 연결의 MTU를 1440으로 줄이고 TCP 트래픽이 진행됩니다.

MSS 클램핑은 UDP 패킷에 영향을 미치지 않으므로 VPC 네트워크의 MTU가 1500인 경우 1,412바이트가 넘는 데이터가 포함된 UDP 데이터그램(1,412바이트 UDP 데이터 + 8바이트 UDP 헤더 + 20바이트 IPv4 헤더 = 1,440)이 삭제됩니다. 이 경우 다음 중 하나를 수행할 수 있습니다.

  • 연결된 VPC 네트워크의 MTU를 1460으로 낮춥니다.
  • 더 작은 UDP 패킷을 전송하도록 애플리케이션을 조정합니다.

네트워크 성능

지연 시간

Google Cloud 네트워크에서 측정된 리전 간 지연 시간은 라이브 대시보드에서 확인할 수 있습니다. 대시보드는 PerfKit Benchmarker를 사용하여 이러한 결과를 재현하기 위해 Google Cloud의 리전 간 지연 시간 중앙값과 처리량 성능 측정항목 및 방법론을 보여줍니다.

Google Cloud는 일반적으로 50번째 백분위수에서 55μs 미만의 왕복 지연 시간과 동일한 영역에 있는 c2-standard-4 VM 인스턴스 간의 99번째 백분위수에서 80μs 미만의 꼬리 지연 시간을 측정합니다.

Google Cloud는 일반적으로 50번째 백분위수에서 45μs 미만의 왕복 지연 시간과 지연 시간이 짧은 동일한 네트워크에 있는 c2-standard-4 VM 인스턴스 간의 99번째 백분위수에서 60μs 미만의 꼬리 지연 시간을 측정합니다('압축' 배치 정책). 압축 배치 정책은 VM이 지연 시간이 짧은 동일한 네트워크 내에 실제로 위치하도록 하여 네트워크 지연 시간을 줄여줍니다.

방법론: 영역 내 지연 시간은 모든 영역 c2 인스턴스에서 한 쌍의 c2-type VM 간에 netperf TCP_RR 벤치마크를 지속적으로 실행하는 블랙박스 프로버를 통해 모니터링됩니다. 압축 배치 정책을 사용하거나 사용하지 않고 설정할 수 있도록 P50 및 P99 결과를 수집합니다. TCP_RR 벤치마크는 트랜잭션 요율을 측정하여 요청/응답 성능을 측정합니다. 애플리케이션에 가능한 최대 지연 시간이 필요한 경우 c2 인스턴스를 사용하는 것이 좋습니다.

패킷 손실

Google Cloud는 모든 리전 간 왕복 손실을 주기적으로 측정하여 리전 간 패킷 손실을 추적합니다. Google은 이러한 측정의 글로벌 평균을 0.01% 미만으로 설정합니다.

방법론: 블랙박스 VM-VM 프로브는 핑을 사용하여 모든 영역 쌍의 패킷 손실을 모니터링하고 결과를 하나의 전역 손실 측정항목으로 집계합니다. 이 측정항목은 1일 기간으로 추적됩니다.

다음 단계