Maestro: ตัวออร์เคสเตรตเวิร์กโฟลว์ของ Netflix

 (netflixtechblog.com)
4 คะแนน โดย GN⁺ 2024-07-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Netflix เปิดซอร์ส Maestro ออร์เคสเตรเตอร์ที่ขยายแนวนอนได้ สำหรับเวิร์กโฟลว์ Data/ML ขนาดใหญ่ และภายในองค์กรได้ย้ายเวิร์กโฟลว์หลายแสนรายการมารันโดยมีการหยุดชะงักน้อยที่สุด
  • ต่างจากออร์เคสเตรเตอร์ที่ยึด DAG เป็นศูนย์กลาง โดยรองรับทั้ง เวิร์กโฟลว์แบบไม่มีวัฏจักรและแบบมีวัฏจักร พร้อมมีแพตเทิร์นระดับเอนจินอย่างลูป foreach, subworkflow และการแตกแขนงตามเงื่อนไข
  • ในช่วง 1 ปีที่ผ่านมา จำนวนงานที่รันเพิ่มขึ้น 87.5% และปัจจุบันรันเวิร์กโฟลว์อินสแตนซ์เฉลี่ยวันละหลายพันรายการกับงานราว 5 แสนงานต่อวัน และในวันที่มีโหลดสูงสามารถทำงานเสร็จได้ราว 2 ล้านงาน
  • รองรับ การควบคุมการปฏิบัติงานและการดีบัก ด้วยการผสานนิยามแบบ JSON เข้ากับกลยุทธ์การรัน, พารามิเตอร์, นิพจน์ SEL, สัญญาณ, เบรกพอยต์, ไทม์ไลน์, นโยบายรีทราย และ rollup
  • ในสภาพแวดล้อมแบบ Netflix ที่ตารางข้อมูลรวมอยู่ในดาต้าแวร์เฮาส์เดียว การแยกเวิร์กโฟลว์ไปหลายคลัสเตอร์จะเพิ่มต้นทุนการประสานงานและทำให้ประสบการณ์ผู้ใช้แย่ลง ดังนั้นสถาปัตยกรรมที่ให้ ออร์เคสเตรเตอร์ตัวเดียว ดูแลทั้งโฟลว์จึงสำคัญ

การเปิดตัว Maestro และขนาดการใช้งานภายใน Netflix

  • Netflix เผยแพร่ ซอร์สโค้ดของ Maestro ผ่าน Maestro GitHub repository
  • Maestro คือ ออร์เคสเตรเตอร์เวิร์กโฟลว์ที่ขยายแนวนอน สำหรับจัดการเวิร์กโฟลว์ Data/ML ขนาดใหญ่ เช่น ดาต้าไปป์ไลน์และไปป์ไลน์ฝึกโมเดลแมชชีนเลิร์นนิง
  • จัดการวงจรชีวิตของเวิร์กโฟลว์ทั้งหมดตั้งแต่เริ่มต้นจนจบ พร้อมดูแลการรีทราย การเข้าคิว และการกระจายงานไปยังคอมพิวต์เอนจิน
  • ผู้ใช้สามารถแพ็กเกจ business logic ได้หลายรูปแบบ เช่น Docker image, notebook, bash script, SQL และ Python
  • หลังจากเปิดตัวก่อนหน้านี้ Netflix ได้ย้ายเวิร์กโฟลว์หลายแสนรายการมายัง Maestro และลดการหยุดชะงักของผู้ใช้ระหว่างการเปลี่ยนผ่านให้น้อยที่สุด
  • ขนาดการใช้งานล่าสุด:
    • จำนวนงานที่รันเพิ่มขึ้น 87.5% ในช่วง 1 ปีที่ผ่านมา
    • รันเวิร์กโฟลว์อินสแตนซ์เฉลี่ยวันละหลายพันรายการ
    • รันงานเฉลี่ยวันละประมาณ 5 แสนงาน
    • ในวันที่มีโหลดสูง ทำงานเสร็จได้ประมาณ 2 ล้านงาน

รองรับทั้งการขยายตัวและความหลากหลายด้วยออร์เคสเตรเตอร์ตัวเดียว

  • Maestro เป็นออร์เคสเตรเตอร์แบบ fully managed ภายใน Netflix ที่ให้บริการ Workflow-as-a-Service แก่ผู้ใช้ปลายทาง แอปพลิเคชัน และบริการหลายพันราย
  • รองรับ ETL pipeline, ML workflow, AB testing pipeline และ data movement pipeline ระหว่างสตอเรจหลายระบบ
  • โครงสร้างแบบขยายแนวนอนถูกออกแบบให้รองรับได้ทั้งจำนวนเวิร์กโฟลว์จำนวนมาก และจำนวนงานจำนวนมากภายในเวิร์กโฟลว์เดียว
  • เวิร์กโฟลว์ของ Netflix เชื่อมโยงกันอย่างหนาแน่น หากแยกเป็นกลุ่มเล็ก ๆ แล้วจัดการบนหลายคลัสเตอร์ จะต้องมีกลไกประสานงานเพิ่มเติมและทำให้ประสบการณ์ผู้ใช้แย่ลง
  • เนื่องจากตารางข้อมูลอยู่ในดาต้าแวร์เฮาส์เดียว จึงตัดสินใจว่าเวิร์กโฟลว์ทั้งหมดที่เข้าถึงข้อมูลนั้นควรถูกจัดการโดย ออร์เคสเตรเตอร์ตัวเดียว

โมเดลการนิยามเวิร์กโฟลว์

  • นิยามเวิร์กโฟลว์ของ Maestro เขียนในรูปแบบ JSON
  • นิยาม orchestration ถูกประกอบขึ้นจากฟิลด์ที่ผู้ใช้กำหนดร่วมกับฟิลด์ที่ Maestro จัดการเอง โดยมีตัวอย่างใน Maestro repository wiki
  • นิยามเวิร์กโฟลว์แบ่งออกเป็น 2 ส่วนใหญ่ ๆ
    • properties: รวมข้อมูลผู้สร้าง ข้อมูลเจ้าของ และการตั้งค่าการรัน
    • versioned workflow: รวม metadata ของเวิร์กโฟลว์และนิยามกราฟ
  • properties ช่วยคงคุณสมบัติหลักอย่างข้อมูลผู้สร้าง/เจ้าของ กลยุทธ์การรัน และการตั้งค่าคอนเคอร์เรนซีไว้ แม้เวอร์ชันของเวิร์กโฟลว์จะเปลี่ยนไป
  • หากมีการเปลี่ยนเจ้าของ ก็สามารถให้เจ้าของใหม่รับช่วงความเป็นเจ้าของเวิร์กโฟลว์เดิมได้โดยไม่ต้องสร้างเวอร์ชันใหม่
  • versioned workflow มีตัวระบุเฉพาะ ชื่อ คำอธิบาย แท็ก การตั้งค่า timeout และระดับ criticality แบบ low, medium, high สำหรับการจัดลำดับความสำคัญ
  • การเปลี่ยนแปลงเวิร์กโฟลว์จะสร้างเวอร์ชันใหม่ และโดยปริยายจะใช้เวอร์ชันที่ active หรือเวอร์ชันล่าสุด
  • เวิร์กโฟลว์ประกอบด้วย step ซึ่งเป็นโหนดในกราฟที่ผู้ใช้กำหนด
    • step อาจแทนงาน เวิร์กโฟลว์อื่นผ่าน subworkflow step หรือการวนลูปผ่าน foreach step
    • step มีตัวระบุเฉพาะ ประเภทของ step แท็ก พารามิเตอร์อินพุต/เอาต์พุต dependency นโยบายรีทราย โหมดความล้มเหลว และเอาต์พุตของ step
    • รองรับนโยบายรีทรายที่ตั้งค่าแยกตามประเภทของข้อผิดพลาดได้

Run Strategy สำหรับควบคุมลำดับการรัน

  • Maestro ใช้ run strategy ที่กำหนดไว้ล่วงหน้าเพื่อตัดสินใจว่าจะรันเวิร์กโฟลว์อินสแตนซ์ใหม่หรือไม่

  • Sequential Run Strategy

    • เป็นกลยุทธ์เริ่มต้น และรันทีละหนึ่งรายการตามลำดับ FIFO
    • ไม่ว่าการรันก่อนหน้าจะสำเร็จหรือไม่ หากอินสแตนซ์ก่อนหน้าเข้าสู่สถานะสิ้นสุด เช่น success หรือ failure แล้ว จะเริ่มอินสแตนซ์ถัดไปในคิว

  • Strict Sequential Run Strategy

    • รันตามลำดับที่ถูก trigger แต่หากประวัติของอินสแตนซ์ก่อนหน้ามี blocking error จะกันไม่ให้รันต่อ
    • อินสแตนซ์ใหม่จะยังคงอยู่ในคิวจนกว่าจะมีการรีสตาร์ตอินสแตนซ์ที่ล้มเหลวด้วยตนเองหรือทำการ unblock
    • เหมาะกับเวิร์กโฟลว์ที่ไม่ไวต่อเวลา แต่มีความสำคัญต่อธุรกิจสูง

  • First-only Run Strategy

    • จะไม่เก็บอินสแตนซ์ใหม่ไว้ในคิวจนกว่าเวิร์กโฟลว์ที่กำลังรันอยู่จะเสร็จ
    • หากมีอินสแตนซ์ที่กำลังรันอยู่ อินสแตนซ์ใหม่ที่เข้าคิวจะถูกลบออก ทำให้การเข้าคิวแทบถูกปิดไปโดยปริยาย
    • ช่วยหลีกเลี่ยงปัญหา idempotency ได้เพราะไม่ปล่อยให้มีอินสแตนซ์ใหม่สะสม

  • Last-only Run Strategy

    • ทำให้มีการรันอินสแตนซ์ที่ถูก trigger ล่าสุดเสมอ
    • หากมีอินสแตนซ์ที่กำลังรันอยู่ จะหยุดอินสแตนซ์นั้นและรันอินสแตนซ์ที่ถูก trigger ใหม่
    • มีประโยชน์เมื่อจำเป็นต้องใช้เฉพาะข้อมูลล่าสุด เช่น เวิร์กโฟลว์ที่ประมวลผลสแนปช็อตล่าสุดของทั้งตารางในแต่ละครั้ง

  • Parallel with Concurrency Limit Run Strategy

    • รันหลายอินสแตนซ์แบบขนานภายในขีดจำกัดคอนเคอร์เรนซีที่กำหนดไว้ล่วงหน้า
    • สามารถ fan-out และกระจายการรันเพื่อประมวลผลข้อมูลจำนวนมากภายในเวลาที่จำกัดได้
    • กรณีใช้งานทั่วไปคือการ backfill ข้อมูลเก่า

พารามิเตอร์และนิพจน์ SEL

  • ใน Maestro พารามิเตอร์ถูกใช้เพื่อควบคุมลอจิกการรัน แชร์สถานะระหว่างเวิร์กโฟลว์กับ step และแชร์สถานะระหว่าง step ต้นน้ำกับปลายน้ำ
  • Maestro รองรับ dynamic parameter ที่มาพร้อม code injection เพื่อให้สามารถนิยามเวิร์กโฟลว์ที่มีการทำพารามิเตอร์ซับซ้อนได้
  • code injection อาจสร้างความเสี่ยงด้านความปลอดภัยและเสถียรภาพ
    • หากผู้ใช้เขียนลูปไม่รู้จบแล้วเพิ่มรายการลงในอาร์เรย์ต่อเนื่อง เซิร์ฟเวอร์อาจหยุดทำงานจาก OOM ได้
    • หากย้ายโค้ดที่ฉีดเข้าไปไว้ใน business logic จะเพิ่มภาระให้ผู้ใช้และทำให้นิยามเวิร์กโฟลว์กับ business logic ผูกกันแน่นเกินไป
  • เพื่อบรรเทาปัญหานี้ Netflix จึงพัฒนาภาษา expression ของตัวเองชื่อ SEL(Simple, Secure, and Safe Expression Language)
  • SEL ใช้ไวยากรณ์และรูปแบบตาม Java Language Specifications แต่รองรับเฉพาะส่วนย่อยที่เหมาะกับกรณีใช้งานของ Maestro
  • SEL รองรับ data type ของประเภทพารามิเตอร์ใน Maestro การจัดการข้อผิดพลาด การประมวลผลวันที่/เวลา และ utility method ที่กำหนดไว้ล่วงหน้า
  • เพื่อความเสถียร ยังมี runtime check เช่น การจำกัดจำนวนรอบลูป การตรวจขนาดอาร์เรย์ และการจำกัดขนาดหน่วยความจำของอ็อบเจ็กต์
  • เอกสารของ SEL อยู่ที่ Maestro GitHub documentation

เอาต์พุตพารามิเตอร์และเวิร์กโฟลว์แบบ parameterized

  • Maestro สามารถรับผลลัพธ์การรันจากผู้ใช้กลับเข้าสู่ระบบในรูป เอาต์พุตพารามิเตอร์ ผ่าน callable step execution
  • ข้อมูลเอาต์พุตถูกส่งผ่าน Maestro REST API โดยที่ step runtime ไม่ต้องเข้าถึงฐานข้อมูลของ Maestro โดยตรง
  • เวิร์กโฟลว์แบบ static นั้นเรียบง่าย แต่หากต้องสะท้อนความแตกต่างเพียงเล็กน้อยก็อาจต้องคัดลอกเวิร์กโฟลว์เดียวกันหลายครั้ง และหากไม่มีพารามิเตอร์ เวิร์กโฟลว์กับงานจะไม่สามารถแชร์สถานะกันได้
  • เวิร์กโฟลว์แบบ dynamic เต็มรูปแบบนั้นจัดการและซัพพอร์ตได้ยาก อีกทั้งยังดีบัก แก้ปัญหา และนำกลับมาใช้ซ้ำได้ลำบาก
  • เวิร์กโฟลว์แบบ parameterized จะถูก initialised ในระดับ step ตอนรันจริงตามพารามิเตอร์ที่ผู้ใช้กำหนด ทำให้ได้ทั้งความยืดหยุ่นในการควบคุมขณะรันและความสามารถในการดูแลจัดการ
  • การรองรับพารามิเตอร์ของ Maestro ทำให้สามารถสร้างเวิร์กโฟลว์แบบ parameterized ที่ซับซ้อนได้ เช่น ดาต้าไปป์ไลน์สำหรับ backfill

รูปแบบการรันเวิร์กโฟลว์ในระดับเอนจิน

  • Maestro รองรับ dataflow และรูปแบบเวิร์กโฟลว์ทั่วไปได้โดยตรงในเอนจิน
  • การรองรับโดยตรงจากเอนจินทำให้สามารถปรับแต่งรูปแบบและมีวิธีติดตั้งใช้งานที่สม่ำเสมอได้

  • Foreach

    • รูปแบบ foreach เดิมถูกโมเดลเป็น step เฉพาะภายในนิยามเวิร์กโฟลว์
    • การวนซ้ำแต่ละครั้งของลูป foreach จะถูกประมวลผลภายในเป็นอินสแตนซ์เวิร์กโฟลว์แยกต่างหาก
    • การรัน step ภายในบล็อกนิยาม foreach หรือก็คือการรัน sub-graph จะถูกมอบหมายให้อินสแตนซ์เวิร์กโฟลว์อีกตัวหนึ่ง
    • step foreach จะคอยมอนิเตอร์และรวบรวมสถานะของอินสแตนซ์เวิร์กโฟลว์ที่รับผิดชอบแต่ละรอบการวนซ้ำ
    • มักใช้กับ data backfill หรือการปรับจูนโมเดลแมชชีนเลิร์นนิงที่ต้องรันงานเดียวกันด้วยพารามิเตอร์ต่างกันในแต่ละรอบ
    • ผู้ใช้ไม่จำเป็นต้องเขียนการวนซ้ำหลักหลายแสนครั้งลงในนิยามเวิร์กโฟลว์โดยตรง และยังลดความจำเป็นในการสร้างเวิร์กโฟลว์ใหม่เมื่อขอบเขตของ foreach เปลี่ยนไป

  • Conditional Branch

    • การแตกแขนงตามเงื่อนไข ทำให้ step ถัดไปทำงานก็ต่อเมื่อเงื่อนไขที่กำหนดของ step ต้นทางเป็นจริง
    • เงื่อนไขจะนิยามด้วยนิพจน์ SEL และประเมินผลในรันไทม์
    • สามารถจัดโฟลว์ที่เมื่อ step ตรวจสอบ audit ล้มเหลว จะทำงานกู้คืนก่อนแล้วจึงรันงานอีกครั้งได้

  • Subworkflow

    • subworkflow ทำให้ step หนึ่งของเวิร์กโฟลว์สามารถเรียกใช้อีกเวิร์กโฟลว์หนึ่งได้ เพื่อให้ฟังก์ชันร่วมถูกใช้ซ้ำในหลายเวิร์กโฟลว์
    • สามารถประกอบกราฟเวิร์กโฟลว์ในรูปแบบ “workflow as a function” ได้
    • ที่ Netflix ยังพบเวิร์กโฟลว์ซับซ้อนที่ประกอบด้วย subworkflow หลายร้อยตัว โดยนำ subworkflow จากหลายทีมมาประกอบกันเพื่อประมวลผลข้อมูลของหลายร้อยตาราง
    • foreach, การแตกแขนงตามเงื่อนไข และ subworkflow สามารถนำมาผสมกันได้
    • สามารถวนลูปกับชุดของ subworkflow ได้
    • สามารถรันลูป foreach แบบซ้อนกันได้
    • สามารถใช้การแตกแขนงตามเงื่อนไขร่วมกับ subworkflow เพื่อจัดการข้อผิดพลาดและสร้างเวิร์กโฟลว์กู้คืนอัตโนมัติที่รีทรายงานได้เอง

Step Runtime และการรวมพารามิเตอร์

  • Maestro ใช้ step runtime เพื่ออธิบายงาน ณ เวลารัน
  • อินเทอร์เฟซ step runtime กำหนดข้อมูลไว้สองอย่าง
    • ชุด API พื้นฐานที่ควบคุมพฤติกรรมการทำงานของอินสแตนซ์ step
    • โครงสร้างข้อมูลแบบเรียบง่ายสำหรับติดตามสถานะรันไทม์ของ step และผลลัพธ์การทำงาน
  • Maestro มีอิมพลีเมนเทชันอย่าง foreach step runtime และ subworkflow step runtime
  • แต่ละอิมพลีเมนเทชันจะกำหนดลอจิกของตัวเองสำหรับการทำงาน start, execute, terminate
  • สถานะรันไทม์ถูกใช้เพื่อตัดสินการเปลี่ยนสถานะถัดไปของ step และใช้พิจารณาว่าล้มเหลวหรือสิ้นสุดแล้วหรือไม่
  • ผลลัพธ์การทำงานจะเก็บ step artifact และไทม์ไลน์ประวัติการรันของ step ซึ่ง step ถัดไปสามารถเข้าถึงได้

  • Step Parameter Merging

    • Maestro รองรับ runtime parameter และการ inject tag เพื่อควบคุมพฤติกรรมของ step แบบไดนามิก
    • map ของ step parameter จะเริ่มต้นเป็นค่าว่าง แล้วถูกรวมตามลำดับต่อไปนี้
    • Default General Parameters: พารามิเตอร์พื้นฐานของทุก step เช่น workflow_instance_id, step_instance_uuid, step_attempt_id, step_id และเป็นค่าที่ Maestro สำรองไว้ใช้ภายใน ผู้ใช้จึงส่งเข้ามาเองไม่ได้
    • Injected Parameters: พารามิเตอร์ที่สร้างขึ้นแบบไดนามิกจาก step runtime และอาจแตกต่างกันตาม schema ของประเภท step
    • Default Typed Parameters: พารามิเตอร์พื้นฐานที่เกี่ยวข้องกับประเภท step เฉพาะ เช่น loop_params, loop_index ของ step แบบ foreach
    • Workflow and Step Info Parameters: ข้อมูลระบุตัวตนที่เกี่ยวกับ step และเวิร์กโฟลว์ เช่น workflow_id
    • Undefined New Parameters: step parameter ใหม่ที่ผู้ใช้ระบุเพิ่มเติมตอนเริ่มหรือรีสตาร์ตอินสแตนซ์เวิร์กโฟลว์
    • Step Definition Parameters: step parameter ที่ผู้ใช้เขียนไว้ตั้งแต่ตอนนิยาม
    • Run and Restart Parameters: ค่าที่ผู้ใช้ส่งมาตอนเริ่มหรือรีสตาร์ตเพื่อเขียนทับพารามิเตอร์เดิมในนิยาม และจะถูกรวมเป็นลำดับสุดท้าย

Step Dependencies และ Signal

  • step ในกราฟเวิร์กโฟลว์ของ Maestro สามารถแสดงการพึ่งพาการรันได้ด้วย step dependency
  • step dependency ใช้ระบุเงื่อนไขด้านข้อมูลที่จำเป็นต่อการรัน step
  • โดยทั่วไปเงื่อนไขจะนิยามบนพื้นฐานของ signal
  • signal คือข้อความที่บรรจุข้อมูลอย่างค่าพารามิเตอร์ และสามารถเผยแพร่ได้ผ่านผลลัพธ์ของ step หรือระบบภายนอกอย่าง SNS และ Kafka
  • signal ถูกใช้ทั้งในรูปแบบ trigger และรูปแบบ signal dependency แบบ publisher-subscriber
  • step หนึ่งสามารถเผยแพร่ output signal เพื่อปลดล็อกการทำงานของหลาย step ที่พึ่งพา signal นั้นได้
  • signal definition มีรายการพารามิเตอร์ที่ถูกแมปไว้ และ Maestro สามารถทำ signal matching ได้โดยใช้เพียงบางฟิลด์
  • Maestro รองรับ signal operators เช่น <, > สำหรับค่าพารามิเตอร์ของ signal
  • Netflix สร้างแอบสแตรกชันหลายอย่างบนแนวคิด signal นี้
    • หากเวิร์กโฟลว์ ETL อัปเดตตารางและส่ง signal ออกมา step ของเวิร์กโฟลว์ downstream ที่พึ่งพาข้อมูลนั้นก็จะเริ่มทำงานได้
    • signal lineage ทำให้สามารถสำรวจอินสแตนซ์ signal ในอดีต และ step ของเวิร์กโฟลว์ที่เผยแพร่หรือบริโภค signal นั้นได้
    • signal trigger รับประกัน exactly-once execution สำหรับเวิร์กโฟลว์ที่ subscribe signal เดี่ยวหรือชุด signal ที่ join กัน
  • การรันเวิร์กโฟลว์หรือ step จะเกิดขึ้นก็ต่อเมื่อเงื่อนไข signal ที่ระบุไว้เป็นจริงเท่านั้น จึงช่วยประหยัดทรัพยากรได้

การดีบักและการมองเห็นการรัน

  • Breakpoint

    • Maestro สามารถตั้ง เบรกพอยต์ ให้กับ step ของเวิร์กโฟลว์ได้
    • เมื่ออินสแตนซ์เวิร์กโฟลว์ไปถึง step ที่ตั้งเบรกพอยต์ไว้ step นั้นจะเข้าสู่สถานะ paused
    • ความคืบหน้าของกราฟเวิร์กโฟลว์จะหยุดจนกว่าผู้ใช้จะสั่งให้ทำงานต่อด้วยตนเอง
    • หากมีหลายอินสแตนซ์ของ step เดียวกันในเวิร์กโฟลว์หยุดอยู่ที่เบรกพอยต์ การสั่งทำงานต่อหนึ่งตัวจะมีผลเฉพาะอินสแตนซ์นั้น ส่วนที่เหลือยังคงอยู่ในสถานะ paused
    • เมื่อลบเบรกพอยต์ อินสแตนซ์ step ทั้งหมดที่หยุดอยู่จะทำงานต่อ
    • มีประโยชน์ในการตรวจสอบการทำงานของ step และข้อมูล output ระหว่างการพัฒนาเวิร์กโฟลว์ช่วงแรก
    • ในรูปแบบ foreach หากตั้งเบรกพอยต์กับ step เดียว ก็สามารถหยุดทุกการวนซ้ำที่ step นั้นเพื่อดีบักได้
    • ยังใช้รองรับการแทรกแซงโดยมนุษย์ระหว่างรัน หรือการเปลี่ยนสถานะของ step ระหว่างการทำงานได้ด้วย

  • Timeline

    • Maestro มีไทม์ไลน์การรันของ step ซึ่งบันทึกเหตุการณ์สำคัญ เช่น การเปลี่ยนแปลงของ state machine และสาเหตุ
    • ตัวอย่างเหตุการณ์มีทรานซิชันอย่าง Created, Evaluating params
    • step runtime ที่อิมพลีเมนต์ไว้สามารถเพิ่มเหตุการณ์ลงในไทม์ไลน์เพื่อแสดงข้อมูลการรันแก่ผู้ใช้ปลายทางได้
    • ตัวอย่างไทม์ไลน์ดูได้ที่ sample-step-instance-failed.json

การลองใหม่, Aggregated View, Rollup

  • นโยบายการลองใหม่

    • Maestro รองรับ นโยบายการลองใหม่ สำหรับ step ที่ไปถึงสถานะสิ้นสุดด้วยความล้มเหลว
    • ผู้ใช้สามารถกำหนดจำนวนครั้งในการลองใหม่, ระยะหน่วงระหว่างการลองใหม่, การลองใหม่แบบช่วงคงที่, และกลยุทธ์ exponential backoff ได้
    • การลองใหม่แบ่งออกเป็น 2 ประเภท
    • platform retry: รับมือข้อผิดพลาดระดับแพลตฟอร์มที่ไม่เกี่ยวกับตรรกะของผู้ใช้
    • user retry: การลองใหม่ตามเงื่อนไขที่ผู้ใช้กำหนด
    • แต่ละประเภทสามารถมีนโยบายการลองใหม่แยกกันได้
    • การลองใหม่อัตโนมัติมีประโยชน์สำหรับจัดการข้อผิดพลาดชั่วคราวที่แก้ไขได้โดยไม่ต้องให้ผู้ใช้เข้ามาแทรกแซง
    • step ที่ไม่มี idempotency สามารถตั้งจำนวนครั้งในการลองใหม่เป็น 0 เพื่อหลีกเลี่ยงการลองใหม่ได้

  • Aggregated View

    • เนื่องจาก workflow instance หนึ่งรายการสามารถมีได้หลาย run ผู้ใช้จึงต้องสามารถดูสถานะรวมของทุก step ได้
    • aggregated view คำนวณโดยผสาน aggregated view พื้นฐานเข้ากับสถานะ step ของ run ปัจจุบัน
    • ตัวอย่างเช่น หากในการรันครั้งแรก step1·step2 สำเร็จ, step3 ล้มเหลว, และ step4·step5 ยังไม่เริ่ม การรีสตาร์ตจะเริ่มจาก step3 และ step1·step2 อาจถูกข้ามเพราะมีสถานะสำเร็จจากก่อนหน้า
    • เมื่อทุก step สำเร็จ aggregated view จะแสดงสถานะการรันของทุก step ทั้งหมด

  • Rollup

    • rollup ให้สรุประดับสูงของ workflow instance โดยแสดงสถานะของแต่ละ step และจำนวน step แยกตามสถานะ
    • ระบบจะขยายและรวม step ของอินสแตนซ์ปัจจุบันและ non-inline workflow แบบซ้อน เช่น subworkflow และ foreach
    • หาก workflow ที่สำเร็จมีสาม step และหนึ่งในนั้นเป็น subworkflow ที่มีห้า step rollup จะแสดงจำนวน step ที่สำเร็จเป็น 7
    • ใน rollup จะนับรวมเฉพาะ leaf step ส่วน step อื่นจะถือเป็นตัวชี้ไปยัง workflow ที่เฉพาะเจาะจง
    • ระบบยังคงเก็บการอ้างอิงของ step ที่ไม่สำเร็จไว้ด้วย เพื่อให้สามารถไปยัง step ที่มีปัญหาใน nested workflow ได้
    • aggregated rollup คำนวณโดยรวม runtime data ของ run ปัจจุบันเข้ากับ base rollup
    • rollup ของ subworkflow step จะสะท้อน rollup ของ subworkflow instance ตรงตัว
    • rollup ของ foreach step จะรวม base rollup จากการรันก่อนหน้าโดยยกเว้นรอบที่เป็นเป้าหมายของการรีสตาร์ต กับ rollup ของรอบที่กำลังรันอยู่ในปัจจุบัน
    • ด้วยกระบวนการนี้ โมเดล rollup จึงเป็นแบบ eventually consistent และเมื่อมี nested foreach และ subworkflow หลายชั้น การคำนวณอาจซับซ้อนและเป็นแบบเรียกซ้ำ

การเผยแพร่อีเวนต์และการเชื่อมต่อภายนอก

  • เมื่อ workflow definition, workflow instance, หรือ step instance มีการเปลี่ยนแปลง Maestro จะสร้างอีเวนต์และหลังจากประมวลผลภายในแล้วจะเผยแพร่ไปยังระบบภายนอก
  • อีเวนต์ของ Maestro แบ่งเป็นอีเวนต์ภายในและอีเวนต์ภายนอก
    • internal event: ติดตามการเปลี่ยนแปลงภายในวงจรชีวิตของ workflow, workflow instance และ step instance และถูกเผยแพร่ไปยังคิวภายใน
    • external event: มีข้อมูลการเปลี่ยนแปลงสถานะของ Maestro สำหรับให้บริการ downstream นำไปใช้ และถูกส่งไปยังคิวภายนอกอย่าง SNS·Kafka
  • Maestro event processor จะ subscribe คิวภายในเพื่อดึง internal event มา จากนั้นประมวลผลตามประเภทของอีเวนต์ และหากจำเป็นก็แปลงเป็น external event
  • notification publisher ในขั้นตอนสุดท้ายจะเผยแพร่อีเวนต์ภายนอกเพื่อให้บริการ downstream นำไปใช้งานได้
  • บริการ downstream ส่วนใหญ่ทำงานแบบ event-driven และอีเวนต์ของ Maestro มีข้อความที่จำเป็นสำหรับตรวจจับการเปลี่ยนแปลงหลากหลายแบบใน Maestro
  • ประเภทของการเปลี่ยนแปลงแบ่งใหญ่ ๆ ได้เป็น 2 หมวด
    • workflow change: การทำงานระดับ workflow เช่น การเปลี่ยนแปลง workflow definition หรือ properties
    • instance status change: การเปลี่ยนสถานะของ workflow instance หรือ step instance

วิธีเริ่มต้น

  • สามารถดูโค้ดของ Maestro ได้ที่ github.com/Netflix/maestro
  • หากมีคำถาม ความเห็น หรือคอมเมนต์ สามารถฝากไว้ที่ GitHub issue ของรีโพซิทอรี Maestro
  • Netflix คาดหวังว่าความสามารถในการขยายระบบและความสะดวกในการใช้งานที่ Maestro มอบให้ จะช่วยให้การพัฒนา workflow นอก Netflix ทำได้รวดเร็วขึ้นเช่นกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-24
ความคิดเห็นจาก Hacker News

  • เมื่อก่อนผมเคยทึ่งกับบล็อกเทคนิคของบริษัทแบบนี้และระบบภายในที่เป็นกรรมสิทธิ์เฉพาะ แต่ตอนนี้ไม่แล้ว เพราะ โค้ดคือหนี้
    แทนที่จะสร้างของอย่าง cron/Celery/Airflow ขึ้นมาใหม่ ผมอยากใช้ โอเพนซอร์ส สำเร็จรูปที่มีประวัติการบำรุงรักษาและปรับปรุงมายาวนานมากกว่า เพราะต้องมีใครสักคนคอยดูแล แก้บั๊ก และเพิ่มฟีเจอร์อยู่ดี แน่นอนว่ายกเว้นกรณีที่มีการเลื่อนตำแหน่งและเงินเดือน/RSU เพิ่มตามมา
    เราควรตระหนักว่าโค้ดที่ไม่ใช่งานหลักที่ทำเงินให้บริษัทนั้นเป็นสิ่งที่เบี่ยงเบนความสนใจและกินทรัพยากร

    • ผมคิดว่าบทความบล็อกนี้น่าจะออกมาด้วยเหตุผลนั้นพอดี คือทำให้ซอฟต์แวร์นี้เป็น โอเพนซอร์ส เพื่อจะได้ไม่ต้องบำรุงรักษาทั้งหมดภายในอย่างเดียวอีกต่อไป
      พวกเขาสร้างมันขึ้นมาเพราะมีความต้องการที่โอเพนซอร์สสำเร็จรูปเดิมแก้ไม่ได้ และตอนนี้กำลังเปลี่ยนมันกลับไปเป็นโอเพนซอร์สสำเร็จรูปเพื่อใช้งานต่อไปพร้อมแบ่งภาระการบำรุงรักษา เครื่องมือแบบนี้จะเกิดขึ้นตั้งแต่แรกได้อย่างไร ถ้าไม่มีใครสร้างมัน
    • มุมมองที่ว่า “โค้ดคือหนี้” นั้นสุดโต่งเกินไป และเชื่อมโยงอย่างแรงกับแนวคิดแบบ MBA ที่พยายาม ทำให้ทุกอย่างเป็นการหาค่าต่ำสุด-สูงสุด
      ดีแล้วที่ยังมีคนที่ไม่กลัวการสร้างระบบใหม่และผลักดันไอเดียใหม่ ๆ แม้จากมุมมองของบริษัทเอง วิธีแก้ปัญหาที่ธรรมดาและหลีกเลี่ยงความเสี่ยงอย่างเดียวก็มีขีดจำกัด บริษัทที่ทำกำไรได้สูงสุดมักค่อนข้างกล้าหาญในเชิงเทคนิค
      โค้ดไม่ใช่หนี้ แต่เป็นสิ่งที่ทำให้ฟันเฟืองของบริษัทหมุน
    • โอเพนซอร์สสำเร็จรูปเองก็มักเป็นผลลัพธ์จากการที่บริษัทใหญ่เปิดเครื่องมือภายในออกมา ตัวอย่างที่ดีคือ Airflow ที่คุณพูดถึงเอง และในสายนี้ Temporal ก็เช่นกัน ต้องมีใครสักคนที่ “โง่พอ” จะสร้างของใหม่ขึ้นมา
    • คำว่า “มีประวัติการบำรุงรักษาและปรับปรุงมายาวนาน” แบกรับสมมติฐานมหาศาลอยู่
      ผมสงสัยว่าคุณมีแผนจะมีส่วนร่วมกับคอมมูนิตี้เองด้วยหรือเปล่า จะสร้างเองหรือซื้อมาใช้นั้นเป็นประเด็นสำคัญเสมอ แต่การมองว่าฝั่ง ‘ซื้อ’ มีต้นทุนด้านการบำรุงรักษาและความน่าเชื่อถือเท่ากับ 0 พอดีนั้นดูไร้เดียงสาไปหน่อย
    • เงื่อนไขที่ว่า “ไม่ใช่งานหลักของบริษัท” นั้นสำคัญ หากเป็นทีมที่ชำนาญในพื้นที่ที่ประสิทธิภาพสำคัญ จุดเปลี่ยนที่โค้ดภายนอกจะกลายเป็น หนี้คุณภาพต่ำ/ควบคุมได้น้อย ก็ไม่ได้อยู่ไกลนัก

  • ผมสงสัยว่าต้องวนซ้ำกันอีกกี่รอบกว่าวิศวกรจะพอใจกับโซลูชันเวิร์กโฟลว์ได้ ก่อน Maestro นั้น Netflix ก็มีโซลูชันหลายอย่างอย่าง Metaflow อยู่แล้ว Uber ก็สร้างหลายโซลูชันเช่นกัน และที่ Amazon ก็มี เอนจินเวิร์กโฟลว์ ภายในอย่างน้อยเป็นสิบตัว
    น่าสนใจที่คนจำนวนมากในหลายบริษัทอยากสร้างเอนจินเวิร์กโฟลว์ ไม่ได้จะโจมตีใครหรือ Netflix แต่อย่างใด แค่มองว่าเป็นข้อสังเกตที่น่าคุยกันเล่น ๆ

    • ปัญหาอยู่ที่ การออร์เคสเทรตเวิร์กโฟลว์ เป็นขอบเขตปัญหาที่กว้างมาก บริษัทต่าง ๆ ต้องแก้ปัญหาหลายแบบที่แตกต่างกัน ทำให้ไม่ว่าโซลูชันใดก็กลายเป็นผลิตภัณฑ์ขนาดใหญ่ที่มีฟีเจอร์เกี่ยวข้องมากมาย และเมื่อเติบโตขึ้นก็มักกลายเป็นก้อนเดียวขนาดใหญ่ที่มีปรัชญาแข็งแรง จึงแทบไม่มีใครพอใจ
      ในทางปฏิบัติมีประเด็นหลักห้าด้าน: การจัดตารางทรัพยากร, การแก้ dependency, API/DSL สำหรับสร้างงานและเวิร์กโฟลว์, การรันตามกำหนดเวลาแบบ cron, และ การรับรู้โดเมน ที่เผยข้อมูลโดเมนในเวิร์กโฟลว์ ETL หรือ ML/AI
      ไม่มีโซลูชันเดียวที่ทำทั้งหมดนี้ได้อย่างเรียบร้อย ดังนั้นบริษัทต่าง ๆ จึงสร้างเองหรือหาทางอ้อมเพื่ออุดข้อด้อยของสินค้าสำเร็จรูปที่มีอยู่ และวงจรที่ทุกคนยังไม่พอใจก็ดำเนินต่อไป
      ผมไม่คิดว่านี่เป็นปัญหาที่สตาร์ทอัพสักแห่งจะสร้าง “คำตอบ” ออกมาได้ ควรแก้ด้วย อีโคซิสเต็มโอเพนซอร์ส ที่ประกอบด้วยคอมโพเนนต์โมดูลาร์แบบเสียบเปลี่ยนได้ที่ดี
    • Metaflow ทำงานอยู่บน Maestro และทั้งสองตัวไม่ได้แทนที่กัน
      ใน https://netflixtechblog.com/orchestrating-data-ml-workflows-... ระบุไว้ว่า “Users can use Metaflow library to create workflows in Maestro to execute DAGs consisting of arbitrary Python code.”
      ส่วนออร์เคสเทรชันของบทความนี้ (https://netflixtechblog.com/supporting-diverse-ml-systems-at...) อธิบายไว้อย่างละเอียดว่า Metaflow เชื่อมเข้ากับ Maestro, Airflow, Argo Workflows และ Step Functions อย่างไร
    • ผมเคยสร้างเอนจินเวิร์กโฟลว์เอง แต่มันมีบั๊กเยอะมากและไม่ยืดหยุ่นเอาเสียเลย จนเกือบทำให้โปรเจกต์ที่ไม่เกี่ยวกันโปรเจกต์หนึ่งพัง
      ผมเริ่มคิดว่าเอนจินเวิร์กโฟลว์อาจเป็น กลิ่นของการออกแบบ ในระดับหนึ่ง พอสร้างอะไรที่นำกลับมาใช้ซ้ำได้ครั้งหนึ่ง มันดูน่าดึงดูดเหมือนจะเอาไปใช้กับเวิร์กโฟลว์จำนวนมากได้ แต่เวิร์กโฟลว์เหล่านั้นแทบไม่มีอะไรเหมือนกันเลย นอกจากต้องมีขั้นตอนอะซิงโครนัสมากกว่าหนึ่งขั้น
      ข้อมูลก็ต่างกัน, API ก็ต่างกัน, ฟีดแบ็กที่ต้องรับจากผู้ใช้หรือระบบอื่นเพื่อเดินหน้าต่อก็ต่างกัน
    • น่าจะเป็นเพราะเรายังหา เอนจิน/ออร์เคสเตรเตอร์เวิร์กโฟลว์ ที่ทั้งจัดการงานหลากหลายและยังเข้าใจง่ายกับดูแลง่ายไม่ได้
      การสร้างเอนจินเวิร์กโฟลว์แบบกำหนดเองที่ปรับให้เหมาะกับ use case เฉพาะนั้นง่ายมาก ผมคิดว่าเหตุผลที่ยังไม่เกิดการบรรจบกัน ก็เพราะเครื่องมือแบบนั้นยังไม่ถูกสร้างขึ้นมา
      ถ้าดูเครื่องมือที่เข้าครองแต่ละโดเมนอย่างรวดเร็วในช่วงหลัง Terraform แก้ปัญหา IaC ส่วน Kubernetes แก้ปัญหายากของ distributed computing ทั้งสองอย่างซับซ้อนมากแต่ก็แก้ปัญหายากได้ ในทางกลับกัน เอนจินเวิร์กโฟลว์แบบทั่วไปนั้นเข้าใจยาก ดูแลยาก และประสบการณ์ก็คลุมเครือ ทำให้คนจำนวนมากไม่แม้แต่จะลองใช้
    • การตั้งชื่อ, cache invalidation, แล้วก็เอนจินเวิร์กโฟลว์งั้นหรือ? :)
      https://github.com/meirwah/awesome-workflow-engines

  • ผมเป็นผู้ก่อตั้ง https://windmill.dev โดย Windmill มีความคล้ายคลึงกับ Maestro อยู่มาก
    ในคำอธิบายของ Maestro ส่วนที่ระบุว่า “ตัว orchestrator เวิร์กโฟลว์แบบใช้งานทั่วไปที่ขยายแนวนอนได้ สำหรับจัดการเวิร์กโฟลว์ขนาดใหญ่, data pipeline และ pipeline สำหรับฝึกโมเดล ML” หากเปลี่ยนเป็น Windmill ก็ยังตรงเป๊ะ สิ่งที่พวกเขาเรียกว่า rollup คือสิ่งที่เราเรียกว่า openflow state
    ความแตกต่างหลักคือ Windmill เขียนด้วย Rust แทน Java และ Maestro ใช้ CockroachDB สำหรับเก็บสถานะ แต่เราใช้ PostgreSQL ทั้งสำหรับสถานะและคิว อย่างไรก็ตาม ก็เข้าใจได้ว่าทำไมถึงใช้ CockroachDB Windmill เองก็ต้องสร้างอัลกอริทึม sharding ของตัวเองเพื่อขยายแนวนอนในอินสแตนซ์ลูกค้าขนาดใหญ่มากเช่นกัน
    Maestro ใช้ Apache 2.0 ส่วน Windmill ใช้ AGPL ซึ่งเป็นมิตรน้อยกว่า แม้จะได้รับการสนับสนุนจาก Netflix จึงมีเงินทุนแทบไม่จำกัด แต่เราเป็นบริษัทที่เล็กกว่ามาก แม้เราจะทำกำไรได้ก็ตาม
    Maestro ยังไม่มีเอกสารสำหรับ self-hosting บน Kubernetes หรือ docker-compose มากพอ และดูเหมือนจะไม่มี UI สำหรับสร้างอะไรบางอย่าง หรืออย่างน้อยก็ยังไม่ปรากฏชัดในเอกสาร ถึงอย่างนั้น โดยรวมแล้วการเปิดเป็นโอเพนซอร์สก็ค่อนข้างยอดเยี่ยม และผมจะคอยติดตามต่อไป พร้อมจะ benchmark ให้เร็วที่สุดเท่าที่ทำได้

    • ถ้ากำลังพิจารณา Windmill ควรดูสิ่งนี้ก่อน: https://www.windmill.dev/docs/advanced/local_development
      ไม่เข้าใจว่าทำไมต้อง “ซิงก์” กับ Windmill ทำไมถึงมี IDE อยู่ใน Windmill และทำไมมันซับซ้อนขนาดนี้ ดูเหมือนเริ่มต้นโดยตั้งเป้าเรื่อง lock-in ก่อนที่จะสร้างผลิตภัณฑ์ที่ดีหรือหา product-market fit ได้เสียอีก
    • การเปรียบเทียบเป็นเรื่องดี แต่ถึง Maestro จะใช้ไลเซนส์ Apache หากต้องพึ่งพา CockroachDB ก็ไม่ค่อยดีนัก เพราะ CockroachDB เองไม่ใช่โอเพนซอร์ส
      ผมมองว่า โค้ดเบส AGPL ยังดีกว่าการพึ่งพาที่ไม่ใช่โอเพนซอร์ส แน่นอนว่าเมื่อเวลาผ่านไป อาจมีใครสักคนเพิ่มการรองรับฐานข้อมูลทางเลือกเข้ามาได้

  • ค่อนข้างสับสนว่าเกิดอะไรขึ้นตรงนี้ โปรเจกต์นี้ดูเหมือนจะใช้ Netflix/conductor [0] แต่พอไปดู repository นั้น กลับถูก archive ไว้แล้ว และมีข้อความว่าถูกแทนที่ด้วยเวอร์ชันภายในของ Netflix ที่ไม่ใช่โอเพนซอร์ส รวมถึง community fork ที่ไม่ได้ระบุชื่อ คงหมายถึง Orkes Conductor [1]
    แต่สิ่งนี้ดูเหมือนจะไม่ได้ใช้ Orkes Conductor และเหมือนใช้เวอร์ชัน Netflix ที่หยุดพัฒนาแล้วคือ com.netflix.conductor:conductor-core:2.31.5 [2] แถมยังเป็นเวอร์ชันเก่าอีกด้วย
    [0] https://github.com/Netflix/conductor
    [1] https://github.com/conductor-oss/conductor
    [2] https://github.com/Netflix/maestro/blob/e8bee3f1625d3f31d84d...

    • ใช่แล้ว Netflix เลิกใช้ Conductor ไปนานแล้ว [0] repository อื่นนั้นเป็นสิ่งที่ Orkes สร้างและดูแลหลังจาก Netflix เลิกสนับสนุน
      [0] https://techcrunch.com/2023/12/13/orkes-forks-conductor-as-n...

  • อยากรู้ว่ามีใครเคยใช้ ActiveBatch บ้างไหม สำหรับผม มันเป็นซอฟต์แวร์ชั้นยอดที่อยากให้มีผลิตภัณฑ์เทียบเท่าสำหรับผู้ใช้ที่ไม่ใช่องค์กร
    ผมพยายามลองใช้ “คู่แข่ง” อื่น ๆ อยู่เรื่อย ๆ แต่ ActiveBatch แค่ต่อกับ MS SQL DB ธรรมดา ติดตั้ง Windows GUI กับ execution agent ก็ได้สภาพแวดล้อม automation แบบ GUI ที่แข็งแรงด้วยการคลิกไม่กี่ครั้ง ไม่ต้องเขียนโค้ดก็ได้ และถ้าต้องการ ก็เขียนโค้ดด้วยภาษาอะไรก็ได้
    Airflow อาจทรงพลัง แต่ซ่อนอยู่หลังกำแพงความซับซ้อน ทำให้คนส่วนใหญ่ไม่เห็นศักยภาพที่แท้จริง ไม่ว่ามันจะมีความสามารถอะไรจริง ๆ ก็ตาม “คู่แข่ง” โอเพนซอร์สรายอื่นก็เช่นกัน
    ไม่เข้าใจว่าทำไมถึงไม่มีใครสร้าง ระบบที่ใช้ DB เป็นฐานและให้ GUI มาก่อน ที่แข็งแรงขึ้นมาได้ ผมลองบริการออนไลน์แล้ว แต่เทียบกันไม่ได้เลย เหตุผลที่ผลิตภัณฑ์แบบจ่ายเงินที่เรียบง่ายกว่าล้มเหลว อาจเป็นเพราะต้นทุนการดูแลส่วนขยายก็ได้
    น่าเสียดายจริง ๆ ที่ ActiveBatch ถูกขังอยู่หลังโมเดลการขายองค์กรแบบงี่เง่า สิ่งนี้กำลังขัดขวางไม่ให้ซอฟต์แวร์ที่ยอดเยี่ยมนี้แพร่ไปสู่ชุมชนที่กว้างขึ้น มันเหมือนความลับที่ถูกซ่อนไว้

  • ขอแนะนำว่าอย่าไปพึ่งพาเครื่องมือที่ Netflix เปิดเป็นโอเพนซอร์สดีกว่า พวกเขามี ประวัติ ยาวนานในการประกาศแล้วหยุดสนับสนุน
    บางคนคงได้ติ๊กช่องในแบบประเมินเลื่อนตำแหน่งจากบล็อกโพสต์และการปล่อยโค้ดครั้งนี้ แต่ไม่ควรสร้างธุรกิจบนโซลูชันแบบนี้

  • ไม่เข้าใจว่าทำไมถึงควรพิจารณาใช้ตัวนี้แทนสิ่งที่ตั้งหลักได้มากกว่าอย่าง Temporal Maestro เขียนด้วย Java และดูเหมือนว่า Temporal เขียนด้วย Go

    • โค้ด Go ของ Temporal ค่อนข้างแปลก เมื่อก่อนเหมือนจะใช้ Java แล้วเปลี่ยนมาเป็น Go และ Go นั้นก็ดูเป็นสไตล์ Java มาก
      หรืออาจเป็นเพราะผมไม่ค่อยรู้จัก Fx ก็ได้
      https://github.com/temporalio/temporal/blob/main/service/mat...
      ปัญหาที่เจอซ้ำ ๆ กับ Temporal คือเอกสารมีน้อยมาก มันเป็นของที่ต้องติดตั้งไว้ในแกนหลักของธุรกิจ แต่กว่าจะผ่านหลายชั้นและเอกสารที่เข้าใจยากมาก ๆ ไปจนเข้าใจว่าเกิดอะไรขึ้นจริง ๆ นั้นยากจริง ๆ
      Maestro ดูเหมือนจะไม่มีเอกสาร ถ้าเป็นอย่างนั้น Temporal ก็ชนะโดยปริยาย
    • Netflix ก็ใช้ Temporal ด้วย: https://temporal.io/in-use/netflix
    • ผมคิดว่า Maestro น่าจะเป็นทางเลือกแทน Airflow มากกว่า ไม่ใช่ทางเลือกแทน Temporal Temporal ไม่ใช่ workflow orchestrator แม้โครงสร้างภายในจะมีส่วนที่ทับซ้อนกันบ้าง แต่เป็นการออกแบบที่ต่างกันสำหรับกรณีการใช้งานที่ต่างกัน
    • ไม่ใช่ว่าเคยเขียนส่วนแกนหลักบางส่วนของ Temporal ใหม่ด้วย Rust หรอกหรือ?

  • เป็นโปรเจกต์ที่ดูดีจริง ๆ ในโปรเจกต์แทบทุกงานที่ผมเคยทำซึ่งผสม ML + data engineering ผมเคยคิดจะสร้างของที่เกือบเหมือนแบบนี้ หรืออาจเป็นเวอร์ชันที่แย่กว่านี้ด้วยซ้ำ
    รอคอยที่จะได้ลองทดสอบเอง

  • ผมกำลังสร้าง orchestra ในพื้นที่นี้อยู่ เลยขอเขียนความเห็นไว้ว่า การทำเป็นโอเพนซอร์สและพัฒนาอย่างเปิดเผยนั้นยอดเยี่ยมแน่นอน แต่สิ่งนี้ตามที่เจ้าตัวบอกเองก็คือ orchestrator และมีของที่มาก่อนหน้านี้มากมายแล้ว รวมถึง Airflow เป็นต้น
    ดังนั้นจึงมองยากว่ามันเพิ่มอะไรให้กับพื้นที่นี้จริง ๆ นอกจากเพิ่มอีกหนึ่งตัวเลือกที่ไม่มีใครจะใช้ในสภาพแวดล้อมเชิงพาณิชย์
    โปรโมตแบบหน้าด้าน ๆ: https://getorchestra.io

  • สงสัยว่ามันแตกต่างอย่างมีนัยสำคัญจาก Conductor ที่เคยถูก archive ไว้หรือไม่ ลองไล่ดูโค้ดแล้วเห็นความคล้ายกันอยู่พอสมควร และยังเหมือนกันตรงที่ใช้ JSON เป็นภาษาในการนิยาม workflow