AWS Lambda - Bài 25

Nội dung

1. AWS Lambda là gì?

AWS Lambda là một dịch vụ điện toán serverless của Amazon Web Services (AWS). Điều này có nghĩa là bạn không cần phải quản lý máy chủ vật lý hay máy chủ ảo như khi sử dụng EC2. Thay vào đó, bạn chỉ cần viết mã (code), triển khai lên AWS và Lambda sẽ tự động xử lý phần còn lại: cấp phát tài nguyên, chạy hàm, và tự động mở rộng quy mô theo nhu cầu.

AWS Lambda hỗ trợ nhiều ngôn ngữ: Python, Node.js, Java, Go, .NET Core, Ruby, thậm chí cả runtime tùy chỉnh như Rust.

Với Amazon EC2, bạn phải tự quản lý máy chủ, cấu hình CPU, RAM, và giữ cho máy chủ hoạt động liên tục, ngay cả khi không có công việc cần xử lý. Ngoài ra, việc mở rộng quy mô (scaling) cần bạn cấu hình thêm như Auto Scaling Group.

Trong khi đó, AWS Lambda chỉ chạy khi có sự kiện xảy ra và tự động mở rộng khi có nhiều yêu cầu. Bạn không tốn chi phí khi Lambda không hoạt động, vì vậy rất tiết kiệm.

Ứng dụng: Khi người dùng tải một hình ảnh lên S3 bucket, Lambda sẽ tự động kích hoạt để xử lý hình ảnh và tạo ra bản thumbnail nhỏ hơn, sau đó lưu vào S3. Ngoài ra, Lambda có thể ghi thông tin metadata (tên, kích thước, thời gian tạo,…) vào DynamoDB.

2. Những lợi ích nổi bật của AWS Lambda

Không cần quản lý máy chủ: Không còn lo lắng về cấu hình hoặc vận hành hạ tầng.
Thanh toán theo mức sử dụng: Bạn chỉ trả tiền khi hàm Lambda được kích hoạt và tính phí dựa trên thời gian chạy và bộ nhớ sử dụng.
Tự động mở rộng: AWS tự động xử lý mọi yêu cầu đồng thời, không cần bạn cấu hình thêm.
Đa dạng ngôn ngữ lập trình: Hỗ trợ Node.js, Python, Java, C#, Go, Ruby,… hoặc container thông qua custom runtime.
Tích hợp sâu với các dịch vụ AWS khác: Có thể dễ dàng kết nối với S3, API Gateway, DynamoDB, Kinesis, SQS, SNS,…
Miễn phí : 1 triệu request và 400.000 GB-giây mỗi tháng hoàn toàn miễn phí.

3. Cách tính giá AWS Lambda

Lượt gọi: 1 triệu lượt gọi đầu tiên mỗi tháng miễn phí. Sau đó, tính 0.20 USD mỗi 1 triệu lượt gọi thêm.
Thời gian tính theo GB-giây: 400.000 GB-giây miễn phí mỗi tháng. Sau đó, tính 1 USD cho mỗi 600.000 GB-giây.

GB-giây là đơn vị đo thời gian chạy nhân với bộ nhớ cấp phát. Ví dụ, một hàm Lambda dùng 1 GB RAM và chạy trong 1 giây sẽ tiêu tốn 1 GB-giây. Nếu bạn chỉ dùng 128 MB RAM, thì bạn sẽ tiêu tốn ít hơn rất nhiều.

4. Execution Limits & Deployment Limits

Execution Limits:

Bộ nhớ (Memory): có thể cấp phát từ 128 MB đến 10 GB và phải theo bội số của 64 MB.
Khi tăng bộ nhớ, số lượng vCPU cũng tăng theo, giúp hàm Lambda thực thi nhanh hơn.
Thời gian chạy tối đa: mỗi hàm Lambda chỉ có thể chạy tối đa 900 giây (15 phút). Nếu workload của bạn cần chạy lâu hơn, thì Lambda không phù hợp.
Biến môi trường (Environment Variables): tổng dung lượng tối đa cho tất cả biến môi trường là 4 KB.
Thư mục tạm thời (/tmp): nếu cần xử lý file lớn tạm thời, bạn có thể sử dụng thư mục /tmp với dung lượng tối đa 10 GB.
Số lượng hàm Lambda chạy đồng thời (Concurrent Executions): mặc định là 1,000. Có thể yêu cầu tăng thêm qua AWS Support nếu cần.
Reserved Concurrency: nên sử dụng để giới hạn số lượng thực thi đồng thời của từng hàm, giúp kiểm soát tài nguyên.

Deployment Limits:

Kích thước file nén (ZIP) tối đa: 50 MB.
Kích thước mã không nén tối đa: 250 MB.
Nếu code hoặc dữ liệu vượt quá giới hạn trên, bạn nên tải file lớn vào thư mục /tmp trong thời gian thực thi.

5. Concurrency trong Lambda là gì?

Concurrency đơn giản là số lượng hàm Lambda đang được thực thi cùng một lúc. Ví dụ:

Nếu bạn có 1000 sự kiện đến đồng thời, Lambda có thể mở rộng để chạy 1000 instance của hàm.
Giới hạn mặc định là 1000 concurrent executions cho toàn tài khoản (per region). Có thể yêu cầu tăng thêm qua AWS Support.

5.1. Reserved Concurrency

Giả sử bạn có 3 ứng dụng dùng 3 hàm Lambda khác nhau. Khi một ứng dụng bất ngờ có lưu lượng cao (ví dụ do chạy quảng cáo), Lambda sẽ ưu tiên xử lý các yêu cầu đó và có thể chiếm hết 1000 concurrency.

Kết quả: 2 ứng dụng còn lại sẽ bị throttled và lỗi, gây ảnh hưởng toàn hệ thống.

Bạn có thể đặt giới hạn riêng cho từng hàm Lambda thông qua Reserved Concurrency:

Ví dụ: giới hạn một hàm chỉ được thực thi tối đa 50 concurrent executions.
Điều này giúp ngăn một hàm “ăn hết tài nguyên” của toàn tài khoản.
Khi vượt quá giới hạn này, các yêu cầu mới sẽ bị throttled.

5.2. Throttling – Khi Lambda bị giới hạn

Nếu số lượng request vượt quá giới hạn concurrency, Lambda sẽ từ chối xử lý thêm. Hành vi tùy thuộc vào loại invocation:

Synchronous invocation (đồng bộ): nhận ngay lỗi 429 - ThrottlingException.
Asynchronous invocation (bất đồng bộ): Khi Lambda bị throttled hoặc lỗi 5xx, Lambda sẽ tự động retry tối đa trong 6 giờ và có thể đưa sự kiện vào Dead Letter Queue (DLQ) nếu vẫn thất bại. Khoảng thời gian giữa các lần retry tăng dần theo exponential backoff: từ 1 giây đến tối đa 5 phút.

6. Cold Start và Provisioned Concurrency

Cold Start xảy ra khi Lambda phải khởi tạo môi trường mới cho một instance:

Tải code, load thư viện, khởi tạo SDK, kết nối DB,…
Gây độ trễ cao cho lần request đầu tiên (vài trăm mili giây đến vài giây).

Để tránh cold start, hãy dùng Provisioned Concurrency:

Giữ sẵn các instance Lambda đã khởi tạo và luôn sẵn sàng chạy.
Phù hợp với ứng dụng cần độ trễ thấp như API hoặc real-time app.
Quản lý bằng Application Auto Scaling để mở rộng linh hoạt theo lịch hoặc theo nhu cầu.

7. Lambda SnapStart

AWS Lambda SnapStart là một tính năng tối ưu hóa hiệu suất cho các hàm Lambda, đặc biệt hỗ trợ các ngôn ngữ như Java, Python và .NET. Với SnapStart, thời gian khởi tạo hàm Lambda có thể được giảm đi đáng kể — lên đến 10 lần — mà không tốn thêm chi phí nào.

7.1. Vấn đề khi không sử dụng SnapStart

Khi SnapStart bị vô hiệu hóa, mỗi lần Lambda được gọi sẽ trải qua 3 giai đoạn trong vòng đời:

Initialize – Giai đoạn khởi tạo hàm: Tải mã nguồn, khởi tạo thư viện, tạo kết nối ban đầu…
Invoke – Giai đoạn thực thi: Hàm bắt đầu xử lý yêu cầu thực tế.
Shutdown – Giai đoạn kết thúc: Giải phóng tài nguyên, đóng kết nối nếu cần.

Vấn đề là: với các ngôn ngữ như Java, giai đoạn initialize thường tiêu tốn nhiều thời gian do việc tải JVM, thư viện và cấu hình phức tạp. Điều này làm tăng cold start latency (độ trễ khi khởi động lần đầu).

Lợi ích:

Giảm độ trễ cold start đáng kể — phù hợp cho các ứng dụng yêu cầu phản hồi nhanh.
Không cần thay đổi mã nguồn — chỉ cần bật SnapStart trong cấu hình hàm.
Miễn phí — không tính thêm chi phí khi sử dụng.

7.2. SnapStart hoạt động như thế nào?

Khi bạn bật SnapStart và đăng một phiên bản mới cho hàm Lambda, AWS sẽ tự động thực hiện các bước sau:

Khởi chạy hàm Lambda như bình thường đến hết giai đoạn initialize.
Chụp lại toàn bộ trạng thái của hàm (bao gồm bộ nhớ và đĩa).
Lưu lại ảnh chụp đó để sử dụng cho các lần gọi sau.

Với ảnh chụp đã được tạo, khi có yêu cầu gọi hàm, Lambda có thể nhanh chóng chuyển sang giai đoạn invoke, bỏ qua bước khởi tạo tốn thời gian.

8. CloudFront Functions và Lambda@Edge

Khi bạn triển khai các ứng dụng hoặc dịch vụ web trên AWS, chúng thường nằm trong một khu vực (region) cụ thể. Tuy nhiên, để tối ưu hiệu suất và giảm độ trễ cho người dùng trên toàn cầu, AWS sử dụng CloudFront – một dịch vụ CDN (Content Delivery Network) phân phối nội dung thông qua các Edge Locations (vị trí biên).

Trong một số tình huống, bạn cần thực thi một số logic hoặc tùy biến ngay tại Edge – trước khi yêu cầu từ người dùng đến được máy chủ chính. Đây là lúc mà các Edge Functions như CloudFront Functions và Lambda@Edge phát huy tác dụng.

8.1. Edge Functions là gì?

Edge Functions là những đoạn mã chạy tại các vị trí Edge của CloudFront, giúp xử lý hoặc điều chỉnh yêu cầu/phan hồi ngay gần người dùng cuối – từ đó giảm độ trễ và cải thiện hiệu suất trải nghiệm.

Lợi ích chính của Edge Functions:

Không cần quản lý máy chủ (serverless).
Triển khai toàn cầu, phân tán tự động.
Chỉ trả tiền khi sử dụng.
Phù hợp với các ứng dụng hiện đại yêu cầu xử lý tức thời tại Edge.

Các tình huống sử dụng phổ biến:

Bảo mật và quyền riêng tư cho website.
Tùy biến ứng dụng web động ngay tại Edge.
Tối ưu SEO (Search Engine Optimization).
Định tuyến thông minh giữa nhiều nguồn gốc (Origins).
Chống bot (Bot Mitigation).
Chuyển đổi ảnh theo thời gian thực.
Thử nghiệm A/B.
Xác thực và phân quyền người dùng.
Ưu tiên người dùng, phân tích hành vi.

8.2. So sánh CloudFront Functions và Lambda@Edge

CloudFront Functions

Viết bằng JavaScript.
Xử lý cực nhanh (dưới 1 mili giây).
Khả năng mở rộng cực lớn (triệu yêu cầu/giây).
Chỉ hoạt động tại giai đoạn Viewer Request và Viewer Response.
Không có quyền truy cập mạng hoặc hệ thống tập tin.
Thích hợp cho các xử lý đơn giản, nhẹ.

Ví dụ về ứng dụng:

Chuẩn hóa cache key.
Thay đổi hoặc xóa HTTP headers.
Chuyển hướng URL.
Kiểm tra JWT token để cấp hoặc từ chối quyền truy cập.

Lambda@Edge

Hỗ trợ Node.js và Python.
Thời gian thực thi lên tới 5–10 giây.
Hỗ trợ tại cả 4 giai đoạn: Viewer Request, Origin Request, Origin Response, Viewer Response.
Có thể truy cập mạng, hệ thống tập tin, và thân của HTTP request.
Hỗ trợ sử dụng thư viện bên ngoài như AWS SDK.
Thích hợp cho xử lý phức tạp, cần tích hợp với hệ thống khác.

9. AWS Lambda và RDS Proxy

Trong AWS, các hàm Lambda mặc định được triển khai bên ngoài VPC của bạn. Cụ thể, chúng được chạy trong một VPC riêng do AWS quản lý. Điều này có nghĩa là nếu bạn muốn hàm Lambda truy cập tài nguyên nội bộ trong VPC của mình (ví dụ như RDS, ElastiCache hay Load Balancer nội bộ), thì mặc định sẽ không thể truy cập được.

9.1. Triển khai Lambda mặc định (ngoài VPC)

Với cấu hình mặc định:

Lambda có thể truy cập các dịch vụ public như Internet API hoặc DynamoDB.
Không thể kết nối tới các tài nguyên private trong VPC như RDS hoặc ElastiCache.

9.2. Kết nối Lambda với VPC của bạn

Để Lambda truy cập được các tài nguyên trong VPC, bạn cần:

Khai báo VPC ID khi cấu hình Lambda.
Chỉ định subnets nơi Lambda sẽ được triển khai (thường là private subnets).
Đính kèm Security Group cho Lambda để kiểm soát truy cập.

Sau đó, AWS sẽ tạo Elastic Network Interface (ENI) cho Lambda trong các subnet bạn chỉ định. Nhờ đó, Lambda có thể giao tiếp với các dịch vụ như Amazon RDS trong cùng VPC.

Ví dụ ứng dụng thực tế:

Giả sử bạn có một Lambda cần truy cập một cơ sở dữ liệu RDS trong private subnet. Khi triển khai Lambda trong VPC, việc này sẽ trở nên khả thi.

9.3. Sử dụng Lambda với RDS Proxy

Một vấn đề thường gặp khi Lambda kết nối trực tiếp tới RDS là:

Mỗi lần Lambda khởi chạy, nó tạo một kết nối mới đến RDS.
Dưới tải cao, điều này có thể gây quá tải số lượng kết nối tới RDS, dẫn đến lỗi và timeout.

Giải pháp:

Sử dụng RDS Proxy nằm giữa Lambda và RDS để quản lý và gom nhóm kết nối.

Kiến trúc hoạt động:

Lambda kết nối đến RDS Proxy.
RDS Proxy duy trì một nhóm kết nối ổn định với RDS instance.
Kết nối hiệu quả và giảm tải cho RDS.

Lưu ý quan trọng:

RDS Proxy là tài nguyên không công khai (private), nên Lambda phải được triển khai trong VPC để có thể kết nối tới RDS Proxy. Nếu Lambda được triển khai mặc định (ngoài VPC), thì không thể nào truy cập được RDS Proxy.

AWS Lambda là một giải pháp cực kỳ mạnh mẽ và tiết kiệm cho các ứng dụng cần phản hồi theo sự kiện, xử lý ngắn hạn hoặc thực hiện các công việc định kỳ. Với khả năng tích hợp sâu với hệ sinh thái AWS và mức giá linh hoạt, đây là một công cụ không thể thiếu cho các kiến trúc hiện đại, đặc biệt là trong các hệ thống serverless.

AWS Lambda – Bài 25