Tác giả: Hàn Lập

Tại Instacart, chúng tôi tự hào cung cấp nhiều loại sản phẩm máy học (ML) đa dạng hỗ trợ mọi khía cạnh trên thị trường của chúng tôi, bao gồm khách hàng, người mua sắm, nhà bán lẻ và thương hiệu. Cùng với sự phát triển của các ứng dụng ML và kinh doanh, chúng tôi đã gặp phải ngày càng nhiều trường hợp sử dụng yêu cầu các kỹ thuật ML phân tán để mở rộng hiệu quả các sản phẩm ML của chúng tôi.

Để hỗ trợ các yêu cầu mới nổi, chúng tôi đã thiết kế hệ thống ML phân tán với các cân nhắc thiết kế chính sau:

• Khả năng mở rộng: Chúng tôi phải có khả năng mở rộng một số lượng lớn khối lượng công việc ML phân tán trên cả phiên bản CPU và GPU bằng một hệ thống mạnh mẽ duy trì hiệu suất và độ tin cậy cao.
• Hiệu quả tài nguyên : Chúng tôi mong muốn sử dụng đầy đủ các tài nguyên tính toán phân tán để tối đa hóa thông lượng hệ thống và đạt được hiệu quả thực thi nhanh nhất với chi phí tối ưu.
• Tính đa dạng : Khung tính toán được chọn phải càng mở rộng càng tốt để hỗ trợ các mô hình ML phân tán đa dạng. Ngoài ra, chúng tôi sẽ có thể xử lý các môi trường đa dạng dành riêng cho các khối lượng công việc ML khác nhau.

• Song song hóa hàng nghìn mô hình đào tạo quy mô vừa và nhỏ trên các máy chủ phân tán với việc sử dụng tài nguyên hiệu quả và thời gian xếp hàng hợp lý.
• Sử dụng tính song song của dữ liệu để cho phép các mô hình học sâu hoạt động với các tập dữ liệu lớn hiệu quả hơn.
• Phát triển khả năng suy luận hàng loạt có thể mở rộng với một số lượng lớn các công việc xử lý song song trên một lượng lớn dữ liệu.

Kiến Trúc Hệ Thống

Chúng tôi nhận thấy rằng một hệ thống có trải nghiệm người dùng đơn giản là điều cần thiết để tăng năng suất của nhà phát triển và tối đa hóa tác động của các ứng dụng ML phân tán của chúng tôi. Do đó, ngoài các nguyên tắc thiết kế về khả năng mở rộng, hiệu quả tài nguyên và tính đa dạng , chúng tôi ưu tiên các mục tiêu sau để đơn giản hóa trải nghiệm người dùng:

• Tính đơn giản trong phát triển : Chúng tôi mong muốn đơn giản hóa quy trình phát triển cho các kỹ sư ML bằng cách cung cấp cho họ các công cụ để kiểm tra mã phân tán của họ một cách liền mạch trong môi trường cục bộ và môi trường phân tán.
• Bảo trì đơn giản : Mục tiêu của chúng tôi là cung cấp một mô hình phát triển không cần máy chủ, cho phép các kỹ sư của chúng tôi phát triển và chạy khối lượng công việc mà không phải chịu gánh nặng quản lý bất kỳ dịch vụ nào. Chúng tôi tin rằng bằng cách loại bỏ nhu cầu xử lý quản lý dịch vụ, chúng tôi có thể cải thiện năng suất của MLE một cách hiệu quả.
• Tích hợp liền mạch : Mục tiêu của chúng tôi là tích hợp liền mạch khối lượng công việc ML phân tán với Instacart ML Platform Griffin mà không cần tạo một bộ công cụ hoặc nền tảng MLOps dự phòng. Thay vì phát minh lại bánh xe, chúng tôi đặt mục tiêu cải thiện cơ sở hạ tầng hiện có của mình.

Dưới đây là bảng phân tích của từng thành phần tương tác với môi trường phân tán Ray:

• Trong giai đoạn phát triển, người dùng có thể đóng gói các đoạn mã tạo mẫu trên môi trường phát triển của họ và khởi chạy chúng trên các máy chủ AWS EKS từ xa thông qua API trình khởi chạy nội bộ trừu tượng hóa quyền truy cập Cụm Ray thông qua API Công việc Ray ( xem Hình 1a).

• Khi người dùng đã sẵn sàng tự động hóa mã của họ trong các quy trình sản xuất (tức là Luồng không khí), họ có thể sử dụng cùng một bộ API để khởi chạy ứng dụng được chứa trong vùng chứa của mình cho các Cụm Ray sản xuất (xem Hình 1b).

• Mỗi cụm Ray được định cấu hình độc lập với các cài đặt Python và biến môi trường. Điều này phân tách hiệu quả các môi trường không gian làm việc giữa các cụm, tránh chi phí duy trì môi trường python nguyên khối, điều này sẽ được thảo luận chi tiết trong phần tiếp theo (xem Hình 1c).

• Ở cấp độ ứng dụng, người dùng cần xây dựng các ứng dụng ML bằng cách sử dụng API Ray để đạt được nhiều mẫu tính toán phân tán, chẳng hạn như API Ray Core , Ray AIR và Ray Serve .
• Về phía bộ điều khiển, chúng tôi sử dụng KubeRay làm bộ điều khiển cung cấp, chia tỷ lệ và xóa tài nguyên Cụm Ray trên Kubernetes.

Nghiên cứu điển hình: Công việc ML thực hiện song song

Tại Instacart, ML được áp dụng trong suốt vòng đời hoàn thành mọi đơn hàng được đặt trên Ứng dụng Instacart (Hình 2). Điều này bao gồm việc gộp nhiều đơn đặt hàng lại với nhau để nâng cao hiệu quả, định tuyến để xác định lộ trình giao hàng tối ưu, dự đoán ETA về thời gian đến của đơn hàng và dự báo cung/cầuđể ngăn chặn việc giao hàng bị thất lạc khi không có đủ người mua hàng có sẵn, v.v. Một số lượng đáng kể các mô hình như vậy được đào tạo với dữ liệu được thu thập trong một vùng lân cận cụ thể và một số mô hình đó cũng nhạy cảm với dữ liệu được thu thập trong một khung thời gian cụ thể, do đó, thông thường là phân vùng toàn bộ tập dữ liệu quốc gia dựa trên một hoặc nhiều không gian /time, sau đó khởi chạy một công việc đào tạo trên mỗi phân vùng dữ liệu, tốt nhất là song song.

“Thuộc tính” phổ biến nhất là vị trí địa lý của các đơn đặt hàng, được gọi là “khu vực”. Tại Instacart, chúng tôi quản lý hàng nghìn vùng duy nhất để phân vùng tập dữ liệu quốc gia của mình. Đối với mỗi ứng dụng Fulfillment ML, thông thường sẽ khởi chạy tới hàng nghìn công việc đào tạo song song để bao quát tất cả các khu vực trong một thử nghiệm mô hình duy nhất.

Các giải pháp & hạn chế trước đây

Giải pháp cũ của chúng tôi đã triển khai dịch vụ xếp hàng tác vụ phân tán bằng Celery ; Hình 3 minh họa sơ đồ kiến ​​trúc. Đối với mỗi ứng dụng mô hình duy nhất (được biểu thị là Mô hình trong sơ đồ) yêu cầu đào tạo song song trên vùng 1~n, các công việc đào tạo cho tất cả các vùng được xuất bản dưới dạng tác vụ cho cùng một hàng đợi tác vụ trên Message Broker . Sau đó, một nhóm nhân viên của Celery đăng ký từng hàng đợi nhiệm vụ và thực hiện các nhiệm vụ bên trong nó. Các tác vụ được thực thi không đồng bộ và bất cứ khi nào một nhân viên Celery rảnh rỗi, nhiệm vụ ở phía trước hàng đợi sẽ bị xóa và gán cho nhân viên rảnh rỗi. Sau khi worker hoàn thành, nó sẽ cập nhật trạng thái tác vụ trong Phần phụ trợ thông báo và tìm nạp tác vụ tiếp theo trong hàng đợi để thực thi.

Khi số lượng ứng dụng ML yêu cầu đào tạo song song cấp vùng tăng lên theo thời gian, loại dịch vụ nguyên khối này bắt đầu khó mở rộng quy mô hơn do những lý do sau:

• Sử dụng tài nguyên không hiệu quả: Nhiều ứng dụng ML đã chia sẻ cùng một hàng đợi tác vụ và các dịch vụ công nhân phân tán của Celery. Hóa ra là các công nhân phân tán không thể được sử dụng đầy đủ một cách hiệu quả:
  - Nút công nhân phải được cung cấp quá mức với đủ khoảng trống tài nguyên để phù hợp với tất cả các loại mô hình. Tuy nhiên, trong Fulfillment ML, hầu hết các mô hình đều khá nhẹ, chẳng hạn như hồi quy, phân loại, v.v. Do đó, khi chạy một mô hình kích thước nhỏ, nhân viên được sử dụng kém. Ví dụ: trong biểu đồ bên trái của Hình 4, một mô hình nhẹ đang chạy trên phiên bản 16 CPU, với mức sử dụng CPU chỉ khoảng 10% đến 15%.
  - Dịch vụ kéo dài có thể khiến hệ thống không hoạt động nếu tải không cân bằng trong suốt cả ngày. Ví dụ, ở phía bên phải của Hình 4, hàng đợi không chạy bất kỳ tác vụ nào trong hơn 60% thời gian trong ngày, dẫn đến việc sử dụng tài nguyên không hiệu quả.

• Thời gian xếp hàng dài : Rất khó để đạt được thời gian thực hiện nhanh hơn mà không nâng cấp dịch vụ hàng đợi tác vụ:
  - Tính đồng thời của công nhân Celery thấp được định cấu hình trên mỗi máy chủ của hàng đợi tác vụ, bởi vì không thể chỉ tăng tính đồng thời để phù hợp với tất cả các mô hình trên một dịch vụ nguyên khối.
  - Khi một hàng đợi nhiệm vụ được giao với quá nhiều nhiệm vụ, chẳng hạn như Hình 5, trong đó có hơn 300 đến hơn 1 nghìn nhiệm vụ xếp hàng cả ngày, thời gian xếp hàng của mỗi nhiệm vụ được thực thi sẽ tăng lên đáng kể, làm chậm quá trình hoàn thành thời gian thực hiện của từng ứng dụng ML.
  - Do đó, cách duy nhất để tăng tốc hàng đợi bận rộn là thực hiện nâng cấp để thêm nhiều máy chủ vật lý hơn, điều này tiếp tục bổ sung thêm các tài nguyên được sử dụng kém vào hệ thống.

• Quản lý phụ thuộc khó khăn : Rất khó để quản lý các phụ thuộc Python cho tất cả các ứng dụng mô hình chạy trên cùng một hàng đợi. Nâng cấp một phiên bản gói python cụ thể là một thách thức.
• Gánh nặng bảo trì : Hệ thống này rất phức tạp để tự động hóa và không cung cấp cách tiếp cận đơn giản để tái tạo hệ thống trong môi trường cục bộ cho mục đích thử nghiệm.

Khi chúng tôi bắt đầu áp dụng khối lượng công việc Fulfillment ML cho các hệ thống ML phân tán mới của mình, thay đổi quan trọng nhất là việc di chuyển từ các dịch vụ nguyên khối chạy lâu dài sang các ứng dụng không có máy chủ dựa trên Ray. Thay vì tất cả các mô hình chạy trên cùng một môi trường, mỗi ứng dụng Fulfillment ML được khởi chạy dưới dạng một tác vụ Ray độc lập được liên kết với một Cụm tia chuyên dụng để xử lý tất cả các tác vụ đào tạo cấp vùng của nó, như được minh họa trong Hình 6. Thiết kế mới này mang lại một số lợi thế so với giải pháp kế thừa của chúng tôi:

• Với hệ thống mới của chúng tôi, mỗi mô hình hiện có môi trường không gian làm việc biệt lập riêng , cho phép quản lý độc lập các phụ thuộc Python và sử dụng tài nguyên trên cơ sở từng mô hình (Hình 7).

• Các dịch vụ hàng đợi tác vụ chạy dài hiện không được dùng nữa . Điều này giúp giảm chi phí cho các tài nguyên tính toán và quan trọng nhất là giúp cơ sở hạ tầng dễ dàng mở rộng quy mô hơn để lưu trữ các ứng dụng mới sắp tới.
• Các ứng dụng không có máy chủ cung cấp cho người dùng khả năng cung cấp tài nguyên cho mỗi nhân viên Ray chính xác hơn, dẫn đến việc sử dụng tài nguyên hiệu quả hơn nhiều . Hình 8 cung cấp một ví dụ thực tế về cải tiến này bằng cách so sánh mức sử dụng CPU trước/sau của mô hình sản xuất Hoàn thành đơn hàng chạy 1,5 nghìn tác vụ đào tạo duy nhất trên cùng một nhóm máy chủ: -
  Trong hệ thống cũ được mô tả trước đó, chỉ một số nhân viên của Celery đã được định cấu hình để chạy trên mỗi máy chủ, dẫn đến mức sử dụng CPU khoảng 10–15% .
  - Với kiến ​​trúc dựa trên Ray mới của chúng tôi, chúng tôi có thể tùy chỉnh chính xác hơn các yêu cầu tài nguyên. Thông qua điểm chuẩn, chúng tôi nhận thấy rằng chỉ cần phân bổ 2 CPU cho mỗi công việc đào tạo theo vùng là đủ. Do đó, chúng tôi có thể tạo nhiều nhân viên Ray đồng thời hơn trên cùng một phiên bản, tăng đáng kể mức sử dụng CPU trên mỗi máy chủ lên tới 80% .

• Việc sử dụng tài nguyên được cải thiện đã góp phần thực hiện từ đầu đến cuối nhanh hơn . Với cùng một mô hình sản xuất được đề cập ở trên chạy trên 10 phiên bản 16 CPU, chỉ có tổng cộng 10 nhân viên đồng thời của Celery trên dịch vụ kế thừa trong khi một ứng dụng dựa trên Ray có thể khởi chạy tới hơn 70 nhân viên Ray. Kết quả là, giờ đây chúng tôi có thể tăng tốc đáng kể thời gian hoàn thành từ đầu đến cuối–trước đây là ~4 giờ– thành 20 phút !

Học hỏi & Công việc Tương lai

Chúng tôi đã thu được những hiểu biết có giá trị từ kinh nghiệm của mình khi xây dựng các giải pháp ML phân tán và di chuyển các trường hợp sử dụng ban đầu khỏi các hệ thống cũ. Chúng tôi đã phát hiện ra rằng việc lưu trữ một dịch vụ nguyên khối dưới dạng phần phụ trợ tính toán cho tất cả các ứng dụng ML được phân phối có những hạn chế về khả năng mở rộng, hiệu quả và tính đa dạng do tính chất đa dạng và phát triển nhanh chóng của các ứng dụng ML. Chẳng hạn, bằng cách chuyển đổi từ các dịch vụ nguyên khối sang các ứng dụng độc lập không có máy chủ để đào tạo ở cấp vùng Hoàn thành, chúng tôi có thể tăng đáng kể thời gian thực hiện, mức sử dụng tài nguyên và tính đơn giản của quá trình phát triển.

Mặc dù cấu trúc liên kết của từng ứng dụng có thể được chủ sở hữu ứng dụng tùy chỉnh cao trong ML phân tán, nhưng điều cần thiết là phải có các công cụ khởi chạy và xây dựng thống nhất trên lớp nền tảng ML. Cách tiếp cận này cho phép chúng tôi hỗ trợ nhiều loại khối lượng công việc ML phân tán hơn trong tương lai đồng thời đảm bảo nền tảng của chúng tôi vẫn có thể mở rộng.

Sắp tới, chúng tôi mong muốn thúc đẩy việc áp dụng rộng rãi hơn các ứng dụng ML phân tán trên Instacart trên nhiều dòng sản phẩm ML. Mục tiêu của chúng tôi cho năm 2023 là hoàn thiện hơn nữa giải pháp ML phân tán dựa trên Ray của chúng tôi dưới dạng giải pháp hợp nhất hoạt động như một phần của Griffin. Khi chúng tôi bắt đầu hành trình này, chúng tôi rất vui mừng được xem ML phân tán nào có thể giúp chúng tôi đạt được thành tựu tiếp theo tại Instacart.