Bài 6 — GCP — Tổng quan Google Cloud

Mở đầu — vì sao bài này quan trọng

Nếu bạn đã đi qua Bài 5 về AWS, bạn sẽ nhận ra một điều: học cloud không phải là học thuộc từng nút bấm, mà là học cách tư duy theo dịch vụ. Google Cloud Platform (GCP) là "người chơi" lớn thứ ba trên thị trường cloud toàn cầu, sau AWS và Azure, nhưng ở nhiều lĩnh vực cụ thể — đặc biệt là dữ liệu lớn, phân tích, machine learning và mạng lưới toàn cầu — GCP lại là lựa chọn được giới kỹ sư đánh giá rất cao.

Vì sao một kỹ sư DevOps ở Việt Nam cần hiểu GCP? Có ba lý do rất thực tế. Thứ nhất, ngày càng nhiều startup và công ty công nghệ Việt Nam (đặc biệt là các đội làm sản phẩm gốc từ Google như Firebase, hay các đội data) chọn GCP làm nền tảng chính. Thứ hai, Google có hạ tầng mạng cáp quang riêng phủ toàn cầu, cho độ trễ (latency) thấp và ổn định khi phục vụ người dùng ở khu vực châu Á — Thái Bình Dương, trong đó có khu vực (region) asia-southeast1 đặt tại Singapore, rất gần Việt Nam. Thứ ba, nếu bạn định làm về AI/ML hoặc phân tích dữ liệu, GCP với BigQuery và Vertex AI gần như là "chuẩn vàng" mà nhiều nhà tuyển dụng mong đợi.

Mục tiêu của bài này không phải để bạn thành chuyên gia GCP sau một buổi học. Mục tiêu là để bạn nắm được bản đồ tổng thể — hiểu GCP được tổ chức như thế nào, các họ dịch vụ chính là gì, chúng tương đương với dịch vụ nào bên AWS mà bạn đã biết, và khi nào thì nên nghiêng về GCP. Đây là nền tảng để các bài sau (Compute, Storage, Database, Networking...) trở nên dễ tiếp thu hơn nhiều.

Khái niệm cốt lõi

Cách GCP tổ chức tài nguyên: Organization → Folder → Project

Điểm khác biệt đầu tiên và quan trọng nhất so với AWS là cách GCP nhóm tài nguyên. Trong GCP, đơn vị trung tâm là Project (dự án). Mọi tài nguyên — máy ảo, cơ sở dữ liệu, bucket lưu trữ — đều phải thuộc về một Project. Project là ranh giới cho việc tính tiền (billing), phân quyền (IAM), và quản lý API.

Phía trên Project là cấu trúc phân cấp:

• Organization: đại diện cho cả công ty (thường gắn với một domain như congty.com.vn).
• Folder: nhóm các Project lại theo phòng ban, môi trường (dev/staging/prod) hoặc nhóm sản phẩm.
• Project: nơi tài nguyên thực sự sống.

Nếu bạn từng làm việc với AWS Account, hãy hình dung: một GCP Project gần giống một AWS Account về mặt ranh giới cô lập, nhưng nhẹ nhàng hơn — bạn có thể tạo hàng chục Project chỉ trong vài phút mà không cần thủ tục mở account riêng. Đây là một điểm mà nhiều người thấy GCP "gọn" hơn.

Region và Zone

Giống mọi nhà cung cấp cloud, GCP chia hạ tầng vật lý thành Region (khu vực địa lý, ví dụ asia-southeast1 ở Singapore, asia-southeast2 ở Jakarta) và Zone (khu dữ liệu độc lập bên trong một Region, ví dụ asia-southeast1-a, -b, -c). Một số dịch vụ là zonal (chỉ sống trong một zone, như một máy ảo cụ thể), số khác là regional (nhân bản qua nhiều zone), và số khác nữa là global (như hệ thống cân bằng tải toàn cầu của Google — một trong những thế mạnh nổi bật của GCP).

Bản đồ các họ dịch vụ chính

Đây là phần "xương sống" của bài. Bảng dưới đây ánh xạ các dịch vụ GCP với dịch vụ AWS tương đương mà bạn đã học ở Bài 5 — cách nhanh nhất để "chuyển ngữ" kiến thức.

Bạn không cần thuộc lòng cả bảng này. Điều cần nhớ là: với gần như mọi nhu cầu, GCP đều có một dịch vụ tương ứng, và tên gọi của GCP thường trực quan hơn (Cloud Storage, Cloud SQL, Cloud DNS — cứ "Cloud + chức năng").

Ba "viên ngọc" đặc trưng của GCP

Trong biển dịch vụ đó, có ba thứ khiến GCP thực sự nổi bật và thường là lý do người ta chọn GCP:

• BigQuery — kho dữ liệu (data warehouse) serverless. Bạn nạp hàng terabyte dữ liệu vào, viết câu lệnh SQL bình thường, và Google tự lo phần hạ tầng tính toán khổng lồ phía sau. Không cần dựng cluster, không cần lo scale. Đây là "sát thủ" của GCP trong lĩnh vực phân tích.

• Google Kubernetes Engine (GKE) — vì Kubernetes vốn do chính Google tạo ra (từ dự án Borg nội bộ), GKE thường được xem là bản Kubernetes quản lý trưởng thành và mượt mà nhất.

• Cloud Run — chạy container theo mô hình serverless, tính tiền theo từng 100 mili-giây thực thi, tự động scale về 0 khi không có request. Cực kỳ tiết kiệm cho ứng dụng có lưu lượng thất thường.

Cách tương tác với GCP

Có bốn cách chính bạn sẽ dùng: Cloud Console (giao diện web), gcloud CLI (dòng lệnh — công cụ chủ lực của DevOps), Cloud Shell (một terminal Linux miễn phí ngay trong trình duyệt, đã cài sẵn gcloud), và API/SDK/Terraform cho tự động hóa. Với vai trò DevOps, bạn sẽ sống chủ yếu với gcloud và Terraform.

Tình huống thực tế

Tình huống 1 — Startup thương mại điện tử chọn Cloud Run để cắt chi phí

Một startup bán mỹ phẩm online tại TP.HCM, gọi là "BeautyBox", ban đầu chạy toàn bộ backend trên ba máy ảo EC2 luôn bật 24/7, tốn khoảng 9 triệu đồng/tháng. Vấn đề: lưu lượng của họ rất "gợn sóng" — cao điểm vào buổi tối và cuối tuần, gần như trống trơn lúc 3–4 giờ sáng, nhưng máy ảo vẫn chạy và vẫn tính tiền suốt.

Đội kỹ thuật quyết định đóng gói backend thành container và chuyển sang Cloud Run trên GCP, region asia-southeast1 (Singapore). Điểm mấu chốt: Cloud Run tự động scale về 0 instance khi không có request, và scale lên hàng chục instance trong vài giây khi lưu lượng tăng. Kết quả sau một tháng: hóa đơn compute giảm xuống còn khoảng 3,2 triệu đồng — tiết kiệm gần 65% — vì họ chỉ trả tiền cho thời gian thực sự xử lý request.

Bài học rút ra: với ứng dụng có lưu lượng không đều, mô hình serverless container như Cloud Run có thể tiết kiệm chi phí rất mạnh so với máy ảo luôn bật. Nhưng đổi lại phải chấp nhận "cold start" — độ trễ nhẹ ở request đầu tiên sau khi scale về 0.

Tình huống 2 — Công ty fintech dùng BigQuery cho báo cáo phân tích

Một công ty fintech giả định, "PayViet", xử lý khoảng 2 triệu giao dịch mỗi ngày. Đội phân tích cần chạy báo cáo tổng hợp doanh thu, phát hiện gian lận, và phân khúc khách hàng. Trước đây họ chạy các câu query nặng trực tiếp trên cơ sở dữ liệu giao dịch (PostgreSQL), khiến hệ thống production đôi lúc chậm hẳn vào cuối tháng khi làm báo cáo.

Họ tách phần phân tích ra bằng cách đẩy dữ liệu giao dịch mỗi đêm sang BigQuery. Giờ đội phân tích viết SQL bình thường trên BigQuery, quét qua hàng trăm triệu dòng chỉ trong vài giây, mà không hề chạm vào database production. Chi phí BigQuery tính theo lượng dữ liệu quét (khoảng 5 USD cho mỗi terabyte quét), nên họ tối ưu bằng cách chia bảng theo ngày (partitioning) để mỗi query chỉ quét đúng khoảng thời gian cần.

Bài học rút ra: hãy tách workload phân tích (OLAP) ra khỏi database vận hành (OLTP). BigQuery là công cụ lý tưởng cho việc này, nhưng cần hiểu mô hình tính tiền theo dung lượng quét để tránh "cháy túi" — đây chính là lý do partitioning và chọn đúng cột rất quan trọng.

Tình huống 3 — Đội mobile tận dụng hệ sinh thái Firebase + GCP

Một studio game nhỏ ở Đà Nẵng phát hành game mobile cho thị trường Đông Nam Á. Họ bắt đầu với Firebase (thuộc hệ sinh thái Google Cloud) để xử lý đăng nhập, lưu tiến trình người chơi (Firestore), và gửi thông báo đẩy. Khi game viral và đạt 500.000 người dùng, họ cần thêm backend xử lý bảng xếp hạng và sự kiện — và vì Firebase nằm chung nhà với GCP, họ chỉ việc mở rộng sang Cloud Functions và Firestore ở cùng một Project, dùng chung IAM và billing, không phải tích hợp chéo giữa hai nền tảng khác nhau.

Bài học rút ra: một trong những sức mạnh của GCP là sự liền mạch với Firebase — đặc biệt hấp dẫn cho đội mobile và game khởi nghiệp. Khi các dịch vụ nằm chung một Project, việc quản lý quyền, chi phí và mở rộng đơn giản hơn nhiều.

Hướng dẫn từng bước

Dưới đây là quy trình thực tế để bạn "chạm tay" vào GCP lần đầu — làm quen với cách tổ chức và công cụ dòng lệnh. Bạn có thể làm hoàn toàn miễn phí với gói dùng thử ($300 credit cho tài khoản mới) và các dịch vụ trong "Always Free tier".

• Tạo tài khoản và Project đầu tiên. Truy cập console.cloud.google.com, đăng nhập bằng tài khoản Google. Ở thanh trên cùng, chọn menu Project và tạo một Project mới, ví dụ đặt tên hoc-gcp-001. Ghi nhớ Project ID — mọi lệnh sau này đều gắn với nó.

• Liên kết tài khoản thanh toán (Billing). GCP yêu cầu gắn thẻ để xác minh, nhưng gói dùng thử sẽ không tự động trừ tiền khi hết credit. Vào mục Billing, tạo billing account và liên kết với Project.

• Bật các API cần dùng. Khác với AWS, ở GCP bạn phải chủ động "enable" API cho từng dịch vụ trước khi dùng. Ví dụ để dùng Compute Engine, vào mục API & Services và bật "Compute Engine API".

• Mở Cloud Shell. Bấm biểu tượng terminal ở góc trên bên phải Console. Bạn sẽ có ngay một môi trường Linux đã cài sẵn gcloud. Kiểm tra bằng lệnh gcloud config list để xem Project đang active.

• Đặt Project mặc định. Chạy gcloud config set project hoc-gcp-001 để mọi lệnh sau tự động áp dụng vào đúng Project, khỏi phải khai báo lặp lại.

• Tạo thử một máy ảo. Chạy gcloud compute instances create vm-test --zone=asia-southeast1-a --machine-type=e2-micro. Loại e2-micro nằm trong Always Free tier ở một số region, phù hợp để thử nghiệm.

• Liệt kê và dọn dẹp. Dùng gcloud compute instances list để xem máy vừa tạo, và quan trọng nhất — xóa nó sau khi thử xong bằng gcloud compute instances delete vm-test --zone=asia-southeast1-a để tránh phát sinh chi phí.

• Thiết lập cảnh báo ngân sách. Vào Billing → Budgets & alerts, tạo một budget ví dụ 200.000 đồng/tháng với cảnh báo email khi đạt 50% và 90%. Đây là bước bảo hiểm bắt buộc cho người mới.

Lỗi thường gặp & mẹo

Lỗi: quên bật API trước khi dùng dịch vụ. Người mới từ AWS chuyển sang thường bối rối khi lệnh báo lỗi kiểu "API has not been used or is disabled". Đây không phải bug — GCP yêu cầu bật từng API. Mẹo: đọc kỹ thông báo lỗi, nó thường kèm luôn đường link để bật API chỉ với một cú click.

Lỗi: nhầm lẫn ranh giới Project. Vì tạo Project quá dễ, nhiều người tạo tài nguyên nhầm Project rồi loay hoay không thấy. Luôn chạy gcloud config list để xác nhận Project active trước khi tạo tài nguyên.

Lỗi: để BigQuery quét toàn bộ bảng. Viết SELECT trên bảng lớn không phân vùng sẽ quét toàn bộ và tốn tiền. Mẹo: luôn dùng bảng có partition theo ngày, chỉ SELECT đúng cột cần, và xem trước ước tính dung lượng quét mà giao diện BigQuery hiển thị trước khi* bấm chạy.

Lỗi: quên máy ảo/dịch vụ đang chạy. Một máy ảo bị bỏ quên có thể âm thầm "ăn" hết credit trong vài tuần. Mẹo: luôn đặt budget alert ngay từ đầu, và tập thói quen xóa tài nguyên thử nghiệm ngay sau khi dùng xong.

Mẹo về region cho người dùng Việt Nam: ưu tiên asia-southeast1 (Singapore) cho độ trễ thấp nhất tới người dùng Việt Nam trong đa số trường hợp; asia-southeast2 (Jakarta) là lựa chọn thay thế. Đặt tài nguyên gần người dùng luôn giúp trải nghiệm nhanh hơn.

Mẹo về danh tính: thay vì tạo user cứng nhắc, GCP khuyến khích dùng Service Account cho ứng dụng và tự động hóa. Khi viết Terraform hay CI/CD, hãy dùng Service Account với quyền tối thiểu cần thiết (nguyên tắc least privilege).

Bài tập thực hành

• Vẽ bản đồ dịch vụ. Không nhìn lại bảng ở trên, hãy tự viết ra 8 nhu cầu (chạy máy ảo, lưu file, database quan hệ, phân tích dữ liệu lớn, CDN, DNS, Kubernetes, serverless function) và điền tên dịch vụ GCP tương ứng cho mỗi nhu cầu. Sau đó đối chiếu lại.

• Thực hành gcloud. Tạo một Project mới, bật Compute Engine API, mở Cloud Shell, tạo một máy ảo e2-micro ở asia-southeast1-a, liệt kê nó, rồi xóa. Ghi lại toàn bộ lệnh bạn dùng thành một đoạn script.

• Tình huống ra quyết định. Một công ty có ứng dụng web lưu lượng rất thất thường (cao điểm buổi tối, ban đêm gần như 0). Hãy viết một đoạn 4–5 câu lập luận: nên chọn Compute Engine hay Cloud Run cho họ? Vì sao? Đánh đổi (trade-off) là gì?

• Thiết lập an toàn chi phí. Tạo một budget alert 100.000 đồng cho Project của bạn với ngưỡng cảnh báo 50%, 90%, 100%. Chụp màn hình lại như bằng chứng bạn đã bảo vệ được ví tiền của mình.

• So sánh mở rộng. Đọc lướt trang giá của BigQuery và Redshift (AWS), viết 3 câu về sự khác biệt cơ bản trong mô hình tính tiền của hai dịch vụ này.

Tóm tắt

GCP là nền tảng cloud lớn thứ ba thế giới, mạnh đặc biệt ở dữ liệu, phân tích, AI/ML và mạng lưới toàn cầu. Điểm cốt lõi cần nhớ:

• Tổ chức tài nguyên theo Organization → Folder → Project, trong đó Project là ranh giới trung tâm cho billing và phân quyền — nhẹ và dễ tạo hơn AWS Account.
• Region/Zone: với Việt Nam, ưu tiên asia-southeast1 (Singapore).
• Bản đồ dịch vụ: hầu hết dịch vụ GCP đều có "họ hàng" bên AWS — Compute Engine ~ EC2, Cloud Storage ~ S3, Cloud SQL ~ RDS, GKE ~ EKS, Cloud Load Balancing ~ ELB. Tên GCP thường trực quan: "Cloud + chức năng".
• Ba viên ngọc đặc trưng: BigQuery (phân tích serverless), GKE (Kubernetes trưởng thành), Cloud Run (container serverless tiết kiệm).
• Công cụ DevOps: sống với gcloud CLI, Cloud Shell và Terraform; dùng Service Account cho tự động hóa với quyền tối thiểu.
• An toàn chi phí là kỹ năng bắt buộc: bật API thủ công, đặt budget alert, và luôn dọn dẹp tài nguyên thử nghiệm.

Ở các bài sau, chúng ta sẽ đi sâu vào từng họ dịch vụ (Compute, Storage, Database, Networking...) và bạn sẽ thấy bản đồ tổng thể hôm nay chính là khung xương giúp mọi thứ khớp vào đúng chỗ.