Google PCNE: 부하 분산, Cloud CDN 및 글로벌 트래픽 관리 — 학습 가이드

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

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

개요

이 섹션에서는 Google Cloud Load Balancing, Cloud CDN, 글로벌 트래픽 관리가 함께 작동하여 복원력 있고, 성능이 뛰어나며, 안전한 서비스를 제공하는 방법을 설명합니다. 부하 분산기 제품군 및 선택, 프록시 방식과 패스스루 방식의 동작 비교, 백엔드 및 라우팅 구성요소, 장애 조치 및 용량 관리, Cloud CDN 캐싱 및 원본 보호, 애니캐스트 및 리전 간 설계, DNS 스티어링 및 상태 확인, 관측성, 견고한 글로벌 진입점을 위한 설계 패턴을 다룹니다.

부하 분산기 제품군, 선택, 데이터 플레인 동작

Google Cloud는 범위, 프로토콜, 데이터 플레인 특성이 각기 다른 외부 및 내부 부하 분산기를 제공합니다. 적절한 부하 분산기를 선택하면 프로토콜 요구사항, 지리적 위치, 운영 제어를 조율할 수 있습니다.

• 외부 프록시 L7(글로벌): HTTP(S) 및 gRPC용 External Application Load Balancer입니다. TLS를 종료하고, L7 정책을 적용하며, URL 맵, Cloud CDN, Cloud Armor, 요청/응답 기능, 애니캐스트 IPv4/IPv6를 지원합니다. 고급 라우팅, 보안, 캐싱이 필요한 인터넷 연결 웹 API/사이트에 가장 적합합니다.

• 외부 프록시 L4.5: External TCP Proxy Load Balancer(글로벌) 및 External UDP Proxy Load Balancer(리전)는 클라이언트 연결을 종료하고 백엔드로 프록시합니다. L7 라우팅 없이 글로벌 VIP 및 L4 기능(TLS 정책, TCP의 경우 헤더를 통한 클라이언트 IP 보존)이 필요할 때 사용합니다.

• 외부 패스스루 L3/L4(리전): External Network Load Balancer는 연결을 종료하지 않고 패킷을 전달합니다. 지연 시간이 가장 짧고 가장 단순하며, TCP/UDP/ESP/ICMP를 지원합니다. 리프트 앤 시프트, 이기종 백엔드 또는 프록시 종료를 허용하지 않는 프로토콜에 적합합니다. 기존 NLB는 대상 풀을 사용하고, 최신 리전 패스스루 NLB는 백엔드 서비스를 사용합니다.

• 내부 프록시(리전): Internal HTTP(S) Load Balancer(L7) 및 Internal TCP Proxy Load Balancer(L4.5)는 마이크로서비스의 남-북(north-south) 및 서비스 간(service-to-service) 사용을 위해 VPC 내부에서 연결을 종료하고 프록시합니다. 호스트/경로 라우팅(HTTP), 애플리케이션을 통한 클라이언트로의 mTLS, 서비스별 보안 정책을 지원합니다.

• 내부 패스스루(리전): Internal TCP/UDP Load Balancer는 비공개 RFC1918을 통해 백엔드로 연결을 분산하고, 클라이언트 IP를 보존하며, MAGLEV 해싱을 사용합니다. 영역 인식 분산과 낮은 오버헤드가 필요한 동-서(east-west) 서비스(데이터베이스, 커스텀 프로토콜)에 이상적입니다.

레이어 및 종료 방식의 장단점:

• 프록시 L7/4.5는 추가 홉과 헤더/NAT 변경 가능성을 감수해야 하지만, 고급 라우팅, TLS 오프로드, 관측성, Cloud Armor/CDN, 리전 간 장애 조치 기능을 제공합니다. 공개 진입점 및 서비스 메시에 적합합니다.
• 패스스루 L3/L4는 엔드투엔드로 클라이언트 IP를 보존하고 지연 시간을 최소화하지만, L7 기능이 없고 관측성 후크가 더 적습니다. 세션 동작은 해시 기반이며 상태 확인이 더 간단합니다.

범위 및 IP 제품군:

• 글로벌 애니캐스트 VIP는 External Application LB 및 External TCP Proxy LB에서 사용할 수 있으며, 어디서나 연결 가능한 단일 IPv4/IPv6 주소를 제공합니다. 리전 부하 분산기는 리전 유니캐스트 VIP를 사용합니다. 공개 서비스의 IPv6 노출은 외부 글로벌 부하 분산기에 IPv6 주소를 구성하여 달성됩니다.

주요 선택 기준:

• 호스트/경로 라우팅, 리디렉션, Cloud CDN, Cloud Armor 또는 gRPC가 필요한 경우: External Application LB.
• L7 없이 글로벌 TCP가 필요한 경우: External TCP Proxy LB.
• 프록시를 허용하지 않는 프로토콜(예: 일부 레거시 UDP/TFTP): 외부 또는 내부 패스스루.
• HTTP 라우팅을 사용하는 비공개 서비스 간 통신: Internal HTTP(S) LB.
• VPC 내 트래픽의 비용/홉 최소화: 내부 패스스루.

백엔드 서비스, 라우팅 객체, 상태 확인 및 트래픽 고정성

핵심 데이터 플레인 객체:

• Backend services: 백엔드(인스턴스 그룹, 영역 NEG, 하이브리드 NEG, 서버리스 NEG), 상태 확인, 분산 모드, 용량, 세션 어피니티, 시간 초과, 장애 조치 정책을 정의합니다. 프록시 LB와 최신 패스스루 LB에 필요합니다.
• Target pools: 기존 외부 NLB를 위한 레거시 구성 요소입니다. 리프트 앤 시프트(lift-and-shift) 중 간단한 TCP/UDP 분산 및 이기종 VM에 적합합니다.
• Named ports: 인스턴스 그룹의 키로, 논리적 이름(예: http)을 포트 번호에 매핑하며, 백엔드 서비스와 URL 맵에서 참조됩니다. 그룹 멤버 간의 일관성을 보장해야 합니다.

상태 확인 및 장애 조치:

• 유형: HTTP(S), HTTP/2, gRPC, TCP, SSL. 단순히 OS 도달 가능성이 아닌 실제 서비스 준비 상태를 검증하는 확인 방법을 선택해야 합니다.
• 범위: 상태 확인은 리전별로 수행됩니다. 각 백엔드는 서비스 제공 리전에 맞는 범위의 상태 확인을 가져야 합니다.
• 장애 조치 정책: 백엔드 서비스는 기본(primary) 백엔드와 장애 조치(failover) 백엔드를 지정할 수 있습니다. 기본 백엔드가 비정상이거나 용량을 초과하면(용량 기반 장애 조치가 활성화되고 임계값을 충족하는 경우) 트래픽이 장애 조치됩니다. ‘Thundering herd’ 현상을 피하기 위해 드레이닝(draining)과 용량 예약을 고려해야 합니다.

URL 맵 및 라우팅:

• URL 맵은 외부 또는 내부 HTTP(S) LB에 연결되며 호스트 규칙과 경로 일치자(path matcher)를 정의합니다.
• 기본 서비스: 어떤 규칙과도 일치하지 않는 요청을 처리하는 포괄(catch-all) 백엔드입니다. 설정되지 않으면 404가 반환됩니다.
• 리디렉션 및 재작성: URL 맵 작업을 사용하여 라우팅 전에 HTTPS 리디렉션, 정규 호스트 리디렉션 또는 경로 재작성을 수행합니다.

예시: HTTPS 리디렉션 및 기본 백엔드를 포함한 최소한의 URL 맵

• example.com에 대한 호스트 규칙을 생성하고, HTTP를 HTTPS로 리디렉션하며, /static 경로는 CDN이 활성화된 백엔드 버킷으로 라우팅하고, 기본적으로는 리전 백엔드 서비스로 라우팅합니다.

세션 어피니티 및 드레이닝:

• 어피니티 옵션은 LB 유형에 따라 다릅니다. 일반적인 옵션은 다음과 같습니다:
  • 없음: 상태 비저장(stateless)에 가장 적합하며, 부하 분산을 극대화합니다.
  • Client IP: L4/L7 전반에 걸쳐 소스 IP를 기준으로 고정됩니다. 여러 프로토콜(예: HTTP 및 TFTP)이 동일한 백엔드에 함께 고정되어야 할 때 사용합니다.
  • 생성된 쿠키(L7 전용): LB가 백엔드에 대한 지속성을 위해 쿠키를 설정합니다. NAT된 클라이언트 환경에서 Client IP 방식보다 분산 효과가 더 좋습니다.
• 장단점: 어피니티는 핫스팟(hotspotting)을 유발하고 오토스케일링을 복잡하게 만들 수 있습니다. 가능한 경우 상태 비저장(statelessness)을 선호해야 합니다.
• 연결 드레이닝: 스케일 인(scale-in) 또는 백엔드 제거 시, LB는 드레이닝 시간 초과 설정을 준수하여 기존 연결이 정상적으로 종료되도록 합니다. 연결 재설정(reset)을 방지하려면 예상되는 가장 긴 요청 시간에 맞춰 드레이닝 시간을 조정해야 합니다.

용량 및 오토스케일링:

• 분산 모드: 사용률(예: CPU), RPS 또는 연결 수를 기반으로 합니다. 각 백엔드는 용량을 알리고, 포화 상태가 되면 LB는 부하를 줄이거나 장애 조치를 수행합니다.
• 오토스케일링: Managed instance groups는 신호(CPU, 커스텀 측정항목)를 기반으로 스케일링됩니다. 스케일 아웃(scale-out) 지연은 LB 용량이 부족할 경우 503 오류를 유발할 수 있습니다. 최소 복제본 수 설정이나 주간 트래픽 패턴에 대한 예측 오토스케일링으로 미리 준비(pre-warm)해야 합니다.
• 장애 조치 및 오버플로우: 적절한 임계값과 함께 용량 기반 장애 조치를 활성화하면 리전 간 오버플로우를 원활하게 처리할 수 있습니다.

백엔드 보안:

• 인스턴스 태그나 서비스 계정을 대상으로 하는 방화벽 규칙을 사용하여 백엔드 액세스를 제한합니다. 내부 클라이언트의 직접 액세스가 필요한 경우, Google 로드 밸런서 및 상태 확인 소스 범위와 승인된 클라이언트 범위의 트래픽만 허용합니다.

예시: 백엔드 태그가 지정된 그룹에 대한 클라이언트 및 상태 확인 제한

• 인스턴스에 application 태그를 지정합니다.
• 클라이언트 CIDR 및 Google 상태 확인 범위로부터의 tcp:80 트래픽에 대해 application 태그를 대상으로 하는 인그레스 허용 규칙을 생성합니다.
• 기본적으로 거부(deny-by-default) 정책을 사용하여 거부된 트래픽이 로그에 표시되도록 하는 것이 좋습니다.

Cloud CDN, 캐시 정책 및 오리진 보호

Cloud CDN은 외부 Application Load Balancer와 통합되어 에지 POP에 응답을 캐시함으로써, 지연 시간을 줄이고 오리진의 부하를 덜어줍니다.

캐시 모드 및 TTL:

• 오리진 헤더 사용: 오리진의 Cache-Control 및 Expires 헤더를 따릅니다. 정확성을 위해 권장됩니다.
• 캐시 강제 적용: 구성된 기본 TTL로 모든 응답을 캐시하며, 정적 콘텐츠에 대해 오리진 헤더를 재정의하거나 무시할 수 있습니다. 동적 데이터가 캐시되지 않도록 주의해서 사용해야 합니다.
• 캐시 우회: 절대 캐시해서는 안 되는 경로에 유용합니다.

캐시 키:

• 키 필드에는 프로토콜, 호스트, 경로, 쿼리 매개변수, 헤더, 쿠키가 포함됩니다. 필요에 따라 쿼리 문자열 정책(모두 포함, 선택 항목 포함 또는 무시), 특정 헤더 및 쿠키 포함, 기기별 분할 등을 구성합니다.
• 적중률을 극대화하려면 키를 최소한으로 유지하고, 표현이 달라지는 필드에 대해서만 키를 다르게 설정해야 합니다.

서명된 요청:

• 서명된 URL: 만료 시간과 경로 범위가 포함된 HMAC 또는 RSA 서명을 첨부하여 특정 리소스에 대한 시간 제한적 액세스 권한을 부여합니다. 객체별 승인이 필요한 CDN 가속기 용도로 적합합니다.
• 서명된 쿠키: 쿠키를 사용하여 여러 경로에 대한 액세스를 승인하며, 사이트 전체의 제한된 콘텐츠에 유용합니다.
• 재전송 공격(replay attack) 위험을 줄이기 위해 키를 순환시키고 만료 기간을 짧게 설정합니다.

압축 및 정확성:

• 오리진은 요청에 Via 헤더가 포함된 경우에도 압축을 수행해야 합니다. 오리진이 “압축을 지원"하는데도 CDN이 압축되지 않은 객체를 제공하는 경우, Via 헤더가 있을 때 오리진이 압축하도록 구성되었는지 확인해야 합니다.

오리진 보안:

• 에지 프록시에서 오리진까지 최신 TLS 정책을 사용하여 HTTPS로 통신합니다.
• 오리진 연결 제한: Google 부하 분산기 및 상태 확인 소스 IP 범위, 그리고 알려진 비공개 생산자(private producer)로부터의 트래픽만 허용하도록 백엔드 방화벽 규칙을 설정합니다. 백엔드 인스턴스는 임의의 퍼블릭 인그레스(public ingress)를 허용해서는 안 됩니다.
• L7 DDoS/WAF, 비율 제한(rate limiting), 위협 탐지를 위해 Cloud Armor와 함께 사용합니다. 오탐(false positive)을 줄이기 위해 새 규칙은 미리보기 모드를 사용합니다.
• TTL이 만료되기 전에 콘텐츠를 제거해야 할 경우, 캐시 무효화 API를 사용하여 의도적으로 콘텐츠를 무효화합니다. 동적 콘텐츠의 경우 짧은 TTL과 재검증(ETag/If-None-Match)을 사용하는 것이 좋습니다.

장애 모드 및 절충점:

• 너무 광범위한 캐시 키는 캐시를 낭비하고 적중률을 낮춥니다. 반면 너무 좁은 키는 잘못된 버전의 콘텐츠를 제공할 위험이 있습니다.
• 동적 데이터를 강제로 캐시하면 개인화된 콘텐츠가 유출될 수 있습니다.
• 서명된 URL/쿠키는 에지에서의 액세스를 보호하지만, 네트워크 정책을 통해 오리진을 직접 우회하는 접근은 여전히 차단해야 합니다.

전역 트래픽 관리, DNS 스티어링, 관측성 및 복원력 있는 진입점

애니캐스트(Anycast) 프런트 도어 및 리전 간 장애 조치:

• 외부 Application LB 및 외부 TCP Proxy LB는 전역 애니캐스트 VIP를 사용하여 클라이언트를 가장 가까운 Google 에지로 유도합니다. 그런 다음 트래픽은 용량이 있는 가장 건강하고 가장 가까운 백엔드로 프록시됩니다. 원활한 장애 조치 및 오버플로를 위해 일관된 상태 확인 및 용량 설정으로 여러 백엔드 리전을 구성합니다.
• 콜드 스타트 페널티를 피하기 위해 보조 리전에 용량을 미리 프로비저닝합니다. 로드 밸런서 용량 임계값과 오토스케일러의 최소/최대 설정을 조율합니다.

리전별 내부 트래픽 관리:

• 내부 HTTP(S) LB 및 내부 패스스루 LB는 리전별 서비스입니다. 리전 내 영역 다양성을 고려하여 설계하고, 필요한 경우 Private Service Connect가 있는 별도의 LB를 사용하거나 서비스 인식 클라이언트가 리전 엔드포인트를 선택하도록 하여 다중 리전으로 설계합니다.
• 통신하는 서비스들을 동일한 리전 및 VPC에 배치하여 동서 간(east-west) 지연 시간을 낮게 유지합니다. 최소한의 비용과 운영 단순성을 위해 단일 VPC 또는 피어링된 VPC와 함께 RFC1918 주소 지정을 사용합니다.

Cloud DNS 라우팅 정책 및 상태 확인:

• 정책: 가중치 기반 라운드 로빈(트래픽 분할), 지역 위치(사용자를 가장 가까운 리전 VIP로 전송), 장애 조치(기본/백업). 비즈니스 규칙을 충족시키기 위해 정책을 결합합니다.
• 상태 확인: 스티어링에 사용되는 A/AAAA 레코드에 DNS 상태 확인(HTTP/HTTPS/TCP)을 연결하여 비정상 엔드포인트를 철회합니다. 응답을 지연시키는 리졸버 캐싱(TTL)을 고려해야 합니다. DNS 조회 수가 증가하는 비용을 감수하고 장애 조치 응답성을 향상시키려면 스티어링된 레코드의 TTL을 낮게 유지합니다.
• 트래픽 스티어링: 가중치 정책을 사용하여 마이그레이션을 단계적으로 수행하거나 리전 간 부하를 이전합니다. 분할 수평(split-horizon) DNS를 사용하지 않는 한 인터넷에서 사설 주소로 스티어링하는 것을 피합니다.

관측성 및 진단:

• 로드 밸런서 로깅: 모든 LB에 대해 로깅을 활성화합니다. HTTP(S) 로그에는 요청 메서드/URI, 지연 시간, 캐시 적중/실패, 백엔드 서비스, URL 맵 규칙, TLS 세부 정보 및 응답 코드가 포함됩니다. TCP/UDP 로그는 연결 메타데이터와 상태 프로브 상태를 제공합니다.
• 측정항목: 백엔드 상태, 사용률, RPS, 연결 수, 지연 시간, 캐시 적중률, 4xx/5xx 비율 및 용량 포화도를 모니터링합니다. 급격한 변화와 지속적인 임계값 초과 시 알림을 설정합니다.
• 일반적인 HTTP(S) 오류 패턴:
  • 404: URL 맵 일치 없음. 호스트/경로 규칙 및 기본 서비스를 확인합니다.
  • 301/302: 의도적인 리디렉션. 리디렉션 루프를 확인합니다.
  • 502: 백엔드 연결 또는 프로토콜 불일치(예: HTTP/1.1 대 gRPC). 상태 및 백엔드 프로토콜 구성을 확인합니다.
  • 503: 정상 백엔드 또는 용량 있는 백엔드가 없음. 상태 확인, 할당량 및 오토스케일러 동작을 확인합니다.
• 요청 추적: 앱에서 전파되는 X-Forwarded-For, X-Forwarded-Proto 및 추적 ID를 사용합니다. 요청 ID를 사용하여 LB 로그와 백엔드 로그를 상호 연관시킵니다.
• 방화벽 통계: 허용 및 거부 규칙에 대해 VPC 방화벽 로깅을 활성화합니다. 명시적으로 삭제(drop)를 로깅하려면 로깅이 활성화된 낮은 우선순위의 전체 거부 규칙을 추가합니다.

복원력 있는 전역 진입점 설계:

• 여러 리전 백엔드 앞에 있는 외부 Application LB에서 단일 전역 애니캐스트 VIP를 사용합니다. 서버리스/VM/컨테이너 백엔드를 최소 두 개 리전에 배치합니다. 리전 간 장애 조치 및 오버플로를 활성화하고, 보수적인 상태 확인을 구성하며, 워크로드에 맞게 드레이닝 및 시간 초과를 조정합니다.
• Cloud Armor 및 할당량 제한 정책으로 진입점을 보호합니다. 정적 및 캐시 가능한 동적 콘텐츠에 Cloud CDN을 사용하여 에지에서 트래픽 급증을 흡수합니다.
• 전역 LB에서 듀얼 스택 IPv4/IPv6를 노출하여 모든 네트워크에 서비스를 제공합니다. 엄격한 클라이언트 액세스를 위해 정확한 소스 범위와 인스턴스 태그 또는 서비스 계정을 사용하여 백엔드 방화벽 규칙을 적용합니다.

예시: 태그가 지정된 백엔드에 대한 클라이언트 및 상태 확인 범위를 제한하는 방화벽 규칙

• 인스턴스에 application 태그를 지정합니다.
• application을 대상으로 하는 tcp:443에 대해 소스 범위 203.0.113.0/24, 198.51.100.0/24 및 Google 상태 확인 범위에 대한 인그레스 허용 규칙을 생성합니다.
• 예상치 못한 소스를 캡처하기 위해 로깅이 활성화된 낮은 우선순위의 전체 거부 규칙이 있는지 확인합니다.

실제 문제 시나리오

Acme Retail은 us-east1과 europe-west1에 걸쳐 낮은 지연 시간, 강력한 보안, 투명한 장애 조치를 필요로 하는 글로벌 전자 상거래 플랫폼을 출시하며, 정적 미디어를 효율적으로 제공해야 합니다. 회사 사무실과 파트너 CDN 스테이징 네트워크만 비공개 관리자 인터페이스에 접근할 수 있어야 합니다.

1. 프런트 도어 및 백엔드

• 공개 스토어프런트 호스트 이름에 대해 듀얼 스택 애니캐스트 VIP와 TLS 인증서를 사용하여 외부 Application Load Balancer를 생성합니다.
• us-east1과 europe-west1에 있는 리전별 관리형 인스턴스 그룹을 각각 가리키는 두 개의 백엔드 서비스를 정의합니다. 상태 확인(HTTPS)을 활성화하고 분산 모드를 사용률로 설정하며 용량 임계값을 80%로 지정합니다. 근거: 애니캐스트와 다중 리전 백엔드를 함께 사용하면 사용자가 가장 가까운 에지에 연결되고, 리전이 비정상이거나 포화 상태일 때 원활하게 장애 조치됩니다.

2. URL 맵, 라우팅 및 리디렉션

• 공개 스토어프런트 및 비공개 관리자 호스트 이름에 대한 호스트 규칙으로 URL 맵을 구성합니다. /static은 Cloud CDN이 활성화된 백엔드 버킷으로 라우팅하고, /api와 /는 VM 백엔드로 라우팅합니다. HTTP-to-HTTPS 리디렉션을 추가합니다. 근거: 호스트/경로 라우팅은 정적 트래픽과 동적 트래픽을 분리하고 보안 액세스를 강제합니다.

3. Cloud CDN 정책

• /static 백엔드 버킷의 경우, 캐시 모드를 원본 헤더 사용으로 설정하고, 기능하지 않는 쿼리 매개변수를 무시하고 Accept-Encoding 헤더만 포함하는 캐시 키를 정의합니다. 일반적인 404 오류에 대해 짧은 TTL로 네거티브 캐싱을 활성화합니다. 근거: 콘텐츠 시맨틱을 존중하고, 적중률을 극대화하며, 잘못된 변형이 캐싱되는 것을 방지합니다.

4. 세션 선호도 및 드레이닝

• 공개 스토어프런트에는 생성된 쿠키 선호도를 설정하고 정적 자산에는 설정하지 않습니다. 연결 드레이닝을 60초로 설정합니다. 근거: 쿠키는 장바구니 세션을 안정적으로 유지하면서 광범위한 분산을 허용합니다. 드레이닝은 스케일 인 또는 장애 조치 중 사용자에게 보이는 오류를 방지합니다.

5. 리전 간 장애 조치 및 오토스케일링

• 용량 기반 장애 조치를 90% 오버플로 임계값으로 활성화하여 초과 트래픽을 다른 리전으로 이전합니다. 리전당 최소 복제본 4개와 LB 사용률에 맞는 CPU 목표를 사용하여 MIG 오토스케일링을 구성합니다. 근거: 용량 절벽(capacity cliff)을 피하고 LB와 오토스케일러의 결정을 조율하여 원활한 확장을 보장합니다.

6. 관리자 인터페이스 제한

• VPC 내부에서만 액세스할 수 있는 비공개 관리자 호스트 이름에 대해 내부 HTTP(S) Load Balancer를 생성합니다. 분할 수평(split-horizon) Cloud DNS를 게시하여 내부 클라이언트는 ILB VIP로 확인되고 외부 클라이언트는 NXDOMAIN을 받도록 합니다. 근거: 공개 엔드포인트를 노출하지 않고 관리자 트래픽을 비공개로 유지하고 제어합니다.

7. 백엔드 방화벽 및 원본 보안

• 관리자 및 웹 백엔드에 application 태그를 지정하고, 회사 및 스테이징 CIDR과 Google 로드 밸런서 및 상태 확인 소스 범위로부터의 tcp:443에 대한 허용 규칙을 추가합니다. 더 낮은 우선순위로 로깅이 포함된 전체 거부 규칙을 추가합니다. 근거: 의도된 클라이언트와 Google 인프라만 백엔드에 도달할 수 있도록 보장하고, 삭제(drop)된 트래픽에 대한 가시성을 제공합니다.

8. Cloud Armor

• 관리형 WAF 규칙과 /api 버스트 트래픽에 대한 미리보기 모드의 속도 제한이 포함된 보안 정책을 적용합니다. 근거: L7 보호와 단계적 적용은 튜닝 중에 위험을 줄여줍니다.

9. Cloud DNS 스티어링 및 상태 확인

• 공개 스토어프런트 호스트 이름에 대한 A 및 AAAA 레코드를 ALB 애니캐스트 VIP로 게시합니다. 블루/그린 카나리 배포를 위해 지정된 카나리 호스트 이름에 가중치 정책을 생성하여 5%를 europe-west1 전용 ALB로, 95%를 전역 배포로 분할합니다. 카나리가 비정상일 때 철회하도록 HTTPS 상태 확인을 연결하고 TTL을 20초로 설정합니다. 근거: DNS 기반 카나리는 상태를 인식하는 제거 기능과 빠른 수렴을 통해 점진적인 노출을 가능하게 합니다.

10. 관측성

• LB 및 CDN 로그를 활성화하고 분석을 위해 BigQuery로 내보냅니다. 5xx 비율, 백엔드 용량, 상태 확인 실패 및 CDN 적중률에 대한 알림을 설정합니다. URL 맵 테스트와 요청 로그를 사용하여 라우팅 오류를 진단하고, 502/503 급증을 검사하여 백엔드 포화 또는 프로토콜 불일치를 확인합니다. 근거: 사전 예방적 모니터링과 신속한 진단은 MTTR을 최소화하고 사용자 경험을 보존합니다.

← 하이브리드 연결 · 모든 도메인 · Cloud DNS →

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

Google 찾아보기 →