IaC & Cost ManagementIaC & Cost Management

Part of the Cloud knowledge base — GCP deep dive. Complements DevOps Roadmap.

Tổng quan

Trang này bàn về hai lĩnh vực đi cùng nhau trong thực tế: Infrastructure as Code (IaC) — khai báo resource GCP trong config được quản lý phiên bản — và cost management (quản lý chi phí) — đo lường, kiểm soát, và tối ưu chi tiêu. IaC làm cho hạ tầng tái tạo được và có thể review; các công cụ chi phí (label, budget, discount, Recommender) biến chi tiêu thành thứ bạn có thể quy trách nhiệm và giảm bớt.

Các lựa chọn IaC trên GCP:

Công cụ	Nó là gì	State	Trạng thái
Terraform (provider google)	HCL, đa cloud, cộng đồng khổng lồ	GCS/backend khác	Tiêu chuẩn thực tế
Infrastructure Manager	Trình chạy Terraform do Google quản lý	Managed (GCS)	Lựa chọn managed được khuyến nghị
Config Connector	Quản lý resource GCP như các CRD Kubernetes	etcd (reconciled)	GitOps / K8s-native
Deployment Manager	IaC YAML/Jinja/Python nguyên bản của Google	Managed	Legacy — đã deprecated
gcloud / Cloud Build	CLI mệnh lệnh + trình chạy CI	Không có	Keo dán, CI, bootstrapping

Kiến thức nền tảng

Terraform trên GCP

Terraform là tiêu chuẩn thực tế cho IaC trên GCP. Provider hashicorp/google (và google-beta) bao phủ hầu như tất cả các service. Vòng lặp cốt lõi: init → plan → apply, với một state file làm nguồn sự thật ánh xạ config tới các resource thật.

terraform {
  required_version = ">= 1.6"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = "my-project"
  region  = "us-central1"
}

resource "google_storage_bucket" "assets" {
  name                        = "my-project-assets"
  location                    = "US"
  uniform_bucket_level_access = true
  labels = {
    team        = "platform"
    environment = "prod"
    cost-center = "cc-1234"
  }
}

Remote state trong một GCS bucket là thiết yếu cho các team — nó tập trung hóa state và cung cấp locking (GCS backend dùng object generation để đảm bảo tính nhất quán, tránh hỏng do apply đồng thời):

# backend.tf — remote state in a GCS bucket
terraform {
  backend "gcs" {
    bucket = "my-project-tfstate"   # create & version this bucket beforehand
    prefix = "env/prod"             # state object path within the bucket
  }
}

Tạo bucket state ngoài luồng (nó không thể quản lý state của chính nó) và bật versioning để bạn có thể khôi phục một state bị hỏng/ghi đè:

gcloud storage buckets create gs://my-project-tfstate \
  --location=us --uniform-bucket-level-access
gcloud storage buckets update gs://my-project-tfstate --versioning

Infrastructure Manager

Infrastructure Manager (Infra Manager) là dịch vụ Terraform được quản lý của Google — nó chạy Terraform của bạn (từ một git repo hoặc GCS) bằng Cloud Build, lưu state trong một GCS bucket do Google quản lý, và thực thi dưới danh nghĩa một service account. Bạn có Terraform mà không cần vận hành trình chạy hay state backend của riêng mình.

gcloud infra-manager deployments apply projects/PROJECT/locations/us-central1/deployments/prod \
  --service-account=projects/PROJECT/serviceAccounts/infra@PROJECT.iam.gserviceaccount.com \
  --git-source-repo=https://github.com/org/infra \
  --git-source-directory=environments/prod \
  --git-source-ref=main

Config Connector

Config Connector là một GKE add-on cho phép bạn quản lý các resource Google Cloud như các custom resource Kubernetes (CRD). Vòng lặp reconciliation của Kubernetes liên tục đẩy trạng thái thực tế về phía spec đã khai báo — một sự phù hợp tự nhiên cho GitOps (Argo CD / Flux) và các platform team đã chuẩn hóa trên Kubernetes. Nó cũng làm nền cho cách tiếp cận KRM (Kubernetes Resource Model) được dùng bởi Config Sync / Anthos Config Management.

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-project-assets
  labels:
    team: platform
spec:
  location: US
  uniformBucketLevelAccess: true

Deployment Manager (legacy)

Deployment Manager là IaC nguyên bản (first-party) đầu tiên của Google dùng template YAML + Jinja/Python. Nó nay đã deprecated để nhường chỗ cho Infrastructure Manager và Terraform và không nên dùng cho công việc mới. Hãy migrate các template DM hiện có sang Terraform.

gcloud & Cloud Build cho CI

• gcloud — CLI mệnh lệnh, lý tưởng để bootstrap, các thao tác một lần, và scripting các mảnh mà IaC bootstrap (bucket state, project seed).
• Cloud Build — CI/CD được quản lý của Google. Một cloudbuild.yaml chạy Terraform trong container, được kiểm soát theo branch/PR, dùng một service account chuyên dụng và Workload Identity.

# cloudbuild.yaml — plan on PR, apply on main
steps:
  - name: 'hashicorp/terraform:1.6'
    args: ['init']
  - name: 'hashicorp/terraform:1.6'
    args: ['plan', '-out=tfplan']
  - name: 'hashicorp/terraform:1.6'
    entrypoint: 'sh'
    args: ['-c', 'if [ "$BRANCH_NAME" = "main" ]; then terraform apply -auto-approve tfplan; fi']
options:
  logging: CLOUD_LOGGING_ONLY

Khái niệm chính

Các bề mặt quản lý chi phí

• Billing reports & Cost Table — bảng phân tích tương tác về chi tiêu theo project, service, SKU, và label trong Cloud Billing console.
• Billing export to BigQuery — bộ dữ liệu chi tiết, có thẩm quyền cho FinOps; bật nó và truy vấn/trực quan hóa (Looker Studio) cho các phân tích chi phí tùy chỉnh.
• Budgets & alerts — đặt một khoản tiền hàng tháng (hoặc theo kỳ tùy chỉnh) và nhận cảnh báo tại các phần trăm ngưỡng (ví dụ 50/90/100%). Cảnh báo đi tới các billing admin và, qua Pub/Sub, có thể kích hoạt các phản ứng lập trình (ví dụ, giới hạn một project non-prod). Lưu ý: một budget cảnh báo, nó không tự động ngừng chi tiêu.

gcloud billing budgets create \
  --billing-account=XXXXXX-XXXXXX-XXXXXX \
  --display-name="prod-monthly" \
  --budget-amount=5000USD \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0

Chiết khấu: CUD, SUD, và Spot

Cơ chế	Tiết kiệm	Cách thức	Phù hợp nhất cho
Sustained Use Discounts (SUD)	tới ~30%	Tự động, cho VM chạy phần lớn tháng	GCE luôn bật ổn định (không cam kết)
Committed Use Discounts (CUD)	tới ~57–70%	Cam kết 1 hoặc 3 năm (theo resource hoặc theo chi tiêu)	Baseline đoán trước được (Compute, GKE, Cloud SQL, v.v.)
Spot VMs	60–91%	Capacity dư có thể bị thu hồi (preemptible)	Chịu lỗi, batch, stateless

• SUD áp dụng tự động — không cần hành động — cho việc dùng GCE ổn định.
• CUD có hai dạng: theo resource (cam kết vCPU/RAM trong một region) và theo chi tiêu / linh hoạt (cam kết $/giờ trên các service đủ điều kiện). Mua CUD cho baseline ổn định của bạn, giữ on-demand/Spot cho các đỉnh.
• Spot VMs có thể bị thu hồi với thông báo trước ~30 giây — kết hợp với MIG/GKE autohealing.

Kiểm soát chi phí BigQuery

Billing on-demand của BigQuery tính theo số byte được quét, nên các truy vấn chạy mất kiểm soát là hóa đơn bất ngờ kinh điển. Các biện pháp kiểm soát:

• Custom quotas — giới hạn số byte xử lý mỗi project/user mỗi ngày.
• Maximum bytes billed — đặt --maximum_bytes_billed cho mỗi truy vấn để thất bại cứng với các truy vấn đắt đỏ.
• Partitioning & clustering — cắt tỉa dữ liệu được quét để các truy vấn chạm vào ít byte hơn nhiều.
• Editions + slot reservations / autoscaling — chuyển từ on-demand sang capacity pricing cho các workload nặng đoán trước được.
• SELECT chỉ các cột cần thiết — lưu trữ dạng cột nghĩa là ít cột hơn = ít byte hơn.

Label cho cost allocation

Label là các cặp key/value trên resource, chảy vào billing export và các báo cáo, cho phép quy trách nhiệm chi phí theo team, môi trường, cost-center, hoặc application. Một sơ đồ gắn label nhất quán là nền tảng của showback/chargeback.

gcloud compute instances add-labels web-1 --zone=us-central1-a \
  --labels=team=platform,environment=prod,cost-center=cc-1234,app=api

Label vs network tag vs resource hierarchy: label dùng cho billing/tổ chức và xuất hiện trong các báo cáo chi phí; network tag chỉ dùng cho firewall rule; resource hierarchy (org → folder → project) là ranh giới chính cho cả IAM lẫn tổng hợp chi phí. Quy các chi phí diện rộng theo project và các chi phí chi tiết theo label.

Recommender & FinOps

Dịch vụ Recommender tạo ra các khuyến nghị có thể hành động: loại bỏ VM nhàn rỗi / disk nhàn rỗi / IP nhàn rỗi, right-sizing loại máy VM, khuyến nghị mua CUD, và các gợi ý IAM/bảo mật. Active Assist đưa những thứ này lên khắp console. Review đầu ra của Recommender một cách thường xuyên là một trong những thói quen FinOps có ROI cao nhất.

Best Practices

1. Quản lý toàn bộ hạ tầng bằng code; cấm click-ops cho production. Lý do: khả năng tái tạo, peer review, và drift detection là bất khả thi với các thay đổi console thủ công.

2. Lưu trữ Terraform state từ xa trong một GCS bucket versioned với locking. Lý do: state được chia sẻ cho phép cộng tác nhóm; versioning khôi phục state bị hỏng; GCS backend ngăn hỏng do apply đồng thời.

3. Tạo bucket state ngoài luồng và bảo vệ nó. Lý do: nó không thể quản lý state của chính mình; hạn chế IAM chặt chẽ và bật versioning/retention vì nó giữ secret và nguồn sự thật.

4. Dùng Infrastructure Manager hoặc Config Connector cho mô hình managed/GitOps. Lý do: chuyển gánh nặng vận hành trình chạy và state cho Google (Infra Manager) hoặc mang lại reconciliation liên tục và GitOps (Config Connector) thay vì các apply cục bộ tùy tiện.

5. Không bắt đầu công việc mới trên Deployment Manager. Lý do: nó đã deprecated; hãy chuẩn hóa trên Terraform / Infra Manager và migrate các template hiện có.

6. Ghim phiên bản provider và Terraform; chạy plan trong CI trên mỗi PR. Lý do: ghim phiên bản ngăn các thay đổi phá vỡ bất ngờ; các plan trên PR làm cho thay đổi hạ tầng có thể review được trước khi apply.

7. Chạy Terraform qua CI (Cloud Build) với một service account least-privilege và Workload Identity. Lý do: loại bỏ thông tin xác thực của con người và các key có thể tải xuống khỏi đường apply và tập trung hóa một pipeline thay đổi có thể audit.

8. Áp đặt một chuẩn gắn label bắt buộc (team, environment, cost-center, app). Lý do: label là xương sống của việc quy trách nhiệm chi phí và showback/chargeback; áp đặt qua org policy hoặc kiểm tra CI để không gì ship mà không có label.

9. Bật Cloud Billing export sang BigQuery ngay ngày đầu tiên. Lý do: đó là bộ dữ liệu chi phí hoàn chỉnh, chi tiết duy nhất; không có lịch sử sớm bạn không thể phân tích xu hướng hay làm FinOps chính xác.

10. Đặt budget với nhiều ngưỡng cảnh báo trên mọi billing account/project. Lý do: các cảnh báo sớm (50/90/100%) bắt được chi tiêu chạy mất kiểm soát trước những bất ngờ cuối tháng.

11. Nối thông báo Pub/Sub của budget vào các guardrail tự động cho non-prod. Lý do: budget chỉ cảnh báo — tự động hóa (ví dụ, tắt billing hoặc scale down một sandbox) mới thực sự giới hạn được khoản chi vượt không quan trọng.

12. Mua Committed Use Discounts cho tải baseline ổn định; để SUD áp dụng tự động. Lý do: giảm tới ~57–70% cho việc dùng đoán trước được; SUD không cần hành động nhưng CUD đòi hỏi mua có chủ đích để có mức tiết kiệm lớn nhất.

13. Dùng Spot VMs cho các workload chịu lỗi, batch, và stateless. Lý do: tiết kiệm 60–91%; với MIG/GKE autohealing, việc thu hồi được hấp thụ một cách êm ái.

14. Bảo vệ BigQuery bằng maximum-bytes-billed, custom quota, và partitioning. Lý do: billing on-demand tính theo byte được quét; các biện pháp này ngăn một truy vấn đơn lẻ tạo ra một hóa đơn khổng lồ.

15. Review đầu ra của Recommender / Active Assist theo một nhịp độ đều đặn. Lý do: loại bỏ resource nhàn rỗi và các khuyến nghị right-sizing là những khoản tiết kiệm ROI cao, ít công sức mà nếu không sẽ tích lũy âm thầm.

16. Dùng resource hierarchy (folder/project) làm ranh giới chi phí và policy. Lý do: tổng hợp theo từng project cộng với org policy cho việc quy trách nhiệm chi phí gọn gàng và các guardrail (ví dụ, hạn chế region, chặn external IP) ở quy mô lớn.

Tài liệu tham khảo

• Terraform on Google Cloud
• Terraform google provider
• Terraform GCS backend
• Infrastructure Manager documentation
• Config Connector documentation
• Deployment Manager deprecation notice
• Cloud Build documentation
• Cloud Billing reports
• Export Cloud Billing data to BigQuery
• Create and manage budgets
• Committed use discounts
• Sustained use discounts
• Spot VMs
• BigQuery cost controls
• Labels and cost allocation
• Recommender / Active Assist

terraform {
  required_version = ">= 1.6"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = "my-project"
  region  = "us-central1"
}

resource "google_storage_bucket" "assets" {
  name                        = "my-project-assets"
  location                    = "US"
  uniform_bucket_level_access = true
  labels = {
    team        = "platform"
    environment = "prod"
    cost-center = "cc-1234"
  }
}

# backend.tf — remote state in a GCS bucket
terraform {
  backend "gcs" {
    bucket = "my-project-tfstate"   # create & version this bucket beforehand
    prefix = "env/prod"             # state object path within the bucket
  }
}

gcloud storage buckets create gs://my-project-tfstate \
  --location=us --uniform-bucket-level-access
gcloud storage buckets update gs://my-project-tfstate --versioning

gcloud infra-manager deployments apply projects/PROJECT/locations/us-central1/deployments/prod \
  --service-account=projects/PROJECT/serviceAccounts/infra@PROJECT.iam.gserviceaccount.com \
  --git-source-repo=https://github.com/org/infra \
  --git-source-directory=environments/prod \
  --git-source-ref=main

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-project-assets
  labels:
    team: platform
spec:
  location: US
  uniformBucketLevelAccess: true

# cloudbuild.yaml — plan on PR, apply on main
steps:
  - name: 'hashicorp/terraform:1.6'
    args: ['init']
  - name: 'hashicorp/terraform:1.6'
    args: ['plan', '-out=tfplan']
  - name: 'hashicorp/terraform:1.6'
    entrypoint: 'sh'
    args: ['-c', 'if [ "$BRANCH_NAME" = "main" ]; then terraform apply -auto-approve tfplan; fi']
options:
  logging: CLOUD_LOGGING_ONLY

gcloud billing budgets create \
  --billing-account=XXXXXX-XXXXXX-XXXXXX \
  --display-name="prod-monthly" \
  --budget-amount=5000USD \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0

gcloud compute instances add-labels web-1 --zone=us-central1-a \
  --labels=team=platform,environment=prod,cost-center=cc-1234,app=api