เจาะลึก
DATABASE
เลิกง้อ Temporal กันเถอะ — Postgres เดี่ยวๆ ก็รัน Workflow แบบ Durable ได้แล้ว
ทำไมต้องแบก orchestrator ตัวเป็นๆ ให้ปวดหัว ในเมื่อฐานข้อมูลที่คุณมีอยู่แล้วมันทำได้
ทีมข่าว เอไอไทย.com
⏱ อ่าน 5 นาที
บางทีความซับซ้อนที่เราต้องการ orchestrator ตัวใหม่ ก็แค่ SQL ไม่กี่บรรทัดที่เราไม่เคยกล้าใช้
ถ้าคุณเคยต้อง setup Temporal, Airflow หรือ Cadence เพียงเพื่อให้ workflow ทำงานได้แบบ durable คือพังแล้วรันต่อจากจุดเดิมได้ ไม่ต้องเริ่มใหม่หมด คุณจะรู้ว่ามันเป็นงานงอกขนาดไหน ต้องมี service แยก ต้องมี worker pool ต้องมี database ของมันเอง ต้อง deploy หลายอย่าง กว่าจะได้ workflow หนึ่งตัวที่ sleep ได้ รอ human approval ได้ แล้วไม่หายไปตอน server restart นี่มันเกินจำเป็นไปเยอะ
Raman Varma เขียนบทความลง InfoQ ชี้ว่าเราสามารถใช้ Postgres เป็นทั้ง durable state store และ coordination layer สำหรับ workflow ได้เลย โดยไม่ต้องพึ่ง external orchestrator ตัวไหน ฟังดูเหมือนขายฝัน แต่เทคนิคที่เขาเสนอคือของจริงที่คนทำ production ใช้กันอยู่แล้ว
หัวใจของเรื่องนี้คือ SKIP LOCKED — คำสั่ง Postgres ที่ให้ worker หลายตัวดึงงานจากตารางเดียวกันไปทำพร้อมกันได้ โดยไม่ต้องแย่ง lock กันและกัน ใครหยิบงานไหนไปแล้ว ตัวอื่นจะข้ามไปหยิบอันถัดไปทันที ไม่ต้องรอ ไม่ต้อง block นี่คือสิ่งที่ทำให้ Postgres กลายเป็น queue ได้ในตัว
ต่อมาคือ primary-key checkpoints ใช้ enforce idempotency คือถ้า workflow ตัวหนึ่งรันไปแล้วบาง step แล้ว crash กลางทาง พอรันใหม่มันจะรู้ว่าทำถึงไหนแล้ว และไม่ทำ step เดิมซ้ำ สิ่งนี้สำคัญมากในระบบที่ retry เป็นเรื่องปกติ เพราะถ้าไม่มี checkpoint คุณอาจส่งอีเมลซ้ำ หักเงินซ้ำ หรือ trigger อะไรที่ไม่ควร trigger ซ้ำได้
และ leases สำหรับ crash recovery — worker ที่หยิบงานไปจะถือ lease ไว้ ถ้ามันตายกลางทาง lease จะหมดอายุ แล้ว worker ตัวอื่นหยิบงานนั้นไปทำต่อได้ กลไกนี้ทำให้ระบบทนต่อการล่มของ worker โดยไม่ต้องมีคนมานั่ง restart ด้วยมือ
จุดที่ผมว่าฉลาดที่สุดในบทความนี้คือการบอกว่า workflow ที่ต้อง sleep รอนานๆ หรือรอคนกด approve ก็เก็บเป็น state ใน database ได้เหมือนกัน ไม่ต้องมี in-memory timer ไม่ต้องมี scheduler แยก พอ server restart ทุกอย่างยังอยู่ครบ workflow ที่นอนรออยู่ก็ตื่นมาทำต่อได้ตามเวลาที่ควรทำ นี่คือสิ่งที่ orchestrator หลายตัวทำได้ แต่ Postgres ก็ทำได้เหมือนกัน
ทีนี้ต้องพูดตรงๆ ว่าวิธีนี้ไม่ใช่ยาครอบจักรวาล ถ้า workflow ของคุณซับซ้อนระดับมี branching เยอะๆ มี sub-workflow ซ้อนกันหลายชั้น หรือมีคนในทีมสิบคนต้องมา debug พร้อมกัน การมี orchestrator ที่มี UI ให้ดู state ทุกอย่างอาจจะคุ้มค่ากว่าการไปนั่งอ่านตารางใน Postgres เอง แต่มันก็เป็น trade-off ที่ต้องคิด ไม่ใช่ default ว่าต้องมี orchestrator เสมอ
อีกเรื่องที่ต้องระวังคือ load ที่จะตกไปที่ Postgres มากขึ้น ถ้าคุณใช้ database ตัวเดียวกันทั้งระบบ และเอามันมารัน workflow ด้วย คุณต้องคิดเรื่อง connection pool, index, และ vacuum ให้ดี ไม่งั้น database ที่ควรจะเสถียรจะกลายเป็นคอขวดของทั้งระบบแทน
SKIP LOCKED
ให้ worker หลายตัวดึงงานจากตารางเดียวกันพร้อมกันได้ ไม่ต้องแย่ง lock กัน
Primary-key checkpoints
enforce idempotency ป้องกันการทำ step เดิมซ้ำเมื่อ workflow retry
Leases
รองรับ crash recovery — worker ตายแล้ว lease หมดอายุ ตัวอื่นรับงานต่อได้
Sleep & Human Approval
เก็บเป็น database state ได้ ไม่หายเมื่อ restart ไม่ต้องมี scheduler แยก
โดยรวมแล้ว บทความนี้ไม่ใช่การบอกให้ทุกคนเลิกใช้ orchestrator แต่เป็นการเตือนสติว่า อย่าเพิ่มความซับซ้อนให้ระบบโดยไม่จำเป็น ถ้าปัญหาของคุณคือ "workflow ต้อง durable" และคุณมี Postgres อยู่แล้ว ลองถามตัวเองดูก่อนว่าจำเป็นต้องลากเครื่องมือใหม่อีกตัวเข้ามาจริงหรือเปล่า
orchestrator ตัวใหม่ไม่ใช่คำตอบของทุกปัญหา บางทีสิ่งที่คุณต้องการจริงๆ คือเข้าใจ SQL ที่มีอยู่แล้วให้ลึกพอ — และกล้าพอที่จะไม่เพิ่มเครื่องมือใหม่เข้าไปใน stack
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 6
กำลังโหลดความคิดเห็น...