Saga Rollback Mechanics: จัดการความล้มเหลวระบบ
เจาะลึก Saga Rollback Mechanics และความท้าทายในการทำ Compensating Transaction ของระบบกระจายตัวในภาษา Go
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การทำธุรกรรมแบบ 2PC มีต้นทุนสูงในการล็อกเครือข่ายและเสี่ยงต่อจุดล้มเหลวเดี่ยว
- Saga ใช้ลำดับธุรกรรมย่อยคู่กับ Compensating Transaction เพื่อแก้ปัญหาการทำงานแบบกระจายตัว
- การชดเชยต้องเป็นไปตามลำดับ LIFO อย่างเคร่งครัดเพื่อป้องกันความขัดแย้ง
- บริการทั้งหมดใน Saga ต้องออกแบบให้เป็นแบบ Idempotent เพื่อป้องกันการทำงานซ้ำซ้อน
การทำธุรกรรมแบบกระจายตัวผ่าน Two-Phase Commit หรือ 2PC มักมีต้นทุนการดำเนินงานที่สูงมาก เนื่องจากตัวประสานงาน (coordinator) กลายเป็นจุดล้มเหลวเดี่ยว ผู้เข้าร่วมต้องถือล็อกข้ามเครือข่าย และหากมีโหนดใดโหนดหนึ่งล่ม ระบบทั้งหมดจะถูกบล็อกทันที ในขณะที่ Saga เข้ามาแทนที่การรับประกันความเป็นอะตอม (atomicity) ด้วยชุดธุรกรรมภายในเครื่อง (local transactions) ที่แต่ละขั้นตอนจะมี Compensating Transaction คู่กันเพื่อทำการยกเลิกผลลัพธ์ในเชิงความหมาย
อย่างไรก็ตาม การยกเลิกในเชิงความหมาย (semantically undo) นั้นไม่เท่ากับการยกเลิกแบบอะตอม (atomically undo) ในระดับฐานข้อมูล และความเหลื่อมล้ำตรงนี้คือจุดที่ความล้มเหลวส่วนใหญ่ในระบบโปรดักชันเกิดขึ้น การชดเชยไม่ใช่การย้อนกลับฐานข้อมูลแบบดั้งเดิม แต่เป็นการเดินหน้าสร้างการดำเนินการใหม่ที่นำระบบกลับสู่สถานะเทียบเท่าก่อนทำธุรกรรมจากมุมมองทางธุรกิจ
ลำดับการชดเชยจะต้องเป็นแบบ Last-In, First-Out (LIFO) ของขั้นตอนที่คอมมิต์สำเร็จแล้วอย่างเคร่งครัด หาก T4 เกิดความล้มเหลว คุณต้องเรียกใช้ C3, C2 และ C1 ตามลำดับนั้น การฝ่าฝืนลำดับ เช่น รัน C1 ก่อน C3 อาจทำให้เกิดการละเมิดความถูกต้องของอินเวอรันต์ได้ และหน้าต่างเวลานี้เองคือกับดักการทำงานบางส่วน (partial execution trap)
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การทำความเข้าใจความแตกต่างระหว่าง Database Rollback ทั่วไปกับ Saga Compensation เป็นหัวใจสำคัญในการออกแบบระบบ Microservices เนื่องจากระบบกระจายตัวไม่สามารถล็อกฐานข้อมูลข้ามบริการเป็นเวลานานได้ การใช้ Compensating Transactions จึงเป็นการแลกเปลี่ยนความสอดคล้องทันที (Strong Consistency) กับความพร้อมใช้งาน (Availability) ตามทฤษฎี CAP Theorem
"The promise is looser coupling and no cross-service lock contention. The trap is that semantically undo is not the same as atomically undo, and most production failures happen in that gap."
Dev.to Article
ตัวประสานงาน (coordinator) จะต้องเป็น Durable State Machine ที่ทำการบันทึกสถานะการเปลี่ยนผ่านอย่างถาวรก่อนที่จะดำเนินการใดๆ ต่อไป เพื่อป้องกันปัญหาการกู้คืนระบบหลังจากพอด (pod) หรือพนักงานประมวลผลล่ม นอกจากนี้ เนื่องจากตัวประสานงานจะทำการลองทำใหม่ (retry) เมื่อเกิดความล้มเหลวชั่วคราว ทุกขั้นตอนและการชดเชยจึงจำเป็นต้องมีคุณสมบัติ Idempotency โดยใช้คีย์ที่สร้างจากรหัส Saga และดัชนีขั้นตอน
เมื่อเกิดความล้มเหลวอย่างถาวรในขั้นตอนการชดเชย เช่น C3 ล้มเหลวซ้ำๆ ระบบจะติดอยู่ในสถานะชดเชยบางส่วน (partially compensated state) ซึ่งต้องอาศัยการแทรกแซงจากมนุษย์หรือ Saga สำหรับการแก้ไขปัญหาเฉพาะหน้า ระบบในโปรดักชันจึงควรใช้งานสถาปัตยกรรมเช่นการบันทึกสถานะไปยัง DynamoDB หรือ MongoDB Atlas และส่งอีเวนต์ผ่าน SQS สำหรับการแจ้งเตือน
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น