ComputeCompute

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

Tổng quan

Google Cloud cung cấp một dải các lựa chọn compute, từ máy ảo thuần túy cho tới các container serverless được quản lý hoàn toàn. Lựa chọn đúng phụ thuộc vào việc bạn muốn tự sở hữu bao nhiêu phần trong operational stack thay vì giao cho Google, workload của bạn scale ra sao, và nó được đóng gói thế nào (VM image, container, hay mã nguồn thuần).

Các dịch vụ cốt lõi, từ nhiều quyền kiểm soát nhất tới ít gánh nặng vận hành nhất:

Dịch vụ	Mức trừu tượng	Bạn quản lý	Google quản lý	Tương đương AWS
Compute Engine (GCE)	Máy ảo	OS, patching, cấu hình scaling	Phần cứng, hypervisor, network	EC2
Google Kubernetes Engine (GKE)	Managed Kubernetes	Workload, (một phần) node	Control plane, (Autopilot) node	EKS
Cloud Run	Container serverless	Container image	Mọi thứ còn lại, autoscaling	App Runner / Fargate
Cloud Functions	Function serverless	Mã function	Runtime, scaling, hạ tầng	Lambda
App Engine	Managed PaaS	Mã ứng dụng	Runtime + hạ tầng	Elastic Beanstalk

Một mô hình tư duy hữu ích: khi bạn đi xuống trong bảng, bạn đánh đổi quyền kiểm soát và tính linh hoạt để giảm gánh nặng vận hành, và thường là để có mô hình tính phí chi tiết hơn (scale-to-zero).

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

Compute Engine (GCE)

Compute Engine cung cấp các máy ảo có thể cấu hình chạy trên hạ tầng của Google. Một VM instance được định nghĩa bởi machine type (vCPU + bộ nhớ), một boot disk (từ một image), một zone, và cấu hình network.

Machine families nhóm các machine type theo profile workload:

Family	Series (ví dụ)	Tối ưu cho
General purpose	E2, N2, N2D, N4, C3, C4	Cân bằng giá/hiệu năng, web server, DB nhỏ/vừa
Compute optimized	C2, C2D, H3	Hiệu năng cao mỗi core, gaming, HPC, ad serving
Memory optimized	M1, M2, M3, M4	DB lớn in-memory (SAP HANA), analytics
Accelerator optimized	A2, A3, G2	Workload GPU/TPU, training/inference ML
Storage optimized	Z3	Mật độ local SSD cao, DB scale-out

Trong một family bạn chọn một machine type như e2-standard-4 (4 vCPU, 16 GB) hoặc một custom machine type khi các shape định sẵn gây lãng phí tài nguyên. E2 là series general-purpose rẻ nhất; C3/C4/N4 chạy trên phần cứng mới hơn với hiệu năng tốt hơn.

Images định nghĩa nội dung boot disk. Google cung cấp public images (Debian, Ubuntu, RHEL, Windows Server, Container-Optimized OS). Bạn có thể build custom images (đã tích hợp sẵn phần mềm của bạn) hoặc dùng một base image kèm startup script.

Startup scripts chạy khi khởi động để cấu hình instance:

gcloud compute instances create web-1 \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --image-family=debian-12 --image-project=debian-cloud \
  --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install -y nginx
    echo "Hello from $(hostname)" > /var/www/html/index.html'

Spot VMs (kế thừa của preemptible VMs) cho mức giảm giá 60-91% đổi lại không có cam kết về tính khả dụng — Google có thể thu hồi chúng với thông báo trước 30 giây. Lý tưởng cho các workload chịu lỗi tốt (fault-tolerant), batch, hoặc stateless. Preemptible VMs là biến thể cũ hơn giới hạn vòng đời 24 giờ; Spot VMs không có thời gian chạy tối đa.

Managed Instance Groups (MIGs) & autoscaling

Một Managed Instance Group chạy các VM giống hệt nhau từ một instance template, cung cấp:

• Autoscaling dựa trên CPU utilization, load-balancing capacity, metric của Cloud Monitoring, hoặc lịch (schedule).
• Autohealing qua health check — các VM không khỏe mạnh sẽ được tạo lại.
• Rolling updates / canary trên toàn nhóm.
• Phân phối regional (nhiều zone) cho tính sẵn sàng cao.

# 1. Tạo một instance template
gcloud compute instance-templates create web-tmpl \
  --machine-type=e2-medium \
  --image-family=debian-12 --image-project=debian-cloud \
  --metadata=startup-script='#! /bin/bash
    apt-get update && apt-get install -y nginx'

# 2. Tạo một regional MIG từ template
gcloud compute instance-groups managed create web-mig \
  --template=web-tmpl \
  --size=3 \
  --region=us-central1

# 3. Cấu hình autoscaling (mục tiêu 60% CPU, 2-10 instance)
gcloud compute instance-groups managed set-autoscaling web-mig \
  --region=us-central1 \
  --min-num-replicas=2 --max-num-replicas=10 \
  --target-cpu-utilization=0.6 --cool-down-period=90

MIG nằm sau Cloud Load Balancing để phân phối lưu lượng và là pattern kinh điển cho các tầng web dựa trên VM có khả năng scale.

Tương đương trong Terraform:

resource "google_compute_instance_template" "web" {
  name_prefix  = "web-tmpl-"
  machine_type = "e2-medium"
  disk {
    source_image = "debian-cloud/debian-12"
    auto_delete  = true
    boot         = true
  }
  network_interface { network = "default" }
  metadata = {
    startup-script = "apt-get update && apt-get install -y nginx"
  }
  lifecycle { create_before_destroy = true }
}

resource "google_compute_region_instance_group_manager" "web" {
  name               = "web-mig"
  region             = "us-central1"
  base_instance_name = "web"
  version { instance_template = google_compute_instance_template.web.id }
  target_size        = 3
}

Google Kubernetes Engine (GKE)

GKE là Kubernetes được quản lý của Google. Google vận hành control plane (API server, etcd, scheduler); bạn triển khai các workload Kubernetes tiêu chuẩn.

Standard vs Autopilot:

Khía cạnh	GKE Standard	GKE Autopilot
Quản lý node	Bạn cấu hình/quản lý node pool	Google provision/quản lý node
Tính phí	Theo node (VM)	Theo resource request của pod
Bin-packing	Trách nhiệm của bạn	Google tối ưu
Tính linh hoạt	Đầy đủ (DaemonSet, cấu hình node tùy chỉnh, GPU)	Hạn chế, mặc định được hardening
Phù hợp cho	Kiểm soát chi tiết, phần cứng đặc biệt	Không phải bận tâm, secure-by-default

Node pools là các nhóm node có cùng cấu hình (machine type, disk, label). Một cluster có thể có nhiều pool — ví dụ một pool chung cộng một pool GPU hoặc một pool Spot cho batch job.

Workload Identity là cách được khuyến nghị để pod xác thực với các API của Google Cloud. Nó ánh xạ một Kubernetes service account tới một IAM service account, loại bỏ nhu cầu mount các service account key tồn tại lâu dài:

# Gắn KSA với GSA
gcloud iam service-accounts add-iam-policy-binding \
  my-gsa@PROJECT.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:PROJECT.svc.id.goog[NAMESPACE/my-ksa]"

Cloud Run

Cloud Run chạy các container stateless tự động scale, bao gồm cả scale to zero (không tốn chi phí khi rảnh). Bạn cung cấp một container lắng nghe trên $PORT; Google lo việc provisioning, TLS, và autoscaling.

Services vs Jobs:

• Services xử lý request (HTTP, gRPC, event) và luôn sẵn sàng phục vụ. Chúng scale theo lượng request.
• Jobs chạy tới khi hoàn thành (batch/ETL/migration) rồi thoát. Chúng có thể chạy các task song song và được kích hoạt thủ công, theo lịch, hoặc qua Cloud Scheduler/Workflows.

Concurrency — một container instance Cloud Run có thể xử lý nhiều request đồng thời (mặc định tới 80, tối đa 1000). Concurrency cao hơn cải thiện mức tận dụng và giảm chi phí nhưng yêu cầu ứng dụng thread-safe. Đặt concurrency bằng 1 cho workload CPU-bound hoặc không thread-safe.

gcloud run deploy my-api \
  --image=us-docker.pkg.dev/PROJECT/repo/my-api:v1 \
  --region=us-central1 \
  --concurrency=80 \
  --cpu=1 --memory=512Mi \
  --min-instances=0 --max-instances=20 \
  --allow-unauthenticated

Scale-to-zero nghĩa là bạn chỉ trả tiền khi request đang được xử lý (cộng tùy chọn min-instances để giữ warm capacity). Cold start là cái giá phải trả; đặt --min-instances=1 cho các service nhạy cảm với độ trễ.

Một Cloud Run job (chạy tới khi hoàn thành rồi thoát):

gcloud run jobs create migrate-db \
  --image=us-docker.pkg.dev/PROJECT/repo/migrator:v1 \
  --region=us-central1 \
  --tasks=1 --max-retries=3 --task-timeout=600
gcloud run jobs execute migrate-db --region=us-central1 --wait

Cloud Functions (gen 2)

Cloud Functions (thế hệ 2) được xây trên Cloud Run và Eventarc, nên kế thừa concurrency, timeout dài hơn (tới 60 phút), và instance lớn hơn của Cloud Run. Nó chạy các function đơn mục đích được kích hoạt bởi HTTP hoặc event (Pub/Sub, Cloud Storage, Firestore, Eventarc).

gcloud functions deploy process-upload \
  --gen2 --runtime=nodejs20 \
  --region=us-central1 \
  --trigger-bucket=my-uploads \
  --entry-point=processUpload \
  --memory=256Mi

Dùng Functions cho mã kết dính (glue code) hướng sự kiện; dùng Cloud Run khi bạn cần toàn quyền kiểm soát container hoặc một service chạy dài.

App Engine (tóm tắt)

App Engine là PaaS nguyên bản của Google. Hai môi trường:

• Standard — chạy sandbox, scale nhanh (kể cả về zero), các runtime ngôn ngữ cụ thể, phù hợp nhất cho các ứng dụng web/API stateless.
• Flexible — chạy ứng dụng của bạn trong container Docker trên các VM GCE được quản lý, linh hoạt hơn (bất kỳ runtime, tiến trình nền) nhưng scale chậm hơn và không scale-to-zero.

Với hầu hết workload mới, Cloud Run về cơ bản đã thay thế App Engine Flexible, và Cloud Run/Functions bao phủ các use case của Standard với tính linh hoạt cao hơn.

Khái niệm chính

Chọn một dịch vụ compute

1. ?Có phải là một function đơn hướng sự kiện (glue code)?
   Có

   Cloud Functionsgen 2
2. ?Có phải là một container/web service/API stateless?
   Có

   Cloud Runscale-to-zero, tính phí theo request, ít vận hành
3. ?Bạn có cần Kubernetes (microservice phức tạp, service mesh, custom operator, tính di động, GPU ở quy mô lớn)?
   Có

   GKEAutopilot để không phải bận tâm, Standard để kiểm soát đầy đủ
4. ?Bạn có cần toàn quyền kiểm soát OS, phần mềm có license, GPU trên VM, lift-and-shift, hoặc machine shape chuyên biệt?
   Có

   Compute Enginekèm MIG để scale

Quy tắc kinh nghiệm:

• Mặc định chọn Cloud Run cho các service stateless mới — ít vận hành nhất, kinh tế tốt.
• Chọn GKE khi bạn đã chạy Kubernetes, cần multi-container pod, service mesh, hoặc scheduling phức tạp.
• Chọn Compute Engine cho legacy/lift-and-shift, workload stateful, licensing, hoặc khi cần một OS/kernel cụ thể.
• Dùng Cloud Functions cho các event handler nhỏ và tích hợp.

Region và zone

Tài nguyên có phạm vi: zonal (một VM đơn, disk zonal), regional (MIG regional, disk regional), hoặc global (image, global load balancer). Trải rộng qua các zone/region là nền tảng của tính sẵn sàng cao.

Sustained use & committed use discounts

• Sustained use discounts (SUDs) áp dụng tự động cho các VM chạy phần lớn thời gian trong tháng.
• Committed use discounts (CUDs) giảm tới ~57% cho cam kết 1 hoặc 3 năm với một lượng tài nguyên — rất tốt cho tải nền ổn định.

Cold start

Cả Cloud Run và Cloud Functions đều “scale to zero”, nên request đầu tiên sau một khoảng rảnh sẽ chịu một cold start (khởi động container + init ứng dụng). Giảm thiểu bằng min-instances, image nhỏ hơn, lazy loading các dependency nặng, và CPU boost khi khởi động.

Best Practices

1. Mặc định ưu tiên managed/serverless trước. Bắt đầu với Cloud Run hoặc Functions và chỉ chuyển sang GKE/GCE khi gặp giới hạn thực sự. Lý do: ít việc vận hành không tạo giá trị khác biệt, tự động scale, và kinh tế trả-theo-sử-dụng.

2. Dùng instance template + MIG, không bao giờ tạo pet VM thủ công. Lý do: template khiến instance có thể tái tạo và cho phép autohealing, autoscaling, rolling update — coi VM như “cattle”, không phải “pet”.

3. Right-size machine type và dùng custom type khi cần. Khớp vCPU/bộ nhớ với mức dùng thực tế; dùng gợi ý từ Recommender. Lý do: các shape định sẵn thường over-provision một chiều, gây lãng phí tiền.

4. Dùng Spot VM cho workload chịu lỗi tốt và batch. Lý do: tiết kiệm 60-91%; kết hợp với MIG và autohealing, các gián đoạn được hấp thụ một cách mượt mà.

5. Mua Committed Use Discount cho tải nền ổn định. Lý do: tiết kiệm tới ~57% cho workload có thể dự đoán; giữ on-demand/Spot cho các đỉnh biến động.

6. Ưu tiên GKE Autopilot trừ khi bạn cần quyền kiểm soát của Standard. Lý do: trả theo pod, Google hardening và quản lý node, ít bề mặt vận hành và ít cấu hình sai hơn.

7. Dùng Workload Identity thay vì service account key trong GKE. Lý do: loại bỏ các key tải xuống được tồn tại lâu dài — vector rò rỉ credential phổ biến nhất trên cloud.

8. Điều chỉnh concurrency của Cloud Run một cách có chủ đích. Lý do: concurrency cao hơn giảm chi phí và cold start cho ứng dụng I/O-bound; đặt bằng 1 cho code CPU-bound hoặc không thread-safe để tránh tranh chấp.

9. Đặt min-instances cho các service Cloud Run nhạy cảm với độ trễ. Lý do: giữ các instance warm để tránh độ trễ cold-start, trong khi vẫn scale xuống một sàn thấp thay vì một cụm cố định lớn.

10. Bake golden image cho các stack khởi động chậm; dùng startup script cho cấu hình nhẹ. Lý do: custom image cắt giảm thời gian khởi động và loại bỏ các lỗi khi cài đặt; startup script giữ template linh hoạt cho các chỉnh sửa nhỏ.

11. Gắn health check cho mọi MIG và load balancer. Lý do: cho phép autohealing và ngăn lưu lượng đi tới các instance hỏng.

12. Phân phối qua nhiều zone (regional MIG / GKE nhiều zone). Lý do: sống sót qua sự cố một zone; tài nguyên regional là chuẩn cơ bản cho HA production.

13. Giữ container tối giản và stateless. Lý do: cold start nhanh hơn, bề mặt tấn công nhỏ hơn, và scale ngang sạch sẽ; đẩy state sang các database/object storage được quản lý.

14. Dùng service account theo nguyên tắc đặc quyền tối thiểu cho mỗi workload. Lý do: một VM/pod/function bị xâm phạm chỉ bị giới hạn trong các quyền hẹp của riêng nó thay vì một account mặc định rộng.

15. Bật Shielded VM và OS Login cho Compute Engine. Lý do: Shielded VM bảo vệ chống rootkit ở mức boot; OS Login tập trung hóa quyền truy cập SSH qua IAM thay vì quản lý key trên từng instance.

16. Tự động hóa hạ tầng với Terraform / Config Connector. Lý do: hạ tầng có thể tái tạo, review được, và version-controlled tốt hơn click-ops và drift.

Tài liệu tham khảo

• Compute Engine documentation
• Machine families resource and comparison guide
• Spot VMs
• Managed Instance Groups
• Autoscaling groups of instances
• GKE documentation
• GKE Autopilot overview
• GKE Workload Identity
• Cloud Run documentation
• Cloud Run jobs
• Cloud Functions (2nd gen)
• App Engine documentation
• Choosing a compute option (hosting decision tree)
• Committed use discounts

gcloud compute instances create web-1 \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --image-family=debian-12 --image-project=debian-cloud \
  --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install -y nginx
    echo "Hello from $(hostname)" > /var/www/html/index.html'

# 1. Create an instance template
gcloud compute instance-templates create web-tmpl \
  --machine-type=e2-medium \
  --image-family=debian-12 --image-project=debian-cloud \
  --metadata=startup-script='#! /bin/bash
    apt-get update && apt-get install -y nginx'

# 2. Create a regional MIG from the template
gcloud compute instance-groups managed create web-mig \
  --template=web-tmpl \
  --size=3 \
  --region=us-central1

# 3. Configure autoscaling (target 60% CPU, 2-10 instances)
gcloud compute instance-groups managed set-autoscaling web-mig \
  --region=us-central1 \
  --min-num-replicas=2 --max-num-replicas=10 \
  --target-cpu-utilization=0.6 --cool-down-period=90

resource "google_compute_instance_template" "web" {
  name_prefix  = "web-tmpl-"
  machine_type = "e2-medium"
  disk {
    source_image = "debian-cloud/debian-12"
    auto_delete  = true
    boot         = true
  }
  network_interface { network = "default" }
  metadata = {
    startup-script = "apt-get update && apt-get install -y nginx"
  }
  lifecycle { create_before_destroy = true }
}

resource "google_compute_region_instance_group_manager" "web" {
  name               = "web-mig"
  region             = "us-central1"
  base_instance_name = "web"
  version { instance_template = google_compute_instance_template.web.id }
  target_size        = 3
}

# Bind KSA to GSA
gcloud iam service-accounts add-iam-policy-binding \
  my-gsa@PROJECT.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:PROJECT.svc.id.goog[NAMESPACE/my-ksa]"

gcloud run deploy my-api \
  --image=us-docker.pkg.dev/PROJECT/repo/my-api:v1 \
  --region=us-central1 \
  --concurrency=80 \
  --cpu=1 --memory=512Mi \
  --min-instances=0 --max-instances=20 \
  --allow-unauthenticated

gcloud run jobs create migrate-db \
  --image=us-docker.pkg.dev/PROJECT/repo/migrator:v1 \
  --region=us-central1 \
  --tasks=1 --max-retries=3 --task-timeout=600
gcloud run jobs execute migrate-db --region=us-central1 --wait

gcloud functions deploy process-upload \
  --gen2 --runtime=nodejs20 \
  --region=us-central1 \
  --trigger-bucket=my-uploads \
  --entry-point=processUpload \
  --memory=256Mi