Nhiều nhà cung cấp phần mềm dưới dạng dịch vụ (SaaS) trong nhiều ngành đang bổ sung khả năng học máy (ML) và trí tuệ nhân tạo (AI) vào các sản phẩm SaaS của họ để giải quyết các trường hợp sử dụng như đề xuất sản phẩm được cá nhân hóa, phát hiện gian lận và dự báo nhu cầu chính xác. Một số nhà cung cấp SaaS muốn xây dựng các khả năng ML và AI như vậy và triển khai chúng trong một môi trường đa khách hàng. Tuy nhiên, những nhà cung cấp khác có khách hàng nâng cao hơn muốn cho phép khách hàng của họ tự xây dựng các mô hình ML và sử dụng chúng để bổ sung SaaS với các khả năng bổ sung hoặc ghi đè lên việc thực hiện mặc định của một số chức năng cụ thể.

Trong bài đăng này, chúng tôi sẽ thảo luận về cách nâng cao sản phẩm SaaS của bạn với một bộ công cụ khoa học dữ liệu được cung cấp bởi Amazon SageMaker Studio.

Hãy giả sử một nhà cung cấp phần mềm độc lập (ISV) có tên XYZ có một sản phẩm SaaS CRM hàng đầu được hàng triệu khách hàng sử dụng để phân tích hành vi mua hàng của khách hàng. Một nhà tiếp thị từ công ty FOO (một khách hàng của XYZ) muốn tìm kiếm những người mua có xu hướng chuyển nhượng để họ có thể tối ưu hóa ROI của các chương trình giữ chân khách hàng bằng cách nhắm mục tiêu những người mua đó. Trước đây, họ đã sử dụng phân tích thống kê đơn giản trong CRM để đánh giá các khách hàng như vậy. Bây giờ, họ muốn cải thiện ROI hơn nữa bằng cách sử dụng các kỹ thuật ML. XYZ có thể cải thiện CRM của họ cho khách hàng bằng cách sử dụng giải pháp được giải thích trong bài đăng này và cho phép nhóm khoa học dữ liệu của FOO tự xây dựng các mô hình trên cơ sở dữ liệu của họ.

Khách hàng SaaS quan tâm đến trường hợp sử dụng này muốn có truy cập vào một bộ công cụ khoa học dữ liệu là một phần của SaaS, thông qua đó họ có thể truy cập dữ liệu của mình nằm trong SaaS một cách dễ dàng, phân tích nó, trích xuất xu hướng và xây dựng, đào tạo và triển khai các mô hình ML tùy chỉnh. Họ muốn tích hợp an toàn giữa bộ công cụ khoa học dữ liệu và SaaS, truy cập vào một tập hợp đầy đủ và rộng lớn các khả năng khoa học dữ liệu và ML, và khả năng nhập các tập dữ liệu bổ sung và kết hợp nó với dữ liệu được trích xuất từ SaaS để rút ra các thông tin hữu ích.

Sơ đồ sau minh họa kiến trúc hiện tại của sản phẩm SaaS CRM của XYZ.

Kiến trúc này bao gồm các yếu tố sau:

• Front-end layer – Lớp này được lưu trữ trên Amazon Simple Storage Service (Amazon S3).  Amazon CloudFront được sử dụng làm mạng phân phối nội dung toàn cầu và Amazon Cognito được sử dụng để xác thực và ủy quyền người dùng. Lớp này bao gồm ba ứng dụng web:
  • Landing và đăng ký – Trang giao diện công khai mà khách hàng có thể tìm và sử dụng để đăng ký giải pháp CRM. Đăng ký sẽ kích hoạt quá trình đăng ký, bao gồm việc tạotenant mới trong hệ thống cho khách hàng.
  • Ứng dụng CRM – Được khách hàng sử dụng để quản lý cơ hội, quản lý khách hàng của chính họ và hơn thế nữa. Nó dựa vào Amazon Cognito để xác thực và ủy quyền cho người dùng.
  • Quản trị viên CRM – Được nhà cung cấp SaaS sử dụng để quản lý và định cấu hình tenant.

• Backend layer – Lớp này được triển khai dưới dạng hai bộ vi dịch vụ chạy trên  Amazon Elastic Kubernetes Service (Amazon EKS):
  • Dịch vụ SaaS – Bao gồm các dịch vụ đăng ký, quản lý tenant và quản lý người dùng. Việc triển khai đầy đủ hơn sẽ bao gồm các dịch vụ bổ sung để thanh toán và đo lường.
  • Dịch vụ ứng dụng – Bao gồm dịch vụ quản lý khách hàng, quản lý cơ hội và danh mục sản phẩm. Tập hợp này có thể chứa các dịch vụ bổ sung dựa trên các chức năng kinh doanh được cung cấp bởi giải pháp CRM.

Các phần tiếp theo của bài đăng sẽ thảo luận về cách xây dựng phiên bản mới của giải pháp CRM SaaS với một bộ công cụ khoa học dữ liệu được nhúng.

Tổng quan về giải pháp

Chúng tôi sử dụng Amazon SageMaker để đáp ứng các yêu cầu của giải pháp của chúng tôi. SageMaker là dịch vụ toàn diện nhất cho ML từ đầu đến cuối. Đây là một dịch vụ quản lý dành cho các nhà khoa học dữ liệu và nhà phát triển giúp loại bỏ những tác vụ nặng nhọc không khác biệt liên quan đến ML, giúp bạn có thêm thời gian, tài nguyên và năng lượng để tập trung vào kinh doanh của mình.

Các tính năng của SageMaker bao gồm SageMaker Studio – môi trường phát triển tích hợp đầy đủ (IDE) đầu tiên cho ML. Nó cung cấp một giao diện trực quan dựa trên web duy nhất, nơi bạn có thể thực hiện tất cả các bước phát triển ML cần thiết để xây dựng, đào tạo, điều chỉnh, gỡ lỗi, triển khai và giám sát các mô hình. Nó cung cấp cho các nhà khoa học dữ liệu tất cả các công cụ cần thiết để chuyển đổi các mô hình ML từ thử nghiệm sang sản xuất mà không cần rời khỏi IDE.

SageMaker Studio được nhúng trong SaaS làm bộ công cụ khoa học dữ liệu – bạn có thể khởi chạy nó bằng cách chọn một liên kết bên trong SaaS và truy cập vào các tính năng khác nhau của SageMaker. Bạn có thể sử dụng SageMaker Studio để xử lý và phân tích dữ liệu của riêng bạn được lưu trữ trong SaaS và trích xuất thông tin. Bạn cũng có thể sử dụng API SageMaker để xây dựng và triển khai một mô hình ML, sau đó tích hợp các quy trình và luồng công việc SaaS với mô hình ML được triển khai để xử lý dữ liệu chính xác hơn.

Bài đăng này đề cập đến một số yếu tố cần thiết cho một giải pháp:

• Phương pháp đa khách hàng và thiết lập tài khoản – Làm cách nào để cô lập các khách hàng. Phần này cũng thảo luận về một cấu trúc tài khoản đề xuất.
• Cung cấp và tự động hóa – Làm cách nào để tự động hóa việc cung cấp bộ công cụ khoa học dữ liệu.
• Tích hợp và quản lý danh tính – Sự tích hợp giữa SaaS và SageMaker Studio và tích hợp với nhà cung cấp danh tính (IdP).
• Quản lý dữ liệu – Trích xuất dữ liệu và làm cách nào để có sẵn cho bộ công cụ khoa học dữ liệu.
  
  Chúng tôi thảo luận về những khái niệm này trong bối cảnh giải pháp CRM SaaS được giải thích ở đầu bài đăng. Biểu đồ sau cung cấp một cái nhìn tổng quan về kiến trúc giải pháp.

Như hình vẽ trước đó đã miêu tả, sự thay đổi chính trong kiến ​​trúc là sự giới thiệu các thành phần sau:

• Dịch vụ quản lý dữ liệu – Chịu trách nhiệm trích xuất dữ liệu của khách hàng SaaS từ kho dữ liệu SaaS và đẩy nó đến bộ phận làm việc khoa học dữ liệu.
• Dịch vụ quản lý bộ phận làm việc khoa học dữ liệu – Chịu trách nhiệm cung cấp bộ phận làm việc khoa học dữ liệu cho khách hàng SaaS và khởi chạy nó trong SaaS.
• Bộ phận làm việc khoa học dữ liệu – Dựa trên SageMaker Studio, và chạy trong một tài khoản AWS riêng biệt. Nó cũng bao gồm một S3 bucket để lưu trữ dữ liệu được trích xuất từ kho dữ liệu SaaS.

Các lợi ích của giải pháp này bao gồm:

• Khách hàng SaaS có thể thực hiện nhiều tác vụ khoa học dữ liệu và ML khác nhau bằng cách khởi chạy SageMaker Studio từ SaaS trong một tab riêng biệt và sử dụng đó như là bộ phận làm việc khoa học dữ liệu, mà không cần phải xác thực lại. Họ không cần phải xây dựng và quản lý một nền tảng khoa học dữ liệu riêng biệt.
• Khách hàng SaaS có thể dễ dàng trích xuất dữ liệu đang tồn tại trong kho dữ liệu SaaS và làm cho nó có sẵn cho bộ phận làm việc khoa học dữ liệu nhúng mà không cần kỹ năng kỹ thuật dữ liệu. Ngoài ra, nó cũng dễ dàng để tích hợp mô hình ML mà họ đã xây dựng với SaaS.
• Khách hàng SaaS có thể truy cập vào bộ sưu tập ML rộng nhất và hoàn chỉnh nhất được cung cấp bởi SageMaker.

Multi-tenancy approach and account setup

Phần này sẽ đề cập đến cách cấp phát SageMaker Studio cho các khách hàng đa-tenant hoặc SaaS khác nhau (khái niệm tenant và khách hàng SaaS được sử dụng thay thế vì chúng liên quan chặt chẽ với nhau – mỗi khách hàng SaaS đều có một tenant). Hình vẽ dưới đây mô tả một hệ thống đa tài khoản hỗ trợ cấp phát một môi trường SageMaker được bảo mật và cô lập cho mỗi tenant. Cấu trúc đề xuất này tuân theo các best practice của AWS cho hệ thống đa tài khoản. Để biết thêm thông tin, vui lòng tham khảo bài viết Organizing Your AWS Environment Using Multiple Accounts.

Chúng tôi sử dụng AWS Control Tower để triển khai hệ thống đa tài khoản đề xuất. AWS Control Tower cung cấp một khung để thiết lập và mở rộng một môi trường AWS đa tài khoản được thiết kế tốt, dựa trên các best practice về bảo mật và tuân thủ quy định. AWS Control Tower sử dụng nhiều dịch vụ AWS khác, bao gồm AWS Organizations, AWS Service Catalog và AWS CloudFormation, để xây dựng cấu trúc tài khoản và áp dụng guardrails (rào cản bảo mật). Guardrails có thể là các chính sách điều khiển dịch vụ AWS Organizations hoặc các quy tắc AWS Config. Account Factory, một tính năng của AWS Control Tower cho phép tiêu chuẩn hóa việc cấp phát tài khoản mới với các baseline phù hợp cho việc trung tâm hóa logging và kiểm toán, được sử dụng để tự động cấp phát tài khoản mới cho môi trường SageMaker của khách hàng như một phần của quá trình onboarding. Vui lòng tham khảo bài viết AWS Control Tower – Set up & Govern a Multi-Account AWS Environment để biết thêm chi tiết về AWS Control Tower và cách nó sử dụng các dịch vụ AWS khác để thiết lập và quản lý một hệ thống đa tài khoản.

Tất cả các tài khoản chứa môi trường SageMaker của khách hàng đều thuộc một đơn vị tổ chức (OU) chung để cho phép áp dụng các guardrails và tự động hóa chung, bao gồm cấu hình baseline tạo một SageMaker Studio domain, S3 bucket chứa các tập dữ liệu được trích xuất từ kho lưu trữ dữ liệu SaaS, các vai trò AWS Identity and Access Management (IAM) chéo tài khoản cho phép truy cập các thành phần SageMaker từ bên trong SaaS và nhiều hơn nữa.

Cô lập tenant

Trong ngữ cảnh của SaaS, bạn có thể xem xét các chiến lược cô lập tenant khác nhau như sau:

• Mô hình Silo – Mỗi tenant chạy một ngăn xếp tài nguyên Silo hoàn toàn độc lập
• Mô hình Pool – Cùng một cơ sở hạ tầng và tài nguyên được chia sẻ trên các tenant
• Mô hình Bridge – Một giải pháp liên quan đến sự kết hợp của các mô hình Silo và Pool. Vui lòng tham khảo whitepaper SaaS Tenant Isolation Strategies để biết thêm chi tiết về các chiến lược cô lập tenant cho SaaS.

Mô hình Silo được sử dụng cho SageMaker – một domain SageMaker Studio riêng hoặc độc lập được cấp phát cho mỗi khách hàng trong một tài khoản riêng như một phiên bản của data science workbench. Mô hình Silo đơn giản hóa thiết lập bảo mật và cô lập. Nó cũng cung cấp các lợi ích khác như đơn giản hóa việc tính toán chi phí liên quan đến việc tiêu thụ các khả năng SageMaker khác nhau của tenant.

Trong khi chiến lược cô lập Silo được sử dụng cho môi trường SageMaker, mô hình Pool được sử dụng cho các thành phần khác (như dịch vụ quản lý data science workbench). Thiết lập cô lập trong mô hình Silo, trong đó mỗi tenant hoạt động trên cơ sở hạ tầng của riêng mình (một tài khoản AWS trong trường hợp này), đơn giản hơn so với mô hình Pool, trong đó cơ sở hạ tầng được chia sẻ. Whitepaper được tham khảo trước đó cung cấp hướng dẫn về cách thiết lập cô lập với mô hình Pool. Trong bài đăng này, chúng tôi sử dụng phương pháp sau:

• Người dùng được chuyển hướng đến IdP (Amazon Cognito trong trường hợp này) để xác thực. Người dùng nhập tên người dùng và mật khẩu của họ, và sau khi xác thực thành công, IdP trả về một mã thông báo chứa thông tin người dùng và định danh tenant. Bên phía trước bao gồm token đã trả về trong các yêu cầu HTTP tiếp theo được gửi bởi bên phía trước đến các microservices.
• Khi microservice nhận được yêu cầu, nó trích xuất định danh tenant từ token được bao gồm trong yêu cầu HTTP và giả định một IAM role tương ứng với tenant. Các quyền IAM role giả định được giới hạn cho các tài nguyên cụ thể của tenant. Do đó, ngay cả khi nhà phát triển của microservice mắc lỗi trong mã và cố gắng truy cập các tài nguyên thuộc về tenant khác, IAM role giả định không cho phép hành động đó tiếp diễn.
• IAM role tương ứng với tenant được tạo ra như một phần của đăng ký và onboarding của tenant.
• Các phương pháp khác để thiết lập cô lập với mô hình Pool bao gồm tạo động các chính sách và vai trò được giả định bởi microservice tại thời điểm chạy. Để biết thêm thông tin, vui lòng tham khảo whitepaper SaaS Tenant Isolation Strategies. Một phương pháp khác là sử dụng các chính sách ABAC IAM – để biết thêm thông tin, vui lòng tham khảo bài viết How to implement SaaS tenant isolation with ABAC and AWS IAM.

Cung cấp và tự động hóa

Như đã đề cập trước đó, chúng tôi sử dụng AWS Organizations, AWS Service Catalog và AWS CloudFormation StackSets để triển khai thiết lập đa tài khoản cần thiết. Một khía cạnh quan trọng của việc này là tạo một tài khoản AWS mới cho mỗi khách hàng để chứa môi trường SageMaker và cách để tự động hóa hoàn toàn quá trình này.

StackSet để cung cấp SageMaker trong tài khoản của khách hàng được tạo trên tài khoản quản lý – mục tiêu cho StackSet là ML OU. Khi một tài khoản mới được tạo trong ML OU, một stack dựa trên mẫu liên quan đến StackSet được xác định trong tài khoản quản lý sẽ được tự động tạo ra trong tài khoản mới.

Việc cung cấp môi trường SageMaker cho một khách hàng là một quá trình đa bước mất vài phút để hoàn thành. Do đó, một bảng Amazon DynamoDB được tạo ra để lưu trữ trạng thái của việc cung cấp môi trường SageMaker.

Sơ đồ dưới đây mô tả quy trình cung cấp trạm làm việc khoa học dữ liệu.

Dịch vụ quản lý trạm làm việc khoa học dữ liệu là một microservice được phối hợp các hoạt động khác nhau để cung cấp trạm làm việc khoa học dữ liệu cho khách hàng SaaS. Nó gọi API ProvisionProduct của AWS Service Catalog để khởi tạo việc tạo tài khoản AWS.

Như đã đề cập trước đó, StackSet được gắn liền với ML OU kích hoạt việc tạo domain SageMaker Studio và các tài nguyên khác trong tài khoản khách hàng ngay khi tài khoản được tạo ra dưới ML OU như là kết quả của việc gọi API ProvisionProduct của AWS Service Catalog. Một cách khác để đạt được điều đó là sử dụng AWS Service Catalog – bạn có thể tạo một sản phẩm để cung cấp môi trường SageMaker Studio và thêm nó vào một danh mục. Sau đó, danh mục được chia sẻ với tất cả các tài khoản AWS trong ML OU. Dịch vụ quản lý trạm làm việc khoa học dữ liệu phải gọi rõ ràng đến API của AWS Service Catalog sau khi hoàn thành việc tạo tài khoản AWS để kích hoạt việc tạo môi trường SageMaker Studio. AWS Service Catalog rất hữu ích nếu bạn cần hỗ trợ nhiều biến thể trạm làm việc khoa học dữ liệu – người dùng lựa chọn từ danh sách các biến thể, và dịch vụ quản lý trạm làm việc khoa học dữ liệu ánh xạ lựa chọn của người dùng vào một sản phẩm được xác định trong AWS Service Catalog. Sau đó, nó kích hoạt API ProvisionProduct với ID sản phẩm tương ứng.

Sau khi tạo tài khoản AWS, sự kiện CreateManagedAccount được xuất bản bởi AWS Control Tower đến Amazon EventBridge. Một luật được cấu hình trong EventBridge để gửi sự kiện CreateManagedAccount đến hàng đợi Amazon Simple Queue Service (Amazon SQS). Dịch vụ quản lý trạm làm việc khoa học dữ liệu đọc hàng đợi SQS, lấy các sự kiện CreateManagedAccount và gọi dịch vụ quản lý khách hàng để thêm số tài khoản AWS đã tạo (một phần của thông điệp sự kiện) vào siêu dữ liệu khách hàng.

Trạng thái yêu cầu cung cấp trạm làm việc khoa học dữ liệu được lưu trữ trong bảng DynamoDB để người dùng có thể truy vấn bất kỳ lúc nào.

Tích hợp và quản lý danh tính

Phần này tập trung vào tích hợp giữa SaaS và SageMaker Studio (bao gồm khởi chạy SageMaker Studio từ trong SaaS) và quản lý danh tính. Chúng tôi sử dụng Amazon Cognito làm IdP trong giải pháp này, nhưng nếu SaaS đã tích hợp với một IdP khác hỗ trợ OAuth 2.0 / OpenID Connect, bạn có thể tiếp tục sử dụng IdP đó vì cùng thiết kế sẽ được áp dụng.

SageMaker Studio hỗ trợ xác thực thông qua AWS Single Sign-On (AWS SSO) và IAM. Với việc tổ chức AWS trong trường hợp này được quản lý bởi nhà cung cấp SaaS, có khả năng AWS SSO được kết nối với IdP của nhà cung cấp SaaS, chứ không phải IdP của khách hàng SaaS. Do đó, chúng tôi sử dụng IAM để xác thực người dùng truy cập vào SageMaker Studio.

Việc xác thực người dùng truy cập vào SageMaker Studio bằng IAM đòi hỏi tạo một hồ sơ người dùng cho mỗi người dùng trên miền SageMaker và ánh xạ danh tính của họ trong Amazon Cognito vào hồ sơ người dùng đã được tạo. Một cách đơn giản để đạt được điều đó là sử dụng tên người dùng của họ trong Amazon Cognito làm tên hồ sơ người dùng của họ trong miền SageMaker Studio. SageMaker cung cấp API CreateUserProfile, có thể được sử dụng để tạo hồ sơ người dùng cho người dùng lần đầu tiên họ cố gắng khởi chạy SageMaker Studio.

Đối với khởi chạy SageMaker Studio từ bên trong SaaS, SageMaker cung cấp API CreatePresignedDomainUrl, tạo ra URL được ký quỹ cho SageMaker Studio. URL được ký quỹ được tạo ra được chuyển đến giao diện người dùng để khởi chạy SageMaker Studio trong một tab trình duyệt khác.

Hình sau mô tả kiến trúc để thiết lập tích hợp giữa SaaS và SageMaker Studio.

Microservice quản lý Data Science Workbench (DSW) xử lý việc tạo URL được ký hợp đồng trước để khởi chạy SageMaker Studio có sẵn trong tài khoản của khách hàng. Nó gọi đến microservice quản lý tenant để lấy số tài khoản AWS tương ứng với ID của tenant được bao gồm trong yêu cầu, sau đó giả định một vai trò IAM trong tài khoản này với các quyền được yêu cầu và gọi đến API SageMaker CreatePresignedDomainUrl để tạo URL được ký hợp đồng trước.

Nếu người dùng khởi chạy SageMaker Studio lần đầu tiên, họ cần được tạo một hồ sơ người dùng. Điều này được thực hiện bằng cách gọi đến API SageMaker CreateUserProfile.

Người dùng có thể sử dụng DSW để thực hiện xử lý dữ liệu quy mô lớn, đào tạo mô hình ML và sử dụng nó cho dự đoán hàng loạt và tạo các bộ dữ liệu phong phú. Họ cũng có thể sử dụng nó để xây dựng và đào tạo mô hình ML, lưu trữ mô hình ML này trên SageMaker managed hosting và kích hoạt nó từ SaaS để thực hiện một trường hợp sử dụng như đã đề cập ở đầu bài (thay thế khả năng phân tích thống kê đơn giản dự đoán khách hàng bỏ đi với khả năng phân tích dựa trên ML nâng cao mà khách hàng tự xây dựng mô hình cho). Hình sau đây mô tả một cách tiếp cận để đạt được điều này.

Nhà khoa học dữ liệu của khách hàng SaaS khởi chạy trạm làm việc khoa học dữ liệu (SageMaker Studio) và sử dụng nó để tiền xử lý dữ liệu đã trích xuất bằng SageMaker Processing (hoặc có thể sử dụng SageMaker Data Wrangler). Sau đó, họ quyết định sử dụng thuật toán ML nào và khởi chạy một công việc đào tạo SageMaker để huấn luyện mô hình với dữ liệu đã được tiền xử lý. Sau đó, họ thực hiện đánh giá mô hình cần thiết trong một cuốn sổ tay SageMaker Studio, và nếu họ hài lòng với kết quả, họ sử dụng hosting được quản lý bởi SageMaker để triển khai và lưu trữ mô hình ML đã được tạo ra.

Sau khi ML được triển khai, nhà khoa học dữ liệu đi đến SaaS và cung cấp chi tiết của điểm cuối SageMaker đang lưu trữ mô hình ML. Điều này kích hoạt một cuộc gọi đến microservice quản lý người dùng để thêm chi tiết điểm cuối SageMaker vào thông tin người dùng. Sau đó, khi một cuộc gọi được thực hiện đến microservice quản lý khách hàng, nó gọi microservice quản lý người dùng để lấy thông tin người dùng, bao gồm số tài khoản AWS và chi tiết điểm cuối SageMaker. Sau đó, nó giả định một vai trò IAM trong tài khoản khách hàng với các quyền cần thiết, gọi điểm cuối SageMaker để tính toán xác suất khách hàng chuyển đổi và bao gồm kết quả trong tin nhắn phản hồi.

ML Endpoint được gọi bởi microservice quản lý khách hàng là động (được lấy từ dịch vụ quản lý người dùng), nhưng giao diện là cố định và được xác định trước bởi nhà cung cấp SaaS – bao gồm định dạng (ví dụ, application/json), các tính năng mà SaaS gửi đến mô hình ML, thứ tự của chúng và đầu ra cũng vậy. Khách hàng SaaS được mong đợi xây dựng một mô hình ML phù hợp với giao diện được xác định bởi nhà cung cấp SaaS. Chi tiết giao diện và yêu cầu/phản hồi mẫu sẽ được trình bày trên trang ứng dụng để cho phép họ ghi đè triển khai với mô hình ML của riêng họ. Microservice SaaS (microservice quản lý khách hàng như được thể hiện trong biểu đồ trên) thực hiện các phép biến đổi và serialization cần thiết để tạo ra các tính năng được mong đợi bởi điểm cuối ML trong định dạng được chỉ định, kích hoạt điểm cuối ML, thực hiện các phép biến đổi và deserialization cần thiết, sau đó bao gồm kết quả suy luận trong phản hồi được trả về bởi microservice.

Có thể xảy ra trường hợp khách hàng SaaS muốn loại bỏ các tính năng không liên quan đến mô hình của họ hoặc thêm tính năng vào những gì SaaS đã truyền. Điều này có thể đạt được bằng cách tận dụng Use Your Own Inference Code, nơi họ có đầy đủ kiểm soát về mã suy luận.

Quản lý dữ liệu

Phần này trình bày kiến trúc đề xuất để xây dựng microservice quản lý dữ liệu, một trong những phương pháp mà bạn có thể theo để cho phép khách hàng SaaS truy cập vào dữ liệu đang nằm trong kho dữ liệu của SaaS. Microservice quản lý dữ liệu nhận yêu cầu trích xuất dữ liệu từ các nhà khoa học dữ liệu và chạy những yêu cầu này một cách kiểm soát để tránh ảnh hưởng tiêu cực đến hiệu suất kho dữ liệu SaaS. Microservice cũng có trách nhiệm kiểm soát truy cập vào kho dữ liệu SaaS (bao gồm các yếu tố dữ liệu được bao gồm trong việc trích xuất dữ liệu) và che giấu và ẩn danh dữ liệu nếu được yêu cầu.

Biểu đồ sau miêu tả một thiết kế tiềm năng cho microservice quản lý dữ liệu.

Dịch vụ micro quản lý dữ liệu được chia thành hai thành phần:

1. Quản lý dữ liệu – Nhận yêu cầu trích xuất dữ liệu, đưa nó vào hàng đợi và gửi phản hồi xác nhận.
2. Công nhân quản lý dữ liệu – Lấy yêu cầu từ hàng đợi và xử lý bằng cách gọi AWS Glue job.

Phân tách này cho phép bạn tăng tỷ lệ của hai thành phần một cách độc lập và kiểm soát tải trên kho dữ liệu SaaS, bất kể khối lượng yêu cầu trích xuất dữ liệu.

AWS Glue job trích xuất dữ liệu từ bản sao của cơ sở dữ liệu giao dịch, thay vì lấy dữ liệu từ bản chính của cơ sở dữ liệu. Điều này ngăn chặn yêu cầu trích xuất dữ liệu ảnh hưởng tiêu cực đến hiệu suất của SaaS.

AWS Glue job tải dữ liệu trích xuất lên một thùng chứa S3 trong tài khoản AWS được tạo ra cho khách hàng cụ thể. Do đó, thành phần công nhân quản lý dữ liệu cần gọi dịch vụ vi mạch quản lý khách hàng để lấy số tài khoản AWS, là một phần của thông tin khách hàng.

Trạng thái của các yêu cầu trích xuất dữ liệu được lưu trữ trong bảng DynamoDB để người dùng có thể tra cứu bất cứ khi nào.

Kết luận

Trong bài đăng này, chúng tôi đã hướng dẫn bạn cách xây dựng data science workbench trong SaaS của bạn bằng cách sử dụng SageMaker Studio. Chúng tôi đã đề cập đến các khía cạnh như cấu trúc tài khoản AWS, cách ly tenant, trích xuất dữ liệu từ kho dữ liệu SaaS và làm cho nó có thể truy cập được vào data science workbench, khởi chạy SageMaker Studio từ bên trong SaaS, quản lý danh tính và cuối cùng là cung cấp data science workbench một cách tự động cách sử dụng các dịch vụ như AWS Control Tower,  AWS Organizations và AWS CloudFormation.

Chúng tôi hy vọng điều này sẽ giúp bạn mở rộng việc sử dụng ML trong SaaS của mình và cung cấp cho khách hàng của bạn một giải pháp linh hoạt hơn cho phép họ sử dụng các khả năng ML mà bạn cung cấp cho họ và cũng để tự xây dựng các khả năng ML.

---

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.