___
bởi James Beswick | 20 tháng 8, 2023 | Lambda, Serverless| Permailink | Share
Bài đăng này được viết bởi Josh Kahn, Trưởng nhóm công nghệ, và Chloe Jeon, Senior PMTes Lambda.
Các ứng dụng serverless có thể giảm tổng chi phí sở hữu (TCO) so với mô hình thực thi dựa trên máy chủ vì nó hiệu quả chuyển trách nhiệm vận hành như quản lý máy chủ cho một nhà cung cấp điện toán đám mây. Nghiên cứu của Deloitte về TCO không máy chủ với các khách hàng Fortune 100 trên các ngành công nghiệp cho thấy rằng các ứng dụng serverless có thể tiết kiệm được đến 57% chi phí so với các giải pháp dựa trên máy chủ.
Các ứng dụng serverless có thể giảm chi phí trong:
- Phát triển ban đầu: Serverless cho phép các nhà xây dựng trở nên linh hoạt hơn, cung cấp các tính năng nhanh hơn và tập trung vào logic kinh doanh khác biệt.
- Cơ sở hạ tầng và bảo trì liên tục: Serverless chuyển gánh nặng vận hành sang AWS. Các nhiệm vụ bảo trì liên tục, bao gồm vá lỗi và cập nhập hệ điều hành.
Bài đăng này tập chung vào các tùy chọn có sẵn để giảm chi phí AWS trực tiếp khi xây dựng ứng dụng serverless. AWS Lambda thường là lớp điện toán trong các khối lượng công việc và có thể chiếm một phần đáng kể trong tổng chi phí.
Để giúp tối ưu giá liên quan đến Lambda, bài đăng này thảo luận về một số kỹ thuật tối ưu hóa tối ưu hóa chi phí sử dụng phổ biến nhất, nhấn mạnh vào những thay đổi về cấu hình khi cập nhập mã. Bài đăng mở rộng cho các kiến trúc sư và phát triển mới để xây dựng với serverless.
Xây dựng với serverless làm cho cả việc thử nghiệm và lặp cải tiến trở nên dễ dàng hơn. Tất cả kỹ thuật được mô tả ở đây có thể áp dụng trước khi phát triển ứng dụng hoặc sau khi triển khai ứng dụng của mình vào sản phẩm. Các kỹ thuật đại khái dựa trên khả năng của ứng dụng: Đầu tiên có thể áp dụng cho bất cứ khối lượng công việc nào; điều cuối cùng áp dụng cho số lượng khối lượng công việc nhỏ hơn.
Điều chỉnh kích thước Lambda function của bạn
Lambda sử dụng mô hình trả phí được điều khiển bởi 3 chỉ số:
- Cấu hình bộ nhớ: bộ nhớ được phân bổ từ 128MB đến 10,240MB. CPU và tài nguyên khác có sẵn cho function được phân bổ tương ứng với bộ nhớ.
- Hàm thời gian: thời gian function chạy, đo bằng mili giây.
- Số lần gọi: số lần bạn chạy function.
Việc cung cấp quá mức bộ nhớ là một trong những lý do khiến giá Lambda tăng. Điều này đặc biệt nghiêm trọng với người xây dựng mới sử dụng Lambda, những người thường đã quen với việc cung cấp nhiều quy trình chạy máy chủ. Lambda điều chỉnh quy mô sao cho môi trường thực thi của một function chỉ xử lý yêu cầu tại một thời điểm. Mỗi môi trường thực thi có quyền truy cập vào các tài nguyên (bộ nhớ, CPU, bộ lưu trữ) để hoàn thành công việc yêu cầu.
Bằng cách điều chỉnh kích thước phù hợp với cấu hình bộ nhớ, function sẽ có tài nguyên để hoàn thành công việc và bạn chỉ phải trả số tiền cho những tài nguyên cần thiết. Khi đó bạn cũng có quyền kiểm soát trực tiếp thời lượng của function nhưng đây là cách tối ưu hóa chi phí kém hiệu quả hơn để thực hiện. Chi phí kỹ thuật để tiết kiệm được vài mili giây có thể lớn hơn chi phí tiết kiệm được. Tùy vào khối lượng công việc, số lần function của bạn được gọi có thể nằm ngoài tầm kiểm soát của bạn. Phần tiếp theo sẽ thảo luận về kỹ thuật giúp giảm số lượng lệnh gọi đối với một số loại công việc.
Cấu hình bộ nhớ thông qua Bảng điều khiển quản lý AWS hoặc tùy chọn cơ sở hạ tầng yêu thích dưới dạng code (IaC). Cài đặt cấu hình bộ nhớ xác định bộ nhớ được phân bổ, không phải bộ nhớ sử dụng bởi function của bạn. Bộ nhớ có kích thước phù hợp là sự điều chỉnh có thể giảm chi phí (hoặc tăng hiệu xuất) cho function của bạn. Tuy nhiên, việc giảm bộ nhớ function có thể không luôn giúp tiết kiệm chi phí. Giảm bộ nhớ function nghĩa là giảm CPU có sẵn function của Lambda function, điều này có thể tăng thời lượng của function, dẫn đến không tiết kiệm được chi phí hoặc chi phí cao hơn. Quan trọng là xác định cấu hình bộ nhớ để tối ưu chi phí trong khi vẫn duy trì hiệu suất.
AWS cung cấp hai cách tiếp cận để phân bổ bộ nhớ: AWS Lambda Power Tuning và AWS Compute Optimizer.
AWS Lambda Power Tuning là một công cụ mã nguồn mở có thể sử dụng để tìm cấu hình bộ nhớ cho function của bạn theo kinh nghiệm bằng các đánh đổi giữa chi phí và thời gian thực hiện. Công cụ này chạy nhiều phiên bản đồng thời của function của bạn dựa trên dữ liệu đầu vào mô phỏng ở các mức phân bố bộ nhớ khác nhau. Kết quả là một biểu đồ có thể giúp bạn tìm “Điểm phù hợp” giữa chi phí và thời gian/hiệu suất. Phụ thuộc vào khối lượng công việc, bạn có thể ưu tiên cái này hơn là cái kia. AWS Lambda Power Tuning là sự lựa chọn tốt cho function mới và cũng giúp chọn giữa hai kiến trúc tập lệnh do Lambda cung cấp.
AWS Compute Optimizer sử dụng học máy để đề xuất cấu hình bộ nhớ dựa trên lịch sử dữ liệu. Compute Optimizer yêu cầu function của bạn phải được gọi ít nhất 50 lần trong 14 ngày để cung cấp đề xuất dựa vào mức sử dụng trước đây, cách này hiệu quả nhất khi function của bạn được đưa vào hoạt động.
Cả Lambda Power Tuning và Compute Optimizer giúp tối ưu hóa bộ nhớ được phân bổ phù hợp cho function của bạn. Sử dụng giá trị này để cập nhập cấu hình function của bạn. Sử dụng giá trị này để cập nhập cấu hình function của bạn sử dụng AWS Management Console hoặc IaC.
Bài đăng này bao gồm code AWS Serverless Application Model (AWS SAM) xuyên suốt để trình bày cách triển khai tối ưu hóa. Bạn cũng có thể sử dụng AWS Cloud Development Kit (AWS CDK), Terraform, Serverless Framework, và công cụ IaC khác để thực hiện những triển khai tương tự.
YAML
| MyFunction: Type: AWS::Serverless::Function Properties: Runtime: nodejs18.x Handler: app.handler MemorySize: 1024 # Set memory configuration to optimize for cost or performance |
Đặt thời gian chờ function thực tế
Các Lambda functions được cấu hình với thời gian tối đa mà mỗi lệnh gọi có thể chạy, tối đa 15 phút. Việc cái đặc thời gian chờ thích hợp có thể hữu ích trong việc giảm chi phí cho ứng dụng dựa trên Lambda của bạn. Các trường hợp ngoại lệ, hành động chặn (ví du: mở kết nối mạng), phần phụ thuộc chậm và các điều kiện khác có thể dẫn đến các function chạy lâu hơn hoặc các function chạy cho đến hết timeout. Timeout tốt nhất là cách bảo vệ tốt nhất chống lại cả mã chậm và mã sai. Tai một thời điểm nào đó, công việc mà function đó đang thực hiện và chi phí trên mỗi mili giấy của công việc đó bị lãng phí.
Đề xuất của chúng tôi là thành lập timeout dưới 29s cho tất cả lệnh gọi đồng bộ hoặc những yêu cầu mà người gọi đang chờ phản hồi. Timeout dài phù hợp cho các yêu cầu không đồng bộ, những hãy cân nhắc timeout dài hơn 1p là một ngoại lệ cần được xem xét và kiểm tra.
Sử dụng Graviton
Lambda cung cấp hai kiến trúc tập lệnh trong phần lớn AWS regions: x86 và arm64.
Chọn Graviton có thể tiết kiệm tiền theo hai cách. Đầu tiên, những functions có thể chạy hiệu quả hơn nhờ kiến trúc Graviton 2. Thứ hai, bạn có thể trả ít hơn cho thời gian chúng chạy. Các Lambda function do Graviton 2 cung cấp được thiết kế để mang lại hiệu suất tốt hơn tới 19% với chi phí thấp hơn 20%. Hãy cân nhắc bắt đầu với Graviton khi phát triển các Lambda function mới, đặc biệt function không yêu cầu các tệp nhị phân được biên dịch nguyên gốc.
Nếu function của bạn dựa trên các tệp nhị phân được biên dịch gốc hoặc được đóng gói dưới dạng vùng chứa hình ảnh, bạn phải xây dựng lại để di chuyển giữa arm64 và x86. Các lớp Lambda cũng có thể bao gồm các phần phụ thuộc được định hướng cho kiến trúc này hoặc kiến trúc kia. Chúng tôi khuyến khích bạn xem lại các phần phụ thuộc và kiểm tra function của mình trước khi thay đổi kiến trúc. Công cụ AWS Lambda Power Tuning cũng cho phép bạn so sánh giá cả và hiệu suất của arm64 và x86 ở các cài đặt bộ nhớ khác nhau.
Bạn có thể sửa đổi cấu hình kiến trúc của function trong bảng điều khiển hoặc IaC mà bạn chọn. Ví du, trong AWS SAM:
YAML
| MyFunction: Type: AWS::Serverless::Function Properties: Architectures: – arm64 # Set architecture to use Graviton2 Runtime: nodejs18.x Handler: app.handler |
Lọc các sự kiện đến
Lambda được tích hợp với hơn 200 event sources, bao gồm Amazon SQS , Amazon Kinesis Data Streams , Amazon DynamoDB Streams , Amazon Managed Streaming for Apache Kafka và Amazon MQ . Dịch vụ Lambda tích hợp với các event source này để truy xuất thông báo và gọi function của bạn khi cần để xử lý các thông báo đó.
Khi làm việc với một trong những event sources này, người xây dựng có thể định cấu hình bộ lọc để giới hạn các sự kiện được gửi đến function của bạn. Kỹ thuật này có thể giảm đáng kể số lần function của bạn được gọi tùy thuộc vào số lượng event và tính đặc hiệu của bộ lọc. Khi không sử dụng tính năng lọc event, trước tiên, function phải được gọi để xác định xem một sự kiện có nên được xử lý hay không trước khi thực hiện công việc thực tế. Tính năng lọc sự kiện giúp giảm bớt nhu cầu thực hiện việc kiểm tra trước này đồng thời giảm số lượng lệnh gọi.
Ví dụ: bạn có thể chỉ muốn một function chạy khi tìm thấy các đơn hàng trên 200 USD trong tin nhắn trên luồng dữ liệu Kinesis. Bạn có thể định cấu hình mẫu lọc event bằng bảng điều khiển hoặc IaC theo cách tương tự như cấu hình bộ nhớ.
Để triển khai bộ lọc luồng Kinesis bằng AWS SAM:
YAMl
| MyFunction: Type: AWS::Serverless::Function Properties: Runtime: nodejs18.x Handler: app.handler Events: Type: Kinesis Properties: StartingPosition: LATEST Stream: “arn:aws:kinesis:us-east-1:0123456789012:stream/orders” FilterCriteria: Filters: – Pattern: ‘{ “data” : { “order” : { “value” : [{ “numeric”: [“>”, 200] }] } } }’ |
Nếu một event đáp ứng một trong các bộ lọc event được liên kết với event source, Lambda sẽ gửi event đó đến function của bạn để xử lý. Nếu không, sự kiện sẽ bị loại bỏ do được sử lý thành công mà không gọi function.
Nếu bạn xây dựng hoặc chạy một Lambda function được gọi bởi một trong các event source đề cấp trước đó, nó đề xuất rằng bạn nên xem lại các tùy chọn lọc có sẵn. Kỹ thuật này không yêu cầu thay đổi code với Lambda function của bạn – ngay cả khi function thực hiện một số kiểm tra tiền xử lý, kiểm tra đó vẫn hoàn tất thành công với bộ lọc được thực hiện.
Để biết thêm, đọc Filtering event sources for AWS Lambda functions.
Tránh đệ quy
Bạn có thể quen với khái niệm chương trình hoặc hàm đệ quy hoặc một hàm/quy trình gọi lại chính nó. Mặc dù hiếm gặp, đôi khi khách hàng vô tình xây dựng đệ quy trong kiến trúc của họ, do đó Lambda function liên tục gọi chính nó.
Mẫu đệ quy phổ biến nhất là giữa Lambda và Amazon S3. Các hành động trong S3 bucket có thể kích hoạt Lambda function và quá trình đệ quy có thể xảy ra khi Lambda function ghi lại cùng một vùng lưu trữ.
Hãy xem xét một trường hợp sử dụng trong đó một Lambda function được sử dụng để tạo ảnh thu nhỏ của các hình ảnh được gửi bởi người dùng. Bạn cấu hình bucket để kích hoạt function tạo ảnh thu nhỏ khi một đối tượng mới được đặt trong bucket. Điều gì sẽ xảy ra nếu Lambda function ghi ảnh thu nhỏ vào cùng một bucket? Quá trình sẽ bắt đầu lại từ đầu và function Lambda sau đó sẽ chạy trên chính ảnh thu nhỏ đó. Điều này là đệ quy và có thể dẫn đến một điều kiện vòng lặp vô hạn.
Trong khi đó có nhiều cách để ngăn chặn tình trạng này, nhưng cách tốt nhất là sử dụng một s3 bucket thứ hai để lưu trữ hình ảnh nhỏ. Cách tiếp cận này giảm thiểu các thay đổi tới kiến trúc vì bạn không cần thay đổi cài đặt thông báo cũng như s3 bucket chính. Để biết thêm về các phương pháp khác, đọc Avoiding recursive invocation with Amazon S3 and AWS Lambda.
Nếu bạn gặp phải đệ quy trong kiến trúc của bạn, đặt Lambda reserved concurrency về 0 để ngăn chặn function chạy. Hãy cho phép một khoảng thời gian từ vài phút đến vài giờ trước khi tăng giới hạn “reserved concurrency” trở lại. Vì các s3 events là asynchronous invocations có thử lại tự động, bạn có thể tiếp tục thấy đệ quy đến khi bạn giải quyết được sự cố hoặc tất cả sự kiện đã hết hạn.
Kết luận
Lambda cung cấp một số kỹ thuật mà bạn có thể sử dụng để giảm thiểu chi phí cơ sở hạ tầng cho dù bạn mới bắt đầu sử dụng Lambda hay đã triển khai nhiều function trong sản xuất. Khi kết hợp với chi phí phát triển ban đầu và bảo trì liên tục thấp hơn, serverless có thể mang lại tổng chi phí sở hữu thấp. Bắt tay thực hành những kỹ thuật này và hơn thế nữa với Serverless Optimization Workshop.
Để biết thêm về kiến trúc serverless, tìm các mẫu có thể tái sử dụng, và cập nhập, hãy truy cập Serverless Land.
TAGS: đã đóng góp, serverless
AWS Study Group 