Chức năng của Lambda so với Step: Trận chiến giữa chi phí và hiệu suất

Trong vài tuần qua, tôi đã thực hiện một số phân tích về cách bạn có thể bắt đầu chuyển sang Chức năng từng bước như một phần của quy trình phát triển tiêu chuẩn của bạn. Bạn có tùy chọn chuyển sang “lưu trữ trước” với quy trình làm việc hoàn toàn không đồng bộ hoặc hoàn toàn đồng bộ với các máy trạng thái nhanh.
Có những trường hợp sử dụng cho cả hai, nhưng sự đồng thuận cho phát triển sản xuất tồn tại với một cách tiếp cận kết hợp: thực hiện đồng bộ nhóm hành động cơ sở, như xác thực và tạo id và khởi động phần còn lại của quá trình xử lý một cách không đồng bộ. Sau đó, bạn sẽ sử dụng WebSocket để thông báo cho người dùng khi quy trình làm việc hoàn tất.
Các nhà phát triển có bản chất là tò mò. Tôi đã có một loạt người trả lời các bài đăng của tôi trên LinkedIn và Twitter hỏi sự khác biệt về chi phí giữa Lambda và Step Functions. Rốt cuộc, tôi đang cố gắng loại bỏ Lambda hoàn toàn. Có vẻ như một câu hỏi chính đáng.
Để tìm ra tác động đối với ví, chúng tôi cần xác định cách mỗi dịch vụ này được lập hóa đơn. AWS có một số cách để tính phí bạn với các dịch vụ không máy chủ của họ, nhưng tuyệt vời về tính minh bạch và hoàn toàn không có chi phí ẩn .
Hãy đi sâu vào và thực hiện một số phân tích về chi phí và hiệu suất của AWS Lambda và AWS Step Functions .
Yếu tố chi phí
Hôm nay chúng ta sẽ so sánh ba cách tiếp cận khác nhau: Lambda , quy trình làm việc nhanh và quy trình công việc tiêu chuẩn với Hàm bước. Dưới đây là bảng về cách tính phí sử dụng của từng dịch vụ.

Bạn có thể điều chỉnh dung lượng bộ nhớ mà Lambda được phép sử dụng, do đó, bộ nhớ của bạn consumed GB/sec
có thể thay đổi dựa trên những gì được cấu hình. Với Step Functions, dung lượng bộ nhớ mà nó sử dụng có thể được tính theo công thức sau :
50MB + kích thước định nghĩa máy trạng thái + kích thước dữ liệu thực thi x Số bước song song hoặc bản đồ
Lấy con số được tính ở trên làm tròn đến 64MB gần nhất và chia nó cho thời lượng trung bình của quy trình làm việc để lấy GB / giây tiêu thụ cho quy trình công việc nhanh.
Như bạn có thể thấy, quy trình công việc nhanh được lập hóa đơn tương tự như Lambdas. Nhưng quy trình làm việc tiêu chuẩn hoàn toàn khác. Việc thanh toán của họ chỉ dựa trên số lần chuyển đổi trạng thái.
Để có ý tưởng về cách Lambda so sánh để thể hiện quy trình công việc, chúng ta phải có một thước đo về hiệu suất.
Đánh giá điểm chuẩn của Big Lambdas và Quy trình làm việc nhanh
So sánh đồng bộ
Giải pháp thay thế để xây dựng một quy trình làm việc nhanh là có một Lambda khổng lồ thực hiện các hoạt động tương tự. Ngoài ra, bạn có thể sử dụng các đích đến của Lambda , nhưng chúng không đồng bộ và không áp dụng trực tiếp cho phép so sánh mà chúng tôi đang thực hiện.
Để có điểm chuẩn, tôi sẽ sử dụng quy trình làm việc khóa API từ bài đăng của tôi trên các máy trạng thái nhanh.

Để cung cấp một so sánh toàn diện hơn, tôi sẽ thử nghiệm quy trình làm việc nhanh dựa trên cùng một Lambda được viết trong cả AWS SDK v2 và AWS SDK v3 trong Node.js.
Mỗi chiếc Lambda đã trải qua quá trình điều chỉnh aws -lambda-power của Alex Casalboni được tối ưu hóa cho hiệu suất.
Để kiểm tra, mỗi điểm cuối được chạy 1000 lần. Kết quả được tính trung bình để có thời gian thực hiện trung bình. Khi chúng tôi có được mức trung bình, chúng tôi có thể thực hiện phân tích chi phí của mình.

Như bạn có thể thấy, người chiến thắng của chúng tôi trên toàn diện là quy trình làm việc nhanh với các Chức năng Bước ! Với Lambda, thời gian chậm nhất có thể là do khởi đầu lạnh. Tuy nhiên, bạn không bị tính phí cho thời gian bắt đầu nguội, đó chỉ là thời gian thực thi chức năng của bạn.
Một lợi ích tuyệt vời của việc đi theo tuyến Hàm bước là bạn không phải bắt đầu nguội (trừ khi bạn sử dụng Lambda làm trạng thái). Nếu bạn sử dụng tích hợp SDK trực tiếp , máy trạng thái của bạn sẽ chạy với tốc độ cực nhanh.
Một lần nữa, những chiếc Lambdas này đã được điều chỉnh để có hiệu suất tối ưu, vì vậy chúng được thiết kế để chạy nhanh nhất có thể. Khi so sánh chúng với Step Functions, hiệu suất hầu như không đáng kể.
Phép toán để so sánh chi phí trực tiếp cho quy trình làm việc nhanh trên 1 triệu lần gọi là:
1,00 + (64 bộ nhớ tiêu thụ được làm tròn đến 64MB / 1024MB) x 1 triệu lệnh gọi x thời lượng trung bình 1,8 giây (làm tròn đến 100ms tiếp theo) x 0,00001667 = 2,87 USD
Đối với Lambda, chúng tôi có thể tận dụng thời gian thực thi AWS SDK v3 nhanh hơn và tính toán chi phí lập hóa đơn cho mỗi 1 triệu lần gọi như sau:
.2 + (trung bình bộ nhớ tiêu thụ 88MB / 1024MB) x 1 triệu lệnh gọi x thời lượng trung bình 1,881 giây x 0,00001667 = 2,89 đô la
Tổng hợp các kết quả, chúng tôi có một số con số đáng ngạc nhiên:

Thật kỳ lạ, hàm AWS SDK v2 tiêu thụ bộ nhớ thấp nhất, điều này làm giảm chi phí cho mỗi triệu lần gọi. Dù thế nào đi nữa, chi phí cho mỗi triệu lần thực hiện chỉ chênh lệch vài xu. Rất thú vị!
So sánh không đồng bộ
Nếu bạn quan tâm đến quy trình làm việc tiêu chuẩn, bạn có thể cắt giảm chi phí theo một cách khác. Nếu bạn có một quy trình không đồng bộ đang chạy trong một hàm Lambda, bạn phải đảm bảo quá trình xử lý sẽ được thực hiện trong 15 phút hoặc bạn khởi động các Lambda khác để tiếp tục xử lý (xây dựng hiệu quả máy trạng thái của riêng bạn thông qua các đích).
Các lựa chọn thay thế cho cách tiếp cận này sẽ là cung cấp một phiên bản EC2 và thanh toán chi phí thời gian hoạt động của máy hoặc tạo quy trình làm việc tiêu chuẩn với các Chức năng Bước và trả tiền cho mỗi lần chuyển đổi.
Hãy lấy ví dụ một công việc xử lý hình ảnh chạy một hình ảnh thông qua Textract để lấy bất kỳ văn bản nào và thả kết quả vào S3, sau đó chạy công việc Rekognition để xác định các đối tượng có trong hình ảnh và cuối cùng lưu kết quả tổng hợp vào DynamoDB.
Với Lambda, điều này sẽ khá tốn kém. Giả sử rằng chúng tôi có thể hoàn thành công việc và hoàn tất quá trình xử lý trong khoảng 2 phút. Nếu chúng tôi cung cấp 1024 MB bộ nhớ và trung bình nó sử dụng 256 MB sức mạnh xử lý (đây là những hình ảnh lớn), chúng tôi đang xem xét công thức sau cho mỗi 1 triệu lần gọi :
.20 + (1 triệu x 120 giây) x (256 MB / 1024 MB) x .0000166667 = $ 500
Giả sử máy trạng thái thực hiện cùng một hành động cần 15 trạng thái để hoàn thành. Nó bắt đầu các công việc và thực hiện kiểm tra trạng thái trên một vòng lặp cho đến khi chúng hoàn thành. Công thức để tính chi phí của 1 triệu lần gọi là:
1 triệu x 15 x 0,000025 = $ 375
Trong trường hợp này, sẽ rẻ hơn một chút mỗi tháng nếu chạy khối lượng công việc như một máy trạng thái tiêu chuẩn.
Tổng chi phí sỡ hửu
Khi nói về chi phí thẳng, có vẻ như không đáng kể so với việc chọn Step Functions so với Lambda. Nhưng khi bạn tính tổng chi phí sở hữu , câu chuyện sẽ thay đổi một chút. Như đã thảo luận trong một bài trước về việc tái cấu trúc các ứng dụng không máy chủ , số tiền chi phí theo nghĩa đen chỉ là một yếu tố khi tính toán chi phí cho doanh nghiệp .
Nếu chi phí $ 1000 / tháng để chạy một đoạn mã trên đám mây nhưng nhà phát triển phải mất 20 giờ thời gian để sửa lỗi vì khả năng bảo trì kém, thì chi phí kinh doanh sẽ tăng lên.
Mặt khác, nếu tốn 2000 đô la / tháng để chạy cùng một đoạn mã trên đám mây nhưng nhà phát triển chỉ mất 4 giờ để sửa lỗi vì khả năng bảo trì dễ dàng, thì chi phí tổng thể cho doanh nghiệp sẽ thấp hơn.
Chi phí đắt hơn nhiều so với đô la và xu.
Không có giải pháp "một kích thước phù hợp với tất cả". Những gì hiệu quả với một nhóm có thể không hiệu quả với những nhóm khác. Hãy cân nhắc điều này khi bạn quyết định cách nào để thực hiện cuộc phiêu lưu không máy chủ của mình.
Bằng cách chuyển sang cấu hình trên mô hình mã có Chức năng bước, bạn đặt trách nhiệm thực thi mã lên nhà cung cấp đám mây. Với tư cách là một công ty phần mềm, bạn càng có ít trách nhiệm hơn, thì lợi tức đầu tư mà bạn nhận được càng cao.
Sự kết luận
Đối với trường hợp sử dụng của tôi, Hàm bước phù hợp hơn cho cả thực thi đồng bộ và không đồng bộ.
Điều này không phải lúc nào cũng đúng, vì một số máy trạng thái có thể trở nên lớn và làm tăng chi phí đáng kể so với một số chức năng Lambda được thiết kế tốt.
Tìm sự cân bằng.
Bạn nên dành thời gian ước tính chi phí trước khi đi sâu vào dự án lớn tiếp theo của mình. Bạn có được lợi khi hiển thị các quy trình công việc phức tạp của mình trong một sơ đồ chức năng từng bước không? Hay làm việc theo nhóm của bạn tốt hơn khi đi qua mã?
Step Functions sẽ là một dịch vụ thay đổi trò chơi trong tương lai ( heck, nó đã là như vậy! ). Khi tỷ lệ chấp nhận tăng lên và các tính năng tiếp tục phát triển, nó sẽ tiếp tục ngày càng tốt hơn và để lại "sự phát triển Lambda" truyền thống trong cát bụi.
Bạn nhận được khả năng truy xuất nguồn gốc tốt hơn, trách nhiệm thấp hơn và một nhà thiết kế tuyệt vời thông qua Chức năng bước. Trong một số trường hợp, nó dường như là một dịch vụ chi phí thấp hơn Lambda.
Tôi khuyến khích bạn nên thử nếu bạn chưa có, bạn có thể thích những gì bạn thấy.
Chúc bạn viết mã vui vẻ!