Mở đầu — vì sao bài này quan trọng
Trong bài trước, bạn đã hình dung được bức tranh tổng thể của điện toán đám mây: máy chủ ảo, mạng, lưu trữ, và ý tưởng "thuê hạ tầng thay vì tự mua". Nhưng có một sự thật hơi phũ phàng mà nhiều đội kỹ thuật ở Việt Nam nhận ra sau vài tháng lên cloud: chỉ chuyển máy chủ vật lý thành máy chủ ảo (VM) thôi thì bạn vẫn phải làm gần như tất cả mọi việc như cũ — vá lỗi hệ điều hành, canh CPU, lo dung lượng ổ đĩa, thức đêm khi traffic tăng đột biến. Cloud đã giúp bạn không phải mua tủ rack, nhưng gánh nặng vận hành vẫn còn nguyên.
Serverless ra đời để giải quyết chính vấn đề đó. Đây là một bước tiến hóa lớn về tư duy: thay vì hỏi "tôi cần bao nhiêu máy chủ?", bạn hỏi "tôi cần chạy đoạn code nào, khi có sự kiện gì?". Còn máy chủ chạy ở đâu, bật lên lúc nào, tắt đi khi nào — đó là việc của nhà cung cấp cloud, không phải của bạn.
Nhưng khi bạn giao phần vận hành hạ tầng cho người khác, một câu hỏi mới xuất hiện ngay lập tức: làm sao tôi biết hệ thống đang khỏe hay đang bệnh? Đây chính là lý do bài học này ghép hai chủ đề tưởng chừng khác nhau — Serverless và Monitoring — vào cùng một chỗ. Càng ít quyền kiểm soát hạ tầng, bạn càng phải "nhìn" hệ thống qua dữ liệu quan trắc. Không có monitoring, chạy serverless giống như lái xe ban đêm mà không bật đèn: đi được, nhưng chỉ đến khi va vào cột điện đầu tiên.
Hiểu chắc hai khái niệm này là nền tảng để bạn theo được rất nhiều bài phía sau trong khóa học. Ta bắt đầu.
Khái niệm cốt lõi
Serverless thực sự là gì?
Tên gọi "serverless" (không máy chủ) hơi gây hiểu lầm — máy chủ vẫn tồn tại, chỉ là bạn không nhìn thấy, không quản lý, và không phải nghĩ về chúng. Serverless được định nghĩa bởi bốn đặc điểm cốt lõi:
1. Không quản lý máy chủ (No server management). Bạn không cần chọn kích thước máy, không cài hệ điều hành, không vá lỗi bảo mật cho OS, không lo ổ đĩa đầy. Bạn chỉ viết code và đẩy lên. Nhà cung cấp lo phần còn lại. Trong thực tế, "đơn vị triển khai" của bạn không còn là một máy chủ mà là một function (hàm) — một đoạn code nhỏ làm một việc cụ thể.
2. Tự co giãn về không (Auto-scales to zero). Đây là điểm khác biệt lớn nhất so với VM. Khi không có request nào, hệ thống serverless co lại về 0 — không có instance nào chạy, và bạn không trả tiền. Khi có 1 request, nó bật 1 instance. Khi có 10.000 request cùng lúc, nó tự bật 10.000 instance song song rồi tắt hết khi hết việc. Với VM, dù không ai truy cập lúc 3 giờ sáng, máy vẫn chạy và vẫn tính tiền.
3. Trả tiền theo lượt thực thi (Pay per execution). Bạn chỉ trả cho số lần function chạy và thời gian chạy thực tế (thường tính theo mili-giây) nhân với lượng bộ nhớ cấp phát. Không request nào thì hóa đơn bằng 0. Đây là mô hình kinh tế cực kỳ hấp dẫn cho các workload có lưu lượng thất thường.
4. Hướng sự kiện (Event-driven). Function serverless không chạy liên tục mà "ngủ" cho đến khi có một sự kiện đánh thức nó: một HTTP request từ người dùng, một file mới được tải lên kho lưu trữ, một bản ghi mới trong hàng đợi, hay một mốc thời gian định sẵn (giống cron). Sự kiện đến — function chạy — trả kết quả — ngủ tiếp.
Các dịch vụ serverless phổ biến bạn sẽ gặp nhiều lần trong khóa: AWS Lambda, Google Cloud Functions, Azure Functions. Ở bài này ta chỉ cần hiểu bản chất; chi tiết kỹ thuật của từng nền tảng sẽ được đào sâu ở các bài chuyên đề sau.
Serverless dùng cho việc gì?
Serverless tỏa sáng ở những tình huống có tính "bùng phát" và rời rạc:
- API endpoint và backend nhẹ: xử lý logic cho một endpoint REST, ví dụ API xác thực OTP, API tính phí ship.
- Xử lý ảnh/file (image processing): người dùng upload ảnh lên, một function tự động tạo thumbnail, nén ảnh, gắn watermark.
- Xử lý dữ liệu theo luồng: mỗi bản ghi từ hệ thống thanh toán được đẩy vào function để làm sạch và ghi vào cơ sở dữ liệu.
- Tác vụ định kỳ (scheduled jobs): gửi email nhắc nhở hằng ngày, dọn dẹp dữ liệu tạm mỗi đêm.
- Webhook và tích hợp: nhận callback từ cổng thanh toán như VNPay, Momo rồi cập nhật trạng thái đơn hàng.
Cái giá phải trả: cold start và giới hạn
Không có bữa trưa miễn phí. Vì function "ngủ" khi không dùng, khi có request đầu tiên sau một thời gian im ắng, hệ thống phải "đánh thức" — khởi tạo môi trường, nạp code. Độ trễ này gọi là cold start (khởi động nguội), thường từ vài trăm mili-giây đến vài giây. Những lần gọi tiếp theo (khi function còn "ấm") sẽ nhanh. Ngoài ra còn có giới hạn thời gian chạy tối đa mỗi lần (ví dụ Lambda tối đa 15 phút), giới hạn bộ nhớ, và giới hạn số lần chạy song song.
Monitoring: nhìn thấy cái vô hình
Khi hạ tầng bị ẩn đi, monitoring trở thành đôi mắt của bạn. Có bốn nhóm dữ liệu quan trắc cần nắm — thường gọi là các "trụ cột của observability" (khả năng quan sát):
- Metrics (số liệu): các con số theo thời gian như số lần gọi, tỷ lệ lỗi, độ trễ trung bình, thời gian thực thi. Đây là thứ bạn nhìn trên biểu đồ.
- Logs (nhật ký): bản ghi văn bản chi tiết từng sự kiện, giúp bạn "đọc lại" chuyện gì đã xảy ra.
- Traces (dấu vết): theo dõi một request đi xuyên qua nhiều function/dịch vụ để tìm chỗ nghẽn.
- Alerts (cảnh báo): quy tắc tự động báo cho bạn khi một số liệu vượt ngưỡng, ví dụ "tỷ lệ lỗi vượt 5%".
Tình huống thực tế
Ví dụ 1 — Sàn thương mại điện tử và cơn bão Flash Sale
Hãy tưởng tượng một sàn thương mại điện tử giả định tên ChợViệt, tương tự Tiki hay Shopee ở quy mô nhỏ hơn. Ngày thường họ có khoảng 200 request/giây cho chức năng tạo thumbnail ảnh sản phẩm khi người bán đăng hàng. Nhưng trong đợt Flash Sale 12/12, hàng nghìn người bán đồng loạt đăng sản phẩm, lưu lượng xử lý ảnh vọt lên gần 8.000 request/giây trong 15 phút, rồi rơi về mức bình thường.
Trước đây họ chạy dịch vụ xử lý ảnh trên 4 máy chủ ảo cố định. Trong Flash Sale, 4 máy này quá tải, ảnh xếp hàng chờ xử lý, người bán phàn nàn thumbnail cả tiếng chưa hiện. Nếu nâng lên 40 máy để chịu đỉnh thì 355 ngày còn lại trong năm số máy đó nằm chơi mà vẫn tốn tiền.
Đội kỹ thuật chuyển sang serverless: mỗi khi có ảnh mới tải lên kho lưu trữ, một function tự động chạy để nén và tạo thumbnail. Trong đỉnh Flash Sale, nền tảng tự bật hàng nghìn instance song song, xử lý mượt; hết cao điểm, mọi thứ co về gần 0. Bài học rút ra: serverless đặc biệt hợp với workload "co giãn dữ dội" — nơi đỉnh cao gấp hàng chục lần mức bình thường và chỉ kéo dài ngắn. Bạn trả tiền cho công việc thực tế, không phải cho công suất dự phòng nằm chờ.
Ví dụ 2 — Startup fintech và cái giá của việc "quên bật đèn"
Một startup fintech ở TP.HCM, ta gọi là PayNhanh, dùng Lambda để nhận webhook từ cổng thanh toán rồi cập nhật trạng thái giao dịch. Họ triển khai xong, chạy mượt vài tuần, và... không thiết lập monitoring gì cả vì "nó tự chạy mà, việc gì phải lo".
Một ngày, cổng thanh toán đối tác đổi định dạng payload. Function của PayNhanh bắt đầu lỗi khi phân tích dữ liệu — nhưng vì serverless vẫn "chạy" (nó vẫn được gọi, chỉ là chạy xong thì báo lỗi bên trong), bề ngoài hệ thống trông vẫn bình thường. Không có VM nào sập, không có cảnh báo CPU nào kêu. Suốt 6 tiếng, khoảng 3.200 giao dịch được thu tiền nhưng trạng thái không cập nhật, khách hàng bị trừ tiền mà đơn báo "chưa thanh toán". Đội chăm sóc khách hàng ngập trong khiếu nại trước khi kỹ thuật kịp phát hiện.
Nguyên nhân gốc không phải là serverless dở, mà là thiếu monitoring. Nếu họ đặt một cảnh báo đơn giản "khi tỷ lệ lỗi của function vượt 2% trong 5 phút thì gửi tin nhắn", sự cố đã được phát hiện trong vài phút thay vì 6 tiếng. Bài học rút ra: với serverless, lỗi thường "im lặng". Bạn không mất máy chủ, bạn mất đúng đắn của dữ liệu. Monitoring không phải thứ làm sau cho có — nó phải được bật cùng lúc với việc triển khai function.
Ví dụ 3 — App gọi xe và bẫy cold start
Một ứng dụng gọi xe khu vực Đông Nam Á (bối cảnh tương tự Grab hoặc Gojek) dùng serverless cho API tính giá cước ước lượng khi người dùng nhập điểm đến. Vào giờ thấp điểm ban đêm, ít người gọi xe, các function tính giá "ngủ". Đến sáng, request đầu tiên của mỗi khu vực gặp cold start khoảng 1,5–2 giây — người dùng thấy màn hình "đang tính giá..." quay lâu bất thường, và một số bỏ cuộc.
Nhóm kỹ thuật phát hiện điều này nhờ đọc metrics duration: họ thấy phân bố thời gian phản hồi có một nhóm nhỏ request chậm hẳn vào các mốc đầu giờ. Họ xử lý bằng cách bật tính năng giữ sẵn một số instance "ấm" (provisioned concurrency) cho các function quan trọng vào khung giờ cao điểm buổi sáng. Chi phí tăng nhẹ nhưng trải nghiệm mượt hơn hẳn. Bài học rút ra: serverless không miễn phí về độ trễ. Với những đường dẫn ảnh hưởng trực tiếp đến trải nghiệm người dùng, bạn cần đo lường cold start qua monitoring và chủ động giảm thiểu — chứ không chỉ tin rằng "auto-scale là xong".
Hướng dẫn từng bước
Đây là quy trình tư duy khi bạn đưa một tác vụ lên serverless kèm monitoring đầy đủ. Không phụ thuộc nhà cung cấp cụ thể — áp dụng được cho cả AWS, GCP lẫn Azure.
- Xác định workload có hợp serverless không. Hỏi ba câu: Tác vụ có hướng sự kiện không? Lưu lượng có thất thường/bùng phát không? Mỗi lần chạy có dưới giới hạn thời gian (ví dụ 15 phút) không? Nếu ba câu đều "có", serverless là lựa chọn tốt.
- Chia nhỏ thành function làm một việc. Mỗi function nên đảm nhận một nhiệm vụ rõ ràng (tạo thumbnail, gửi email, xử lý webhook). Tránh nhồi nhét quá nhiều logic vào một function khổng lồ — khó debug và khó co giãn.
- Chọn nguồn sự kiện (trigger). Xác định thứ gì đánh thức function: HTTP request qua API Gateway, file mới trong object storage, message trong hàng đợi, hay lịch định kỳ.
- Cấu hình tài nguyên và timeout hợp lý. Đặt bộ nhớ và thời gian tối đa vừa đủ. Nhớ rằng trên nhiều nền tảng, tăng bộ nhớ cũng tăng CPU, đôi khi làm function chạy nhanh hơn và tổng chi phí lại thấp hơn.
- Bật logging ngay từ đầu. Đảm bảo mọi lần chạy đều ghi log — ít nhất là log lỗi và các mốc quan trọng. Đây là cơ sở để điều tra khi có sự cố.
- Thiết lập metrics và dashboard. Theo dõi tối thiểu: invocations, errors, duration, throttles. Dựng một bảng điều khiển để nhìn nhanh sức khỏe hệ thống.
- Tạo cảnh báo (alert). Đặt ngưỡng cụ thể: tỷ lệ lỗi vượt X%, độ trễ p95 vượt Y mili-giây, throttles lớn hơn 0. Gắn cảnh báo với kênh bạn thật sự đọc — email, Slack, hoặc Telegram.
- Kiểm thử tải và quan sát. Bắn thử lưu lượng cao, quan sát hệ thống co giãn ra sao, cold start bao nhiêu, có bị throttle không. Điều chỉnh dựa trên dữ liệu thật.
Lỗi thường gặp & mẹo
Lỗi 1 — Triển khai function rồi quên monitoring. Đây là lỗi kinh điển, đúng như tình huống PayNhanh. Mẹo: coi cảnh báo tỷ lệ lỗi là một phần bắt buộc của việc "hoàn thành" một function, không phải việc làm thêm.
Lỗi 2 — Bỏ qua cold start ở các đường dẫn nhạy cảm. Đừng để người dùng thật gánh độ trễ khởi động nguội trên các API quan trọng. Mẹo: đo duration để tách nhóm request chậm; dùng provisioned/warm concurrency cho function trọng yếu.
Lỗi 3 — Function quá "béo" và chạy quá lâu. Nhồi tác vụ dài hàng chục phút vào serverless dễ đụng giới hạn timeout. Mẹo: chia nhỏ, hoặc chuyển tác vụ chạy dài sang container/VM.
Lỗi 4 — Không xử lý retry và lỗi lặp. Nhiều nguồn sự kiện sẽ tự thử lại khi function lỗi, dẫn đến cùng một message được xử lý nhiều lần. Mẹo: thiết kế function có tính idempotent (chạy nhiều lần cho cùng một kết quả) và dùng dead-letter queue để hứng message lỗi.
Lỗi 5 — Bất ngờ vì hóa đơn. Một vòng lặp vô tình khiến function tự gọi chính nó có thể tạo hàng triệu lượt chạy. Mẹo: đặt cảnh báo ngân sách và giới hạn concurrency tối đa.
Mẹo chung về monitoring: đừng cảnh báo mọi thứ — cảnh báo quá nhiều gây "mệt mỏi cảnh báo" (alert fatigue) và người ta bắt đầu phớt lờ. Hãy cảnh báo ít nhưng đúng thứ khiến bạn phải hành động ngay.
Bài tập thực hành
- Phân loại workload. Lấy 5 tác vụ trong một hệ thống bạn biết (ví dụ: gửi email xác nhận đơn, tạo báo cáo doanh thu hằng đêm, phục vụ trang chủ website, xử lý ảnh upload, chạy mô hình dự báo 3 tiếng). Với mỗi tác vụ, quyết định có nên dùng serverless không và giải thích lý do dựa trên bốn đặc điểm cốt lõi.
- Thiết kế trên giấy. Chọn tình huống "người dùng upload avatar, hệ thống tự tạo 3 kích thước ảnh". Vẽ luồng: nguồn sự kiện là gì, function làm gì, kết quả lưu đâu. Liệt kê 3 metrics và 2 alert bạn sẽ thiết lập.
- Suy nghĩ về sự cố. Đọc lại tình huống PayNhanh. Viết ra 3 cảnh báo cụ thể (kèm ngưỡng và cửa sổ thời gian) mà nếu có, đội đó đã phát hiện sự cố sớm.
- Ước tính chi phí. Một function chạy 2 triệu lần/tháng, mỗi lần 200 mili-giây, cấp 256 MB bộ nhớ. So sánh về mặt ý tưởng với việc chạy 2 VM 24/7 cho cùng tác vụ có lưu lượng thất thường. Serverless có vẻ rẻ hơn hay đắt hơn trong trường hợp này? Vì sao?
Tóm tắt
Serverless là bước tiến hóa nơi bạn ngừng quản lý máy chủ và bắt đầu chỉ quan tâm đến code cùng sự kiện. Bốn đặc điểm cốt lõi cần nhớ: không quản lý máy chủ, tự co giãn về 0, trả tiền theo lượt thực thi, và hướng sự kiện. Nó tỏa sáng với các workload bùng phát và rời rạc — API nhẹ, xử lý ảnh/file, tác vụ định kỳ, webhook — nhưng có cái giá về cold start và các giới hạn thời gian, bộ nhớ, concurrency.
Vì hạ tầng bị ẩn đi, monitoring không còn là tùy chọn mà là điều kiện sống còn. Bốn trụ cột — metrics, logs, traces, alerts — là đôi mắt giúp bạn nhìn thấy hệ thống vô hình. Với serverless, hãy đặc biệt theo dõi invocations, errors, duration, throttles, và luôn bật cảnh báo tỷ lệ lỗi ngay khi triển khai. Ba tình huống ChợViệt, PayNhanh và app gọi xe cho thấy cùng một thông điệp: serverless cho bạn sức mạnh co giãn phi thường, nhưng chỉ an toàn khi đi kèm khả năng quan sát. Lái xe ban đêm thì phải bật đèn. Ở các bài sau, chúng ta sẽ đi sâu vào từng nền tảng và từng công cụ đã nhắc đến ở đây.