Maestro: Bộ điều phối quy trình làm việc của Netflix

 (netflixtechblog.com)
4 điểm bởi GN⁺ 2024-07-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • Netflix đã phát hành mã nguồn mở Maestro, bộ điều phối có thể mở rộng theo chiều ngang cho các workflow Data/ML quy mô lớn, và nội bộ công ty đang vận hành sau khi chuyển hàng trăm nghìn workflow sang hệ thống này với mức gián đoạn tối thiểu
  • Khác với các bộ điều phối tập trung vào DAG, hệ thống này xử lý đồng thời workflow không chu trình và có chu trình, đồng thời cung cấp vòng lặp foreach, subworkflow và nhánh điều kiện như các mẫu ở cấp engine
  • Trong 1 năm qua, số lượng job thực thi đã tăng 87,5%; hiện hệ thống chạy trung bình mỗi ngày hàng nghìn workflow instance và khoảng 500.000 job, còn vào những ngày cao điểm thì hoàn thành khoảng 2 triệu job
  • Định nghĩa dựa trên JSON kết hợp chiến lược chạy, tham số, biểu thức SEL, tín hiệu, breakpoint, timeline, chính sách retry và rollup để hỗ trợ kiểm soát vận hành và gỡ lỗi
  • Trong môi trường như Netflix, nơi các bảng dữ liệu tập trung trong một data warehouse duy nhất, nếu chia workflow ra nhiều cụm thì chi phí điều phối và trải nghiệm người dùng sẽ giảm sút, vì vậy kiến trúc để một bộ điều phối duy nhất đảm nhiệm toàn bộ luồng là rất quan trọng

Công bố Maestro và quy mô vận hành tại Netflix

  • Netflix đã công bố mã nguồn Maestro thông qua Maestro GitHub repository
  • Maestro là bộ điều phối workflow có thể mở rộng theo chiều ngang để quản lý các workflow Data/ML quy mô lớn như pipeline dữ liệu và pipeline huấn luyện mô hình machine learning
  • Hệ thống quản lý toàn bộ vòng đời workflow từ lúc bắt đầu đến khi kết thúc, đồng thời xử lý retry, queueing và phân phối job tới compute engine
  • Người dùng có thể đóng gói business logic dưới nhiều dạng như Docker image, notebook, bash script, SQL và Python
  • Netflix đã giới thiệu hệ thống này trước đó rồi chuyển hàng trăm nghìn workflow sang Maestro, đồng thời giảm thiểu gián đoạn cho người dùng trong quá trình chuyển đổi
  • Quy mô vận hành gần đây:
    • Trong 1 năm qua, số lượng job thực thi đã tăng 87,5%
    • Trung bình mỗi ngày chạy hàng nghìn workflow instance
    • Trung bình mỗi ngày chạy khoảng 500.000 job
    • Vào những ngày bận rộn, hoàn thành khoảng 2 triệu job

Hỗ trợ khả năng mở rộng và đa dạng bằng một bộ điều phối duy nhất

  • Trong nội bộ Netflix, Maestro là một bộ điều phối được quản lý hoàn toàn, cung cấp Workflow-as-a-Service cho hàng nghìn người dùng cuối, ứng dụng và dịch vụ
  • Hệ thống hỗ trợ pipeline ETL, workflow ML, pipeline thử nghiệm AB và pipeline di chuyển dữ liệu giữa nhiều hệ thống lưu trữ
  • Kiến trúc mở rộng theo chiều ngang được thiết kế để xử lý cả số lượng workflow lớn lẫn số lượng job lớn bên trong từng workflow đơn lẻ
  • Các workflow của Netflix được liên kết chặt chẽ với nhau, nên nếu chia thành các nhóm nhỏ để quản lý trên nhiều cụm khác nhau thì sẽ cần thêm cơ chế điều phối và làm giảm trải nghiệm người dùng
  • Do các bảng dữ liệu nằm trong một data warehouse duy nhất, Netflix cho rằng một bộ điều phối duy nhất phải xử lý mọi workflow truy cập vào đó

Mô hình định nghĩa workflow

  • Định nghĩa workflow của Maestro được viết dưới định dạng JSON
  • Định nghĩa điều phối được tạo bằng cách kết hợp các trường do người dùng cung cấp và các trường do Maestro quản lý; ví dụ có tại Maestro repository wiki
  • Định nghĩa workflow được chia thành hai phần lớn
    • properties: chứa thông tin tác giả, chủ sở hữu và cấu hình thực thi
    • versioned workflow: chứa metadata workflow và định nghĩa đồ thị
  • properties giữ lại các thuộc tính cốt lõi như thông tin tác giả/chủ sở hữu, chiến lược chạy và cấu hình đồng thời ngay cả khi phiên bản workflow thay đổi
  • Nếu quyền sở hữu thay đổi, chủ sở hữu mới có thể tiếp quản workflow hiện có mà không cần tạo phiên bản workflow mới
  • versioned workflow bao gồm mã định danh duy nhất, tên, mô tả, thẻ, cấu hình timeout và mức độ criticality low, medium, high để ưu tiên hóa
  • Khi workflow thay đổi, hệ thống tạo phiên bản mới; mặc định sẽ dùng phiên bản đang hoạt động hoặc phiên bản mới nhất
  • Workflow được cấu thành từ các step là các nút trong đồ thị do người dùng định nghĩa
    • Step có thể biểu thị một job, một workflow khác thông qua subworkflow step, hoặc một vòng lặp thông qua foreach step
    • Step bao gồm mã định danh duy nhất, loại step, thẻ, tham số đầu vào/đầu ra, dependency, chính sách retry, chế độ lỗi và đầu ra của step
    • Hệ thống hỗ trợ chính sách retry có thể cấu hình theo từng loại lỗi

Run Strategy để kiểm soát thứ tự thực thi

  • Maestro quyết định có chạy workflow instance mới hay không bằng run strategy được định nghĩa sẵn

  • Sequential Run Strategy

    • Đây là chiến lược mặc định, chạy từng instance một theo thứ tự FIFO
    • Bất kể lần chạy trước thành công hay không, khi instance đạt trạng thái kết thúc như thành công hoặc thất bại thì hệ thống sẽ bắt đầu instance tiếp theo trong hàng đợi

  • Strict Sequential Run Strategy

    • Chạy theo đúng thứ tự được kích hoạt, nhưng sẽ chặn nếu lịch sử instance trước đó có blocking error
    • Instance mới sẽ tiếp tục nằm trong hàng đợi cho tới khi instance bị lỗi được khởi động lại thủ công hoặc được xử lý unblock
    • Phù hợp với workflow ít nhạy cảm về thời gian nhưng có mức độ quan trọng cao với business

  • First-only Run Strategy

    • Không giữ instance mới trong hàng đợi cho tới khi workflow đang chạy hoàn tất
    • Nếu đã có instance đang chạy, hệ thống sẽ loại bỏ instance mới được đưa vào hàng đợi, tức là gần như tắt queueing
    • Cách này giúp tránh vấn đề idempotency vì không tích lũy thêm instance mới

  • Last-only Run Strategy

    • Luôn bảo đảm instance được kích hoạt gần nhất sẽ được chạy
    • Nếu đã có instance đang chạy, hệ thống sẽ dừng nó và chạy instance mới được kích hoạt
    • Hữu ích khi chỉ cần dữ liệu mới nhất, như workflow xử lý snapshot mới nhất của toàn bộ bảng ở mỗi lần chạy

  • Parallel with Concurrency Limit Run Strategy

    • Chạy song song nhiều instance trong giới hạn đồng thời được định nghĩa sẵn
    • Có thể fan-out và phân tán thực thi để xử lý lượng dữ liệu lớn trong thời gian giới hạn
    • Backfill dữ liệu cũ là một trường hợp sử dụng phổ biến

Tham số và biểu thức SEL

  • Trong Maestro, tham số được dùng để điều khiển logic thực thi, chia sẻ trạng thái giữa workflow và step, cũng như giữa step upstream và downstream
  • Maestro hỗ trợ tham số động kèm chèn mã, cho phép định nghĩa các workflow được tham số hóa phức tạp
  • Chèn mã có thể tạo ra rủi ro về bảo mật và độ ổn định
    • Nếu người dùng viết vòng lặp vô hạn rồi liên tục thêm phần tử vào mảng, máy chủ có thể bị dừng do OOM
    • Nếu chuyển mã được chèn vào bên trong business logic thì gánh nặng cho người dùng sẽ tăng lên, đồng thời workflow definition và business logic bị gắn chặt với nhau
  • Để giảm thiểu điều này, Netflix đã phát triển SEL (Simple, Secure, and Safe Expression Language), ngôn ngữ biểu thức riêng của mình
  • SEL tuân theo ngữ pháp và cú pháp của Java Language Specifications nhưng chỉ hỗ trợ một tập con phù hợp với các trường hợp sử dụng của Maestro
  • SEL hỗ trợ kiểu dữ liệu của loại tham số trong Maestro, xử lý lỗi, xử lý ngày giờ và các utility method được định nghĩa sẵn
  • Để bảo đảm ổn định, hệ thống bao gồm các kiểm tra runtime như giới hạn số lần lặp, kiểm tra kích thước mảng và giới hạn kích thước bộ nhớ của đối tượng
  • Tài liệu SEL có tại Maestro GitHub documentation

Tham số đầu ra và workflow được tham số hóa

  • Maestro cho phép trả kết quả thực thi do người dùng tạo ra về hệ thống dưới dạng tham số đầu ra thông qua callable step execution
  • Dữ liệu đầu ra được truyền qua Maestro REST API, và runtime của step không truy cập trực tiếp vào cơ sở dữ liệu Maestro
  • Workflow tĩnh thì đơn giản, nhưng để phản ánh khác biệt nhỏ có thể phải nhân bản cùng một workflow nhiều lần; ngoài ra nếu không có tham số thì workflow và job không thể chia sẻ trạng thái
  • Workflow động hoàn toàn thì khó quản lý và hỗ trợ, đồng thời cũng khó debug, xử lý sự cố và tái sử dụng
  • Workflow được tham số hóa được khởi tạo cho từng step tại runtime dựa trên tham số do người dùng định nghĩa, từ đó mang lại cả sự linh hoạt trong kiểm soát lúc thực thi lẫn khả năng quản lý
  • Hỗ trợ tham số của Maestro cho phép tạo ra các workflow được tham số hóa phức tạp như pipeline dữ liệu backfill

Mẫu thực thi workflow ở cấp độ engine

  • Maestro hỗ trợ trực tiếp các mẫu dataflow và workflow phổ biến ngay trong engine
  • Việc được engine hỗ trợ trực tiếp cho phép tối ưu hóa mẫu và có cách triển khai nhất quán

  • Foreach

    • Mẫu foreach ban đầu được mô hình hóa như một step chuyên dụng trong định nghĩa workflow
    • Mỗi lần lặp của vòng foreach được xử lý nội bộ như một workflow instance riêng biệt
    • Việc thực thi các step trong khối định nghĩa foreach, tức thực thi sub-graph, được ủy quyền cho một workflow instance riêng
    • Step foreach giám sát và thu thập trạng thái của các workflow instance phụ trách từng lần lặp
    • Thường được dùng cho backfill dữ liệu hoặc tinh chỉnh mô hình machine learning, nơi cùng một tác vụ được chạy với tham số khác nhau cho từng lần lặp
    • Người dùng không cần viết trực tiếp hàng trăm nghìn lần lặp vào định nghĩa workflow, đồng thời cũng giảm nhu cầu tạo workflow mới khi phạm vi foreach thay đổi

  • Conditional Branch

    • Nhánh điều kiện cho phép chỉ chạy các step tiếp theo khi một điều kiện cụ thể từ step upstream được thỏa mãn
    • Điều kiện được định nghĩa bằng biểu thức SEL và được đánh giá tại runtime
    • Có thể xây dựng luồng trong đó khi step kiểm tra audit thất bại thì thực hiện thao tác khôi phục rồi chạy lại công việc

  • Subworkflow

    • Subworkflow cho phép một step của workflow chạy một workflow khác, nhờ đó có thể chia sẻ chức năng dùng chung giữa nhiều workflow
    • Có thể cấu thành đồ thị workflow theo dạng “workflow as a function”
    • Tại Netflix, cũng quan sát thấy các workflow phức tạp gồm hàng trăm subworkflow, kết hợp các subworkflow do nhiều đội ngũ cung cấp để xử lý dữ liệu của hàng trăm bảng
    • Foreach, nhánh điều kiện và subworkflow có thể được kết hợp với nhau
    • Có thể xử lý một tập hợp subworkflow theo vòng lặp
    • Có thể chạy các vòng lặp foreach lồng nhau
    • Có thể dùng kết hợp nhánh điều kiện và subworkflow để xử lý lỗi và tạo workflow tự phục hồi nhằm tự động retry công việc

Step Runtime và hợp nhất tham số

  • Maestro sử dụng step runtime để mô tả tác vụ tại thời điểm thực thi
  • Giao diện step runtime định nghĩa hai loại thông tin
    • Tập API cơ bản để điều khiển hành vi thực thi của step instance
    • Cấu trúc dữ liệu đơn giản để theo dõi trạng thái runtime của step và kết quả thực thi
  • Maestro cung cấp các implementation như foreach step runtime và subworkflow step runtime
  • Mỗi implementation định nghĩa logic riêng cho các hành vi start, execute và terminate
  • Trạng thái runtime được dùng để xác định bước chuyển trạng thái tiếp theo của step và quyết định có bị lỗi hay kết thúc hay không
  • Kết quả thực thi chứa step artifact và timeline lịch sử thực thi của step, và có thể được các step sau truy cập

  • Step Parameter Merging

    • Maestro hỗ trợ runtime parameter và chèn tag để điều khiển động hành vi của step
    • Parameter map của step ban đầu trống và được hợp nhất theo thứ tự sau
    • Default General Parameters: là các tham số mặc định của mọi step như workflow_instance_id, step_instance_uuid, step_attempt_id, step_id; đây là các giá trị được Maestro dành riêng nội bộ nên người dùng không thể truyền vào
    • Injected Parameters: là các tham số được tạo động trong step runtime và có thể khác nhau tùy schema của từng loại step
    • Default Typed Parameters: là các tham số mặc định liên quan đến một loại step cụ thể, ví dụ loop_params, loop_index của foreach step
    • Workflow and Step Info Parameters: là thông tin định danh liên quan đến step và workflow như workflow_id
    • Undefined New Parameters: là các tham số step mới do người dùng chỉ định khi khởi động hoặc khởi động lại workflow instance
    • Step Definition Parameters: là các tham số step do người dùng viết tại thời điểm định nghĩa
    • Run and Restart Parameters: là các giá trị do người dùng cung cấp khi khởi động hoặc khởi động lại để ghi đè các tham số định nghĩa hiện có, và được hợp nhất cuối cùng

Step Dependencies và Signal

  • Các step trong đồ thị workflow của Maestro có thể biểu diễn phụ thuộc thực thi bằng step dependency
  • Step dependency chỉ định các điều kiện liên quan đến dữ liệu cần thiết để thực thi step
  • Các điều kiện thường được định nghĩa dựa trên signal
  • Signal là thông điệp chứa thông tin như giá trị tham số, có thể được phát hành từ đầu ra của step hoặc qua các hệ thống bên ngoài như SNS·Kafka
  • Signal được dùng cả cho mẫu trigger lẫn mẫu signal dependency theo kiểu publisher-subscriber
  • Một step có thể phát hành signal đầu ra để mở khóa việc thực thi của nhiều step phụ thuộc vào signal đó
  • Signal definition bao gồm danh sách tham số được ánh xạ, và Maestro có thể thực hiện signal matching chỉ với một phần trường
  • Maestro hỗ trợ các signal operators như <, > cho giá trị tham số của signal
  • Netflix xây dựng nhiều lớp trừu tượng trên khái niệm signal
    • Khi workflow ETL cập nhật một bảng và gửi signal, step của workflow downstream phụ thuộc vào dữ liệu đó có thể được thực thi
    • Signal lineage cho phép truy vết các signal instance trong quá khứ và các step workflow đã phát hành hoặc tiêu thụ signal đó
    • Signal trigger bảo đảm exactly-once execution cho các workflow đăng ký một signal hoặc một tập signal được join
  • Chỉ chạy workflow hoặc step khi các điều kiện signal được chỉ định được thỏa mãn, nhờ đó có thể tiết kiệm tài nguyên

Gỡ lỗi và khả năng quan sát thực thi

  • Breakpoint

    • Maestro cho phép đặt breakpoint trên các step của workflow
    • Khi workflow instance đạt đến step có breakpoint, step đó sẽ chuyển sang trạng thái paused
    • Tiến trình của đồ thị workflow sẽ dừng lại cho đến khi người dùng tiếp tục thủ công
    • Nếu nhiều instance của cùng một workflow step dừng tại breakpoint, việc tiếp tục một instance chỉ ảnh hưởng đến instance đó, các instance còn lại vẫn giữ trạng thái paused
    • Khi xóa breakpoint, tất cả các step instance đang dừng sẽ được tiếp tục
    • Tính năng này hữu ích để kiểm tra việc thực thi step và dữ liệu đầu ra trong giai đoạn phát triển workflow ban đầu
    • Trong mẫu foreach, nếu đặt breakpoint ở một step đơn lẻ thì mọi lần lặp sẽ dừng tại step đó để gỡ lỗi
    • Cũng có thể dùng để hỗ trợ sự can thiệp của con người trong lúc chạy hoặc thay đổi trạng thái step khi đang thực thi

  • Timeline

    • Maestro bao gồm timeline thực thi step, ghi lại các sự kiện quan trọng như thay đổi state machine và lý do của chúng
    • Các sự kiện ví dụ bao gồm các chuyển trạng thái như Created, Evaluating params
    • Các step runtime đã được triển khai có thể thêm sự kiện timeline để hiển thị thông tin thực thi cho người dùng cuối
    • Ví dụ timeline có tại sample-step-instance-failed.json

Thử lại, Aggregated View, Rollup

  • Chính sách thử lại

    • Maestro hỗ trợ chính sách thử lại cho các step kết thúc ở trạng thái thất bại
    • Người dùng có thể cấu hình số lần thử lại, độ trễ giữa các lần thử, thử lại theo khoảng cố định và chiến lược exponential backoff
    • Việc thử lại được chia thành hai loại
    • platform retry: xử lý lỗi ở cấp nền tảng, không liên quan đến logic của người dùng
    • user retry: thử lại theo các điều kiện do người dùng định nghĩa
    • Mỗi loại có thể có chính sách thử lại riêng
    • Tự động thử lại hữu ích để xử lý các lỗi tạm thời có thể khắc phục mà không cần người dùng can thiệp
    • Với các step không có tính idempotent, có thể đặt số lần thử lại là 0 để tránh thử lại

  • Aggregated View

    • Vì một workflow instance có thể có nhiều run, nên người dùng cần có khả năng xem trạng thái tổng hợp của tất cả step
    • aggregated view được tính bằng cách hợp nhất aggregated view cơ sở với trạng thái step của run hiện tại
    • Ví dụ, nếu ở lần chạy đầu tiên step1 và step2 thành công, step3 thất bại, còn step4 và step5 chưa bắt đầu, thì khi khởi động lại sẽ bắt đầu từ step3 và step1, step2 có thể bị bỏ qua do trạng thái thành công từ lần trước
    • Khi tất cả step đều thành công, aggregated view sẽ hiển thị trạng thái run của toàn bộ step

  • Rollup

    • rollup cung cấp bản tóm tắt ở cấp cao hơn của workflow instance, thể hiện trạng thái của từng step và số lượng step theo từng trạng thái
    • Hệ thống sẽ mở rộng và tổng hợp step của instance hiện tại cùng các non-inline workflow lồng nhau như subworkflow và foreach
    • Nếu một workflow thành công có ba step, trong đó một step là subworkflow gồm năm step, thì rollup sẽ hiển thị số step thành công là 7
    • Trong rollup, chỉ các leaf step được tổng hợp, còn các step khác được xem như con trỏ trỏ tới workflow cụ thể
    • Tham chiếu của các step chưa thành công cũng được giữ lại để có thể điều hướng đến step có vấn đề bên trong workflow lồng nhau
    • Aggregated rollup được tính bằng cách kết hợp runtime data của run hiện tại với base rollup
    • Rollup của step subworkflow phản ánh nguyên trạng rollup của subworkflow instance
    • Rollup của step foreach được tạo bằng cách kết hợp base rollup từ lần chạy trước, ngoại trừ các vòng lặp là đối tượng khởi động lại, với rollup của các vòng lặp đang chạy ở lần hiện tại
    • Vì quá trình này, mô hình rollup có tính eventually consistent, và nếu foreach lồng nhau với subworkflow đi sâu qua nhiều tầng thì việc tính toán có thể phức tạp và mang tính đệ quy

Phát hành sự kiện và tích hợp bên ngoài

  • Khi định nghĩa workflow, workflow instance hoặc step instance thay đổi, Maestro tạo sự kiện, xử lý nội bộ rồi phát hành ra các hệ thống bên ngoài
  • Sự kiện Maestro được chia thành sự kiện nội bộ và sự kiện bên ngoài
    • internal event: theo dõi các thay đổi nội bộ trong vòng đời của workflow, workflow instance và step instance, và được phát hành vào hàng đợi nội bộ
    • external event: chứa thông tin thay đổi trạng thái của Maestro để các dịch vụ downstream tiêu thụ, và được gửi tới các hàng đợi bên ngoài như SNS hoặc Kafka
  • Maestro event processor đăng ký hàng đợi nội bộ để lấy internal event, xử lý theo từng loại sự kiện, rồi khi cần sẽ chuyển đổi sang external event
  • Ở bước cuối, notification publisher sẽ phát hành external event để các dịch vụ downstream có thể tiêu thụ
  • Các dịch vụ downstream phần lớn hoạt động theo mô hình event-driven, và sự kiện Maestro chứa các thông điệp cần thiết để phát hiện những thay đổi khác nhau trong Maestro
  • Các loại thay đổi được chia lớn thành hai nhóm
    • workflow change: các thao tác ở cấp workflow như thay đổi định nghĩa workflow hoặc properties
    • instance status change: chuyển trạng thái của workflow instance hoặc step instance

Cách bắt đầu

  • Có thể xem mã nguồn Maestro tại github.com/Netflix/maestro
  • Có thể để lại câu hỏi, ý kiến hoặc bình luận tại GitHub issue của kho lưu trữ Maestro
  • Netflix kỳ vọng khả năng mở rộng và tính dễ sử dụng mà Maestro cung cấp sẽ giúp đẩy nhanh việc phát triển workflow bên ngoài Netflix

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-07-24
Ý kiến trên Hacker News

  • Trước đây tôi từng thán phục các blog kỹ thuật doanh nghiệp kiểu này và những hệ thống độc quyền nội bộ, nhưng giờ thì không còn nữa. Vì code là nợ
    Thay vì làm lại những thứ như cron/Celery/Airflow, tôi muốn dùng mã nguồn mở có sẵn với lịch sử bảo trì và cải tiến lâu dài. Vì dù sao cũng phải có ai đó bảo trì, sửa lỗi và thêm tính năng. Tất nhiên sẽ có ngoại lệ nếu đi kèm thăng chức và tăng lương/RSU
    Cần nhận ra rằng code không thuộc nghiệp vụ cốt lõi tạo doanh thu cho công ty là thứ làm phân tán sự chú ý và ngốn tài nguyên

    • Tôi nghĩ bài blog này ra đời chính vì lý do đó. Họ muốn mở mã nguồn phần mềm này để không còn phải tự bảo trì toàn bộ trong nội bộ nữa
      Họ tạo ra nó vì có nhu cầu mà các mã nguồn mở có sẵn hiện tại chưa giải quyết được, và giờ đây đang biến nó trở lại thành một mã nguồn mở có sẵn để tiếp tục dùng đồng thời chia sẻ gánh nặng bảo trì. Những công cụ như thế ban đầu xuất hiện bằng cách nào chứ; phải có ai đó tạo ra
    • Góc nhìn “code là nợ” quá cực đoan, và gắn rất chặt với lối tư duy kiểu MBA muốn tối thiểu-tối đa hóa mọi thứ trên đời
      May mà vẫn có những người không sợ xây dựng hệ thống mới và thúc đẩy ý tưởng mới. Ngay cả từ góc độ doanh nghiệp, chỉ những giải pháp tầm thường và né tránh rủi ro cũng có giới hạn. Những công ty có lợi nhuận cao nhất thường khá táo bạo về mặt kỹ thuật
      Code không phải là nợ, mà là thứ làm cho các bánh răng của công ty vận hành
    • Mã nguồn mở có sẵn cũng thường là kết quả của việc các tập đoàn lớn công khai công cụ nội bộ. Airflow mà bạn nhắc đến là ví dụ hay, và trong lĩnh vực này Temporal cũng vậy. Phải có ai đó đủ “ngốc” để tạo ra thứ mới
    • Cụm “có lịch sử bảo trì và cải tiến lâu dài” đang gánh một giả định rất lớn
      Tôi tò mò liệu bạn có kế hoạch tự đóng góp cho cộng đồng hay không. Tự xây hay mua luôn là một cuộc thảo luận quan trọng, nhưng cho rằng phía “mua” có chi phí bảo trì và độ tin cậy đúng bằng 0 thì có vẻ ngây thơ
    • Điều kiện “không phải nghiệp vụ cốt lõi của công ty” mới là quan trọng. Với một đội ngũ thành thạo trong lĩnh vực yêu cầu hiệu năng cao, điểm mà code bên ngoài biến thành nợ chất lượng thấp/khó kiểm soát không xa đến vậy

  • Tôi tự hỏi cần thêm bao nhiêu vòng lặp nữa thì các kỹ sư mới hài lòng với giải pháp workflow. Trước Maestro, Netflix cũng đã có nhiều giải pháp như Metaflow, Uber cũng đã tạo ra nhiều giải pháp, còn Amazon thì có ít nhất hơn chục workflow engine nội bộ
    Thật thú vị khi rất nhiều cá nhân ở nhiều công ty muốn tạo workflow engine. Tôi không có ý hạ thấp ai hay Netflix, chỉ xem đây là một quan sát đáng để nói chuyện nhẹ nhàng

    • Vấn đề là workflow orchestration là một miền vấn đề rất rộng. Các công ty phải giải quyết nhiều vấn đề khác nhau, nên bất kỳ giải pháp nào cũng trở thành một sản phẩm khổng lồ với nhiều tính năng liên quan, và khi phát triển rất dễ thành một khối nguyên khối lớn với triết lý mạnh. Vì vậy gần như chẳng ai hài lòng
      Trên thực tế có năm mối quan tâm cốt lõi: lập lịch tài nguyên, giải quyết phụ thuộc, API/DSL để tạo tác vụ và workflow, chạy theo lịch kiểu cron, và nhận biết miền để bộc lộ thông tin miền trong các workflow ETL hoặc ML/AI
      Không có một giải pháp đơn lẻ nào làm gọn gàng tất cả những việc này. Vì thế các công ty tự xây hoặc đi đường vòng để bù cho nhược điểm của sản phẩm có sẵn, và vòng lặp mọi người tiếp tục bất mãn cứ thế kéo dài
      Tôi không nghĩ đây là vấn đề mà một startup có thể tạo ra “lời giải”. Nó nên được giải quyết bằng một hệ sinh thái mã nguồn mở gồm các thành phần mô-đun tốt, có thể cắm ghép
    • Metaflow chạy bên trên Maestro, và không cái nào thay thế cái còn lại
      Trong https://netflixtechblog.com/orchestrating-data-ml-workflows-... có viết: “Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.”
      Phần orchestration của bài này (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) giải thích chi tiết Metaflow khớp với Maestro, Airflow, Argo Workflows và Step Functions như thế nào
    • Tôi từng tự làm một workflow engine, nhưng nó quá nhiều lỗi và quá thiếu linh hoạt đến mức suýt làm hỏng một dự án không liên quan
      Tôi bắt đầu nghĩ rằng workflow engine ở một mức nào đó có thể là mùi thiết kế. Một khi tạo ra thứ có thể tái sử dụng, nó trông rất hấp dẫn như thể có thể dùng cho vô số workflow, nhưng ngoài việc cần nhiều hơn một bước bất đồng bộ thì các workflow hầu như không có điểm chung
      Dữ liệu cũng khác, API cũng khác, phản hồi cần nhận từ người dùng hoặc hệ thống khác để tiếp tục cũng khác
    • Khả năng cao là vì chúng ta vẫn chưa tìm được workflow engine/orchestrator vừa xử lý được nhiều loại công việc, vừa dễ hiểu và dễ vận hành
      Tạo một workflow engine tùy chỉnh tối ưu cho một use case cụ thể thật sự rất dễ. Tôi nghĩ lý do vẫn chưa có sự hội tụ là vì công cụ như vậy vẫn chưa được tạo ra
      Nhìn vào những công cụ gần đây nhanh chóng chiếm lĩnh từng lĩnh vực, Terraform đã giải quyết IaC, Kubernetes giải quyết bài toán khó của điện toán phân tán. Cả hai đều rất phức tạp nhưng giải quyết được vấn đề khó. Ngược lại, workflow engine đa dụng thì phức tạp để hiểu, khó vận hành và trải nghiệm cũng lưng chừng, nên nhiều người thậm chí không thử
    • Đặt tên, vô hiệu hóa cache, và workflow engine chăng? :)
      https://github.com/meirwah/awesome-workflow-engines

  • Tôi là nhà sáng lập của https://windmill.dev, và Windmill có nhiều điểm tương đồng với Maestro
    Phần mô tả Maestro là “một workflow orchestrator đa dụng, có khả năng mở rộng ngang, để quản lý các workflow quy mô lớn, data pipeline và pipeline huấn luyện mô hình ML” nếu thay bằng Windmill thì cũng hoàn toàn chính xác. Cái họ gọi là rollup chính là thứ chúng tôi gọi là openflow state
    Điểm khác biệt chính là Windmill được viết bằng Rust thay vì Java; Maestro dùng CockroachDB để lưu trạng thái, còn chúng tôi dùng PostgreSQL cho cả trạng thái lẫn queue. Tuy vậy tôi hiểu lý do dùng CockroachDB. Với các instance khách hàng rất lớn, Windmill cũng đã phải tự xây dựng thuật toán sharding riêng để mở rộng ngang
    Maestro dùng giấy phép Apache 2.0, còn Windmill dùng AGPL kém thân thiện hơn. Được Netflix hậu thuẫn nên nguồn lực tài chính gần như vô hạn, trong khi chúng tôi dù có doanh thu nhưng vẫn là một công ty nhỏ hơn rất nhiều
    Maestro chưa có đủ tài liệu self-host dựa trên Kubernetes hoặc docker-compose, và dường như chưa có UI để tạo thứ gì đó, hoặc ít nhất tài liệu chưa thể hiện rõ. Dù vậy, nhìn chung việc nó được mở mã nguồn là khá tuyệt, tôi sẽ tiếp tục theo dõi và benchmark sớm nhất có thể

    • Nếu đang cân nhắc Windmill, trước tiên nên xem phần này: https://www.windmill.dev/docs/advanced/local_development
      Tôi không hiểu vì sao phải “đồng bộ” với Windmill, vì sao lại có IDE bên trong Windmill, và vì sao nó phức tạp đến vậy. Có vẻ như họ bắt đầu với mục tiêu tạo hiệu ứng khóa chân trước cả khi tạo ra một sản phẩm tốt hay tìm được product-market fit
    • So sánh thì tốt, nhưng dù Maestro dùng giấy phép Apache, nếu phụ thuộc vào CockroachDB thì cũng không hay lắm vì bản thân CockroachDB không phải mã nguồn mở
      Tôi cho rằng một codebase AGPL còn tốt hơn là một phụ thuộc không phải mã nguồn mở. Tất nhiên theo thời gian có thể sẽ có ai đó bổ sung hỗ trợ cơ sở dữ liệu thay thế

  • Tôi hơi bối rối không rõ chuyện gì đang diễn ra ở đây. Dự án này có vẻ dùng Netflix/conductor [0]. Nhưng khi vào repo đó thì thấy nó đã được lưu trữ, kèm thông báo rằng nó đã được thay thế bằng một phiên bản nội bộ không mã nguồn mở của Netflix và một fork cộng đồng không được nêu tên. Có lẽ là nói đến Orkes Conductor [1]
    Tuy nhiên dự án này dường như không dùng Orkes Conductor, mà dùng phiên bản Netflix đã bị ngừng phát triển là com.netflix.conductor:conductor-core:2.31.5 [2]. Đó cũng là một phiên bản cũ
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

  • Tôi tò mò không biết có ai từng dùng ActiveBatch chưa. Với tôi, đây là phần mềm tuyệt vời mà tôi rất muốn có một sản phẩm tương đương cho người dùng ngoài doanh nghiệp
    Tôi đã nhiều lần thử các “đối thủ” khác, nhưng với ActiveBatch, chỉ cần gắn một MS SQL DB đơn giản, cài Windows GUI và execution agent là qua vài cú nhấp chuột đã có một môi trường tự động hóa dựa trên GUI rất vững chắc. Không cần viết code, và nếu muốn thì cũng có thể viết code bằng bất kỳ ngôn ngữ nào
    Airflow có thể rất mạnh, nhưng bị che sau một rào cản phức tạp nên đa số mọi người không thấy được năng lực thật sự của nó. Các đối thủ “mã nguồn mở” khác cũng tương tự
    Tôi không hiểu vì sao chưa ai làm được một hệ thống ưu tiên GUI, dựa trên DB thật vững chắc. Tôi cũng đã thử các dịch vụ online nhưng không thể so sánh được. Có lẽ các sản phẩm trả phí đơn giản hơn thất bại vì chi phí duy trì phần mở rộng quá cao
    Thật đáng tiếc khi ActiveBatch bị nhốt sau mô hình bán hàng doanh nghiệp ngớ ngẩn. Điều đó đang ngăn phần mềm tuyệt vời này lan rộng tới cộng đồng lớn hơn. Nó giống như một bí mật bị che giấu

  • Lời khuyên là tốt nhất đừng phụ thuộc vào các công cụ mà Netflix mở mã nguồn. Họ có một tiền lệ dài là công bố rồi sau đó ngừng hỗ trợ
    Có thể ai đó đã có được một dấu tích trong bảng đánh giá thăng chức nhờ bài blog và việc công bố code này, nhưng đừng xây dựng doanh nghiệp của bạn trên những giải pháp như vậy

  • Không rõ vì sao nên cân nhắc cái này thay vì một thứ đã vững chỗ hơn như Temporal. Maestro được viết bằng Java, còn Temporal có vẻ được viết bằng Go

    • Mã Go của Temporal hơi kỳ. Có vẻ trước đây họ dùng Java rồi chuyển sang Go, và phần Go đó trông rất kiểu Java
      Hoặc cũng có thể là tôi không hiểu rõ Fx
      https://github.com/temporalio/temporal/blob/main/service/mat...
      Vấn đề tôi liên tục gặp với Temporal là tài liệu rất thiếu. Đây là thứ được cài vào phần cốt lõi của nghiệp vụ, nhưng phải đi qua nhiều tầng và tài liệu rất khó hiểu mới có thể hiểu thực sự chuyện gì đang diễn ra
      Maestro có vẻ không có tài liệu. Nếu vậy thì Temporal mặc định thắng
    • Netflix cũng dùng Temporal: https://temporal.io/in-use/netflix
    • Tôi nghĩ Maestro không phải là phương án thay thế cho Temporal, mà là phương án thay thế cho Airflow. Temporal không phải là workflow orchestrator. Cấu trúc bên trong có phần chồng lấn, nhưng đây là những thiết kế khác nhau cho các use case khác nhau
    • Chẳng phải một phần cốt lõi của Temporal đã được viết lại bằng Rust sao?

  • Đây có vẻ là một dự án thật sự tốt. Trong hầu hết các dự án lai giữa ML + data engineering mà tôi từng phụ trách, tôi đều từng cân nhắc làm một thứ gần giống thế này, có lẽ là một phiên bản tệ hơn
    Rất mong được tự mình thử nghiệm

  • Vì tôi đang làm orchestra trong lĩnh vực này, xin chia sẻ suy nghĩ của mình: việc làm mã nguồn mở và phát triển công khai rõ ràng là tuyệt vời. Nhưng như chính họ nói, đây là một orchestrator, và đã có quá nhiều thứ ra đời trước đó, bao gồm cả Airflow
    Vì vậy, ngoài việc thêm một lựa chọn nữa mà sẽ không ai dùng trong môi trường thương mại, tôi khó thấy nó thực sự bổ sung điều gì cho lĩnh vực này
    Quảng cáo không ngại ngùng: https://getorchestra.io

  • Tôi tò mò liệu cái này có khác biệt đáng kể so với Conductor đã từng được lưu trữ không. Lướt qua mã thì thấy khá nhiều điểm tương đồng, và việc dùng JSON làm ngôn ngữ định nghĩa workflow cũng giống nhau