Google ACE: VPC 네트워킹, 연결 및 트래픽 관리 — 학습 가이드

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

개요

Google Cloud의 Virtual Private Cloud (VPC) 네트워킹은 주소 지정, 라우팅, 보안 및 트래픽 관리에 대한 세분화된 제어 기능을 갖춘 소프트웨어 정의 글로벌 네트워킹 기본 요소를 제공합니다. 이 섹션에서는 Google Cloud 서비스, 온프레미스 환경, 공용 인터넷을 상호 연결하는 복원력 있고 안전하며 관측 가능한 네트워크를 구축하는 데 사용할 실용적인 설계 및 운영 주제에 중점을 둡니다.

핵심 VPC 아키텍처 및 IP 계획

• VPC 네트워크 및 서브넷

  • VPC는 글로벌 리소스이며, 서브넷은 리전별 리소스이고 여러 영역(zone)에 걸쳐 있을 수 있습니다. 해당 리전의 모든 영역에 있는 인스턴스는 서브넷을 사용할 수 있습니다.
  • 프로덕션 환경에는 커스텀 모드 VPC를 사용하십시오. 자동 모드는 사전 정의된 CIDR 범위 세트를 사용하여 리전당 하나의 서브넷을 미리 생성하며, 확장 시 IP 충돌 제약, 주소 공간 낭비, 리팩토링의 어려움을 초래할 수 있습니다.
  • 서브넷의 보조 IP 범위를 사용하면 GKE Pod/서비스 IP 및 VM용 별칭 IP를 사용할 수 있습니다. IP 재할당을 피하려면 기본 및 보조 CIDR을 미리 계획하십시오.

• IP 주소 계획

  • 연결할 수 있는 현재 및 미래의 모든 VPC와 온프레미스 네트워크에 대해 겹치지 않는 RFC1918 공간을 선택하십시오. 미래의 리전과 서비스를 위해 확장용 블록을 예약해 두십시오.
  • 성장을 고려하여 서브넷 크기를 적절하게 조정하고(예: /24 ~ /20), ACL 및 진단을 복잡하게 만드는 지나치게 큰 범위는 피하십시오.
  • IP 사용 내역을 문서화하십시오: 워크로드용 기본 범위, GKE용 보조 범위, NAT 풀 또는 서비스 엔드포인트용 예약 블록.

• 예시

undefined

undefined

라우팅, 방화벽 및 정책 계층 구조

• 경로 및 동적 라우팅 모드

  • 각 VPC에는 시스템에서 생성된 서브넷 경로, 기본 경로, 커스텀 정적 또는 동적 경로로 구성된 라우팅 테이블이 있습니다.
  • 동적 라우팅 모드:
    • 리전별: Cloud Router를 통해 학습된 동적 (BGP) 경로는 동일한 리전의 리소스만 사용할 수 있습니다.
    • 전역: 동적 경로는 VPC의 모든 리전에 있는 리소스가 사용할 수 있습니다. 여러 리전에서 온프레미스에 도달해야 하는 하이브리드 네트워크에는 전역 모드를 사용하는 것이 좋습니다.
  • 다음 홉: 기본 인터넷 게이트웨이(0.0.0.0/0), VPN 터널, Cloud Router (BGP), 인스턴스(라우팅 어플라이언스) 또는 가상 어플라이언스를 위한 내부 부하 분산기 다음 홉.
  • 경로 우선순위: 숫자가 낮을수록 우선순위가 높습니다. 우선순위를 잘못 구성하면 트래픽이 블랙홀 처리되거나 의도하지 않은 다음 홉으로 유출될 수 있습니다. 명확한 규칙을 사용하십시오(예: 기본 이그레스는 1000, 더 구체적인 경로는 900).

• 방화벽 계층 구조

  • VPC 방화벽 규칙은 상태 저장(stateful) 방식이며 패킷 전달 전에 평가됩니다. VPC 수준에 존재하며 모든 서브넷에 적용됩니다.
  • 계층적 방화벽 정책(조직, 폴더 또는 프로젝트에 연결)은 VPC 규칙보다 먼저 허용/거부를 강제합니다. 이를 사용하여 중앙 집중식 가드레일(예: 인터넷에 노출된 관리자 포트 거부)을 구현하십시오.
  • 암시적 규칙: 가장 낮은 우선순위로 암시적 이그레스 허용 및 암시적 인그레스 거부 규칙이 존재하며, 이는 제거할 수 없습니다. 모든 연결에는 명시적인 인그레스 허용 규칙이 필요합니다.

• 방화벽 규칙, 태그, 서비스 계정, 보안 태그

  • 타겟팅: 네트워크 태그 또는 서비스 계정을 사용하여 특정 VM에 규칙을 적용합니다. 서비스 계정 타겟팅은 더 강력한 ID 기반 제어를 제공합니다.
  • 보안 태그는 정책 타겟팅을 위해 중앙에서 관리되고 IAM으로 보호되는 라벨을 제공합니다. 워크로드가 스스로 태그를 연결하는 것을 방지하고 제로 트러스트 세분화를 지원합니다.
  • 로깅: 가시성과 비용의 균형을 맞추기 위해 중요한 규칙에 대해 선택적으로 방화벽 로깅을 활성화합니다. 전체 페이로드가 아닌 패킷을 샘플링합니다.
  • 일반적인 장애 모드: 상태 확인 소스 범위 누락, 응답 패킷 손실을 유발하는 비대칭 라우팅, 의도하지 않은 노출을 생성하는 지나치게 넓은 소스 범위.

• 예시

undefined

로드 밸런싱, IP, DNS 및 트래픽 관리

• Cloud Load Balancing 유형 및 동작

  • 전역 프록시 기반: External HTTP(S), External TCP Proxy, External SSL Proxy. Google 에지에서 클라이언트 연결을 종료하고, 애니캐스트 전역 VIP를 지원하며, 헤더(예: X-Forwarded-For)를 삽입합니다. 원본 클라이언트 IP는 L3 소스로 보존되는 대신 헤더나 PROXY 프로토콜(TCP용)을 통해 사용할 수 있습니다.
  • 리전별 패스스루: External Network Load Balancer 및 Internal TCP/UDP Load Balancer는 L4에서 트래픽을 라우팅하고 클라이언트 IP를 보존합니다. PROXY 프로토콜 없이 백엔드에서 소스 IP를 확인해야 할 때 사용합니다.
  • Internal HTTP(S) Load Balancer: 고급 라우팅 및 mTLS 옵션을 갖춘 내부 서비스용 리전 L7 프록시입니다.

• 백엔드 서비스, 상태 확인 및 트래픽 정책

  • 백엔드 서비스는 백엔드(인스턴스 그룹, NEG/VM/Endpoint, GKE 서비스), 분산 모드(UTILIZATION 또는 RATE), 용량 한도, 세션 어피니티, 연결 드레이닝을 정의합니다.
  • Google 상태 확인 시스템으로부터의 상태 확인 트래픽은 방화벽을 통과하도록 허용되어야 합니다. 비정상 백엔드는 자동으로 제거되며, 상태 확인이 잘못 구성되면 전체 서비스 중단을 유발할 수 있습니다.
  • 트래픽 정책에는 지역성(리전/영역), 오버플로 및 장애 조치 백엔드, 일부 LB 유형에서 점진적 출시를 위한 가중치 기반 트래픽 분할이 포함됩니다.

• 외부 및 내부 IP, 전달 규칙

  • 외부 및 내부 주소는 임시 또는 예약된 고정 주소일 수 있습니다. 전역 고정 외부 주소는 전역 LB에서 사용되며, 대부분의 다른 주소는 리전별입니다.
  • 전달 규칙은 IP:포트를 대상(예: targetHttpProxy 또는 backend service)에 매핑합니다. LB 유형에 맞게 전역 또는 리전 규칙을 선택해야 하며, 일치하지 않으면 생성이 금지됩니다.

• Cloud DNS

  • 영역: 공개 영역은 공용 인터넷에서 확인되고, 비공개 영역은 승인된 VPC에서만 확인할 수 있습니다. 관리형 레코드(A/AAAA, CNAME, TXT, MX, SRV 등)를 사용합니다.
  • 스플릿 호라이즌: 동일한 도메인에 대해 공개 영역과 비공개 영역을 모두 생성하여 내부 리졸버는 비공개 응답(예: ILB IP)을 받고, 외부 사용자는 인터넷 연결 IP를 받도록 합니다.
  • 비공개 DNS 전달: Cloud DNS 정책을 사용하여 인바운드 및 아웃바운드 전달을 통해 온프레미스 리졸버와 통합합니다. VPC 간 DNS 피어링을 사용하여 전체 피어링 연결 없이 비공개 영역을 공유합니다.

• 예시

  • gcloud compute forwarding-rules create web-ilb –region=us-central1 –load-balancing-scheme=INTERNAL_MANAGED –ports=80 –backend-service=web-be

하이브리드 및 비공개 연결

• Cloud Router, Cloud NAT 및 비공개 Google 액세스

  • Cloud Router는 BGP를 통해 온프레미스와 경로를 교환하고, VPC 서브넷을 공지하며, 온프레미스 프리픽스를 가져옵니다. 여러 리전에서 온프레미스 연결이 필요할 때 전역 동적 라우팅을 사용합니다.
  • Cloud NAT는 외부 IP가 없는 비공개 VM 및 GKE 노드에 인터넷 이그레스(egress)를 제공합니다. 포트 고갈을 피하기 위해 NAT IP 풀의 크기를 적절히 조정하고, 연결 끊김이 있는지 로그를 모니터링하여 그에 따라 주소를 확장합니다.
  • 비공개 Google 액세스(PGA)를 사용하면 비공개 VM이 기본 라우팅 경로를 통해 외부 IP 없이 Google API에 연결할 수 있습니다. Google API용 Private Service Connect(PSC)는 VPC 내에 정책 제어가 가능한 비공개 IP 엔드포인트를 제공하여 공용 이그레스를 완전히 피합니다. 더 엄격한 이그레스 제어와 일관된 DNS를 위해 PSC 엔드포인트를 사용하는 것이 좋습니다.

• Private Service Connect (생산자 및 소비자 서비스)

  • 생산자 프로젝트의 서비스 연결(service attachment) 뒤에 내부 서비스를 노출하고, 소비자 프로젝트의 비공개 엔드포인트를 통해 사용합니다. DNS 매핑과 명시적인 허용 정책으로 액세스를 제어합니다. 이는 VPC 피어링에 비해 격리 수준을 높이고 서비스 게시를 중앙 집중화합니다.

• VPC 네트워크 피어링, 공유 VPC 및 세분화

  • VPC 피어링은 VPC 간에 지연 시간이 짧은 비공개 연결을 제공합니다. 이는 비전이적(non-transitive)이며 IP 중복을 허용하지 않습니다. 커스텀 경로를 선택적으로 가져오거나 내보내면 연결성이 확장되지만, 여전히 전이적 라우팅을 생성하지는 않으므로 허브 앤 스포크(hub-and-spoke) 모델을 신중하게 계획해야 합니다.
  • 공유 VPC는 호스트 프로젝트의 서브넷을 중앙에서 관리하여 서비스 프로젝트에서 사용하도록 합니다. 이를 통해 애플리케이션별 IAM을 위임하면서 라우팅, 방화벽, NAT, LB를 중앙에서 관리할 수 있습니다. 세분화를 위해 계층적 방화벽 및 보안 태그와 결합하여 사용합니다.
  • Network Connectivity Center(NCC)는 스포크(VPN, Interconnect, 라우터 어플라이언스, VPC 스포크)를 오케스트레이션하고 엔터프라이즈 WAN 토폴로지를 일관되게 관리하는 허브를 제공합니다.

• Cloud VPN, Cloud Interconnect 및 BGP

  • Cloud VPN: 가용성 및 자동 경로 장애 조치를 위해 동적 라우팅(BGP)을 사용하는 HA VPN을 사용합니다. 가능하면 독립적인 Cloud VPN 인터페이스와 별개의 온프레미스 장치/링크에 걸쳐 피어당 두 개의 터널을 구축합니다.
  • Cloud Interconnect: Dedicated Interconnect는 10–100 Gbps의 비공개 링크를 제공하고, Partner Interconnect는 서비스 제공업체를 사용합니다. 복원력을 위해 다양한 에지 가용성 도메인에 이중화된 상호 연결을 배포하고, 지원되는 경우 BGP와 함께 BFD를 사용합니다.
  • 장애 도메인: 리전, 영역, 장치, 제공업체별로 격리합니다. 장애 조치를 정기적으로 테스트해야 합니다. 비대칭 경로는 온프레미스의 상태 저장 방화벽을 중단시킬 수 있습니다.

• 예시

  • gcloud compute routers create corp-router –region=us-central1 –network=prod-net –asn=64514
  • gcloud compute routers nats create nat-us-central1 –router=corp-router –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
  • gcloud compute vpn-gateways create ha-gw –region=us-central1 –network=prod-net

관측성 및 문제 해결

• Connectivity Tests

  • VPC, 온프레미스(하이브리드 링크 경유), 부하 분산기 전반에 걸쳐 소스와 대상 간의 연결 가능성을 시뮬레이션하고 검증합니다. 이 도구는 프로덕션 변경 전에 라우트, 방화벽 규칙, 구성을 평가하여 트래픽 유실 또는 잘못된 라우팅을 찾아냅니다.
  • 예시: gcloud beta network-management connectivity-tests create test-ilb –source-ip=10.10.1.5 –destination-ip=10.30.4.10 –protocol=TCP –destination-port=80 –project=my-proj

• VPC Flow Logs

  • 서브넷 수준에서 활성화하여 5-튜플 흐름, 바이트, 유실, 지연 시간에 대한 실시간 통계를 얻습니다. 분석을 위해 Cloud Logging, Pub/Sub 또는 BigQuery로 내보냅니다. 비용 관리를 위해 샘플링 및 메타데이터 수준을 조정합니다.
  • 사용 사례: 방화벽 효율성 검증, 데이터 유출 탐지, 용량 계획, SLO 모니터링.

• Packet Mirroring

  • 심층 패킷 검사(DPI) 또는 침입 탐지 시스템(IDS)을 위해 VM 또는 GKE 트래픽을 수집기 엔드포인트로 미러링합니다. 서브넷, 태그 또는 인스턴스별로 미러링 범위를 지정합니다. 성능 오버헤드를 이해하고 수집기가 미러링된 트래픽 양을 처리할 수 있는지 확인해야 합니다. 원본 헤더가 필요한 경우 NAT 이후의 트래픽은 미러링하지 마십시오.

• 일반적인 진단 패턴

  • 블랙홀: 라우트는 존재하지만 방화벽이나 비대칭 라우팅으로 인해 응답 경로가 차단됩니다. 양측에서 Connectivity Tests와 흐름 로그로 검증합니다.
  • 상태 확인 실패: 방화벽이 상태 검사기(health-checker)로부터의 트래픽을 허용하는지, 백엔드가 올바른 포트에서 리슨(listen)하는지 확인합니다. 동일 서브넷의 VM에서 로컬로 테스트합니다.
  • NAT 고갈: 거부된 흐름에서 “no available NAT ports"라는 이유를 찾습니다. NAT IP를 추가하거나 VM당 포트 제한을 줄입니다.

실용적인 문제 시나리오

Acme Retail은 비공개 백엔드, 공개 웹 진입점, 온프레미스 ERP를 갖춘 다중 리전 전자상거래 플랫폼을 운영합니다. 이들은 워크로드를 분할하고, Google API로의 비공개 이그레스(egress)를 제공하며, 모든 리전에서 하이브리드 연결을 활성화하고, 관측성을 유지하면서 보안을 강화해야 합니다.

1. 중앙 제어를 위해 커스텀 모드 Shared VPC 생성

• gcloud compute networks create acme-net –subnet-mode=custom
• 근거: 커스텀 모드는 자동 할당되는 CIDR을 피하고 의도적인 IP 계획을 가능하게 합니다. Shared VPC는 호스트 프로젝트에서 라우팅, 방화벽, NAT를 중앙 집중화하는 동시에 서비스 프로젝트가 안전하게 배포할 수 있도록 합니다.

2. GKE를 위한 보조 범위를 포함하여 서브넷 계획 및 생성

• gcloud compute networks subnets create web-us –region=us-central1 –network=acme-net –range=10.10.0.0/20 –secondary-range=pods=10.20.0.0/16,svcs=10.21.0.0/20
• 근거: 겹치지 않는 기본 및 보조 범위는 향후 피어링 충돌을 방지하고 IP 고갈 없이 GKE에 alias IP를 사용할 수 있게 합니다.

3. VPC 동적 라우팅을 전역(global)으로 설정하고 Cloud Router 배포

• gcloud compute networks update acme-net –bgp-routing-mode=global
• gcloud compute routers create hub-uc1 –region=us-central1 –network=acme-net –asn=64514
• 근거: 전역 모드는 BGP를 통해 학습된 온프레미스 라우트를 모든 리전에서 사용할 수 있게 하여 하이브리드 연결 및 장애 조치를 단순화합니다.

4. 온프레미스로의 HA VPN을 구축하고 서브넷 광고

• 다양한 온프레미스 장비에 걸쳐 두 개의 HA VPN 터널을 생성합니다. BGP를 사용하여 프리픽스(prefix)를 교환하고 정상적인 장애 조치(graceful failover)를 활성화합니다.
• 근거: 이중 터널은 단일 장애 지점(SPOF)을 제거합니다. BGP는 유지보수 또는 중단 시 라우트를 신속하게 수렴시킵니다.

5. 비공개 이그레스를 위해 Cloud NAT 배포 및 Google API용 PSC 배포

• gcloud compute routers nats create nat-uc1 –router=hub-uc1 –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
• Google API용 Private Service Connect 엔드포인트를 생성하고, 비공개 DNS를 업데이트하여 API 엔드포인트를 PSC에 매핑합니다.
• 근거: NAT는 외부 VM IP 없이 인터넷 이그레스를 허용합니다. PSC는 API 트래픽을 비공개 IP에 유지하고 명시적인 정책 제어 하에 두어 공용 이그레스 경로를 제거합니다.

6. 전역 외부 HTTP(S) 부하 분산기로 프런트엔드 구성, 내부 서비스는 내부 HTTP(S) 사용

• 관리형 인증서를 사용하여 전역 외부 HTTP(S) LB를 생성하고, NEG 백엔드를 가리키는 백엔드 서비스를 만듭니다.
• 마이크로서비스 간 mTLS를 사용하여 서비스 간 트래픽을 위한 리전별 내부 HTTP(S) LB를 생성합니다.
• 근거: 전역 프록시 LB는 애니캐스트(anycast), 자동 확장, CDN을 제공합니다. 내부 L7 LB는 내부(east-west) 트래픽에 대해 풍부한 라우팅 및 보안 기능을 제공합니다.

7. 계층적 방화벽 정책 및 워크로드 아이덴티티 타겟팅 구현

• 인터넷으로부터의 관리자 포트를 거부하는 조직 수준 정책을 연결합니다. LB 상태 확인 소스만 허용합니다.
• 계층 간 최소 권한 액세스를 위해 서비스 계정을 타겟팅하는 VPC 규칙을 생성합니다. 동적 분할을 위해 보안 태그를 사용합니다.
• 근거: 계층 구조는 가드레일을 중앙에서 강제합니다. 아이덴티티 기반 타겟팅은 태그 스푸핑(spoofing)에 저항하고 자동화를 단순화합니다.

8. 스플릿 호라이즌(split-horizon) 및 전달 기능으로 Cloud DNS 구성

• 웹 VIP용으로 공개 영역(public zone) acme.com을 생성하고, ILB에 매핑되는 내부 서비스 이름용으로 비공개 영역(private zone) acme.com을 생성합니다.
• 온프레미스 DNS로의 아웃바운드 전달과, 온프레미스에서 비공개 영역을 해석하기 위한 인바운드를 구성합니다.
• 근거: 스플릿 호라이즌은 데이터 유출을 방지하고 소스 네트워크에 따라 올바른 이름 해석을 보장합니다. 전달 기능은 레거시 네임스페이스를 통합합니다.

9. 가시성을 위해 Connectivity Tests, 흐름 로그, 패킷 미러링 사용

• 중요 경로(사용자 → 웹 LB, 웹 → 내부 서비스, 서비스 → 온프레미스 ERP)에 대한 테스트를 생성합니다.
• 서브넷에서 흐름 로그를 활성화하고, 추세 분석을 위해 BigQuery로 내보냅니다. 인시던트 대응 중에는 일시적으로 패킷 미러링을 활성화합니다.
• 근거: 선제적인 검증과 원격 측정(telemetry)은 평균 복구 시간(MTTR)을 단축하고, 잘못된 구성을 찾아내며, 용량에 대한 통찰력을 제공합니다.

10. 장애 시나리오 문서화 및 테스트

• VPN 터널, 리전, 백엔드 MIG의 손실을 시뮬레이션합니다. BGP 장애 조치, LB 상태 확인 제거, DNS 정확성을 검증합니다.
• 근거: 정기적인 게임 데이(Game Day)는 이중화에 대한 가정을 확인하고, 중단을 유발하기 전에 구성 드리프트(configuration drift)를 노출시킵니다.

← 컨테이너 · 모든 도메인 · 스토리지 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Google 찾아보기 →