Google PCA: 비용, 성능 및 지속 가능한 클라우드 설계 — 학습 가이드

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

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

개요

비용, 성능, 지속 가능한 클라우드 설계는 함께 최적화되는 분야입니다. Google Cloud에서 효율적인 아키텍처를 구축하려면 재무적 가시성, 수요에 따른 탄력적인 용량, 엄격한 데이터 수명 주기 관리, 정보에 기반한 네트워크 배치 및 캐싱, 지속적인 측정이 필요합니다. 이 섹션에서는 안정성, 보안 또는 성능을 저하시키지 않으면서 낭비를 줄이는 설계 및 운영 패턴을 설명하고, 비용 관련 예기치 않은 문제를 피하기 위한 장애 모드와 장단점을 강조합니다.

비용 아키텍처 및 재무 책임

플랫폼 기본 구성의 일부로 재무 통제 체계를 구축하십시오.

• 결제 분석 및 할당

  • 프로젝트, 서비스, SKU, 라벨별로 쿼리 가능한 거의 실시간 비용 분석을 위해 결제 데이터를 BigQuery로 내보내십시오. 확장 가능한 쿼리를 위해 일별로 파티셔닝하고 재무 및 엔지니어링 이해관계자를 위한 데이터 세트 접근 제어를 설정하십시오.
  • 알림 임계값이 있는 예산을 사용하여 비용 초과를 방지하십시오. 예산 알림을 Pub/Sub으로 라우팅하고 응답을 자동화하십시오(예: 중요하지 않은 워크로드 일시 중지). 알림은 트랜잭션 방식이 아니며 보고 지연이 있을 수 있음을 인지해야 합니다. 폭주하는 작업을 제어하는 유일한 수단으로 의존해서는 안 됩니다.

• 라벨, 태그, 비용 귀속

  • 조직 전체의 라벨(cost_center, env, owner, app)을 표준화하고 배포 템플릿이나 policy-as-code를 사용하여 프로비저닝 시점에 이를 강제하십시오.
  • 차지백/쇼백 모델을 반영하기 위해 계층적 태그와 폴더/프로젝트 구조를 사용하는 것이 좋습니다. 정확한 할당을 위해 라벨(리소스 수준)과 태그(정책 및 결제 범위)를 모두 사용하십시오.

• 예산 가드레일 및 이상 감지

  • 프로젝트별 및 포트폴리오별 예산을 구성하고, 여러 임계값(예: 50, 80, 100%)과 ‘예측’ 알림을 설정하여 사전 조치를 취하십시오.
  • Recommender 권장사항(유휴 VM, 연결되지 않은 디스크, IP, 미사용 약정)을 사용하여 지속적으로 낭비를 제거하십시오.

• 실용적인 예시

  • 생성 시 라벨 적용:

undefined

• CI/CD 검사를 통해 규정 준수를 강제하기 위해 라벨이 없는 비용에 대해 결제 내보내기 데이터를 쿼리하십시오.

일반적인 장애 모드 및 장단점:

• 일관성 없는 라벨은 비용 할당을 어렵게 만듭니다. 조직 정책과 파이프라인 내 검증을 통해 강제하십시오.
• 팀별 예산이 없는 중앙 집중식 결제는 책임 소재를 불분명하게 만듭니다. 팀 또는 제품 수준에서 예산을 생성하십시오.
• 예산 알림이 지연되면 급격한 비용 증가가 예산을 초과할 수 있습니다. 가능한 경우 상한선과 할당량을 계층적으로 적용하십시오.

컴퓨팅 효율성 및 성능

워크로드 프로필에 맞게 리소스를 조정하고, 탄력성을 자동화하며, 안정적인 기본 부하에 대해 예약 또는 할인을 적용하십시오.

• 라이트사이징 및 커스텀 머신 유형

  • CPU, 메모리, 디스크 IOPS, 네트워크 사용률을 지속적으로 분석하여 라이트사이징하십시오. 커스텀 머신 유형을 사용하여 vCPU와 메모리를 앱의 실제 필요에 맞추고 유휴 메모리에 대한 비용 지불을 피하십시오.
  • 헤드룸에 유의하십시오. 지속적인 CPU 사용률 60~75%를 목표로 하고 GC 또는 스파이크에 충분한 메모리 헤드룸을 확보하십시오. 너무 공격적인 라이트사이징은 쓰로틀링 또는 OOM(메모리 부족)의 위험을 증가시킵니다.

• 오토스케일링 및 수명 주기 스케줄링

  • 관련 신호(CPU, 부하 분산기 용량 또는 커스텀 큐 깊이)에 따라 관리형 인스턴스 그룹 오토스케일링을 사용하십시오. 준비 기간(warmup period)과 축소 제어(scale-in control)를 구성하여 스래싱을 방지하십시오.
  • 24/7 환경이 아닌 경우, VM, GKE 노드 풀 또는 Cloud Run 최소 인스턴스의 시작/중지를 예약하여 유휴 비용을 피하십시오. 간단한 첫 단계는 Cloud Scheduler를 사용하여 매일 밤 개발 인스턴스를 중지하는 Cloud Run 작업을 트리거하는 것입니다.

• 할인 수단

  • 약정 사용 할인(CUD): 약정 대상이 되는 안정적인 상태의 사용량에 대해 1~3년 약정을 하십시오. 과거 사용량 및 비즈니스 예측과 약정 규모의 균형을 맞추십시오. 과도한 약정은 비용 낭비입니다.
  • Spot VM: 내결함성, 배치 또는 분산 워크로드에 이상적입니다. 언제든지 회수될 수 있으므로, 체크포인팅과 온디맨드 폴백이 포함된 다중 인스턴스 그룹을 구현하십시오.
    • 예시:

undefined

• 용량 예약: 리전의 자원 부족 시 스케일업 실패를 완화하기 위해 중요한 플릿을 위한 영역 또는 리전 용량을 예약하십시오.
  • 예시:

undefined

• 사용률 지표 및 성능 튜닝
  • Cloud Monitoring, Profiler, Trace를 사용하여 계측하십시오. p50/p95 지연 시간, CPU 스틸, GC 시간, 큐 백로그를 측정하십시오. 스케일 아웃하기 전에 핫 코드 경로를 최적화하십시오.
  • 성능에 민감한 워크로드를 적절한 CPU 플랫폼이 있는 리전 및 영역에 고정하고, 필요한 경우 처리량이 높은 영구 디스크 또는 Hyperdisk를 고려하십시오.

장애 모드 및 장단점:

• 제한 없는 오토스케일링은 할당량과 비용 목표를 초과할 수 있습니다. 할당량을 미리 상향 조정하고, 최대 복제본 수를 설정하며, 알려진 피크에 대해서는 예측 오토스케일링을 사용하십시오.
• Spot VM은 플릿의 부분적인 이탈을 유발할 수 있습니다. 영역을 다각화하고 정상 종료 훅(graceful termination hook)을 구현하십시오.
• CUD를 과도하게 약정하거나 예약을 충분히 활용하지 않으면 매몰 비용이 발생합니다. 분기별로 약정을 검토하십시오.

스토리지, 데이터베이스, 분석 비용 대비 성능

액세스 패턴, 보존 기간, 성능 SLO를 반영하여 스토리지 클래스와 데이터베이스 용량 모델을 선택하세요.

• 스토리지 클래스 및 수명 주기 정책

  • 자주 액세스하는 데이터(hot)는 Standard, 월별 액세스는 Nearline, 분기별 액세스는 Coldline, 장기 보관하며 거의 액세스하지 않는 데이터는 Archive를 사용하세요. 이그레스(egress) 비용을 피하려면 데이터와 컴퓨팅을 동일한 리전에 두세요.
  • 수명 주기 관리를 적용하여 객체를 자동으로 전환하거나 삭제하세요. 최소 스토리지 기간과 검색 요금에 유의하세요. 너무 이른 클래스 전환은 절약되는 비용보다 더 많은 비용을 초래할 수 있습니다.
  • 수명 주기 정책 예시 (90일 이상 된 객체 삭제):
    • { “rule”: [{ “action”: {“type”: “Delete”}, “condition”: {“age”: 90} }]}
    • gsutil lifecycle set lifecycle.json gs://my-backups

• 데이터 전송 및 아카이브

  • 리전 간 액세스는 종종 이그레스 비용을 발생시킵니다. 생산자와 소비자를 같은 위치에 배치하세요. 보안과 비용을 고려하여 Google API에 액세스하려면 Private Google Access와 VPC-SC를 사용하세요. 장기 아카이브의 경우, 높은 검색 요금을 피하기 위해 Archive에서 데이터를 자주 검색하지 마세요.

• 데이터베이스 사이징 및 성능

  • 관계형: 메모리에 상주하는 워킹셋(working set), IOPS, 읽기 복제본(read replica)에 맞춰 크기를 조정하세요. 자동 스토리지 증가를 활성화하고 복제 지연(replication lag)을 모니터링하세요. 지연이 RPO/RTO를 위협할 경우 수직 확장(scale vertically) 또는 수평 샤딩(shard horizontally)을 수행하세요.
  • NoSQL/시계열: 핫스팟(hotspot)을 피하기 위한 적절한 행 키(row key) 설계와 함께, 처리량이 높고 지연 시간이 짧은 수집을 위해 Bigtable을 사용하세요.

• BigQuery 비용 제어 및 용량 모델

  • 주문형(On-demand, 스캔된 TB당): 시작은 빠르지만 비용 급증(spiky cost) 위험이 있습니다. 용량 기반 예약: 예측 가능한 지출, 동시성 및 처리량 제어가 가능합니다. Flex 약정은 단기적인 급증을 흡수합니다.
  • 파티셔닝과 클러스터링으로 쿼리를 최적화하세요. 전체 테이블 스캔을 방지하기 위해 파티션 필터를 요구하세요:
    • bq update –require_partition_filter=true myds.mytable
  • 작업당 청구되는 최대 바이트를 설정하여 지출 상한을 정하세요:
    • bq query –use_legacy_sql=false –maximum_bytes_billed=100000000000 ‘SELECT …’
  • 구체화된 뷰(materialized view), 결과 캐시, 근사 집계(approximate aggregation)를 사용하고, 프로덕션 환경에서 SELECT * 사용을 피하세요. 스토리지와 컴퓨팅을 동일한 리전에 유지하세요.

장애 모드 및 절충점:

• 자주 사용하는(hot) 객체를 Coldline/Archive로 이동하면 검색 비용과 조기 삭제 수수료가 발생합니다.
• 제어 장치 없는 BigQuery 주문형(on-demand) 모델은 필터링되지 않은 스캔으로 인해 통제 불가능한 비용을 초래할 수 있습니다. 청구되는 최대 바이트와 파티션 필터를 강제하세요.
• 데이터베이스를 과도하게 샤딩하면 운영 복잡성이 증가합니다. 분할하기 전에 벤치마크를 수행하세요.

← DevOps · 모든 도메인

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

Google 찾아보기 →