Cẩm Nang Kiến Trúc GCP Thực Dụng: Dịch Vụ Nào Thực Sự Nên Dùng (Và Nên Tránh Điều Gì)

Google Cloud Platform là một đô thị rộng lớn với hơn 100 dịch vụ. Điều hướng nó giống như bị đưa một cuốn danh bạ rồi bảo bạn đi tìm một nhà hàng ngon. Nghịch lý lựa chọn làm tê liệt. Thực tế của kỹ sư cloud chuyên nghiệp là thế này: một hệ thống production mạnh mẽ, có khả năng mở rộng và tiết kiệm chi phí không được xây bằng cách dùng 50 dịch vụ khác nhau. Nó được xây bằng cách làm chủ một lõi nhỏ, gắn kết khoảng 10-15 dịch vụ. 85% còn lại là hỗn hợp của các hệ thống cũ giữ lại để tương thích ngược, các giải pháp doanh nghiệp chuyên ngành quá mà bạn sẽ không bao giờ chạm tới, hoặc những cái bẫy ngân sách được ngụy trang tinh vi được thiết kế để khai thác sự lười biếng kiến trúc. Đây không phải là một tổng quan lý thuyết. Đây là cẩm nang thực dụng, đã được thử nghiệm chiến trường, được thiết kế để trao cho bạn những heuristic kiến trúc nhằm xây dựng hệ thống gọn gàng, mạnh mẽ trên GCP và tránh những quả mìn.

Ma Trận Phân Loại Dịch Vụ GCP 4 Tầng

Để tồn tại và phát triển trong GCP, trước tiên bạn phải học cách phân loại dịch vụ không phải theo trang marketing của chúng, mà theo tính hữu dụng thực tế và khả năng gây ra tổn hại về tài chính hoặc vận hành. Tôi xếp mọi dịch vụ GCP vào một trong bốn tầng. Nếu một dịch vụ không có trong danh sách này, bạn có thể yên tâm bỏ qua nó cho đến khi bạn ký được hợp đồng hỗ trợ trị giá hàng triệu đô la và có 50 kỹ sư SRE.

• Tầng 1: Nền Tảng Thiết Yếu. Đây là các khối xây không thể thương lượng. 99% ứng dụng mới nên được xây hoàn toàn chỉ từ tầng này. Chúng serverless, tiết kiệm chi phí và đơn giản về mặt vận hành.
• Tầng 2: Dữ Liệu & AI Đòn Bẩy Cao. Khi nền tảng của bạn đã vững chắc, những dịch vụ này mang lại giá trị vượt trội. Chúng cho phép các đội nhỏ vượt xa sức cân nặng của mình trong phân tích và học máy.
• Tầng 3: Chuyên Ngành / Quy Mô Lớn. Đây là những công cụ mạnh mẽ nhưng chuyên biệt. Bạn chỉ dùng đến chúng khi một dịch vụ tầng 1 chạm đến giới hạn kiến trúc nền tảng. Chúng đắt hơn và phức tạp hơn, nên quyết định sử dụng phải có chủ ý và có lý do biện minh.
• Tầng 4: Vùng Nguy Hiểm. Những dịch vụ này hoặc là hố đen ngân sách, hoặc là đầm lầy độ phức tạp. Trường hợp sử dụng của chúng hẹp đến mức khi bạn thực sự cần chúng, bạn khả năng cao đã vận hành ở quy mô có sẵn một đội riêng để quản lý chi phí và độ phức tạp. Startup và công ty quy mô vừa nên tránh chúng theo mặc định.

Compute: Vì Sao Cloud Run Là 90% Những Gì Bạn Cần

Hãy thẳng thắn mà nói: với đại đa số dịch vụ web không trạng thái, API và worker back-end, việc chọn GKE hoặc GCE VM thay vì Cloud Run vào năm 2026 là hành vi sai lầm kiến trúc. Tranh luận đã kết thúc.

Cloud Run không chỉ đơn thuần là "functions-as-a-service" kèm một Dockerfile. Đó là một nền tảng lưu trữ container tinh vi được xây trên hạ tầng Borg nội bộ của chính Google, với mô hình bảo mật và mở rộng gần như không thể sao chép.

Kiến Trúc Bên Trong

• Môi Trường Thực Thi: Container của bạn không chạy trên một VM thô. Nó chạy bên trong gVisor, một kernel không gian người dùng cung cấp sandbox an toàn. Nó chặn các system call từ container của bạn và kiểm tra chúng trước khi chuyển tới kernel máy chủ. Điều này tạo ra sự cô lập mạnh mẽ giữa các container mà không kéo theo chi phí hiệu năng của ảo hóa toàn phần. Đây là bảo mật cấp doanh nghiệp mà bạn nhận được miễn phí.
• Mở Rộng & Đồng Thời: Một "instance" truyền thống trong Cloud Run là một micro-VM Firecracker. Tham số tinh chỉnh then chốt là concurrency (độ đồng thời). Nếu bạn đặt --concurrency=80 (mặc định), một instance container sẽ xử lý tối đa 80 request đồng thời. Điều này khác hẳn về mặt bản chất so với một hàm Lambda chỉ xử lý từng request một. Khả năng xử lý nhiều request đồng thời này giảm mạnh cold start và hạ chi phí, vì một instance đã được làm nóng có thể phục vụ nhiều người dùng.
• Phân Bổ CPU: Đây là một tính năng quan trọng và thường bị hiểu lầm.
  • CPU tăng cường trong lúc xử lý request: Mặc định, một instance Cloud Run chỉ nhận toàn bộ vCPU được cấp phát (ví dụ 1 hoặc 2 vCPU) khi nó đang tích cực xử lý một request. Giữa các request, CPU của nó bị giới hạn xuống gần như bằng không. Điều này hoàn hảo cho các web API bị giới hạn bởi I/O và cực kỳ tiết kiệm chi phí.
  • CPU luôn bật: Đối với công việc nền hoặc tác vụ intensive CPU cần sức xử lý giữa các request, bạn có thể đặt cờ --cpu-allocation=always-on. Cách này tốn kém hơn (bạn phải trả tiền vCPU suốt vòng đời của instance) nhưng lại thiết yếu với một số workload.

Cloud Run vs. GKE vs. GCE: Lựa Chọn Thực Dụng

Ngừng dựng các cluster Kubernetes chỉ cho vài chục microservice. Sức kéo vận hành của việc quản lý YAML, node pool và các bản vá CVE cho kube-proxy sẽ nuốt hết chu kỳ kỹ sư vốn nên dùng để phát triển tính năng sản phẩm. Hãy bắt đầu với Cloud Run. Chỉ "tốt nghiệp" sang GKE khi bạn có thể mô tả chính xác một giới hạn ở tầng nền tảng mà bạn đã gặp phải.

Lệnh Triển Khai gcloud Cho Production

Đừng dùng giao diện web. Hãy mã hóa việc triển khai của bạn. Đây là lệnh sẵn sàng cho production mà bạn có thể đặt vào script deploy.sh.

#!/bin/bash

# A production-grade deployment command for a Cloud Run service.

PROJECT_ID="your-gcp-project-id"
SERVICE_NAME="my-api-service"
REGION="us-central1"
IMAGE="gcr.io/${PROJECT_ID}/${SERVICE_NAME}:latest"
SERVICE_ACCOUNT="my-service-sa@${PROJECT_ID}.iam.gserviceaccount.com"

gcloud run deploy "${SERVICE_NAME}" \
  --project="${PROJECT_ID}" \
  --image="${IMAGE}" \
  --region="${REGION}" \
  --platform="managed" \
  --allow-unauthenticated \
  --port=8080 \
  --timeout=300 \
  --concurrency=100 \
  --cpu=1 \
  --memory=512Mi \
  --min-instances=0 \
  --max-instances=10 \
  --service-account="${SERVICE_ACCOUNT}" \
  --set-secrets="DB_PASSWORD=my-db-secret:latest" \
  --vpc-egress="private-ranges-only" \
  --vpc-connector="projects/${PROJECT_ID}/locations/${REGION}/connectors/my-vpc-connector"

Lệnh này làm mọi thứ: đặt vùng, trỏ tới một service account cho IAM, tiêm vào một secret từ Secret Manager, và kết nối tới VPC của bạn để có egress an toàn tới cơ sở dữ liệu. Đây là chuẩn vàng.

Dữ Liệu & Phân Tích: Sức Mạnh Của BigQuery + Cloud Storage

Tài sản quý giá nhất của công ty bạn, sau con người, chính là dữ liệu. Đối xử kém với nó là một mối đe dọa mang tính tồn tại. Cách tiếp cận hiện đại cho phân tích là Lakehouse Serverless, và sự kết hợp giữa Cloud Storage và BigQuery là hiện thực hoá tốt nhất.

Cloud Storage (GCS): Đây là data lake của bạn. Nó là kho lưu trữ đối tượng có khả năng mở rộng vô hạn, cực kỳ bền bỉ (11 số 9 về độ bền) và rẻ đến mức phi lý. Bạn đổ hết dữ liệu thô vào đây: log ứng dụng, luồng sự kiện, bản export cơ sở dữ liệu, tải lên từ người dùng. Với giá khoảng $0.02 mỗi GB/tháng, lưu trữ dữ liệu còn rẻ hơn việc phải cân nhắc có nên xóa nó hay không.

BigQuery: Đây là engine truy vấn của bạn. Nó không phải là một cơ sở dữ liệu; nó là một siêu máy tính để chạy các truy vấn SQL. Sức mạnh của nó đến từ Dremel execution engine, vốn có hai đặc điểm kiến trúc then chốt:

1. Lưu Trữ Cột: Nó lưu dữ liệu theo cột chứ không phải theo hàng. Khi bạn chạy SELECT user_id, event_name FROM events, nó chỉ đọc hai cột user_id và event_name, bỏ qua mọi dữ liệu khác trên đĩa. Điều này nhanh hơn và rẻ hơn cơ sở dữ liệu dựa trên hàng hàng chục lần.
2. Thực Thi Song Song Khổng Lồ: Một truy vấn đơn lẻ được phân rã thành hàng nghìn giai đoạn nhỏ được phân bố trên một cụm worker khổng lồ nhiều người thuê. Kết quả được tổng hợp theo cấu trúc hình cây. Đây là lý do BigQuery có thể quét hàng terabyte dữ liệu trong vài giây, mà bạn không phải quản lý máy chủ nào cả.

Tầng miễn phí hào phóng đến mức đáng kinh ngạc: 1 TB dữ liệu truy vấn mỗi tháng, miễn phí. Với hầu hết startup, điều này có nghĩa là nền tảng phân tích của bạn thực tế miễn phí trong 1-2 năm đầu.

Thực Hành Tốt Nhất Về Chi Phí Và Hiệu Năng

Để sử dụng BigQuery hiệu quả, bạn phải cấu trúc bảng của mình đúng cách.

• Phân Vùng (Partitioning): Chia bảng thành các đoạn dựa trên một cột ngày hoặc số nguyên. Khi bạn truy vấn với mệnh đề WHERE trên cột phân vùng, BigQuery chỉ quét các partition liên quan.
• Phân Cụm (Clustering): Sắp xếp dữ liệu bên trong một partition theo tối đa bốn cột. Điều này đặt cạnh nhau dữ liệu liên quan, nên khi bạn lọc hoặc join trên các cột đó, BigQuery đọc ít dữ liệu hơn.

Dưới đây là câu lệnh DDL cho một bảng sự kiện có cấu trúc tốt:

CREATE TABLE my_dataset.user_events (
  event_timestamp TIMESTAMP,
  user_id STRING,
  event_name STRING,
  payload JSON
)
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_name
OPTIONS (
  description="User events partitioned by day and clustered by user/event."
);

Khi bạn chạy một truy vấn như SELECT * FROM my_dataset.user_events WHERE DATE(event_timestamp) = '2026-09-22' AND user_id = 'user-123', BigQuery sẽ đi thẳng tới partition '2026-09-22', rồi bên trong partition đó, nó sẽ đọc hiệu quả các khối chứa dữ liệu của 'user-123'. Điều này có thể giảm chi phí và thời gian truy vấn tới 99% so với một bảng không phân vùng.

Tầng AI: Vertex AI So Với Google AI Studio

AI tạo sinh đã ở lại đây, nhưng nhiều đội đang triển khai nó với một anti-pattern nguy hiểm: dùng API key được sao chép từ Google AI Studio (trước đây là MakerSuite). Tuyệt đối, tuyệt đối không bao giờ đặt API key thô trong code hay biến môi trường của bạn. Những key này thường có vòng đời dài, quá rộng quạng, và là một cơn ác mộng để xoay vòng. Nếu một cái bị rò rỉ, bạn gặp một sự cố bảo mật nghiêm trọng.

Giải pháp sẵn sàng cho production là Vertex AI. Đó là nền tảng MLOps cấp doanh nghiệp của Google, và nó cung cấp cách truy cập an toàn, do IAM kiểm soát, vào các mô hình nền tảng của Google như Gemini.

Luồng xác thực đúng đắn sử dụng Application Default Credentials (ADC).

1. Bạn tạo một IAM Service Account riêng cho ứng dụng của mình (ví dụ my-api-sa@...).
2. Bạn trao cho service account này đúng một role đặc quyền tối thiểu mà nó cần: roles/aiplatform.user.
3. Khi dịch vụ Cloud Run của bạn (hoặc pod GCE, GKE) chạy, nó tự động xác thực với tư cách service account này. Các thư viện client Google Cloud tự động lấy các thông tin xác thực đó.
4. Code của bạn gọi endpoint Vertex AI mà không cần bất kỳ key hay secret nào. IAM xử lý phần ủy quyền.

Gọi Gemini 2.5 Pro An Toàn Bằng Python

Dưới đây là code Python đúng đắn, cấp production để tương tác với mô hình Gemini từ một dịch vụ đang chạy trên GCP. Hãy chú ý sự vắng mặt hoàn toàn của API key.

import vertexai
from vertexai.generative_models import GenerativeModel

# Your project ID and location, fetched from environment or hardcoded.
PROJECT_ID = "your-gcp-project-id"
LOCATION = "us-central1"

def call_gemini():
    """
    Securely initializes the Vertex AI client and calls the Gemini 2.5 Pro model.
    This function assumes it's running in a GCP environment with a service account
    that has the 'roles/aiplatform.user' permission.
    """
    # Initialize Vertex AI. The client library automatically uses Application
    # Default Credentials (ADC) to authenticate. No API key needed.
    vertexai.init(project=PROJECT_ID, location=LOCATION)

    # Load the Gemini 2.5 Pro model
    model = GenerativeModel("gemini-2.5-pro")

    # Send a prompt to the model
    response = model.generate_content(
        "Explain the difference between Cloud Tasks and Cloud Pub/Sub "
        "from the perspective of a principal engineer."
    )

    print(response.text)

if __name__ == "__main__":
    call_gemini()

Điều này an toàn, có thể kiểm toán, và mở rộng được. Bạn có thể thu hồi quyền truy cập của service account ngay lập tức trong IAM console mà không cần triển khai lại ứng dụng.

Kiến Trúc Bất Đồng Bộ: Cloud Tasks So Với Cloud Pub/Sub

Không phải công việc nào cũng có thể xảy ra trong một request web đồng bộ. Đối với job nền, thông báo và pipeline xử lý dữ liệu, bạn cần một kiến trúc bất đồng bộ. GCP cung cấp hai dịch vụ tuyệt vời ở tầng 1 / tầng 3 cho việc này, nhưng chúng giải quyết những vấn đề khác nhau.

Dùng Cloud Tasks khi: Bạn cần thực hiện một hành động cụ thể vào thời điểm sau, hoặc cần kiểm soát tốc độ thực thi. Ví dụ: gửi email, xử lý video đã tải lên, gọi một API bên thứ ba có giới hạn tốc độ.

Dùng Cloud Pub/Sub khi: Bạn cần tách rời các dịch vụ và phản ứng với sự kiện theo thời gian thực. Một sự kiện là một tuyên bố sự thật (ví dụ user_created, order_placed). Nhiều dịch vụ downstream (phân tích, thông báo, phát hiện gian lận) đều có thể đăng ký vào cùng một topic và phản ứng độc lập. Pub/Sub dành cho kiến trúc quy mô lớn, dựa trên sự kiện. Nó phức tạp hơn khi thiết lập (subscription, pull worker) và thuộc về tầng 3 vì lý do đó. Hãy bắt đầu với Tasks.

Mổ Xẻ Hóa Đơn GCP: 5 Bẫy Rút Cạn Ngân Sách Startup

Cloud cho ta nhiều, và cloud cũng lấy đi. Không gì làm chết một startup nhanh hơn một hóa đơn cloud bất ngờ năm chữ số. Dưới đây là những thủ phạm phổ biến nhất và cách khắc phục chúng.

1. Cloud NAT (Vùng Nguy Hiểm)

• Cái bẫy: Bạn cần các dịch vụ Cloud Run trong một VPC để nói chuyện với cơ sở dữ liệu Cloud SQL. Nhưng giờ chúng cần tới một API công khai. Bạn thêm một Cloud NAT gateway. Bạn phải trả khoảng 32/tháng phí theo giờ cho mỗi gateway** *cộng thêm* **phí xử lý dữ liệu 0.045/GB. Con số này tăng rất nhanh.
• Cách khắc phục:
  • Tốt nhất: Tránh nó. Để truy cập các Google API khác, hãy bật Private Google Access trên subnet của bạn. Miễn phí.
  • Tốt: Nếu bạn thực sự cần gọi một API bên ngoài không phải của Google, hãy tạo một Cloud NAT gateway duy nhất cho toàn bộ vùng và định tuyến mọi subnet qua đó. Đừng tạo một cái cho mỗi VPC hay mỗi dịch vụ.

2. Bucket GCS Không Giới Hạn Phiên Bản

• Cái bẫy: Bạn bật phiên bản đối tượng trên một bucket để sao lưu, nhưng bạn không bao giờ cấu hình chính sách dọn dẹp. Mỗi lần ghi đè một file (ví dụ ảnh đại diện của người dùng), phiên bản cũ vẫn được giữ lại. Sau một năm, bạn đang trả tiền lưu trữ 100 phiên bản của mọi file.
• Cách khắc phục: Áp dụng một lifecycle rule cho bucket. Điều này không thể thương lượng với bất kỳ bucket có phiên bản nào.
  • Chính sách: Xóa mọi phiên bản không phải hiện hành cũ hơn 30 ngày.
  • Cấu hình (lifecycle.json):
    jsonCopy

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": {
            "numNewerVersions": 10,
            "isLive": false
          }
        },
        {
          "action": { "type": "Delete" },
          "condition": {
            "daysSinceNoncurrent": 30,
            "isLive": false
          }
        }
      ]
    }
    

  • Lệnh: gcloud storage buckets update gs://your-bucket --lifecycle-file=lifecycle.json

3. Dữ Liệu Cloud Logging Chưa Được Phân Tích (Vùng Nguy Hiểm)

• Cái bẫy: Dịch vụ của bạn đang ghi hàng nghìn dòng log debug JSON dài dòng mỗi phút. Cloud Logging vui vẻ nuốt hết với giá $0.50 mỗi GB. Chỉ một dịch vụ bị lỗi có thể tạo ra hàng terabyte log, tốn của bạn hàng trăm hay hàng nghìn đô la.
• Cách khắc phục:
  • Lọc ngay tại nguồn: Trong cấu hình logging của ứng dụng, hãy đặt mức mặc định là INFO ở production.
  • Dùng Log Sinks: Tạo một log router sink để xuất thẳng log không thiết yếu hoặc khối lượng lớn sang BigQuery (lưu trữ dài hạn rẻ, truy vấn được) hoặc Cloud Storage (lưu trữ lưu trữ). Bạn có thể tạo một bộ lọc loại trừ để ngăn log đó được nạp vào Cloud Logging ngay từ đầu. Bộ lọc ví dụ: jsonPayload.level="DEBUG".

4. Phí Egress Liên Vùng

• Cái bẫy: Dịch vụ Cloud Run của bạn ở us-central1, nhưng cơ sở dữ liệu Cloud SQL của bạn ở europe-west1. Bây giờ, mỗi byte đọc từ cơ sở dữ liệu đều phát sinh phí egress liên vùng 0.08 đến 0.12 mỗi GB. Đây là kẻ giết ngấm thầm với các ứng dụng intensive dữ liệu.
• Cách khắc phục: Đơn giản nhưng kỷ luật nghiêm ngặt: Đặt tất cả dịch vụ của bạn trong cùng một vùng. Compute, cơ sở dữ liệu và lưu trữ của bạn nên cùng nằm ở us-central1 (hoặc vùng bạn chọn). Có rất ít lý do hợp lệ để chạy kiến trúc active-active đa vùng trước khi bạn đạt quy mô khổng lồ.

5. Phí Quản Lý Cluster GKE + Node Nhàn Rỗi (Vùng Nguy Hiểm)

• Cái bẫy: Bạn dựng một cluster GKE Standard cho một dự án nhỏ. Bạn lập tức bắt đầu trả khoảng $73/tháng phí quản lý cluster. Rồi bạn tạo một node pool với máy n1-standard-2. Ngay cả khi ứng dụng của bạn không có bất kỳ lưu lượng nào, bạn vẫn phải trả tiền cho các VM đó bật 24/7.
• Cách khắc phục:
  • Tốt nhất: Dùng Cloud Run. Nó scale về 0.
  • Tốt: Nếu bắt buộc phải dùng GKE, hãy dùng GKE Autopilot. Bạn trả theo mức dùng tài nguyên của từng pod, và nó quản lý node cùng việc mở rộng thay bạn. Phí quản lý được miễn trừ cho cluster Autopilot. Nó đắt hơn theo CPU-giờ, nhưng bạn không phải trả cho công suất nhàn rỗi, khiến nó rẻ hơn nhiều với phần lớn workload.

Bản Mẫu Production: Manifest Terraform Tối Giản

Infrastructure-as-code không phải là tùy chọn. File main.tf này cung cấp một nền tảng an toàn, sẵn sàng production, sử dụng các dịch vụ tầng 1 mà chúng ta đã bàn luận.

# main.tf - A minimal, production-ready GCP setup

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

provider "google" {
  project = "your-gcp-project-id"
  region  = "us-central1"
}

# 1. Dedicated Service Account for the application
resource "google_service_account" "app_sa" {
  account_id   = "my-api-service-sa"
  display_name = "Service Account for My API"
}

# 2. A GCS bucket for application assets or data
resource "google_storage_bucket" "app_bucket" {
  name          = "my-unique-app-bucket-name-12345"
  location      = "US-CENTRAL1"
  force_destroy = false # Set to true only for dev environments

  lifecycle_rule {
    condition {
      age = 30 # days
    }
    action {
      type = "Delete"
    }
  }
}

# Grant the Service Account read/write access to the bucket (least privilege)
resource "google_storage_bucket_iam_member" "bucket_access" {
  bucket = google_storage_bucket.app_bucket.name
  role   = "roles/storage.objectAdmin"
  member = "serviceAccount:${google_service_account.app_sa.email}"
}


# 3. A secret in Secret Manager
resource "google_secret_manager_secret" "db_password" {
  secret_id = "my-db-secret"

  replication {
    automatic = true
  }
}

resource "google_secret_manager_secret_version" "db_password_version" {
  secret      = google_secret_manager_secret.db_password.id
  secret_data = "s3cure-p@ssw0rd-from-terraform-vault!"
}

# Grant the Service Account access to ONLY this specific secret
resource "google_secret_manager_secret_iam_member" "secret_access" {
  secret_id = google_secret_manager_secret.db_password.id
  role      = "roles/secretmanager.secretAccessor"
  member    = "serviceAccount:${google_service_account.app_sa.email}"
}


# 4. The Cloud Run service itself
resource "google_cloud_run_v2_service" "api_service" {
  name     = "my-api-service"
  location = "us-central1"
  
  template {
    scaling {
      min_instance_count = 0
      max_instance_count = 10
    }

    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello" # Replace with your image
      ports {
        container_port = 8080
      }
      
      env {
        name = "BUCKET_NAME"
        value = google_storage_bucket.app_bucket.name
      }
      
      volume_mounts {
        name = "secret-volume"
        mount_path = "/etc/secrets"
      }
    }
    
    volumes {
      name = "secret-volume"
      secret {
        secret = google_secret_manager_secret.db_password.secret_id
        items {
          path = "db_password"
          version = "latest"
        }
      }
    }
    
    service_account = google_service_account.app_sa.email
  }
}

# Allow public traffic to the Cloud Run service
resource "google_cloud_run_v2_service_iam_member" "public_access" {
  project  = google_cloud_run_v2_service.api_service.project
  location = google_cloud_run_v2_service.api_service.location
  name     = google_cloud_run_v2_service.api_service.name
  role     = "roles/run.invoker"
  member   = "allUsers"
}

Manifest Terraform này là bản mẫu cho một dịch vụ mạnh mẽ và an toàn. Nó tách bạch các mối quan tâm đúng cách, thực thi IAM đặc quyền tối thiểu, và cung cấp các dịch vụ tầng 1 cốt lõi.

Các Bước Tiếp Theo Hành Động & Checklist Kiến Trúc

Đọc cẩm nang này là bước đầu tiên. Nội tâm hóa và áp dụng nó mới là điều quan trọng. Dưới đây là checklist của bạn để xây dựng hệ thống thực dụng, cấp production trên GCP.

• [ ] Mặc Định Dùng Cloud Run: Với mỗi dịch vụ không trạng thái mới, hãy bắt đầu với Cloud Run. Đừng cân nhắc GKE ngay cả khi chưa có lý do cụ thể nào được ghi lại.
• [ ] Kiểm Toán Logging Của Bạn: Kiểm tra khối lượng và chi phí nạp vào Cloud Logging. Bạn có đang trả tiền để lưu log debug vô nghĩa không? Hãy thiết lập sink và bộ lọc loại trừ ngay hôm nay.
• [ ] Rà Soát Chính Sách Vòng Đời GCS: Kiểm tra mọi bucket GCS, đặc biệt là những bucket đã bật phiên bản. Đảm bảo có một lifecycle rule Delete cho các phiên bản hoặc đối tượng cũ.
• [ ] Mã Hóa Mọi Thứ Bằng Terraform: Hạ tầng của bạn phải là code. Dùng manifest được cung cấp làm điểm khởi đầu. Không click thủ công trong console cho tài nguyên production.
• [ ] Dùng Service Account Riêng: Mỗi dịch vụ Cloud Run nên có IAM service account riêng với đúng những role tối thiểu cần thiết để hoạt động.
• [ ] Ôm Lấy Lakehouse Serverless: Thiết lập một pipeline để đổ dữ liệu vận hành thô vào một bucket GCS. Dùng BigQuery với bảng phân vùng để phân tích. Đây là con đường của bạn tới một văn hóa dữ liệu dẫn dắt quyết định.
• [ ] Ở Lại Một Vùng: Trừ khi có yêu cầu pháp lý hoặc ràng buộc độ trễ, hãy đặt toàn bộ compute, lưu trữ và cơ sở dữ liệu trong một vùng duy nhất để loại bỏ chi phí egress.

Bằng cách tập trung vào lõi mạnh mẽ, tiết kiệm chi phí của GCP và chủ động tránh các vùng nguy hiểm, bạn có thể xây dựng những hệ thống không chỉ xuất sắc về mặt kỹ thuật mà còn bền vững về mặt tài chính. Kiến trúc tốt nhất thường là kiến trúc đơn giản nhất có thể hoạt động.

Kiểm tra kiến thức