핵심 요약
- GCP 비용 최적화는 할인 프로그램(CUD/SUD), 워크로드 선택(Spot/Preemptible), 운영 패턴(라이프사이클/Autoscaling) 세 축으로 접근한다.
- Committed Use Discounts(CUD)는 1년/3년 약정으로 최대 70% 할인. Spend-based vs Resource-based 두 종류이며 워크로드 안정성에 따라 선택한다.
- Sustained Use Discounts(SUD)는 자동 적용되어 별도 설정 불필요. Compute Engine에서만 적용되며 월간 사용 시간에 따라 단계적 할인.
- Spot VM은 최대 91% 저렴하지만 24시간 후 또는 capacity 회수 시 종료. 배치/내결함성 워크로드에 한정.
- Cloud Run min-instances 설정과 Cloud Storage Storage Class 전환은 비용에 가장 직접적인 영향을 주는 두 가지 운영 결정이다.
- 본 글은 비용 분석 도구(Billing Export, FinOps 대시보드), Recommender, 실전 최적화 패턴을 다룬다.
사전 지식: 시리즈 #1~#4, BigQuery 기본, GCE/Cloud Run 기본 운영 경험
작성 시점: 2026년 5월 기준 (Spot VM GA, CUD 자동 갱신 옵션 추가됨)
1. GCP 비용 구조 분해
1.1 비용 카테고리
GCP 청구서를 분해하면 크게 5가지로 나뉜다:
| Compute (GCE, GKE, Cloud Run) | 40~60% | 매우 높음 |
| Storage (GCS, Persistent Disk) | 10~25% | 높음 |
| Network egress | 5~20% | 중간 |
| Databases (Cloud SQL, Spanner, BigQuery) | 10~30% | 높음 |
| Operations (Logging, Monitoring) | 1~5% | 낮음 |
비중은 워크로드 성격에 따라 크게 다르다. 데이터 분석 중심이면 BigQuery가 50% 이상을 차지하기도 한다.
1.2 비용 가시성 확보
최적화 전에 현재 비용이 어디서 발생하는지 정확히 파악해야 한다. 다음 3단계로 가시성을 확보한다:
1단계: Billing Export to BigQuery
청구 데이터를 BigQuery로 export하면 SQL로 자유롭게 분석할 수 있다. 콘솔에서 활성화:
활성화 후 약 24시간이 지나면 데이터가 적재되기 시작한다. 테이블 이름은 gcp_billing_export_v1_BILLING_ACCOUNT_ID 형식이다.
2단계: 라벨 표준화
모든 리소스에 일관된 라벨을 부여한다. 권장 라벨 키:
- env: prod / staging / dev
- team: platform / data / frontend / ...
- service: api / worker / scheduler / ...
- cost-center: 부서 또는 프로젝트 코드
Terraform으로 default labels을 강제:
name = "my-instance"
labels = {
env = "prod"
team = "platform"
service = "api"
cost_center = "eng-001"
}
}
3단계: FinOps 대시보드
Looker Studio로 비용 대시보드 구축. 핵심 차트:
- 서비스별 일일 비용 (라인 차트)
- 라벨 기준 비용 분해 (스택 바)
- 전월 대비 증감률 (TOP 10 서비스)
- CUD/SUD 적용 후 절감 효과
- 예산 대비 실제 사용량
1.3 비용 분석 SQL 예시
서비스별 최근 30일 비용 TOP 10:
service.description AS service,
SUM(cost) AS total_cost,
SUM(IFNULL((
SELECT SUM(c.amount)
FROM UNNEST(credits) AS c
), 0)) AS total_credits,
SUM(cost) + SUM(IFNULL((
SELECT SUM(c.amount)
FROM UNNEST(credits) AS c
), 0)) AS net_cost
FROM `my-project.billing_export.gcp_billing_export_v1_XXXXX`
WHERE DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY service
ORDER BY net_cost DESC
LIMIT 10
라벨 기준 비용 분해:
(SELECT value FROM UNNEST(labels) WHERE key = 'team') AS team,
(SELECT value FROM UNNEST(labels) WHERE key = 'service') AS service,
SUM(cost) AS total_cost
FROM `my-project.billing_export.gcp_billing_export_v1_XXXXX`
WHERE DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY team, service
ORDER BY total_cost DESC
2. 자동 할인 - SUD와 CUD
2.1 Sustained Use Discounts (SUD)
Compute Engine 인스턴스를 월간 25% 이상 사용하면 자동 할인이 적용된다. 별도 신청 불필요, 결제 시 자동 차감.
월간 사용률별 할인:
| 0~25% | 0% | 100% |
| 25~50% | 20% | 80% |
| 50~75% | 40% | 60% |
| 75~100% | 30% | 70% |
표가 직관과 다르게 보일 수 있는데, 이는 구간별 누적 할인 방식이기 때문이다. 24/7 운영 시 평균 약 30% 할인이 적용된다.
SUD 적용 조건:
- Compute Engine N1, N2, E2 인스턴스
- 동일 머신 타입 + 동일 리전 (호스트 변경되어도 합산)
- Cloud Run, GKE Autopilot, Cloud SQL 등은 다른 할인 체계 사용
2.2 Committed Use Discounts (CUD)
1년 또는 3년 약정으로 최대 70% 할인. 24/7 운영하는 워크로드라면 거의 무조건 이득이다.
두 종류의 CUD:
Spend-based CUD:
- 일정 금액(예: $100/시간)을 약속
- Cloud Run, Compute Engine, GKE Autopilot 등 광범위하게 적용
- 워크로드 변경에 유연 (인스턴스 타입 변경 가능)
- 할인율은 약간 낮음 (1년 약 20%, 3년 약 35~50%)
Resource-based CUD:
- 특정 머신 타입 + 리전 + vCPU/메모리 양 약속
- Compute Engine, Cloud SQL 등
- 워크로드 변경에 비유연 (해당 인스턴스 타입 고정)
- 할인율 높음 (1년 약 37%, 3년 약 55~70%)
2.3 CUD 결정 기준
다음 결정 트리로 선택한다:
├─ Yes
│ └─ 향후 1년 이상 동일 형태로 유지될 가능성?
│ ├─ 높음 (>80%) → 3년 Resource-based CUD
│ ├─ 중간 (50~80%) → 1년 Resource-based CUD
│ └─ 낮음 → 1년 Spend-based CUD
├─ No (피크/비피크 패턴)
│ └─ 베이스라인 부분은 1년 Spend-based CUD
│ 나머지는 Spot 또는 정가
└─ 예측 불가
└─ CUD 보류, Spot/Preemptible 활용
2.4 CUD 구매 명령
3년 Compute Engine CUD 구매 예시:
--plan=THIRTY_SIX_MONTH \
--region=asia-northeast3 \
--resources=vcpu=10,memory=40 \
--type=GENERAL_PURPOSE
이 약정은 asia-northeast3에서 N1/N2/E2 General Purpose vCPU 10개와 메모리 40GB를 3년간 사용한다는 commitment다. 약정 범위 내에서는 70% 할인, 초과 사용분은 정가다.
2.5 CUD 활용률 모니터링
구매한 CUD가 실제로 잘 활용되고 있는지 확인:
commitment_id,
SUM(IF(credit_type = 'COMMITTED_USAGE_DISCOUNT', credit_amount, 0)) AS used_amount,
SUM(IF(credit_type = 'COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE', credit_amount, 0)) AS available_amount,
SAFE_DIVIDE(
SUM(IF(credit_type = 'COMMITTED_USAGE_DISCOUNT', credit_amount, 0)),
SUM(IF(credit_type = 'COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE', credit_amount, 0))
) AS utilization_rate
FROM `my-project.billing_export.gcp_billing_export_v1_XXXXX`,
UNNEST(credits) AS credit
WHERE DATE(_PARTITIONTIME) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY commitment_id
활용률이 80% 이하면 약정 규모가 워크로드 대비 큰 것이다. 갱신 시 축소를 검토한다.
3. Spot VM과 Preemptible
3.1 Spot VM 개요
Spot VM은 GCP의 여유 capacity를 최대 91% 할인으로 제공한다. 단, 다음 제약이 있다:
- 시작 24시간 이내 또는 그 이후 언제든 종료 가능 (GCP의 capacity 회수 시)
- 최대 24시간 동안만 실행 (예전 Preemptible과 달리 Spot은 이 제약 완화됨)
- 30초 전 SIGTERM 시그널 후 강제 종료
- Live migration 미지원
3.2 적합한 워크로드
Spot VM이 적합한 케이스:
- 배치 처리: Hadoop/Spark 작업, ML 학습, 이미지/영상 인코딩
- CI/CD 빌드 서버: 작업 실패 시 재시도 가능한 환경
- 개발/테스트 환경: 운영 중요도 낮음
- stateless 큐 워커: SQS/Pub/Sub 메시지 처리
부적합한 케이스:
- 운영 웹 서버: 사용자 영향
- stateful 데이터베이스: 데이터 손실 위험
- 장시간 단일 작업: 중간 종료 시 처음부터 재시작 필요
3.3 Spot VM 생성
--zone=asia-northeast3-a \
--machine-type=e2-standard-4 \
--provisioning-model=SPOT \
--instance-termination-action=DELETE \
--image-family=debian-12 \
--image-project=debian-cloud
--instance-termination-action=DELETE는 종료 시 인스턴스를 완전 삭제한다. 영구 디스크는 별도 보관됨.
3.4 Graceful Shutdown 처리
Spot VM 종료 30초 전 SIGTERM이 발송된다. 워커 프로세스가 이를 감지해서 작업을 멈추고 큐에 반환하는 패턴이 필수다.
Python 예시:
import sys
from queue_client import release_task
def handle_shutdown(signum, frame):
print("SIGTERM received, releasing current task...")
release_task(current_task_id)
sys.exit(0)
signal.signal(signal.SIGTERM, handle_shutdown)
이 패턴 없이 Spot VM을 운영하면 작업 손실로 인한 데이터 정합성 문제가 발생한다.
3.5 Managed Instance Group + Spot 혼합
운영 환경에서 Spot의 비용 이점을 살리면서 안정성을 확보하는 패턴: MIG에 Spot과 정가 인스턴스 혼합 배치.
Terraform 예시:
name = "batch-workers"
region = "asia-northeast3"
base_instance_name = "worker"
version {
name = "regular"
instance_template = google_compute_instance_template.regular.self_link
target_size {
fixed = 2
}
}
version {
name = "spot"
instance_template = google_compute_instance_template.spot.self_link
}
target_size = 10
}
이 구성은 항상 2개의 정가 인스턴스(stable baseline) + 나머지 8개는 Spot으로 운영한다. Spot이 종료되어도 정가 인스턴스가 baseline을 유지한다.
4. Cloud Run 비용 최적화
4.1 비용 구조 재확인
#4편에서 다룬 Cloud Run 비용 구조 핵심:
- CPU + Memory: 요청 처리 시간에만 과금 (기본)
- min-instances: idle 시간도 과금
- 외부 egress: 별도 계산
- 무료 한도: 월 200만 요청, 360,000 GB-초 메모리, 180,000 vCPU-초
4.2 min-instances 비용 vs 콜드 스타트 트레이드오프
min-instances=1 (asia-northeast3, 1 vCPU, 512Mi, 2026년 5월 기준):
- CPU always-allocated: 약 $46.66/월
- Memory always-allocated: 약 $2.59/월
- 합계: 약 $49/월
이 비용을 절약하려면 대안을 검토한다:
대안 1: 콜드 스타트 최적화로 min-instances=0 유지
- 이미지 슬림화 + cpu-boost + 1st gen 활용
- p95 콜드 스타트 1초 이내 달성 가능
- 절감액: $49/월
대안 2: 조건부 min-instances
- Cloud Scheduler로 업무 시간(평일 9~18시)만 min-instances=1
- 비업무 시간은 0으로 자동 전환
- 절감액: 약 $35/월 (70% 절감)
조건부 min-instances 스케줄링 예시:
--location=asia-northeast3 \
--schedule="0 9 * * 1-5" \
--time-zone="Asia/Seoul" \
--uri="https://run.googleapis.com/v1/projects/PROJECT/locations/asia-northeast3/services/my-api" \
--http-method=PATCH \
--oauth-service-account-email=scheduler-sa@PROJECT.iahttp://m.gserviceaccount.com \
--message-body='{"spec":{"template":{"metadata":{"annotations":{"autoscaling.knative.dev/minScale":"1"}}}}}'
대응되는 scale-down job은 18시에 실행.
4.3 max-instances 한도로 비용 방어
트래픽 폭증 또는 봇 공격 시 비용 폭탄을 막기 위해 max-instances를 반드시 설정한다:
--region=asia-northeast3 \
--max-instances=20
20개 인스턴스 × 80 concurrency = 1600 동시 요청 처리. 일반 SaaS에는 충분하다. 초과 트래픽은 429 응답으로 reject되며, 이는 비용 폭탄보다 훨씬 안전한 실패 모드다.
4.4 Cloud Run vs GKE Autopilot vs GCE 선택
워크로드 형태별 최적 선택:
| 짧은 HTTP 요청 (~10초) | Cloud Run | 요청당 과금, 콜드 스타트 OK |
| 긴 HTTP/WebSocket | GKE Autopilot | 24시간 idle 더 저렴 |
| 배치 작업 | Cloud Run Jobs 또는 GCE Spot | 작업 단위 격리 |
| stateful 서비스 | GCE + MIG | 디스크 attachment |
| 고정 부하 + 24/7 | GCE + CUD | 가장 저렴 |
5. Storage 비용 최적화
5.1 GCS Storage Class 자동 전환
#3편의 라이프사이클 정책으로 저장 비용을 50~70% 절감할 수 있다. 일반 SaaS 업로드 워크로드 기준 권장 라이프사이클:
"lifecycle": {
"rule": [
{
"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
"condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
},
{
"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
"condition": {"age": 90, "matchesStorageClass": ["NEARLINE"]}
},
{
"action": {"type": "SetStorageClass", "storageClass": "ARCHIVE"},
"condition": {"age": 365, "matchesStorageClass": ["COLDLINE"]}
},
{
"action": {"type": "Delete"},
"condition": {"age": 2555}
}
]
}
}
1TB 데이터 기준 월간 저장 비용 시뮬레이션 (asia-northeast3):
| All Standard | $0.023 | $23.55 |
| 라이프사이클 적용 (30일 Nearline) | 평균 $0.017 | $17.41 |
| 라이프사이클 적용 (90일 Coldline) | 평균 $0.010 | $10.24 |
| 라이프사이클 적용 (365일 Archive) | 평균 $0.005 | $5.12 |
장기 보관 데이터가 많을수록 효과가 크다.
5.2 Persistent Disk 최적화
GCE/GKE Persistent Disk는 의외로 큰 비용 항목이다. 주요 최적화 포인트:
1) 디스크 타입 선택
| pd-standard (HDD) | $0.04 | ~3,000 | 로그, 배치 데이터 |
| pd-balanced | $0.10 | ~15,000 | 일반 서버 |
| pd-ssd | $0.17 | ~30,000 | DB, 고성능 |
| pd-extreme | $0.125 + IOPS | 사용자 지정 | 고급 DB |
대부분의 GCE VM은 pd-balanced로 충분하다. pd-ssd로 기본 설정된 경우 검토 필요.
2) Snapshot 라이프사이클
Snapshot은 누적되면 큰 비용이 된다. 자동 정리 정책:
--region=asia-northeast3 \
--max-retention-days=14 \
--on-source-disk-delete=apply-retention-policy \
--daily-schedule \
--start-time=02:00 \
--storage-location=asia-northeast3
이 정책은 매일 새벽 2시 스냅샷 + 14일 자동 삭제.
3) 사용되지 않는 디스크 정리
VM 삭제 후 분리된 영구 디스크가 누적된다. 미연결 디스크 조회:
월 1회 정기 점검하여 삭제한다.
5.3 외부 Egress 최적화
데이터 외부 전송 비용은 의외로 큰 부분을 차지한다. 주요 단가 (2026년 5월 기준):
- 같은 리전 내: 무료
- 같은 멀티리전 내 (예: us 안의 두 리전): $0.01/GB
- 리전 간 (대륙 내): $0.02/GB
- 대륙 간: $0.05~0.12/GB
- 외부 인터넷 egress: $0.08~0.23/GB (대상에 따라)
최적화 패턴:
- CDN 활용: 정적 콘텐츠는 Cloud CDN으로 캐시. CDN egress는 일반 egress보다 저렴
- 리전 일치: 클라이언트와 서비스 리전을 일치시켜 cross-region egress 회피
- Private Google Access: VPC 내에서 Google 서비스 호출 시 외부 egress 회피
- Storage Transfer Service: 대용량 데이터 이동 시 일반 다운로드보다 저렴
6. BigQuery 비용 최적화
6.1 Pricing 모델 선택
BigQuery는 두 가지 pricing 모델이 있다:
On-demand:
- 쿼리당 스캔된 데이터에 대해 $5/TB 과금
- 별도 약정 없음
- 예측 불가능한 워크로드에 적합
Editions (Standard/Enterprise/Enterprise Plus):
- 슬롯 단위 예약, 시간당 과금
- 약정 시 최대 40% 할인
- 대량 분석 워크로드에 적합
판단 기준:
- 월간 BigQuery 비용 < $2,000 → On-demand
- $2,000~$10,000 → Standard Edition + Autoscaler
- $10,000+ → Enterprise Edition + Commitment
6.2 쿼리 비용 절감 패턴
1) Partitioned + Clustered 테이블
날짜 partitioning + 자주 필터링되는 컬럼 clustering:
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_type
AS SELECT * FROM source_table;
WHERE 조건에 partition column이 포함되면 스캔량이 극적으로 감소한다. clustering도 효과적이지만 partition만큼은 아니다.
2) SELECT * 회피
BigQuery는 column-oriented 저장이므로 SELECT *은 모든 column을 스캔한다. 필요한 column만 명시:
SELECT * FROM my_dataset.events WHERE date = '2026-05-01';
-- 좋음: 필요 column만
SELECT user_id, event_type, timestamp FROM my_dataset.events WHERE date = '2026-05-01';
3) Dry Run으로 사전 비용 측정
쿼리 실행 전 스캔 예상량 확인:
Query successfully validated. Assuming the tables are not modified, running this query will process X bytes of data. 메시지로 예상 스캔량 확인.
4) Query Plan 분석
비싼 쿼리는 INFORMATION_SCHEMA로 분석:
query,
total_bytes_billed,
total_bytes_billed / POWER(1024, 4) * 5 AS cost_usd,
user_email
FROM `my-project.region-asia-northeast3.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
AND statement_type = 'SELECT'
ORDER BY total_bytes_billed DESC
LIMIT 20
6.3 Storage 비용 최적화
BigQuery storage는 다음 두 단계로 자동 전환된다:
- Active storage: $0.02/GB/월 (90일 이내 수정된 테이블)
- Long-term storage: $0.01/GB/월 (90일 이상 수정 없는 테이블)
자동 적용이므로 별도 설정 불필요. 단, 자주 수정되는 테이블은 Active로 유지되어 비용 증가할 수 있다. partition별 분리하면 일부 partition만 Active로 유지된다.
7. Recommender - 자동 최적화 추천
7.1 Recommender 개요
GCP는 머신러닝 기반으로 비용 최적화 추천을 자동 생성한다. 콘솔 → Recommender 또는 API로 조회.
주요 Recommender:
- VM rightsizing: 과잉 프로비저닝된 VM 식별
- VM machine type: 더 적합한 머신 패밀리 추천
- CUD recommender: 약정 권장 분량 계산
- Idle VM: 90일 이상 idle 상태 VM
- Unattached PD: 미연결 디스크
- IAM: 사용되지 않는 권한
7.2 추천 조회 명령
--project=my-project \
--location=asia-northeast3 \
--recommender=google.compute.instance.MachineTypeRecommender \
--format="table(content.overview.observedMachineType.value,content.overview.recommendedMachineType.value,primaryImpact.costProjection.cost.units)"
7.3 추천 자동 적용 파이프라인
대규모 환경에서는 추천을 자동 적용하는 파이프라인을 구축한다. 일반적인 패턴:
- Cloud Scheduler가 매주 1회 Cloud Function 트리거
- Function이 Recommender API로 활성 추천 조회
- 추천을 BigQuery에 적재
- Looker Studio 대시보드로 시각화
- Slack/Email로 담당자에게 알림
- 승인 후 gcloud 또는 Terraform으로 적용
자동 적용은 위험하므로 승인 게이트를 반드시 둔다.
8. 실전 비용 최적화 시나리오
8.1 시나리오 1 - 스타트업 SaaS 백엔드
현황:
- Cloud Run + Cloud SQL + GCS 구성
- 트래픽 일 평균 10만 요청
- 월 비용 약 $800
최적화:
| Cloud Run min-instances | 2 (24/7) | 1 (업무시간만) | -$70 |
| Cloud SQL | db-n1-standard-2 | db-custom-1-3840 + 1년 CUD | -$120 |
| GCS lifecycle | 없음 | 30일 → Nearline | -$45 |
| Cloud Logging | 모두 보관 | 30일 후 Cold Storage | -$25 |
| 합계 | $800 | $540 | -32.5% |
큰 구조 변경 없이 설정만으로 약 1/3 절감 가능한 케이스다.
8.2 시나리오 2 - 데이터 분석 워크로드
현황:
- BigQuery 중심 (월 50TB 쿼리)
- Cloud Composer로 매일 ETL
- 월 비용 약 $3,500
최적화:
| BigQuery pricing | On-demand | Standard Edition + Autoscaler | -$800 |
| 쿼리 최적화 | SELECT * 다수 | column selection + partition pruning | -$400 |
| Composer | 24/7 운영 | 야간 시간만 운영 | -$300 |
| GCS dataset | All Standard | 90일 후 Coldline | -$150 |
| 합계 | $3,500 | $1,850 | -47% |
데이터 분석 워크로드는 쿼리 최적화 효과가 매우 크다.
8.3 시나리오 3 - 배치 처리 시스템
현황:
- GCE n2-standard-8 인스턴스 10개로 야간 배치
- 작업 시간 매일 6시간
- 월 비용 약 $1,200
최적화:
| 인스턴스 | 정가 GCE | Spot VM 80% + 정가 20% | -$600 |
| 머신 타입 | n2-standard-8 | c3-standard-8 (Recommender 추천) | -$80 |
| 디스크 | pd-ssd 500GB | pd-balanced 500GB | -$70 |
| 합계 | $1,200 | $450 | -62.5% |
배치 워크로드는 Spot 활용으로 가장 큰 절감을 달성할 수 있다.
9. 비용 모니터링 자동화
9.1 예산 알림 + 자동 차단
#1편에서 Budget Alert를 다뤘다. 단순 알림을 넘어 자동 차단까지 구현한다.
아키텍처:
Cloud Function 예시:
import json
from google.cloud import compute_v1
def stop_expensive_resources(event, context):
pubsub_message = base64.b64decode(event['data']).decode('utf-8')
budget_notification = json.loads(pubsub_message)
cost_amount = budget_notification['costAmount']
budget_amount = budget_notification['budgetAmount']
threshold = cost_amount / budget_amount
if threshold >= 1.2:
client = compute_v1.InstancesClient()
instances = client.list(project='my-project', zone='asia-northeast3-a')
for instance in instances:
if 'env' in instance.labels and instance.labels['env'] == 'dev':
client.stop(project='my-project', zone='asia-northeast3-a', instance=instance.name)
print(f"Stopped dev instance: {instance.name}")
이 패턴은 dev 환경 인스턴스만 정지하므로 운영 영향 없이 비용을 차단한다.
9.2 일일 비용 리포트
매일 슬랙으로 전일 비용 발송:
from google.cloud import bigquery
def daily_cost_report(request):
client = bigquery.Client()
query = """
SELECT
service.description AS service,
SUM(cost) AS total_cost
FROM `my-project.billing_export.gcp_billing_export_v1_XXXXX`
WHERE DATE(_PARTITIONTIME) = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY)
GROUP BY service
ORDER BY total_cost DESC
LIMIT 10
"""
results = list(client.query(query).result())
message = "*Daily GCP Cost Report*\n"
for row in results:
message += f"• {row.service}: ${row.total_cost:.2f}\n"
requests.post(SLACK_WEBHOOK_URL, json={"text": message})
Cloud Scheduler로 매일 오전 9시 실행.
10. 시리즈 마무리
전체 시리즈 핵심 정리
- #1 계정 구조: Project가 모든 격리의 기본 단위. Billing Account는 분리되어 다대다 연결 가능.
- #2 IAM: 최소 권한 원칙, Predefined Role 활용, Service Account Key 회피.
- #3 Cloud Storage: 라이프사이클 + Versioning + Signed URL로 안전하고 경제적인 운영.
- #4 Cloud Run: 콜드 스타트 최적화 후 min-instances는 마지막 수단. 트래픽 분할로 점진적 배포.
- #5 비용 최적화: 가시성 확보 → 자동 할인 활용 → 운영 패턴 최적화 → 자동화 순으로 접근.
비용 최적화 우선순위 정리
운영 환경 GCP를 처음 비용 분석할 때 다음 순서로 점검:
- Billing Export to BigQuery 활성화
- 모든 리소스에 표준 라벨 부여
- FinOps 대시보드 (Looker Studio) 구축
- Recommender 추천 사항 검토 (특히 VM rightsizing, idle VM, unattached PD)
- 24/7 워크로드에 CUD 적용
- Cloud Run min-instances 검토 (조건부 스케줄링 가능성)
- GCS 라이프사이클 정책 적용
- BigQuery 쿼리 패턴 분석 및 partition/cluster 적용
- 배치 워크로드에 Spot VM 도입
- Budget Alert + 자동 차단 구현
다음 학습 방향
이 시리즈를 완주하셨다면 다음 영역으로 확장을 권장한다:
- GKE 깊이 있게: Cloud Run보다 복잡하지만 더 큰 유연성. Autopilot vs Standard 선택 기준.
- Networking: VPC, Cloud Load Balancer, Cloud Armor, VPC Service Controls
- Observability: Cloud Logging, Monitoring, Trace, Profiler 통합 활용
- Multi-region 아키텍처: Spanner, Global Load Balancer, Disaster Recovery
- Data Platform: Dataflow, Pub/Sub, BigQuery 깊이 있게
각 주제는 별도 시리즈로 다룰 예정이다.
참고 자료
- GCP Pricing Calculator
- Billing Export to BigQuery
- Sustained Use Discounts 공식 문서
- Committed Use Discounts
- Spot VMs 공식 가이드
- Cloud Run Pricing 상세
- Active Assist Recommender
- FinOps Foundation
카테고리: Cloud / GCP
태그: gcp google-cloud cost-optimization finops cud spot-vm bigquery cloud-run cloud-architecture devops
'개발 프로젝트 > GCP 실습 일지' 카테고리의 다른 글
| GCP 시작 가이드 #4 — Cloud Run 배포 실전 (0) | 2026.06.03 |
|---|---|
| GCP 시작 가이드 #3 — Cloud Storage 깊이 있게 (0) | 2026.05.30 |
| GCP 시작 가이드 #2 — IAM과 Service Account 깊이 있게 (0) | 2026.05.27 |
| GCP 시작 가이드 #1 — 계정 구조, 빌링, Free Tier의 함정 (0) | 2026.05.22 |