Google ACE: 비용 관리, 성능 및 용량 최적화 — 학습 가이드

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

개요

Google Cloud에서의 비용 관리 및 성능/용량 최적화는 지속적인 가시성, 적정 규모 산정 결정, 그리고 리소스 활용을 비즈니스 목표에 맞추는 거버넌스를 필요로 합니다. 효과적인 관행은 재무적 통제(예산, 할당), 기술적 수단(자동 확장, 예약, 수명 주기 정책), 아키텍처 선택(데이터 지역성, 복제), 그리고 운영 피드백(원격 측정, 부하 테스트)을 결합합니다. 이 섹션에서는 컴퓨팅, 스토리지, 데이터 처리, 네트워킹, 데이터베이스, 할당량, 성능 엔지니어링 전반에 걸친 주요 도구, 장단점, 실패 모드를 자세히 설명합니다.

비용 가시성, 예산 및 할당

• 결제 보고서 및 내보내기:

  • 빠른 추세 및 SKU별 분석을 위해 Cloud Billing 보고서를 사용하고, 상세하고 쿼리 가능한 비용 및 사용량 데이터를 위해 Cloud Billing 데이터 내보내기를 BigQuery로 활성화하세요. 이를 통해 표준 SQL로 일별/월별 예측, 이상 감지, 여러 프로젝트의 롤업을 지원할 수 있습니다.
  • 가격표 내보내기는 정가와 SKU 비용 및 크레딧을 조정하는 데 도움이 됩니다.
  • 실패 모드: 콘솔 뷰만 사용하면 세분성이 제한됩니다. BigQuery로 내보내지 않으면 과거 데이터 모델링과 정확한 쇼백/차지백이 불가능합니다.

• 예산 및 알림:

  • 결제 계정, 프로젝트, 폴더, 서비스 또는 라벨/태그 필터로 범위를 지정하여 예산을 생성하고, 실제 및 예상 비용에 대한 임계값 알림(예: 50/90/100%)을 구성하세요. Pub/Sub를 통한 알림 채널을 사용하여 자동화된 작업(예: 비프로덕션 환경 일시 중지)을 트리거하는 것을 고려해 보세요.
  • 장단점: 공격적인 자동 종료는 지출을 줄이지만 프로덕션 경로에 적용될 경우 안정성을 해칠 수 있습니다.

• 할당을 위한 라벨 및 태그:

  • 리소스 라벨과 Resource Manager 태그(env, app, owner, cost-center)를 일관되게 적용하세요. 태그는 조직 정책을 지원하며 결제 필터에 표시되어 강력한 비용 할당을 가능하게 합니다.
  • 거버넌스: Organization Policy, 배포 템플릿, CI/CD 검사를 사용하여 라벨/태그 정책을 강제하세요.
  • 실패 모드: 일관성 없는 키나 누락된 라벨은 할당 모델을 망가뜨립니다. 도구가 일관되지 않으면 상속된 태그가 모든 리소스 유형에 적용되지 않을 수 있습니다.

• 비용 할당 모델:

  • 쇼백/차지백은 일반적으로 프로젝트 → 서비스/SKU → 라벨/태그 계층 구조를 사용합니다. 공유 플랫폼 비용(예: 부하 분산기, VPC 이그레스)은 요청 수, 전송된 GB, 또는 로그/측정항목을 통해 측정된 CPU 시간과 같은 동인에 따라 할당될 수 있습니다.
  • 장단점: 단순한 모델(균등 분할)은 실행하기 쉽지만 사용량이 많은 사용자에게 잘못된 비용을 책정할 수 있습니다. 세분화된 모델은 신뢰할 수 있는 원격 측정 데이터와 더 많은 오버헤드를 필요로 합니다.

간단한 예시 (비용 예측을 위한 BigQuery 드라이런):

undefined

컴퓨팅 효율성 및 수명 주기 최적화

• 적정 규모 산정 및 커스텀 머신 유형:

  • Recommender API/콘솔을 사용하여 CPU/메모리 사용량 백분위수를 기반으로 VM의 적정 규모를 산정하세요. 꾸준하고 사전 정의된 유형보다 작은 사양이 필요한 경우(예: 2 vCPU/10GB RAM) 커스텀 머신 유형을 사용하여 사용하지 않는 용량에 대한 비용 지불을 피하세요.
  • 실패 모드: 지연 시간에 민감하거나 트래픽이 급증하는 서비스의 규모를 축소하면 스로틀링이 발생할 수 있습니다. 부하 테스트와 버퍼 헤드룸으로 검증하세요.

• 약정 사용 할인 (CUDs):

  • 콘솔 또는 CLI를 통해 리전 범위에서 1년 또는 3년 약정으로 리소스 기반 CUD(vCPU, 메모리, GPU)를 구매하세요. 안정적인 기준 용량에 가장 적합하며, 트래픽 급증 시에는 자동 확장을 함께 사용하세요.
  • 장단점: 약정은 단가를 낮추지만 유연성이 떨어집니다. 과도하게 약정하면 지출이 고정되고, 부족하게 약정하면 할인 혜택을 놓치게 됩니다.

• Spot VMs:

  • 내결함성이 있고 중단 가능한 워크로드(배치, CI, 상태 비저장 계층)에 Spot VM을 사용하세요. 체크포인팅과 선점 처리(메타데이터/Pub/Sub를 통한 30초 전 알림)를 구현하세요.
  • 실패 모드: 용량은 언제든지 사라질 수 있습니다. 상태 저장 또는 쿼럼이 중요한 서비스는 절대로 Spot VM에만 배치해서는 안 됩니다.

• 자동 확장, 예약 및 수명 주기:

  • 자동 확장(CPU, 부하 분산기 또는 커스텀 Cloud Monitoring 측정항목 기준) 기능이 있는 관리형 인스턴스 그룹(MIG)으로 가변적인 부하를 처리하세요. 오실레이션을 방지하기 위해 축소 대기 기간 및 축소 제어를 조정하고, 상태 확인 초기 지연 시간을 앱 준비 시간과 맞추세요.
  • 예약: 업무 외 시간에는 개발/테스트 VM을 중지하거나 일시 중단하세요. Instance Schedules 또는 Cloud Scheduler와 Cloud Functions를 사용한 자동화를 통해 유휴 비용을 최소화하세요.
  • 수명 주기 및 유지보수: 고가용성을 위해 자동 재시작 및 호스트 유지보수 마이그레이션을 활성화하세요. 단, 실시간 마이그레이션은 GPU나 로컬 SSD가 있는 경우 적용되지 않을 수 있음을 인지해야 합니다.
  • 유휴 리소스 정리: Recommender를 사용하여 연결되지 않은 영구 디스크, 오래된 스냅샷, 사용하지 않는 고정 IP를 회수하세요.
  • 실패 모드: 짧은 상태 확인 지연 시간이나 준비 신호 누락은 과도한 프로비저닝을 유발합니다. 너무 공격적인 축소는 연결을 끊고, 자동 복구를 비활성화하면 장애가 발생한 노드를 숨기게 됩니다.

간단한 예시:

undefined

undefined

스토리지 및 데이터 처리 경제학

• Cloud Storage 클래스 및 수명 주기:

  • 액세스 패턴에 따라 클래스 선택: Standard(hot), Nearline(최소 30일), Coldline(최소 90일), Archive(최소 365일). 수명 주기 규칙을 적용하여 데이터를 계층화하고 예약된 일정에 따라 삭제합니다.
  • 검색 비용 상충 관계: 저비용 클래스는 GB당 검색 요금과 최소 스토리지 기간 요금이 부과됩니다. Coldline/Archive에서 빈번하게 읽으면 비용 절감 효과가 사라집니다. 최대 읽기 비용에 대비하여 복원 워크플로를 계획하세요.
  • 거버넌스: 규정 준수를 위해 보관 정책 및 객체 보존 잠금을 사용합니다. 공유 데이터 세트에 대해 ‘요청자 지불’을 활성화하여 팀 간 예기치 않은 요금 청구를 방지하세요.

• 수명 주기 정책 예시 (계층화 후 삭제):

  • Age 기반 SetStorageClass 및 Delete 작업을 정의하여 오래된 데이터의 전환 및 정리를 자동화합니다.

• BigQuery 비용 제어:

  • 주문형 쿼리는 처리된 바이트당 요금이 부과됩니다. 파티션 프루닝과 클러스터링으로 이를 최소화하세요. 수집 시간 또는 날짜 열을 기준으로 파티셔닝하고, 카디널리티/선택도가 높은 열을 최대 4개까지 클러스터링합니다.
  • 모의 실행(dry run)을 사용하여 비용을 예측하고, 자주 사용되는 집계에는 구체화된 뷰(materialized view)를, 시간 범위를 좁히기 위해서는 테이블 데코레이터를 사용하세요.
  • 예약(슬롯)은 예측 가능한 성능과 비용을 제공합니다. 프로젝트/폴더별로 할당을 사용하고, 단기적인 급증에 대비해 flex commitment를 고려하세요.
  • 장애 모드: 파티셔닝되지 않은 테이블 스캔, 폭이 넓은 테이블에서의 SELECT *, 잘못 정렬된 클러스터링은 막대한 스캔 바이트를 생성합니다. 임시 중간 테이블은 만료되지 않으면 스토리지 사용량이 급증할 수 있습니다.

간단한 예시 (Cloud Storage 수명 주기 JSON 스니펫):

• { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

네트워킹, 데이터베이스 및 할당량 인식 확장

• 네트워크 이그레스 및 아키텍처 영향:

  • 인터넷, 리전 간, 외부 IP를 통한 이그레스에는 요금이 부과됩니다. 동일 리전 내 내부 IP를 통한 트래픽은 일반적으로 무료입니다. 성능을 위해서는 Premium Network Tier를, 지연/지터 요구사항이 덜 엄격한 비용에 민감한 워크로드에는 Standard Tier를 선택하세요.
  • 부하 분산기: L7 HTTP(S) 및 L4 TCP/UDP에는 데이터 처리 및 전달 규칙 요금이 있습니다. 리전 간 LB는 리전 간 이그레스 비용을 추가할 수 있습니다. LB를 통합하면 고정 비용은 절약되지만 장애 영향 반경(blast radius)이 커질 수 있습니다.
  • 최적화: 트래픽을 리전 내에서 유지하고, 리전별 버킷과 서비스를 사용하며, 외부 IP를 통한 헤어피닝(hairpinning)을 피하세요. 정적 자산을 엣지에 캐시하여 오리진 이그레스를 줄입니다.
  • 장애 모드: 동일한 VPC 내 서비스 간에 실수로 외부 IP를 사용하면 불필요한 이그레스 비용이 발생합니다. 다중 리전 복제는 쓰기 경로에 대한 이그레스 비용을 두 배로 만듭니다.

• 데이터베이스 크기 조정, 복제본 및 가용성:

  • Cloud SQL: 95번째 백분위수 부하에 맞춰 vCPU/RAM 크기를 조정하고, 스토리지 자동 크기 조정을 활성화하며, 읽기 확장(scale-out)을 위해 읽기 복제본을 사용합니다. HA는 컴퓨팅 비용을 두 배로 만들지만 장애 조치 RTO를 줄입니다. 커넥션 풀링은 과도한 연결 오버헤드를 방지합니다.
  • Spanner: 용량은 노드 또는 처리 단위로 프로비저닝됩니다. 다중 리전 구성은 가용성과 읽기 지연 시간을 개선하지만 비용과 쓰기 지연 시간을 증가시킵니다. 분할 및 핫스팟을 신중하게 계획하세요.
  • Bigtable: 노드 수가 처리량을 결정하며, 자동 확장 처리기가 트래픽 추적을 돕습니다. 다중 클러스터 복제는 가용성과 비용을 추가합니다. 키가 고르게 분산되도록 스키마를 설계하세요.
  • 상충 관계: 복제본은 읽기 처리량과 가용성을 향상시키지만 쓰기 증폭 및 이그레스를 증가시킵니다. 강력한 일관성과 다중 리전 쓰기는 지연 시간을 추가합니다.

• 할당량, 속도 제한 및 백프레셔:

  • API별 할당량과 서비스별 동시성을 이해해야 합니다. 429/5xx 오류에 대해 지터(jitter)가 포함된 지수 백오프를 구현하세요. Pub/Sub 및 Dataflow 또는 Cloud Run 작업을 사용하여 큐 기반 부하 평준화를 적용합니다.
  • 동시성 설정: Cloud Run에서 동시성을 높이면 비용은 절감되지만 테일 레이턴시(tail latency) 위험이 있습니다. 안정적인 처리량을 위해 요청 시 CPU 할당을 조정하세요.
  • 백프레셔: Pub/Sub 구독자의 흐름 제어, 서킷 브레이커, 승인 제어를 사용하여 연쇄적인 장애를 방지하세요.
  • 장애 모드: 할당량을 무시하면 갑작스러운 스로틀링이 발생합니다. 자동 확장은 백프레셔 없이 다운스트림의 부하를 증폭시켜 재시도를 유발하고 비용을 가중시킬 수 있습니다.

성능 측정 및 최적화 거버넌스

• 측정 및 부하 테스트:

  • 지연 시간, 오류율, 포화도에 대한 SLI/SLO를 설정합니다. Cloud Monitoring 대시보드, 업타임 체크, 알림을 사용합니다. 추적(Cloud Trace) 및 프로파일링(Cloud Profiler)을 사용하여 핫 경로(hot path)와 잠금 경합(lock contention)을 찾습니다.
  • 실제와 유사한 트래픽 모델, 데이터 카디널리티, 思考 시간(think time)으로 부하 테스트를 수행합니다. 오토스케일러 파라미터, 워밍업(warm-up), 준비 게이트(readiness gate)를 검증합니다. 장애 조치 및 카오스 시나리오를 포함하여 용량 헤드룸과 복구 시간을 관찰합니다.
  • 병목 현상 진단: CPU, 메모리, 디스크, 네트워크 및 다운스트림 종속성에 걸쳐 USE(사용률, 포화도, 오류) 방법을 사용하고, 로그 및 추적과 연관 분석합니다.

• 비용, 보안, 안정성의 균형을 맞추는 거버넌스:

  • FinOps 가드레일: 필수 라벨/태그, 예측 알림 기능이 있는 예산, 중앙화된 결제 내보내기 및 비용 검토 주기. Recommender 권장 사항(유휴 IP/디스크, 권장 크기 조정)을 소유자 SLA와 함께 백로그에 포함시킵니다.
  • 보안: 비공개 연결(외부 IP 없음)을 선호하고, 데이터 유출 위험에 대비해 VPC Service Controls를 사용합니다. 비공개 경로는 송신 패턴과 비용을 변경할 수 있음을 인지해야 합니다. 저장 데이터와 전송 중인 데이터를 암호화하고, 비용 모델에 KMS 사용량을 고려합니다.
  • 안정성: CUD 또는 BigQuery 예약을 통해 기준 용량을 예약하고, SLO를 위한 버스트 헤드룸을 유지하며, 정기적인 게임 데이(game day)를 수행합니다. 중요 경로에 Spot 또는 공격적인 오토스케일링이 부적합한 경우를 문서화합니다.
  • 변경 관리: 비용에 영향을 미치는 파라미터(오토스케일러 상한, BigQuery 예약, LB 토폴로지)를 검토 및 롤백 계획이 있는 코드로 취급합니다.

실용적인 문제 시나리오

Contoso Media는 다중 리전 비디오 분석 플랫폼을 운영하고 있으며, 비용 상승과 트래픽 급증 시 간헐적인 지연 시간 SLO 위반을 경험하고 있습니다. 경영진은 API의 p95 지연 시간 SLO 300ms와 야간 배치 완료 2시간 SLA를 저해하지 않으면서 20%의 비용 절감을 원합니다.

1. 비용 및 성능 기준선 설정

• 조치: Cloud Billing 내보내기를 BigQuery로 활성화하고, SKU 비용과 Cloud Monitoring SLI(지연 시간, CPU, 송신 바이트)를 상호 연관시키는 대시보드를 생성합니다. 상위 20개 쿼리에 대해 bq dry run을 실행하여 스캔되는 바이트를 추정합니다.
• 근거: 기준선은 영향이 큰 서비스를 식별하고 지출을 성능 동인에 매핑하여 목표 지향적인 최적화를 가능하게 합니다.

2. 할당 태그 및 예산 강제

• 조치: 배포 템플릿을 통해 라벨/태그(env, service, owner, cost-center)를 필수로 지정하고, 환경별 예산을 설정하여 FinOps Pub/Sub 주제로 예측 알림을 보냅니다.
• 근거: 완벽한 할당 데이터와 사전 예방적 알림을 통해 초과 지출이 발생하기 전에 신속하게 소유권을 파악하고 시정 조치를 취할 수 있습니다.

3. 기준 컴퓨팅 리소스의 크기 최적화 및 약정

• 조치: 안정적인 서비스에 Recommender VM 권장 크기 조정을 적용하고, 안정 상태 용량을 1년 리전 CUD로 전환하며, 트래픽 급증에 대비하여 오토스케일러 최대치에 20–30%의 버퍼를 유지합니다.
• 근거: 권장 크기 조정 및 약정은 예측 가능한 부하에 대한 단가를 낮추면서 SLO를 위한 여유 공간(headroom)을 보존합니다.

4. 오토스케일링 및 준비 상태 최적화

• 조치: MIG의 경우, 오토스케일링 신호를 요청 기반 또는 맞춤형 QPS/지연 시간 측정항목으로 전환하고, 쿨다운(cool-down) 기간을 120–180초로 설정하며, 상태 확인 초기 지연 시간을 앱 워밍업 시간과 맞춥니다. 급격한 축소를 방지하기 위해 스케일 인 제어(scale-in control)를 활성화합니다.
• 근거: 워크로드 인식 신호와 안정화 조치는 비용을 부풀리고 지연 시간에 악영향을 미치는 스래싱(thrash)과 과도한 프로비저닝을 방지합니다.

5. 네트워크 송신 및 로드 밸런서 오버헤드 감소

• 조치: 서비스 간 외부 IP 통신을 제거하고, 모든 동서(east-west) 트래픽이 내부 로드 밸런싱을 사용하도록 보장하며, 통신량이 많은(chatty) 서비스들을 리전 내에 함께 배치하고, 정적 자산을 엣지에 캐시합니다.
• 근거: 내부 경로는 불필요한 송신을 제거하고 L7 처리를 줄여 지연 시간과 비용을 개선합니다.

6. 스토리지 수명 주기 및 아카이빙

• 조치: Cloud Storage 수명 주기 규칙을 적용하여 90일이 지난 콜드 아티팩트를 Coldline으로 이동시키고 365일 후에 삭제합니다. 공유 버킷에 요청자 지불(requester-pays)을 설정하고, 드물게 액세스하는 데이터에 대한 최소 스토리지 기간의 영향을 검토합니다.
• 근거: 계층화 및 보존 정책은 규정 준수를 유지하면서 스토리지 및 검색 비용을 절감합니다.

7. BigQuery 쿼리 및 용량 튜닝

• 조치: 대규모 팩트 테이블을 날짜별로 파티셔닝하고, 선택도가 높은 열을 기준으로 클러스터링합니다. SELECT *를 열 프로젝션으로 대체하고, 주요 집계를 위해 구체화된 뷰(materialized view)를 도입합니다. 피크 ETL 시간대를 위해 소규모 예약을 구매하고 배치 급증 시에는 flex slot을 사용합니다.
• 근거: 파티셔닝/클러스터링은 스캔되는 바이트를 줄이고, 용량 예약은 중요 워크로드의 성능과 비용을 안정화시킵니다.

8. 데이터베이스 확장 및 복제본

• 조치: 읽기 중심(read-heavy)의 Cloud SQL 서비스에는 읽기 복제본을 추가하고, 커넥션 풀링을 조정하며, 스토리지 자동 크기 조정을 설정하고, 장애 조치(failover)를 테스트하여 RTO/RPO를 검증합니다. Bigtable의 경우, 오토스케일러를 활성화하고 핫스팟 키(hotspot key) 문제를 해결합니다.
• 근거: 복제본은 읽기 부하를 분산하고 쓰기 경로를 보호하며, 오토스케일링은 수동으로 과도하게 프로비저닝하지 않고도 처리량을 수요에 맞게 유지합니다.

9. 할당량, 동시성 및 역압(Backpressure)

• 조치: 지터(jitter)를 사용한 지수 백오프(exponential backoff)를 구현하고, Pub/Sub 구독자 흐름 제어(flow control)를 구성하며, 처리량과 지연 시간의 균형을 맞추기 위해 Cloud Run 동시성을 설정하고, 다운스트림 경계에 서킷 브레이커(circuit breaker)를 추가합니다.
• 근거: 적절한 역압은 SLO를 저하시키고 비용을 부풀리는 연쇄 장애 및 제어 불가능한 재시도를 방지합니다.

10. 지속적인 검증 및 거버넌스

• 조치: 매월 부하 테스트와 카오스 드릴(chaos drill)을 실행하고, SLO/오류 예산을 추적하며, Recommender 권장 사항과 비용 이상 현상을 소유자 및 기한과 함께 스프린트 계획에 통합합니다.
• 근거: 반복적인 검증을 통해 워크로드가 발전함에 따라 비용 절감 효과가 지속되고 SLO가 정상 상태(green)를 유지하도록 보장합니다.

← 안정성 · 모든 도메인

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

Google 찾아보기 →