Working with AWS Lambda functions - part 1

Overview

Chào mọi người, hôm này mình nói về AWS Lambda. Ở bài này mình đang hướng đến best practice cho việc xây dựng lambda kết hợp API Gateway để cung cấp Rest API cho enduser.
Nội dung bài hôm nay sẽ chia thành 2 phần.

• Đầu tiên là tuân thủ best practice với AWS Lambda với docs: https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html. Ae nào ngại đọc tiếng việt thì có thể đọc docs của AWS nhé.
• Cold Start là 1 vấn đề lớn của AWS Lambda, thực ra 1 số checklist trong phần best practice ở trên cũng liên quan đến cold start. Chúng ta thử tìm hiểu các giải pháp để giảm thời gian cold Start nhé.

1. Best Practices for Lambda (checklist)

Function Code

Liên quan đến best practice cho function code. Mọi người chịu khó đọc https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-code nhé. Cái này còn liên quan đến bạn chạy Runtime là gì, logic. Nên có thể coi để tham khảo nhé. Mình liệt kê keyword ở dưới đây:

• Separate the Lambda handler from your core logic
• Take advantage of execution environment reuse to improve the performance of your function.
• Use a keep-alive directive to maintain persistent connections
• Use environment variables to pass operational parameters to your function.
• Control the dependencies in your function’s deployment package
• Minimize your deployment package size to its runtime necessities
• Reduce the time it takes Lambda to unpack deployment packages
• Minimize the complexity of your dependencies
• Avoid using recursive code
• Choosing Right Programming Language
  https://www.simform.com/blog/lambda-cold-starts/#section34
  Thông tin benchmark thì ở đây. Tuy nhiên, cá nhân mình chạy các dự án thì không được quyết định hoàn toàn về ngôn ngữ. Có vẻ theo Benchmark thì NodeJS và Python đang đạt performance tốt nhất.

Function Configuration

• Performance testing: Bạn cần test Performance của Lambda function. Và đánh giá được max memory (CPU). Với mỗi mức memory thì sẽ cho performance như thế nào.
• Memory Configuration: Từ bước ở trên ta sẽ xác định được memory cần cấp phát cho lambda function. Tất nhiên cũng cần buffer thêm. Việc test performance này giúp bạn cân đối được với memory là bao nhiêu thì bạn chấp nhận được performance của lambda chẳng hạn.
• Load test Lambda function: Việc test cũng giúp bạn xác định được max timeout là bao nhiêu. Từ đó thiết lập tránh những trường hợp chạy max 15phút khá tốn cost vì lambda tính tiền theo duration.
• Use most-restrictive permissions when setting IAM policies: Tất nhiên rồi, bạn cần giới hạn permissions cho IAM Role được attach hoặc Resource Base Policy.
• Lambda quotas: Bạn cần quan tâm xem Lambda quotas hiện tại đã đáp ứng được chưa nhé. Nếu không đủ mà quota có thể request AWS nâng lên thì hãy làm, hoặc cũng có kế hoạch xử lý.
• Use with SQS: Lưu ý là SQS Visible Timeout phải lớn hơn thời gian lambda xử lý nhé.

Metrics and alarms

Khi triển khai Lambda là serverless trên AWS. Vậy nên tất cả các dịch vụ đi kèm cũng nên là ở trên AWS để dễ dàng tích hợp. Thật may là AWS Cloudwatch giúp đỡ ta rất mạnh mẽ.

• Metrics and CloudWatch Alarms: Chúng ta cần tạo Dashboard, Alarm cho lambda function. Các bạn nhớ enable Lambda Insight nhé.
• Logs của Lambda thì sẽ được tập hợp về Cloudwatch Logs. Vậy nên để phân biệt dễ hãy cố gắng đặt tên lambda function thật tường mình nhé.
• Tracing Request with X-Ray: Ngoài ra mọi người có thể tham khảo việc tracing và analyzing request với AWS X-Ray nhé. Mọi người tham khảo Pricing trước khi sử dụng nhé.

2. Code Start time

What is Cold Start in Lambda?

Hình mình tham khảo từ AWS chính là vòng đời của 1 Lambda function (Lambda container thì cũng tương tự).
Như mọi người thấy có 4 giai đoạn:

• Download code => Cái này do AWS Optimize, tất nhiên bạn cũng cần optimize code của bạn nữa.
• Start new container => nếu AWS kiểm tra k có container nào đang chạy, nó sẽ phải start container mới
• Run Bootstrap => phần này là cài dependencies. phần này chúng ta phải optimize. Cái này bạn cần optimize để chỉ các package nào cần, nhỏ gọn chẳng hạn.
• Warm Start với code của chúng ta, cái này còn phụ thuộc vào ngôn ngữ sử dụng. Và chúng ta cũng phải optimize.

Vậy thời gian Cold Start = Download code + Start new Container + Run Bootstrap.
Và như chúng ta thấy việc cold start này chỉ xảy ra khi bạn chạy lần đầu. Từ lý do khi muốn ta muốn tăng trải niệm người dùng, giảm độ trễ, Chúng ta sẽ cần đưa ra các giải pháp để hạn chế cold start đi. Nhưng tất nhiên, để đánh đổi được việc đó thì tất cả các giải pháp này đều sẽ làm tăng chi phí.

Một số cách để giảm AWS Lambda Cold Start

Các giải pháp thì mình tham khảo từ https://www.simform.com/blog/lambda-cold-starts/ . Vì mình thấy bài này viết thực sự đầy đủ.

Solution 1. Run Lambdas Out of VPC

Mọi người có thể tự test để trải niệm hoặc tham khảo kết quả benmark của Nathan.
Việc build lambda function đặt trong 1 VPC bạn tự tạo thì coldstart gấp nhiều lần với lambda function được AWS tự động cấp phát network. Vậy nên chỉ trừ trường hợp bạn bắt buộc phải attach VPC để có thể giao tiếp về mặt network với thành phần khác thì hãy cố gắng hướng tới việc triển khai Lambda với no-VPC nha.
Ví dụ:

• Lambda => DynamoDB thì k cần attach VPC
• Lambda => RDS Proxy => RDS thì cần attach VPC.

Solution 2. Provisional Concurrency

Lý thuyết về Provisioning Concurency: https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html#managing-provisioned-concurency

Liên quan đến lý thuyết cold start ở trên, bây giờ để tránh bị cold start chúng ta sẽ cho chạy sẵn 1 số lượng concurency lambda. Khi hệ thống peak hour thì các request sẽ k bị cold start mà sẽ thực hiện luôn.
Đây có lẽ là giải pháp xử lý hoàn toàn được cold start. Tuy nhiên đánh đổi của nó là cost. Điểm mạnh của Lambda là chỉ sử dụng khi cần => chỉ trả phí duration khi có request. Tuy nhiên với Provisioning Concurency thì chúng ta hiểu như là bật 24/24 rồi. Từ đó sẽ thấy Cost khi sử dụng lambda bị tăng lên rất nhiều, theo mình thấy là còn hơn chạy EC2 nhiều. Lúc này, chúng ta chỉ đảm bảo tiêu chí được khả năng đáp ứng
Tuy nhiên, ta cũng có vài giải pháp để giảm thiểu với ApplicationAutoScaling bằng cách kết hợp với Dynamic Scale hoặc Schedule Scale giá trị Provision Concurency để giảm thiểu cost. Mình áp dụng cho dự án của mình và thấy khá hiệu quả. Mọi người có thể tham khảo link này nhé: https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/

Solution 3. Keeping Your Lambda Functions Warm

Giải pháp này thì bản chất là cũng muốn giữ cho Lambda function luôn ở trạng thái Warm. Lợi dụng cơ chế, sau khi lambda function xử lý request xong thì container sẽ được keep warm trong 1 khoảng thời gian, hình như là 15 phút gì đó. Nên từ đó chúng ta sẽ xây dựng cơ chế ping tới lambda đó sau 1 khoảng thời gian (ví dụ 5 phút 1 lần).
Tất nhiên giải pháp này thì tiết kiệm hơn giải pháp provisioning concurency ở trên.
Tuy nhiên, mình thấy việc ping này chỉ keep warm cho 1 containers thôi. Ví dụ vào thời điểm peak hour thì sẽ không phù hợp, hệ thống vẫn bị cold start.
Mọi người tham khảo:
https://github.com/juanjoDiaz/serverless-plugin-warmup

Kết luận:

Bài viết này là trong quá trình mình làm việc với Lambda dẫn tới việc phải research các tài liệu dưới đây để viết checklist cũng như các giải pháp cho các vấn đề của Lambda. Rất mong được mọi người góp thêm của mọi người.
Ở bài viết sau có lẽ mình sẽ viết bài lab để xử lý colde start.
Bài viết được tham khảo từ:

• AWS Docs: https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
• Schedule Provisioning Solutions: https://aws.amazon.com/blogs/compute/scheduling-aws-lambda-provisioned-concurrency-for-recurring-peak-usage/
• Tham khảo solution, benchmark từ: https://www.simform.com/blog/lambda-cold-starts

---

• Next Post →

---

---