Hatchet – คิวงานแบบกระจายโอเพนซอร์ส

 (github.com/hatchet-dev)
11 คะแนน โดย GN⁺ 2024-03-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

คิวงานแบบกระจายที่ทนทานต่อความล้มเหลว

  • Hatchet ช่วยให้สามารถออกแบบเวิร์กโหลดที่ทนทานซึ่งกู้คืนจากความล้มเหลวได้ และแก้ปัญหาอย่าง concurrency, fairness, และ rate limiting ได้ โดยเข้ามาแทนที่คิวหรือระบบ pub/sub แบบเดิมที่ดูแลจัดการได้ยาก
  • แทนที่จะต้องดูแลคิวงานหรือระบบ pub/sub ของตัวเอง สามารถใช้ Hatchet เพื่อกระจายฟังก์ชันไปยังชุดของ worker ได้ด้วยการตั้งค่าหรือโครงสร้างพื้นฐานให้น้อยที่สุด

ข้อดีของ Hatchet

  • การจัดตารางแบบหน่วงต่ำมากและรองรับงานปริมาณสูง
    • Hatchet สร้างบนคิวแบบ latency ต่ำที่มีเวลาเริ่มต้นเฉลี่ย 25ms จึงมอบสมดุลที่ลงตัวระหว่างความสามารถในการโต้ตอบแบบเรียลไทม์กับความน่าเชื่อถือที่จำเป็นสำหรับงานสำคัญระดับ mission-critical
  • Concurrency, fairness, rate limiting
    • ใช้กลยุทธ์ในตัวของ Hatchet เพื่อรองรับแนวทางอย่าง FIFO, LIFO, Round Robin และ Priority Queues ช่วยหลีกเลี่ยงปัญหาการสเกลที่พบบ่อยได้ด้วยการตั้งค่าเพียงเล็กน้อย
  • ความยืดหยุ่นที่ออกแบบมาในตัว
    • ด้วยนโยบาย retry แบบกำหนดเองและการจัดการข้อผิดพลาดแบบรวมศูนย์ Hatchet ช่วยให้มั่นใจได้ว่างานจะกู้คืนจากความล้มเหลวชั่วคราวได้อย่างรวดเร็ว

การมองเห็นและการควบคุมที่ดีขึ้น

  • Observability
    • การทำงานทุกครั้งสามารถค้นหาได้ทั้งหมด ทำให้ระบุปัญหาได้อย่างรวดเร็ว
  • การรันแบบคงทนที่ใช้งานได้จริง
    • สามารถ replay event และเริ่มการรันใหม่ด้วยตนเองจากบางขั้นตอนของ workflow ได้
  • Cron
    • สามารถจัดตารางให้รันฟังก์ชันซ้ำ ๆ ได้
  • การจัดตารางแบบครั้งเดียว
    • สามารถกำหนดเวลาให้รันฟังก์ชันในวันและเวลาที่ระบุได้
  • การป้องกันสไปก์
    • ช่วยบรรเทาการพุ่งขึ้นของทราฟฟิก และรันเฉพาะเท่าที่ระบบรองรับได้
  • การสตรีมแบบค่อยเป็นค่อยไป
    • สามารถ subscribe การอัปเดตตามความคืบหน้าของ background worker ได้

ตัวอย่างกรณีใช้งาน

  • Fairness สำหรับ Generative AI
    • สามารถใช้ Hatchet เพื่อกระจายคำขอไปยัง worker อย่างเป็นธรรม เพื่อไม่ให้ผู้ใช้ที่ใช้งานหนักทำให้ระบบล้นเกิน
  • การประมวลผลแบบแบตช์สำหรับการทำดัชนีเอกสาร
    • Hatchet รองรับการประมวลผลเอกสาร รูปภาพ และข้อมูลอื่น ๆ แบบแบตช์ขนาดใหญ่ และเมื่อเกิดความล้มเหลวก็สามารถทำต่อจากจุดกลางของงานได้
  • Workflow orchestration สำหรับระบบมัลติโหมด
    • Hatchet สามารถประสานอินพุตและเอาต์พุตแบบ multimodal และรองรับการทำงานทั้งชุดในสไตล์ DAG ได้
  • ความถูกต้องสำหรับการประมวลผลแบบ event-driven
    • สามารถตอบสนองต่อ event ภายนอกหรือ event ภายในระบบ และ replay event ได้โดยอัตโนมัติ

เริ่มต้นอย่างรวดเร็ว

  • Hatchet รองรับ SDK โอเพนซอร์สสำหรับ Python, Typescript และ Go
  • หากต้องการเริ่มต้น สามารถดูเอกสารของ Hatchet หรือตรวจสอบ quickstart repository ได้

ที่เก็บ SDK

  • Hatchet มี Go SDK ให้เป็นหลัก
  • นอกจากนี้ยังมี Typescript SDK ให้ใช้งาน
  • หากพบปัญหาที่เกี่ยวข้องกับ SDK สามารถส่ง issue ใน repository ที่เกี่ยวข้องได้

มี Hatchet เวอร์ชันคลาวด์แบบจัดการให้หรือไม่?

  • มี โดยในช่วงเบต้าได้เปิดให้บางบริษัทใช้งานเวอร์ชันคลาวด์ เพื่อช่วยสร้างและกำหนดทิศทางของผลิตภัณฑ์

มี Hatchet เวอร์ชัน self-hosted หรือไม่?

  • มี โดยสามารถดูคำแนะนำสำหรับโอเพนซอร์ส Docker container เพื่อการ self-hosting ได้จากเอกสาร

เทียบกับทางเลือกอื่นอย่างไร? (Celery, BullMQ)

  • ทำไมถึงสร้างคิวแบบจัดการอีกตัวขึ้นมา?
    • เพราะต้องการข้อดีของระบบคิวสำหรับทรานแซ็กชันแบบครบวงจร โดยเฉพาะที่พึ่งพาการรันในสไตล์ DAG และเชื่ออย่างมากว่า Postgres สามารถเข้ามาแทนกรณีใช้งานด้านคิวส่วนใหญ่ได้
    • คิวจำนวนมากสร้างบน Redis และหากไม่ระวังอาจเกิดการสูญหายของข้อมูลจาก OOM ได้ แต่การใช้ PG สามารถหลีกเลี่ยงปัญหาเหล่านี้ได้

ปัญหา

  • สามารถส่งบั๊กที่พบได้ผ่าน Github issue
  • เนื่องจากโปรเจกต์ยังอยู่ในระยะเริ่มต้น จึงแนะนำให้ติดต่อผ่าน Discord ก่อนหากมีคำขอฟีเจอร์ที่ซับซ้อน

หากต้องการมีส่วนร่วม

  • โปรดดูเอกสารการมีส่วนร่วม และแจ้งสิ่งที่อยากทำในช่อง #contributing ของ Discord เพื่อช่วยกำหนดทิศทางของโปรเจกต์และทำให้การร่วมมือกันง่ายขึ้น

ความเห็นของ GN⁺

  • Hatchet ดูเป็นโซลูชันที่ช่วยลดความซับซ้อนของการจัดการคิวงานในระบบแบบกระจาย พร้อมมอบความพร้อมใช้งานสูงและความทนทานต่อความล้มเหลว โดยน่าจะมีประโยชน์อย่างยิ่งสำหรับการประมวลผลข้อมูลขนาดใหญ่และบริการแบบเรียลไทม์
  • เมื่อเทียบกับระบบคิวอื่นที่ใช้อยู่ในตลาดปัจจุบัน ความเสถียรและความสามารถในการสเกลที่ได้จากการใช้ Postgres ถือเป็นจุดเด่นที่น่าสนใจ
  • สิ่งที่ควรพิจารณาเมื่อนำ Hatchet มาใช้งาน ได้แก่ ความเข้ากันได้กับโครงสร้างพื้นฐานเดิม การย้ายข้อมูล และความพร้อมด้านทักษะทางเทคนิคของทีม
  • ความสามารถด้านการมองเห็นและการควบคุมขั้นสูงที่ Hatchet มีให้ ช่วยให้การมอนิเตอร์ประสิทธิภาพของระบบและการแก้ปัญหาทำได้ง่ายขึ้น ลดภาระงานของทั้งนักพัฒนาและทีมปฏิบัติการ
  • เนื่องจาก Hatchet ยังอยู่ในช่วงเบต้า จึงยังต้องมีการตรวจสอบด้านเสถียรภาพและความสมบูรณ์ของฟังก์ชันอย่างเพียงพอ และควรทดสอบอย่างรอบด้านก่อนนำไปใช้กับระบบขนาดใหญ่

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

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

 
GN⁺ 2024-03-09
ความคิดเห็นจาก Hacker News
  • ผู้ใช้รายหนึ่งบอกว่าเขาตามหาผลิตภัณฑ์ที่มีคิวงานบนพื้นฐาน Postgres, worker ที่ทำงานได้หลายภาษา และมีความสามารถด้านการสังเกตการณ์ในตัวที่เหมาะสมมานาน 3 ปี เขาบอกว่าทุก ๆ 6 เดือนจะคอยเช็กตลาดและประเมินทางเลือกต่าง ๆ แต่ก็ผิดหวังอยู่เสมอ อย่างไรก็ตาม เขาอยากหลีกเลี่ยง dependency เพิ่มเติมอย่าง RabbitMQ จึงชอบคิวที่อิงกับ Postgres มากกว่า ปัจจุบันใช้ graphile-worker อยู่ แต่ก็ยังมีความต้องการบางอย่างที่ยังไม่ถูกตอบโจทย์
  • ผู้ใช้อีกรายชี้ว่าผลิตภัณฑ์นี้ได้รับการสนับสนุนจาก Y Combinator และสงสัยว่าบริษัทนี้จะเดินตามโมเดล "open core" หรือจะมองหาวิธีสร้างรายได้แบบอื่น
  • ผู้ใช้อีกคนกล่าวว่าชอบความสามารถของ push subscription ในระบบ pub/sub โดยยกตัวอย่างว่าใน GCP pub/sub สามารถมี subscriber ที่ push ไปยัง HTTP endpoint ได้แทนที่จะดึง event จากคิว วิธีนี้มีข้อดีคือสามารถใช้ runtime อย่าง Cloud Run หรือ Lambda เพื่อสเกลตาม HTTP request และสเกลลงจนเป็นศูนย์ได้ เขาบอกว่าการตั้งค่า autoscaling สำหรับ worker อาจซับซ้อนกว่า แม้จะสามารถตั้งค่า KEDA autoscaling บน RabbitMQ โดยอิงจาก metric ความลึกของคิวได้ แต่ก็เป็นการเพิ่มความซับซ้อน จึงถามว่ามีแผนจะรองรับโมเดลที่ daemon ซึ่งรักษาการเชื่อมต่อ HTTP ไว้สามารถ push งานเข้ามาได้หรือไม่
  • ผู้ใช้รายหนึ่งขอให้ช่วยอธิบายว่าทำไมทุกฟังก์ชันต้องรับ context เป็นอาร์กิวเมนต์ เพราะรู้สึกว่าทำให้ต้องเขียน boilerplate เยอะเวลาเขียนฟังก์ชัน
  • ผู้ใช้อีกคนบอกว่าถ้ามีไอเดียนี้ตอนที่เขากำลังสร้างระบบประมวลผล DAG แบบกระจายก็คงดี และอยากลองใช้งานดู
  • ผู้ใช้รายหนึ่งถามว่ามีการเปิดเผยราคาของบริการคลาวด์ที่ให้มาหรือไม่ และมีแผนจะทำ Kubernetes operator สำหรับตัวเลือก self-hosted หรือเปล่า นอกจากนี้ยังแสดงความกังวลว่าการใช้ไลเซนส์ MIT อาจทำให้ Amazon สร้างบริการ Amazon Hatchet ขึ้นมาในอนาคตได้
  • ผู้ใช้อีกคนกำลังเขียนคิวงานสำหรับ task runner แบบอิง DAG และต้องการให้กราฟงานถูกรันได้โดยใช้ PostgreSQL, SQLite, in-memory ฯลฯ โดยไม่ต้องคำนึงถึงการ retry, timeout, ทรัพยากรที่ต้อง serialize เป็นต้น ผู้ใช้นี้สนใจแนวทางดังกล่าว
  • ผู้ใช้รายหนึ่งบอกว่าต้องการคิวงานที่ให้ client (เว็บเบราว์เซอร์) ฟังความคืบหน้าของงานได้จนเสร็จ เขาชอบความเรียบง่ายและเข้าถึงง่ายของ Deno queue แต่ต้องไปทำวิธี subscribe สถานะงานจากฝั่ง client เอง เขาสงสัยว่าสามารถทำบนพื้นฐาน Postgres ได้หรือไม่ และยืนยันจากลิงก์เอกสารแล้วว่าสามารถทำได้
  • ผู้ใช้อีกคนเล่าว่าที่ทำงานเก่าเคยเจอปัญหาที่ต้องตั้งเวลางานได้ไม่จำกัด ตัวอย่างเช่น หากผู้ป่วยจองนัดไว้ล่วงหน้า 6 เดือน ก็ต้องตั้งเวลาการแจ้งเตือนหลายชุดสำหรับนัดหมายนั้นตลอดช่วงเวลาดังกล่าว ตอนแรกเขาเริ่มจากใส่เรคอร์ดลงใน database queue แล้ว polling ทุก ๆ ไม่กี่วินาที แต่ค่าใช้จ่ายด้าน IO จากการ polling ไม่เหมาะนัก และเขาอยากแก้ปัญหานี้โดยไม่ต้องใช้ระบบแบบกระจาย จากนั้นจึงย้ายไปใช้ Redis แต่ก็เจอปัญหาอย่างความซับซ้อนในการจัดการ dispatcher หลายตัว, ปัญหา OOM และต้องรันงานเสริมเพื่อย้ายงานไปยังคิวทันที เขาเคยคิดจะย้ายไปใช้ PG และใช้ SKIP LOCKED เป็นต้น แต่ก็ย้ายงานไปก่อน จึงสงสัยว่า Hatchet เหมาะกับ use case แบบนี้หรือไม่
  • สุดท้าย มีผู้ใช้ถามว่า Hatchet เทียบกับ Temporal/Cadence/Conductor อย่างไร และ Hatchet รองรับ durable execution ด้วยหรือไม่