Google PCA: 네트워킹, 하이브리드 연결 및 트래픽 아키텍처 — 학습 가이드

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

개요

Google Cloud의 네트워킹, 하이브리드 연결, 트래픽 아키텍처는 안전하고 확장 가능한 Virtual Private Cloud(VPC) 설계, 안정적인 하이브리드 상호 연결, 지능적인 트래픽 관리, 강력한 관측 가능성을 중심으로 이루어집니다. 목표는 명확한 세분화, 제어된 이그레스(egress), 예측 가능한 장애 모드를 통해 지연 시간이 짧고 복원력 있는 서비스를 제공하는 것입니다. 이 섹션에서는 핵심 Google Cloud 네트워킹 서비스 전반에 걸친 실용적인 설계 패턴, 장단점, 운영 가이드를 간략하게 설명합니다.

VPC 아키텍처 및 세분화

• 주소 계획 및 서브넷

  • 커스텀 모드 VPC를 사용하여 서브넷 생성 및 IP 주소 지정을 제어합니다. 프로덕션 환경에서는 기본 VPC 사용을 피하십시오.
  • 겹치지 않는 RFC1918 블록을 조기에 할당합니다. 향후 성장, 고가용성 토폴로지, 하이브리드 확장을 고려하십시오. 서비스(예: Private Service Connect 엔드포인트) 및 피어링/Interconnect를 위한 범위를 예약해 둡니다.
  • 장애 영향 반경을 최소화하고 방화벽 구성을 단순화하기 위해 대규모 플랫 네트워크보다는 기능별 또는 환경별 소규모 서브넷을 선호합니다.

• 경로

  • 각 VPC에는 시스템 경로 테이블이 있으며, 경로는 최장 접두사 일치(longest-prefix match) 후 우선순위에 따라 평가됩니다. Google 관리 경로에는 외부 IP가 존재할 경우의 기본 인터넷 경로와 서브넷 경로가 포함됩니다. 동적 경로는 Cloud Router를 통해 온프레미스와 교환됩니다.
  • 커스텀 정적 경로는 드물게 사용하고, 복원력을 위해 가능한 한 동적 라우팅에 의존합니다. 의도적인 제어 목적이 아니라면 블랙홀 경로는 피하십시오.

• 방화벽 규칙

  • VPC 방화벽은 상태 저장(stateful) 방식이며 우선순위에 따라 평가되고, 마지막에는 암시적 거부가 적용됩니다. 네트워크 태그 또는 서비스 계정으로 대상을 지정하십시오. 서비스 계정 타겟팅은 태그보다 더 강력한 ID 보장을 제공합니다.
  • 허용 규칙을 목적(상태 확인, 티어 내부, 관리)에 따라 분리하고 소스 서비스 계정 또는 IP 범위로 범위를 제한합니다.
  • 중요한 규칙에 대한 방화벽 결정을 Cloud Logging에 기록하여 포렌식 및 성능 분석을 지원합니다.

• 계층적 방화벽 정책 및 조직 정책

  • 계층적 방화벽 정책은 조직 또는 폴더 수준에서 적용되며 VPC 수준 규칙보다 먼저 평가됩니다. 이를 사용하여 프로젝트가 재정의할 수 없는 전역 가드레일(예: 0.0.0.0/0 SSH 거부)을 설정합니다. 사전 및 사후 정책은 유연성을 제공하지만, 상위 수준에서의 거부는 재정의될 수 없습니다.
  • 조직 정책 제약 조건(예: 외부 IP 생성 제한, 프로젝트의 VPC 피어링 생성 비허용)으로 보완하여 거버넌스를 강제합니다.

• Shared VPC 및 세분화

  • Shared VPC를 사용하여 호스트 프로젝트에서 네트워킹을 중앙 집중화하고 서비스 프로젝트에서 워크로드를 격리합니다. 이 패턴은 중복 이그레스 경로를 줄이고, 제어를 표준화하며, 하이브리드 전송을 단순화합니다.
  • 프로덕션, 비프로덕션과 같은 환경을 별도의 호스트 프로젝트나 폴더로 분리하고, 계층적 정책과 별도 서브넷으로 세분화를 강제합니다. NetOps 팀만 호스트 프로젝트 리소스를 관리하도록 IAM을 제한합니다.

• VPC 네트워크 피어링

  • 피어링은 비공개이며 확장 가능하고 지연 시간이 짧지만, 전이적이지 않습니다(non-transitive). 자율 네트워크나 서드파티 관리형 서비스를 연결하는 데 가장 적합합니다. 피어링으로 전송 허브를 구축하는 것은 피하고, 전송을 위해서는 Network Connectivity Center나 중앙 집중식 Shared VPC를 사용하십시오.
  • 제한 사항: IP가 겹칠 수 없으며, 특정 경로(예: 기본 인터넷 경로)와 일부 서비스는 전파되지 않습니다. 설계 시 커스텀 경로의 가져오기/내보내기를 이해해야 합니다.

장단점 및 장애 모드:

• 겹치는 IP 범위는 피어링 및 하이브리드 경로 교환을 차단합니다. IP 재할당 또는 NAT로 해결하십시오.
• 과도하게 허용적인 방화벽 규칙이나 누락된 상태 확인 규칙은 서비스 중단 및 진단하기 어려운 동작을 유발합니다.
• 정적 경로는 취약한 종속성을 만듭니다. 장애 조치를 위해 Cloud Router를 선호하십시오.

트래픽 관리, DNS 및 엣지 보안

• Cloud Load Balancing 패턴

  • External HTTP(S) Load Balancer는 단일 애니캐스트 VIP를 사용하는 글로벌 애니캐스트이며, 리전 간 장애 조치, 경로 및 호스트 기반 라우팅, CDN/Armor 통합을 지원합니다. 인터넷에 연결되는 웹 및 API 워크로드에 사용합니다.
  • Internal HTTP(S) Load Balancer는 리전 기반이며, VPC 내 또는 Private Service Connect를 통한 서비스 간 트래픽에 사용됩니다.
  • External/Internal TCP/UDP Network Load Balancer는 리전 기반 L4 로드 밸런서입니다. 비-HTTP 프로토콜이나 소스 IP 보존이 필요한 경우에 사용합니다.
  • 백엔드 서비스 및 네트워크 엔드포인트 그룹(NEG): VM 풀에는 영역별 인스턴스 그룹 백엔드를 사용하고, GKE, 하이브리드 백엔드 또는 Cloud Run에는 영역별, 리전별 또는 서버리스 NEG를 사용합니다. 트래픽 클래스, 상태 프로필 또는 용량 정책별로 별도의 백엔드 서비스를 생성합니다. 예시: 경로 라우팅을 통해 고유한 백엔드 서비스로 트래픽을 보내 동일한 호스트 이름으로 이전 버전과 새 버전의 API를 모두 제공하고, 두 버전을 독립적으로 배포하고 확장할 수 있도록 유지합니다.

• 상태 확인 및 일반적인 함정

  • 상태 확인은 방화벽에서 허용되어야 합니다. 외부 HTTP(S) 상태 확인을 위해 백엔드에 130.211.0.0/22 및 35.191.0.0/16 IP 대역을 허용해야 합니다. 이 규칙이 없으면 백엔드가 비정상으로 표시되고, 자동 확장이 로드 밸런서 신호에 반응할 경우 VM이 빠르게 다시 시작될 수 있습니다.
  • 상태 확인 경로와 포트를 컨테이너 준비 상태 엔드포인트(readiness endpoint)와 일치시키고, 타임아웃과 임계값을 설정하여 빠른 장애 조치와 거짓 양성(false positive) 사이의 균형을 맞춥니다.

• DNS 아키텍처

  • 권한 있는 영역(authoritative zone)에는 Cloud DNS를 사용합니다. 내부 이름에는 비공개 영역(private zone)을, 인터넷 이름에는 공개 영역(public zone)을 생성합니다.
  • 스플릿 호라이즌(Split-horizon) DNS: 동일한 이름으로 별도의 공개 및 비공개 영역을 만들어 내부와 외부에 서로 다른 응답을 제공합니다. 이를 통해 비공개 서비스 호스트 이름과 공개용 레코드를 안전하게 지원할 수 있습니다.
  • 전달 및 피어링 영역: DNS 정책 및 서버 정책을 사용하여 온프레미스 DNS와 통합하고 특정 도메인에 대한 쿼리를 전달합니다. 재귀 루프를 피하기 위해 조건부 전달을 사용합니다.
  • 서비스 디스커버리: 환경 및 서비스별로 일관된 이름 지정 규칙을 채택합니다. GKE의 경우, Cloud DNS와 함께 헤드리스 서비스(headless service)를 사용하거나, Internal HTTP(S) Load Balancer와 비공개 DNS 이름을 통해 서비스 엔드포인트를 매핑하는 것을 고려합니다.

• 엣지 캐싱 및 보호

  • Cloud CDN은 엣지에서 캐시 가능한 콘텐츠를 오프로드하여 오리진(origin) 지연 시간과 이그레스(egress) 비용을 줄입니다. 캐시 키, TTL, 네거티브 캐싱을 신중하게 설정하고, 개인화되거나 동적인 엔드포인트에 대해서는 캐싱을 우회합니다.
  • Cloud Armor는 WAF, 비율 제한(rate limiting), 지역/IP 기반 액세스 제어를 제공합니다. 보안 정책을 로드 밸런서에 연결하고 규칙 적중 로그를 모니터링합니다. 일반적인 CVE에 대해서는 사전 구성된 규칙을 사용하고, 애플리케이션별 위협에 대해서는 맞춤형 시그니처를 사용합니다.
  • 로드 밸런서에서의 TLS 종료는 인증서 관리를 중앙 집중화합니다. 가능한 경우 자동 인증서 프로비저닝 및 관리형 갱신을 활성화합니다.

운영 가이드:

• 버전 관리 API: 경로 또는 호스트 기반 라우팅을 구현하여 백엔드 서비스를 분리하고, 각 버전이 블루/그린 또는 카나리 패턴으로 독립적으로 롤아웃되도록 합니다.
• 트래픽 조종 정책을 통한 A/B 테스트에는 요청 헤더와 쿠키를 사용합니다. 로깅/메트릭이 올바른 백엔드 ID와 상관관계가 있는지 항상 확인합니다.

하이브리드 연결, 비공개 액세스 및 전송

• Cloud Router와 BGP

  • Cloud Router는 BGP를 통해 온프레미스와 동적으로 경로를 교환하여 Cloud VPN 터널 및 Interconnect 연결을 지원합니다. 다중 리전 스포크 연결이 필요한 경우 VPC에서 전역 동적 라우팅 모드를 사용하세요.
  • 필요한 프리픽스만 공지하고 필터링하여 경로 유출을 방지하세요. 기본/백업 경로를 설계할 때 MED와 우선순위 상호작용을 이해해야 합니다.

• Cloud VPN, Dedicated 및 Partner Interconnect

  • HA VPN은 IPsec을 통해 SLA가 지원되는 이중화 터널을 제공하고, Cloud Router를 통한 동적 라우팅을 지원하며, 중간 수준의 대역폭이 필요한 프로덕션 하이브리드 환경에 적합합니다.
  • Dedicated Interconnect는 하나 이상의 위치에서 물리적인 10/100Gbps 링크를 제공하며, Partner Interconnect는 서비스 제공업체를 통해 유사한 서비스를 제공합니다. 고가용성을 위해 별도의 대도시 위치나 별도의 에지 영역에 최소 두 개의 다양한 상호 연결을 사용하세요.
  • 이중화 경로 및 장애 조치: 리전당 두 개의 Cloud Router와 두 개의 온프레미스 라우터에 걸쳐 BGP를 사용하는 활성/활성(active/active) 구성을 설계하고, 비대칭 라우팅 허용 오차를 검증하세요.
  • 장애 조치를 정기적으로 테스트하고, 원하는 수렴 시간을 위해 BFD 타이머와 상태 임계값을 조정하세요.
  • 장애 모드: MTU 불일치는 단편화와 성능 저하를 유발합니다. Interconnect의 경우 종단 간(end-to-end) 점보 프레임을 보장하세요. 잘못 구성된 경로 필터는 서브넷을 블랙홀 처리할 수 있습니다. 단일 홈 파트너 회선은 일반적인 단일 장애점(SPOF)입니다.

• Cloud NAT, Private Google Access 및 Private Service Connect

  • Cloud NAT는 외부 IP가 없는 비공개 VM이 인터넷으로 이그레스(egress)할 수 있게 해줍니다. 포트 고갈을 방지하기 위해 최대 연결 수에 맞춰 NAT IP와 포트 할당 크기를 조정하고, 문제 해결을 위해 로깅을 활성화하세요.
  • Private Google Access를 사용하면 비공개 VM이 내부 IP를 사용하여 Google API에 연결할 수 있습니다. VM 액세스를 위해 서브넷에서 활성화하고, 노드 로컬 API 액세스를 위해 GKE 노드에서 활성화하세요. 온프레미스 클라이언트의 경우, Private Service Connect for Google APIs를 사용하여 Google API를 프런트엔드하는 비공개 VIP를 노출하세요.
  • 생산자/소비자 서비스를 위한 Private Service Connect는 프로젝트 간 또는 조직 간 서비스 게시에 사용할 비공개 내부 IP 엔드포인트를 제공합니다. 비공개 DNS와 결합하여 네트워크를 노출하지 않고 트래픽을 유도하세요.

• Network Connectivity Center(NCC)와 전송

  • NCC는 스포크가 VPC, HA VPN 또는 Interconnect 연결인 허브 앤 스포크(hub-and-spoke) 토폴로지를 구현합니다. 중앙 허브를 사용하여 경로 배포와 다중 VPC 전송을 단순화하세요. 특히 프로젝트나 조직 간에 유용합니다.
  • 거버넌스가 허용하는 경우 조직 내 전송에는 Shared VPC를 사용하는 것이 좋습니다. 유연한 다중 도메인 전송이나 SD-WAN 통합이 필요할 때는 NCC를 사용하세요.
  • VPC Peering은 전송 라우팅(non-transitive)을 지원하지 않는다는 점을 이해해야 합니다. 전송 목적으로 VPC Peering에 의존하지 마세요. NCC 또는 중앙 집중식 방화벽/부하 분산기 VPC가 전송 코어를 형성합니다.

다중 리전 선택, 지연 시간 및 이그레스 비용:

• RTT를 최소화하기 위해 컴퓨팅 리소스를 사용자와 스테이트풀(stateful) 백엔드 가까이에 배치하세요. External HTTP(S) Load Balancing은 스마트 라우팅을 통해 전역 인그레스(ingress)를 제공하지만, 데이터베이스 복제 지연 시간과 일관성은 여전히 애플리케이션의 제약 조건으로 남습니다.
• 리전 내 영역 간 트래픽에는 비용이 발생하며, 리전 간 복제는 이그레스 요금과 지연 시간을 추가합니다. Cloud CDN을 사용하여 인터넷 이그레스와 오리진 부하를 줄이고, 통신이 잦은 서비스는 동일 위치에 배치하세요.
• 재해 복구를 위해 다른 리전의 웜 스탠바이(warm standby) 구성과 이그레스 비용 및 운영 복잡성을 비교 검토하세요. 데이터 영역과 제어 영역이 리전 격리를 감당할 수 있는 경우에만, 리전 간 장애 조치 정책과 상태 확인을 사용하는 전역 부하 분산을 사용하세요.

관측성, 안정성 운영 및 제어

• 네트워크 관측성

  • VPC Flow Logs: 서브넷 수준에서 활성화하고 샘플링 및 메타데이터 옵션을 조정합니다. 트래픽 기준선 설정, 이그레스 분석, 위협 탐지에 사용합니다. 장기 분석을 위해 BigQuery로 내보냅니다.
  • 방화벽 규칙 로깅: 중요한 규칙에 대해 활성화하여 허용 및 거부된 트래픽을 캡처합니다. 플로우 로그와 연관시켜 잘못된 구성을 탐지합니다.
  • Connectivity Tests: 소스-대상 경로를 모델링하여 도달 가능성, 경로 선택, 방화벽 평가를 검증합니다. CI/CD에 통합하여 배포 전 구성 변경(drift)을 탐지합니다.
  • 상태 대시보드: 부하 분산기 백엔드 상태, Cloud NAT 포트 사용률, Cloud Router BGP 세션 상태, Interconnect 사용률을 모니터링합니다. 편차가 발생하면 알림을 보냅니다.

• 안정성 패턴 및 일반적인 장애 모드

  • 영역(Zone) 복원력: 백엔드를 최소 2개 영역에 분산시킵니다. 관리형 인스턴스 그룹 또는 다중 영역 GKE 노드 풀을 사용합니다. 상태 확인 및 방화벽 태그가 모든 영역에 적용되는지 확인합니다.
  • 라우팅 복원력: 리전을 아우르는 연결을 위해 전역 동적 라우팅과 여러 개의 Cloud Router를 사용합니다. 블랙홀 시나리오를 테스트하고 모니터링이 경로 철회(withdrawal)를 포함하는지 확인합니다.
  • DNS 복원력: Cloud DNS를 사용하여 기본적으로 여러 네임 서버를 배포합니다. 하이브리드 환경의 경우, 전달자(forwarder)가 이중화되었는지 확인하고 온프레미스 리졸버의 단일 장애점을 피합니다. 잘못된 쪽에서 라우팅할 수 없는 응답을 반환하는 스플릿 호라이즌(split-horizon) 구성 오류를 방지합니다.
  • 에지(Edge)에서의 보안: Cloud Armor 비율 제한을 적용하여 대규모 트래픽(flood)으로부터 오리진(origin)을 보호합니다. 이를 실패하면 오토스케일링 폭풍(storm)과 비용 급증을 유발할 수 있습니다.

• 비용 제어

  • 리전 간 호출을 최소화하고, VPC 내 트래픽에는 내부 부하 분산을 선호하며, 생산자-소비자 트래픽에는 PSC를 고려하여 NAT 이그레스를 피합니다.
  • 정적 및 준정적 자산에는 Cloud CDN을 사용하고 캐시 가능성을 조정합니다. 유휴 헤드룸에 대한 과다 지불을 피하기 위해 Interconnect 용량을 적절히 산정합니다. 트래픽 데이터를 사용하여 약정(commit) 규모를 적정화합니다.

운영 스니펫:

• 비공개 백엔드로 부하 분산기 상태 확인 허용:

undefined

• 서브넷에서 Private Google Access 활성화:

undefined

• HA VPN용 Cloud Router 생성:

undefined

실용적인 문제 시나리오

Contoso Retail은 무중단 버전 관리, 백오피스 시스템에 대한 엄격한 비공개 연결, 애플리케이션 VM에 퍼블릭 IP를 사용하지 않는 글로벌 이커머스 API를 출시할 계획입니다. 이 솔루션은 DDoS 보호, 에지 캐싱, 그리고 두 개의 데이터 센터로부터의 안정적인 하이브리드 액세스를 제공해야 합니다.

접근 방식:

1. VPC 및 세분화 설계

• 두 리전에 걸쳐 티어(web, api, data)별 전용 서브넷을 갖춘 커스텀 모드 Shared VPC 호스트 프로젝트를 생성합니다. 근거: Shared VPC는 제어를 중앙화하고 서비스 프로젝트는 팀을 격리합니다. 티어별 서브넷은 최소 권한 방화벽 설정과 더 작은 장애 도메인을 가능하게 합니다.
• 조직 수준에서 계층적 방화벽 정책을 적용하여 인터넷으로부터의 인바운드 SSH를 거부하고 허용된 대상으로의 이그레스를 제한합니다. 근거: 전역 가드레일은 프로젝트 내 잘못된 구성의 위험을 줄여줍니다.

2. 경로 기반 전역 인그레스 및 API 버전 관리 구현

• 단일 애니캐스트 IP와 HTTPS 종료 기능을 갖춘 외부 HTTP(S) Load Balancer를 배포합니다. URL 맵을 구성하여 /v1/* 및 /v2/*를 리전별 영역 NEG(regional zonal NEGs)가 지원하는 별도의 백엔드 서비스로 라우팅합니다. 근거: 별개의 백엔드 서비스를 사용하면 단일 호스트 이름과 TLS 하에서 각 API 버전에 대한 독립적인 배포 및 롤백이 가능합니다.
• Cloud Armor WAF 및 비율 제한을 연결합니다. 캐시 가능한 엔드포인트(예: 제품 이미지)에 대해 Cloud CDN을 활성화합니다. 근거: 오리진을 보호하고 지연 시간 및 이그레스 비용을 절감합니다.

3. 백엔드 도달 가능성 및 상태 보장

• 예상 포트에서 api 인스턴스 그룹으로의 부하 분산기 상태 확인을 허용하는 방화벽 규칙을 생성합니다. 근거: 이 규칙이 없으면 상태 확인이 실패하고 인스턴스가 비정상으로 간주되어 오토스케일러가 비정상적으로 작동할 수 있습니다.
• 리전당 두 개의 영역에 인스턴스를 분산시킵니다. 상태가 계속 바뀌는 현상(flapping)을 피하기 위해 상태 확인 임계값을 보수적으로 설정합니다. 근거: 영역 다양성과 안정적인 상태 정책은 가용성을 향상시킵니다.

4. 스플릿 호라이즌 및 서비스 디스커버리를 사용한 DNS 구축

• contoso.com에 대한 퍼블릭 Cloud DNS 영역과 내부 전용 레코드(예: db.internal.contoso.com)를 위한 동일한 이름의 비공개 영역을 생성합니다. 근거: 스플릿 호라이즌은 일관된 네이밍을 유지하면서 내부 이름이 외부로 유출되는 것을 방지합니다.
• 온프레미스 corp.local 쿼리를 엔터프라이즈 DNS로 전달하고 비공개 영역을 애플리케이션 프로젝트로 가져오도록 DNS 정책을 구성합니다. 근거: 재귀 루프 없이 하이브리드 경계 전반에 걸쳐 원활한 이름 확인이 가능합니다.

5. 이중화를 갖춘 하이브리드 연결 설정

• 각 리전에서 각 데이터 센터로 2개의 HA VPN 터널을 프로비저닝하고, 각 쌍은 BGP를 사용하는 별도의 Cloud Router에 연결합니다. 용량 및 SLA 요구사항이 정당화된다면, 별도의 에지 영역에 이중화된 연결(attachment)을 갖춘 Partner Interconnect를 추가합니다. 근거: 다양한 다중 경로는 장애 조치를 제공합니다. BGP는 빠른 컨버전스와 동적 경로 교환을 가능하게 합니다.
• Shared VPC에서 전역 동적 라우팅을 사용하고 원치 않는 온프레미스 프리픽스가 전파되는 것을 방지하기 위해 경로 필터를 적용합니다. 근거: 리전 전반에 걸쳐 일관된 라우팅을 제공하면서 경로 유출 위험을 줄입니다.

6. Google API 및 아웃바운드 인터넷에 대한 비공개 액세스 제공

• 앱 서브넷에서 Private Google Access를 활성화하고 배치 작업에서 사용하는 Google API에 대해 Private Service Connect 엔드포인트를 구성합니다. 필요한 경우 API가 아닌 아웃바운드 이그레스에는 Cloud NAT를 사용합니다. 근거: 백엔드는 퍼블릭 IP를 유지하지 않으면서도 필요한 서비스에 도달할 수 있습니다. PSC는 비공개 DNS를 통해 이름 확인을 단순화합니다.

7. 전송(Transit) 및 서드파티 연결 중앙화

• 호스트 프로젝트에 Network Connectivity Center 허브를 생성합니다. HA VPN, Interconnect 연결(attachment), 모든 SD-WAN 스포크를 연결합니다. 근거: 허브 앤 스포크 전송 방식은 피어링 메시(peering mesh)에 비해 여러 VPC와 외부 네트워크 간의 경로 분배를 단순화합니다.

8. 관측성 및 가드레일 구현

• 모든 서브넷에서 적절한 샘플링으로 VPC Flow Logs를 활성화하고, 중요한 규칙에 대해 방화벽 로그를 활성화하며, BigQuery로 내보냅니다. 새로운 방화벽 또는 경로 변경을 적용하기 전에 CI/CD에서 Connectivity Tests를 사용합니다. 근거: 심층적인 가시성은 문제 해결, 용량 계획, 감사 가능성을 지원합니다.
• Cloud Router BGP 세션 끊김, Cloud NAT 포트 고갈, 백엔드 상태 저하, Cloud Armor 규칙 적중(hit)에 대한 알림을 설정합니다. 근거: 장애 및 공격의 조기 탐지는 평균 복구 시간(MTTR)을 줄입니다.

9. 성능 및 비용 최적화

• 상태 저장(stateful) 서비스와 컴퓨팅을 동일한 리전에 함께 배치합니다. Cloud CDN을 사용하여 에지에서 정적 콘텐츠를 캐시합니다. 근거: RTT와 리전 간 이그레스를 최소화합니다.
• 주기적으로 플로우 로그를 검토하여 영역 간 불필요한 통신(chatter)을 식별하고 배치 또는 서비스 경계를 조정합니다. 근거: 불필요한 이그레스와 지연 시간을 줄입니다.

이 설계는 버전별 라우팅을 통한 전역적이고 안전한 인그레스, 동적 장애 조치를 갖춘 복원력 있는 하이브리드 연결, 필수 서비스에 대한 비공개 액세스, 포괄적인 관측성을 제공하는 동시에 지연 시간과 이그레스 비용을 제어합니다.

← 데이터 스토리지 · 모든 도메인 · 보안 →

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

Google 찾아보기 →