Phân Tích Chuyên Sâu Toàn Bộ Các Dịch Vụ Serverless của Google Cloud Platform cho Kỳ Thi ACE

Mục Lục (Dự kiến):

Giới Thiệu về Serverless:
- Serverless là gì?
- Tại sao Serverless lại quan trọng? Các vấn đề Serverless giải quyết.
- Đặc điểm cốt lõi của kiến trúc Serverless.
- Serverless khác gì so với IaaS, PaaS, Containers truyền thống?
- Lợi ích và thách thức của Serverless.
- Serverless trong bối cảnh Google Cloud.
- Serverless cho kỳ thi ACE: Tại sao bạn cần nắm vững nó?
Các Dịch Vụ Serverless Compute (Tính toán) Chủ Đạo:
- Google Cloud Functions (GCF):
  - Tổng quan: Function-as-a-Service (FaaS).
  - Kiến trúc và cách hoạt động: Event-driven (Kiến trúc hướng sự kiện).
  - Các loại Trigger (Kích hoạt):
    - HTTP Triggers (Kích hoạt qua HTTP).
    - Background Triggers (Kích hoạt ngầm) từ các dịch vụ khác (Cloud Storage, Pub/Sub, Firestore, BigQuery, Audit Logs, v.v.).
    - Trigger từ Eventarc.
  - Môi trường thực thi (Runtime): Node.js, Python, Go, Java, .NET, Ruby, PHP.
  - Quản lý vòng đời và Triển khai: Mã nguồn, cấu hình, gcloud functions, Cloud Console.
  - Scaling (Tự động co giãn): Tự động dựa trên số lượng sự kiện/yêu cầu. Khái niệm Concurrency (đồng thời). Cold Start (Khởi động nguội) và tác động.
  - Pricing (Mô hình tính cước): Theo số lượng lời gọi, thời gian thực thi, bộ nhớ, network egress.
  - Use Cases (Trường hợp sử dụng điển hình): Webhooks, xử lý dữ liệu luồng, tác vụ nền, APIs đơn giản, tích hợp dịch vụ.
  - Bảo mật (Security): IAM Permissions, Service Accounts, VPC Connector (truy cập tài nguyên trong VPC).
  - Giám sát và Ghi log (Monitoring & Logging): Cloud Monitoring, Cloud Logging.
  - Ưu điểm và nhược điểm.
  - So sánh sơ bộ với Cloud Run và App Engine Standard.
  - ACE Focus: Khi nào dùng Cloud Functions? Hiểu rõ các loại trigger. Cấu hình cơ bản. Kết nối mạng (VPC Connector).
- Google Cloud Run:
  - Tổng quan: Serverless Containers (Container không máy chủ). Chạy stateless container qua HTTP.
  - Kiến trúc và cách hoạt động: Nhận HTTP requests, triển khai container từ image.
  - Triển khai: Container Image (Dockerfile), Cloud Build, Artifact Registry/Container Registry, gcloud run deploy, Cloud Console.
  - Scaling (Tự động co giãn): Tự động dựa trên số lượng request. Cấu hình Minimum/Maximum instances. Concurrency (Đồng thời xử lý request trên một instance). Tối ưu Cold Start.
  - Pricing (Mô hình tính cước): Theo số lượng request, thời gian CPU/memory được cấp phát.
  - Use Cases (Trường hợp sử dụng điển hình): Microservices, APIs, Web applications, containerized batch jobs qua HTTP.
  - Deep Dive: Yêu cầu Stateless. Mapping Custom Domains. Traffic Splitting (chia lưu lượng). Các bản revision. Service-to-Service Authentication.
  - Bảo mật (Security): IAM Permissions, Service Accounts, VPC Connector, Ingress settings.
  - Giám sát và Ghi log (Monitoring & Logging): Cloud Monitoring, Cloud Logging, Cloud Trace.
  - Ưu điểm và nhược điểm.
  - So sánh chi tiết với Cloud Functions và App Engine Standard.
  - ACE Focus: Khi nào dùng Cloud Run? Hiểu về container và stateless. Cấu hình scaling, concurrency, domains, traffic splitting. Kết nối mạng (VPC Connector). Bảo mật ingress/auth.
- Google App Engine Standard Environment (GAE Standard):
  - Tổng quan: Platform-as-a-Service (PaaS) ban đầu của Google, có môi trường Standard Serverless.
  - Kiến trúc và cách hoạt động: Triển khai code trên các runtime được quản lý (Managed Runtimes). Google quản lý hoàn toàn hạ tầng. Sandboxing.
  - Các Runtime được hỗ trợ: Python 2/3, Java 8/11, Node.js, PHP 5/7/8, Go 1.11+, Ruby 2.5+.
  - Triển khai: app.yaml configuration file, gcloud app deploy.
  - Scaling (Tự động co giãn): Tự động (Automatic scaling), cơ bản (Basic scaling - ít serverless hơn), thủ công (Manual scaling - không serverless). Tập trung vào Automatic scaling. Instance classes.
  - Pricing (Mô hình tính cước): Theo instance hour (Frontend/Backend), network, storage.
  - Use Cases (Trường hợp sử dụng điển hình): Web applications truyền thống, Mobile Backends.
  - Deep Dive: app.yaml chi tiết (handler, scaling config, env variables). Sandboxing limitations (filesystem, background threads). Services (Microservices trong App Engine). Versioning và Traffic Splitting. Cron Service. Task Queues (đã cũ, thay bằng Cloud Tasks).
  - Bảo mật (Security): IAM, Service Accounts, Firewall Rules, Access Control.
  - Giám sát và Ghi log (Monitoring & Logging): Cloud Monitoring, Cloud Logging.
  - Ưu điểm và nhược điểm (đặc biệt so với App Engine Flex).
  - ACE Focus: Khi nào dùng App Engine Standard? Hiểu app.yaml, cấu hình scaling (automatic), versioning/traffic splitting. Limitations của Standard env. So sánh với Functions/Run.
Các Dịch Vụ Serverless khác hỗ trợ Compute:
- Workflows:
  - Tổng quan: Managed orchestration service.
  - Cách hoạt động: Định nghĩa chuỗi các bước thực thi (YAML/JSON). Gọi các dịch vụ khác (Cloud Functions, Cloud Run, các API của GCP, API bên ngoài).
  - Use Cases: Tổ chức các luồng công việc phức tạp, tự động hóa, ETL nhẹ.
  - ACE Focus: Vai trò của Workflows trong kiến trúc Serverless (kết nối các services), không cần quản lý máy chủ cho orchestration logic.
- Eventarc:
  - Tổng quan: Serverless eventing bus (kênh sự kiện không máy chủ).
  - Cách hoạt động: Nhận sự kiện từ nhiều nguồn GCP và gửi đến các đích (sinks) như Cloud Functions, Cloud Run, GKE, Workflows. Sử dụng Pub/Sub nội bộ.
  - Use Cases: Xây dựng kiến trúc hướng sự kiện (event-driven architecture) mạnh mẽ, decoupling (tách rời) các thành phần.
  - ACE Focus: Vai trò của Eventarc trong việc kết nối các dịch vụ serverless, đảm bảo sự kiện được gửi đáng tin cậy.
Các Dịch Vụ Serverless Data & Messaging:
- Cloud Firestore:
  - Tổng quan: Serverless, NoSQL Document database.
  - Cách hoạt động: Dữ liệu được tổ chức theo Collections và Documents. Hỗ trợ Subcollections. Real-time updates.
  - Pricing: Theo số lượng reads/writes/deletes, storage, network.
  - Use Cases: Web/Mobile app backends, profile storage, game state, real-time data synchronization.
  - Deep Dive: Data Model chi tiết. Querying (Indexes, limitations). Security Rules (kiểm soát truy cập từ client-side). Consistency Model. Chế độ Native (Datastore mode) và khác biệt.
  - ACE Focus: Hiểu về NoSQL, Document Model, khi nào chọn Firestore, Security Rules (concept), tích hợp với Functions/Run.
- Cloud Pub/Sub:
  - Tổng quan: Serverless Messaging Service.
  - Cách hoạt động: Publish/Subscribe pattern. Topics và Subscriptions. Đảm bảo tin nhắn được gửi (at-least-once delivery).
  - Subscription Types: Pull và Push.
  - Pricing: Theo dung lượng tin nhắn được xử lý, storage cho tin nhắn chưa được xác nhận.
  - Use Cases: Decoupling services, data ingestion/streaming, asynchronous communication, event-driven systems (vai trò là trigger cho Functions/Run).
  - Deep Dive: Pull vs. Push Subscriptions chi tiết (Push rất quan trọng với Serverless Compute). Dead-letter topics. Message retention.
  - ACE Focus: Vai trò trung tâm trong kiến trúc hướng sự kiện, trigger cho serverless compute, hiểu Pull/Push, at-least-once delivery.
- Cloud Storage:
  - Tổng quan: Serverless Object Storage.
  - Cách hoạt động: Lưu trữ đối tượng (file) trong buckets. Class lưu trữ khác nhau (Standard, Nearline, Coldline, Archive).
  - Pricing: Theo storage capacity, network egress, operation costs.
  - Use Cases: Lưu trữ bất kỳ loại file nào (hình ảnh, video, backup, log), Data Lake, static website hosting.
  - ACE Focus: Vai trò là nguồn dữ liệu/trigger cho Cloud Functions (khi file được upload/xóa), nơi lưu trữ output của serverless process. Mặc dù không phải "ứng dụng" serverless, nó là thành phần serverless cốt lõi.
- BigQuery:
  - Tổng quan: Serverless Data Warehouse.
  - Cách hoạt động: Chạy query (SQL) trên tập dữ liệu rất lớn mà không cần quản lý hạ tầng. Tự động scaling.
  - Pricing: Theo dung lượng dữ liệu được quét khi chạy query, dung lượng lưu trữ.
  - Use Cases: Phân tích dữ liệu lớn, Business Intelligence, Data Science.
  - ACE Focus: Hiểu rằng BigQuery là serverless cho phân tích, thường là đích đến của dữ liệu được xử lý bởi các dịch vụ serverless khác (ví dụ: Functions/Run xử lý dữ liệu rồi đưa vào BigQuery).
Tích Hợp Các Dịch Vụ Serverless (Kiến trúc Serverless điển hình):
- Ví dụ kiến trúc:
  - Xử lý ảnh tự động (Cloud Storage -> Cloud Functions -> Cloud Storage).
  - Xây dựng API Microservices (Cloud Run -> Firestore/Pub/Sub).
  - Web application với backend serverless (App Engine Standard / Cloud Run -> Firestore/Pub/Sub).
  - Xử lý luồng dữ liệu (Dataflow/Pub/Sub -> Cloud Functions/Cloud Run -> BigQuery/Firestore).
  - Orchestration (Workflows gọi Functions/Run/APIs).
  - Event-Driven Pipelines (Source -> Eventarc -> Sink).
Bảo Mật trong Serverless (Tập trung vào ACE):
- IAM (Identity and Access Management): Kiểm soát ai có quyền làm gì với dịch vụ serverless (invoker, developer, admin roles).
- Service Accounts: Danh tính cho ứng dụng serverless khi gọi các dịch vụ GCP khác hoặc API bên ngoài. Cấp quyền tối thiểu cần thiết.
- VPC Connector (Serverless VPC Access): Cho phép các dịch vụ serverless (Functions, Run, Workflows, App Engine Standard) truy cập tài nguyên trong VPC (ví dụ: Compute Engine, Cloud SQL, Memorystore) bằng địa chỉ IP nội bộ. Cực kỳ quan trọng cho ACE.
- Identity Platform / Firebase Authentication: Quản lý người dùng cuối cho ứng dụng (thường dùng với Cloud Run/App Engine/Firestore).
- Security Rules (Firestore, Firebase Storage): Kiểm soát truy cập dữ liệu trực tiếp từ client.
Giám Sát và Ghi log Serverless (Tập trung vào ACE):
- Cloud Logging: Xem log từ các dịch vụ serverless (request logs, application logs). Tìm kiếm, filter log.
- Cloud Monitoring: Xem metrics (số lần gọi, thời gian thực thi, lỗi, số instance, độ trễ). Tạo dashboards, alerting.
- Cloud Trace (cho Cloud Run/App Engine): Theo dõi đường đi của request qua các dịch vụ.
Lựa Chọn Dịch Vụ Serverless Phù Hợp (ACE Perspective):
- Tổng kết so sánh Functions vs. Run vs. App Engine Standard.
- Flowchart đơn giản giúp quyết định.
- Đánh giá dựa trên: Use Case, ngôn ngữ/framework, statelessness, scaling needs, cold start tolerance, mức độ quản lý cần thiết, tích hợp hệ sinh thái hiện có.
Tips Chuẩn Bị Cho Kỳ Thi ACE với Serverless:
- Tập trung vào "Use Cases": Hiểu rõ khi nào sử dụng dịch vụ nào. Đây là phần lớn câu hỏi thực tế của ACE.
- Nắm vững sự khác biệt giữa các dịch vụ Compute (Functions, Run, GAE Standard).
- Hiểu cách các dịch vụ Serverless tích hợp với nhau và với các dịch vụ GCP khác (Pub/Sub, Firestore, Cloud Storage, VPC).
- Thực hành: Sử dụng Qwiklabs/Cloud Skills Boost để triển khai thử các kiến trúc serverless đơn giản.
- Đọc Documentation chính thức: Đây là nguồn tài nguyên tốt nhất.
- Hiểu các khái niệm: Event-driven, Stateless, Cold Start, Concurrency, IAM, VPC Connector.
- Ôn tập các câu hỏi mẫu.
Kết luận và Hướng đi tiếp theo.
Phần 1: Giới Thiệu về Serverless

Chào mừng bạn đến với thế giới Serverless! Đây là một khái niệm đã thay đổi cách chúng ta nghĩ về việc xây dựng và vận hành ứng dụng trên đám mây.

1.1. Serverless là gì?

Nếu dịch sát nghĩa, "Serverless" có nghĩa là "không máy chủ". Nghe có vẻ hơi lạ đúng không? Làm sao chạy ứng dụng mà không cần máy chủ? Thực tế, Serverless không có nghĩa là không có máy chủ vật lý nào cả. Máy chủ vẫn tồn tại, nhưng điều quan trọng là bạn (người phát triển/vận hành) không cần phải trực tiếp quản lý, cấu hình, bảo trì hay lo lắng về hạ tầng máy chủ đó nữa.

Hãy tưởng tượng thế này:

Cách truyền thống (On-premises hoặc IaaS như Compute Engine VM): Giống như bạn muốn mở một nhà hàng. Bạn phải mua đất, xây nhà bếp, mua lò nướng, tủ lạnh, bàn ghế, thuê đầu bếp, nhân viên phục vụ... Bạn chịu trách nhiệm về mọi thứ, từ việc sửa ống nước, kiểm tra hệ thống điện đến việc đảm bảo luôn có đủ nguyên liệu và nhân viên. Bạn có toàn quyền kiểm soát, nhưng cũng chịu toàn bộ gánh nặng vận hành.
Serverless: Giống như bạn sử dụng dịch vụ đặt đồ ăn trực tuyến (ví dụ: GrabFood, Now/ShopeeFood). Bạn chỉ cần tập trung vào việc chọn món, đặt hàng và thưởng thức. Bạn không cần biết nhà hàng đó thuê bao nhiêu đầu bếp, dùng loại bếp nào, hay lo lắng về hóa đơn tiền điện của họ. Bạn chỉ trả tiền cho món bạn ăn. Bạn không quản lý nhà hàng, bạn chỉ sử dụng dịch vụ nhà hàng cung cấp.

Trong thế giới đám mây, Serverless có nghĩa là bạn viết mã (code) hoặc đóng gói ứng dụng của mình, đưa lên nền tảng đám mây, và nền tảng đó sẽ lo mọi thứ còn lại:

Cấp phát tài nguyên máy chủ khi cần.
Tự động co giãn (scaling) ứng dụng của bạn lên hoặc xuống dựa trên lưu lượng truy cập hoặc số lượng sự kiện.
Đảm bảo ứng dụng luôn khả dụng (highly available) mà không cần cấu hình phức tạp.
Quản lý hệ điều hành, patching, bảo mật hạ tầng cơ bản.
Bạn chỉ trả tiền cho tài nguyên bạn thực sự sử dụng (lời gọi hàm, thời gian xử lý, dung lượng lưu trữ, v.v.), thường tính theo từng request hoặc từng mili giây.

1.2. Tại sao Serverless lại quan trọng? Các vấn đề Serverless giải quyết.

Serverless trở nên quan trọng bởi nó giải quyết được nhiều vấn đề mà các kiến trúc truyền thống gặp phải, đặc biệt là:

Gánh nặng vận hành (Operational Overhead): Quản lý máy chủ (cài đặt OS, cập nhật bảo mật, quản lý patch, cấu hình mạng, dự đoán tải, mở rộng...) tốn rất nhiều thời gian, công sức và nhân lực. Serverless loại bỏ hoặc giảm thiểu đáng kể gánh nặng này, cho phép đội ngũ tập trung vào việc phát triển tính năng ứng dụng.
Hiệu quả chi phí (Cost Efficiency): Với mô hình thanh toán Pay-per-Use (trả tiền theo mức sử dụng thực tế), bạn không phải trả tiền cho máy chủ nhàn rỗi (idle). Nếu ứng dụng không có request/sự kiện nào, chi phí có thể bằng 0 hoặc rất thấp. Điều này khác với việc thuê một máy chủ ảo (VM) chạy 24/7 dù chỉ xử lý lúc có traffic.
Khả năng co giãn tự động (Automatic Scaling): Xử lý tải tăng đột ngột là một thách thức lớn. Serverless platforms được thiết kế để tự động co giãn từ 0 đến hàng ngàn hoặc hàng triệu instance/lời gọi trong tích tắc khi cần, mà không cần bạn can thiệp thủ công hay dự đoán trước.
Thời gian phát triển nhanh hơn (Faster Time to Market): Khi không phải lo về hạ tầng, đội ngũ phát triển có thể tập trung hoàn toàn vào việc viết code xử lý logic nghiệp vụ, giúp đưa sản phẩm ra thị trường nhanh hơn.
Tính sẵn sàng cao (High Availability): Các nền tảng Serverless thường được xây dựng để có tính sẵn sàng cao trên nhiều khu vực/zone mà bạn không cần phải cấu hình phức tạp về load balancing hay failover ở tầng hạ tầng.

1.3. Đặc điểm cốt lõi của kiến trúc Serverless.

No Server Management: Đây là đặc điểm định danh. Bạn không SSH vào máy chủ, không cấu hình OS, không quản lý cluster.
Automatic Scaling: Nền tảng tự động điều chỉnh tài nguyên dựa trên tải.
Pay-per-Use (or Pay-per-Value): Thanh toán dựa trên mức sử dụng thực tế (thời gian chạy, số lượng request, dung lượng xử lý, v.v.), không phải dựa trên tài nguyên được cấp phát liên tục.
Event-Driven (Thường là): Nhiều dịch vụ Serverless được kích hoạt bởi các sự kiện (event) xảy ra trong hệ thống (ví dụ: file được upload lên Cloud Storage, tin nhắn đến Pub/Sub, một HTTP request).

1.4. Serverless khác gì so với IaaS, PaaS, Containers truyền thống?

Để hiểu rõ hơn, hãy so sánh Serverless với các mô hình khác:

On-Premises / Colocation: Bạn quản lý mọi thứ: trung tâm dữ liệu, máy chủ vật lý, mạng, lưu trữ, ảo hóa, hệ điều hành, runtime, ứng dụng...
- Ưu điểm: Toàn quyền kiểm soát.
- Nhược điểm: Chi phí cao, phức tạp, gánh nặng vận hành khổng lồ, co giãn khó khăn.
IaaS (Infrastructure-as-a-Service - Ví dụ: Google Compute Engine VM): Bạn thuê máy chủ ảo (VMs), mạng, lưu trữ từ nhà cung cấp đám mây. Nhà cung cấp quản lý hạ tầng vật lý (datacenter, server, mạng). Bạn quản lý hệ điều hành, runtime, ứng dụng.
- Ưu điểm: Linh hoạt, kiểm soát nhiều hơn so với PaaS/Serverless.
- Nhược điểm: Vẫn còn gánh nặng quản lý OS, scaling thủ công (hoặc bán tự động với Managed Instance Groups), trả tiền theo giờ/phút VM chạy dù nhàn rỗi.
PaaS (Platform-as-a-Service - Ví dụ: Google App Engine Flexible, có phần nào App Engine Standard): Nhà cung cấp đám mây quản lý cả hạ tầng vật lý, hệ điều hành, runtime (Java, Node.js, Python...). Bạn chỉ tập trung vào code ứng dụng.
- Ưu điểm: Giảm gánh nặng quản lý OS/runtime, scaling tự động tốt hơn IaaS.
- Nhược điểm: Ít linh hoạt hơn IaaS (bị ràng buộc bởi runtime, framework hỗ trợ), vẫn có thể có chi phí cho tài nguyên dự phòng. App Engine Flex, mặc dù tự động scale, bạn vẫn trả tiền cho VMs chạy, nên nó "ít" serverless hơn Standard hoặc Cloud Run/Functions.
Containers (Ví dụ: Google Kubernetes Engine - GKE, Google Cloud Run - đây là container Serverless): Bạn đóng gói ứng dụng vào container (Docker). Nhà cung cấp đám mây (hoặc bạn tự quản lý với GKE) cung cấp nền tảng để chạy các container đó. Với GKE, bạn quản lý cluster (các máy chủ chạy container). Với Cloud Run, Google quản lý nền tảng container hoàn toàn.
- Ưu điểm: Đóng gói ứng dụng nhất quán, di động giữa các môi trường.
- Nhược điểm (với GKE): Quản lý cluster Kubernetes phức tạp, vẫn có chi phí cho các node (máy chủ) trong cluster.
Serverless (Ví dụ: Cloud Functions, Cloud Run, App Engine Standard): Nhà cung cấp đám mây quản lý tất cả từ hạ tầng vật lý, OS, runtime (với Functions/Standard) đến nền tảng container (với Cloud Run). Bạn chỉ cung cấp code (Functions/Standard) hoặc container image (Cloud Run). Bạn không quản lý máy chủ hay cluster nào cả.
- Ưu điểm: Gần như loại bỏ gánh nặng vận hành, tối ưu chi phí (pay-per-use), scaling tự động mạnh mẽ, thời gian phát triển nhanh.
- Nhược điểm: Bị giới hạn bởi môi trường thực thi (thời gian chạy tối đa, tài nguyên cấp phát, access file system...), khó khăn hơn khi cần kiểm soát sâu vào hạ tầng, debugging phức tạp hơn.

Tóm lại: Serverless là một bước tiến xa hơn trong việc trừu tượng hóa hạ tầng. Bạn tập trung vào code/ứng dụng, đám mây lo phần còn lại.

1.5. Lợi ích và thách thức của Serverless.

Lợi ích (đã đề cập): Giảm OpEx (Operational Expenditure), tối ưu chi phí, scaling tuyệt vời, tốc độ phát triển nhanh, HA tích hợp sẵn.
Thách thức:
- Cold Starts (Khởi động nguội): Khi một hàm/container serverless không hoạt động trong một thời gian, nền tảng sẽ tắt nó đi để tiết kiệm chi phí. Request/event tiếp theo sẽ yêu cầu nền tảng khởi tạo lại, mất một khoảng thời gian trễ đáng kể (từ vài trăm mili giây đến vài giây tùy runtime/kích thước). Điều này có thể ảnh hưởng đến các ứng dụng nhạy cảm với độ trễ (latency-sensitive).
- Duration Limits (Giới hạn thời gian thực thi): Các dịch vụ serverless compute thường có giới hạn về thời gian một lần thực thi (ví dụ: 9 phút cho Cloud Functions, 60 phút cho Cloud Run). Không phù hợp cho các tác vụ chạy rất lâu.
- Vendor Lock-in: Mỗi nhà cung cấp đám mây có nền tảng serverless riêng. Việc di chuyển code giữa các nền tảng này có thể cần điều chỉnh.
- Debugging và Monitoring: Debugging một hàm/container chỉ chạy khi có sự kiện có thể phức tạp hơn so với debug trên một máy chủ chạy liên tục. Cần dựa nhiều vào logging và tracing.
- Complexity in Orchestration: Xây dựng ứng dụng lớn từ nhiều hàm/services serverless nhỏ đòi hỏi các công cụ orchestration (như Workflows) và kiến trúc phù hợp (như Event-Driven).
- Resource Limits: Giới hạn về CPU, memory, kích thước gói triển khai.

1.6. Serverless trong bối cảnh Google Cloud.

Google Cloud là một trong những nhà cung cấp hàng đầu về các dịch vụ serverless. Họ cung cấp một hệ sinh thái Serverless rất phong phú, bao gồm:

Serverless Compute: Cloud Functions, Cloud Run, App Engine Standard (và cả App Engine Flexible, dù ít serverless hơn).
Serverless Data & Analytics: Cloud Firestore, BigQuery, Pub/Sub, Cloud Storage, Dataflow, Dataproc Serverless.
Serverless Integration & Orchestration: Eventarc, Workflows, Cloud Scheduler (lên lịch chạy tác vụ), Cloud Tasks (quản lý hàng đợi tác vụ).
Serverless Networking: Serverless VPC Access (VPC Connector).
Serverless AI/ML: Một số API AI/ML.

Hệ sinh thái này cho phép bạn xây dựng hầu hết các loại ứng dụng và luồng xử lý dữ liệu hoàn toàn bằng các dịch vụ serverless, giảm thiểu tối đa việc quản lý máy chủ.

1.7. Serverless cho kỳ thi ACE: Tại sao bạn cần nắm vững nó?

Chủ đề Serverless chiếm một phần đáng kể trong kỳ thi ACE. Bạn sẽ gặp các câu hỏi liên quan đến:

Hiểu các dịch vụ Serverless chính: Chức năng, ưu điểm, nhược điểm của Cloud Functions, Cloud Run, App Engine Standard, Firestore, Pub/Sub, BigQuery, Cloud Storage.
Lựa chọn dịch vụ phù hợp: Dựa trên một kịch bản/use case cụ thể, bạn cần biết dịch vụ serverless nào là lựa chọn tốt nhất (Ví dụ: Khi nào dùng Functions thay vì Run? Khi nào dùng Run thay vì App Engine?).
Cấu hình cơ bản và Triển khai: Cách triển khai code/container lên các dịch vụ serverless. Cấu hình scaling, trigger, môi trường.
Kết nối mạng (Networking): Cách dịch vụ serverless truy cập tài nguyên trong VPC (VPC Connector).
Bảo mật (Security): IAM, Service Accounts, Ingress Control, Security Rules.
Tích hợp: Hiểu cách các dịch vụ serverless hoạt động cùng nhau (ví dụ: Functions trigger bởi Pub/Sub, Cloud Run ghi vào Firestore).
Giám sát và Ghi log: Cách xem log và metrics của các dịch vụ serverless.

Nắm vững Serverless không chỉ giúp bạn vượt qua kỳ thi mà còn trang bị cho bạn những kỹ năng cần thiết để xây dựng các ứng dụng hiện đại, hiệu quả về chi phí và dễ dàng mở rộng trên Google Cloud.

Đến đây, bạn đã có cái nhìn tổng quan về Serverless là gì, tại sao nó quan trọng và phạm vi của nó trên GCP. Chúng ta đã đặt nền móng vững chắc.

Bây giờ, tôi sẽ bắt đầu đi sâu vào từng dịch vụ Serverless Compute quan trọng nhất, bắt đầu với Cloud Functions.

Bạn có câu hỏi nào về phần giới thiệu này không trước khi chúng ta tiếp tục? Hoặc bạn có muốn tập trung vào khía cạnh nào của Serverless hơn không?

Nếu không có câu hỏi gì ngay lúc này, tôi sẽ tiếp tục với Cloud Functions nhé.

Phần 2: Các Dịch Vụ Serverless Compute (Tính toán) Chủ Đạo

2.1. Google Cloud Functions (GCF)

2.1.1. Tổng quan: Function-as-a-Service (FaaS)

Google Cloud Functions là một dịch vụ Function-as-a-Service (FaaS) được quản lý hoàn toàn. Ý tưởng cốt lõi là bạn triển khai những đoạn mã nhỏ (gọi là "hàm" - functions) mà không cần quan tâm đến hạ tầng máy chủ bên dưới. Cloud Functions sẽ chạy code của bạn để phản hồi lại các sự kiện.

Hãy nghĩ về nó như một bộ phận tự động hóa rất nhỏ. Thay vì có một hệ thống lớn luôn chạy để chờ việc, bạn chỉ viết một "công thức" nhỏ cho một công việc cụ thể (ví dụ: "khi có ảnh mới được tải lên, hãy tạo ra phiên bản thumbnail"). Cloud Functions là dịch vụ sẽ chạy công thức đó chỉ khi sự kiện xảy ra và chỉ trong thời gian cần thiết để hoàn thành công việc.

Các đặc điểm chính:

Event-driven: Được kích hoạt bởi các sự kiện.
Fully Managed: Google quản lý hoàn toàn hạ tầng, scaling, patching.
Stateless: Mỗi lần thực thi (invocation) của hàm là độc lập. Không nên lưu trạng thái (state) trong biến cục bộ của hàm giữa các lần gọi.
Short-lived: Các hàm thường được thiết kế để chạy trong thời gian ngắn (có giới hạn về thời gian thực thi tối đa).
Pay-per-invocation: Thanh toán dựa trên số lần hàm được gọi và thời gian CPU/memory sử dụng.

2.1.2. Kiến trúc và cách hoạt động: Event-driven (Kiến trúc hướng sự kiện)

Cloud Functions hoạt động dựa trên mô hình kiến trúc hướng sự kiện (Event-Driven Architecture - EDA). Điều này có nghĩa là hàm của bạn "ngủ" cho đến khi một sự kiện xảy ra. Khi sự kiện xảy ra, nó sẽ "đánh thức" hoặc tạo ra một instance mới của hàm để xử lý sự kiện đó.

Cơ chế hoạt động cơ bản:

Một sự kiện (event) xảy ra trong hệ sinh thái GCP (hoặc từ bên ngoài). Ví dụ: một tệp được tải lên Cloud Storage, một tin nhắn được gửi đến Pub/Sub, một bản ghi được thêm vào Firestore, hoặc một yêu cầu HTTP đến một URL cụ thể.
Hệ thống Cloud Functions nhận biết sự kiện này thông qua một kênh sự kiện (event channel) hoặc trực tiếp từ nguồn (đối với HTTP triggers).
Cloud Functions kích hoạt (triggers) hàm của bạn.
Hàm của bạn được cấp phát tài nguyên (CPU, memory) trong một môi trường thực thi (runtime environment) tạm thời.
Mã của bạn được thực thi để xử lý sự kiện. Dữ liệu về sự kiện được truyền dưới dạng tham số cho hàm.
Sau khi xử lý xong hoặc khi đạt đến thời gian timeout, instance của hàm sẽ được giải phóng tài nguyên. Nếu không có sự kiện nào khác đến trong một thời gian, instance có thể bị tắt đi (gây ra Cold Start cho lần gọi tiếp theo).

2.1.3. Các loại Trigger (Kích hoạt)

Đây là một phần cực kỳ quan trọng trong kỳ thi ACE. Bạn cần biết các loại sự kiện nào có thể kích hoạt Cloud Functions.

HTTP Triggers:
- Hàm được kích hoạt bởi một yêu cầu HTTP (GET, POST, PUT, DELETE, v.v.).
- Cloud Functions cung cấp một URL công khai (hoặc yêu cầu xác thực IAM) cho mỗi hàm HTTP.
- Dữ liệu yêu cầu (request body, headers, query parameters) được truyền vào hàm.
- Hàm trả về một phản hồi HTTP (response).
- Use Case: Xây dựng APIs đơn giản, Webhooks (ví dụ: nhận thông báo từ GitHub, Stripe), xử lý form trên website.
- ACE Focus: Đây là loại trigger phổ biến nhất cho các tác vụ liên quan đến web. Hiểu cách truy cập request/response objects trong code của bạn. Hiểu cách cấu hình bảo mật (Allow unauthenticated invocations hay yêu cầu xác thực IAM).
Background Triggers:
- Hàm được kích hoạt bởi các sự kiện xảy ra trong các dịch vụ GCP khác. Dữ liệu sự kiện (event data) được truyền vào hàm.
- Các nguồn sự kiện phổ biến:
  - Cloud Storage: Kích hoạt khi đối tượng (file) được tạo, cập nhật, xóa trong một bucket cụ thể.
    - Event Types: google.cloud.storage.object.v1.finalized (tạo/cập nhật), google.cloud.storage.object.v1.deleted (xóa), google.cloud.storage.object.v1.archived (chuyển sang trạng thái archived/đã xóa tạm), google.cloud.storage.object.v1.metadataUpdated (metadata được cập nhật).
    - Use Case: Xử lý file sau khi upload (ví dụ: nén ảnh, phân tích video, xử lý dữ liệu CSV), gửi thông báo khi file bị xóa.
  - Cloud Pub/Sub: Kích hoạt khi một tin nhắn mới được publish đến một Topic Pub/Sub cụ thể.
    - Event Type: google.cloud.pubsub.topic.v1.messagePublished
    - Use Case: Xử lý dữ liệu luồng, thực hiện các tác vụ bất đồng bộ (asynchronous), decoupling các hệ thống. Đây là một pattern rất mạnh mẽ: hệ thống A publish tin nhắn, Cloud Functions (đăng ký nhận tin nhắn từ Topic đó) sẽ tự động chạy để xử lý mà A không cần biết về Functions.
  - Cloud Firestore / Cloud Datastore: Kích hoạt khi một bản ghi (document/entity) được tạo, cập nhật, xóa trong một đường dẫn cụ thể.
    - Event Types: google.cloud.firestore.document.v1.created, updated, deleted, written (cho cả 3 loại trên). Datastore tương tự.
    - Use Case: Đồng bộ hóa dữ liệu giữa các hệ thống, cập nhật các bản ghi liên quan, gửi thông báo khi dữ liệu thay đổi.
  - Cloud BigQuery: Kích hoạt khi dữ liệu thay đổi trong BigQuery (ví dụ: khi một bảng mới được tạo hoặc dữ liệu được thêm vào).
    - Event Types: google.cloud.bigquery.table.v2.created, updated, deleted.
    - Use Case: Tự động xử lý sau khi dữ liệu được nạp vào BigQuery, kích hoạt workflow phân tích.
  - Google Analytics for Firebase: Kích hoạt bởi các sự kiện phân tích người dùng từ ứng dụng Firebase.
    - Event Type: google.firebase.analytics.log
    - Use Case: Xử lý các sự kiện người dùng tùy chỉnh, tích hợp với các dịch vụ khác dựa trên hành vi người dùng.
  - Firebase Authentication: Kích hoạt khi người dùng đăng ký hoặc xóa tài khoản.
    - Event Types: google.firebase.auth.user.v1.created, deleted.
    - Use Case: Gửi email chào mừng, tạo profile người dùng ban đầu, dọn dẹp dữ liệu khi người dùng xóa tài khoản.
  - Firebase Realtime Database: Kích hoạt khi dữ liệu thay đổi tại một đường dẫn cụ thể trong Realtime Database.
    - Event Types: google.firebase.database.document.v1.created, updated, deleted, written.
    - Use Case: Đồng bộ dữ liệu, tạo trigger cho các thay đổi dữ liệu thời gian thực.
  - Firebase Remote Config: Kích hoạt khi cấu hình Remote Config được cập nhật.
    - Event Type: google.firebase.remoteconfig.remoteConfig.v1.updated
    - Use Case: Tự động cập nhật các hệ thống hoặc thông báo khi cấu hình ứng dụng thay đổi.
  - Cloud Audit Logs: Kích hoạt bởi các hoạt động ghi vào Audit Logs.
    - Event Type: google.cloud.audit.log.v1.written
    - Use Case: Phản ứng lại các hành động quản trị cụ thể (ví dụ: cảnh báo khi một quyền quan trọng bị thay đổi).
Trigger từ Eventarc (Thế hệ mới):
- Eventarc là dịch vụ quản lý sự kiện tập trung của GCP. Cloud Functions thế hệ thứ 2 (--gen2 khi deploy) sử dụng Eventarc làm nền tảng trigger mặc định (trước đây là Cloud Functions thế hệ 1 sử dụng một lớp "Event Broker" nội bộ).
- Eventarc cho phép Cloud Functions được kích hoạt bởi nhiều nguồn hơn nữa, bao gồm cả các sự kiện trực tiếp từ hơn 100 dịch vụ GCP, các nguồn bên ngoài thông qua Pub/Sub, hoặc các nguồn tùy chỉnh.
- Ưu điểm: Đáng tin cậy hơn, có thể lọc sự kiện nâng cao, hỗ trợ nhiều nguồn hơn.
- ACE Focus: Mặc dù ACE tập trung vào các trigger truyền thống, việc hiểu Eventarc là cách Cloud Functions (đặc biệt là gen 2) nhận sự kiện là rất hữu ích và thể hiện kiến thức cập nhật.

Cách cấu hình Trigger (ACE Relevant):

Khi triển khai Cloud Functions, bạn sẽ chỉ định trigger. Ví dụ bằng gcloud:

bash

# HTTP Trigger
gcloud functions deploy myFunction --runtime=nodejs16 --trigger-http --allow-unauthenticated

# Cloud Storage Trigger (khi file được finalized trong bucket 'my-bucket')
gcloud functions deploy processImage --runtime=python39 --trigger-resource=my-bucket --trigger-event=google.cloud.storage.object.v1.finalized

# Pub/Sub Trigger (khi tin nhắn đến topic 'my-topic')
gcloud functions deploy processMessage --runtime=go118 --trigger-topic=my-topic

# Firestore Trigger (khi document được tạo/cập nhật/xóa trong đường dẫn 'users/{userId}')
gcloud functions deploy auditUserChange --runtime=java11 --trigger-resource=projects/PROJECT_ID/databases/(default)/documents/users/{userId} --trigger-event=google.cloud.firestore.document.v1.written

Hoặc trong Cloud Console, bạn chọn loại trigger và cấu hình các thông số liên quan (tên bucket, tên topic, đường dẫn Firestore, v.v.).

2.1.4. Môi trường thực thi (Runtime)

Cloud Functions hỗ trợ nhiều ngôn ngữ lập trình phổ biến. Khi triển khai, bạn chọn runtime phù hợp với mã nguồn của mình. Google cung cấp và quản lý môi trường runtime này (bao gồm hệ điều hành, interpreter/VM, các thư viện cơ bản).

Các runtime phổ biến (kiểm tra phiên bản mới nhất trên docs chính thức):

Node.js (10, 12, 14, 16, 18, 20)
Python (3.7, 3.8, 3.9, 3.10, 3.11)
Go (1.11, 1.13, 1.16, 1.18, 1.20)
Java (11, 17)
.NET (Core 3.1, 6, 7)
Ruby (2.6, 2.7, 3.0, 3.1)
PHP (7.4, 8.0, 8.1, 8.2)

Bạn chỉ cần cung cấp mã nguồn và file dependency (ví dụ: package.json cho Node.js, requirements.txt cho Python), Cloud Functions sẽ xây dựng môi trường thực thi.

ACE Focus: Bạn không cần là chuyên gia về tất cả các ngôn ngữ, nhưng cần biết Cloud Functions hỗ trợ nhiều runtime khác nhau và cách chỉ định chúng khi triển khai.

2.1.5. Quản lý vòng đời và Triển khai

Triển khai Cloud Functions thường bao gồm:

Viết mã nguồn: Code của bạn phải tuân theo một cấu trúc nhất định tùy thuộc vào runtime. Ví dụ, với Node.js, bạn export một hàm (function) mà Cloud Functions sẽ gọi khi có sự kiện.

javascript

// Node.js Example for HTTP Trigger
exports.helloHttp = (req, res) => {
  res.status(200).send("Hello World!");
};

// Node.js Example for Pub/Sub Trigger
exports.helloPubSub = (pubSubEvent, context) => {
  const message = pubSubEvent.data ? Buffer.from(pubSubEvent.data, 'base64').toString() : 'No message';
  console.log(`Received message: ${message}`);
};

Định nghĩa dependencies: Sử dụng file chuẩn của ngôn ngữ (package.json, requirements.txt, pom.xml, v.v.).
Triển khai:
- Sử dụng gcloud CLI: Đây là cách phổ biến nhất và được khuyến khích cho tự động hóa và từ terminal.
  bash
```
gcloud functions deploy YOUR_FUNCTION_NAME \
  --runtime YOUR_RUNTIME \
  --trigger-YOUR_TRIGGER_TYPE [...] \
  --source YOUR_CODE_DIRECTORY \
  --entry-point YOUR_FUNCTION_ENTRY_POINT \
  --region YOUR_REGION \
  [--allow-unauthenticated (for HTTP)] \
  [--vpc-connector=CONNECTOR_NAME (for VPC access)] \
  [--memory=AMOUNT --timeout=SECONDS] \
  [--set-env-vars KEY=VALUE,...]
```
  - YOUR_FUNCTION_NAME: Tên duy nhất cho hàm của bạn.
  - YOUR_RUNTIME: Ngôn ngữ và phiên bản (nodejs16, python39, etc.).
  - --trigger-...: Loại trigger (http, resource, topic).
  - --source: Đường dẫn đến mã nguồn của bạn.
  - --entry-point: Tên của hàm trong mã nguồn mà Cloud Functions sẽ gọi.
  - --region: Khu vực triển khai (quan trọng cho độ trễ và kết nối dịch vụ khác).
- Sử dụng Cloud Console: Giao diện web trực quan để tạo, cấu hình và triển khai hàm. Bạn có thể viết code trực tiếp trong editor trên Console hoặc tải lên file ZIP.
- Sử dụng Cloud Build/CI/CD: Tích hợp với các pipeline CI/CD để tự động hóa việc build và triển khai khi code được commit.

ACE Focus: Nắm vững lệnh gcloud functions deploy với các flag cơ bản (--runtime, --trigger-http, --trigger-resource, --trigger-topic, --source, --entry-point, --region). Hiểu cách Cloud Functions sử dụng file dependency.

2.1.6. Scaling (Tự động co giãn)

Cloud Functions tự động co giãn bằng cách tạo ra nhiều instance của hàm khi có nhiều sự kiện hoặc yêu cầu đến cùng lúc.

Cách hoạt động: Khi một sự kiện đến, Cloud Functions kiểm tra xem có instance nhàn rỗi nào sẵn sàng xử lý không.
- Nếu có instance nhàn rỗi: Sử dụng instance đó -> xử lý nhanh.
- Nếu không có instance nhàn rỗi: Kiểm tra xem số lượng instance hiện tại đã đạt đến giới hạn tối đa chưa.
  - Nếu chưa: Tạo một instance mới để xử lý sự kiện đó. Quá trình tạo instance mới này gọi là Cold Start.
  - Nếu đạt giới hạn tối đa: Sự kiện/request sẽ phải chờ trong hàng đợi hoặc bị từ chối (tùy cấu hình và loại trigger).
Concurrency (Đồng thời): Một instance của Cloud Functions (thế hệ 1) chỉ có thể xử lý một sự kiện/request tại một thời điểm. Với Cloud Functions thế hệ 2, bạn có thể cấu hình concurrency (số lượng yêu cầu một instance có thể xử lý đồng thời), giống như Cloud Run. Đây là một khác biệt quan trọng.
Cold Start (Khởi động nguội): Đây là nhược điểm cố hữu của các dịch vụ FaaS/Serverless Compute dựa trên sự kiện không liên tục. Khi một instance mới được tạo (do không có instance nhàn rỗi và chưa đạt giới hạn tối đa), cần có thời gian để:
1. Khởi động môi trường runtime.
2. Tải mã nguồn và dependencies của hàm.
3. Chạy mã khởi tạo bên ngoài hàm xử lý sự kiện chính. Quá trình này mất thời gian, gây ra độ trễ đáng kể cho request/event đầu tiên đến instance mới đó. Thời gian Cold Start phụ thuộc vào runtime (Java/Python thường lâu hơn Node.js/Go), kích thước dependency và lượng mã khởi tạo.
Giới hạn Scaling: Có giới hạn cứng về số lượng instance tối đa mà một hàm có thể co giãn lên (mặc định là 1000 instance mỗi khu vực, có thể yêu cầu tăng). Ngoài ra, có giới hạn về số lượng instance mới được tạo mỗi phút (burst capacity).
Kiểm soát Scaling (Gen 2): Cloud Functions thế hệ 2 cho phép cấu hình số lượng instance tối thiểu (min instances) để giảm Cold Start và số lượng instance tối đa (max instances). Thế hệ 1 chỉ có giới hạn tối đa.

ACE Focus: Hiểu khái niệm Cold Start và tác động của nó. Biết rằng Cloud Functions (Gen 1) xử lý 1 request/instance tại một thời điểm (không đồng thời). Biết có thể cấu hình min/max instances với Gen 2.

2.1.7. Pricing (Mô hình tính cước)

Mô hình tính cước của Cloud Functions rất phù hợp với kiến trúc Serverless: bạn chỉ trả tiền cho những gì bạn sử dụng.

Số lần gọi (Invocations): Tính phí cho mỗi lần hàm được gọi (sau một lượng miễn phí đáng kể hàng tháng).
Thời gian sử dụng tài nguyên (Resource Usage): Tính phí dựa trên thời gian thực thi của hàm và lượng CPU/memory được cấp phát.
- Tính theo Gb-seconds và GHz-seconds. Ví dụ: chạy một hàm với 256MB memory trong 1 giây tính là 0.25 Gb-seconds. Chạy với 1 vCPU trong 1 giây tính là 1 GHz-second.
- Thời gian được tính từ khi hàm bắt đầu chạy đến khi nó kết thúc hoặc timeout.
Network Egress: Tính phí cho dữ liệu truyền ra ngoài mạng của Google Cloud. Truyền dữ liệu giữa các dịch vụ GCP trong cùng khu vực thường miễn phí hoặc rất rẻ.

Free Tier (Tầng miễn phí): Cloud Functions có một tầng miễn phí rất hào phóng, bao gồm một lượng đáng kể số lần gọi, thời gian sử dụng tài nguyên và network egress mỗi tháng. Điều này giúp bạn dễ dàng thử nghiệm hoặc chạy các workload nhỏ mà không tốn kém.

ACE Focus: Hiểu rằng pricing dựa trên số lần gọi và thời gian sử dụng tài nguyên. Nắm được mô hình pay-per-use giúp tối ưu chi phí bằng cách chỉ chạy code khi cần.

2.1.8. Use Cases (Trường hợp sử dụng điển hình)

Cloud Functions rất phù hợp cho:

Xử lý sự kiện (Event Processing): Phản ứng lại các thay đổi trong dữ liệu (Firestore, Cloud Storage), tin nhắn (Pub/Sub), log (Audit Logs). Ví dụ: Tự động xử lý ảnh sau khi upload lên Cloud Storage, gửi email khi có đơn hàng mới trong Firestore, ghi log tùy chỉnh khi có sự kiện hệ thống.
Xây dựng Webhooks: Nhận và xử lý dữ liệu từ các dịch vụ bên ngoài (ví dụ: thông báo thanh toán từ Stripe, sự kiện từ GitHub).
Tạo APIs đơn giản: Xây dựng các endpoint API nhỏ, không cần logic phức tạp hoặc trạng thái.
Tác vụ nền (Background Jobs): Thực hiện các tác vụ không đồng bộ, không cần người dùng chờ đợi (ví dụ: gửi email chào mừng sau khi đăng ký, xử lý dữ liệu định kỳ được kích hoạt bởi Cloud Scheduler).
Tích hợp dịch vụ (Service Integration): Kết nối các dịch vụ GCP hoặc dịch vụ bên ngoài lại với nhau (ví dụ: nhận dữ liệu từ Pub/Sub và ghi vào BigQuery, gọi API bên ngoài từ một sự kiện Firestore).
Microservices nhỏ: Triển khai các chức năng rất nhỏ, độc lập như một phần của kiến trúc microservices.

Khi nào KHÔNG nên dùng Cloud Functions:

Ứng dụng yêu cầu thời gian chạy rất dài (> 9 phút cho Gen 1, > 60 phút cho Gen 2).
Ứng dụng cần trạng thái (stateful) giữa các request/event.
Ứng dụng yêu cầu kiểm soát chi tiết môi trường runtime hoặc cần truy cập hệ thống file đầy đủ.
Ứng dụng là một web server phức tạp, có nhiều endpoint và logic phức tạp (Cloud Run hoặc App Engine phù hợp hơn).
Ứng dụng nhạy cảm với Cold Start (trừ khi sử dụng min instances trong Gen 2 hoặc các kỹ thuật "warm-up").

2.1.9. Bảo mật (Security)

Bảo mật cho Cloud Functions bao gồm:

IAM (Identity and Access Management):
- Deploy/Manage: Cần các quyền IAM thích hợp (cloudfunctions.functions.deploy, cloudfunctions.functions.delete, v.v.) để quản lý hàm. Vai trò (roles) như roles/cloudfunctions.developer hoặc roles/cloudfunctions.admin cung cấp các quyền này.
- Invoke: Ai được phép gọi hàm của bạn?
  - HTTP Functions: Mặc định yêu cầu xác thực IAM. Người dùng/Service Account gọi hàm cần có quyền cloudfunctions.functions.invoke. Bạn có thể cho phép gọi không cần xác thực bằng cờ --allow-unauthenticated khi deploy (thích hợp cho public APIs, webhooks).
  - Background Functions: Chỉ có thể được kích hoạt bởi nguồn sự kiện đã cấu hình (ví dụ: Cloud Storage, Pub/Sub). Không thể gọi trực tiếp qua HTTP (trừ khi bạn cấu hình thêm HTTP trigger).
Service Account: Khi hàm của bạn cần truy cập các dịch vụ GCP khác (ví dụ: ghi vào Firestore, đọc từ Cloud Storage, publish tin nhắn Pub/Sub), nó sử dụng danh tính của một Service Account. Mặc định là Service Account PROJECT_ID@appspot.gserviceaccount.com (Service Account mặc định của App Engine), nhưng bạn nên tạo Service Account riêng với các quyền tối thiểu cần thiết và gán cho hàm khi deploy bằng cờ --service-account.
VPC Connector (Serverless VPC Access): Mặc định, Cloud Functions chạy trong mạng của Google và không có quyền truy cập trực tiếp vào tài nguyên trong Virtual Private Cloud (VPC) của bạn (ví dụ: máy chủ Compute Engine, instance Cloud SQL với địa chỉ IP nội bộ, Memorystore). Để khắc phục điều này, bạn cần tạo một Serverless VPC Access connector trong VPC của mình và cấu hình hàm Cloud Functions sử dụng connector đó (--vpc-connector=CONNECTOR_NAME). Hàm của bạn sau đó sẽ có địa chỉ IP nội bộ trong VPC và có thể truy cập các tài nguyên riêng tư. Đây là một chủ đề rất quan trọng cho ACE.
Firewall Rules: Khi sử dụng VPC Connector, bạn cần đảm bảo các Firewall Rules trong VPC cho phép lưu lượng truy cập từ subnet của connector đến tài nguyên đích.

ACE Focus: Hiểu về IAM cho cả việc quản lý và gọi hàm. Biết về Service Accounts và nguyên tắc cấp quyền tối thiểu. Nắm vững VPC Connector và khi nào cần sử dụng nó để Cloud Functions truy cập tài nguyên riêng tư.

2.1.10. Giám sát và Ghi log (Monitoring & Logging)

Giống như các dịch vụ GCP khác, Cloud Functions tích hợp chặt chẽ với Cloud Logging và Cloud Monitoring.

Cloud Logging:
- Mọi output ra stdout/stderr từ mã của bạn (ví dụ: console.log() trong Node.js, print() trong Python) sẽ tự động được chuyển đến Cloud Logging.
- Các log hệ thống về quá trình thực thi hàm (bắt đầu, kết thúc, lỗi) cũng được ghi lại.
- Bạn có thể xem log trong Cloud Console (mục "Logging" -> "Logs Explorer" hoặc trực tiếp trong giao diện Cloud Functions). Log rất quan trọng để debug.
Cloud Monitoring:
- Cung cấp các metrics (số liệu) về hoạt động của hàm:
  - Execution count: Tổng số lần hàm được gọi.
  - Execution time (Latency): Thời gian thực thi trung bình, p50, p95, p99.
  - Error count/rate: Số lượng hoặc tỷ lệ lỗi xảy ra.
  - Instance count: Số lượng instance đang chạy (có thể thấy Cold Start qua biểu đồ này).
  - Memory/CPU utilization: Mức độ sử dụng tài nguyên.
- Bạn có thể xem các biểu đồ metrics này trong Cloud Monitoring (mục "Monitoring" -> "Metrics Explorer" hoặc trong giao diện Cloud Functions).
- Thiết lập Alerts (cảnh báo) dựa trên các metrics này (ví dụ: cảnh báo khi tỷ lệ lỗi tăng đột ngột).

ACE Focus: Biết cách xem log trong Cloud Logging để debug và theo dõi hoạt động của hàm. Biết các metrics quan trọng có sẵn trong Cloud Monitoring để giám sát hiệu năng và sức khỏe của hàm.

2.1.11. Ưu điểm và nhược điểm

Ưu điểm:
- Quản lý hoàn toàn, cực kỳ đơn giản để bắt đầu với code logic nhỏ.
- Tự động co giãn tuyệt vời dựa trên sự kiện.
- Mô hình thanh toán pay-per-use rất hiệu quả cho các workload không liên tục hoặc có lưu lượng biến động lớn.
- Tích hợp sâu với nhiều dịch vụ GCP khác thông qua background triggers.
- Tầng miễn phí hào phóng.
Nhược điểm:
- Cold Start có thể là vấn đề cho các ứng dụng nhạy cảm độ trễ (đặc biệt là HTTP triggers).
- Giới hạn thời gian thực thi tối đa.
- Giới hạn về tài nguyên (CPU/Memory) và kích thước gói triển khai.
- Không phù hợp cho các ứng dụng cần trạng thái hoặc chạy liên tục.
- Debugging có thể khó khăn hơn so với môi trường truyền thống.
- Môi trường thực thi bị sandbox, có một số hạn chế về file system và networking (ngoại trừ qua VPC Connector).

2.1.12. So sánh sơ bộ với Cloud Run và App Engine Standard

Cloud Functions vs. Cloud Run:
- Functions: Event-driven, chạy đoạn mã (function), đơn giản cho các tác vụ nhỏ, tích hợp background trigger mạnh mẽ. Cold Start (Gen 1) có thể nghiêm trọng hơn.
- Run: Request-driven (HTTP), chạy container bất kỳ, linh hoạt hơn về runtime/dependencies/frameworks, hỗ trợ concurrency (một instance xử lý nhiều request), Cold Start thường ít nghiêm trọng hơn (do có thể cấu hình min instances và concurrency).
Cloud Functions vs. App Engine Standard:
- Functions: Event-driven/HTTP, FaaS, đơn vị triển khai là hàm, rất nhỏ gọn, pay-per-invocation/time.
- App Engine Standard: Request-driven (HTTP), PaaS, đơn vị triển khai là toàn bộ ứng dụng/service, dựa trên các runtime cố định của Google, mô hình instance/hour (Automatic scaling vẫn có yếu tố serverless). Phù hợp cho các ứng dụng web/backend truyền thống hơn.

Chúng ta sẽ so sánh chi tiết hơn sau khi tìm hiểu về Cloud Run và App Engine Standard.

2.1.13. ACE Focus: Khi nào dùng Cloud Functions?

Bạn cần chạy một đoạn code nhỏ để phản ứng lại các sự kiện từ các dịch vụ GCP khác (Cloud Storage, Pub/Sub, Firestore, v.v.).
Bạn cần xây dựng một webhook để nhận dữ liệu từ bên ngoài.
Bạn cần một API đơn giản chỉ thực hiện một tác vụ cụ thể và không cần framework phức tạp.
Bạn muốn giảm thiểu tối đa chi phí bằng cách chỉ trả tiền cho thời gian code thực sự chạy.
Tác vụ của bạn có thời gian thực thi ngắn (dưới giới hạn timeout).
Ứng dụng của bạn có thể xử lý được Cold Start (hoặc bạn dùng Gen 2 và cấu hình min instances).

Nếu bạn cần chạy container tùy chỉnh, cần kiểm soát runtime/dependencies cao hơn, hoặc xây dựng microservices/web apps phức tạp, Cloud Run có thể là lựa chọn tốt hơn. Nếu bạn cần một nền tảng đầy đủ cho ứng dụng web truyền thống với các dịch vụ đi kèm (Task Queues cũ, Cron), App Engine Standard có thể phù hợp.

2.1.14. Links quan trọng:

Cloud Functions Documentation: https://cloud.google.com/functions/docs
Cloud Functions Pricing: https://cloud.google.com/functions/pricing
Serverless VPC Access Documentation: https://cloud.google.com/vpc/docs/configure-serverless-vpc-access
Eventarc Documentation: https://cloud.google.com/eventarc/docs

Tuyệt vời! Cảm ơn bạn đã sẵn sàng tiếp tục. Chúng ta đã hoàn thành phần giới thiệu về Serverless và đi sâu vào Cloud Functions (FaaS). Bây giờ, hãy chuyển sang dịch vụ serverless compute cực kỳ mạnh mẽ và linh hoạt khác: Google Cloud Run.

(Tiếp tục Phần 2: Các Dịch Vụ Serverless Compute Chủ Đạo)

2.2. Google Cloud Run

2.2.1. Tổng quan: Serverless Containers (Container không máy chủ)

Google Cloud Run là một nền tảng serverless cho phép bạn chạy các container stateless được kích hoạt bởi các yêu cầu HTTP. Đây là điểm khác biệt cốt lõi so với Cloud Functions (FaaS): bạn không bị giới hạn bởi việc chỉ chạy một "hàm" nhỏ với các runtime có sẵn, mà có thể đóng gói toàn bộ ứng dụng của mình (bao gồm cả web framework, thư viện phức tạp) vào một container và chạy nó trên một nền tảng serverless được quản lý hoàn toàn.

Hãy nghĩ về Cloud Run như một môi trường PaaS (Platform-as-a-Service) thế hệ mới, kết hợp sự linh hoạt của container với sự đơn giản và khả năng co giãn của Serverless.

Các đặc điểm chính:

Request-driven: Được kích hoạt chủ yếu bởi các yêu cầu HTTP.
Stateless Containers: Yêu cầu container không lưu trạng thái trên disk hoặc trong memory giữa các request (tức là mỗi request có thể được xử lý bởi một instance khác nhau). Nếu cần trạng thái, hãy lưu trữ ở các dịch vụ bên ngoài như Firestore, Cloud SQL, Memorystore.
Fully Managed: Google quản lý hoàn toàn hạ tầng bên dưới, bao gồm cả môi trường container runtime, scaling, load balancing.
Supports any Language/Framework: Miễn là bạn đóng gói được vào container, bạn có thể chạy nó trên Cloud Run. Điều này mang lại sự linh hoạt vượt trội so với FaaS.
Automatic Scaling: Tự động co giãn số lượng instance container dựa trên lượng request đến.
Concurrency: Một instance container có thể xử lý nhiều request HTTP đồng thời (có thể cấu hình). Đây là điểm khác biệt lớn so với Cloud Functions Gen 1.
Pay-per-Use: Thanh toán dựa trên số lượng request và thời gian CPU/memory được cấp phát khi instance đang xử lý request. Khi không có request, instance có thể được "ngừng hoạt động" (dẫn đến cold start cho request đầu tiên), nhưng bạn không trả tiền cho thời gian nhàn rỗi hoàn toàn (trừ khi cấu hình min instances > 0).

2.2.2. Kiến trúc và cách hoạt động

Cloud Run được xây dựng dựa trên Knative, một nền tảng mã nguồn mở trên Kubernetes, nhưng Google quản lý hoàn toàn tầng Kubernetes bên dưới cho bạn.

Cách hoạt động cơ bản:

Bạn đóng gói ứng dụng của mình vào một container image (ví dụ: Docker image) và đẩy nó lên một registry (như Google Artifact Registry hoặc Container Registry).
Bạn triển khai container image này lên Cloud Run, tạo ra một Service (dịch vụ Cloud Run).
Cloud Run cung cấp một URL công khai cho dịch vụ của bạn.
Khi một yêu cầu HTTP đến URL này:
- Cloud Run nhận yêu cầu.
- Nếu có instance container nhàn rỗi có khả năng xử lý yêu cầu, yêu cầu sẽ được gửi đến instance đó.
- Nếu không có instance nhàn rỗi và chưa đạt đến giới hạn scaling tối đa, Cloud Run sẽ khởi động một hoặc nhiều instance mới của container của bạn. Quá trình khởi động này có thể mất một chút thời gian (Cold Start).
- Yêu cầu được chuyển đến instance container đang chạy. Container phải lắng nghe trên cổng được chỉ định (mặc định là 8080, có thể cấu hình bằng biến môi trường PORT).
- Container xử lý yêu cầu và trả về phản hồi HTTP.
Một instance container có thể xử lý nhiều yêu cầu đồng thời lên đến giới hạn concurrency mà bạn cấu hình.
Nếu một instance không nhận được request nào trong một khoảng thời gian, Cloud Run có thể tắt nó đi để tiết kiệm tài nguyên và chi phí.

Điểm quan trọng: Cloud Run yêu cầu container của bạn phải lắng nghe các yêu cầu trên một cổng cụ thể và phản hồi lại HTTP requests. Nó không trực tiếp được kích hoạt bởi các background event như Cloud Storage hay Pub/Sub một cách tự nhiên như Cloud Functions. Tuy nhiên, bạn có thể sử dụng Eventarc để kích hoạt Cloud Run services khi có các sự kiện xảy ra.

2.2.3. Triển khai

Triển khai ứng dụng lên Cloud Run bao gồm các bước:

Đóng gói ứng dụng vào Container Image:
- Bạn cần viết một Dockerfile để mô tả cách xây dựng image.
- Image này phải chứa tất cả mã nguồn, dependencies và môi trường runtime cần thiết để ứng dụng của bạn chạy.
- Container của bạn phải expose một cổng (thường là 8080) để nhận yêu cầu HTTP.
- Ví dụ Dockerfile đơn giản:
  dockerfile
```
# Use a base image
FROM python:3.9-slim

# Set the working directory
WORKDIR /app

# Copy the application code and dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

# Expose the port your application listens on
ENV PORT 8080
EXPOSE $PORT

# Command to run the application
CMD ["python", "main.py"]
```
Build Container Image: Sử dụng Docker CLI hoặc Cloud Build.
- docker build -t gcr.io/PROJECT_ID/my-cloud-run-app:latest .
- Cloud Build: Dịch vụ CI/CD serverless của GCP. Bạn có thể cấu hình Cloud Build để tự động build container image từ source code trong Cloud Source Repositories, GitHub, Bitbucket, v.v. khi có commit mới. Kết quả build (image) sẽ được đẩy vào Artifact Registry hoặc Container Registry.
Lưu trữ Container Image: Đẩy image đã build lên một Container Registry. Google Cloud cung cấp:
- Artifact Registry: Dịch vụ quản lý artifact (bao gồm container images) thế hệ mới, tích hợp tốt hơn với các dịch vụ GCP khác. Nên sử dụng cái này.
- Container Registry: Dịch vụ registry cũ hơn, cũng hoạt động tốt.
- docker push gcr.io/PROJECT_ID/my-cloud-run-app:latest
Triển khai lên Cloud Run: Sử dụng gcloud CLI hoặc Cloud Console.
- Sử dụng gcloud CLI:
  bash
```
gcloud run deploy my-cloud-run-service \
  --image gcr.io/PROJECT_ID/my-cloud-run-app:latest \
  --platform managed \
  --region YOUR_REGION \
  --allow-unauthenticated \
  [--cpu=1 --memory=512Mi] \
  [--concurrency=80] \
  [--min-instances=0 --max-instances=100] \
  [--vpc-connector=CONNECTOR_NAME] \
  [--set-env-vars KEY=VALUE,...]
```
  - my-cloud-run-service: Tên dịch vụ Cloud Run.
  - --image: Đường dẫn đầy đủ đến container image trong registry.
  - --platform managed: Chỉ định sử dụng môi trường Cloud Run được quản lý (serverless). Có cả Cloud Run for GKE (chạy container trên GKE cluster của bạn, không serverless hoàn toàn).
  - --region: Khu vực triển khai.
  - --allow-unauthenticated: Cho phép truy cập công khai qua HTTP.
  - --cpu, --memory: Cấu hình tài nguyên cho mỗi instance.
  - --concurrency: Số lượng request đồng thời mà một instance có thể xử lý.
  - --min-instances, --max-instances: Cấu hình scaling.
  - --vpc-connector: Kết nối đến VPC.
- Sử dụng Cloud Console: Giao diện web trực quan để tạo Service, chọn image từ registry, cấu hình các thiết lập scaling, memory, environment variables, networking, v.v.
- CI/CD Pipelines: Tích hợp Cloud Build hoặc các công cụ CI/CD khác để tự động triển khai sau khi build image.

ACE Focus: Hiểu luồng triển khai: Code -> Dockerfile -> Build Image (Cloud Build) -> Push Image (Artifact Registry/Container Registry) -> Deploy to Cloud Run (gcloud run deploy). Biết các cờ quan trọng khi deploy (--image, --platform managed, --allow-unauthenticated, --concurrency, --min-instances, --max-instances, --vpc-connector). Hiểu vai trò của container image.

2.2.4. Scaling (Tự động co giãn)

Scaling trên Cloud Run rất linh hoạt và có thể cấu hình nhiều hơn so với Cloud Functions (Gen 1).

Nguyên tắc: Cloud Run tự động điều chỉnh số lượng instance container đang chạy để xử lý lượng request đến.
Min/Max Instances:
- --min-instances: Số lượng instance tối thiểu luôn được giữ ấm và sẵn sàng xử lý request. Giá trị > 0 giúp giảm thiểu hoặc loại bỏ Cold Start, nhưng tốn chi phí khi không có request. Mặc định là 0.
- --max-instances: Số lượng instance tối đa mà dịch vụ có thể co giãn lên. Giúp kiểm soát chi phí và tránh quá tải tài nguyên downstream.
Concurrency (Đồng thời):
- Một instance của Cloud Run có thể xử lý nhiều request cùng lúc.
- Bạn cấu hình số lượng request tối đa mà mỗi instance có thể xử lý đồng thời (--concurrency). Giá trị mặc định thường là 80, tối đa là 1000.
- Việc cấu hình concurrency phù hợp giúp tối ưu hóa việc sử dụng tài nguyên của mỗi instance. Nếu concurrency quá thấp, bạn cần nhiều instance hơn. Nếu quá cao, một instance có thể bị quá tải.
Metrics Scaling: Cloud Run theo dõi tải trên các instance (ví dụ: CPU utilization) và số lượng request đang chờ để quyết định khi nào cần tăng/giảm số lượng instance. Khi số lượng request/tải vượt quá khả năng của các instance hiện có, Cloud Run sẽ tạo thêm instance (lên đến max-instances). Khi tải giảm, các instance nhàn rỗi sẽ bị tắt (trừ khi min-instances > 0).

ACE Focus: Đây là phần rất quan trọng cho ACE. Hiểu cách Cloud Run scale, vai trò của min-instances (giảm Cold Start), max-instances (kiểm soát chi phí/tải), và đặc biệt là Concurrency (tối ưu hiệu quả sử dụng instance).

2.2.5. Pricing (Mô hình tính cước)

Mô hình tính cước của Cloud Run cũng dựa trên mức sử dụng thực tế:

Request Fee: Tính phí cho mỗi 100.000 request (sau một lượng miễn phí đáng kể hàng tháng).
Resource Usage Fee: Tính phí dựa trên thời gian CPU và memory được cấp phát cho các instance trong khi chúng đang xử lý request.
- Khi instance không xử lý request (nhàn rỗi), bạn không trả tiền cho CPU, chỉ trả một phần rất nhỏ cho memory được cấp phát (trừ khi min-instances > 0).
- Nếu min-instances > 0, bạn trả tiền cho CPU và memory của các instance đó ngay cả khi chúng nhàn rỗi, để đảm bảo chúng luôn sẵn sàng.
Network Egress: Tính phí cho dữ liệu truyền ra ngoài mạng của Google Cloud.

Free Tier: Cloud Run cũng có tầng miễn phí hào phóng cho phép bạn chạy các workload nhỏ.

ACE Focus: Hiểu rằng pricing dựa trên số request và thời gian xử lý (CPU/Memory). Nắm được chi phí phát sinh khi sử dụng min-instances > 0.

2.2.6. Use Cases (Trường hợp sử dụng điển hình)

Cloud Run cực kỳ linh hoạt và phù hợp cho nhiều trường hợp, đặc biệt là những ứng dụng dựa trên HTTP:

Microservices: Triển khai các microservices độc lập, mỗi service là một container. Cloud Run cung cấp một nền tảng tuyệt vời để chạy và mở rộng các microservices mà không cần quản lý cluster Kubernetes.
APIs: Xây dựng các RESTful APIs phức tạp sử dụng bất kỳ ngôn ngữ và framework nào bạn thích.
Web Applications: Chạy các ứng dụng web (có hoặc không có frontend) được đóng gói trong container. Cloud Run có thể phục vụ cả nội dung động.
Containerized Batch Jobs (qua HTTP trigger): Mặc dù chủ yếu là request-driven, bạn có thể kích hoạt một tác vụ batch trong container Cloud Run bằng cách gửi một HTTP request (ví dụ: từ Cloud Scheduler, Pub/Sub push subscription, Workflows).
Xử lý dữ liệu luồng (qua Push Subscription): Cloud Pub/Sub có thể cấu hình push subscription để gửi tin nhắn dưới dạng HTTP POST request đến một endpoint HTTP. Endpoint này có thể là dịch vụ Cloud Run của bạn.
Static Website Hosting (ít phổ biến hơn so với Cloud Storage, nhưng có thể nếu cần xử lý logic): Mặc dù Cloud Storage tốt hơn cho static content thuần túy, nếu bạn cần xử lý nhẹ nhàng hoặc định tuyến phức tạp, Cloud Run có thể được sử dụng.

Khi nào KHÔNG nên dùng Cloud Run:

Tác vụ không được kích hoạt bởi HTTP requests (ví dụ: chỉ phản ứng lại sự kiện Cloud Storage mà không thông qua một lớp trung gian nào khác như Eventarc/Pub/Sub). Cloud Functions có trigger trực tiếp tốt hơn cho trường hợp này.
Ứng dụng yêu cầu trạng thái trên disk hoặc trong memory giữa các request.
Ứng dụng yêu cầu quyền truy cập hệ thống file đầy đủ và liên tục.
Tác vụ batch chạy rất lâu và không thể đóng gói thành các đơn vị nhỏ hơn (có giới hạn timeout - 60 phút).
Bạn cần kiểm soát hạ tầng máy chủ ở mức độ rất thấp (Compute Engine, GKE).

2.2.7. Deep Dive: Các tính năng nâng cao

Mapping Custom Domains: Dễ dàng ánh xạ tên miền tùy chỉnh của bạn (ví dụ: api.mydomain.com) đến dịch vụ Cloud Run, bao gồm cả việc tự động cấp chứng chỉ SSL/TLS miễn phí (Managed Certificates).
Traffic Splitting: Triển khai các phiên bản (revisions) khác nhau của dịch vụ Cloud Run và chia lưu lượng truy cập giữa chúng (ví dụ: 90% cho phiên bản ổn định, 10% cho phiên bản mới để thử nghiệm). Tuyệt vời cho blue/green deployments hoặc canary releases.
Revisions: Mỗi lần bạn triển khai container image mới hoặc thay đổi cấu hình dịch vụ Cloud Run, một Revision mới sẽ được tạo. Bạn có thể dễ dàng chuyển đổi giữa các Revision, roll back về phiên bản cũ.
Service-to-Service Authentication: Khi một dịch vụ Cloud Run (hoặc dịch vụ GCP nào khác) cần gọi một dịch vụ Cloud Run khác (không cho phép truy cập công khai), nó có thể sử dụng IAM để tạo một mã thông báo ID (ID token) và gửi kèm theo request. Cloud Run sẽ xác minh mã thông báo này để cho phép truy cập. Điều này sử dụng danh tính của Service Account.

ACE Focus: Custom Domains, Traffic Splitting/Revisions, và Service-to-Service Authentication là những tính năng quan trọng cho ACE, đặc biệt khi xây dựng kiến trúc microservices.

2.2.8. Bảo mật (Security)

Bảo mật trong Cloud Run tương tự như Cloud Functions, với một số điểm bổ sung:

IAM:
- Deploy/Manage: Cần quyền (roles/run.developer, roles/run.admin) để triển khai và quản lý dịch vụ.
- Invoke: Ai được phép gửi request đến dịch vụ Cloud Run? Mặc định là không ai. Bạn phải cấp quyền roles/run.invoker cho người dùng/Service Account hoặc cho phép truy cập không xác thực (--allow-unauthenticated) khi deploy.
Service Account: Tương tự Cloud Functions, dịch vụ Cloud Run chạy với danh tính của một Service Account (mặc định hoặc tùy chỉnh) khi cần truy cập các dịch vụ GCP khác. Cấp quyền tối thiểu là rất quan trọng. Service Account cũng được sử dụng cho Service-to-Service Authentication.
VPC Connector (Serverless VPC Access): Giống như Cloud Functions, nếu dịch vụ Cloud Run cần truy cập tài nguyên nội bộ trong VPC (Cloud SQL private IP, Compute Engine VM, v.v.), bạn phải cấu hình nó sử dụng Serverless VPC Access Connector.
Ingress Settings: Cloud Run cho phép cấu hình ai được phép gửi request đến dịch vụ:
- all: Cho phép truy cập công khai (cần thêm --allow-unauthenticated).
- internal: Chỉ cho phép request từ bên trong cùng một VPC hoặc từ các mạng on-premises kết nối đến VPC đó (ví dụ: qua VPN, Interconnect) khi sử dụng VPC Connector.
- internal-and-cloud-load-balancing: Cho phép từ VPC và qua Cloud Load Balancing (khi Cloud Load Balancer được cấu hình để gửi traffic đến Cloud Run).
- ACE Focus: Hiểu các chế độ Ingress và khi nào sử dụng internal hoặc internal-and-cloud-load-balancing kết hợp với VPC Connector hoặc Load Balancer để bảo mật ứng dụng.

ACE Focus: Nắm vững IAM cho Invoke, Service Accounts, VPC Connector (cực kỳ quan trọng), và các chế độ Ingress.

2.2.9. Giám sát và Ghi log (Monitoring & Logging)

Cloud Run tích hợp sâu với Cloud Logging và Cloud Monitoring.

Cloud Logging:
- Log từ container của bạn (stdout/stderr) được tự động thu thập.
- Log request HTTP đến dịch vụ (độ trễ, mã trạng thái, v.v.).
- Log hệ thống về trạng thái của instance.
- Có thể xem và filter log trong Logs Explorer.
Cloud Monitoring:
- Cung cấp các metrics quan trọng:
  - Request count (số lượng yêu cầu).
  - Request latency (độ trễ xử lý yêu cầu).
  - Container instance count (số lượng instance đang chạy - giúp thấy scaling và cold starts).
  - CPU/Memory utilization.
  - Request errors (lỗi HTTP 5xx).
  - Billing metrics.
- Giúp theo dõi hiệu năng, sức khỏe của dịch vụ, và debug các vấn đề liên quan đến scaling hoặc độ trễ.
Cloud Trace: Tích hợp với Cloud Trace để theo dõi đường đi của một request xuyên suốt nhiều dịch vụ (nếu ứng dụng của bạn có instrumented).

ACE Focus: Biết cách sử dụng Cloud Logging để xem log ứng dụng và request log. Biết các metrics chính trong Cloud Monitoring để theo dõi hiệu năng và scaling của dịch vụ Cloud Run.

2.2.10. Ưu điểm và nhược điểm

Ưu điểm:
- Sự linh hoạt của Container: Chạy bất kỳ ứng dụng nào đóng gói trong container, sử dụng framework và ngôn ngữ yêu thích.
- Serverless Simplicity: Không cần quản lý máy chủ hoặc cluster Kubernetes.
- Automatic Scaling mạnh mẽ với Concurrency: Tối ưu hiệu quả sử dụng tài nguyên và xử lý tải cao.
- Giảm thiểu Cold Start (có thể cấu hình min instances).
- Mô hình thanh toán pay-per-use hiệu quả.
- Hỗ trợ Custom Domains, SSL tự động, Traffic Splitting.
Nhược điểm:
- Yêu cầu ứng dụng phải stateless.
- Chủ yếu là request-driven (HTTP), không có background triggers trực tiếp như Cloud Functions (cần Eventarc hoặc Pub/Sub push).
- Giới hạn timeout (60 phút).
- Có thể phức tạp hơn Cloud Functions nếu bạn chỉ cần chạy một đoạn code rất nhỏ.
- Việc đóng gói vào container có thể là một bước làm quen ban đầu.

2.2.11. So sánh chi tiết với Cloud Functions và App Engine Standard

Đặc điểm	Cloud Functions (Gen 1)	Cloud Functions (Gen 2)	Cloud Run	App Engine Standard
Model	FaaS (Function-as-a-Service)	FaaS (Function-as-a-Service)	Serverless Containers	PaaS (Platform-as-a-Service)
Đơn vị triển khai	Hàm (Function)	Hàm (Function)	Container Image	Mã nguồn + config (`app.yaml`)
Runtime	Runtimes được quản lý (Node.js, Py, Go, Java, etc.)	Runtimes được quản lý (Node.js, Py, Go, Java, etc.)	Bất kỳ runtime nào trong container	Runtimes được quản lý (Node.js, Py, Java, PHP, Go, Ruby)
Trigger	HTTP, Background events (Pub/Sub, Storage, Firestore, etc.)	Eventarc (HTTP, 100+ GCP sources), Pub/Sub push	HTTP requests (chính), Pub/Sub push, Eventarc	HTTP requests
Scaling	Auto (0 -> Max), 1 request/instance	Auto (Min -> Max), Configurable Concurrency	Auto (Min -> Max), Configurable Concurrency	Auto (0 -> Max), Basic, Manual (instance-based)
Concurrency	1 request/instance	Configurable	Configurable (>1)	Không áp dụng (instance-based)
Cold Start	Có thể đáng kể	Giảm bớt (Min instances)	Giảm bớt (Min instances)	Ít hơn (đối với Auto scaling)
Stateless	Có	Có	Yêu cầu	Khuyến khích (để scale tốt)
Giới hạn Timeout	9 phút	60 phút	60 phút	10 phút (Requests), Worker > 10p (tùy runtime/scaling)
VPC Access	Có (VPC Connector)	Có (VPC Connector)	Có (VPC Connector)	Có (Native)
Pricing	Per invocation + Per resource-time	Per request + Per resource-time	Per request + Per resource-time	Per instance-hour + resource-use
Use Cases	Event handlers, webhooks, simple APIs, background tasks	Event handlers, webhooks, APIs, background tasks, flexible integrations	Microservices, APIs, Web Apps, containerized workloads	Web Apps, Mobile Backends, truyền thống PaaS

ACE Focus: Bảng so sánh này là CỰC KỲ quan trọng cho kỳ thi ACE. Bạn cần hiểu rõ sự khác biệt giữa Cloud Functions, Cloud Run và App Engine Standard để chọn dịch vụ phù hợp cho từng kịch bản. Hãy tập trung vào:

Loại trigger chính.
Đơn vị triển khai (Function vs Container vs App).
Hỗ trợ Concurrency.
Cách xử lý Cold Start (Min instances).
Khả năng chạy container tùy chỉnh (Run là duy nhất trong 3 cái này).
VPC Connector.

2.2.12. ACE Focus: Khi nào dùng Cloud Run?

Bạn muốn triển khai một microservice hoặc một API sử dụng framework/thư viện phức tạp mà Cloud Functions runtime có thể không hỗ trợ hoặc khó quản lý dependencies.
Bạn đã có sẵn ứng dụng đóng gói dưới dạng container image hoặc muốn sử dụng containerization.
Bạn cần một dịch vụ có thể xử lý nhiều yêu cầu đồng thời trên cùng một instance để tối ưu hiệu quả.
Bạn muốn giảm thiểu tác động của Cold Start bằng cách cấu hình số lượng instance tối thiểu luôn chạy.
Ứng dụng của bạn chủ yếu được kích hoạt bởi HTTP requests.
Bạn cần các tính năng như Traffic Splitting hoặc Custom Domains dễ dàng.

2.2.13. Links quan trọng:

Cloud Run Documentation: https://cloud.google.com/run/docs
Cloud Run Pricing: https://cloud.google.com/run/pricing
Building Containers for Cloud Run: https://cloud.google.com/run/docs/containerizing
Serverless VPC Access Documentation: https://cloud.google.com/vpc/docs/configure-serverless-vpc-access
Eventarc for Cloud Run: https://cloud.google.com/eventarc/docs/run/enable-run

Vậy là chúng ta đã hoàn thành phần chuyên sâu về Cloud Run. Bạn có thể thấy sự khác biệt rõ rệt giữa Cloud Functions và Cloud Run, đặc biệt là ở mô hình triển khai (Function vs Container), trigger và khả năng cấu hình scaling/concurrency.

Trước khi chuyển sang App Engine Standard và các dịch vụ serverless khác, bạn có câu hỏi nào về Cloud Run, cách nó hoạt động, hay sự khác biệt với Cloud Functions không? Đừng ngần ngại nhé!

*(Mentor Note: This part focused on Cloud Run, covering its core concepts, deployment, scaling, pricing, security, and comparison. The depth and ACE focus points are included. I will move on to App Engine Standard in the next part, and then cover the supporting serverless services and integration examples.)*Tuyệt vời, chúng ta sẽ tiếp tục hành trình khám phá thế giới Serverless trên Google Cloud với App Engine Standard Environment. Mặc dù là một trong những dịch vụ PaaS lâu đời nhất của Google, App Engine Standard vẫn giữ vị trí quan trọng, đặc biệt là trong ngữ cảnh Serverless Compute, và chắc chắn sẽ xuất hiện trong kỳ thi ACE.

(Tiếp tục Phần 2: Các Dịch Vụ Serverless Compute Chủ Đạo)

2.3. Google App Engine Standard Environment (GAE Standard)

2.3.1. Tổng quan: Nền tảng PaaS Serverless ban đầu

Google App Engine (GAE) ra mắt từ năm 2008, rất lâu trước khi thuật ngữ "Serverless" trở nên phổ biến. Nó là một nền tảng Platform-as-a-Service (PaaS) cho phép các nhà phát triển triển khai ứng dụng web mà không cần quản lý máy chủ. GAE có hai môi trường chính: Standard và Flexible. Trong ngữ cảnh Serverless, chúng ta chủ yếu tập trung vào App Engine Standard Environment.

App Engine Standard cung cấp một môi trường sandbox được quản lý hoàn toàn để chạy ứng dụng web của bạn. Google quản lý hệ điều hành, runtime, và scaling. Bạn chỉ cung cấp mã nguồn ứng dụng của mình.

Các đặc điểm chính (Environment Standard):

Request-driven: Được kích hoạt bởi các yêu cầu HTTP.
Managed Runtimes: Ứng dụng chạy trên các runtime cụ thể do Google cung cấp và quản lý.
Sandboxed Environment: Có một số hạn chế về quyền truy cập hệ thống file, thread, networking (trừ khi dùng VPC Connector).
Automatic Scaling: Tự động co giãn dựa trên lượng request (với chế độ Automatic Scaling).
Pay-per-Use (dựa trên Instance-hour): Thanh toán chủ yếu dựa trên số giờ các instance ứng dụng của bạn chạy, cùng với tài nguyên khác như network, storage.
Built-in Services: Cung cấp các dịch vụ tích hợp sẵn như Datastore (Firestore Native mode), Task Queues (cũ, nên dùng Cloud Tasks), Memcache, Cron Service, Users API. Một số dịch vụ này đã được chuyển sang các dịch vụ GCP độc lập và hiện đại hơn (ví dụ: Datastore -> Firestore, Task Queues -> Cloud Tasks).

2.3.2. Kiến trúc và cách hoạt động

App Engine Standard hoạt động bằng cách chạy code ứng dụng của bạn trên các máy chủ do Google quản lý trong một môi trường "sandbox" an toàn.

Bạn phát triển ứng dụng web của mình bằng một trong các ngôn ngữ được hỗ trợ và cấu hình nó bằng file app.yaml.
Bạn triển khai ứng dụng lên App Engine Standard. Google sẽ tự động build (nếu cần) và đưa code của bạn vào môi trường runtime.
App Engine tạo ra các instance để chạy ứng dụng của bạn. Mỗi instance là một môi trường riêng biệt chạy code của bạn.
Khi một yêu cầu HTTP đến ứng dụng của bạn, App Engine sẽ định tuyến request đó đến một instance đang chạy.
Instance xử lý request và trả về phản hồi.
Với chế độ Automatic Scaling, App Engine sẽ tự động tạo thêm instance khi lượng request tăng và tắt bớt instance khi request giảm (thậm chí về 0 instance khi không có traffic).
Môi trường sandbox giới hạn những gì code của bạn có thể làm để đảm bảo an toàn và khả năng mở rộng. Ví dụ: không thể ghi file tùy ý lên disk sau khi deploy, không thể tạo thread nền tùy ý, không thể thiết lập kết nối mạng đi (outbound connections) tùy ý (trừ khi dùng các thư viện hỗ trợ của GAE hoặc VPC Connector).

2.3.3. Các Runtime được hỗ trợ

App Engine Standard hỗ trợ các phiên bản runtime cụ thể và được quản lý bởi Google. Bạn không thể cài đặt phần mềm tùy ý hoặc thay đổi cấu hình OS.

Các runtime phổ biến (kiểm tra docs chính thức để cập nhật):

Python 2.7 (Legacy) & 3+ (Recommended)
Java 8 (Legacy) & 11+ (Recommended)
Node.js (các phiên bản gần đây)
PHP (các phiên bản gần đây)
Go (các phiên bản gần đây)
Ruby (các phiên bản gần đây)

Việc sử dụng các runtime được quản lý giúp giảm gánh nặng bảo trì, nhưng cũng có nghĩa là bạn phải tuân theo những gì runtime đó cung cấp.

ACE Focus: Biết rằng GAE Standard sử dụng các runtime được quản lý và giới hạn về ngôn ngữ/phiên bản so với Cloud Run.

2.3.4. Triển khai

Triển khai ứng dụng lên App Engine Standard dựa trên file cấu hình app.yaml.

Viết code ứng dụng: Phát triển ứng dụng web của bạn.

Tạo file app.yaml: File này mô tả cách App Engine nên chạy ứng dụng của bạn. Nó bao gồm runtime, phiên bản, cách xử lý URL (handlers), cấu hình scaling, biến môi trường, v.v.

Ví dụ app.yaml đơn giản:

yaml

runtime: python39
entrypoint: gunicorn -b :$PORT main:app

handlers:
- url: /.*
  script: auto

instance_class: F1 # Loại instance, ảnh hưởng đến CPU/memory và chi phí
manual_scaling: # Hoặc basic_scaling hoặc automatic_scaling
  instances: 1

Với automatic_scaling (chế độ serverless):

yaml

runtime: nodejs16
entrypoint: node server.js

handlers:
- url: /.*
  script: auto

automatic_scaling:
  max_instances: 10 # Số lượng instance tối đa
  min_instances: 0  # Số lượng instance tối thiểu
  target_cpu_utilization: 0.6 # Mục tiêu sử dụng CPU để scale
  target_throughput_utilization: 0.6 # Mục tiêu throughput để scale

Triển khai: Sử dụng gcloud CLI.
- gcloud app deploy --project PROJECT_ID --version YOUR_VERSION_ID --promote
- --project: Chỉ định dự án GCP.
- --version: ID cho phiên bản ứng dụng bạn đang triển khai (quan trọng cho versioning).
- --promote: Tự động chuyển tất cả lưu lượng truy cập đến phiên bản mới sau khi triển khai thành công. Nếu bỏ cờ này, bạn có thể chuyển đổi lưu lượng sau đó (traffic splitting).

ACE Focus: Nắm vững file app.yaml, đặc biệt là phần runtime, entrypoint, handlers, và cấu hình automatic_scaling (min/max instances, target utilization). Hiểu lệnh gcloud app deploy và ý nghĩa của --version và --promote.

2.3.5. Scaling (Tự động co giãn)

App Engine Standard có 3 chế độ scaling, nhưng chỉ Automatic Scaling là serverless hoàn toàn:

Automatic Scaling: Đây là chế độ mặc định và serverless. App Engine tạo và tắt các instance để duy trì hiệu suất tối ưu và giảm chi phí.
- Bạn có thể cấu hình min_instances, max_instances, và các ngưỡng kích hoạt scaling (CPU utilization, throughput utilization, latency).
- App Engine có thể scale về 0 instance khi không có traffic (nếu min_instances: 0), dẫn đến Cold Start cho request đầu tiên.
Basic Scaling: App Engine tạo instance khi nhận request, nhưng giữ một số instance hoạt động trong một thời gian nhất định sau khi xử lý xong request cuối cùng. Không scale về 0. Ít serverless hơn.
Manual Scaling: Bạn chỉ định số lượng instance cố định luôn chạy. Không serverless. Phù hợp cho các ứng dụng cần chạy liên tục hoặc các tác vụ nền không được kích hoạt bởi request.

ACE Focus: Hiểu rõ Automatic Scaling là chế độ serverless của GAE Standard. Biết cách cấu hình min_instances và max_instances trong app.yaml cho chế độ này. Hiểu sự khác biệt giữa Automatic, Basic, và Manual scaling.

2.3.6. Pricing (Mô hình tính cước)

Mô hình tính cước của GAE Standard chủ yếu dựa trên instance-hour:

Frontend Instance Hours: Tính phí cho thời gian các instance xử lý request. Có một lượng miễn phí hàng ngày.
Backend Instance Hours (cho Manual Scaling): Tính phí cho thời gian các instance chạy liên tục (chỉ áp dụng cho Manual Scaling).
Storage: Dung lượng dữ liệu được lưu trữ.
Network Egress: Dữ liệu truyền ra ngoài.
Services: Chi phí cho việc sử dụng các dịch vụ tích hợp sẵn (Firestore, Pub/Sub, v.v. - các dịch vụ này có mô hình giá riêng).

Free Tier: App Engine Standard có tầng miễn phí hàng ngày cho Instance Hours, Storage, Network Egress.

ACE Focus: Hiểu rằng pricing dựa trên instance-hour khi sử dụng Automatic Scaling, và có một tầng miễn phí hàng ngày. So sánh với mô hình pay-per-request/time của Functions/Run.

2.3.7. Use Cases (Trường hợp sử dụng điển hình)

App Engine Standard phù hợp cho:

Web Applications: Chạy các ứng dụng web truyền thống sử dụng các framework phổ biến.
Mobile Backends: Cung cấp API backend cho ứng dụng di động.
Các ứng dụng đã được xây dựng trên App Engine Standard từ trước: Tiếp tục phát triển và bảo trì các ứng dụng hiện có.

Khi nào KHÔNG nên dùng App Engine Standard:

Ứng dụng yêu cầu chạy môi trường runtime/ngôn ngữ không được GAE Standard hỗ trợ.
Ứng dụng cần cài đặt phần mềm tùy chỉnh ở cấp độ OS hoặc có yêu cầu về hệ thống file phức tạp.
Ứng dụng cần kiểm soát sâu vào môi trường thực thi (Flexible Environment hoặc Cloud Run/GKE tốt hơn).
Bạn muốn sử dụng containerization để đóng gói ứng dụng (Cloud Run hoặc GKE tốt hơn).
Tác vụ của bạn là xử lý sự kiện nhỏ, không liên quan đến HTTP request trực tiếp (Cloud Functions tốt hơn).

2.3.8. Deep Dive: Các tính năng và hạn chế

Services: Một ứng dụng App Engine có thể bao gồm nhiều "services" (trước đây gọi là "modules"). Mỗi service là một phần độc lập của ứng dụng và có thể được cấu hình scaling, runtime, và phiên bản riêng. Điều này hỗ trợ kiến trúc microservices ở một mức độ.
Versioning và Traffic Splitting: Tương tự Cloud Run, bạn có thể triển khai nhiều phiên bản của một service và chia lưu lượng truy cập giữa chúng để thử nghiệm A/B testing hoặc blue/green deployment.
Cron Service: App Engine có dịch vụ Cron tích hợp để lên lịch chạy các tác vụ định kỳ bằng cách gửi HTTP request đến một URL trong ứng dụng của bạn.
Sandboxing Limitations:
- Không thể ghi file tùy ý lên disk sau khi deploy (chỉ có thể đọc file đã deploy hoặc ghi vào /tmp).
- Không thể tạo thread nền tùy ý (chỉ các thread ngắn hạn để xử lý request).
- Các kết nối mạng đi (outbound) phải sử dụng các thư viện hỗ trợ của App Engine hoặc thông qua VPC Connector.
- Không thể gọi các thư viện native hoặc thay đổi kernel.

ACE Focus: Nắm vững các hạn chế của môi trường sandbox trong GAE Standard. Hiểu các khái niệm Services, Versioning và Traffic Splitting, Cron Service.

2.3.9. Bảo mật (Security)

IAM: Kiểm soát ai có quyền triển khai, quản lý, xem log, v.v., ứng dụng App Engine. Các vai trò như roles/appengine.developer.
Service Account: Ứng dụng App Engine chạy với danh tính của Service Account mặc định hoặc tùy chỉnh khi gọi các dịch vụ GCP khác.
App Engine Firewall: Cấu hình các quy tắc tường lửa để cho phép hoặc từ chối traffic đến ứng dụng dựa trên địa chỉ IP nguồn.
VPC Connector (Serverless VPC Access): Tương tự Functions/Run, cần sử dụng VPC Connector để ứng dụng GAE Standard truy cập tài nguyên nội bộ trong VPC (ví dụ: Cloud SQL private IP). GAE Standard có tích hợp VPC Connector.

ACE Focus: IAM, Service Account, App Engine Firewall, và VPC Connector là các điểm bảo mật chính cho ACE.

2.3.10. Giám sát và Ghi log (Monitoring & Logging)

Cloud Logging: Thu thập log từ ứng dụng của bạn (stdout/stderr), request logs, log hệ thống. Có thể xem trong Logs Explorer.
Cloud Monitoring: Metrics về hiệu suất ứng dụng:
- Request count.
- Latency.
- Error count/rate.
- Instance count.
- CPU/Memory usage.
- Có thể xem và thiết lập Alerts.

ACE Focus: Biết cách sử dụng Cloud Logging và Cloud Monitoring để theo dõi ứng dụng GAE Standard.

2.3.11. Ưu điểm và nhược điểm (Tóm lại)

Ưu điểm:
- Quản lý hoàn toàn, đơn giản cho các ứng dụng web truyền thống.
- Automatic Scaling tốt cho workload web.
- Tầng miễn phí hàng ngày.
- Các dịch vụ tích hợp sẵn (Cron).
- Lịch sử lâu đời, cộng đồng lớn.
Nhược điểm:
- Sandboxing Limitations (hạn chế quyền truy cập hệ thống, mạng).
- Giới hạn về runtime/phiên bản.
- Mô hình thanh toán instance-hour có thể kém hiệu quả hơn pay-per-request/time cho workload rất biến động.
- Cold Start có thể xảy ra khi scale từ 0.
- Không hỗ trợ container (so với Cloud Run/GAE Flex).

2.3.12. ACE Focus: Khi nào dùng App Engine Standard?

Bạn đang xây dựng một ứng dụng web hoặc backend di động truyền thống sử dụng một trong các ngôn ngữ được hỗ trợ bởi runtime của Standard Environment.
Bạn muốn một nền tảng PaaS đơn giản, được quản lý hoàn toàn, không cần lo lắng về máy chủ hoặc container.
Ứng dụng của bạn có thể hoạt động trong môi trường sandbox với các hạn chế đã biết.
Bạn muốn sử dụng các dịch vụ tích hợp sẵn của App Engine (Cron, Task Queue cũ).

Nếu bạn cần linh hoạt hơn về runtime, muốn sử dụng container, hoặc xây dựng microservices hiện đại hơn, Cloud Run có thể là lựa chọn tốt hơn. Nếu bạn chỉ cần phản ứng lại sự kiện nhỏ hoặc xây dựng API rất đơn giản, Cloud Functions có thể phù hợp hơn.

2.3.13. Links quan trọng:

App Engine Standard Documentation: https://cloud.google.com/appengine/docs/standard
App Engine Standard Pricing: https://cloud.google.com/appengine/pricing#standard_environment
App Engine Standard app.yaml Reference: https://cloud.google.com/appengine/docs/standard/python3/config/appref (ví dụ cho Python3, cấu trúc tương tự cho các runtime khác)
Serverless VPC Access for App Engine: https://cloud.google.com/vpc/docs/configure-serverless-vpc-access#app_engine_standard

3. Các Dịch Vụ Serverless khác hỗ trợ Compute

Các dịch vụ này không tự chạy code ứng dụng của bạn theo nghĩa truyền thống, nhưng chúng đóng vai trò quan trọng trong kiến trúc serverless, đặc biệt là trong việc kết nối và điều phối các dịch vụ serverless compute.

3.1. Workflows

Tổng quan: Workflows là một dịch vụ quản lý orchestration (điều phối) serverless. Nó cho phép bạn định nghĩa một chuỗi các bước (steps) để thực thi một tác vụ hoặc một quy trình nghiệp vụ. Các bước này có thể là việc gọi các dịch vụ khác của Google Cloud (như Cloud Functions, Cloud Run, các API của GCP), hoặc gọi các dịch vụ bên ngoài thông qua HTTP requests.

Cách hoạt động:

Bạn định nghĩa workflow bằng ngôn ngữ đặc tả riêng (dựa trên YAML hoặc JSON). Workflow này mô tả tuần tự các bước thực thi, bao gồm cả logic điều kiện, vòng lặp, xử lý lỗi.
Workflows service sẽ thực thi định nghĩa workflow của bạn từng bước một.
Mỗi bước có thể gọi một dịch vụ khác. Workflows sẽ chờ kết quả từ dịch vụ được gọi trước khi chuyển sang bước tiếp theo.
Workflows được thiết kế để có trạng thái (stateful), khác với tính stateless của Functions/Run. Trạng thái thực thi của workflow (đã hoàn thành bước nào, kết quả là gì, lỗi nếu có) được Workflows service quản lý. Điều này cho phép bạn xây dựng các quy trình dài và phức tạp.
Workflows có thể được kích hoạt bởi HTTP requests hoặc từ Cloud Scheduler.

Use Cases:

Orchestrating Serverless Services: Gọi một Cloud Function, sau đó gọi một Cloud Run service dựa trên kết quả của Function, rồi ghi kết quả cuối cùng vào Firestore.
Tự động hóa các tác vụ quản trị GCP: Chạy một loạt các lệnh API GCP theo trình tự (ví dụ: tạo VM, cấu hình mạng, deploy ứng dụng).
Tích hợp các hệ thống: Kết nối các API khác nhau, xử lý dữ liệu qua nhiều bước.
ETL nhẹ: Lấy dữ liệu từ nguồn A, xử lý bằng bước B, lưu vào đích C.

ACE Focus:

Hiểu vai trò của Workflows là dịch vụ orchestration serverless.
Biết rằng nó được dùng để kết nối và điều phối việc thực thi của các dịch vụ khác (đặc biệt là Cloud Functions và Cloud Run).
Nắm được tính stateful của Workflows (quản lý trạng thái của quy trình).
Biết nó có thể được kích hoạt qua HTTP hoặc Cloud Scheduler.

Links quan trọng:

Workflows Documentation: https://cloud.google.com/workflows/docs
Workflows Pricing: https://cloud.google.com/workflows/pricing

3.2. Eventarc

Tổng quan: Eventarc là một dịch vụ quản lý sự kiện serverless, tập trung vào việc kết nối các nguồn sự kiện (event sources) với các đích đến (event targets hay sinks) một cách đáng tin cậy và linh hoạt. Nó xây dựng một "kênh" cho phép sự kiện "chảy" từ nơi phát sinh đến nơi xử lý.

Cách hoạt động:

Eventarc lắng nghe các sự kiện từ nhiều nguồn khác nhau trong hệ sinh thái GCP (ví dụ: thay đổi trong Cloud Storage, tin nhắn Pub/Sub, thay đổi Firestore, log Audit Logs, v.v.) hoặc thậm chí các nguồn tùy chỉnh.
Khi một sự kiện xảy ra, Eventarc nhận nó.
Eventarc định tuyến sự kiện đến đích đã được cấu hình. Các đích có thể là:
- Cloud Functions (Gen 2): Eventarc là lớp nền tảng cho các background trigger của Cloud Functions Gen 2.
- Cloud Run: Có thể cấu hình Eventarc để gửi sự kiện (dưới dạng HTTP request) đến một dịch vụ Cloud Run.
- Google Kubernetes Engine (GKE): Gửi sự kiện đến các workfload trong GKE.
- Workflows: Kích hoạt một Workflow.
- Cloud Pub/Sub: Chuyển sự kiện thành tin nhắn Pub/Sub để các dịch vụ khác có thể tiêu thụ.
Eventarc sử dụng Cloud Pub/Sub nội bộ để đảm bảo việc gửi sự kiện đáng tin cậy (at-least-once delivery).

Use Cases:

Xây dựng kiến trúc hướng sự kiện (Event-Driven Architecture): Tách rời các thành phần của hệ thống. Ví dụ: một ứng dụng A ghi dữ liệu vào Firestore (phát ra sự kiện). Eventarc bắt sự kiện đó và gửi đến một dịch vụ Cloud Run xử lý dữ liệu (thành phần B) và một Cloud Function khác gửi thông báo (thành phần C). A không cần biết về B và C.
Tự động hóa dựa trên thay đổi trạng thái: Phản ứng lại các thay đổi trong các dịch vụ GCP mà không cần polling (liên tục kiểm tra).
Kết nối các hệ thống: Cho phép các hệ thống giao tiếp thông qua sự kiện.

ACE Focus:

Hiểu vai trò của Eventarc là một event bus serverless kết nối các nguồn sự kiện với các đích.
Biết rằng Eventarc là nền tảng trigger cho Cloud Functions Gen 2 và có thể kích hoạt Cloud Run và Workflows.
Hiểu rằng nó cho phép xây dựng kiến trúc hướng sự kiện bằng cách tách rời các thành phần.
Biết nó sử dụng Pub/Sub bên dưới để đảm bảo độ tin cậy.

Links quan trọng:

Eventarc Documentation: https://cloud.google.com/eventarc/docs
Eventarc Pricing: https://cloud.google.com/eventarc/pricing

4. Các Dịch Vụ Serverless Data & Messaging

Các dịch vụ này không phải là dịch vụ compute, nhưng chúng là các thành phần dữ liệu và nhắn tin quan trọng trong kiến trúc serverless. Chúng tự bản thân đã là serverless - bạn không quản lý máy chủ cho database, message queue hay storage của chúng.

4.1. Cloud Firestore

Tổng quan: Cloud Firestore là một cơ sở dữ liệu NoSQL document serverless và có tính năng real-time (thời gian thực). Nó có thể hoạt động ở hai chế độ: Native mode (mới hơn, tập trung vào mobile/web) và Datastore mode (tương thích ngược với Cloud Datastore). Cả hai đều là serverless.

Cách hoạt động:

Dữ liệu được tổ chức thành các Collections chứa các Documents. Documents có thể chứa dữ liệu phức tạp và cả Subcollections.
Firestore tự động scale để xử lý lượng đọc/ghi tăng lên.
Chế độ Native hỗ trợ cập nhật dữ liệu thời gian thực (client nhận thông báo khi dữ liệu thay đổi).
Pricing dựa trên số lần đọc/ghi/xóa document, dung lượng lưu trữ, và network bandwidth.

Use Cases:

Mobile và Web Application Backends: Lưu trữ dữ liệu người dùng, trạng thái ứng dụng.
Game State Storage: Lưu trạng thái của game.
Real-time Data Sync: Xây dựng các ứng dụng cần cập nhật dữ liệu ngay lập tức cho nhiều client.
User Profiles, Catalogs, etc.

Tích hợp Serverless Compute: Cloud Firestore là nguồn trigger phổ biến cho Cloud Functions (khi document được tạo, cập nhật, xóa) để thực hiện các hành động tự động dựa trên thay đổi dữ liệu. Các dịch vụ Cloud Run hoặc App Engine thường sử dụng Firestore làm backend database.

Deep Dive:

Data Model: Tập trung vào Collections và Documents.
Querying: Hỗ trợ các truy vấn phức tạp hơn so với Datastore truyền thống (ví dụ: truy vấn theo range, nhiều điều kiện lọc). Cần tạo Indexes cho các truy vấn phi tiêu chuẩn.
Security Rules: Ngôn ngữ cấu hình mạnh mẽ để kiểm soát quyền truy cập dữ liệu trực tiếp từ ứng dụng client (web/mobile) mà không cần logic bảo mật trên server.
Consistency Model: Strongly Consistent (ngay lập tức nhất quán) cho các giao dịch đọc/ghi.

ACE Focus:

Hiểu Firestore là database NoSQL document serverless.
Biết nó hỗ trợ real-time updates (chế độ Native).
Nắm được Data Model cơ bản (Collections, Documents).
Quan trọng nhất: Hiểu cách Firestore được sử dụng làm trigger cho Cloud Functions và là backend database cho Cloud Run/App Engine.
Biết về Security Rules (concept).

Links quan trọng:

Cloud Firestore Documentation: https://cloud.google.com/firestore/docs
Cloud Firestore Pricing: https://cloud.google.com/firestore/pricing
Firestore Security Rules: https://cloud.google.com/firestore/docs/security/get-started

4.2. Cloud Pub/Sub

Tổng quan: Cloud Pub/Sub là một dịch vụ nhắn tin (messaging) serverless, có khả năng co giãn cao và đáng tin cậy, hoạt động theo mô hình Publish/Subscribe.

Cách hoạt động:

Publisher: Hệ thống gửi tin nhắn (ví dụ: ứng dụng của bạn, một dịch vụ GCP khác) publish tin nhắn đến một Topic.
Topic: Là một kênh trung gian. Publisher gửi tin nhắn đến Topic, không cần biết ai sẽ nhận.
Subscriber: Hệ thống nhận tin nhắn (ví dụ: Cloud Functions, Cloud Run, Dataflow, ứng dụng của bạn) đăng ký nhận tin nhắn từ một Subscription đến Topic đó. Một Topic có thể có nhiều Subscriptions.
Subscription: Là một liên kết giữa Topic và Subscriber. Pub/Sub giữ các tin nhắn cho Subscription cho đến khi Subscriber xác nhận đã xử lý.
Delivery Model: Pub/Sub đảm bảo tin nhắn được gửi at-least-once (ít nhất một lần) đến mỗi Subscriber đăng ký. Subscriber cần xử lý việc trùng lặp nếu cần (idempotency).
Types of Subscriptions:
- Pull Subscription: Subscriber chủ động "kéo" tin nhắn từ Subscription. Thường dùng cho các ứng dụng chạy liên tục (VMs, GKE) hoặc các dịch vụ xử lý batch.
- Push Subscription: Pub/Sub chủ động "đẩy" tin nhắn dưới dạng HTTP POST request đến một endpoint đã cấu hình. Đây là cách Pub/Sub kích hoạt trực tiếp Cloud Functions (Gen 1) và có thể kích hoạt Cloud Run/App Engine. Endpoint nhận tin nhắn cần phản hồi HTTP 200 OK để xác nhận đã nhận.
Pricing dựa trên dung lượng tin nhắn được xử lý và dung lượng lưu trữ cho các tin nhắn chưa được xác nhận.

Use Cases:

Decoupling Services: Tách rời các thành phần của hệ thống. Thay vì gọi trực tiếp, các dịch vụ giao tiếp qua tin nhắn.
Data Ingestion/Streaming: Nhận và xử lý lượng lớn dữ liệu từ nhiều nguồn.
Asynchronous Communication: Thực hiện các tác vụ không cần phản hồi ngay lập tức.
Event-Driven Architectures: Sử dụng Pub/Sub làm trung tâm cho việc truyền tải sự kiện (Eventarc sử dụng Pub/Sub bên dưới).
Load Balancing for Background Tasks: Nhiều instance của cùng một Subscriber có thể cùng lắng nghe một Subscription, giúp chia tải xử lý tin nhắn.

Tích hợp Serverless Compute: Pub/Sub là nguồn trigger RẤT PHỔ BIẾN cho Cloud Functions. Nó cũng có thể cấu hình Push Subscription để gửi tin nhắn đến Cloud Run hoặc App Engine (trong trường hợp này, dịch vụ Cloud Run/App Engine hoạt động như một endpoint HTTP nhận request từ Pub/Sub).

ACE Focus:

Hiểu Pub/Sub là dịch vụ messaging serverless Publish/Subscribe.
Nắm được các khái niệm Topics và Subscribers.
Hiểu Pull vs. Push Subscriptions và biết Push Subscription là cách Pub/Sub kích hoạt Cloud Functions/Cloud Run/App Engine.
Hiểu Pub/Sub là một thành phần trung tâm trong các kiến trúc hướng sự kiện và tích hợp serverless.
Biết về đảm bảo gửi tin nhắn at-least-once.

Links quan trọng:

Cloud Pub/Sub Documentation: https://cloud.google.com/pubsub/docs
Cloud Pub/Sub Pricing: https://cloud.google.com/pubsub/pricing
Push Subscriptions: https://cloud.google.com/pubsub/docs/push

4.3. Cloud Storage

Tổng quan: Cloud Storage là dịch vụ lưu trữ đối tượng (object storage) serverless của Google Cloud. Nó cho phép bạn lưu trữ bất kỳ loại file nào (hình ảnh, video, tài liệu, backup, log, v.v.) dưới dạng "đối tượng" trong các "buckets".

Cách hoạt động:

Dữ liệu được tổ chức trong các Buckets duy nhất trên toàn cầu.
Mỗi đối tượng được lưu trữ trong một bucket với một tên duy nhất.
Có nhiều lớp lưu trữ (Storage Classes) khác nhau (Standard, Nearline, Coldline, Archive) với chi phí và thời gian truy cập khác nhau, phù hợp cho các mục đích sử dụng khác nhau (truy cập thường xuyên, ít thường xuyên, lưu trữ lâu dài).
Tự động co giãn để xử lý lượng dữ liệu và lượng request đọc/ghi bất kỳ.
Pricing dựa trên dung lượng lưu trữ, network egress, và số lượng hoạt động (operations) thực hiện trên dữ liệu.

Use Cases:

Lưu trữ bất kỳ loại file nào.
Data Lake: Lưu trữ dữ liệu thô hoặc bán cấu trúc cho phân tích sau này.
Backup và Archiving: Lưu trữ dữ liệu dự phòng hoặc cần lưu giữ lâu dài.
Hosting Static Websites: Phục vụ các file HTML, CSS, JavaScript, hình ảnh trực tiếp từ bucket.
Media Storage: Lưu trữ và phân phối video, âm thanh.

Tích hợp Serverless Compute: Cloud Storage là nguồn trigger phổ biến cho Cloud Functions. Khi một file được upload, cập nhật hoặc xóa trong một bucket cụ thể, nó có thể kích hoạt một hàm Cloud Functions để xử lý sự kiện đó (ví dụ: tạo thumbnail cho ảnh mới upload, phân tích nội dung file text). Các dịch vụ Cloud Run hoặc App Engine cũng thường đọc/ghi dữ liệu từ Cloud Storage.

ACE Focus:

Hiểu Cloud Storage là dịch vụ Object Storage serverless.
Nắm được khái niệm Buckets và Objects.
Biết nó là nguồn trigger trực tiếp cho Cloud Functions khi các đối tượng thay đổi.
Hiểu các lớp lưu trữ khác nhau (Standard, Nearline, Coldline, Archive) và mục đích sử dụng của chúng (liên quan đến chi phí và thời gian truy cập).
Biết nó thường là nơi lưu trữ dữ liệu đầu vào hoặc đầu ra cho các quy trình serverless.

Links quan trọng:

Cloud Storage Documentation: https://cloud.google.com/storage/docs
Cloud Storage Pricing: https://cloud.google.com/storage/pricing
Cloud Storage Trigger for Cloud Functions: https://cloud.google.com/functions/docs/calling/storage

4.4. BigQuery

Tổng quan: BigQuery là kho dữ liệu (data warehouse) serverless, có khả năng co giãn Petabyte, được thiết kế để phân tích dữ liệu lớn.

Cách hoạt động:

Dữ liệu được lưu trữ trong các bảng (tables) được quản lý.
Bạn chạy các truy vấn SQL trên dữ liệu mà không cần quản lý bất kỳ cơ sở hạ tầng nào.
BigQuery tự động co giãn tài nguyên tính toán (compute) để xử lý các truy vấn của bạn.
Pricing chủ yếu dựa trên lượng dữ liệu được quét khi chạy truy vấn (on-demand pricing) hoặc dựa trên dung lượng tài nguyên tính toán được dành riêng (flat-rate pricing). Lưu trữ dữ liệu cũng tính phí.

Use Cases:

Phân tích dữ liệu lớn (Big Data Analytics).
Business Intelligence (BI).
Data Warehousing.
Data Science và Machine Learning (với BigQuery ML).

Tích hợp Serverless: Mặc dù không phải là dịch vụ compute, BigQuery là một thành phần Serverless quan trọng trong các luồng xử lý dữ liệu. Dữ liệu thường được đưa vào BigQuery bởi các dịch vụ serverless khác (ví dụ: Cloud Functions/Cloud Run xử lý dữ liệu từ Pub/Sub hoặc Storage và ghi vào BigQuery). BigQuery cũng có thể phát ra sự kiện (qua Audit Logs) mà Cloud Functions có thể bắt và xử lý.

ACE Focus:

Hiểu BigQuery là dịch vụ Data Warehouse serverless cho phân tích dữ liệu lớn.
Biết mô hình pricing dựa trên lượng dữ liệu được quét khi chạy query (on-demand).
Hiểu vai trò của BigQuery là đích đến phổ biến cho dữ liệu được xử lý bởi các dịch vụ serverless compute.

Links quan trọng:

BigQuery Documentation: https://cloud.google.com/bigquery/docs
BigQuery Pricing: https://cloud.google.com/bigquery/pricing(Tiếp tục Phần 5 & 6: Tích Hợp Các Dịch Vụ Serverless & Bảo Mật)

5. Tích Hợp Các Dịch Vụ Serverless (Kiến trúc Serverless điển hình)

Kiến trúc Serverless không chỉ là việc sử dụng một dịch vụ serverless duy nhất, mà thường là sự kết hợp của nhiều dịch vụ khác nhau để xử lý các phần khác nhau của một ứng dụng hoặc quy trình. Đây là nơi sức mạnh tổng hợp của hệ sinh thái GCP Serverless được thể hiện rõ nhất.

Dưới đây là một vài ví dụ về các kiến trúc serverless phổ biến mà bạn có thể gặp trong thực tế và kỳ thi ACE:

5.1. Xử lý ảnh tự động:

Kịch bản: Người dùng upload ảnh lên website hoặc ứng dụng di động. Hệ thống cần tự động tạo phiên bản ảnh thumbnail và lưu trữ cả ảnh gốc lẫn thumbnail.
Kiến trúc Serverless:
- Ứng dụng (ví dụ: chạy trên Cloud Run hoặc App Engine) nhận ảnh từ người dùng và lưu trữ ảnh gốc vào một bucket Cloud Storage.
- Sự kiện "Object Finalized" (tạo/cập nhật đối tượng) trong bucket Cloud Storage đó sẽ kích hoạt một Cloud Function.
- Cloud Function nhận thông tin về file ảnh mới (tên file, bucket).
- Cloud Function đọc file ảnh gốc từ Cloud Storage, sử dụng thư viện xử lý ảnh để tạo thumbnail.
- Cloud Function lưu file thumbnail vào một bucket Cloud Storage khác (hoặc cùng bucket với một tiền tố/thư mục khác).
Tại sao Serverless?
- Cloud Storage tự động co giãn cho việc lưu trữ.
- Cloud Functions chỉ chạy khi có ảnh mới (pay-per-use), tự động co giãn theo số lượng ảnh upload. Không cần máy chủ luôn chạy chỉ để chờ ảnh.
ACE Focus: Hiểu cách Cloud Storage triggers Cloud Functions. Biết cách Cloud Functions đọc/ghi dữ liệu từ Cloud Storage.

5.2. Xây dựng API Microservices với Database Serverless:

Kịch bản: Xây dựng một hệ thống backend gồm nhiều dịch vụ nhỏ (microservices), mỗi dịch vụ cung cấp một tập hợp API cụ thể, và sử dụng database NoSQL.
Kiến trúc Serverless:
- Mỗi microservice được đóng gói trong một container và triển khai lên Cloud Run như một dịch vụ độc lập.
- Các dịch vụ Cloud Run này được cấu hình chỉ cho phép truy cập nội bộ (ingress=internal) hoặc qua Cloud Load Balancer (ingress=internal-and-cloud-load-balancing) để đảm bảo bảo mật.
- Các dịch vụ Cloud Run cần truy cập dữ liệu sẽ kết nối đến Cloud Firestore (NoSQL Database serverless).
- Để các dịch vụ Cloud Run có thể truy cập Firestore (hoặc các tài nguyên nội bộ khác như Cloud SQL Private IP), chúng phải được cấu hình sử dụng Serverless VPC Access Connector để có IP nội bộ.
- Các dịch vụ có thể giao tiếp với nhau qua HTTP (nội bộ qua VPC Connector) hoặc thông qua Cloud Pub/Sub cho các tác vụ bất đồng bộ.
Tại sao Serverless?
- Cloud Run cung cấp nền tảng linh hoạt, tự động co giãn cho từng microservice độc lập.
- Firestore là database serverless, không cần quản lý.
- Pub/Sub là message queue serverless để decoupling.
- Không cần quản lý VMs hay Kubernetes cluster cho các microservices.
ACE Focus: Hiểu cách dùng Cloud Run cho microservices, kết nối chúng với Firestore, và sử dụng VPC Connector cho truy cập nội bộ. Hiểu vai trò của Pub/Sub cho giao tiếp bất đồng bộ giữa các services.

5.3. Xử lý luồng dữ liệu (Streaming Data Processing):

Kịch bản: Nhận một lượng lớn dữ liệu liên tục (ví dụ: log từ thiết bị IoT, clickstreams từ website) và xử lý chúng theo thời gian thực.
Kiến trúc Serverless:
- Nguồn dữ liệu publish tin nhắn đến một Cloud Pub/Sub Topic. Pub/Sub hoạt động như một buffer (bộ đệm) và là điểm đầu vào cho luồng dữ liệu.
- Một Cloud Function hoặc một dịch vụ Cloud Run (được cấu hình với Pub/Sub Push Subscription hoặc được kích hoạt bởi Eventarc từ Pub/Sub) đăng ký nhận tin nhắn từ Topic Pub/Sub đó.
- Hàm/service serverless xử lý từng tin nhắn (ví dụ: parse dữ liệu, làm sạch, biến đổi).
- Dữ liệu đã xử lý có thể được lưu vào Cloud Firestore, BigQuery (để phân tích), hoặc lưu trữ tạm thời vào Cloud Storage.
Tại sao Serverless?
- Pub/Sub co giãn vô hạn để nhận lượng dữ liệu bất kỳ.
- Functions/Run tự động co giãn theo số lượng tin nhắn trong Pub/Sub, chỉ chạy khi có tin nhắn.
- Firestore/BigQuery/Storage là serverless cho lưu trữ/phân tích.
ACE Focus: Hiểu vai trò trung tâm của Pub/Sub trong xử lý luồng dữ liệu serverless. Biết cách Pub/Sub triggers Cloud Functions/Cloud Run.

5.4. Orchestration các tác vụ phức tạp:

Kịch bản: Cần thực hiện một quy trình gồm nhiều bước phụ thuộc lẫn nhau, có logic điều kiện và xử lý lỗi.
Kiến trúc Serverless:
- Sử dụng Workflows để định nghĩa chuỗi các bước.
- Mỗi bước trong Workflow có thể gọi:
  - Một Cloud Function (ví dụ: thực hiện một tính toán nhỏ).
  - Một Cloud Run Service (ví dụ: gọi một API của microservice).
  - Các API của các dịch vụ GCP khác (ví dụ: kiểm tra trạng thái của một tài nguyên).
- Workflow quản lý trạng thái và chuyển đổi giữa các bước.
Tại sao Serverless? Workflows là dịch vụ orchestration serverless, bạn không cần chạy máy chủ chỉ để điều phối các tác vụ khác. Các dịch vụ được gọi (Functions, Run) cũng là serverless.
ACE Focus: Hiểu Workflows được dùng để điều phối (orchestrate) các dịch vụ serverless khác.

Tóm lại về tích hợp: Các dịch vụ serverless của GCP được thiết kế để hoạt động cùng nhau một cách liền mạch. Hiểu cách kết nối chúng (triggering, API calls, Pub/Sub messaging, shared storage/database) là rất quan trọng. Pub/Sub và Eventarc đóng vai trò là "keo" kết nối các thành phần hướng sự kiện, trong khi Workflows đóng vai trò "nhạc trưởng" điều phối các quy trình.

6. Bảo Mật trong Serverless (Tập trung vào ACE)

Bảo mật là một chủ đề cốt lõi trong kỳ thi ACE, và việc áp dụng nó cho kiến trúc serverless đòi hỏi sự hiểu biết cụ thể. Các điểm chính cần lưu ý:

6.1. IAM (Identity and Access Management):

Kiểm soát ai (principal - user, group, Service Account) có quyền thực hiện hành động gì (permissions) trên tài nguyên nào (resource - Cloud Function, Cloud Run service, Pub/Sub topic, Firestore database, etc.) trong dự án của bạn.
Nguyên tắc đặc quyền tối thiểu (Principle of Least Privilege): Luôn cấp quyền tối thiểu cần thiết.
- Người triển khai (Deployer): Cần quyền deploy (cloudfunctions.functions.deploy, run.services.create, appengine.applications.create, appengine.versions.create, etc.). Các vai trò như roles/cloudfunctions.developer, roles/run.developer, roles/appengine.developer.
- Người gọi hàm/service (Invoker):
  - Cloud Functions (HTTP) / Cloud Run (HTTP): Mặc định yêu cầu xác thực. Người gọi cần có quyền cloudfunctions.functions.invoke (cho Functions) hoặc run.services.invoke (cho Run). Bạn có thể cho phép truy cập công khai bằng cách gán vai trò roles/cloudfunctions.invoker hoặc roles/run.invoker cho principal allUsers (không khuyến khích cho ứng dụng nội bộ).
  - Cloud Functions (Background) / Cloud Run (Eventarc/Pub/Sub Push): Việc kích hoạt bởi sự kiện được quản lý bởi nền tảng. Bạn cần đảm bảo Service Account của nguồn sự kiện có quyền cần thiết để publish event hoặc gọi đích (với Gen 2/Eventarc).
ACE Focus: Hiểu rõ cách cấp quyền Invoke cho Functions và Cloud Run (qua allUsers cho công khai hoặc gán vai trò invoker cho user/Service Account cụ thể). Nắm vững nguyên tắc đặc quyền tối thiểu khi cấp quyền deploy và invoke.

6.2. Service Accounts:

Service Account là danh tính của ứng dụng (thay vì người dùng cuối).
Khi một dịch vụ serverless (Cloud Functions, Cloud Run, App Engine Standard, Workflows) cần gọi một dịch vụ GCP khác hoặc truy cập tài nguyên (Firestore, Pub/Sub, Cloud Storage, BigQuery, Secret Manager, v.v.), nó sẽ sử dụng danh tính của Service Account được gán cho nó.
Mặc định, chúng sử dụng Service Account mặc định của App Engine hoặc Compute Engine (Project ID@appspot.gserviceaccount.com). Tuy nhiên, khuyến khích tạo Service Account riêng cho mỗi dịch vụ với chỉ các quyền cần thiết để tương tác với các dịch vụ khác.
Ví dụ: Một Cloud Function đọc từ Cloud Storage và ghi vào Firestore. Service Account của hàm đó chỉ cần quyền đọc Cloud Storage (roles/storage.objectViewer) và quyền ghi Firestore (roles/datastore.user hoặc các quyền Firestore cụ thể hơn).
ACE Focus: Hiểu Service Account là danh tính của ứng dụng serverless khi tương tác với các dịch vụ GCP khác. Biết cách chỉ định Service Account khi triển khai (--service-account flag). Hiểu nguyên tắc cấp quyền tối thiểu cho Service Account.

6.3. Serverless VPC Access (VPC Connector):

Đây là một trong những chủ đề bảo mật và mạng quan trọng nhất cho Serverless trong ACE.
Mặc định, các dịch vụ serverless (Functions, Run, App Engine Standard) chạy trong mạng của Google và không có địa chỉ IP nội bộ trong VPC của bạn. Do đó, chúng không thể truy cập các tài nguyên chỉ có IP nội bộ (ví dụ: Cloud SQL instance chỉ có Private IP, Compute Engine VM không có IP công khai, Memorystore, GKE internal services).
Serverless VPC Access Connector: Là một tài nguyên mạng được tạo trong VPC của bạn. Khi bạn cấu hình một dịch vụ serverless sử dụng connector này, lưu lượng truy cập đi ra từ dịch vụ serverless đến các tài nguyên trong VPC sẽ đi qua connector và sử dụng địa chỉ IP nội bộ từ subnet của connector.
Cấu hình: Bạn tạo connector trong VPC (chọn region, subnet, cấu hình scale). Sau đó, khi triển khai dịch vụ serverless, bạn chỉ định sử dụng connector đó (--vpc-connector=CONNECTOR_NAME).
Lưu ý:
- Connector chỉ áp dụng cho traffic đi ra (egress) từ dịch vụ serverless vào VPC. Traffic đến dịch vụ serverless (ingress) được quản lý bằng IAM, Ingress settings (Cloud Run), hoặc Firewall App Engine.
- Bạn cần cấu hình Firewall Rules trong VPC để cho phép traffic từ subnet của connector đến tài nguyên đích (ví dụ: cho phép traffic từ dải IP của connector đến port 3306 của Cloud SQL instance).
ACE Focus: Tuyệt đối phải hiểu Serverless VPC Access Connector. Biết tại sao cần nó (truy cập tài nguyên nội bộ/private IP). Biết cách cấu hình và áp dụng nó cho Cloud Functions, Cloud Run, và App Engine Standard. Hiểu rằng nó xử lý traffic egress vào VPC và cần cấu hình Firewall Rules phù hợp.

6.4. Cloud Run Ingress Settings:

Như đã đề cập ở phần Cloud Run, Ingress settings kiểm soát nguồn traffic đến dịch vụ Cloud Run:
- all: Cho phép từ bất kỳ đâu (cần thêm allow-unauthenticated).
- internal: Chỉ cho phép từ trong VPC của bạn (khi dùng VPC Connector) hoặc từ các dịch vụ GCP khác trong cùng mạng.
- internal-and-cloud-load-balancing: Cho phép từ VPC và từ Cloud Load Balancer.
Sử dụng internal hoặc internal-and-cloud-load-balancing là cách bảo mật dịch vụ Cloud Run khỏi truy cập công cộng, chỉ cho phép traffic từ mạng nội bộ hoặc qua Load Balancer (đã được cấu hình bảo mật).
ACE Focus: Biết các chế độ Ingress của Cloud Run và khi nào sử dụng internal hoặc internal-and-cloud-load-balancing để giới hạn truy cập.

6.5. Cloud Firestore Security Rules:

Đối với các ứng dụng web/mobile tương tác trực tiếp với Firestore (không qua backend serverless), bạn sử dụng Firestore Security Rules (ngôn ngữ cấu hình riêng) để định nghĩa ai có quyền đọc, ghi, cập nhật, xóa tài liệu nào dựa trên danh tính người dùng đã xác thực (Firebase Authentication, Google Identity Platform) và dữ liệu trong database.
Điều này giúp thực thi logic bảo mật ở tầng database mà không cần viết code backend phức tạp cho các trường hợp đơn giản.
ACE Focus: Biết về Firestore Security Rules như một cách để bảo mật truy cập dữ liệu trực tiếp từ client trong kiến trúc serverless.

6.6. Identity Platform / Firebase Authentication:

Nếu ứng dụng serverless của bạn có người dùng cuối, bạn cần một cách để xác thực và quản lý người dùng đó. Google Cloud cung cấp Identity Platform và Firebase Authentication cho mục đích này.
Sau khi người dùng được xác thực, bạn có thể sử dụng danh tính của họ trong Firestore Security Rules hoặc truyền thông tin xác thực đến các dịch vụ backend (Cloud Run, Cloud Functions) để xử lý logic nghiệp vụ dựa trên người dùng.
ACE Focus: Biết về Identity Platform/Firebase Authentication là giải pháp quản lý người dùng cho ứng dụng serverless.

6.7. Quản lý Secrets:

Ứng dụng thường cần truy cập secrets (mật khẩu database, khóa API). Không bao giờ lưu secrets trong mã nguồn hoặc file cấu hình được deploy.
Sử dụng Secret Manager (dịch vụ quản lý secrets tập trung, được mã hóa). Các dịch vụ serverless (Functions, Run, App Engine) có thể được cấp quyền (qua Service Account của chúng) để đọc secrets từ Secret Manager khi khởi động hoặc khi cần.
ACE Focus: Biết Secret Manager là giải pháp quản lý secrets an toàn cho ứng dụng serverless và cách dịch vụ serverless truy cập secrets bằng cách sử dụng Service Account.

Tóm lại về Bảo mật: Bảo mật Serverless trong ACE xoay quanh việc hiểu IAM (quyền deploy/invoke), Service Accounts (danh tính ứng dụng), Serverless VPC Access (truy cập mạng nội bộ), Ingress control (kiểm soát traffic đến), và các công cụ quản lý dữ liệu/secrets an toàn (Firestore Security Rules, Secret Manager).

7. Giám Sát và Ghi log Serverless (Tập trung vào ACE)

Giám sát (Monitoring) và ghi log (Logging) là cực kỳ quan trọng trong môi trường serverless, nơi bạn không có quyền truy cập trực tiếp vào máy chủ. Bạn phải dựa vào các công cụ được cung cấp bởi nền tảng đám mây. Google Cloud cung cấp bộ công cụ mạnh mẽ là Cloud Logging và Cloud Monitoring (trước đây là Stackdriver) để làm điều này.

7.1. Cloud Logging:

Mục đích: Thu thập, xem, tìm kiếm, lọc, và phân tích log từ các dịch vụ Google Cloud và ứng dụng của bạn.
Cách hoạt động với Serverless:
- Application Logs: Bất kỳ thứ gì ứng dụng của bạn ghi ra stdout hoặc stderr sẽ tự động được thu thập bởi Cloud Logging.
  - Cloud Functions: console.log(), print().
  - Cloud Run: Output từ container của bạn.
  - App Engine Standard: Output từ ứng dụng của bạn.
- Request Logs: Cloud Logging tự động thu thập thông tin chi tiết về mỗi yêu cầu HTTP đến các dịch vụ request-driven như Cloud Functions (HTTP), Cloud Run, App Engine. Thông tin này bao gồm thời gian request đến, thời gian xử lý, mã trạng thái HTTP, độ trễ, v.v.
- Platform Logs: Log về các sự kiện xảy ra ở cấp độ nền tảng (ví dụ: instance của Cloud Functions bắt đầu chạy, instance của Cloud Run scale up/down, triển khai phiên bản App Engine mới).
Xem Log: Sử dụng giao diện Logs Explorer trong Cloud Console. Bạn có thể lọc log theo dịch vụ (Cloud Function, Cloud Run Revision, App Engine Version), tên hàm/service, mức độ nghiêm trọng (INFO, WARNING, ERROR), text search, v.v.
Logging Sink: Bạn có thể định tuyến log đến các đích khác (ví dụ: BigQuery cho phân tích log nâng cao, Pub/Sub cho xử lý log luồng, Cloud Storage để lưu trữ lâu dài).
ACE Focus:
- Biết cách xem Application Logs để debug mã nguồn của bạn (output ra stdout/stderr).
- Biết cách xem Request Logs để phân tích hiệu suất và lỗi của các dịch vụ request-driven.
- Biết cách sử dụng Logs Explorer để tìm kiếm và lọc log theo dịch vụ, tên tài nguyên, mức độ nghiêm trọng.

7.2. Cloud Monitoring:

Mục đích: Thu thập các chỉ số (metrics) về hiệu suất và sức khỏe của các tài nguyên đám mây của bạn, tạo biểu đồ, dashboards, và thiết lập cảnh báo (alerting).
Cách hoạt động với Serverless: Cung cấp các metrics tích hợp sẵn cho từng dịch vụ serverless:
- Cloud Functions: Execution count (số lần gọi), Execution time (độ trễ), Error count/rate, Instance count, Memory/CPU utilization.
- Cloud Run: Request count, Request latency, Container instance count, CPU/Memory utilization, Request errors.
- App Engine Standard: Request count, Latency, Error count/rate, Instance count, Resource utilization (CPU, Memory, Disk, Network).
- Firestore: Read/Write/Delete count, Latency, Storage size.
- Pub/Sub: Publish/Subscribe throughput, Undelivered messages, Oldest unacked message age.
- Cloud Storage: Storage capacity, Network egress, Operation count.
Xem Metrics: Sử dụng Metrics Explorer trong Cloud Console để tạo biểu đồ tùy chỉnh, hoặc xem dashboards tích hợp sẵn cho từng dịch vụ trong giao diện của dịch vụ đó.
Alerting: Thiết lập các chính sách cảnh báo dựa trên các ngưỡng metrics. Ví dụ: gửi thông báo khi tỷ lệ lỗi của Cloud Function vượt quá 5%, hoặc khi số lượng instance của Cloud Run đạt đến giới hạn tối đa.
Dashboards: Tạo dashboards tùy chỉnh kết hợp các biểu đồ từ nhiều dịch vụ khác nhau để có cái nhìn tổng quan về hệ thống.
ACE Focus:
- Biết các metrics chính có sẵn cho từng dịch vụ serverless compute (request count, latency, error rate, instance count, utilization).
- Biết cách sử dụng Metrics Explorer để xem các biểu đồ về hiệu suất.
- Hiểu cách thiết lập Alerting để nhận thông báo về các vấn đề.
- Biết Cloud Monitoring là nơi bạn kiểm tra hiệu suất và sức khỏe của các dịch vụ serverless.

7.3. Cloud Trace (cho Cloud Run, App Engine Standard):

Mục đích: Theo dõi đường đi của một yêu cầu xuyên suốt nhiều dịch vụ trong ứng dụng phân tán (microservices).
Cách hoạt động với Serverless: Khi một yêu cầu đến một dịch vụ (ví dụ: Cloud Run) và dịch vụ đó gọi các dịch vụ khác (ví dụ: một Cloud Function, một dịch vụ Cloud Run khác, truy vấn Firestore), Cloud Trace (nếu các dịch vụ được instrumented) có thể hiển thị một biểu đồ thời gian (timeline) cho thấy mất bao lâu ở mỗi bước.
Giúp xác định bottleneck trong các kiến trúc sử dụng nhiều dịch vụ serverless gọi lẫn nhau.
ACE Focus: Biết Cloud Trace có thể giúp phân tích độ trễ trong các kiến trúc serverless phân tán (đặc biệt là với Cloud Run và App Engine).

Tóm lại về Giám sát và Ghi log: Cloud Logging và Cloud Monitoring là bộ đôi không thể thiếu để quản lý các ứng dụng serverless. Cloud Logging để hiểu tại sao điều gì đó xảy ra (qua log), và Cloud Monitoring để hiểu điều gì đang xảy ra (qua metrics). Cloud Trace giúp phân tích hiệu năng trong các hệ thống phân tán. Nắm vững cách sử dụng các công cụ này là rất quan trọng cho ACE.

8. Lựa Chọn Dịch Vụ Serverless Phù Hợp (ACE Perspective)

Đây là một trong những kỹ năng quan trọng nhất được kiểm tra trong kỳ thi ACE: dựa vào một kịch bản hoặc yêu cầu cụ thể, bạn phải chọn dịch vụ serverless (hoặc đôi khi không serverless) phù hợp nhất.

Dưới đây là một số yếu tố và cách tiếp cận để đưa ra quyết định:

8.1. Yếu tố quyết định:

Use Case / Loại ứng dụng:
- Xử lý sự kiện từ các nguồn GCP (Storage, Pub/Sub, Firestore)? -> Cloud Functions (background triggers), hoặc Cloud Run/Workflows (qua Eventarc/PubSub push).
- Xây dựng Webhook? -> Cloud Functions (HTTP) hoặc Cloud Run.
- Xây dựng API đơn giản/logic nhỏ? -> Cloud Functions (HTTP).
- Xây dựng Microservices hoặc API phức tạp hơn? -> Cloud Run.
- Xây dựng ứng dụng web truyền thống? -> Cloud Run hoặc App Engine Standard.
- Xử lý luồng dữ liệu? -> Pub/Sub kết hợp với Cloud Functions hoặc Cloud Run.
- Điều phối các tác vụ/workflow phức tạp? -> Workflows.
- Lưu trữ file? -> Cloud Storage.
- Lưu trữ database NoSQL document? -> Cloud Firestore.
- Data Warehouse / Phân tích dữ liệu lớn? -> BigQuery.
Môi trường thực thi / Ngôn ngữ / Framework:
- Cần chạy một đoạn code nhỏ bằng ngôn ngữ phổ biến, không cần framework phức tạp? -> Cloud Functions.
- Cần chạy container tùy chỉnh, sử dụng framework bất kỳ, hoặc cần kiểm soát môi trường runtime cao hơn? -> Cloud Run.
- Ứng dụng web truyền thống bằng các ngôn ngữ/phiên bản được hỗ trợ cụ thể? -> App Engine Standard.
Scaling Requirements:
- Cần scale tự động từ 0 dựa trên sự kiện/request? -> Cả 3 (Functions, Run, GAE Standard Automatic).
- Cần xử lý nhiều request đồng thời trên một instance? -> Cloud Run (Concurreny). Functions Gen 2 cũng có concurrency. GAE Standard thì mỗi instance chỉ xử lý 1 request tại một thời điểm (nhưng platform quản lý việc khởi tạo nhiều instance).
- Nhạy cảm với Cold Start? -> Cloud Run hoặc Cloud Functions Gen 2 (với min-instances > 0), hoặc App Engine Standard Automatic (với min_instances > 0 trong app.yaml).
Thời gian thực thi (Execution Duration):
- Tác vụ ngắn (<9 phút cho Functions Gen 1, <60 phút cho Functions Gen 2/Run, <10 phút cho GAE Standard Request)? -> Tất cả đều phù hợp.
- Tác vụ dài hơn (>9 phút, <60 phút)? -> Cloud Run hoặc Cloud Functions Gen 2.
- Tác vụ rất dài hoặc chạy liên tục? -> Compute Engine, GKE, hoặc App Engine Flexible (không serverless hoàn toàn theo định nghĩa chặt chẽ).
Quản lý Trạng thái (State):
- Ứng dụng/tác vụ là stateless? -> Cả 3 (Functions, Run, GAE Standard) đều phù hợp.
- Ứng dụng/tác vụ cần trạng thái liên tục trên disk hoặc trong memory giữa các request? -> Không phù hợp với Serverless Compute (Functions, Run, GAE Standard). Cân nhắc GKE hoặc Compute Engine. Nếu trạng thái có thể lưu bên ngoài (database, cache), Serverless vẫn phù hợp.
Kết nối mạng nội bộ (VPC Access):
- Cần truy cập tài nguyên trong VPC (private IP)? -> Cả 3 (Functions, Run, GAE Standard) đều hỗ trợ Serverless VPC Access Connector. Đây là một yếu tố quyết định quan trọng nếu ứng dụng cần kết nối database nội bộ, v.v.
Chi phí (Pricing Model):
- Workload rất biến động, có thể có thời gian không có traffic, muốn pay-per-use chính xác? -> Cloud Functions, Cloud Run.
- Workload có traffic tương đối ổn định hoặc chấp nhận trả tiền cho instance nhàn rỗi để giảm Cold Start? -> Cloud Run/Functions Gen 2 (với min instances > 0) hoặc App Engine Standard Automatic.

8.2. Flowchart đơn giản (trong đầu bạn):

Tác vụ này được kích hoạt bởi cái gì?
- HTTP Request? -> Functions (HTTP), Run, GAE Standard.
- Background Event (Storage, Pub/Sub, Firestore)? -> Functions (background trigger), hoặc Run/Workflows (qua Eventarc/PubSub push).
- Lịch trình (Schedule)? -> Cloud Scheduler gọi Functions (HTTP), Run, GAE Standard, hoặc Workflows.
Ứng dụng/Code của tôi là gì?
- Một đoạn code nhỏ, một hàm xử lý một sự kiện cụ thể? -> Functions.
- Một ứng dụng đầy đủ với framework, cần đóng gói container? -> Run.
- Một ứng dụng web truyền thống bằng ngôn ngữ/phiên bản được GAE Standard hỗ trợ? -> GAE Standard.
Có cần xử lý nhiều request đồng thời trên một instance không? -> Có -> Cloud Run (hoặc Functions Gen 2). Không -> Functions Gen 1, GAE Standard.
Có nhạy cảm với Cold Start không? -> Có -> Run/Functions Gen 2 (min instances > 0) hoặc GAE Standard Automatic (min_instances > 0).
Có cần truy cập tài nguyên nội bộ (private IP) trong VPC không? -> Có -> Cần Serverless VPC Access Connector -> Functions, Run, GAE Standard đều hỗ trợ.
Thời gian chạy có vượt quá giới hạn timeout của Functions/Run/GAE không? -> Có -> Serverless Compute có thể không phù hợp.

ACE Focus: Thực hành phân tích các kịch bản và lựa chọn dịch vụ. Đọc kỹ câu hỏi và các yêu cầu (trigger, ngôn ngữ, statelessness, scaling, networking, cost).

9. Tips Chuẩn Bị Cho Kỳ Thi ACE với Serverless

Serverless là một chủ đề quan trọng trong ACE, chiếm một phần đáng kể các câu hỏi. Để ôn tập hiệu quả, hãy tập trung vào các điểm sau:

Tập trung vào "Use Cases" và "When to Use": Đây là loại câu hỏi phổ biến nhất. Đề bài sẽ đưa ra một kịch bản và hỏi bạn nên sử dụng dịch vụ nào. Hãy ôn lại phần "Use Cases" và "Khi nào dùng..." của từng dịch vụ (Cloud Functions 2.1.13, Cloud Run 2.2.12, App Engine Standard 2.3.12) và bảng so sánh chi tiết (2.2.11). Hãy tự hỏi: Sự kiện gì kích hoạt? Cần chạy loại code gì? Có cần container không? Có cần xử lý nhiều request đồng thời không? Có cần truy cập VPC nội bộ không?
Hiểu rõ sự khác biệt giữa Cloud Functions, Cloud Run, và App Engine Standard: Nắm chắc bảng so sánh (2.2.11) về Trigger, Đơn vị triển khai, Runtime, Scaling (Min/Max instances, Concurrency), Cold Start, Timeout.
Nắm vững Serverless VPC Access (VPC Connector): Đây là chủ đề kỹ thuật thường xuất hiện. Hiểu TẠI SAO cần nó (truy cập private IP trong VPC) và CÁCH cấu hình/áp dụng cho cả 3 dịch vụ compute chính. Biết rằng nó xử lý traffic EGRESS và cần Firewall Rules. (Xem lại phần 6.3).
Hiểu cách các dịch vụ tích hợp với nhau:
- Nguồn trigger phổ biến cho Cloud Functions/Run/GAE: Pub/Sub, Cloud Storage, Firestore (xem lại phần 2.1.3, 4.1, 4.2, 4.3, 5).
- Database/Storage phổ biến: Firestore, Cloud Storage, BigQuery (xem lại phần 4).
- Orchestration: Workflows gọi Functions/Run/APIs (xem lại phần 3.1, 5.4).
- Eventing Bus: Eventarc kết nối các nguồn/đích serverless (xem lại phần 3.2).
Bảo mật: Ôn tập lại IAM (quyền invoke, roles), Service Accounts (danh tính ứng dụng, least privilege), và Serverless VPC Access (xem lại phần 6).
Giám sát và Ghi log: Biết sử dụng Cloud Logging để xem log ứng dụng và request log. Biết sử dụng Cloud Monitoring để xem các metrics hiệu suất (latency, error rate, instance count). (Xem lại phần 7).
Thực hành (Hands-on): Lý thuyết rất quan trọng, nhưng không gì thay thế được việc thực hành. Hãy sử dụng Qwiklabs hoặc Google Cloud Skills Boost (tìm các lab về Cloud Functions, Cloud Run, App Engine, Pub/Sub, Firestore, VPC Connector). Tự tay triển khai một vài kiến trúc serverless đơn giản sẽ giúp bạn củng cố kiến thức rất nhiều.
Đọc Documentation chính thức: Tài liệu của Google Cloud là nguồn thông tin chính xác và đầy đủ nhất. Đọc kỹ các trang tổng quan (Overview), cách hoạt động (How it works), Use Cases, và Cấu hình (Configuration/Deployment) cho các dịch vụ serverless chính.
Ôn tập các câu hỏi mẫu: Tìm kiếm các câu hỏi mẫu về ACE trên các nền tảng uy tín để làm quen với định dạng và loại câu hỏi về serverless.

Các điểm kỹ thuật cụ thể cần lưu ý cho ACE:

Cách cấu hình trigger cho Cloud Functions (qua gcloud flags).
Cách deploy container lên Cloud Run (gcloud run deploy, --image, --concurrency, --min-instances, --max-instances).
Cách cấu hình scaling trong app.yaml cho App Engine Standard Automatic scaling (min_instances, max_instances).
Mục đích và cấu hình cơ bản của Serverless VPC Access Connector.
Cách một dịch vụ serverless sử dụng Service Account để truy cập dịch vụ khác.
Cách xem log và metrics trong Cloud Logging/Monitoring.

10. Kết luận và Hướng đi tiếp theo

Chúc mừng bạn đã dành thời gian đi sâu vào thế giới Serverless trên Google Cloud! Đây là một lĩnh vực năng động và ngày càng quan trọng trong phát triển ứng dụng đám mây. Bằng việc nắm vững các dịch vụ này, bạn không chỉ chuẩn bị tốt cho kỳ thi ACE mà còn trang bị cho mình những kỹ năng giá trị cho sự nghiệp Cloud của mình.

Để tiếp tục hành trình của bạn:

Review: Đọc lại các phần đã thảo luận, đặc biệt là các mục "ACE Focus" và bảng so sánh.
Practice: Dành thời gian thực hành trên Google Cloud. Bắt đầu với các lab cơ bản, sau đó thử kết hợp các dịch vụ để xây dựng các kiến trúc đơn giản theo các mẫu đã trình bày.
Deepen: Nếu một khái niệm nào đó vẫn chưa rõ ràng, hãy đọc thêm tài liệu chính thức hoặc tìm kiếm các bài viết/video giải thích.
Ask Questions: Đừng ngần ngại hỏi tôi bất cứ lúc nào nếu bạn gặp khó khăn hoặc có thắc mắc. Mục tiêu của tôi là giúp bạn hiểu rõ mọi thứ.

Chứng chỉ ACE là một bước đệm tuyệt vời. Việc hiểu sâu về Serverless sẽ giúp bạn tự tin hơn rất nhiều trong bài thi và trong công việc sau này.

Bạn có bất kỳ câu hỏi nào về các mẹo ôn thi hay bất cứ điều gì khác không? Tôi sẵn sàng hỗ trợ bạn!

Hãy cùng nhau cố gắng để đạt được mục tiêu ACE của bạn nhé!

Phân Tích Chuyên Sâu Toàn Bộ Các Dịch Vụ Serverless của Google Cloud Platform cho Kỳ Thi ACE ​

Phần 1: Giới Thiệu về Serverless ​

Phần 2: Các Dịch Vụ Serverless Compute (Tính toán) Chủ Đạo ​

2.1. Google Cloud Functions (GCF) ​

2.2. Google Cloud Run ​

2.3. Google App Engine Standard Environment (GAE Standard) ​

3. Các Dịch Vụ Serverless khác hỗ trợ Compute ​

3.1. Workflows ​

3.2. Eventarc ​

4. Các Dịch Vụ Serverless Data & Messaging ​

4.1. Cloud Firestore ​

4.2. Cloud Pub/Sub ​

4.3. Cloud Storage ​

4.4. BigQuery ​

5. Tích Hợp Các Dịch Vụ Serverless (Kiến trúc Serverless điển hình) ​

6. Bảo Mật trong Serverless (Tập trung vào ACE) ​

7. Giám Sát và Ghi log Serverless (Tập trung vào ACE) ​

8. Lựa Chọn Dịch Vụ Serverless Phù Hợp (ACE Perspective) ​

9. Tips Chuẩn Bị Cho Kỳ Thi ACE với Serverless ​

10. Kết luận và Hướng đi tiếp theo ​

Phân Tích Chuyên Sâu Toàn Bộ Các Dịch Vụ Serverless của Google Cloud Platform cho Kỳ Thi ACE

Phần 1: Giới Thiệu về Serverless

Phần 2: Các Dịch Vụ Serverless Compute (Tính toán) Chủ Đạo

2.1. Google Cloud Functions (GCF)

2.2. Google Cloud Run

2.3. Google App Engine Standard Environment (GAE Standard)

3. Các Dịch Vụ Serverless khác hỗ trợ Compute

3.1. Workflows

3.2. Eventarc

4. Các Dịch Vụ Serverless Data & Messaging

4.1. Cloud Firestore

4.2. Cloud Pub/Sub

4.3. Cloud Storage

4.4. BigQuery

5. Tích Hợp Các Dịch Vụ Serverless (Kiến trúc Serverless điển hình)

6. Bảo Mật trong Serverless (Tập trung vào ACE)

7. Giám Sát và Ghi log Serverless (Tập trung vào ACE)

8. Lựa Chọn Dịch Vụ Serverless Phù Hợp (ACE Perspective)

9. Tips Chuẩn Bị Cho Kỳ Thi ACE với Serverless

10. Kết luận và Hướng đi tiếp theo