AWS Study Group

Mở rộng quy mô (Scaling) Container Phân tích Dữ liệu bằng Hàm AWS Lambda dựa trên sự kiện

Tác giả: Brian Maguire, Guy Bachar, and Mike Boyar  

Ngày đăng: ngày 30 tháng 8, 2021 |

Danh mục: Amazon API Gateway, Amazon EC2, Amazon Elastic Container Service, Analytics, Architecture, AWS Elastic Beanstalk, Intermediate (200), Manufacturing 

Ngành tiếp thị  thu thập và sử dụng dữ liệu từ nhiều giai đoạn khác nhau trong hành trình của khách hàng. Khi phân tích dữ liệu này, họ xác lập các chỉ số và phát triển các thông tin chi tiết có thể hành động, sau đó được sử dụng để đầu tư vào khách hàng và tạo ra doanh thu.

Nếu bạn là một nhà khoa học dữ liệu hoặc nhà phát triển trong lĩnh vực tiếp thị, bạn có thể thường xuyên sử dụng các containers cho các dịch vụ như thu thập và chuẩn bị dữ liệu, phát triển mô hình machine learning, và thực hiện phân tích thống kê. Do loại và khối lượng dữ liệu tiếp thị ngày càng tăng nhanh, bạn sẽ cần một giải pháp để quản lý khả năng mở rộng, chi phí, và số lượng tích hợp phân tích dữ liệu cần thiết.

Trong bài viết này, chúng tôi cung cấp một giải pháp có thể hoạt động và mở rộng với lưu lượng động và được tối ưu hóa chi phí cho việc tiêu thụ theo nhu cầu. Giải pháp này sử dụng ứng dụng khoa học dữ liệu dựa trên container đồng bộ được triển khai với kiến trúc container bất đồng bộ trên AWS Lambda. Kiến trúc serverless này tự động hóa các quy trình công việc phân tích dữ liệu bằng cách sử dụng các tác nhân kích hoạt (prompts) dựa trên sự kiện.

Ứng dụng container đồng bộ 

Các ứng dụng khoa học dữ liệu thường được triển khai trên các instance container chuyên dụng, và các yêu cầu được định tuyến thông qua Amazon API Gateway hoặc load balancer. Thông thường, Amazon API Gateway định tuyến các yêu cầu HTTP như các lần gọi đồng bộ tới các container host dựa trên instance.

Mục tiêu của các yêu cầu này là một ứng dụng dựa trên container chạy dịch vụ machine learning (SciLearn). Service container được cấu hình với các dependency packages cần thiết như scikit-learn, pandas, NumPy và SciPy.

Các container thường được triển khai trên nhiều mục tiêu (targets) khác nhau như tại chỗ (on-premises), Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Compute Cloud (Amazon EC2) và AWS Elastic Beanstalk. Các dịch vụ này chạy đồng bộ và mở rộng thông qua Amazon Auto Scaling groups với mô hình tính phí dựa trên thời gian sử dụng.

Figure 1. Sơ đồ ứng dụng container đồng bộ

Thách thức với kiến trúc đồng bộ 

Khi sử dụng kiến trúc đồng bộ, bạn có thể gặp một số thách thức liên quan đến khả năng mở rộng, hiệu năng và chi phí:

  • Chặn hoạt động: bên gửi không thể tiếp tục cho đến khi Lambda phản hồi, và việc xử lý lỗi (chẳng hạn như thử lại (retries),) phải được bên gửi thực hiện.
  • Không tích hợp gốc (native) với dịch vụ AWS: không thể sử dụng nhiều tích hợp gốc với các dịch vụ AWS khác như Amazon Simple Storage Service (Amazon S3), Amazon EventBridge và Amazon Simple Queue Service (Amazon SQS).
  • Chi phí tăng: môi trường hoạt động 24/7 có thể làm tăng chi phí nếu tài nguyên nhàn rỗi (idle), không được định cỡ phù hợp và không thể tự động mở rộng.

Bài viết “New for AWS Lambda – Container Image Support” giới thiệu một kiến trúc serverless dựa trên sự kiện (serverless, event-based architecture) để giải quyết các thách thức này.

Lợi ích của việc sử dụng Lambda Container Image Support

Trong giải pháp của chúng tôi, ứng dụng SciLearn đồng bộ được triển khai trên các instance-based host đã được tái cấu trúc thành ứng dụng bất đồng bộ dựa trên sự kiện chạy trên Lambda. Giải pháp này mang lại các lợi ích sau:

  • Dễ dàng quản lý phụ thuộc (dependencies) với Dockerfile: Dockerfile cho phép bạn cài đặt các gói hệ điều hành gốc (native) và các phụ thuộc tương thích với ngôn ngữ hoặc sử dụng các container image cấp doanh nghiệp (enterprise-ready container images).
  • Công cụ tương tự: cả hai giải pháp đồng bộ và bất đồng bộ đều sử dụng Amazon Elastic Container Registry (Amazon ECR) để lưu trữ các tệp tạo tác ứng dụng (application artifacts). Do đó, cả hai đều sử dụng cùng các công cụ đường ống xây dựng và triển khai (build and deployment pipeline) để kiểm tra Dockerfile, giúp nhóm của bạn ít tốn thời gian và công sức học công cụ mới hơn.
  • Hiệu năng và chi phí: Lambda cung cấp khả năng mở rộng tự động dưới một giây (sub-second autoscaling) theo nhu cầu. Điều này dẫn đến tính khả dụng (availability) cao hơn, giảm chi phí vận hành và tối ưu chi phí.
  • Tích hợp: AWS cung cấp hơn 200 tích hợp dịch vụ (service integrations) để triển khai các hàm (functions) dưới dạng container image trên Lambda mà không cần tự phát triển, giúp triển khai nhanh hơn.
  • Hỗ trợ artifact lớn hơn đến 10 GB: Điều này hỗ trợ nhiều dependency ứng dụng hơn, cho phép bạn lưu trữ nhiều file và gói hơn so với giới hạn 250 MB của deployment packages dạng .zip.

Mở rộng với sự kiện bất đồng bộ 

AWS cung cấp hai cách để mở rộng xử lý bất đồng bộ độc lập và tự động: Elastic Beanstalk worker environments và lời gọi bất đồng bộ (asynchronous invocation) với Lambda.  Cả hai tùy chọn đều cung cấp các tính năng sau:

  • Chúng đưa các sự kiện vào SQS queue
  • Chúng có thể được thiết kế để chỉ lấy các item từ queue khi có đủ sức chứa để xử lý tác vụ. Điều này giúp ngăn chúng bị quá tải.
  • Chúng giảm tải (offload) các tác vụ khỏi một thành phần của ứng dụng sang queue và xử lý chúng một cách bất đồng bộ.

Các lời gọi bất đồng bộ (asynchronous invocations) này bổ sung các cơ chế xử lý lỗi mặc định, có thể tùy chỉnh và thử lại (retry mechanisms) thông qua các điểm đến sự kiện (event destinations) “on failure” và “on success”, như được mô tả trong phần tiếp theo.

Tích hợp với nhiều điểm đến

Các sự kiện “on failure” và “on success” có thể được ghi vào SQS queue, Amazon Simple Notification Service (Amazon SNS) topic, EventBridge event bus hoặc một Lambda function khác. Cả bốn đều được tích hợp với hầu hết các AWS services.

Các sự kiện “on failure” được gửi đến một hàng đợi SQS dead-letter (SQS dead-letter queue) vì chúng không thể được chuyển đến các hàng đợi đích (destination queues). Chúng sẽ được xử lý lại khi cần thiết, và bất kỳ vấn đề nào trong quá trình xử lý message sẽ được cô lập.

Hình 2 mô tả một Amazon API Gateway bất đồng bộ đặt một HTTP request dưới dạng một message vào SQS queue, qua đó tách rời (decoupling) các thành phần (components).

Các message trong SQS queue sau đó kích hoạt một Lambda function. Function này chạy machine learning service SciLearn container trong Lambda cho các data analysis workflows, đồng thời được tích hợp với một SQS dead-letter queue khác để xử lý lỗi.

Hình 2. Sơ đồ ví dụ các ứng dụng container dựa trên bất đồng bộ

Khi bạn triển khai Lambda functions dưới dạng container images, chúng được hưởng lợi từ cùng sự đơn giản trong vận hành, mở rộng tự động, tính sẵn sàng cao và tích hợp gốc. Điều này làm cho kiến trúc này trở nên hấp dẫn cho các trường hợp sử dụng phân tích dữ liệu của chúng tôi.

Các cân nhắc khi thiết kế

Khi triển khai Docker Container Images với Lambda, cần xem xét:

  • Lambda hỗ trợ các container image có tệp kê khai (manifest files) theo các định dạng sau:
    • Docker image manifest V2, schema 2 (Docker version 1.10 trở lên)
    • Open Container Initiative (OCI) specifications (v1.0.0 trở lên)
  • Lưu trữ trong Lambda:
  • Khi tạo/cập nhật, Lambda sẽ cache image (lưu bộ đệm image) để tăng tốc độ khởi động lạnh (cold start) của các hàm trong quá trình thực thi. Khởi động lạnh xảy ra khi có yêu cầu ban đầu (initial request) gửi đến Lambda, điều này có thể dẫn đến thời gian khởi động lâu hơn. Yêu cầu đầu tiên sẽ duy trì một instance của hàm chỉ trong một khoảng thời gian ngắn. Nếu Lambda không được gọi trong khoảng thời gian đó, lần gọi tiếp theo sẽ tạo một instance mới.
  • Các chính sách vai trò được phân quyền chi tiết (Fine-grained role policies) được khuyến nghị mạnh mẽ vì mục đích bảo mật.
  • Container images có thể dùng Lambda Extensions API để tích hợp monitoring, security và các công cụ khác với môi trường thực thi Lambda (Lambda execution environment).

Kết luận

Chúng tôi đã có thể thiết kế kiến trúc (architect) lại dịch vụ đồng bộ (synchronous) này (vốn trước đây được triển khai trên các host dựa trên instance (instance-based hosts)) và thiết kế (design) nó để trở thành dịch vụ bất đồng bộ (asynchronous) trên Amazon Lambda.

Bằng cách sử dụng tính năng hỗ trợ container-based images mới trong Lambda và chuyển đổi workload sang kiến trúc bất đồng bộ dựa trên sự kiện, chúng tôi đã giải quyết được các thách thức sau:

  • Hiệu năng và bảo mật: Với các batch request, bạn có thể mở rộng workload bất đồng bộ (asynchronous workloads) và xử lý các bản ghi lỗi (failure records) bằng cách sử dụng SQS Dead Letter Queues và Lambda destinations. Việc sử dụng Lambda để tích hợp với các dịch vụ khác (như EventBridge và SQS) và sử dụng Lambda roles giúp đơn giản hóa việc duy trì cấu trúc phân quyền chi tiết (granular). Khi Lambda sử dụng một Amazon SQS queue làm nguồn sự kiện (event source), nó có thể mở rộng quy mô lên đến 60 instance mới mỗi phút, với tối đa 1.000 lời gọi đồng thời (concurrent invocations).
  • Tối ưu chi phí: Tài nguyên tính toán là thành phần quan trọng trong bất kỳ kiến trúc ứng dụng nào. Việc cung cấp thừa (overprovisioning) tài nguyên tính toán và vận hành các tài nguyên nhàn rỗi (idle) có thể dẫn đến chi phí cao hơn. Vì Lambda là serverless, chi phí chỉ phát sinh khi bạn gọi một hàm (function) và dựa trên các tài nguyên được phân bổ (allocated) cho mỗi yêu cầu.

Về tác giả

Brian Maguire

Brian Maguire là Principal Solutions Architect tại Amazon Web Services, nơi anh tập trung giúp khách hàng xây dựng ý tưởng của họ trên đám mây. Anh là một technologist, writer, teacher và student yêu thích việc học hỏi. Brian là đồng tác giả của cuốn sách Scalable Data Streaming with Amazon Kinesis.

Guy Bachar

Guy là Senior Solutions Architect tại AWS. Anh chuyên hỗ trợ người dùng trong Capital Markets và FinTech với các hành trình chuyển đổi lên cloud. Chuyên môn của anh bao gồm quản lý Danh tính (Identity), bảo mật (security) và truyền thông hợp nhất (unified communication).

Mike Boyar

Mike Boyar là Solutions Architect tại AWS. Trong thời gian rảnh, anh thích nướng bánh mì kiểu French country.

←
→

Leave a comment