Google PCNE: 라우팅, Network Connectivity Center 및 세그멘테이션 — 학습 가이드

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Cloud Network Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

Network Connectivity Center 및 전송 아키텍처

NCC 허브 앤 스포크
- 허브는 스포크 간 라우팅을 위한 컨트롤 플레인을 제공합니다. 스포크에는 VLAN 연결(Interconnect), HA VPN 터널, 라우터 어플라이언스 스포크, 사이트 간 데이터 전송을 지원하는 VPC 스포크가 포함됩니다. NCC 경로 테이블은 어떤 프리픽스를 가져오고 내보낼지, 어떤 스포크가 이를 수신할지를 제어하여 정밀한 세분화를 가능하게 합니다.
- 사이트 간 데이터 전송을 통해 온프레미스 사이트들은 허브를 전송 지점으로 사용하여 Google 백본을 통해 서로 통신할 수 있으며, 이로써 서드파티 전송의 필요성을 줄이고 운영을 단순화합니다.
라우터 어플라이언스 스포크 및 서드파티 NVA
- 라우터 어플라이언스 스포크는 Compute Engine에서 호스팅되는 가상 라우터/방화벽을 전송 또는 인라인 서비스로 온보딩합니다. 다음 홉으로 ILB를 사용하여 여러 어플라이언스에 걸쳐 확장성 및 상태 확인 기반 장애 조치를 달성할 수 있습니다.
- HA 설계: 서로 다른 영역에 최소 두 개의 어플라이언스를 배포하고, 가능하면 MIG와 함께 ILB 뒤에 배치합니다. 인스턴스에서 IP 전달을 활성화하고, ILB 다음 홉을 사용하여 대칭 스티어링을 사용합니다. 태그 또는 서비스 계정을 기반으로 한 정책 기반 경로를 사용하여 부하를 분산합니다.
- 처리량 및 장애 절충점: NVA는 인스턴스 유형과 NIC 대역폭에 의해 제한되므로 수평 확장을 계획해야 합니다. 어플라이언스 장애 또는 상태 확인 실패는 ILB 제거 및 빠른 장애 조치를 트리거하지만, 경로 수렴 타이머와 상태 임계값을 조정하여 플랩(flapping)을 방지해야 합니다.
전송 토폴로지 절충점
- NCC를 사용한 허브 앤 스포크: 중앙 집중식 정책, 높은 확장성, 명확한 장애 영향 반경 제어. 경로 테이블 설계 및 가져오기/내보내기 의도가 필요합니다.
- 전체 메시 피어링: 소수의 VPC에는 간단하고 중앙 전송이 없지만, 확장성이 떨어지며 전이성이나 서비스 삽입을 제공할 수 없습니다.
- 중앙 집중식 이그레스: 단일 NGFW 또는 NAT를 통한 간단한 보안 적용. 지연 시간을 추가하고 병목 지점이 될 수 있으며, 리전별 이그레스 지점과 자동 확장을 통해 완화할 수 있습니다.
- Cloud Router를 사용한 메시 VPN: 유연하고 신속하게 배포 가능. 피어 수가 증가함에 따라 운영 오버헤드가 증가하므로 NCC를 사용하여 통합하는 것을 고려해야 합니다.
Cloud VPN 고려사항
- 온프레미스 장치에 BGP가 없는 경우, 정적 경로와 신중하게 범위를 지정한 트래픽 선택기를 사용하는 정책 기반 Cloud VPN을 사용합니다. 장기적인 오버헤드를 최소화하기 위해 BGP를 사용하는 HA VPN으로의 최종 마이그레이션을 계획해야 합니다.
- 온프레미스 방향의 활성/대기 터널의 경우, 온프레미스에서 MED 또는 AS-path를 조작합니다. 단일 Cloud Router에 연결되는 이중 온프레미스 라우터의 경우, 두 경로의 설치와 ECMP를 허용하기 위해 동일한 피어 ASN을 사용하는 것이 좋습니다. 다른 피어 ASN을 사용하면 일반적으로 하나의 경로만 선택됩니다.

운영: 검증, 분석 및 장애 격리

연결성 검증 및 경로 분석
- Network Intelligence Center의 Connectivity Tests를 사용하여 VM, 부하 분산기, VPC 피어링, Cloud VPN, Interconnect 전반의 데이터 경로를 추적하고 방화벽 규칙과 경로를 검증합니다.
- VM/서브넷별 유효 경로를 분석하여 다음 홉(next hop)과 동적 프리픽스를 확인하고, 동적 라우팅 모드 범위가 의도와 일치하는지 검증합니다.
- 성능 또는 사용자 경험 문제의 경우, 전역 HTTP(S) 부하 분산을 선호하여 애니캐스트(anycast) 인그레스 및 에지 종단을 통해 전 세계 사용자의 지연 시간을 줄입니다. 네트워크 부하 분산기는 리전별 서비스이므로 전역 지연 시간을 개선하지 않습니다.
장애 격리 및 영향 반경(blast radius) 축소
- VPC, NCC 경로 테이블, 프로젝트별 Shared VPC 서브넷으로 분할하여 장애나 잘못된 구성이 의도치 않게 전파되는 것을 방지합니다.
- 피어링을 통한 전이적 종속성(transitive dependency)을 피합니다. 전송(transit)이 필요한 경우, NCC와 제어된 가져오기/내보내기를 사용하여 도달 가능성을 제한합니다.
- 중앙 집중식 조직 수준 방화벽 정책을 사용하여 기본 거부/허용 규칙을 설정하고, 로컬 정책으로 애플리케이션 예외를 처리합니다. 변경 사항은 Connectivity Tests로 테스트합니다.
- 인라인 보안이 필요한 경우, 상태 확인(health check) 및 정책 기반 라우팅을 갖춘 다음 홉(next-hop) ILB를 배포하여 정상적인 장애 조치(graceful failover)를 지원합니다. 외부 IP에 의존하지 않고 Private Google Access 또는 Cloud NAT를 통해 중요한 Google API에 도달할 수 있도록 보장합니다.
- BGP 세션과 경로 변경을 모니터링합니다. 경로 진동(route oscillation)과 비대칭 흐름(asymmetric flow)을 방지하기 위해 메트릭(MED, local preference)과 주소 계획을 표준화합니다.
간단한 구성 예시
- 정적 경로를 생성하여 인라인 ILB를 통해 트래픽을 전달:
  - gcloud compute routes create egress-via-ngfw –network my-vpc –destination-range 0.0.0.0/0 –next-hop-ilb ngfw-ilb –priority 900
- MED를 사용하여 온프레미스로 들어오는 두 개의 BGP 경로 중 하나를 선호하도록 설정 (온프레미스 라우터에서):
  - route-map FROM_GCP permit 10
  - set metric 20
  - router bgp 65000
  - neighbor 169.254.x.y route-map FROM_GCP in

실용적인 문제 시나리오

Acme Retail은 us-east1 및 europe-west1 근처에 두 개의 사용자 집단이 있는 멀티 프로젝트 Google Cloud 조직을 운영하고 있습니다. 이들은 리전 간 워크로드의 비공개 저비용 통신, 중앙 집중식 온프레미스 연결, 인터넷 이그레스(egress)를 위한 인라인 URL 필터링이 필요하며, 동시에 재무(Finance) 부서를 엔지니어링(Engineering) 부서로부터 격리해야 합니다.

호스트 프로젝트에 단일 Shared VPC를 구축하고 us-east1 및 europe-west1에 리전별 서브넷을 생성한 후, 동적 라우팅 모드를 전역(global)으로 설정합니다.

근거: 단일 VPC를 사용하면 피어링 오버헤드 없이 리전 간에 직접적인 RFC1918 통신이 가능합니다. 전역 동적 라우팅은 학습된 하이브리드 경로를 모든 리전에 설치하여 운영을 단순화하고 효율적인 VPC 내 흐름을 보장합니다.

필요한 서브넷만 각 서비스 프로젝트에 공유하고, 재무 부서와 엔지니어링 부서를 별도의 서비스 프로젝트에 배치합니다.

근거: 서브넷 수준 공유는 조직적 분할을 제공하고 의도치 않은 경로 노출을 최소화합니다. 엔지니어링 서브넷을 공유하지 않고 방화벽 정책 범위를 분리함으로써 재무 부서를 격리된 상태로 유지할 수 있습니다.

호스트 프로젝트에서 Dedicated Interconnect를 종단하고 Cloud Router를 연결합니다. 커스텀 공지(custom advertisement)를 사용하여 필요한 프리픽스만 공지합니다.

근거: 중앙 집중식 하이브리드 연결은 비용과 복잡성을 줄이면서 온프레미스에 도달하는 경로를 제어할 수 있게 해줍니다. 커스텀 공지는 과도한 노출을 방지하고 영향 반경을 억제합니다.

인라인 L7 URL 필터링 어플라이언스를 리전별 내부 TCP/UDP 부하 분산기 뒤에 삽입합니다. 각 리전에서 0.0.0.0/0 정적 경로를 ILB 다음 홉으로 지정하여 이그레스 트래픽을 유도합니다.

근거: ILB 다음 홉과 상태 확인을 함께 사용하면 어플라이언스 간 대칭 흐름을 보장하는 고가용성(HA) 서비스 삽입이 가능합니다. 기본 경로보다 높은 우선순위를 가진 정적 경로는 모든 이그레스 트래픽이 필터링되도록 보장합니다.

외부 IP가 없는 인스턴스가 Google API에 직접 도달할 수 있도록 보장합니다. 모든 서브넷에서 Private Google Access를 활성화하고, Google API VIP 범위에 대한 정적 경로를 기본 인터넷 게이트웨이로 추가하여 어플라이언스를 우회하도록 합니다.

근거: Private Google Access는 BigQuery 및 Pub/Sub에 대한 비공개 액세스를 유지합니다. 커스텀 경로는 필터를 통한 불필요한 헤어피닝(hairpinning)을 방지하여 비용과 지연 시간을 줄입니다.

재무 부서를 격리된 상태로 유지합니다. 계층적 방화벽 정책에서 프로젝트 간 트래픽을 거부하고 재무 부서와 엔지니어링 부서 간에 피어링을 구성하지 않습니다. 엔지니어링↔분석(Analytics) 부서 간 협업이 필요한 경우, 겹치지 않는 CIDR을 사용하여 전용 피어링 VPC 쌍을 생성합니다.

근거: VPC 경계, 피어링 부재, 조직 수준 방화벽 정책은 격리를 강제합니다. 특정 부서 간 연결을 위한 타겟 피어링은 전이성(transitivity) 없이 낮은 운영 오버헤드를 제공합니다.

검증 및 모니터링: Connectivity Tests를 사용하여 리전 간 도달 가능성과 어플라이언스 삽입을 확인합니다. Cloud Router BGP 상태와 경로 테이블을 모니터링합니다. 여러 터널이 있는 경우, 온프레미스 라우터에 MED를 구현하여 활성/대기(active/standby) 장애 조치를 구성합니다.