Serverless Computing và AWS Lambda: Tương lai của backend

Serverless đang thay đổi cách xây backend: thay vì một ứng dụng chạy liên tục trên máy chủ, backend trở thành tập hợp các hàm nhỏ như AWS Lambda kết nối với dịch vụ được quản lý qua sự kiện. Đây có phải là tương lai của backend? Câu trả lời thực tế là serverless sẽ là lựa chọn mặc định cho ngày càng nhiều loại khối lượng công việc, nhưng không thay thế hoàn toàn container hay máy chủ. Bài này đi sâu vào cách thiết kế một backend serverless hoàn chỉnh, những mẫu kiến trúc thường dùng và các bài toán bạn phải giải.

Nếu bạn chưa quen với khái niệm cơ bản như hàm, sự kiện kích hoạt hay cold start, hãy đọc trước bài serverless là gì và vì sao chọn AWS Lambda.

Tư duy mới: backend hướng sự kiện

Backend truyền thống tổ chức quanh một tiến trình lớn nhận yêu cầu, gọi cơ sở dữ liệu và trả kết quả. Backend serverless tổ chức quanh sự kiện: một yêu cầu HTTP, một file được tải lên, một bản ghi thay đổi, một tin nhắn trong hàng đợi. Mỗi sự kiện kích hoạt một hàm làm đúng một việc, và hàm đó có thể phát ra sự kiện mới cho bước tiếp theo.

Tư duy này có hai hệ quả lớn. Thứ nhất, phần lớn "keo dán" giữa các thành phần được giao cho dịch vụ quản lý như API Gateway, EventBridge, SQS, Step Functions, thay vì viết trong mã. Thứ hai, các thành phần liên kết lỏng, có thể thay đổi và mở rộng độc lập, giống tinh thần của microservices nhưng ở mức hạt mịn hơn.

Các khối xây dựng của một backend serverless trên AWS

Năm mẫu kiến trúc phổ biến

1. API đồng bộ

API Gateway nhận yêu cầu, chuyển cho Lambda, Lambda đọc ghi DynamoDB rồi trả kết quả. Đây là mẫu cơ bản nhất cho ứng dụng web và di động. Lưu ý giữ hàm gọn để thời gian phản hồi thấp, và tránh gọi chuỗi Lambda này sang Lambda khác một cách đồng bộ.

2. Đệm tải bằng hàng đợi

Khi yêu cầu không cần xử lý ngay, API ghi vào SQS và trả về ngay. Lambda đọc hàng đợi theo lô và xử lý với tốc độ kiểm soát được. Mẫu này bảo vệ hệ thống phía sau như cơ sở dữ liệu quan hệ khỏi bị quá tải khi lưu lượng tăng đột biến.

3. Fan-out qua pub/sub

Một sự kiện "đơn hàng đã tạo" được phát qua SNS hoặc EventBridge tới nhiều hàm cùng lúc: một hàm gửi email, một hàm cập nhật kho, một hàm ghi vào hệ thống phân tích. Thêm người nghe mới không cần sửa phía phát.

4. Quy trình nhiều bước với Step Functions

Với quy trình như xử lý đơn hàng gồm kiểm tra tồn kho, thanh toán, xác nhận, giao hàng, Step Functions định nghĩa máy trạng thái có rẽ nhánh, thử lại, xử lý lỗi và bước bù trừ. Đây là cách hiện thực mẫu saga mà không phải tự viết mã điều phối.

5. Xử lý dữ liệu theo luồng

Lambda đọc từ Kinesis hoặc DynamoDB Streams, biến đổi và ghi vào kho phân tích. Phù hợp với nhật ký, sự kiện người dùng, dữ liệu cảm biến.

Những bài toán khó của backend serverless

Quản lý trạng thái và kết nối cơ sở dữ liệu

Hàm không giữ trạng thái giữa các lần gọi một cách đáng tin cậy. Mọi trạng thái nằm ở dịch vụ bên ngoài. Với cơ sở dữ liệu quan hệ, hàng trăm môi trường Lambda đồng thời có thể mở quá nhiều kết nối; Amazon RDS Proxy được thiết kế để gộp kết nối cho trường hợp này. DynamoDB, vốn giao tiếp qua HTTP, không gặp vấn đề tương tự nhưng đòi hỏi thiết kế dữ liệu theo mẫu truy cập.

Idempotency

Nhiều nguồn sự kiện đảm bảo "ít nhất một lần", nghĩa là hàm có thể nhận cùng một sự kiện hai lần. Thao tác như trừ tiền hay gửi email cần kiểm tra trùng lặp, ví dụ lưu mã sự kiện đã xử lý. Bộ công cụ Powertools for AWS Lambda có tiện ích hỗ trợ việc này.

Quan sát hệ thống phân tán

Một yêu cầu có thể đi qua API Gateway, ba hàm Lambda, một hàng đợi và một máy trạng thái. Cần log có cấu trúc kèm mã tương quan, metrics tùy chỉnh và tracing với AWS X-Ray hoặc OpenTelemetry để biết chuyện gì xảy ra.

Kiểm thử

Phần lớn hành vi nằm ở tích hợp giữa các dịch vụ, nên unit test là chưa đủ. Nhiều đội chạy kiểm thử tích hợp trực tiếp trên môi trường cloud tạm thời cho mỗi nhánh, triển khai bằng hạ tầng dưới dạng mã. Đưa việc này vào quy trình CI/CD với nhiều tầng kiểm thử giúp phát hiện lỗi cấu hình quyền và sự kiện sớm.

Bảo mật

Mỗi hàm nên có IAM role riêng với quyền tối thiểu, thay vì một role dùng chung có mọi quyền. Bí mật đặt trong Secrets Manager hoặc Parameter Store. Bề mặt tấn công máy chủ giảm, nhưng lỗi ở tầng ứng dụng như kiểm tra đầu vào hay phân quyền vẫn là trách nhiệm của bạn.

Chi phí: cần mô hình hóa, đừng đoán

Serverless rẻ khi lưu lượng thấp hoặc biến động. Ở lưu lượng cao và đều, tổng chi phí Lambda, API Gateway và các dịch vụ đi kèm có thể vượt chi phí chạy container. Hãy ước tính bằng công cụ tính giá với số liệu lưu lượng thực, theo dõi chi phí theo từng hàm, và điều chỉnh bộ nhớ cấp phát: tăng bộ nhớ cũng tăng CPU, đôi khi giảm thời gian chạy đủ để tổng chi phí thấp hơn. Bài tối ưu chi phí dịch vụ đám mây có thêm phương pháp theo dõi chi phí.

Serverless có phải tương lai của backend?

Một số xu hướng cho thấy ranh giới giữa serverless và container đang mờ dần:

• Lambda hỗ trợ chạy image container, và các nền tảng như Google Cloud Run hay AWS Fargate mang trải nghiệm "không quản lý máy chủ" cho container.
• Cơ sở dữ liệu ngày càng có phiên bản serverless, tự co giãn theo tải.
• Edge function chạy mã ở các điểm hiện diện gần người dùng, mở rộng khái niệm serverless ra biên mạng.
• Công cụ hạ tầng dưới dạng mã và framework như AWS CDK, SST giúp định nghĩa backend serverless gọn gàng hơn.

Xu hướng chung là nhà phát triển ngày càng ít phải nghĩ về máy chủ. Nhưng những khối lượng công việc chạy dài, cần GPU chuyên dụng, cần độ trễ cực thấp ổn định hoặc có lưu lượng lớn đều đặn vẫn có lý do để chạy trên container hay máy ảo. Kiến trúc thực tế của nhiều công ty là lai: lõi chạy container, phần xử lý sự kiện và tác vụ phụ chạy serverless.

Khi nào nên chọn serverless cho backend mới

• Đội nhỏ, muốn tập trung vào sản phẩm thay vì vận hành.
• Lưu lượng khó dự đoán hoặc có đỉnh đột biến.
• Bài toán tự nhiên mang tính hướng sự kiện.
• Chấp nhận gắn bó với một nhà cung cấp cloud để đổi lấy tốc độ phát triển.