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, GKE, 데이터 플랫폼), 그리고 사용자 경험을 저해하지 않으면서 유휴 자원 낭비와 탄소 영향을 줄이는 지속 가능성을 고려한 선택에 대해 자세히 설명합니다.

비용 제어 및 가시성

• 결제 계정, 라벨, 비용 할당, 예산, 알림 및 가시성
  • 비즈니스 단위나 자금 출처별로 전용 결제 계정을 사용하여 소유권을 분리하고 세분화된 권한을 설정합니다. 상세 분석, 예측, 비용 청구를 위해 결제 데이터를 BigQuery로 내보냅니다.
  • 라벨은 리소스에 부착하는 키-값 쌍으로 비용 귀속에 사용됩니다. 라벨 키(team, app, env, cost-center)를 표준화하고 조직 정책 및 CI 검사를 통해 적용을 강제합니다. 참고: 라벨은 소급 적용되지 않으며, 라벨이 없는 리소스는 보고서를 왜곡시킬 수 있습니다.
  • 결제 계정 및 프로젝트 수준에서 예산과 알림을 사용합니다. 임계값(예: 50, 90, 100%)과 예측 기반 트리거를 결합하여 사용합니다. 예산 알림을 Pub/Sub으로 라우팅하여 Chat/Ops 도구로 전달합니다. 예산은 알림을 보낼 뿐, 비용 집행을 강제하지는 않습니다.
  • 공유 플랫폼(예: GKE, BigQuery)의 경우, 네임스페이스별 또는 작업별 라벨을 사용하고 이를 로그 및 사용량 데이터에 첨부하여 쇼백/차지백(showback/chargeback)을 구현합니다.

예시: 라벨 추가 gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

• 할당량, 한도, 소비 예측 및 용량 거버넌스
  • 할당량은 서비스를 보호하고 예상치 못한 비용 급증을 제한합니다. 서비스 할당량을 정기적으로 검토하고, 프로젝트별로 적절한 크기로 조정하며, 출시 전에 미리 할당량 증가를 요청합니다. 예상 최대 사용량을 할당량과 비교하는 배포 전 검사를 구현합니다.
  • 결제 내보내기 데이터와 제품 사용량 원격 측정 데이터(Cloud Monitoring 측정항목, 로그 기반 측정항목)를 사용하여 지출을 예측합니다. 예상 시나리오(예상 QPS, 스캔 데이터 양)를 모델링하고 사전 프로덕션 환경에서 검증합니다.
  • 장애 모드: 장애 처리 중이나 제품 출시 중에 할당량에 도달하면 스로틀링(429/403), 부분적인 서비스 중단 또는 조용한 성능 저하로 이어집니다. 과도하게 프로비저닝된 할당량은 결함이 있는 작업의 영향 반경(blast radius)을 넓힙니다.

예시: Compute Engine 할당량 목록 보기 gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

탄력성 및 컴퓨팅 경제학

• 적정 크기 조정, 자동 확장, 요청 기반 결제, 약정 사용, 스팟 용량

  • Cloud Monitoring 및 Recommender의 통계를 사용하여 vCPU와 메모리의 크기를 적절하게 조정하고, 부하 테스트로 검증합니다. 할당량이 너무 적으면 지연 시간 급증과 OOM/CPU 스로틀링이 발생하고, 할당량이 너무 많으면 비용이 낭비됩니다.
  • 자동 확장은 capex와 같은 오버프로비저닝을 탄력적인 opex로 전환합니다. GKE에는 HPA/VPA를 사용하고, 서버리스(Cloud Run)에는 요청별 자동 확장을 사용하여 용량을 수요에 맞춥니다.
  • 요청 기반 결제(Cloud Run, Cloud Functions, GKE Autopilot)는 비용을 사용량에 맞춰 조정하고 유휴 상태를 줄입니다. 요청별 오버헤드와 콜드 스타트에 주의하고, 필요한 경우 최소 인스턴스를 조정합니다.
  • 약정 사용은 안정적인 상태의 기준 워크로드에 적합합니다. Compute Engine에는 리소스 기반 CUD를 사용하고, 지원되는 관리형/서버리스 제품에는 유연한 CUD를 사용합니다. 변동성이 큰 워크로드에 대해서는 과도하게 약정하지 마십시오.
  • 스팟 용량은 중단 가능하고 내결함성이 있는 작업의 컴퓨팅 비용을 절감합니다. 항상 정상 종료 핸들러를 구현하고, 이중화와 빠른 체크포인팅을 유지해야 합니다. 짧은 통보 후 언제든지 종료될 수 있음을 예상해야 합니다.

• Cloud Run 동시성 및 최소 인스턴스의 장단점

  • 동시성은 단일 인스턴스가 동시에 처리할 수 있는 요청 수를 제어합니다.
    • 동시성이 높을수록 사용률과 비용 효율성이 향상되지만, 컨테이너 내부의 head-of-line 블로킹으로 인해 tail latency가 증가할 수 있습니다.
    • 동시성 1은 요청을 격리하지만(CPU 집약적이거나 스레드로부터 안전하지 않은 코드에 유용), 종종 인스턴스 수와 비용을 증가시킵니다.
  • 최소 인스턴스는 기준 비용을 지불하는 대신 콜드 스타트를 줄이고 지연 시간을 완화합니다. SLO에서 요구하는 경우에만 사용하고 수요 패턴을 통해 최소값을 검증해야 합니다.

예시: Cloud Run 구성 (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

• GKE 리소스 요청 및 한도, 클러스터 자동 확장 처리 방식, 유휴 리소스 정리
  • 요청(requests)은 스케줄링을 결정하고, 한도(limits)는 최대 사용량을 제한합니다. 요청은 관찰된 안정적인 필요량에 가깝게 설정하고, 한도는 짧은 급증을 허용하도록 약간 높게 설정합니다. 한도가 너무 낮으면 CPU 스로틀링이 발생하고, 메모리 한도가 너무 낮으면 OOMKilled가 발생합니다. 실제보다 훨씬 높은 요청은 용량을 낭비하고 스케줄링을 방해합니다.
  • Cluster Autoscaler는 스케줄링할 수 없는 파드(총 요청량 부족)를 기반으로 노드 풀을 확장합니다. PodDisruptionBudgets를 준수하며 특정 파드(예: 로컬 스토리지를 사용하거나 제한적인 PDB가 있는 파드)를 축출할 수 없어 스케일 다운을 방해할 수 있습니다. DaemonSets와 노드 taint/affinity 또한 스케일 효율성을 저해할 수 있습니다.
  • Horizontal Pod Autoscaler는 CPU/메모리 또는 커스텀 측정항목에 따라 스케일링을 조정하고, Vertical Pod Autoscaler는 시간에 따라 요청 크기를 적절하게 조정합니다. 진동(oscillation)을 피하기 위해 HPA와 VPA를 조율하고, 상황에 맞게 VPA를 recommend 또는 auto 모드로 사용합니다.
  • 유휴 리소스 정리: 사용하지 않는 부하 분산기, 영구 디스크, 스냅샷, 고정 IP를 삭제합니다. Active Assist 권장사항과 자동화된 정리 도구를 사용하여 유휴 자산을 탐지하고 제거합니다.

예시: 요청/한도가 포함된 GKE 배포 apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

데이터, 분석 및 네트워크 비용 거버넌스

• 스토리지 클래스, 수명 주기 제어, 데이터베이스 확장 및 네트워크 이그레스(egress) 설계
  • 액세스 패턴에 따라 Cloud Storage 클래스를 선택합니다. 핫 데이터는 Standard, 콜드 데이터는 Nearline, Coldline 또는 Archive를 사용합니다. 콜드 티어의 데이터 검색 및 조기 삭제 최소 요금에 유의해야 합니다.
  • 수명 주기 규칙은 데이터 전환 및 삭제를 자동화합니다. 다중 리전 지연 시간이 허용되는 경우 복원력을 위해 이중 리전을 사용하고, 이그레스와 지연 시간을 줄이기 위해 컴퓨팅과 데이터를 동일한 위치에 배치합니다.
  • 데이터베이스 확장:
    • Cloud SQL: 신중하게 수직 확장하고, 읽기 작업에는 읽기 복제본을 사용하며, 스토리지 자동 확장을 활용하고, 쿼리 계획과 커넥션 풀링을 사용합니다. 쓰기 처리량이 높으면 샤딩하거나 Spanner/Bigtable로 마이그레이션해야 할 수 있습니다.
    • Spanner: 노드를 추가하여 수평 확장하고, 가용성 및 전역 읽기를 위해 다중 리전 구성을 사용하며, 부하 분산을 위해 스키마와 키를 설계합니다.
    • Bigtable: 핫스팟을 피하도록 행 키를 설계하고, 클러스터 노드와 스토리지를 별도로 확장합니다.
  • 네트워크 이그레스: 리전 간 트래픽을 피하고, 가능하면 클라이언트와 데이터를 동일한 리전에 배치합니다. 인터넷 규모의 콘텐츠에는 Cloud CDN을, 하이브리드 환경에는 Cloud Interconnect/Peering을, Google API에 비공개로 액세스하려면 Private Google Access 또는 Private Service Connect를 사용합니다. 불필요한 영역/리전 간 트래픽은 비용과 지연 시간을 증가시킵니다.

예시: Cloud Storage 수명 주기

undefined

• BigQuery 쿼리 제어, 데이터 보존 및 분석 사용 비용
  • 스캔되는 바이트 제어: 항상 파티션/클러스터 키로 필터링하고, SELECT * 사용을 피하며, 반복적인 쿼리에는 구체화된 뷰와 결과 캐싱을 사용하고, 가능하면 근사 집계를 사용합니다.
  • 청구되는 최대 바이트 수로 스캔 비용에 상한을 설정하고, 긴급하지 않은 작업은 작업 우선순위를 배치(batch)로 설정하여 경합과 비용을 줄입니다.
  • 요금 모델 선택: 산발적인 워크로드에는 주문형(on-demand)을, 꾸준한 대용량 워크로드에는 약정 기반의 예약(슬롯)을 사용합니다. 팀을 격리하기 위해 별도의 예약과 할당을 사용합니다.
  • 데이터 보존: 거버넌스를 위해 데이터 세트/테이블 및 파티션 만료를 설정하고, 아카이빙을 위해 계층형 스토리지 또는 내보내기를 구현합니다.
  • 장애 모드: 파티셔닝되지 않은 대규모 테이블은 비용을 폭증시키고, 파티션 필터가 없는 쿼리는 전체 테이블을 스캔하며, 지나치게 공격적인 만료 설정은 필요한 데이터를 삭제하고, 과도한 슬롯 경합은 SLA를 저하시킵니다.

예시: 쿼리 비용 상한 설정

undefined

← 테스트 · 모든 도메인

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

Google 찾아보기 →