Google PCD: 컴퓨트, 컨테이너 및 서버리스 런타임 플랫폼 — 학습 가이드

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

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

개요

Google Cloud는 서버리스, 컨테이너, 가상 머신에 걸쳐 여러 런타임 플랫폼을 제공합니다. 적절한 플랫폼 선택은 워크로드의 특성, 예를 들어 요청 패턴, 상태 관리, 빌드 및 릴리스 규율, 운영 모델, 네트워킹 제약 조건 등에 따라 달라집니다. 이 섹션에서는 Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE), Compute Engine의 설계 원칙, 장애 모드, 장단점과 함께 이미지, ID, 네트워킹, 구성, 운영을 지원하는 서비스에 대해 다룹니다.

서버리스 런타임: Cloud Run, App Engine, Cloud Functions

Cloud Run

모델: HTTP 요청을 처리하는 완전 관리형 컨테이너 또는 완료 시까지 실행되는 컨테이너화된 Job입니다.
리비전 및 트래픽: 각 배포는 불변의 리비전을 생성합니다. 리비전 간에 트래픽을 백분율로 분할하여 즉시 롤백이 가능한 카나리 및 블루그린 패턴을 구현할 수 있습니다. 예:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

동시성 및 확장: 기본 동시성은 80입니다. CPU 집약적이거나 스레드로부터 안전하지 않은(non-thread-safe) 코드의 경우 1로 설정합니다. 동시성이 높을수록 콜드 스타트 증폭과 비용을 줄일 수 있지만, 요청당 CPU/메모리가 부족하면 테일 레이턴시가 증가할 수 있습니다. Cloud Run은 수신 요청률에 따라 0으로 축소 및 확장됩니다. 최소/최대 인스턴스로 콜드 스타트를 줄이고 비용을 제한할 수 있습니다.
CPU 할당: 요청 간 백그라운드 작업을 위해 ‘CPU 상시 할당’을 선택하면 추가 비용이 발생합니다. 그렇지 않으면 CPU는 요청을 처리하는 동안에만 할당됩니다.
Job: Cloud Run Job은 N개의 병렬 태스크를 각 태스크의 최대 재시도 횟수와 전체 타임아웃 내에서 완료될 때까지 실행합니다. ETL, 배치, 팬아웃 처리에 적합합니다. 장애 모드로는 많은 태스크가 동일한 종속성을 대상으로 할 때 백엔드에 핫스팟이 발생하는 경우가 있습니다. 속도 제한과 백오프를 사용한 재시도를 추가하세요.
네트워킹: 공개, IAM을 통한 인증, 또는 Serverless VPC Access 및 Private Service Connect를 통해 VPC 뒤에서 비공개로 설정할 수 있습니다.

App Engine

환경:
- Standard: 샌드박스 환경, 빠른 확장, 언어별 고정 런타임, 자동 확장으로 인한 낮은 콜드 스타트 지연 시간, 제한된 파일 시스템, 요청 타임아웃, 인바운드 요청 크기 제한이 있습니다. 대용량 업로드에는 Cloud Storage 서명된 URL을 사용하세요.
- Flexible: Docker 기반, VM과 유사한 기능, 커스텀 런타임, Standard보다 느린 확장 속도, 백그라운드 스레드 및 로컬 디스크 쓰기를 지원합니다.
서비스 및 버전: 하나의 서비스(마이크로서비스)는 여러 버전을 호스팅할 수 있습니다. Cloud Run과 유사하게 버전 간에 트래픽을 백분율로 라우팅합니다. 외부 로드 밸런서 없이 간단하고 중앙 집중화된 라우팅을 위해 dispatch.yaml을 사용하여 특정 경로 또는 호스트를 서비스로 라우팅하세요.
확장: Standard에서는 수동, 기본 또는 자동 확장을 사용하고, Flexible에서는 VM 수 기반 확장을 사용합니다. 장단점: 공격적인 자동 확장은 응답성을 향상시키지만 비용과 백엔드 경합을 증가시킬 수 있습니다.
일반적인 함정: 할당량 없이 인스턴스를 무제한으로 확장하면 다운스트림 시스템에 과부하가 걸릴 수 있습니다. 할당량과 서킷 브레이커를 적용하세요.

Cloud Functions

이벤트 기반 핸들러: HTTP, Pub/Sub, Cloud Storage 또는 Eventarc 이벤트에 의해 트리거됩니다. 2세대를 사용하여 Cloud Run의 실행 모델, VPC 이그레스 제어, 동시성을 활용하세요. 1세대는 한 번에 하나의 요청만 처리합니다.
재시도 및 멱등성: 백그라운드 함수는 실패 시 재시도될 수 있습니다. 이중 처리를 피하기 위해 멱등성 있는 핸들러를 설계하고 중복 제거 키를 사용하세요. HTTP 트리거는 플랫폼에서 재시도되지 않으므로, 클라이언트에서 지수 백오프를 사용한 재시도를 구현해야 합니다.
런타임 구성: 환경 변수, Secret Manager 통합, 함수별 동시성/최대 인스턴스 설정이 있습니다. 비용 급증을 막기 위해 타임아웃을 설정하세요. 의존성이 클 경우 콜드 스타트가 길어질 수 있으니 패키지를 가볍게 유지하세요.

Google Kubernetes Engine의 컨테이너

워크로드

Deployments: 롤링 업데이트를 사용하는 상태 비저장 파드입니다. 서지/사용 불가 제한으로 안전한 롤아웃을 보장하세요:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

StatefulSets: 상태 저장 서비스를 위한 순서가 있고 안정적인 네트워크 ID 및 영구 볼륨입니다.
DaemonSets, Jobs, CronJobs: 노드 수준 에이전트 및 배치 워크로드입니다.

Service 및 Ingress

Service 유형:
- ClusterIP: 내부 전용입니다.
- NodePort: 간단한 외부 액세스용입니다(운영상 제한적임).
- LoadBalancer: 리전 외부/내부 로드 밸런싱용입니다.
Ingress: HTTP(S) 라우팅 및 TLS 종료입니다. L7 정책을 위해서는 Gateway API 또는 관리형 컨트롤러가 있는 Ingress를 사용하는 것이 좋습니다. 장애 모드: 방화벽으로 인해 상태 확인이 실패하는 경우, 로드 밸런서 IP 범위를 백엔드 노드에 허용해야 합니다.

오토스케일링 및 노드 풀

Horizontal Pod Autoscaler (HPA): CPU, 메모리 또는 커스텀 메트릭을 기준으로 파드를 확장합니다. 가용성을 보호하기 위해 Pod Disruption Budget과 함께 사용하세요.
Vertical Pod Autoscaler (VPA): 파드의 요청/제한을 적절한 크기로 조정합니다. 피드백 루프를 방지하려면 동일한 차원에서 HPA와 VPA를 동시에 사용하지 마세요.
Cluster Autoscaler: 대기 중인 파드의 리소스 요청을 충족시키기 위해 노드를 추가/제거합니다.
노드 풀: 워크로드 클래스별로 풀을 분리합니다. 스케줄링을 위해 taint/toleration 및 레이블을 사용하세요. 중단 허용이 가능한 비용에 민감한 워크로드에는 스팟/선점형을 혼합하여 사용하세요. 파드별 제한으로 인한 스로틀링을 피하기 위해 충분한 메모리 대역폭/CPU를 갖춘 머신 유형을 선택하세요.

상태 및 롤아웃

Liveness, readiness, startup 프로브는 준비되지 않은 파드로 트래픽이 전송되는 것을 방지하고 교착 상태에 빠진 컨테이너를 재시작합니다. Liveness 프로브를 너무 타이트하게 설정하면 연쇄적인 재시작이 발생할 수 있으므로 초기 지연 시간과 실패 임계값을 조정하세요.
kubectl rollout undo로 롤백합니다. 카나리 배포를 위해서는 여러 Deployment를 사용하고 Ingress/Gateway를 통해 Service 수준에서 트래픽을 분할하세요.

애플리케이션 워크로드를 위한 Compute Engine

VM 설계

인스턴스 템플릿은 머신 유형, 이미지, 디스크, 서비스 계정 범위, 시작 스크립트, 메타데이터를 정의합니다. 이미지는 최소한으로 유지하고, 결정론적 부팅을 위해 시작 스크립트나 Packer로 구운(baked) 이미지를 사용합니다.
디스크: 지연 시간에 민감한 앱에는 균형 있는(balanced) 또는 SSD 영구 디스크를 사용합니다. 관리형 인스턴스 그룹(managed instance group) 전체에서 대용량 읽기 전용 데이터 세트를 공유하려면, 여러 인스턴스에 연결된 읽기 전용 영구 디스크를 통해 낮은 지연 시간과 빠른 시작을 구현할 수 있습니다.
네트워킹: 부하 분산기(load balancer)를 사용할 때는 상태 확인(health checker)을 위한 방화벽 규칙을 생성합니다. 예시:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

관리형 인스턴스 그룹(Managed Instance Groups, MIGs)

CPU, 초당 부하 분산기 요청 수, 커스텀 측정항목 또는 일정에 따라 자동 확장(Autoscaling)합니다. 과도한 변동(thrashing)을 방지하기 위해 냉각 기간(cool-down)을 설정합니다.
상태 확인을 통한 자동 복구(Autohealing)는 비정상 VM을 다시 시작합니다. 500 오류를 제공하는 것을 방지하려면, 상태 확인 경로가 단순한 포트 연결 가능성이 아닌 애플리케이션 준비 상태를 테스트하도록 해야 합니다.
롤링 업데이트 및 블루-그린(blue-green): 새 인스턴스 템플릿을 만들고 인스턴스의 일부에 카나리(canary) 업데이트를 시작합니다. 오류가 증가하면 이전 템플릿으로 롤백(rollback)합니다. 가동 시간 확인(Uptime check)과 SLO 기반 알림은 성능 저하를 신속하게 감지합니다.

로깅 및 모니터링

에이전트를 설치하여 코드 변경 없이 앱 로그를 수집하고, Cloud Logging으로 전송하며 Cloud Monitoring을 통해 알림을 보냅니다. 중단을 최소화하면서 실시간 진단을 하려면 Debug Logpoints를 사용합니다.

빌드, ID, 네트워킹, 보안 비밀 및 운영

Artifact Registry와 이미지

컨테이너 이미지와 언어 아티팩트에는 Artifact Registry를 사용합니다. 취약점 스캔과 출처 생성을 활성화합니다. 이미지를 작게 유지합니다:
- 다단계 빌드를 사용하여 빌드와 런타임을 분리합니다.
- 최종 이미지에 개발 도구를 포함하지 않고, OS 및 패키지 버전을 고정합니다. 예시:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

프로모션: 이미지를 불변적으로 태그(예: app:1.3.7, app:prod-20240901)하고, Artifact Registry에서 다시 태그하여 프로모션합니다. 프로덕션에서는 변경 가능한 latest 태그 사용을 피합니다. 통합 및 카나리 테스트 결과로 프로모션을 제어(gate)합니다.

런타임 ID 및 최소 권한

워크로드별로 전용 서비스 계정을 할당하고 필요한 최소한의 IAM 역할을 부여합니다. Editor와 같은 광범위한 역할은 피합니다. GKE에서는 Workload Identity를 통해 Kubernetes ServiceAccount를 Google 서비스 계정에 매핑합니다. 서버리스의 경우 런타임 서비스 계정을 명시적으로 설정하고 기본 토큰 범위를 제거합니다.

VPC 커넥터 및 서비스 네트워킹

Serverless VPC Access 커넥터는 Cloud Run, Cloud Functions, App Engine의 이그레스(egress) 트래픽을 VPC로 라우팅합니다. 이그레스 모드를 선택합니다:
- 비공개 범위만(Private ranges only): RFC1918 및 VPC 연결 서비스에 도달하는 데 사용하고, 공개 이그레스는 직접 나갑니다.
- 모든 트래픽(All traffic): 커넥터와 Cloud NAT를 함께 사용하여 결정적인 이그레스 IP를 확보하고 아웃바운드 정책을 제한합니다.
비공개 종속 항목: Cloud SQL에는 비공개 IP를, Google API 또는 파트너 서비스에는 Private Service Connect를 사용하는 것이 좋습니다. 커넥터가 리전과 일치하고 처리량에 맞게 크기가 조정되었는지 확인합니다. 커넥터 CPU를 모니터링하여 스로틀링(throttling)을 방지합니다.

구성, 보안 비밀 및 상태 확인

보안 비밀이 아닌 구성에는 환경 변수를 사용합니다. 보안 비밀은 Secret Manager에 저장하고 런타임에 마운트하거나 주입합니다. 키를 정기적으로 순환합니다. GKE에서는 Secret과 Secret Manager용 CSI 드라이버를 사용합니다. App Engine 및 Cloud Run에서는 서비스 계정에 특정 보안 비밀에 대한 액세스 권한을 부여합니다.
상태 확인:
- Cloud Run: 비정상 종료 시 인스턴스 재시작, 요청 수준 확인 및 지연 시간 SLI를 사용합니다.
- App Engine: 기본 제공 상태 확인, Flexible 환경의 경우 liveness/readiness를 맞춤설정합니다.
- GKE: liveness/readiness/startup 프로브를 구성합니다.
- LB 뒤의 Compute Engine: 애플리케이션별 엔드포인트를 사용하는 HTTP(S) 상태 확인을 사용합니다.

문제 해결, 롤백 및 출시 패턴

Cloud Run 및 App Engine에서 트래픽 분할을 이용한 블루-그린 및 카나리 배포, GKE에서는 병렬 Deployment 또는 점진적 배포 컨트롤러를 사용하고, MIG에서는 인스턴스의 카나리 서브셋을 사용합니다. 항상 SLO 오류 예산 및 지연 시간을 기준으로 중단 기준을 정의합니다.
일반적인 장애 모드:
- 0으로 축소(scale-to-zero) 또는 대규모 출시 후 발생하는 ‘Thundering herd’ 현상. 최소 인스턴스, 준비(warmup) 요청, 비율 제한으로 완화합니다.
- 백엔드 할당량 또는 연결 한도 초과. 지수 백오프(exponential backoff) 및 서킷 브레이커(circuit breaker)를 적용합니다.
- 큰 이미지 또는 종속성으로 인한 콜드 스타트. 이미지를 줄이고 클라이언트를 미리 초기화합니다.

실용적인 문제 시나리오

Acme Retail은 이미지 크기 조정 API를 자체 관리 VM에서 확장 가능하고 비용 효율적인 플랫폼으로 마이그레이션하려고 합니다. 이 플랫폼은 낮은 지연 시간 응답, 리전 Cloud Storage 버킷에 대한 비공개 액세스, 안전한 카나리 출시를 지원해야 합니다.

접근 방식

서비스를 작은 컨테이너 이미지로 패키징하여 Artifact Registry에 게시합니다.

근거: 슬림한 다단계 Docker 빌드는 콜드 스타트와 네트워크 전송을 최소화합니다. Artifact Registry는 스캔 및 프로모션 워크플로를 중앙에서 관리합니다.

API를 Cloud Run에 배포하고, 최소 인스턴스 2개, 동시성 40, CPU 상시 할당 비활성화로 설정합니다.

근거: Cloud Run은 즉각적인 수평 확장과 관리형 HTTPS를 제공합니다. 작은 최소 인스턴스 풀은 일일 트래픽 피크 동안 콜드 스타트 지연 시간을 줄여줍니다. 동시성 40은 I/O 집약적인 이미지 변환 작업의 비용과 tail latency 간의 균형을 맞춥니다. CPU 상시 할당을 비활성화하면 요청 사이의 유휴 컴퓨팅 비용을 절약할 수 있습니다.

Serverless VPC Access 커넥터를 생성하고 이그레스를 ‘비공개 범위만’으로 설정합니다. 서브넷에서 비공개 Google 액세스를 활성화하고, 필요한 경우 Cloud Storage용 VPC-SC 또는 Private Service Connect 엔드포인트를 구성합니다.

근거: API는 공개 이그레스 없이 비공개로 이미지를 가져오고 써야 합니다. ‘비공개 범위만’ 모드는 VPC 트래픽만 커넥터를 통과하도록 보장하여 공개 호출은 직접적이고 효율적으로 유지합니다. 비공개 Google 액세스 또는 Private Service Connect는 VPC에서 Google API에 대한 비공개 액세스를 제공합니다.

전용 런타임 서비스 계정에 대상 Cloud Storage 버킷 및 필요한 보안 비밀에 대한 최소 권한 액세스를 부여합니다.

근거: 최소 권한 원칙은 장애 발생 시 영향을 받는 범위(blast radius)를 제한합니다. 런타임 ID는 특정 버킷에 대한 storage.objectViewer 및 storage.objectAdmin 권한과 필요한 Secret Manager 보안 비밀에 대한 accessor 역할을 받습니다.

API 키와 환경별 구성은 Secret Manager와 환경 변수에 저장하고, 보안 비밀은 런타임에 주입합니다.

근거: 중앙 집중식 보안 비밀 순환 및 감사 가능한 액세스를 지원합니다. 환경 변수를 통한 비보안 구성은 12-factor 원칙을 지원합니다.

Cloud Storage에서 발생하는 429/5xx 오류를 처리하기 위해 지수 백오프와 멱등성(idempotent) 쓰기를 구현합니다.

근거: 트래픽 급증 또는 리전 이벤트 중에 일시적인 오류가 발생할 수 있습니다. 지터(jitter)를 사용한 백오프는 API와 Cloud Storage 모두를 재시도 폭풍(retry storm)으로부터 보호합니다.

카나리 리비전(revision)을 구성하고 트래픽의 10%를 분할하여 보냅니다. 오류율, P95 지연 시간, 포화도를 모니터링합니다.

근거: Cloud Run의 트래픽 분할 기능은 안전한 점진적 출시를 가능하게 합니다. SLO 기반 모니터는 오류 예산이 너무 빨리 소진될 경우 자동 롤백 트리거를 제공합니다.

다운스트림 종속성을 테스트하는 HTTP 상태 엔드포인트를 추가합니다. Cloud Monitoring 가동 시간 확인 및 로그 기반 측정항목에 대한 알림을 설정합니다.

근거: 엔드투엔드 상태 확인은 종속성 장애를 조기에 감지합니다. 가동 시간 확인은 외부 관점을 제공하며, 로그 기반 측정항목은 애플리케이션별 장애 패턴을 포착합니다.

자동 확장 한도와 예산을 설정합니다. 최대 인스턴스를 설정하여 지출을 제한하고, 과부하에 대한 429 처리 방식을 정의합니다.

근거: 확장 규모를 제한하면 통제 불가능한 비용과 백엔드 고갈을 방지할 수 있습니다. 정상적인 과부하 처리는 서비스 안정성을 유지합니다.

롤백 절차 문서화: 단일 명령으로 트래픽 100%를 이전 Cloud Run 리비전으로 되돌립니다.

근거: 불변 리비전은 롤백을 안전하고 빠르게 만들어 평균 복구 시간(MTTR)을 최소화합니다.

← 클라우드 네이티브 애플리케이션 아키텍처 및 서비스 선택 · 모든 도메인 · API 설계 →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

시험 합격하기 →

Google 찾아보기 →