Ngân hàng đề — Google Cloud Associate Cloud Engineer

Đáp án

D — App Engine.

Vì sao đúng

Đề có bốn ràng buộc, và App Engine thoả cả bốn: API chạy liên tục, tải rất thấp phần lớn thời gian, có lúc tăng đột biến, chi phí thấp và ít công quản lý.

⚠ Điểm mấu chốt — App Engine Standard co giãn tới KHÔNG:

App Engine Standard (Python 3)
        ↓
    Không có request → co về 0 instance
        ↓
    → gần như KHÔNG TỐN TIỀN khi nhàn rỗi
        ↓
    Có đợt tăng đột biến
        ↓
    → tự khởi chạy thêm instance trong vài giây
    → cold start rất nhanh với runtime Python
        ↓
    Và bạn KHÔNG quản máy chủ, không vá,
    không cấu hình load balancer

⚠ Vì sao Cloud Functions không phải lựa chọn tốt hơn ở đây:

Cloud Functions
        ↓
    Thiết kế cho MỘT HÀM phản ứng với MỘT SỰ KIỆN
        ↓
    Đề nói: "API endpoint chạy LIÊN TỤC"
        ↓
    → đây là một ứng dụng web có nhiều route
    → App Engine phù hợp hơn về mô hình
        ↓
    (Cloud Run cũng rất hợp, nhưng không
     có trong bốn phương án)

⚠ App Engine Standard ↔ Flexible:

STANDARD
        ↓
    Sandbox, runtime dựng sẵn
    Co giãn về 0, khởi động trong GIÂY
    Rẻ nhất khi tải thấp
        ↓
FLEXIBLE
        ↓
    Chạy trong container trên Compute Engine
    KHÔNG co về 0 — luôn có ít nhất 1 instance
    Khởi động chậm hơn (phút)
    → dùng khi cần thư viện hệ thống đặc thù,
      hoặc runtime tuỳ chỉnh
        ↓
    → với yêu cầu "chi phí thấp nhất" thì
      STANDARD là lựa chọn

Vì sao các phương án khác sai

• C (Cloud Functions) — đây là phương án gần nhất và cũng co giãn về 0, nhưng nó hướng tới hàm phản ứng với sự kiện, không phải một API chạy liên tục với nhiều endpoint. Về mô hình ứng dụng thì App Engine sát hơn.

• B (Kubernetes Engine) — rất nhiều công quản lý: cụm, node pool, manifest, nâng cấp. Và cụm phải chạy liên tục nên tốn tiền kể cả khi không có tải.

• A (Compute Engine) — tự quản máy hoàn toàn: vá lỗi, co giãn, cân bằng tải. Trái thẳng yêu cầu ít công quản lý.

Ghi nhớ

⚠ Bốn lựa chọn tính toán của Google Cloud — bảng phải thuộc: | Dịch vụ | Đặc điểm | |---|---| | Compute Engine | VM — bạn quản mọi thứ, linh hoạt nhất | | GKE | Kubernetes được quản lý — cho microservice phức tạp | | Cloud Run | container serverless, co về 0, trả theo request | | App Engine | PaaS — đẩy mã lên là chạy, co về 0 (Standard) | | Cloud Functions | hàm phản ứng với sự kiện | | Thứ tự công sức | Compute Engine > GKE > App Engine Flexible > Cloud Run ≈ App Engine Standard > Cloud Functions |

Từ khoá nhận diện:

"web app, ít công quản lý, co về 0" → App Engine Standard hoặc Cloud Run "phản ứng với một sự kiện" → Cloud Functions "đã có container" → Cloud Run "microservice phức tạp, cần kiểm soát" → GKE "cần cài phần mềm hệ thống đặc thù" → Compute Engine hoặc App Engine Flexible

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng đang chạy mấy instance | App Engine → Instances trên console | | Cold start mất bao lâu | Cloud Trace, hoặc log của request đầu tiên | | Chi phí thực tế | Billing report, lọc theo App Engine |

Và một cấu hình đáng cân nhắc nếu độ trễ của request đầu tiên là vấn đề: đặt min_instances bằng 1. Nó giữ một instance luôn ấm nên không còn cold start, đổi lại bạn trả tiền cho instance đó suốt ngày đêm — một đánh đổi rất đáng làm với API phục vụ người dùng thật, và không đáng với một dịch vụ nội bộ chạy vài lần mỗi ngày.

Đáp án

D — Cloud Dataproc.

Vì sao đúng

Đề có hai từ khoá quyết định: Spark đã có sẵn, và giảm công vận hành.

⚠ Điểm mấu chốt — Dataproc là Hadoop/Spark được quản lý:

Cloud Dataproc
        ↓
    Cụm Hadoop, Spark, Hive, Pig, Presto
    ĐƯỢC GOOGLE QUẢN LÝ
        ↓
    → mã Spark hiện có CHẠY GẦN NHƯ NGUYÊN VẸN
    → không phải viết lại bằng framework khác
        ↓
    Google lo: dựng cụm, cấu hình, vá lỗi
        ↓
    → đúng nghĩa "giảm công vận hành"

⚠ Và Dataproc có một đặc điểm rất hợp với việc tiết kiệm:

Cụm khởi tạo trong khoảng 90 GIÂY
        ↓
    → mô hình "CỤM PHÙ DU" (ephemeral cluster)
        ↓
    Tạo cụm → chạy job → XOÁ cụm
        ↓
    → chỉ trả tiền đúng thời gian chạy job
    → khác hẳn cụm tại chỗ phải nuôi 24/7
        ↓
    Dữ liệu để ở Cloud Storage, không để trên HDFS
    → cụm trở thành thứ vứt đi được

⚠ Vì sao không phải Dataflow:

Dataflow (Apache Beam)
        ↓
    Serverless, mạnh hơn về xử lý luồng
        ↓
    NHƯNG phải VIẾT LẠI mã bằng Beam
        ↓
    → công sức chuyển đổi lớn
    → trái yêu cầu "giảm công" của CFO
        ↓
    Dataproc là đường ngắn nhất từ
    cụm Spark tại chỗ lên cloud

Vì sao các phương án khác sai

• B (Cloud Dataflow) — đây là phương án gần nhất và về lâu dài có thể là đích đến tốt hơn (serverless hoàn toàn), nhưng nó dùng Apache Beam, nghĩa là phải viết lại toàn bộ job Spark. Với mục tiêu chuyển đổi ít tốn công nhất, Dataproc thắng rõ.

• A (Bigtable) — một CSDL NoSQL, không phải nền tảng xử lý phân tán. Không chạy job Spark.

• C (Cloud Pub/Sub) — hàng đợi tin nhắn, dùng để nhận và phân phối dữ liệu, không xử lý tính toán.

Ghi nhớ

⚠ Các dịch vụ xử lý dữ liệu — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Dataproc | Hadoop, Spark, Hive được quản lý — CHUYỂN mã có sẵn lên | | Dataflow | Apache Beam — luồng và lô, serverless, phải viết mã | | Data Fusion | ETL kéo thả, không cần mã | | BigQuery | kho dữ liệu, SQL, serverless | | Pub/Sub | hàng đợi tin nhắn | | Composer | điều phối luồng công việc (Airflow) |

Từ khoá nhận diện:

"đã có Spark / Hadoop" → Dataproc "xây mới, cần serverless, cả luồng lẫn lô" → Dataflow "ETL không viết mã" → Data Fusion "phân tích SQL trên dữ liệu lớn" → BigQuery "nhận sự kiện theo luồng" → Pub/Sub

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy thế nào | gcloud dataproc jobs list và describe | | Cụm còn sống không | gcloud dataproc clusters list | | Chi phí ra sao | Billing report, lọc Dataproc và Compute Engine |

Và một thay đổi tư duy quan trọng khi chuyển từ Hadoop tại chỗ lên Dataproc: đừng lưu dữ liệu trên HDFS của cụm. Để dữ liệu ở Cloud Storage khiến cụm trở thành thứ có thể xoá bất cứ lúc nào — và chính điều đó mở ra mô hình cụm phù du, nơi bạn ngừng trả tiền ngay khi job kết thúc thay vì nuôi một cụm nhàn rỗi suốt đêm.

Đáp án

A — INSTANCE TEMPLATE (mẫu instance).

Vì sao đúng

Managed Instance Group (MIG) bắt buộc phải dựa trên một instance template — đó là bản thiết kế để tạo ra mọi VM giống hệt nhau.

⚠ Điểm mấu chốt — template là điều kiện tiên quyết của MIG:

Instance template
        ↓
    Khai sẵn: loại máy, image nguồn, đĩa,
    mạng, network tag, service account,
    metadata (startup script)
        ↓
    → BẤT BIẾN, không sửa được sau khi tạo
        ↓
MIG dùng template đó
        ↓
    → mọi VM sinh ra đều GIỐNG HỆT NHAU
    → autoscaler thêm máy là tạo từ template
        ↓
    Không có template → không tạo được MIG

⚠ Autoscaler của MIG hoạt động thế nào:

Gắn autoscaling policy vào MIG
        ↓
    Chỉ số co giãn:
      - CPU utilization
      - HTTP load balancing utilization
      - Cloud Monitoring metric tuỳ chỉnh
      - Số message trong hàng đợi Pub/Sub
        ↓
    Khai: minNumReplicas, maxNumReplicas,
          coolDownPeriod
        ↓
    → MIG tự thêm bớt VM

⚠ MIG còn cho nhiều thứ ngoài co giãn:

AUTOHEALING
        ↓
    Health check phát hiện VM hỏng
    → TỰ TẠO LẠI VM đó
        ↓
ROLLING UPDATE
        ↓
    Đổi sang template mới, thay VM theo lô
    → có maxSurge và maxUnavailable
        ↓
REGIONAL MIG
        ↓
    Trải VM ra NHIỀU ZONE trong một Region
    → chịu được mất một zone

Vì sao các phương án khác sai

• B (Snapshot) — bản sao lưu của một persistent disk tại một thời điểm. Dùng để khôi phục hoặc tạo image, không phải thứ MIG dựa vào để tạo máy.

• C (Persistent Disk) — một đĩa lưu trữ, là thành phần của VM, không phải bản thiết kế.

• D (Shielded VM) — một tính năng bảo mật (secure boot, vTPM, integrity monitoring). Khai được trong instance template, nhưng bản thân nó không tạo ra MIG.

Ghi nhớ

⚠ Các thành phần của MIG — bảng phải thuộc: | Thành phần | Việc | |---|---| | Instance template | BẢN THIẾT KẾ — bắt buộc, BẤT BIẾN | | Managed Instance Group | quản lý một nhóm VM giống hệt nhau | | Autoscaling policy | thêm bớt VM theo chỉ số | | Health check | dùng cho autohealing và cho load balancer | | Update policy | rolling update, canary | | Regional MIG | trải nhiều zone — chịu được mất một zone |

Từ khoá nhận diện:

"tự thêm VM khi tải cao" → MIG + autoscaling policy "tự thay VM hỏng" → autohealing với health check "cập nhật không gián đoạn" → rolling update "chịu được mất một zone" → regional MIG "nhóm VM khác nhau, không co giãn" → unmanaged instance group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | MIG đang dùng template nào | gcloud compute instance-groups managed describe <ten> | | Autoscaler có hoạt động không | gcloud compute instance-groups managed describe --format="value(autoscaler)" | | VM có bị tạo lại liên tục không | Cloud Logging, tìm sự kiện autohealing |

Và một cấu hình rất nên đặt cẩn thận khi bật autohealing: initialDelaySec của health check. Nếu thời gian chờ ngắn hơn thời gian ứng dụng khởi động, MIG sẽ đánh dấu VM là hỏng và tạo lại — rồi VM mới cũng chưa kịp khởi động và lại bị tạo lại, tạo thành một vòng lặp mà từ bên ngoài trông giống hệt một sự cố hạ tầng.

Đáp án

A — Target pool THIẾU HEALTH CHECK.

Vì sao đúng

Với Network Load Balancer kiểu cũ của Google Cloud, target pool bắt buộc phải có health check thì mới biết gửi lưu lượng tới máy nào.

⚠ Điểm mấu chốt — không có health check thì không biết máy nào còn sống:

Target pool
        ↓
    Danh sách instance nhận lưu lượng
        ↓
    Health check quyết định instance nào KHOẺ
        ↓
    Không có health check
        ↓
    → load balancer không xác định được
      trạng thái backend
    → hành vi không như mong đợi
        ↓
    Đây là cấu hình bị thiếu phổ biến nhất

⚠ Target pool có vài đặc điểm riêng cần nhớ:

Chỉ dùng cho External passthrough Network LB
      (kiểu CŨ, tầng 4)
        ↓
    - Phạm vi: THEO REGION
    - Chứa instance ở NHIỀU ZONE cùng Region  ✓
      (nên phương án về hai zone không phải lỗi)
    - Health check kiểu HTTP (legacy)
    - Giữ nguyên IP nguồn của client
        ↓
    Kiểu MỚI dùng BACKEND SERVICE thay target pool
    → linh hoạt hơn, health check hiện đại hơn

⚠ Health check trong Google Cloud — dải IP phải mở:

Health check probe đến từ hai dải:
        ↓
    130.211.0.0/22
    35.191.0.0/16
        ↓
    Firewall PHẢI cho phép ingress từ hai dải này
    tới cổng health check
        ↓
    → thiếu luật này là mọi backend
      bị đánh dấu UNHEALTHY
    → và đây là nguyên nhân số hai
      sau việc thiếu hẳn health check

Vì sao các phương án khác sai

• C (không gửi chỉ số sang Cloud Monitoring) — đây là phương án gần nhất về hình thức vì cũng nói tới giám sát, nhưng chỉ số chỉ để quan sát, không quyết định việc định tuyến. Thiếu chỉ số thì bạn không nhìn thấy gì, nhưng load balancer vẫn hoạt động.

• D (không gửi log sang Cloud Logging) — cùng lý do: log là để chẩn đoán, không ảnh hưởng tới chức năng.

• B (các node có cấu hình bộ nhớ khác nhau) — target pool không yêu cầu các instance phải giống nhau về phần cứng. Máy khác cấu hình vẫn nhận lưu lượng bình thường.

Ghi nhớ

⚠ Health check của Google Cloud — bảng phải thuộc: | Nội dung | Chi tiết | |---|---| | Dải IP của probe | 130.211.0.0/22 và 35.191.0.0/16 | | Firewall | phải cho phép ingress từ hai dải đó | | Loại | HTTP, HTTPS, HTTP/2, TCP, SSL, gRPC | | Tham số | check-interval, timeout, healthy-threshold, unhealthy-threshold | | Dùng cho | load balancer và autohealing của MIG | | Legacy health check | chỉ dùng với target pool |

Từ khoá nhận diện:

"target pool không hoạt động" → thiếu health check "mọi backend đều unhealthy" → firewall chưa mở cho dải probe "tự tạo lại VM hỏng" → autohealing của MIG + health check "cần định tuyến theo URL" → backend service của HTTP(S) LB, không phải target pool "giữ IP nguồn của client" → passthrough Network LB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backend có khoẻ không | gcloud compute target-pools get-health <ten> --region=<region> | | Firewall đã mở chưa | gcloud compute firewall-rules list --filter="sourceRanges:130.211.0.0/22" | | Ứng dụng có trả 200 không | curl tới đường dẫn health check từ trong VPC |

Và một nguyên nhân chiếm phần lớn các ca "mọi backend đều unhealthy" trong Google Cloud: firewall chưa mở cho hai dải IP của health check probe. Ứng dụng chạy hoàn toàn bình thường, curl từ máy khác trong VPC vẫn trả 200, nhưng probe của Google không tới được — và triệu chứng nhìn từ console giống hệt như ứng dụng đang chết.

Đáp án

C — Cloud Functions.

Vì sao đúng

Đề mô tả đúng mô hình của Cloud Functions: phản ứng với một sự kiện, xử lý rất ngắn, và tải lúc có lúc không.

⚠ Điểm mấu chốt — kích hoạt trực tiếp từ sự kiện Cloud Storage:

Người dùng tải ảnh lên Cloud Storage
        ↓
    Sự kiện google.cloud.storage.object.v1.finalized
        ↓
    Cloud Function được gọi NGAY
        ↓
    Xử lý ảnh trong ~1 giây rồi kết thúc
        ↓
    → "phân tích ngay khi ảnh được tải lên"
      → đúng yêu cầu của đề

⚠ Và mô hình chi phí khớp hoàn hảo với tải trong đề:

Có lúc KHÔNG có ảnh nào
        ↓
    → 0 instance, KHÔNG tốn tiền
        ↓
Có lúc RẤT NHIỀU ảnh cùng lúc
        ↓
    → tự khởi chạy nhiều instance song song
    → mỗi ảnh một lần gọi hàm
        ↓
    Trả tiền theo: số lần gọi × thời gian chạy
        ↓
    → xử lý 1 giây mỗi ảnh là rất rẻ

⚠ Vì sao App Engine không hợp bằng:

App Engine
        ↓
    Thiết kế cho ỨNG DỤNG WEB phục vụ request HTTP
        ↓
    Muốn phản ứng với sự kiện Cloud Storage
      → phải thêm Pub/Sub và một endpoint
      → nhiều mảnh ghép hơn
        ↓
    Cloud Functions gắn thẳng vào sự kiện
    → ít thành phần hơn hẳn

Vì sao các phương án khác sai

• D (Cloud Run) — đây là phương án gần nhất và hoàn toàn làm được (qua Eventarc, cũng co về 0), nhưng nó đòi bạn đóng gói một container và cấu hình trigger riêng. Cloud Functions gắn thẳng vào sự kiện Cloud Storage mà không cần bước nào thêm — đơn giản hơn cho một tác vụ một giây.

• A (App Engine Standard) — hướng tới ứng dụng web, cần thêm cầu nối để nhận sự kiện lưu trữ.

• B (App Engine Flexible) — KHÔNG co về 0: luôn có ít nhất một instance chạy, nên tốn tiền trong những khoảng không có ảnh nào — trái với mô hình tải trong đề.

Ghi nhớ

⚠ Chọn dịch vụ tính toán theo mô hình kích hoạt — bảng phải thuộc: | Mô hình | Dịch vụ | |---|---| | Phản ứng với SỰ KIỆN, xử lý ngắn | Cloud Functions | | Container, HTTP hoặc sự kiện, co về 0 | Cloud Run | | Ứng dụng web nhiều route | App Engine | | Microservice phức tạp | GKE | | Cần kiểm soát hệ điều hành | Compute Engine | | Xử lý dữ liệu lớn theo luồng | Dataflow |

Từ khoá nhận diện:

"khi có tệp mới trong Cloud Storage" → Cloud Functions, hoặc Eventarc + Cloud Run "API chạy liên tục" → App Engine hoặc Cloud Run "đã có container" → Cloud Run "tải lúc có lúc không, muốn rẻ nhất" → dịch vụ co về 0 "App Engine Flexible" → KHÔNG co về 0

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có được gọi không | Cloud Logging, lọc theo tên hàm | | Xử lý mất bao lâu | chỉ số execution time trong Cloud Monitoring | | Có lỗi không | chỉ số error rate, và log của hàm |

Và một tính chất phải tính tới ngay khi viết hàm loại này: sự kiện có thể được gửi hơn một lần. Cloud Storage đảm bảo giao ít nhất một lần chứ không phải đúng một lần, nên nếu hàm ghi kết quả vào một nơi nào đó, hãy làm cho thao tác đó idempotent — chẳng hạn đặt tên tệp kết quả theo tên tệp gốc — để một ảnh được xử lý hai lần không tạo ra hai bản ghi khác nhau.

Đáp án

B — BigQuery.

Vì sao đúng

Đề có ba từ khoá: kho dữ liệu (data warehouse), ít công vận hành, và dùng được công cụ SQL sẵn có.

⚠ Điểm mấu chốt — BigQuery là kho dữ liệu serverless:

BigQuery
        ↓
    Kho dữ liệu phân tích, KHÔNG có máy chủ nào
    để bạn quản lý
        ↓
    → không dựng cụm, không chọn cỡ máy
    → không vá, không mở rộng thủ công
        ↓
    Dùng SQL CHUẨN (GoogleSQL)
        ↓
    → kết nối được qua JDBC và ODBC
    → Tableau, Looker, Power BI, dbt… đều dùng được
        ↓
    → đúng cả ba yêu cầu của đề

⚠ Kiến trúc tách biệt tính toán và lưu trữ:

Lưu trữ (Colossus, định dạng cột)
        ↓
    Trả tiền theo GB lưu
        ↓
Tính toán (slot)
        ↓
    Trả tiền theo TB quét, hoặc mua slot
        ↓
    → hai thứ độc lập
    → lưu petabyte mà chỉ trả tiền
      cho phần thực sự truy vấn

⚠ Vì sao không phải Cloud SQL:

Cloud SQL
        ↓
    CSDL GIAO DỊCH (OLTP) — MySQL, PostgreSQL, SQL Server
        ↓
    Tối ưu cho: nhiều thao tác đọc ghi nhỏ, nhanh
        ↓
    KHÔNG hợp với: quét hàng tỉ dòng để tổng hợp
        ↓
    → kho dữ liệu là bài toán PHÂN TÍCH (OLAP)
    → BigQuery mới đúng

Xem thêm câu #12488 và #12489 (cùng lô): bộ ba chọn CSDL — ở đó khoá là Cloud SQL và Bigtable. Khoá khác nhau vì bài toán khác nhau, không mâu thuẫn.

Vì sao các phương án khác sai

• D (Cloud Spanner) — đây là phương án gần nhất về khả năng SQL, nhưng Spanner là CSDL GIAO DỊCH phân tán toàn cầu, tối ưu cho OLTP quy mô lớn. Dùng nó làm kho phân tích là rất đắt và không đúng mục đích.

• C (Cloud SQL) — CSDL giao dịch theo Region, không mở rộng được cho khối lượng phân tích lớn.

• A (Bigtable) — NoSQL cột rộng, KHÔNG hỗ trợ SQL đầy đủ, không kết nối được với công cụ BI truyền thống.

Ghi nhớ

⚠ Sáu dịch vụ dữ liệu của Google Cloud — bảng phải thuộc: | Dịch vụ | Loại | Dùng khi | |---|---|---| | BigQuery | kho dữ liệu, OLAP, serverless | phân tích, báo cáo, SQL trên dữ liệu lớn | | Cloud SQL | quan hệ, OLTP, theo Region | ứng dụng thông thường, MySQL/PostgreSQL | | Cloud Spanner | quan hệ, OLTP, TOÀN CẦU | giao dịch quy mô lớn, nhiều Region | | Bigtable | NoSQL cột rộng | ghi lớn, độ trễ thấp, chuỗi thời gian, IoT | | Firestore | NoSQL tài liệu | ứng dụng web và di động | | Memorystore | Redis / Memcached | cache trong bộ nhớ |

Từ khoá nhận diện:

"data warehouse, phân tích, SQL" → BigQuery "ứng dụng giao dịch thông thường" → Cloud SQL "giao dịch, quy mô toàn cầu, nhất quán mạnh" → Cloud Spanner "HBase, IoT, chuỗi thời gian, ghi rất nhiều" → Bigtable "ứng dụng di động, đồng bộ offline" → Firestore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu | bq query --dry-run | | Ai đang tốn nhiều nhất | INFORMATION_SCHEMA.JOBS | | Bảng có partition không | bq show <dataset>.<bang> |

Và một quyết định thiết kế nên làm ngay từ ngày đầu khi chuyển kho dữ liệu sang BigQuery: phân vùng bảng theo ngày. Nó là thứ quyết định phần lớn chi phí truy vấn về sau, và thêm phân vùng cho một bảng đã có hàng terabyte dữ liệu là công việc tốn kém hơn nhiều so với việc khai đúng ngay từ lúc tạo bảng.

Đáp án

B — Cloud SQL.

Vì sao đúng

Đề có hai ràng buộc: CSDL được quản lý cho ứng dụng quản lý kho hàng, và thị trường giới hạn ở đông bắc Hoa Kỳ.

⚠ Điểm mấu chốt — quy mô KHU VỰC thì không cần CSDL toàn cầu:

Ứng dụng quản lý kho hàng
        ↓
    Là ứng dụng GIAO DỊCH (OLTP) điển hình:
      đọc ghi nhiều bản ghi nhỏ,
      cần khoá ngoại, giao dịch, chỉ mục
        ↓
    → CSDL QUAN HỆ
        ↓
    Thị trường chỉ một khu vực
        ↓
    → KHÔNG cần phân tán toàn cầu
    → Cloud SQL là đủ, và RẺ HƠN NHIỀU

⚠ Cloud SQL cho gì:

MySQL, PostgreSQL, SQL Server được quản lý
        ↓
    Google lo: vá lỗi, sao lưu tự động,
    nhân bản, chuyển đổi khi sự cố
        ↓
    Tính năng sẵn sàng cao:
      - HA với standby ở zone khác
      - Read replica (kể cả cross-Region)
      - Point-in-time recovery
      - Sao lưu tự động
        ↓
    → đủ cho gần như mọi ứng dụng cấp doanh nghiệp
      ở quy mô một khu vực

⚠ Vì sao Cloud Spanner là quá mức cần thiết:

Cloud Spanner
        ↓
    SQL + giao dịch + nhất quán mạnh
    + mở rộng ngang TOÀN CẦU
        ↓
    Nhưng: chi phí tối thiểu CAO HƠN NHIỀU
      (tính theo node hoặc processing unit)
        ↓
    Đề nói rõ: thị trường một khu vực
        ↓
    → dùng Spanner là trả tiền cho khả năng
      không bao giờ dùng tới

Xem thêm câu #12487 và #12489 (cùng lô): bộ ba chọn CSDL — ở đó khoá là BigQuery (phân tích) và Bigtable (NoSQL ghi lớn). Khoá khác nhau vì bài toán khác nhau.

Vì sao các phương án khác sai

• C (Cloud Spanner) — đây là phương án gần nhất và hoàn toàn làm được, nhưng nó là giải pháp quá mức: chi phí tối thiểu cao hơn Cloud SQL rất nhiều, đổi lại một khả năng phân tán toàn cầu mà bài toán trong đề không cần.

• A (Bigtable) — NoSQL, không có giao dịch nhiều dòng, không có SQL đầy đủ. Không hợp với ứng dụng quản lý kho hàng.

• D (Cloud Dataproc) — nền tảng Hadoop/Spark, không phải CSDL.

Ghi nhớ

⚠ Cloud SQL ↔ Cloud Spanner — bảng phải thuộc: | | Cloud SQL | Cloud Spanner | |---|---|---| | Động cơ | MySQL, PostgreSQL, SQL Server | riêng của Google, tương thích GoogleSQL và PostgreSQL | | Mở rộng | DỌC (đổi cỡ máy) + read replica | NGANG, không giới hạn | | Phạm vi | theo Region | nhiều Region, toàn cầu | | Chi phí tối thiểu | thấp | cao hơn nhiều | | Nhất quán | mạnh trong một instance | mạnh TOÀN CẦU | | Dùng khi | hầu hết ứng dụng thông thường | quy mô rất lớn, nhiều Region |

Từ khoá nhận diện:

"CSDL quan hệ, quy mô khu vực" → Cloud SQL "giao dịch toàn cầu, nhất quán mạnh" → Cloud Spanner "phân tích, kho dữ liệu" → BigQuery "NoSQL ghi rất nhiều, độ trễ thấp" → Bigtable "cần MySQL/PostgreSQL y như đang dùng" → Cloud SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có bật HA không | gcloud sql instances describe <ten> → availabilityType | | Có IP công cộng không | cùng lệnh, xem ipConfiguration | | Sao lưu có chạy không | gcloud sql backups list --instance=<ten> |

Và một nguyên tắc rất đáng theo khi chọn CSDL: bắt đầu từ lựa chọn đơn giản nhất đủ dùng. Cloud SQL phục vụ tốt phần lớn ứng dụng doanh nghiệp, và việc chuyển sang Spanner sau này khi thật sự chạm trần vẫn khả thi — trong khi chọn Spanner ngay từ đầu cho một thị trường một khu vực là một khoản chi phí cố định rất khó biện minh.

Đáp án

A — Bigtable.

Vì sao đúng

Đề có ba dấu hiệu, và cả ba đều chỉ thẳng về Bigtable: dữ liệu cảm biến IoT, ghi khối lượng lớn với độ trễ thấp, và đang dùng HBase.

⚠ Điểm mấu chốt — Bigtable tương thích API với HBase:

Đội đang dùng HBase
        ↓
    Bigtable có HBASE CLIENT LIBRARY
        ↓
    → mã ứng dụng chuyển sang gần như nguyên vẹn
    → chỉ đổi thư viện kết nối
        ↓
    Và Bigtable là DỊCH VỤ ĐƯỢC QUẢN LÝ
        ↓
    → đúng yêu cầu "chuyển sang managed service"

⚠ Và đặc tính kỹ thuật khớp hoàn hảo với IoT:

Dữ liệu cảm biến từ xe
        ↓
    - Khối lượng GHI rất lớn, liên tục
    - Cần độ trễ THẤP (mili giây một chữ số)
    - Dữ liệu CHUỖI THỜI GIAN
        ↓
Bigtable
        ↓
    - Thông lượng ghi rất cao, mở rộng ngang
      bằng cách thêm node
    - Độ trễ ổn định ở mili giây
    - Thiết kế riêng cho chuỗi thời gian
        ↓
    → đây là trường hợp sử dụng kinh điển

⚠ Nhưng thiết kế ROW KEY quyết định tất cả:

Bigtable CHỈ có MỘT chỉ mục: row key
        ↓
    Row key sắp xếp theo thứ tự từ điển
        ↓
    Row key bắt đầu bằng DẤU THỜI GIAN
        ↓
    → mọi lượt ghi dồn vào MỘT node
    → gọi là HOTSPOT
    → thông lượng sụp đổ
        ↓
    Mẫu đúng cho IoT:
      <ma-thiet-bi>#<dau-thoi-gian>
      hoặc thêm tiền tố băm để trải đều

Xem thêm câu #12487 và #12488 (cùng lô): bộ ba chọn CSDL — ở đó khoá là BigQuery (phân tích) và Cloud SQL (quan hệ, khu vực). Khoá khác nhau vì ràng buộc khác nhau.

Vì sao các phương án khác sai

• B (BigQuery) — đây là phương án gần nhất vì cũng xử lý được dữ liệu rất lớn, nhưng BigQuery là kho PHÂN TÍCH: nó tối ưu cho truy vấn quét lớn, không cho ghi từng bản ghi với độ trễ mili giây. (Mô hình rất phổ biến là Bigtable để ghi và đọc nóng, rồi đẩy sang BigQuery để phân tích.)

• C (Cloud Spanner) — CSDL quan hệ có giao dịch, chi phí cao hơn nhiều và không tối ưu cho khối lượng ghi chuỗi thời gian như Bigtable.

• D (Cloud Dataproc) — nền tảng xử lý Hadoop/Spark, không phải CSDL.

Ghi nhớ

⚠ Bigtable — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Loại | NoSQL cột rộng, được quản lý | | Tương thích | HBase API | | Chỉ mục | CHỈ có ROW KEY — không có chỉ mục phụ | | Độ trễ | mili giây một chữ số | | Mở rộng | thêm node, thông lượng tăng tuyến tính | | Không có | giao dịch nhiều dòng, SQL đầy đủ, join | | Dùng cho | IoT, chuỗi thời gian, dữ liệu tài chính, cá nhân hoá, đồ thị |

Từ khoá nhận diện:

"HBase, IoT, chuỗi thời gian, ghi rất nhiều" → Bigtable "phân tích, SQL, báo cáo" → BigQuery "giao dịch quan hệ" → Cloud SQL hoặc Spanner "ứng dụng di động, đồng bộ offline" → Firestore "cache trong bộ nhớ" → Memorystore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có hotspot không | Key Visualizer trong console Bigtable | | Node có đủ không | chỉ số CPU utilization — nên dưới 70% | | Độ trễ thực tế | chỉ số read/write latency trong Cloud Monitoring |

Và một việc đáng làm ngay từ giai đoạn thiết kế, trước cả khi ghi dòng dữ liệu đầu tiên: vẽ ra vài mẫu row key rồi kiểm tra chúng bằng Key Visualizer trên dữ liệu thử. Row key là thứ không đổi được sau khi đã có dữ liệu, và một thiết kế sai sẽ giới hạn thông lượng của cả cụm bất kể bạn thêm bao nhiêu node.

Đáp án

C — Dùng HAI NODE POOL, một pool có CPU và bộ nhớ lớn hơn pool kia.

Vì sao đúng

Trong Kubernetes, loại máy là thuộc tính của NODE, nên muốn hai nhóm tải chạy trên phần cứng khác nhau thì phải có hai node pool.

⚠ Điểm mấu chốt — pod không tự chọn được phần cứng:

Pod khai `resources.requests`
        ↓
    Scheduler tìm NODE có đủ tài nguyên
        ↓
    Nhưng mọi node trong MỘT node pool
    đều CÙNG loại máy
        ↓
    → muốn có máy mạnh cho training
      và máy nhỏ cho prediction
    → phải tạo HAI NODE POOL

⚠ Và điều hướng pod về đúng pool bằng ba cơ chế:

1. nodeSelector (đơn giản nhất)
        ↓
    Node pool có nhãn tự động:
      cloud.google.com/gke-nodepool: <ten-pool>
        ↓
    Pod khai nodeSelector trỏ tới nhãn đó

2. Node affinity (linh hoạt hơn)
        ↓
    requiredDuringScheduling… → bắt buộc
    preferredDuringScheduling… → ưu tiên

3. TAINT và TOLERATION (chặt nhất)
        ↓
    Gắn taint lên node pool đắt tiền
        ↓
    → chỉ pod có toleration tương ứng
      mới được xếp lên đó
    → NGĂN pod khác vô tình chiếm chỗ

⚠ Cấu hình thực tế cho bài toán của đề:

Node pool "training"
        ↓
    Máy nhiều CPU và RAM (hoặc có GPU)
    Taint: workload=training:NoSchedule
    Autoscaling: min 0, max N
        ↓
    → min=0 nghĩa là KHÔNG có job thì
      KHÔNG TỐN TIỀN

Node pool "prediction"
        ↓
    Máy nhỏ hơn, min 2 để luôn sẵn sàng
        ↓
Pod training khai toleration + nodeSelector
Pod prediction không khai gì → vào pool mặc định

Vì sao các phương án khác sai

• A (dùng nhiều pod, một số cấu hình nhiều CPU và bộ nhớ hơn) — đây là phương án gần nhất và đúng ở chỗ pod khai requests khác nhau, nhưng nếu mọi node đều cùng một cỡ thì pod training không có node nào đủ lớn để chạy — nó sẽ nằm mãi ở trạng thái Pending.

• B (tăng số deployment cho tiến trình training) — thêm bản sao không đổi được loại phần cứng mà chúng chạy trên đó.

• D (tăng số replica set) — cùng lý do như B: nhiều bản sao hơn, vẫn cùng một loại node.

Ghi nhớ

⚠ Ba cách điều hướng pod về node — bảng phải thuộc: | Cơ chế | Đặc điểm | |---|---| | nodeSelector | đơn giản nhất — khớp nhãn của node | | Node affinity | linh hoạt hơn — bắt buộc hoặc ưu tiên, có biểu thức | | Taint và Toleration | NGĂN pod không đủ điều kiện xếp lên node | | Pod affinity / anti-affinity | xếp pod gần hoặc xa pod khác | | Kết hợp mạnh nhất | taint trên node pool + toleration và nodeSelector trên pod |

Từ khoá nhận diện:

"tải cần phần cứng khác nhau" → nhiều node pool "chỉ pod này được chạy trên node đắt tiền" → taint và toleration "trải pod ra nhiều node" → pod anti-affinity "cần GPU" → node pool riêng có GPU, và taint tự động "không muốn quản node nào" → GKE Autopilot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những node pool nào | gcloud container node-pools list --cluster=<ten> | | Pod chạy trên node nào | kubectl get pods -o wide | | Vì sao pod Pending | kubectl describe pod <ten> |

Và một cấu hình rất đáng dùng cho node pool phục vụ training: autoscaling với min-nodes=0. Máy nhiều CPU hoặc có GPU rất đắt, và với một tải chỉ chạy vài giờ mỗi ngày thì một pool co về 0 sẽ tiết kiệm phần lớn chi phí — trong khi pod prediction vẫn chạy liên tục trên pool nhỏ hơn mà không bị ảnh hưởng.

Đáp án

C — Cloud Dataproc.

Vì sao đúng

Hai từ khoá quyết định: đã có cụm Hadoop, và giảm công vận hành.

⚠ Điểm mấu chốt — Dataproc là Hadoop được quản lý:

Cloud Dataproc
        ↓
    Cụm Hadoop, Spark, Hive, Pig, Presto
    do Google quản lý
        ↓
    → job và cấu hình hiện có CHẠY GẦN NHƯ NGUYÊN VẸN
    → không phải viết lại bằng framework khác
        ↓
    Google lo: dựng cụm, cấu hình, vá lỗi
        ↓
    → đường ngắn nhất từ cụm tại chỗ lên cloud

⚠ Và mô hình cụm phù du giúp tiết kiệm mạnh:

Cụm khởi tạo trong khoảng 90 giây
        ↓
    Tạo cụm → chạy job → XOÁ cụm
        ↓
    Dữ liệu để ở Cloud Storage, không ở HDFS
        ↓
    → chỉ trả tiền đúng thời gian chạy
    → khác hẳn cụm tại chỗ nuôi 24/7

Xem thêm câu #12483 (CÙNG LÔ): cùng một câu hỏi, cùng đáp án Cloud Dataproc. Chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là D, ở đây là C). Khoá nhất quán.

Vì sao các phương án khác sai

• A (Cloud Dataflow) — đây là phương án gần nhất và về lâu dài có thể là đích đến tốt hơn, nhưng nó dùng Apache Beam, nghĩa là phải viết lại toàn bộ job Hadoop. Trái yêu cầu giảm công.

• B (Cloud Pub/Sub) — hàng đợi tin nhắn, không xử lý tính toán.

• D (Bigtable) — CSDL NoSQL, không phải nền tảng xử lý phân tán.

Ghi nhớ

⚠ Các dịch vụ xử lý dữ liệu — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Dataproc | Hadoop, Spark, Hive được quản lý — CHUYỂN mã có sẵn | | Dataflow | Apache Beam — luồng và lô, serverless, phải viết mã | | Data Fusion | ETL kéo thả, không cần mã | | BigQuery | kho dữ liệu, SQL, serverless | | Pub/Sub | hàng đợi tin nhắn | | Composer | điều phối luồng công việc (Airflow) |

Từ khoá nhận diện:

"đã có Hadoop / Spark" → Dataproc "xây mới, serverless" → Dataflow "ETL không viết mã" → Data Fusion "phân tích SQL dữ liệu lớn" → BigQuery "Dataproc Serverless" → chạy job Spark mà không tạo cụm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job chạy thế nào | gcloud dataproc jobs list | | Cụm còn sống không | gcloud dataproc clusters list | | Chi phí ra sao | Billing report, lọc Dataproc |

Và một thay đổi tư duy quan trọng khi lên Dataproc: đừng lưu dữ liệu trên HDFS của cụm. Để dữ liệu ở Cloud Storage khiến cụm trở thành thứ xoá được bất cứ lúc nào — nền tảng của mô hình cụm phù du.