Điện toán phi máy chủ (Serverless Computing / FaaS)
1. Tổng quan
Định nghĩa: Điện toán phi máy chủ (serverless) là mô hình thực thi đám mây trong đó lập trình viên giao hoàn toàn việc vận hành hạ tầng như cấp phát, co giãn, vá lỗi máy chủ cho nhà cung cấp đám mây, cấu thành ứng dụng theo đơn vị hàm (Function) phản ứng với sự kiện hoặc dịch vụ được quản lý, và chỉ bị tính phí theo lượng tài nguyên thực sự dùng để thực thi (pay-per-use).
Tên gọi "không có máy chủ" không có nghĩa là máy chủ vật lý biến mất, mà có nghĩa là sự tồn tại của máy chủ biến mất khỏi mối quan tâm của lập trình viên (server-less). Trong IaaS, PaaS truyền thống, dù không có lưu lượng thì instance vẫn phải chạy thường trực và phải trả chi phí tương ứng, còn serverless chỉ tạo instance hàm để thực thi ngay khi có yêu cầu đến và thu nhỏ tài nguyên về 0 khi nhàn rỗi (scale-to-zero). Đây chính là sự thay đổi hạ đơn vị nhỏ nhất của việc sử dụng tài nguyên từ 'thời gian thuê máy chủ' xuống 'một lần gọi hàm·vài chục mili giây', và cùng với sự lan rộng của microservice và kiến trúc hướng sự kiện, đã hình thành nên bối cảnh xuất hiện.
Bối cảnh xuất hiện gồm ba yếu tố. Thứ nhất là gánh nặng vận hành bùng nổ. Khi container và điều phối (orchestration) trở nên phổ biến, bề mặt quản lý hạ tầng mà đội phát triển phải gánh vác mở rộng, và vấn đề tài nguyên dồn vào vận hành hơn là logic nghiệp vụ nổi lên. Thứ hai là hiệu quả chi phí. Với các khối lượng công việc có lưu lượng biến động lớn hoặc không liên tục (xử lý lô, webhook, sự kiện IoT), instance chạy thường trực gây lãng phí lớn, và tính phí theo mức sử dụng giải quyết điều này. Thứ ba là tính linh hoạt trong phát triển. Triển khai theo đơn vị hàm giúp rút ngắn chu kỳ phát hành, và kết hợp với backend được quản lý (BaaS) cho phép hoàn thiện dịch vụ với lượng mã tối thiểu. Việc AWS Lambda ra mắt năm 2014 là mốc thương mại hóa, và sau đó khái niệm serverless đang mở rộng vượt ra ngoài FaaS sang DB serverless và container serverless.
2. Cấu trúc và thành phần của kiến trúc serverless
Ứng dụng serverless về cơ bản được cấu thành từ sự kết hợp giữa FaaS (Function as a Service) đảm nhận tính toán và BaaS (Backend as a Service) cung cấp trạng thái và chức năng. Yêu cầu đi vào qua API Gateway và các nguồn sự kiện, hàm được thực thi phi trạng thái (stateless) rồi tương tác với kho lưu trữ, DB, hàng đợi thông điệp được quản lý, ủy thác trạng thái ra bên ngoài.
graph LR
U["Client/Nguồn sự kiện"] --> G["API Gateway / Trigger sự kiện"]
G --> F1["Function A (Xác thực)"]
G --> F2["Function B (Xử lý đơn hàng)"]
F1 --> Q["Hàng đợi thông điệp / Stream"]
F2 --> Q
Q --> F3["Function C (Hậu xử lý bất đồng bộ)"]
F2 --> DB[("DB serverless")]
F3 --> S[("Object storage")]
subgraph BaaS["Backend được quản lý (BaaS)"]
DB
S
Q
end
FaaS là môi trường thực thi hàm có vòng đời ngắn được kích hoạt bởi sự kiện. Lập trình viên chỉ cung cấp mã hàm và cấu hình bộ nhớ, timeout, phần còn lại như runtime và co giãn do nền tảng đảm nhận. Hàm phải tuân thủ nguyên tắc phi trạng thái nên các trạng thái như phiên, bộ nhớ đệm bắt buộc phải đặt ở kho lưu trữ bên ngoài. BaaS là dịch vụ được quản lý cung cấp các chức năng backend như xác thực (Auth), cơ sở dữ liệu, lưu trữ, thông báo dưới dạng API, giúp frontend serverless hoàn thiện chức năng mà không cần mã máy chủ. Nguồn sự kiện là cò súng kích hoạt thực thi hàm, bao gồm yêu cầu HTTP, tạo đối tượng trong kho lưu trữ, thông điệp hàng đợi, lịch (cron), luồng thay đổi DB….
| Thành phần | Vai trò | Ví dụ tiêu biểu |
|---|---|---|
| FaaS | Thực thi hàm phi trạng thái hướng sự kiện | AWS Lambda, Azure Functions, Google Cloud Functions |
| API Gateway | Định tuyến·xác thực·throttling·chuyển đổi yêu cầu | Amazon API Gateway |
| Nguồn sự kiện | Kích hoạt hàm | S3, SQS/SNS, EventBridge, Kinesis, cron |
| BaaS (trạng thái) | DB·lưu trữ·xác thực được quản lý | DynamoDB, Aurora Serverless, Firebase |
| Điều phối | Kết hợp luồng công việc của các hàm | AWS Step Functions |
3. Nguyên lý hoạt động — Vòng đời thực thi và khởi động lạnh
Vấn đề kỹ thuật cốt lõi của serverless là quản lý vòng đời của instance hàm. Khi không có yêu cầu, tài nguyên được giữ ở mức 0, và khi yêu cầu đến thì phải tạo môi trường thực thi tức thời; độ trễ phát sinh trong quá trình chuẩn bị này chính là khởi động lạnh (Cold Start).
graph TD
A["Yêu cầu/Sự kiện đến"] --> B{"Có instance<br/>sẵn sàng?"}
B -->|"Có (khởi động ấm)"| E["Thực thi handler ngay"]
B -->|"Không (khởi động lạnh)"| C["Cấp phát container/microVM"]
C --> D["Nạp runtime & khởi tạo mã"]
D --> E
E --> F["Trả về phản hồi"]
F --> G["Giữ instance nhàn rỗi một thời gian"]
G -->|"Yêu cầu lại"| E
G -->|"Vượt thời gian nhàn rỗi"| H["Hủy instance (scale-to-zero)"]
Khởi động lạnh xảy ra qua ba bước cấp phát môi trường thực thi → nạp runtime → thực thi mã khởi tạo (bên ngoài handler), và dao động lớn từ vài chục ms đến vài giây tùy ngôn ngữ, kích thước gói và cấu hình bộ nhớ. Ví dụ, hàm JVM chứa nhiều phụ thuộc lớn có khởi tạo nặng nên khởi động lạnh lên tới 1~2 giây, trong khi runtime nhẹ thì dưới vài trăm ms. Trong thực tế, người ta đưa logic khởi tạo ra ngoài handler để lưu đệm khi tái sử dụng instance, dùng đồng thời được cấp phát trước (Provisioned Concurrency) để luôn duy trì instance ấm, và với AWS thì dùng microVM Firecracker để rút ngắn thời gian khởi động xuống mức mili giây. Co giãn là cơ chế nhân bản ngang instance hàm tỷ lệ với số yêu cầu nên gần như tự động, nhưng khi thiết kế phải lưu ý rằng số lần thực thi đồng thời bị giới hạn (quota) theo tài khoản và region.
4. So sánh với mô hình truyền thống
Để hiểu vị trí của serverless, cần so sánh khác biệt về ranh giới trách nhiệm với IaaS và container (CaaS). Bảng dưới đây là liệt kê, nhưng lý do tạo nên khác biệt nằm ở sự dịch chuyển mức trừu tượng: 'lập trình viên kiểm soát đến đâu và ủy thác đến đâu'. Mức trừu tượng càng cao thì càng đánh đổi gánh nặng vận hành lấy quyền kiểm soát chi tiết.
| Phân loại | IaaS (VM) | Container (K8s) | Serverless (FaaS) |
|---|---|---|---|
| Đơn vị mở rộng | Instance | Pod/Node | Lần gọi hàm |
| Co giãn về 0 | Không (chạy thường trực) | Hạn chế | Hỗ trợ mặc định |
| Cơ sở tính phí | Thời gian | Thời gian/Tài nguyên | Số lần·thời gian thực thi (ms) |
| Gánh nặng vận hành | Cao (OS·vá lỗi) | Trung bình | Tối thiểu |
| Giới hạn thời gian thực thi | Không | Không | Có (ví dụ: tối đa 15 phút) |
| Khởi động lạnh | Không | Thấp | Có |
IaaS có quyền kiểm soát lớn nhưng phải gánh vận hành OS, middleware và trả chi phí nhàn rỗi. Container mang lại tính di động và kiểm soát chi tiết nhưng vẫn còn gánh nặng vận hành bộ điều phối. Serverless gần như loại bỏ vận hành nhưng đổi lại phải chấp nhận các ràng buộc như giới hạn thời gian thực thi, khởi động lạnh, ràng buộc về đĩa cục bộ và trạng thái, phụ thuộc nhà cung cấp. Vì vậy, cốt lõi của lựa chọn kiến trúc là phán đoán điểm hòa vốn (break-even): khối lượng công việc tải cao liên tục và dự đoán được có thể có lợi hơn về tổng chi phí sở hữu với container và IaaS, còn khối lượng công việc không liên tục, mang tính sự kiện, dạng đột biến thì serverless có lợi hơn.
5. Tình huống áp dụng
Serverless đặc biệt thể hiện ưu thế trong pipeline hậu xử lý ảnh·dữ liệu. Ví dụ, trong cấu trúc khi người dùng tải ảnh lên object storage, sự kiện tạo đối tượng kích hoạt hàm để tạo thumbnail và ghi metadata vào DB, hệ thống tự động mở rộng lên hàng trăm instance khi lượt tải lên dồn dập và giảm về 0 khi rảnh, nên chi phí tỷ lệ chính xác với mức sử dụng. Ngoài ra, serverless được dùng rộng rãi cho các khối lượng công việc có yêu cầu không đều và duy trì máy chủ thường trực là lãng phí như webhook, chatbot, thu thập sự kiện IoT, xử lý lô định kỳ (cron), một số endpoint cụ thể của backend API. Gần đây nó còn được tận dụng cho tiền xử lý suy luận AI·suy luận nhẹ và giai đoạn xử lý tài liệu của pipeline RAG. Ngược lại, nó không phù hợp với giao dịch siêu độ trễ thấp mà độ trễ mili giây là chí mạng, tính toán liên tục dài hạn (huấn luyện quy mô lớn), hay khối lượng công việc duy trì lượng lớn trạng thái.
6. Chuyên sâu — Sự mở rộng của serverless và xu hướng mới nhất
Serverless đang mở rộng khái niệm vượt ra ngoài FaaS sang container serverless và cơ sở dữ liệu serverless. AWS Fargate, Google Cloud Run thực thi container theo phương thức serverless (scale-to-zero, tính phí theo mức sử dụng), nới lỏng giới hạn thời gian thực thi và runtime của FaaS trong khi vẫn giữ lợi ích vận hành của serverless. Các DB serverless như Aurora Serverless, DynamoDB On-Demand tự động điều chỉnh dung lượng theo lưu lượng. Về tiêu chuẩn hóa, CloudEvents (CNCF) chuẩn hóa định dạng thông điệp sự kiện để nâng cao khả năng tương tác sự kiện giữa các nhà cung cấp, còn Knative cung cấp thực thi serverless và tự động co giãn trên Kubernetes, hướng tới serverless trung lập với nhà cung cấp dựa trên mã nguồn mở. Kỹ thuật microVM (Firecracker) và khôi phục snapshot để giảm khởi động lạnh, serverless tại biên (Edge Functions) thực thi hàm tại các điểm biên, và serverless siêu nhẹ tận dụng runtime WebAssembly cũng là những lĩnh vực nghiên cứu và thương mại hóa sôi động. Những xu hướng này có thể được hiểu là hướng tổng quát hóa triết lý serverless 'điện toán chỉ tồn tại khi cần' ra nhiều tầng khác nhau, vượt khỏi phạm vi 'lấy hàm làm trung tâm'.
7. Những điểm cần cân nhắc và hàm ý
Từ góc nhìn Kỹ sư chuyên nghiệp, việc áp dụng serverless cần được phán đoán tổng hợp các điểm sau.
- Tính phù hợp của khối lượng công việc và phân tích hòa vốn: So sánh tổng chi phí sở hữu của serverless, container, IaaS dựa trên mô hình lưu lượng (không liên tục/đột biến vs tải cao thường trực) và đặc tính thời gian thực thi, đồng thời tính trước điểm hòa vốn mà tại đó đơn giá serverless có thể trở nên bất lợi với lưu lượng thường trực quy mô lớn.
- Phụ thuộc nhà cung cấp (Lock-in) và tính di động: Định dạng sự kiện, trigger, API BaaS khác nhau giữa các nhà cung cấp làm sự phụ thuộc sâu hơn, vì vậy cần áp dụng các tầng tiêu chuẩn và mã nguồn mở như CloudEvents, Knative, và bảo đảm tính di động bằng thiết kế lục giác (hexagonal) tách logic nghiệp vụ khỏi SDK của nhà cung cấp.
- Đánh đổi giữa hiệu năng và độ trễ: Đánh giá tác động của khởi động lạnh lên SLA để ứng phó bằng đồng thời được cấp phát trước, tối ưu hóa khởi tạo, runtime nhẹ, và với những phân đoạn mà độ trễ thấp là yêu cầu tuyệt đối thì kết hợp (hybrid) với mô hình chạy thường trực.
- Khả năng quan sát và mức độ trưởng thành vận hành: Nhiều hàm phân tán rất khó truy vết, nên bắt buộc phải có khả năng quan sát dựa trên distributed tracing, log có cấu trúc, correlation ID, đồng thời quản lý cấu hình hàm, trigger và quyền bằng IaC (Infrastructure as Code).
- Bảo mật·quản trị: Phản ánh ngay từ giai đoạn thiết kế nguyên tắc đặc quyền tối thiểu (IAM) cho từng hàm, kiểm chứng độ tin cậy của nguồn sự kiện, quản lý lỗ hổng của gói phụ thuộc (SCA), và phòng chống bùng nổ chi phí hay DoS bằng giới hạn đồng thời.
Trong tương lai, serverless dự kiến sẽ mở rộng phạm vi áp dụng khi kết hợp với biên (edge), WebAssembly và container serverless, và năng lực phán đoán của kiến trúc sư trong việc thiết kế cân bằng giữa giá trị 'mở rộng không cần vận hành' và chi phí 'ràng buộc và phụ thuộc' sẽ quyết định thành bại.
Tài liệu tham khảo
- Hướng dẫn dành cho nhà phát triển AWS Lambda, https://docs.aws.amazon.com/lambda/
- Đặc tả CNCF CloudEvents, https://cloudevents.io/
- Knative Documentation, https://knative.dev/docs/
- CNCF Serverless Whitepaper, https://github.com/cncf/wg-serverless
Tóm tắt một câu: Serverless là mô hình giao việc vận hành hạ tầng cho nhà cung cấp và thực thi các hàm phi trạng thái hướng sự kiện (FaaS) cùng backend được quản lý (BaaS) với tính phí theo mức sử dụng và co giãn về 0; cần phán đoán theo đặc tính khối lượng công việc giữa lợi ích loại bỏ gánh nặng vận hành và các đánh đổi về khởi động lạnh, giới hạn thực thi và phụ thuộc nhà cung cấp.