của James Beswick | ngày 06 tháng 11 năm 2023 | trong Amazon Simple Queue Service (SQS), AWS Lambda, Serverless | Permalink |  Share

Bài viết này được viết bởi Anton Aleksandrov, Principal Solutions Architect, và Tarun Rai Madan, Senior Product Manager.

Hôm nay, AWS thông báo rằng AWS Lambda hỗ trợ polling scale-up nhanh hơn gấp 5 lần cho khối lượng công việc Lambda tăng đột biến được cấu hình với Amazon Simple Queue Service (Amazon SQS) làm event source.

Tính năng này cho phép khách hàng xây dựng ứng dụng hướng sự kiện sử dụng Lambda và SQS để đạt được khả năng mở rộng nhanh hơn khi có lượng message tăng đột ngột trong hàng đợi SQS, và cắt giảm được những hàm Lambda hoặc hàng đợi SQS bị lặp để xử lý message nhanh hơn.

Tổng quát

Khách hàng xây dựng những ứng dụng tin nhắn và hướng sự kiện hiện đại với AWS Lambda sử dụng Amazon SQS như một khối kiến trúc cơ bản để tạo ra các kiến trúc tách rời. Amazon SQS là một dịch vụ hàng đợi tin nhắn được quản lý hoàn toàn cho microservices, distributed system và ứng dụng serverless. Khi một hàm Lambda được đăng ký vào hàng đợi SQS làm event source, Lambda sẽ kiểm tra hàng đợi, lấy tin nhắn và gửi hàng loạt tin nhắn đến hàm xử lý. Để xử lý message một cách hiệu quả, Lambda phát sự sự gia tăng chiều dài hàng đợi, và tăng số lượng số lượng quá trình kiểm tra hàng đợi để xử lý các message được xếp hàng đợi.

Cho đến hôm nay, Lambda đã bổ sung đến 60 luồng xử lý đồng thời trên phút cho hàm Lambda đăng ký trong hàng đợi SQS, khả năng mở rộng tối đa lên đến 1,250 luồng xử lý đồng thời trong khoảng 20 phút. Tuy nhiên, khách hàng cho chúng tôi biết rằng một số ứng dụng hướng sự kiện hiện đại mà họ xây dựng bằng Lambda và SQS rất nhạy cảm với mức tăng đột biến của message, điều này có thể gây ra việc xử lý message chậm trễ cho người dùng cuối. Để khai thác sức mạnh của Lambda cho các ứng dụng gặp phải tình trạng hàng loạt message trong hàng đợi SQS, những khách hàng này cần kiểm tra message trong Lambda để mở rộng nhanh hơn. 

Với thông báo ngày hôm nay, Lambda functions đăng ký vào trong hàng đợi SQS có thể mở rộng nhanh hơn đến 5 lần đối với các hàng đợi mà có lượng tin nhắn tồn đọng tăng đột biến, mở rộng đến 300 xử lý đồng thời trên phút, và mở rộng tối đa đến 1,250 lượng xử lý đồng thời. Việc cải thiện khả năng mở rộng này giúp tận dụng tính đơn giản của tích hợp Lambda và SQS để xây dựng các ứng dụng hướng sự kiện có quy mô nhanh hơn khi có nhiều tin nhắn đến, đặc biệt là đối với các hệ thống thời gian thực. Nó cũng đem đến cho khách hàng nhiều lợi ích từ việc xử lý nhanh nhiều tin nhắn trong hàng đợi SQS, đồng thời vẫn tiếp tục đem đến sự linh hoạt để hạn chế số lượng tối đa số lượng gọi các hàm Lambda đồng thời trên mỗi SQS event source.

Kiểm soát số lệnh gọi Lambda đồng thời tối đa bằng SQS

Khả năng mở rộng cải tiến mới sẽ tự động áp dụng với toàn bộ tài khoản AWS sử dụng Lambda và SQS làm một event source. Không có hành động nào mà bạn cần thực hiện, và không có bất kỳ chi phí nào được thêm vào. Việc cải thiện khả năng mở rộng này giúp khách hàng xây dựng ứng dụng Lambda với hiệu suất cao hơn khi họ cần mở khả năng polling của SQS. Để ngăn chặn việc quá tải hoặc downstream những phụ thuộc, Lambda cung cấp cho người dùng khả năng kiểm soát số lượng tối đa các xử lý đồng thời tại function level với reserved concurrency, và event source level với maximum concurrency.

Sơ đồ sau đây minh họa các cài đặt mà bạn có thể sử dụng để kiểm soát tốc độ luồng của SQS event-source. Bạn sử dụng reserved concurrency để kiểm soát khả năng mở rộng ở function-level, và maximum concurrency để kiểm soát mở rộng event source. 

Reserved concurrency là lượng xử lý đồng thời tối đa mà bạn muốn cấp cho một function. Khi một function được cấp reserved concurrency, thì không có hàm nào khác có thể sử dụng xử lý đồng thời này.

AWS khuyến nghị sử dụng reserved concurrency khi bạn muốn đảm bảo một function có đủ hàm xử lý đồng thời để mở rộng. Khi một SQS event source cố gắng để mở rộng số lượng gọi hàm Lambda đồng thời, nhưng function đã đạt tới ngưỡng của reserved concurrency, dịch vụ Lambda sẽ bị nghén cổ chai bởi những lệnh gọi tiếp theo.

Điều này có thể dẫn đến SQS event source cố gắng giảm xuống, cắt giảm lượng xử lý message đồng thời. Phụ thuộc vào cấu hình của hàng đợi, các tin nhắn bị hiệu ứng nghén cổ chai sẽ được trả về hàng đợi và thử lại, hết hạn dựa trên những chính sách lưu trữ hoặc gửi đến dead-letter queue (DLQ) hoặc on-failure destination.

Cài đặt maximum concurrency cho phép bạn kiểm soát lượng thực thi đồng thời tại event source level. Nó cho phép bạn định nghĩa số lượng lệnh gọi tối đa đồng thời mà event source cố gắng gửi tới Lambda function. Đối với các trường hợp trong đó một function có nhiều cấu hình SQS event sources, bạn có thể định nghĩa maximum concurrency cho mỗi event source riêng biệt, cung cấp khả năng kiểm soát chi tiết hơn. Khi cố gắng thêm tốc độ kiểm soát với SQS event sources, AWS khuyến nghị bạn bắt đầu đánh giá maximum concurrency trước tiên, vì nó cung cấp sự linh hoạt tốt hơn.

Reserved concurrency và maximum concurrency là khả năng bổ sung và có thể sử dụng cùng nhau. Maximum concurrency có thể giúp ngăn chặn quá tải downstream hệ thống và các lệnh gọi bị nghén cổ chai. Reserved concurrency giúp đảm bảo sự sẵn các thực thi đồng thời cho function.

Kích bản ví dụ

Hãy xem xét doanh nghiệp của bạn phải xử lý khối lượng lớn tài liệu từ bộ lưu trữ. Cứ sau vài giờ, các đối tác kinh doanh của bạn tải khối lượng lớn tài liệu lên bộ chứa S3 trong tài khoản của bạn.

Để có khả năng phục hồi tốt, bạn phải thiết kế ứng dụng của mình gửi message đến một hàng đợi SQS cho mỗi lần tải tài liệu lên, nhờ đó, bạn có thể xử lý chúng một cách hiệu quả mà không vô tình bỏ qua bất kỳ tài liệu nào. Các tài liệu được xử lý bằng Lambda function, mất khoảng hai giây để xử lý một tài liệu. 

Xử lý những tài liệu này là hoạt động mất nhiều CPU, vì vậy bạn quyết định xử lý mỗi tài liệu trên mỗi lần gọi. Bạn muốn sử dụng sức mạnh của Lambda để triển khai những xử lý song song trên nhiều môi trường thực thi đồng thời nhất có thể. Bạn muốn dùng Lambda function để mở rộng nhanh chóng để xử lý song song các tài liệu đó nhanh nhất có thể và giảm quy mô xuống 0 sau khi tất cả tài liệu được xử lý để tiết kiệm chi phí.

Khi một doanh nghiệp đối tác tải lên 200,000 tài liệu, 200,000 messages được gửi đến hàng đợi SQS. Lambda function được cấu hình với một SQS event source và nó bắt đầu xử lý message từ hàng đợi.

Sơ đồ này hiển thị kết quả chạy kịch bản thử nghiệm trước khi cải thiện quy mô nguồn sự kiện SQS. Như mong đợi, bạn có thể thấy rằng lượng thực thi đồng thời tăng thêm mỗi 60 phút. Nó mất khoảng 16 phút để mở rộng đến 900 lượng thực thi đồng thời và dần dần xử lý toàn bộ messages trong hàng đợi.

Sơ đồ sau đây cho thấy kết quả của việc chạy cùng một kịch bản thử nghiệm sau khi cải thiện khả năng mở rộng của SQS event source. Khung thời gian được sử dụng cho cả hai biểu đồ là giống nhau, nhưng hiệu năng trên biểu đồ 2 lại tốt hơn. Lượng thực thi đồng thời tăng thêm 300 mỗi phút. Nó chỉ mất 4 phút để mở rộng đến 1,250 lượng thực thi đồng thời, và tất cả messages trong hàng đợi được xử lý trong khoảng 8 phút.

Triển khai ví dụ này

Sử dụng example project để sao chép kiểm tra hiệu suất này trong tài khoản AWS của bạn. Làm theo hướng dẫn trong README.md file để cung cấp dự án mẫu trong tài khoản AWS của bạn bằng Bộ công cụ AWS Cloud Development Kit (CDK).

Dự án ví dụ này được cấu hình để cho thấy việc mở rộng xử lý message với quy mô lớn . Chạy dự án ví dụ này trong tài khoản của bạn có thể sẽ phải trả phí. Xem ở AWS Lambda pricing và Amazon SQS pricing.

Một khi đã triển khai, sử dụng ứng dụng trong thư mục “sqs-cannon” để gửi 200.000 tin nhắn đến hàng đợi SQS (hoặc cấu hình lại thành bất kỳ số nào khác). Nó mất một vài phút để thêm tin nhắn vào hàng đợi. Sau khi tất cả tin nhắn đã được gửi đi, bật SQS event source, như được mô tả trong README.md và theo dõi các biểu đồ trong Cloudwatch dashboard được cung cấp.

Giới hạn xử lý đồng thời mặc định cho tài khoản AWS mới là 1000. Nếu bạn yêu cầu tăng giới hạn này lên, số lượng xử lý đồng thời được giới hạn ở con số này. Dùng Service Quotas hoặc liên hệ với nhóm tài khoản của bạn để yêu cầu tăng lượng sử lý đồng thời. 

Các biện pháp bảo vệ tốt nhất

Luôn sử dụng least privileged permissions khi cấp quyền cho Lambda function của bạn truy cập vào hàng đợi SQS. Điều này làm cắt giảm những nguy cơ tấn công tiềm ẩn bằng cách đảm bảo rằng những function nhất định chỉ có quyền thực hiện những hành động nhất định trên những hàng đợi nhất định. Ví dụ, trong trường hợp function của bạn chỉ kiểm tra từ hàng đợi, chỉ cấp cho nó quyền đọc message, mà không phải là gửi message. Một function execution role định nghĩa những hành động mà function của bạn được phép thực hiện trên những tài nguyên khác. Một queue access policy định nghĩa những principal được phép truy cập vào hàng đợi này và được thực hiện những hành động được phép.

Sử dụng server-side encryption (SSE) để lưu dữ những dữ liệu nhạy cảm được mã hóa trong hàng đợi SQS. Với SSE, message của bạn luôn được lưu trữ dưới dạng mã hóa, và chỉ có SQS giải mã chúng để gửi đến cho những consumer đã được xác thực. SSE bảo vệ nội dung của message trong hàng đợi sử dụng SQS-managed encryption keys (SSE-SQS) hoặc keys managed trong AWS Key Management Service (SSE-KMS).

Kết luận

Khả năng mở rộng Lambda SQS event source polling được cải tiến cho phép hiệu suất mở rộng nhanh hơn tới 5 lần đối với khối lượng công việc theo sự kiện tăng đột biến bằng cách sử dụng hàng đợi SQS mà không mất thêm phí. Cải tiến này mang lại cho khách hàng lợi ích của việc xử lý nhanh hơn khi có nhiều tin nhắn trong hàng đợi SQS, đồng thời tiếp tục cung cấp tính linh hoạt để hạn chế số lần gọi đồng thời tối đa của SQS dưới dạng event source. 

Link bài viết