Google PCD: 성능, 확장성 및 복원력 엔지니어링 — 학습 가이드

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

개요

Google Cloud에서의 성능, 확장성, 복원성 엔지니어링은 가변적인 부하에서도 낮은 지연 시간과 비용 효율적인 서비스를 유지하고, SLO를 위반하지 않으면서 장애를 허용하는 데 중점을 둡니다. 설계 시에는 워크로드 특성에 맞춰 자동 확장 신호를 조정하고, 데이터와 컴퓨팅을 배치하여 테일 지연 시간을 최소화하며, 과부하 제어, 재시도, 장애 조치를 구현하여 연쇄 장애를 방지해야 합니다. 이 섹션에서는 컴퓨팅, 네트워킹, 데이터 계층 전반에 걸쳐 애플리케이션 개발자에게 중요한 패턴, 제어, 장단점을 자세히 설명합니다.

확장 및 부하 분산

수평 확장 vs 수직 확장

수평 확장은 인스턴스나 포드를 추가하여 용량과 복원성을 높입니다. 상태 비저장(stateless) 서비스나 빠른 탄력성이 필요할 때 선호됩니다. Managed Instance Groups (MIGs), Cloud Run 리비전 또는 GKE Deployments를 사용합니다.
수직 확장은 머신 크기를 늘리는 것입니다. 단일 스레드 또는 메모리 집약적 워크로드에 유용하거나 노드 간 조정 작업을 줄이는 데 도움이 되지만, 확장 여유 공간이 제한적이고 재시작 시간이 더 깁니다.
동시성: CPU 집약적 프로필과 I/O 집약적 프로필에 맞게 요청 동시성을 조정합니다. Cloud Run은 리비전별 동시성을 지원하며, GKE 포드는 런타임이 논블로킹(non-blocking)인 경우 여러 요청을 처리할 수 있습니다. 엄격한 격리가 필요하면 동시성을 1로 설정합니다.

자동 확장 신호 및 준비된 용량(warm capacity)

MIG 자동 확장은 CPU 사용률, 부하 분산 사용률, 그리고 Cloud Monitoring을 통한 커스텀 측정항목을 지원합니다. 트래픽이 급증하는 경우, CPU보다는 요청 관련 측정항목(rps, 큐 깊이)을 기반으로 확장하세요.
GKE Horizontal Pod Autoscaler (HPA)는 CPU, 메모리 또는 커스텀/외부 측정항목(예: Pub/Sub 큐 길이)을 기반으로 확장할 수 있습니다. 리소스 최적화(right-sizing)를 위해 Vertical Pod Autoscaler (VPA)를 사용하되, 빠르게 확장되는 프런트엔드에서는 churn(잦은 변경)을 방지하기 위해 VPA 실시간 업데이트를 피하세요.
Cloud Run은 동시 요청 부하와 선택적으로 커스텀 측정항목에 따라 확장됩니다. 콜드 스타트를 피하기 위해 준비된 용량(warm capacity)을 유지하세요: 최소 인스턴스를 구성하고, 유휴 동시성을 낮게 유지하며, 필요한 경우 가상 상태 확인 핑(synthetic health pings)을 통해 미리 준비(pre-warm)합니다.
MIG의 예측 자동 확장과 Deployment/Revision에서 최소 복제본을 설정하는 것은 일일 최고점 동안의 프로비저닝 지연 시간을 가리는 데 도움이 됩니다.

부하 분산, 글로벌 트래픽 분산, 상태 확인, 장애 조치

전 세계적인 애니캐스트(anycast) VIP, HTTP/2 및 HTTP/3, 그리고 Cloud CDN을 통한 에지(edge) 종료를 위해 글로벌 외부 Application Load Balancer를 사용하세요. 백엔드는 인스턴스 그룹, 영역/리전 NEG, 서버리스 NEG(Cloud Run/Functions) 또는 GKE Ingress가 될 수 있습니다.
상태 확인은 비정상 백엔드로부터 트래픽을 다른 곳으로 보냅니다. 다운스트림 중단 시 순환 장애를 피하기 위해 상태 확인 엔드포인트가 의존성을 좁게(예: 프로세스 및 중요한 로컬 리소스) 검증하도록 하세요.
방화벽 허용 목록은 상태 검사기를 허용해야 합니다. 80번 포트로의 확인이 실패하면 Google의 범위를 허용하세요:

undefined

장애 조치: 상태 확인 실패 시 대체 리전으로 트래픽을 보내는 기본/백업 백엔드 서비스 또는 트래픽 정책을 구성하세요. DNS 수준의 장애 조치를 위해서는 비-HTTP 엔드포인트에 대한 상태 확인 기능이 있는 Cloud DNS 정책을 사용하세요.

지연 시간 및 효율성

지연 시간 예산

계층(클라이언트, 에지, 앱, 데이터)별로 종단 간 지연 시간 예산을 할당하세요. 평균이 아닌 p95/p99를 모니터링하세요. Cloud Trace를 사용하여 서비스 간 기여 요인과 head-of-line 블로킹을 찾으세요. RPC에 데드라인을 적용하여 업스트림의 취소가 용량을 확보하도록 하세요.

캐싱 및 CDN 사용

계층화된 캐시: 클라이언트/브라우저 캐시, CDN 에지(Cloud CDN), 리전/메모리 캐시(Memorystore 또는 인-프로세스). 캐시 키를 신중하게 선택하고 vary 헤더를 사용하세요. 데이터 최신성과 부실 데이터(stale)의 위험에 따라 TTL을 설정하고, 안전한 경우 404에 대한 네거티브 캐싱을 고려하세요.
오리진 부하와 테일 지연 시간을 줄이기 위해 Cloud CDN 뒤의 Cloud Storage에서 정적 애셋을 제공하세요. 제어된 액세스를 위해 서명된 URL/헤더를 사용하세요.

연결 재사용

멀티플렉싱과 헤더 압축을 위해 HTTP/2 또는 gRPC를 선호하세요. 핸드셰이크 오버헤드를 줄이기 위해 keep-alive와 연결 풀링을 활성화하세요. NAT 포트 고갈을 주시하고, 클라이언트 연결 풀과 유휴 타임아웃을 조정하며, 해당되는 경우 VM당 Cloud NAT 포트 크기를 조절하세요.

페이로드 효율성

바이너리 인코딩(예: protobuf)을 사용하고, 특정 크기 임계값 이상의 텍스트 페이로드는 압축(gzip/brotli)하세요. 요청/응답 필드를 신중하게 설계하고, 페이지네이션, 서버 측 필터링을 사용하며, 과도한 데이터 가져오기(over-fetching)를 피하세요. ETag와 조건부 요청(If-None-Match)을 사용하여 중복 전송을 피하세요. Cloud Storage의 경우, 부분 콘텐츠에 대해 generation 전제 조건과 Range 읽기를 사용하세요.

과부하 및 복원성 패턴

속도 제한, 역압, 큐잉, 배치 처리

에지(edge)에서 속도 제한을 적용하고(Cloud Armor를 사용하여 IP/지역/서비스 기반 속도 제한) API 계층에서 적용합니다(Apigee 할당량, API 클라이언트별 토큰). 공정한 공유를 위해 서버 측에서 토큰 버킷 또는 리키 버킷 알고리즘을 구현합니다.
역압(Backpressure): 다운스트림 시스템의 처리 속도를 초과하지 마세요. 큐를 사용하세요(최소 한 번(at-least-once) 이벤트 전달을 위한 Pub/Sub, 큐별 및 대상별 조절(throttle)과 스케줄링 및 재시도를 지원하는 Cloud Tasks). 클라이언트의 요청을 늦추기 위해 Retry-After 헤더와 함께 429 Too Many Requests 또는 503을 전파합니다.
배치 처리는 처리량을 높이고 호출당 오버헤드를 줄일 수 있지만(예: 데이터베이스에 대한 배치 변경 또는 Pub/Sub ack 배치 처리), 효율성을 위해 지연 시간이 늘어나는 트레이드오프가 있습니다. 배치 크기와 최대 대기 시간을 조정하세요.

과부하 보호

모든 RPC에 타임아웃과 데드라인을 적용하세요. 서킷 브레이커를 사용하여 실패한 종속성으로 작업을 보내는 것을 중단하고 빠른 폴백(fallback)을 활성화하세요. 핵심 기능을 보호하기 위해 큐 깊이, CPU 또는 지연 시간 SLO 위반을 기반으로 부하 차단(load shedding)을 구현하세요.

복원력 있는 재시도, 지수 백오프, 지터, 멱등성, 중복 처리

안전할 때만 재시도하세요: 네트워크 타임아웃, 5xx 또는 문서화된 재시도 가능 코드(예: Cloud Storage 429/5xx). 400/401/403과 같은 4xx 오류는 명시되지 않는 한 절대 재시도하지 마세요.
동기화된 재시도를 피하기 위해 지터(jitter)가 포함된 잘린 지수 백오프(truncated exponential backoff)를 사용하세요. 풀 지터(full jitter)를 사용하는 것이 좋습니다. 예시:

undefined

멱등성을 보장하세요. 중복을 허용하기 위해 멱등성 키(예: 고유한 작업 ID)와 upsert/조건부 쓰기를 사용하세요. Pub/Sub의 경우 messageId 또는 애플리케이션 키를 사용하여 중복을 제거하고, 최소 한 번 전달(at-least-once delivery)에 안전하도록 핸들러를 설계하세요. Cloud Storage 쓰기의 경우, 덮어쓰기를 방지하기 위해 generation-match 사전 조건을 사용하세요.

휴면 리소스 워밍업(Ramp-up)

일부 서비스는 적응형 제한(adaptive limits)을 적용합니다. Cloud Storage의 경우, 이전에 유휴 상태였던 버킷에 대한 요청률을 점진적으로 높여 갑작스러운 스파이크 동안 발생하는 일시적인 429/5xx 오류를 줄이세요. 전체 부하를 가하기 전에 제어된 트래픽으로 생산자(producer)를 조절하고 버킷을 워밍업하세요.

← 관찰 가능성 · 모든 도메인 · 테스트 →

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